Разработка интерфейса сети для связи устройств между собой является для меня ключевым вопросом. Принцип работы этой сети продумывался еще до создания блога и делались кой-какие наброски. В общем, еще все в процессе обдумывания и я приглашаю поучаствовать в разработке!

Основные принципы интерфейса:
– сеть должна работать в 2х вариантах беспроводном (с применением TSOP и IR светодиодов) и однопроводном (потому и назвал так 1W – один провод, IR – инфракрасная передача). Причем они должны работать одновременно и создавать одно «поле» устройств;
– так как TSOP предназначены, в первую очередь, для работы с IR пультами, то эту функцию отнимать я не намерен. А значит, кроме обмена данными между устройствами, сеть должна «видеть» посылки с пультов (причем любых);
– передача сигнала должна потреблять как можно меньше энергии, так как планируются выносные устройства с батарейным питанием;
– сеть не должна иметь управляющего устройства, то есть все должно работать в любой комбинации устройств. Устройства должны «вписываться» в сеть без каких либо настроек/перемычек/конфигурирования;
– но самое главное, интерфейс должен ПРОСТО реализовываться в любом микроконтроллере, на любом языке программирования (простой и доступный алгоритм), даже в ущерб некоторому функционалу.

Я понимаю, что изобретаю велосипед и подобных интерфейсов в сети валом, но хочется иметь простой интерфейс который легко мог использовать каждый в своих проектах.

Скидывайте свои идеи или предложения по реализации, функциям. Если знаете где описаны подобные интерфейсы – скидывайте ссылки – может не стоит заморачиваться и есть уже готовое решение.

Устройства собранные с TSOPом и IR-светодиодом будут управляться с бытовых пультов (устройство будет уметь изучать нажатые клавиши и ассоциировать с ними действия).
Кроме того это устройство, попадая в окружение 1W-IR сети, автоматически становиться ее участником, выдавая команды в сеть и выполняя принятые по сети команды (при этом не теряя возможности управления от пульта)

Насчет организации сети:
Самым полезным в плане функционала будет сделать мастер-устройство которое будет опрашивать поочередно все адреса в сети и решать какую информацию куда передавать. Для этого оно должно поддерживать некие "скрипты", которые пользователь может создавать или изменять по ходу работы. Такая система уже больше похожа на компьютер, но и результат получаем тот же - гибкость и универсальность. Минус но одновременно и плюс - отсутствие глухо-слепых устройств.

Другой путь это то о чем вы говорили - каждое устройство передает в сеть широковещательный пакет где указывает НЕ адрес получателя а СВОЙ адрес. Без указания своего типа. К примеру термометр передает в сеть "я - номер 3, вот температура". Эту посылку слушают все. Дисплей тоже слышит, смотрит свою внутреннюю функциональную таблицу и видит что данные из этого адреса нужно выводить на вторую строку с таким-то префиксом и постфиксом.
В этом случае все устройства изначально создаются "чистыми", но каждое должно иметь свои "скрипты", как и в случае с мастер-устройством.
Пример: поставили дисплей, поставили два термометра. Берем специальное устройство - "настройщик" и передаем дисплею набор команд что от кого получать и что с этим делать. При этом формат этих управляющих скриптов может быть каким-то совсем упрощенным. Типа байт команды программирования, байт адреса устройства от которого нужно получать данные+байт команды+два байта данных.
Говорим дисплею такое - "это настройка+адрес первого термометра+выводи на дисплей+позиция куда выводить (в двух байтах данных)".
Дисплей запоминает это дело и после получения соответствующего пакета делает соответствующее действие. Так же выводим второй термометр на вторую строку.
В любом случае что-то подобное придется делать, потому что без настройки каждого девайса получится непонятно что, как в случае когда на один дисплей нужно вывести время + 1 температуру а на второй - 2 и 3 температуру. То есть самоорганизация тут, увы, не прокатит.

Если добавить чуточку фантазии и достаточно развить скриптовый язык то можно делать более сложную автоматизацию. К примеру есть часы, есть дисплей, есть диммер.
Часы программировать не нужно.
Программируем диммер говоря ему - "это настройка+адрес дисплея+управляй освещением".
Программируем дисплей говоря ему - "это настройка+адрес часов+выводи на дисплей+позиция куда выводить (в двух байтах данных)".
"это настройка+адрес диммера+передай при совпадении переменной 1+два байта кода времени+два байта данных".

Происходит следующее - часы передают инфу дисплею. Он его выводит, храня значение во внутренней переменной 1. Потом смотрит что у него еще в скриптах есть команда "передай при совпадении переменной 1". Оценивает равно ли значение переменной (текущее время) и значение в скрипте. Если стукнуло 10 часов вечера то дисплей исполняет скрипт и передает на адрес диммера значение яркости освещения которую нужно установить.

Тут следует заметить что кажущаяся сложность и громоздкость скриптового языка компенсируется его абсолютной гибкостью в зависимости от устройства. Грубо говоря общими будут только форматы посылок и некоторые коды типа "программирование". Все остальное можно добавлять-убирать в зависимости от устройства. То есть у дисплея может быть команда "передай при совпадении" а у термометра может ее попросту не быть для экономии ресурсов контроллера. Так же общим будет само ядро обработки скриптов. На языке высокого уровня эта задача решается достаточно просто и элегантно.

Еще что в голову пришло - нужно будет подумать насчет устройства-транслятора кодов пультов в формат сети. Иначе получится кака.

Не судите строго если чушь написал. Просто системное проектирование - мое хобби...

Очень много интересной информации!
Это действительно проблема, решать которую сложно, но в то-же время интересно.
Однозначно, сеть будет без управляющего устройства и, как Вы говорите, посылка будет содержать идентификатор передающего устройства, а принимать посылку будут все устройства (даже само передающее устройство) и самостоятельно решать, что с этой посылкой делать. И вот это самое - "самостоятельно решать что с этой посылкой делать" меня и мучит. Не хотелось бы городить что-то громоздкое - для этих целей есть огромное количество готовых интерфейсов и пытаться сделать что-то подобное просто глупо, нужна простота (согласен даже с уклоном к примитивному) работы и реализации. Идея со скриптами довольно интересна, как-то до этого мне в голову не приходила - нужно подумать в этом направлении...

По поводу кодов пульта, наверное каждое устройство (которому это нужно) будет "обучаться" своим клавишам и работать по командам этих клавиш. Кстати можно сделать и устройство-интерпретатор кодов пультов в команды сети.

Просто вы говорите о протоколах, изучаете импульсы в посылке, шум, и много прочего. Это все естественно нужно. Но как ни крути - все это меркнет если нету концепции организации сети на высоком уровне. И наоборот - если есть высокоуровневая модель (концепция) то физические нюансы передачи данных отходят на второй план и выбираются из критериев достаточности и удобности. Иначе зачем иметь идеальную систему передачи данных но не иметь смысла их куда-либо передавать?
На данном этапе мне все же кажется что моя идея со скриптами наиболее оптимальна именно для такого применения как вы задумали. Одно ядро интерпретатора скриптового языка пишется на языке высокого уровня один раз. После этого тупо вставляется в любой проект, удаляются все ненужные функции, болванки - заголовки нужных функций заполняются конкретными командами (типа для термометра - код считывания значений, для дисплея - код отображения), компилируется под конкретный контроллер и все. Эдакая мини-операционная система в некотором роде. Будучи хорошо продуманной в деталях она несомненно найдет свою нишу в бытовой или даже промышленной автоматике. Потому что все что есть теперь ограничивается только красивыми протоколами (тот же САN, ModBus), но не идет дальше...

Не мне соваться в беседу крутых специалистов, я просто сделаю свой "писк из под стола"
Нельзя давать slave-устройствам возможность самим решать, когда передавать данные. Иначе может получиться банальная интерферренция в какой-то момент времени.
Лучше назначить каждому slave-девайсу (термометр, исполнительное устройство, сервер часов и т.д.) свой адрес, 6-7 бит. 1 бит сделать определяющим, отправляем ли мы команду на устройство или наоборот - ждем от него байта данных состояния. Т.е. система будет напоминать приснопамятный I2C
И не забыть сделать прием от исполнителя байта подтверждения принятой команды.
Мастер-девайс уже будет определять порядок опроса "подозреваемых" и решать что делать с полученной информацией.
Вот здесь я согласен насчет применения скрипт-языка. На начальном этапе можно обойтись и без него, просто тупо опрашивая по кругу подчиненные устройства, а с клавиатуры давая команды исполнителям.

Мастер-устройство конечно многое решает, но все же хочется без него. Опрос по адресам естественно самый простой и надежный способ, но не самый элегантный. Насчет определяющего бита в байтовом адресе я согласен. 128 устройств в одной комнате сложно себе представить, а уж 256 - и подавно...
Насчет же интерференций - в комментариях к статьям люди предлагали довольно-таки интересные методы самоорганизации передачи данных, мне кажется что они вполне и вполне заслуживают внимания с некоторыми поправками на реальное использование.

Идея хороша и много интересных мыслей. Готов присоедениться к проэкту и оказать посильную помощь, если таковая потребуется. Вот только хотел спросить: а почему такая сильная привязка именно к ИК? Дешевизна конечно решает, я понимаю. И радимодули достаточно дорогие, но не все. Есть к примеру такая штучка, как TR-24a. При стоимости в 2-2,5 бакинских рублей получаем вполне сносный модуль приёмопередатчика, да к тому же с печатной антенкой, 80 рабочими каналами, аппаратным CRC и многими другими вкусняшками. Как по мне, то стоимость приемлемая, при том, что функциональность сети с применением такого решения намного выше, будет возможность организовать очень надёжную систему и реализовать много-много всяких фич (например не составит проблем разрешение коллизий и т.д.). К тому же при этом такая преграда, как, к примеру, стена, уже не будет непреодолимой. И при всём этом потребление будет соизмеримо с током того же ИК-светодидика, а при использовании экономичных режимов суммарный расход энергии возможно будет даже ниже, благодаря значительно меньшему времени передачи.
Вобщем вот такие аргументы по этому поводу, но решать конечно вам.

Предложение о формате посылки.

1 байт: адрес (старший бит - указатель обычной или программируемой посылки. остальные - адрес)
2 байт: команда (в зависимости от синтаксиса скриптового языка. при этом старший бит указывает длину данных. если он = 0 то сразу после этого идут два байта данных. если он = 1 то после этого идет байт означающий кол-во байтов данных).
3 байт: кол-во байтов данных, если нужно.
n байт: данные
n+1 байт: контроль.

Мне кажется что так будет достаточно компактно и функционально. Адресов хватит с головой. Команд тоже хватит для любого мыслимого применения. Расширяемость объема данных сделана для того чтобы можно было передавать сложные программируемые команды длинной больше 2 байт. Ну и таким образом получается большая универсальность - термометр может передавать дисплею сразу необходимую для вывода строку. Как-то так...