Arduino.ru

не знаю, вот 20 версия. Изменил массив девайсов, присутствующих на узле (ранее весь массив девайсов присутствовал в виде оверхеда , даже если на узле не укомплектовано) Теперь в массиве содержаться только те девайсы которые есть на узле. 

С долгими командами пока до конца не доделано. С короткими командами всё без проблем работает. 

ver 20 

еще правлю скетч,уже 22 версия)) самое сложное сделать полное описание всей этой городьбы. (для себя в т.ч.) Скоро переезжаю в новую квартиру. Может что-нибудь там придётся автоматизировать. Хотелось бы, что бы протокол был уже готов к тому времени. Riv, а у тебя как движуха?

PS. В доме я так и не применил этот наш протокол. До сих пор всё продолжает работать на 11битных ID и компактной передачей булевых данных. (в одном байте 8 переменных, а во фрейме 64).

Начал делать подробное описание протокола.

Версия 22.

Описание протокола SmartHomeCAN. 

Покритикуйте кто-нибудь. 

Предлагаю в описании протокола не привязываться пока с конкретными файлами конфигов и пр.

Нужно расписать , согласовать, подробно структуру заголовка и перечень команд. Чтобы как минимум сохранить совместимость твоего кода и моей библиотеки. Чтобы навстречу работали.

эмм , мне бы быстрее всё на бумагу положить, пока я через два года опять всё вспомнил, а то это "вспомнил" будет не долго продолжаться.

Потом переделать легче, когда инфа будет в электронном виде , а не в голове. 

Набросай тогда, потом дополним. См. ещё на гитхаб у меня там тоже какое что есть.

У меня Emergency-сообщения типа аварий с большим приоритетом идут, нежели данные по метрикам.

Насколько я помню в can нет приоритезации. Скорости большие. Обработку нужно вводить на 3 или 4 уровне в шлюзе. Кстати я сейчас занимаюсь интеграцией с majordomo на базе https://github.com/foxvlad/OkBitUDP и https://github.com/foxvlad/ESP8266WiFiOkBit и can to udp.

И ещё предложение. Давай на гитхаб уже проект вытаскивай, для совместной работы.

Хочется вам помочь, только не знаю чем :) Критиковать не буду чтоб не сбить с мысли.

Просто оставлю это тут. Ссылка.

У меня нет текстового описания своего протокола (мне как-то проще ориентироваться именно по таблицам), и он заточен именно под автоматизацию дачи, то есть не является универсальным. Из того что я тут прочел очень многое пересекается. Может кто-то найдет для себя что-то полезное или вообще пересмотрит всю концепцию как это в свое время произошло со мной.

Может тогда и код сюда или на гитхаб есть смысл выложить. Так сказать для заимствования идей. Платформы разные конечно. Базовые принципы те же.

Вот не хочется никого учить. По-этому и не хочу никого сбивать с мысли. В основном я использую pic18f46k80 с прерыванием по приему can. В прерывании идет чтение пакета в экземпляр структуры, описанной в протоколе

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

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

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

Упустил это твое сообщение.

1.  Библиотеку отлаживаю, но пока до команд не дошел. Пока 3 уровень. Потом твои наработки просто интегрирую в ahb_node.cpp () (В ahb_master.cpp и ahb_slave.cpp будет код шлюзов и общего контроля сети)

2. Занялся интеграцией с majordomo, используя https://github.com/foxvlad/ESP8266WiFiOkBit , https://github.com/foxvlad/OkBitUDP, 

https://github.com/coryjfowler/MCP_CAN_lib/tree/master/examples/CAN_to_Ethernet. Пытался связаться с автором на тему интеграции. Он те ответил. Буду делать форк. 

3. Занялся интерфейсом. Нарыл тут симпатичный проект https://github.com/kirush0280/scenes_okbit , немного платный 2200, но это того стоит. Это мой УД так выглядит.

4. Собрал мультирум. (Ранее схему накидывал) Пока управление не интегрировал но иду к этому.

P.S.

Умышлено не лезу пока в 4 уровень. Посмотрю как MD реализовано, чтобы проще и понятнее к нему привязаться.

И кстати, закладывай больше проводов в новой квартире. Начал подключаться и то тут то там лезут забытые силовые и слаботочные цепи. А стены уже крушить жалко. Так что радио и АКБ для питания.

да с нехваткой проводов сам сталкивался уже. Хата новая. Будет шанс разгуляться в плане проводки. Как минимум везде напихаю витухи и лапши. 

Лапшу-то зачем пихать, или тебе дядя прислал бобину кабеля ТРП?

ну на всякий случай заложил этот бит. Болтался этот 29-й бит, не знал куда его девать. Вот и нашлось применение. Конечно, основную приоритизацию можно сделать,  поправив список типов сообщений - поставить самые важные типы сообщений первыми (что и сделаю в следующей итерации скетча). А этот бит пусть задаёт т.н. сверхважные сообщения. В алгоритм уже всё равно это добавлено, сильно уж не усложнило код (в отличие от некоторых других вещей). 

PS. и да, мне каж правильнее говорить heartbeat , а не heartbreath

лапша - питание причём 220В. Просто много читал, что типа многим не хватает через жилы витухи . Фиг его знает на чё меня растащит, делая тот или иной узел. 

Да неплохая тема, но, блин, знаний и скилла не хватает катастрофически, чтобы всё понять как работает. Заумно там всё как то. Времени бы купить где-нибуть. 

PS. MQTT хоть я освоил, и то ладно))

Дак это не лапша. Лапша - это совершенно определённый вид кабеля.

Учти, что стандарты СКС не приветствуют сбор в пучок силовых и сигнальных кабелей. Правильная проводка подразумевает определённый гап между ними. При прокладке чистой витухи с POE можно просто увеличить  напряжение, чтобы получить больше тока на удалённом конце. Кипятильник же ты не будешь подключать? Тогда 51W тебе должно хватить: https://www.a1securitycameras.com/technical-support/pover-over-ethernet-classes-comparison-chart/

Насчёт heartbeat ты прав, наверное. Я изучал дойч, поэтому не всегда правильно воспринимаю инглиш на слух. Впрочем, МК акцент безразличен, к моему счастью.

про кабели понятно, что лучше силу от сигнальных подальше разводить, по возможности буду так и делать. Хотя в доме сейчас в одном здоровенном кабель-канале стопицот силовых и CAN лежит, всё работает без сучка. Причем одна из силы это толстенный кабель - завод питания в дом от столба. 

про лапшу я имел ввиду такой, видимо, да, неправильно его обозвал. думаю взять 2*0,75

ШВВП, как мне помнится, кабель присоединительный - т.е. для использования в поле зрения. Не то, что он прям совсем плохой, но стандарты не рекомендуют закладывать его в короба. Для скрытой проводки - NYM, ВВГ(НГ). 

Кабель-канал тебе нужен двухсекционный (если хочешь красиво) - в одну секцию силу кладёшь, в другую - низвковольтные. Заполняемость - 35%, вроде бы.

Я тут вспомнил, что у меня подключена UniFi-тарелка по POE: 50 или 60 метров по витухе - работает не падая.

я хотел ups компьютерный поставить, тем самым раздавая узлам непадающие 220В,  а на узлах уже АС-DC. Плюс можно какую-то более менее силу запитать на месте, если нужно. Подход так себе?

С POE ведь надо какие трансформаторы мутить, напругу хотя бы 24В я так понимаю. 

Я считаю, что лучше дырку в стене перфорировать под один кабель, а не под два. И, если где-то что-то передавит, то лучше бы не получать по рукам 220V из Ethernet-джека. 

Узлы у тебя не на расстоянии 100 метров от UPS и по киловатту не жрут? Тогда берёшь, к примеру, модуль на XL6009 с расчётом установки на стороне узла, смотришь у него максимальное напряжение и запускаешь его в витуху около гейтвея по схеме Passive POE через инжектор (или любую другую понижающую схему - хоть БП от роутера).  На удалённой стороне две пары жил кидаешь на DC-DC, а две - по назначению используешь. До 100Mbit такая схема работать будет. С гигабитом сложнее, но он наврядли тебе нужен.

посмотрел, действительно есть очень похожие решения. Но всё же прихожу к мнению, что чужой труд, прям очень сложен к пониманию. Пытаюсь протокол сделать простым и понятным в настройке. Пока плохо получается. Поэтому решил сделать описание, для себя в т.ч., чтобы не забывать как всё устроено. 

На счёт адресации фреймов от кого и кому, от части согласен.  Ну пусть будет, раз коллега по цеху настоял. Возможно это предостережёт от некоторых проблем в будущем при усложнении системы. 

PS. и ID у вас.... это жесть конечно, не кратные нибблам данные, жонглировать ими то ещё удовольствие. 

конечно нет, в основном это будет запитка самой электроники. Но где то возможно питание на свет или подсветка какая, в любом случае это будут экономичные LED лампы. Так что, буду комбинировать. Где не хватит отдельного кабеля питания, придётся через PoE. Ethernet-а в моей системе наверное не будет, разве только для обеспечения интернета компа.  В крайнем случае шлюз езернет-кан.  вся остальная витуха - CAN.  поэтому какие там мегабиты и гигабиты))   125кбит/с наше всё.  

Ай, не знаю. У меня единственная сеть - это до медиаплеера. Городить умный дом ради 10 выключателей в квартире и потом его сопровождать? Мне этого гемора и на работе хватает. Не так уж сложно жопу поднять и свет выключить.

в квартире согласен, так баловство.  В доме нужная штука, удаленный контроль и т.п. Хотя чем комплектовать УД, свет то понятно, а вот если приколхозить пожарную сигнализацию, и в квартире полезно. Я негатив с пожаром почти испытал на себе даже (дважды причём).

Поофтоплю. Один раз под нами квартира горела. ночью. Соседи те уехали и видать чето не выключили. Я как обычно до ночи за компом сижу,  паяю чё то. Дым от паяльника и обоняние к тому же не черту, не учуял дым костра так сказать. Жена сонная забегает ко мне в комнату с предъявой  - чё ты тут жгешь_паяешь?!  Потом поняли, не в этом дело - вся кухня в дыму нах. Дымит с плинтусов, я думал проводка завоняла, которую я до холодильника в плинтусе прокинул. Потом чую пол как с подогревом. Короче быстро понял, что квартира под нами горит. Задохнуться ночью при этом даже в квартире сверху - легко. Дыма просто ппц. вызвал пожарных. Потушили, часа два на улице ночью с детьми протусили. Но тут ладно жена проснулась и я не спал, а если бы все крепко спали - то хз. Это я к тому, что пожарные датчики и оповещение крайне желательно иметь. 

На работе весь цех сгорел однажды, тоже ночью. Ох как неприкольно было на след день на работе. Черный день в моей жизни. тоже давно не работала противопожарка. 

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

Вспомнил, ещё у отца дом обнесли тыщ на 300. Моя городьба там уже была причём , но ещё в начальном варианте на соплях, и батя в ту ночь как раз из розетки всё вырубил зачем-то. Так бы PIRы сработали и смс хоть пришло. 

Макс, ты не поверишь, но есть люди, у которых всего этого никогда не происходит ))

Посмотри на Vutlan.

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

Готовые решения лично для меня дороги и, учитывая мой интерес к самостоятельной разработке и кое какой, но все же опыт, выбираю "сделай сам". 

Я знаю, что есть устоявшееся мнение что УД это баловство, чисто поиграться неделю и просто потом пользоваться как обычным домом.

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

Потомушто ты не вор. Экспрессивные кражи - это участь гастролёров. Местные работают по наводке. От соседей там или ещё от кого, кто видит, что все из дома свалили на машине с чемоданами. А то, что свет бессмысленно мигает... да и пофиг. 

Одного моего коллегу обнесли за час. Пока у него родные вышли на ежедневный променад, а он сам был на работе.

Именно... Казалось бы, ну возьми CANOpen и не надо морщить мозг, но нет, не понимаю я его. В хорошем смысле не понимаю. Не вижу смысла делать очередной псевдо-промышленный ПЛК. По-этому из-за разной концепции в ваш код даже не лезу. Ну разве что одним глазком. Буду придерживаться своего концепта. Да, там в какой-то степени колхоз и уровни OSI друг на друга заползают, но я художник, я так вижу :)  По крайней мере для дома.

Просто сие деяние уводит мысли от непосредственно CAN-шины в сторону Ethernet-а. При усложнении системы CAN-шину нужно или сегментировать или структурировать. Если с первым все понятно, то для второго лучше tcp/ip. Я скорее всего сделаю и то и другое. То есть, например, отдельная can-шина "сауна", состоит из 3 блоков разного назначения. И этому сегменту в общем все равно на то, что происходит в сегменте "теплица". По-этому на концах будут wi-fi шлюзы (он на stm32 вот такой трехэтажный с питанием до 30в)

для объединения шин, но каждая шина автономна и самодостаточна. Примерно так.

Да не, битовые поля это не так сложно как кажется. Особенно если использовать union.

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

Мда, действительно, главное не доводить до того , чтоб дом был умнее тебя))

круто, а схемку его можно увидеть? Код для СТМ32 в чем написан?

MaxVV, выложил твой код https://github.com/graynet-dev/SmartHomeCAN

Ставь https://desktop.github.com/ и выкладывай сразу сюда.

Я схем не рисую. Сразу плату. Штук 300 нарисовал - мне так удобнее.

Нижняя соответственно ВОТ

Средняя это питальник на MP1584, крутилку убрал, резистор 0604 подобрал чтоб 3.3в было.

Верхняя соответственно модуль ESP-01

Камень STM32F103C8, CAN-передатчик SN65HVD230, клеммник DG340-3.81-02P-12-00AH, электролит оказался ни к чему с таким питанием.

Софт я весь пишу в MikroC (PIC, PIC32, ARM, AVR, STM - для каждой своя среда), но с STM32 потихоньку перебираюсь на STM32CubeIDE. А для ESP пишу, простихоспади, в ArduinoIDE.

а зачем тут STM? Почему сразу всё в ESP не впихнуть? 

1) Я люблю когда каждый МК занимается своей конкретной задачей. У ESP и так дофига фоновых задач и реального времени на ней не получить. Если "все в одном" - это получится очередной универсальный ПЛК, на базе которого "вы можете сделать всё что угодно". Если быть точным, то ничего :)

2) Вместо STM32+ESP поставить ESP+MCP2515 ? А смысл ? Разделить внешний eeprom c контроллером CAN по SPI и поиметь с этой связи офигительный геморрой с прерываниями ?

3) ESP я везде использую исключительно в виде веб-интерфейса с ajax. Ну и просто запросами что-то поменять. Никаких фреймворков, микропитонов и прочей ереси. Именно по-этому у него божественное быстродействие в том числе и в многопользовательском режиме.

Тут много STM32 :)

demid.net - поддерживаю, связка СТМ32 + самый дешевый ЕСП-01 - и у меня показала себя как очень удобный вариант. На ЕСП только веб интерфейс и протокол обмена, на СТМ - собственно вся работа.

ок, вам можно верить с вашим опытом. И да, у вас с стм платами действительно дефицит отсутствует )) 

ЗЫ. а есп 32 не пробовали? Он кажись помощнее и там вроде CAN встроенный. н

ЗЫЫ. потихоньку дополняю описание протокола, кому интересно заглядывайте иногда (по той же ссылке)

Скетч версия 23. Описание дополнил. Файл описания лучше скачивать, а то онлайн коряво - там всё съезжает. 

Макс, не хочешь мануальное конфигурирование нод заменить на автоматическое? С гейта кинул реквест "кто здесь", а в ответ устройства прислали свои id и типы.

да точно, сделаю, только не заменю, а добавлю. Можно будет и  так, и так. 

Собираешься менять только тип узла или множество параметров настройки?

И будешь ли делать сохранение, чтение параметров в/из EEPROM?

не, я так понял Sadman говорил только про формирование таблицы комплектации CAN сети для мастера. Т.е. чтобы в ручную не забивать. Дали команду мастеру, он сохранил в таблице тех кто сейчас присутствует на шине. И эту таблицу далее и будет использовать для контроля онлайности узлов. 

А на счёт конфигурации через еепром я вообще смысла не вижу. Какая разница как конфигурировать узлы -  меняя еепром или саму прошивку (флеш). Все равно к узлу как то надо обращаться при этом. Если конфигурировать через еепром, то с этим еепромом прошивка ещё больше вырастет. И получится, что CAN протокол более половины флеша будет занимать, нафиг он такой нужен. 

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

это в общем то и так в рабочем режиме происходит. Мастер каждую секунду рассылает всем время, можно назвать это, как ты говоришь, heartbeat. А узлы отвечают, в заголовке ответа адрес узла и так уже есть. А вот что включить в  payload этих ответов STATUS ?   Хочу один байт отвести на количество ошибок на узле. Ну тип узла тоже можно . 

Предлагайте что в  STATUS ещё можно включить? 

Лучше не делать пин-понг цикличным совсем. (Оставить, только для инициативных запросов). 

 heartbeat (сердцебиение) лучше сделать с каждого узла в асинхронном режиме по таймеру. Только мастер рассылает время а ноды свой аптайм, и количество ребутов. См. https://github.com/graynet-dev/aHomeBus/blob/master/ahb.cpp void AHB::ahbHeartbeat(uint8_t bus_Type){...

Так сделан асинхрон intervalHeartbeat*1000+_nodeId*100

В итоге вся сеть видит состояния всех нодов. На этом принципе сделан и саморебут, если в течении минуты

узел не принимает ни чьих heartbeat то ребут.

Так реализовано в CANOPEN. (В нем есть  heartbeat и nodeguard). У меня реализовано оба алгоритма, но все рекомендуют именно heartbeat, практика показала то же(уже с месяц сеть гоняю) . У Макса nodeguard.

Да и еще количество ошибок RX TX тоже нужный параметр.

Все что в таблице приходит по heartbeat, ребуты тупо считаю на мастере и слейве, но потом сделаю запись в епром перед ребутом на ноде и передачу на мастер.

А зачем ребут-то сразу? Это не поможет, если провод порвали.

сердцебиение лучше синхронизировать от мастера . Так гарантированно по времени разнесутся heartbeat-ы узлов. Просто сделать эти heatbeats широковещательными тогда. и будут все видеть, только не пойму, честно, нафига всем это видеть.

А если уж мастер перестал свой heartbeat с временем слать, тогда уж в аварийном режиме начинают ноды  сами пульс гнать в шину.