У меня сделано 3 класса которые различаются для мастера, слейва, узла. В них должны храниться базовые функции 4 уровня. З уровень с маршрутизацией я буду добивать. А в 4 уровне ты традиционно силен. Я про твою логику по установке пинов, контролю исполнения команд и пр.
не знаю, вот 20 версия. Изменил массив девайсов, присутствующих на узле (ранее весь массив девайсов присутствовал в виде оверхеда , даже если на узле не укомплектовано) Теперь в массиве содержаться только те девайсы которые есть на узле.
С долгими командами пока до конца не доделано. С короткими командами всё без проблем работает.
еще правлю скетч,уже 22 версия)) самое сложное сделать полное описание всей этой городьбы. (для себя в т.ч.) Скоро переезжаю в новую квартиру. Может что-нибудь там придётся автоматизировать. Хотелось бы, что бы протокол был уже готов к тому времени. Riv, а у тебя как движуха?
PS. В доме я так и не применил этот наш протокол. До сих пор всё продолжает работать на 11битных ID и компактной передачей булевых данных. (в одном байте 8 переменных, а во фрейме 64).
Предлагаю в описании протокола не привязываться пока с конкретными файлами конфигов и пр.
Нужно расписать , согласовать, подробно структуру заголовка и перечень команд. Чтобы как минимум сохранить совместимость твоего кода и моей библиотеки. Чтобы навстречу работали.
У меня нет текстового описания своего протокола (мне как-то проще ориентироваться именно по таблицам), и он заточен именно под автоматизацию дачи, то есть не является универсальным. Из того что я тут прочел очень многое пересекается. Может кто-то найдет для себя что-то полезное или вообще пересмотрит всю концепцию как это в свое время произошло со мной.
У меня нет текстового описания своего протокола (мне как-то проще ориентироваться именно по таблицам), и он заточен именно под автоматизацию дачи, то есть не является универсальным. Из того что я тут прочел очень многое пересекается. Может кто-то найдет для себя что-то полезное или вообще пересмотрит всю концепцию как это в свое время произошло со мной.
Может тогда и код сюда или на гитхаб есть смысл выложить. Так сказать для заимствования идей. Платформы разные конечно. Базовые принципы те же.
почему? Это ведь арбитраж на шине. Если шина загружена по самое не хочу, и создается ситуация, что сообщения накладываются друг на друга, то арбитраж выигрывает сообщение с меньшим ID.
sadman41 пишет:
У меня Emergency-сообщения типа аварий с большим приоритетом идут, нежели данные по метрикам.
я сделал подготовку под такой же алгоритм. Один бит в ID отдан на важность сообщения. В обычном обмене все фреймы с низким приоритетом. Если нужно послать что то очень важное - выставляем этот бит в 0 - приоритет станет высокий.
К тому же, даже при обычном обмене с низким приоритетом, в списке адресов узлов можно наиболее важные узлы писать первыми, тогда у них будет более высокий приоритет при прочих равных.
Нужно только расположение в ID адреса отправителя , наверное, местами поменять с типом сообщения, чтобы приоритет адресов МК работал.
К тому же, даже при обычном обмене с низким приоритетом, в списке адресов узлов можно наиболее важные узлы писать первыми, тогда у них будет более высокий приоритет при прочих равных.
А, вижу... очень серый бит приоритета.
Я с битами не заморачивался. Просто расставил типы сообщений "сверху вниз" так, чтобы типы пакетов heartbreath, alarm были с наименьшим ID. Тогда оно само рассосётся и нет нужды манипулировать битом важности, усложняя алгоритм.
Может тогда и код сюда или на гитхаб есть смысл выложить. Так сказать для заимствования идей. Платформы разные конечно. Базовые принципы те же.
Вот не хочется никого учить. По-этому и не хочу никого сбивать с мысли. В основном я использую pic18f46k80 с прерыванием по приему can. В прерывании идет чтение пакета в экземпляр структуры, описанной в протоколе
, после чего он перекладывается в кольцевой буффер структур для дальнейшей обработки другим потоком ОСРВ.
Да всё то же самое что и у вас, те же дефайны "тип блока", по которому переподключаются разные заголовочные файлы и один и тот же проект компилируется под разные блоки с разными задачами. Есть задачи глобальные, есть применимые только к конкретному блоку. Даже их количество разное для каждого блока. С инициализацией камней то же самое.
Я не сторонник использования can-шины как эзернета, с адресом отправителя, адресом получателя и.т.п вещами. Есть идентификатор пакета и по этом идентификатору каждый блок и так знает нужен он ему или нет внезависимости от кого он поступил. По-этому в концепцию даже не вмешиваюсь.
еще правлю скетч,уже 22 версия)) самое сложное сделать полное описание всей этой городьбы. (для себя в т.ч.) Скоро переезжаю в новую квартиру. Может что-нибудь там придётся автоматизировать. Хотелось бы, что бы протокол был уже готов к тому времени. Riv, а у тебя как движуха?
PS. В доме я так и не применил этот наш протокол. До сих пор всё продолжает работать на 11битных ID и компактной передачей булевых данных. (в одном байте 8 переменных, а во фрейме 64).
Упустил это твое сообщение.
1. Библиотеку отлаживаю, но пока до команд не дошел. Пока 3 уровень. Потом твои наработки просто интегрирую в ahb_node.cpp () (В ahb_master.cpp и ahb_slave.cpp будет код шлюзов и общего контроля сети)
4. Собрал мультирум. (Ранее схему накидывал) Пока управление не интегрировал но иду к этому.
P.S.
Умышлено не лезу пока в 4 уровень. Посмотрю как MD реализовано, чтобы проще и понятнее к нему привязаться.
И кстати, закладывай больше проводов в новой квартире. Начал подключаться и то тут то там лезут забытые силовые и слаботочные цепи. А стены уже крушить жалко. Так что радио и АКБ для питания.
Я с битами не заморачивался. Просто расставил типы сообщений "сверху вниз" так, чтобы типы пакетов heartbreath, alarm были с наименьшим ID. Тогда оно само рассосётся и нет нужды манипулировать битом важности, усложняя алгоритм.
ну на всякий случай заложил этот бит. Болтался этот 29-й бит, не знал куда его девать. Вот и нашлось применение. Конечно, основную приоритизацию можно сделать, поправив список типов сообщений - поставить самые важные типы сообщений первыми (что и сделаю в следующей итерации скетча). А этот бит пусть задаёт т.н. сверхважные сообщения. В алгоритм уже всё равно это добавлено, сильно уж не усложнило код (в отличие от некоторых других вещей).
PS. и да, мне каж правильнее говорить heartbeat , а не heartbreath
лапша - питание причём 220В. Просто много читал, что типа многим не хватает через жилы витухи . Фиг его знает на чё меня растащит, делая тот или иной узел.
Да неплохая тема, но, блин, знаний и скилла не хватает катастрофически, чтобы всё понять как работает. Заумно там всё как то. Времени бы купить где-нибуть.
лапша - питание причём 220В. Просто много читал, что типа многим не хватает через жилы витухи . Фиг его знает на чё меня растащит, делая тот или иной узел.
Дак это не лапша. Лапша - это совершенно определённый вид кабеля.
Учти, что стандарты СКС не приветствуют сбор в пучок силовых и сигнальных кабелей. Правильная проводка подразумевает определённый гап между ними. При прокладке чистой витухи с 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В я так понимаю.
я хотел ups компьютерный поставить, тем самым раздавая узлам непадающие 220В, а на узлах уже АС-DC. Плюс можно какую-то более менее силу запитать на месте, если нужно. Подход так себе?
С POE ведь надо какие трансформаторы мутить, напругу хотя бы 24В я так понимаю.
Я считаю, что лучше дырку в стене перфорировать под один кабель, а не под два. И, если где-то что-то передавит, то лучше бы не получать по рукам 220V из Ethernet-джека.
Узлы у тебя не на расстоянии 100 метров от UPS и по киловатту не жрут? Тогда берёшь, к примеру, модуль на XL6009 с расчётом установки на стороне узла, смотришь у него максимальное напряжение и запускаешь его в витуху около гейтвея по схеме Passive POE через инжектор (или любую другую понижающую схему - хоть БП от роутера). На удалённой стороне две пары жил кидаешь на DC-DC, а две - по назначению используешь. До 100Mbit такая схема работать будет. С гигабитом сложнее, но он наврядли тебе нужен.
Из того что я тут прочел очень многое пересекается.
посмотрел, действительно есть очень похожие решения. Но всё же прихожу к мнению, что чужой труд, прям очень сложен к пониманию. Пытаюсь протокол сделать простым и понятным в настройке. Пока плохо получается. Поэтому решил сделать описание, для себя в т.ч., чтобы не забывать как всё устроено.
На счёт адресации фреймов от кого и кому, от части согласен. Ну пусть будет, раз коллега по цеху настоял. Возможно это предостережёт от некоторых проблем в будущем при усложнении системы.
PS. и ID у вас.... это жесть конечно, не кратные нибблам данные, жонглировать ими то ещё удовольствие.
Узлы у тебя не на расстоянии 100 метров от UPS и по киловатту не жрут? ... До 100Mbit такая схема работать будет. С гигабитом сложнее, но он наврядли тебе нужен.
конечно нет, в основном это будет запитка самой электроники. Но где то возможно питание на свет или подсветка какая, в любом случае это будут экономичные LED лампы. Так что, буду комбинировать. Где не хватит отдельного кабеля питания, придётся через PoE. Ethernet-а в моей системе наверное не будет, разве только для обеспечения интернета компа. В крайнем случае шлюз езернет-кан. вся остальная витуха - CAN. поэтому какие там мегабиты и гигабиты)) 125кбит/с наше всё.
Ай, не знаю. У меня единственная сеть - это до медиаплеера. Городить умный дом ради 10 выключателей в квартире и потом его сопровождать? Мне этого гемора и на работе хватает. Не так уж сложно жопу поднять и свет выключить.
в квартире согласен, так баловство. В доме нужная штука, удаленный контроль и т.п. Хотя чем комплектовать УД, свет то понятно, а вот если приколхозить пожарную сигнализацию, и в квартире полезно. Я негатив с пожаром почти испытал на себе даже (дважды причём).
Поофтоплю. Один раз под нами квартира горела. ночью. Соседи те уехали и видать чето не выключили. Я как обычно до ночи за компом сижу, паяю чё то. Дым от паяльника и обоняние к тому же не черту, не учуял дым костра так сказать. Жена сонная забегает ко мне в комнату с предъявой - чё ты тут жгешь_паяешь?! Потом поняли, не в этом дело - вся кухня в дыму нах. Дымит с плинтусов, я думал проводка завоняла, которую я до холодильника в плинтусе прокинул. Потом чую пол как с подогревом. Короче быстро понял, что квартира под нами горит. Задохнуться ночью при этом даже в квартире сверху - легко. Дыма просто ппц. вызвал пожарных. Потушили, часа два на улице ночью с детьми протусили. Но тут ладно жена проснулась и я не спал, а если бы все крепко спали - то хз. Это я к тому, что пожарные датчики и оповещение крайне желательно иметь.
На работе весь цех сгорел однажды, тоже ночью. Ох как неприкольно было на след день на работе. Черный день в моей жизни. тоже давно не работала противопожарка.
Также другая крайность была. потоп был у меня в кварире, соседей затопил нафиг. Поэтому все эти фенички со светом это так себе, конечно, а вот безопасность нужна в первую очередь, а потом удобства.
Вспомнил, ещё у отца дом обнесли тыщ на 300. Моя городьба там уже была причём , но ещё в начальном варианте на соплях, и батя в ту ночь как раз из розетки всё вырубил зачем-то. Так бы PIRы сработали и смс хоть пришло.
тем не менее подушки безопасности сейчас есть в каждом автомобиле. и я ох как хочу чтобы они не пригодились. Так и тут, пусть это у меня будет, но надеюсь не пригодится.
Готовые решения лично для меня дороги и, учитывая мой интерес к самостоятельной разработке и кое какой, но все же опыт, выбираю "сделай сам".
Я знаю, что есть устоявшееся мнение что УД это баловство, чисто поиграться неделю и просто потом пользоваться как обычным домом.
но вот ещё пример. в доме уже было мной сделано включение света от МК через нефиксируемые выключатели. После обкрадывания дома, решил добавить имитацию хозяев (для начала хотя бы играя светом) - дак вот данная задача на базе того, что свет уже рулился МК, дело оказалось одного часа работы - чисто ПОшной. Также т.к. это дом большой комнаты и коридоры тоже не маленькие, и в нескольких помещениях по два (а в одном - вообще три) выключателя света. руля светом через МК тактовыми выключателями решается проблема "проходных" выключателей. Так что в полезности многих автоматизируемых вещей лично я не сомневаюсь.
После обкрадывания дома, решил добавить имитацию хозяев (для начала хотя бы играя светом) - дак вот данная задача на базе того, что свет уже рулился МК, дело оказалось одного часа работы - чисто ПОшной.
Потомушто ты не вор. Экспрессивные кражи - это участь гастролёров. Местные работают по наводке. От соседей там или ещё от кого, кто видит, что все из дома свалили на машине с чемоданами. А то, что свет бессмысленно мигает... да и пофиг.
Одного моего коллегу обнесли за час. Пока у него родные вышли на ежедневный променад, а он сам был на работе.
Но всё же прихожу к мнению, что чужой труд, прям очень сложен к пониманию. Пытаюсь протокол сделать простым и понятным в настройке. Пока плохо получается.
Именно... Казалось бы, ну возьми CANOpen и не надо морщить мозг, но нет, не понимаю я его. В хорошем смысле не понимаю. Не вижу смысла делать очередной псевдо-промышленный ПЛК. По-этому из-за разной концепции в ваш код даже не лезу. Ну разве что одним глазком. Буду придерживаться своего концепта. Да, там в какой-то степени колхоз и уровни OSI друг на друга заползают, но я художник, я так вижу :) По крайней мере для дома.
MaksVV пишет:
На счёт адресации фреймов от кого и кому, от части согласен. Ну пусть будет, раз коллега по цеху настоял. Возможно это предостережёт от некоторых проблем в будущем при усложнении системы.
Просто сие деяние уводит мысли от непосредственно CAN-шины в сторону Ethernet-а. При усложнении системы CAN-шину нужно или сегментировать или структурировать. Если с первым все понятно, то для второго лучше tcp/ip. Я скорее всего сделаю и то и другое. То есть, например, отдельная can-шина "сауна", состоит из 3 блоков разного назначения. И этому сегменту в общем все равно на то, что происходит в сегменте "теплица". По-этому на концах будут wi-fi шлюзы (он на stm32 вот такой трехэтажный с питанием до 30в)
для объединения шин, но каждая шина автономна и самодостаточна. Примерно так.
MaksVV пишет:
PS. и ID у вас.... это жесть конечно, не кратные нибблам данные, жонглировать ими то ещё удовольствие.
Да не, битовые поля это не так сложно как кажется. Особенно если использовать union.
С некратностью связана только одна сложность... Вручную ввести пакет для передачи трудновато :) Хотя был забавный момент, когда я решил подать команду в сеть на включение шифрования приема/передачи пакетов. Кое-как в калькуляторе посчитал ID, команду подал, вижу что пошел откровеннейший "мусор", то есть блоки друг друга понимают, а я сижу как перед экраном Матрицы, разве что только интерфейс не черно-зеленый. Ну, думаю, всё, хорош, верните понятные данные. Даю команду отключить шифрование, она конечно не работает. Ну все, подумал уж восстание машин началось, ан нет. Команду-то тоже надо было подавать в зашифрованном виде :) В общем проще наверное было все блоки перепрошить чем это посчитать, но я справился. Хорошо хоть не догадался ввести команду смены ключа шифрования. Сеть бы себе придумала новый ключ, и было бы еще веселее.
Средняя это питальник на 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. Ну и просто запросами что-то поменять. Никаких фреймворков, микропитонов и прочей ереси. Именно по-этому у него божественное быстродействие в том числе и в многопользовательском режиме.
demid.net - поддерживаю, связка СТМ32 + самый дешевый ЕСП-01 - и у меня показала себя как очень удобный вариант. На ЕСП только веб интерфейс и протокол обмена, на СТМ - собственно вся работа.
Макс, не хочешь мануальное конфигурирование нод заменить на автоматическое? С гейта кинул реквест "кто здесь", а в ответ устройства прислали свои id и типы.
не, я так понял Sadman говорил только про формирование таблицы комплектации CAN сети для мастера. Т.е. чтобы в ручную не забивать. Дали команду мастеру, он сохранил в таблице тех кто сейчас присутствует на шине. И эту таблицу далее и будет использовать для контроля онлайности узлов.
А на счёт конфигурации через еепром я вообще смысла не вижу. Какая разница как конфигурировать узлы - меняя еепром или саму прошивку (флеш). Все равно к узлу как то надо обращаться при этом. Если конфигурировать через еепром, то с этим еепромом прошивка ещё больше вырастет. И получится, что CAN протокол более половины флеша будет занимать, нафиг он такой нужен.
А конфигурируя, заменой прошивки, так гораздо больше возможностей для конфигурации.
.... а в ответ устройства прислали свои id и типы.
это в общем то и так в рабочем режиме происходит. Мастер каждую секунду рассылает всем время, можно назвать это, как ты говоришь, heartbeat. А узлы отвечают, в заголовке ответа адрес узла и так уже есть. А вот что включить в payload этих ответов STATUS ? Хочу один байт отвести на количество ошибок на узле. Ну тип узла тоже можно .
.... а в ответ устройства прислали свои id и типы.
это в общем то и так в рабочем режиме происходит. Мастер каждую секунду рассылает всем время, можно назвать это, как ты говоришь, heartbeat. А узлы отвечают, в заголовке ответа адрес узла и так уже есть. А вот что включить в payload этих ответов STATUS ? Хочу один байт отвести на количество ошибок на узле. Ну тип узла тоже можно .
Предлагайте что в STATUS ещё можно включить?
Лучше не делать пин-понг цикличным совсем. (Оставить, только для инициативных запросов).
heartbeat (сердцебиение) лучше сделать с каждого узла в асинхронном режиме по таймеру. Только мастер рассылает время а ноды свой аптайм, и количество ребутов. См. https://github.com/graynet-dev/aHomeBus/blob/master/ahb.cppvoidAHB::ahbHeartbeat(uint8_t bus_Type){...
Так сделан асинхрон intervalHeartbeat*1000+_nodeId*100
В итоге вся сеть видит состояния всех нодов. На этом принципе сделан и саморебут, если в течении минуты
узел не принимает ни чьих heartbeat то ребут.
Так реализовано в CANOPEN. (В нем есть heartbeat и nodeguard). У меня реализовано оба алгоритма, но все рекомендуют именно heartbeat, практика показала то же(уже с месяц сеть гоняю) . У Макса nodeguard.
Да и еще количество ошибок RX TX тоже нужный параметр.
Все что в таблице приходит по heartbeat, ребуты тупо считаю на мастере и слейве, но потом сделаю запись в епром перед ребутом на ноде и передачу на мастер.
сердцебиение лучше синхронизировать от мастера . Так гарантированно по времени разнесутся heartbeat-ы узлов. Просто сделать эти heatbeats широковещательными тогда. и будут все видеть, только не пойму, честно, нафига всем это видеть.
А если уж мастер перестал свой heartbeat с временем слать, тогда уж в аварийном режиме начинают ноды сами пульс гнать в шину.
не знаю, вот 20 версия. Изменил массив девайсов, присутствующих на узле (ранее весь массив девайсов присутствовал в виде оверхеда , даже если на узле не укомплектовано) Теперь в массиве содержаться только те девайсы которые есть на узле.
С долгими командами пока до конца не доделано. С короткими командами всё без проблем работает.
ver 20
еще правлю скетч,уже 22 версия)) самое сложное сделать полное описание всей этой городьбы. (для себя в т.ч.) Скоро переезжаю в новую квартиру. Может что-нибудь там придётся автоматизировать. Хотелось бы, что бы протокол был уже готов к тому времени. Riv, а у тебя как движуха?
PS. В доме я так и не применил этот наш протокол. До сих пор всё продолжает работать на 11битных ID и компактной передачей булевых данных. (в одном байте 8 переменных, а во фрейме 64).
Начал делать подробное описание протокола.
Версия 22.
Описание протокола SmartHomeCAN.
Покритикуйте кто-нибудь.
Начал делать подробное описание протокола.
Версия 22.
Описание протокола SmartHomeCAN.
Покритикуйте кто-нибудь.
Предлагаю в описании протокола не привязываться пока с конкретными файлами конфигов и пр.
Нужно расписать , согласовать, подробно структуру заголовка и перечень команд. Чтобы как минимум сохранить совместимость твоего кода и моей библиотеки. Чтобы навстречу работали.
эмм , мне бы быстрее всё на бумагу положить, пока я через два года опять всё вспомнил, а то это "вспомнил" будет не долго продолжаться.
Потом переделать легче, когда инфа будет в электронном виде , а не в голове.
Набросай тогда, потом дополним. См. ещё на гитхаб у меня там тоже какое что есть.
Описание протокола SmartHomeCAN.
Покритикуйте кто-нибудь.
У меня Emergency-сообщения типа аварий с большим приоритетом идут, нежели данные по метрикам.
Описание протокола SmartHomeCAN.
Покритикуйте кто-нибудь.
У меня Emergency-сообщения типа аварий с большим приоритетом идут, нежели данные по метрикам.
Насколько я помню в can нет приоритезации. Скорости большие. Обработку нужно вводить на 3 или 4 уровне в шлюзе. Кстати я сейчас занимаюсь интеграцией с majordomo на базе https://github.com/foxvlad/OkBitUDP и https://github.com/foxvlad/ESP8266WiFiOkBit и can to udp.
Начал делать подробное описание протокола.
Версия 22.
Описание протокола SmartHomeCAN.
Покритикуйте кто-нибудь.
И ещё предложение. Давай на гитхаб уже проект вытаскивай, для совместной работы.
Хочется вам помочь, только не знаю чем :) Критиковать не буду чтоб не сбить с мысли.
Просто оставлю это тут. Ссылка.
У меня нет текстового описания своего протокола (мне как-то проще ориентироваться именно по таблицам), и он заточен именно под автоматизацию дачи, то есть не является универсальным. Из того что я тут прочел очень многое пересекается. Может кто-то найдет для себя что-то полезное или вообще пересмотрит всю концепцию как это в свое время произошло со мной.
Хочется вам помочь, только не знаю чем :) Критиковать не буду чтоб не сбить с мысли.
Просто оставлю это тут. Ссылка.
У меня нет текстового описания своего протокола (мне как-то проще ориентироваться именно по таблицам), и он заточен именно под автоматизацию дачи, то есть не является универсальным. Из того что я тут прочел очень многое пересекается. Может кто-то найдет для себя что-то полезное или вообще пересмотрит всю концепцию как это в свое время произошло со мной.
Может тогда и код сюда или на гитхаб есть смысл выложить. Так сказать для заимствования идей. Платформы разные конечно. Базовые принципы те же.
Вот не хочется никого учить. По-этому и не хочу никого сбивать с мысли. В основном я использую pic18f46k80 с прерыванием по приему can. В прерывании идет чтение пакета в экземпляр структуры, описанной в протоколе
, после чего он перекладывается в кольцевой буффер структур для дальнейшей обработки другим потоком ОСРВ.
Да всё то же самое что и у вас, те же дефайны "тип блока", по которому переподключаются разные заголовочные файлы и один и тот же проект компилируется под разные блоки с разными задачами. Есть задачи глобальные, есть применимые только к конкретному блоку. Даже их количество разное для каждого блока. С инициализацией камней то же самое.
Я не сторонник использования can-шины как эзернета, с адресом отправителя, адресом получателя и.т.п вещами. Есть идентификатор пакета и по этом идентификатору каждый блок и так знает нужен он ему или нет внезависимости от кого он поступил. По-этому в концепцию даже не вмешиваюсь.
еще правлю скетч,уже 22 версия)) самое сложное сделать полное описание всей этой городьбы. (для себя в т.ч.) Скоро переезжаю в новую квартиру. Может что-нибудь там придётся автоматизировать. Хотелось бы, что бы протокол был уже готов к тому времени. Riv, а у тебя как движуха?
PS. В доме я так и не применил этот наш протокол. До сих пор всё продолжает работать на 11битных ID и компактной передачей булевых данных. (в одном байте 8 переменных, а во фрейме 64).
Упустил это твое сообщение.
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 хоть я освоил, и то ладно))
лапша - питание причём 220В. Просто много читал, что типа многим не хватает через жилы витухи . Фиг его знает на чё меня растащит, делая тот или иной узел.
Дак это не лапша. Лапша - это совершенно определённый вид кабеля.
Учти, что стандарты СКС не приветствуют сбор в пучок силовых и сигнальных кабелей. Правильная проводка подразумевает определённый гап между ними. При прокладке чистой витухи с 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В я так понимаю.
я хотел 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в)
для объединения шин, но каждая шина автономна и самодостаточна. Примерно так.
PS. и ID у вас.... это жесть конечно, не кратные нибблам данные, жонглировать ими то ещё удовольствие.
Да не, битовые поля это не так сложно как кажется. Особенно если использовать union.
С некратностью связана только одна сложность... Вручную ввести пакет для передачи трудновато :) Хотя был забавный момент, когда я решил подать команду в сеть на включение шифрования приема/передачи пакетов. Кое-как в калькуляторе посчитал ID, команду подал, вижу что пошел откровеннейший "мусор", то есть блоки друг друга понимают, а я сижу как перед экраном Матрицы, разве что только интерфейс не черно-зеленый. Ну, думаю, всё, хорош, верните понятные данные. Даю команду отключить шифрование, она конечно не работает. Ну все, подумал уж восстание машин началось, ан нет. Команду-то тоже надо было подавать в зашифрованном виде :) В общем проще наверное было все блоки перепрошить чем это посчитать, но я справился. Хорошо хоть не догадался ввести команду смены ключа шифрования. Сеть бы себе придумала новый ключ, и было бы еще веселее.
Мда, действительно, главное не доводить до того , чтоб дом был умнее тебя))
на концах будут wi-fi шлюзы (он на stm32 вот такой трехэтажный с питанием до 30в)
круто, а схемку его можно увидеть? Код для СТМ32 в чем написан?
MaxVV, выложил твой код https://github.com/graynet-dev/SmartHomeCAN
Ставь https://desktop.github.com/ и выкладывай сразу сюда.
круто, а схемку его можно увидеть? Код для СТМ32 в чем написан?
Я схем не рисую. Сразу плату. Штук 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 не впихнуть?
а зачем тут 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. А узлы отвечают, в заголовке ответа адрес узла и так уже есть. А вот что включить в 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 с временем слать, тогда уж в аварийном режиме начинают ноды сами пульс гнать в шину.