Подумал о дешёвой двухпроводной шине для мелкой автоматизации на больших расстояниях.
Придумал простую схему, для передачи данных дёргать двумя GPIO через транзисторные ключи подключенные к высокочастотному трансформатору и таким образом генерировать импульсы с различной частотой. А для приёма данных, подсчитывать число принятых фотодиодом импульсов от светодиода подключенного к шине.
Но возникает проблема. Если кабель неизвестного качества и расстояния неизвестные. И число устройство подключенных на одну шину неизвестно, то для максимально надёжной передачи, нужно напряжение повыше. Но, в сети ведь есть падение напряжения и поэтому непонятно какое конкретно придёт на светодиод, 3 вольта или 50 вольт. Например от одного передатчика придёт 7 вольт, а от другого 40 вольт. А ещё в случае коллизии они могут наложится. А приёмник должен не выйти из строя. А в идеале нужно учесть и всякие проблемы со статическими потенциалами. Я конечно разбираюсь слабо, но что то мне подсказывает что в таких условиях светодиод долго не прослужит.
Нужна какая то простая схема, которая частоту переменного тока частотой несколько килогерц (от 0,3 до 5) и широкого диапазона напряжений, от 3 до 110 вольт преобразует в аналогичное количество открытий полевого транзистора на входном GPIO.
Примечание: Про схему шины с коротким замыканием двух жил знаю, но хочу сделать нечто более универсальное и в теории не требующие запитывания самой шины когда данные не передаются. А ещё что бы через фильтры, поток данных можно было загнать и в сеть переменного тока.
Да, в данном случае как верно заметил @torvn77, у тебя сетевой синус амплитудой 311 вольт просто сам по себе будет на 10 миллисекунд включать светодиод, и поверх него твои импульсы уже влиять не будут.
Интересно, сколько таких импульсов в секунду ожидается в типовой квартире? Это вопрос того какого размера должен быть пакет данных и какой тип алгоритма восстановления через избыточность данных выбрать.
Как то все слишком абстрактно.
Ты можешь какое-то минимально работающее устройство, или задачу, описать? Тогда можно говорить о реализации, а то пока больше вопросов чем ответов.
Создать простой открытый аппаратный стандарт и сделать фреймоворк для написания систем умного дома на произвольных языках программирования. Конечные исполняющие устройства должны быть очень дешёвые, то есть не должна каждая лампочка уметь ходить в интернет. А вся сложная логика должна быть на центральном узле сравнительно высокой вычислительной мощности, типа raspberry pi.
У системы должна быть независимость от простых глушилок бытовых радиодиапазонов, то есть надёжная связь по дешёвым проводам.
Это как USB, который имеет успех, потому что в самом начале позволял создавать максимально дешёвые устройства.
Тебе лучше избегать этих названий, потому как по закону ты ОБЯЗАН сделать так, чтобы твоя система управлялась исключительно только через внешний сайт с обязательной регистрацией и индентификацией пользователей, о чём можешь прочитать годовалую новость на опеннете.
ШТА?
Они упоролись?
Как это???
Вот так, решили что новый зонд должен сразу принадлежать государству, а не как Виндовс или Андройд частным компаниям(это моя интерпретация и я надеюсь что это так)
Я вообще не понимаю какой идиот придумал умный дом изначально через облако пускать.
Ну с точки зрения государства это не идеотизм так как позволяет собирать информацию о гражданах
Чтоб не быть совсем голословным поискал, на опенете ничего не находится, из всей сети нашлось два упоминания, одно из которых ссылается на другое:
Ссылка: https://www.kommersant.ru/doc/3924324
В целом может там и нет таких драконовских мер как я написал, но имхо если ТС будет продавать свои устройства как средства IoT то ему следует изучить законы ну или как минимум не давать устройству таких названий.
Ещё материал: https://polit.ru/article/2019/03/27/IoT/
“Интернет вещей” - это когда вещи являются устройствами подключающимися к интернету. Когда они имеют свои IP адреса.
Открытые стандарты для умного дома уже есть, 1-wire например, вот только оно похоже никому не нужно. Это как со смердфонами, 99% молча жрут зонды от эпла или гугла+вендора, ну и что, что барен лазит по твоему устройству, собирает телеметрию и в любой момент может его выключить, никому до этого нет дела. Так же и с иот, 99% просто купят вумный дилдак “ксеноми” и не будут заморачиваться с твоим raspberry pi
Тут надо смотреть на то, насколько сложно эти стандарты использовать неподготовленному по it человеку.
Если надо самому компиоять и набивать код то они конечно будут слишком сложны.
А если будет как LinuxCNC net net и ЧПУ с кастомной топологией готово то может стать и популярным.
Технически для масового потребителя это должно выглядеть приблизительно так:
Человек покупает всякие выключатели и датчики, которые стоят лишь на 50 или 100 рублей дороже таких же обычных. Устанавливает их. Цепляет к ним телефонный кабель или специальные беспроводные модули (если неудобно сигнальный провод тянуть). Подключает к шине главное устройство на базе raspberry pi и специальным приложением для смартфона через bluetooth вводит настройки сети и получает IP адрес WEB-интерфейса. (Ну или записав параметры в специальный файл на флешке)
Перейдя по адресу настраивает доступ и выбирает для установки конкретную систему управления. Зайдя в систему управления, уже в её настройках определяет какое устройство где находится и в её рамках настраивает всё остальное. Соответственно эти системы смогут быть как собственными скриптами на bash, платным ПО с свистопердельным интерфейсом. Или же вообще нейросетями запоминающими привычки пользователей.
Основные задачи:
Что бы каждый производитель мог приклеив к своим выключателям электромагнит и простую электронную схему - производить такие устройства. Естественно базовые шаблоны прошивки дешёвых чипов с протоколами обмена должны быть в открытом доступе.
Для системы управления умным домом все устройства должны быть видны в формате файловой системы, в которой можно считывать и записывать значения файлов, а так же запускать исполняемые файлы.
Основная проблема сегодняшних систем умного дома, в том что аппаратное обеспечение и система автоматизации не разделены.