Очередной "Умный дом", на этот раз модульная система...

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Обмен это как раз для виртуальных устройств. Обмен данными 11 например сенсор CO2 а 22 это контроллер вентиляции. (это условно, могут быть мульти функц. устройства с кучей датчиков и иу, которые для тебя черный ящик только с протоколом управления и датчиками и иу)

Я хочу и на сервере их видеть и ими управлять в ручном режиме но и пусть они сами трудятся в автоматическом режиме.

нода 22 запрашивает датчик CO2 (пусть адрес будет 06 и номер датчика 2) на Kitchen (адрес 11). 

                                                   -------ID-------     -payload-

CAN фрейм запрос от ноды 22:     1 3  22  11  06         02

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

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

Я вообще то думал, что мы общую систему сделаем. В библиотеке куча твоего кода. Много идей и пр.

Мы ведь пока макетируемся.

И идея в начале топика указана к ней вроде и идем

>>Краткая суть идеи такая:

>>1. Система управления должна состоять из полностью автономных и независимых модулей.

>>2. Каждый модуль легко может быть отключен (выключателем) и система будет функционировать без него по упрощенному или ручному режиму

>>3. Все модули умеют общатся друг с другом по единому протоколу и иметь универсальный программный интерфейс сопряжения.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Обмен это как раз для виртуальных устройств. Обмен данными 11 например сенсор CO2 а 22 это контроллер вентиляции. (это условно, могут быть мульти функц. устройства с кучей датчиков и иу, которые для тебя черный ящик только с протоколом управления и датчиками и иу)

Я хочу и на сервере их видеть и ими управлять в ручном режиме но и пусть они сами трудятся в автоматическом режиме.

нода 22 запрашивает датчик CO2 (пусть адрес будет 06 и номер датчика 2) на Kitchen (адрес 11). 

                                                   -------ID-------     -payload-

CAN фрейм запрос от ноды 22:     1 3  22  11  06         02

Так у нас так и работает. О чем спорим 2 страницы )))

Но вроде договорились

CAN фрейм запрос от ноды 22:     1 3  06  22  11           02

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Ну у объекта есть свойства, методы и события.

да, эти понятия в мажор доме обильно используются. Я так их понимаю .

Объект – наш девайс в массиве девайсов; Свойство – это состояние девайса , которое можно изменить; Метод – это команда, которая используется для изменения свойства объекта; Значение – это новая установка свойства. Событие  - выполнение команды. Почти теже термины, что и у меня. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Так у нас так и работает. О чем спорим 2 страницы )))

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

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Так у нас так и работает. О чем спорим 2 страницы )))

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

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

Например в моем случае 7,8,9  1 группа. 9,10,11 - 2 группа,  и т.д. Плоть до использования блока данных для этой адресации. 16 групп хватит? 4 бита.

MaksVV
Offline
Зарегистрирован: 06.08.2015

16 хватит 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Ну у объекта есть свойства, методы и события.

да, эти понятия в мажор доме обильно используются. Я так их понимаю .

Объект – наш девайс в массиве девайсов; Свойство – это состояние девайса , которое можно изменить; Метод – это команда, которая используется для изменения свойства объекта; Значение – это новая установка свойства. Событие  - выполнение команды. Почти теже термины, что и у меня. 

Скорее так

Свойство - включено-выключено - состояние при опросе, но можно и поменять

Метод - включить-выключить - команда

Событие - включилось выключилось, приходит по исполнению команды или по внешнему воздействию.

И классы в библиотеке это тоже объекты,  поэтому и рекомендую уходить в ООП. Объем кода уже огромный без классов дублирование сумашедшее. Я уже к Template подбираюсь.

P.S.

Объектом является сеть для PC, в нем контроллеры и ниже и ниже и ниже

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
MaksVV пишет:

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

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

Начнём с ИУ . Этими ИУ рулит тип фрейма команда.  У каждого ИУ в конфиге указывается вид подключения. Дак вот, до этого момента варианты вида подключения были только  GPIO: 

LONG                           // надстройка для команд, которые выполняются дольше 0,5 секунды. 
DIGITALWRITE              // булевое устройство, подключено к цифровому
DIGITALWRITE_INVERT // булевое устройство,   инвертирована логика (например, как у релейных модулей)
PWMWRITE                  // устройство управляемое ШИМ сигналом, подключено к PWM выходу ардуино
PROCENTWRITE           // устройство управляемое градацией от 0 до 100%
IMPULSE_GND             // устройство, импульс GND ,  меняет своё состояние на противоположное
IMPULSE_POWER         // устройство, импульс HIGH, меняет своё состояние на противоположное
 
Теперь нужно это завернуть в отдельный подтип GPIO. При получении команды на девайс на нём проверяется вид подключения, если GPIO вызывается отдельная для этого функция. Так же и для остальных видов подключения   - нужно сделать отдельные функции, которые будут вызываться по результатам проверки какой вид подключения. Не забываем что в команде присутствует способ управления
RESERVE,                               00 - Резерв
DIGITAL_REMOTE               01 - Включение/выключение булевых устройств                                         
DIGITAL_INVERT,                02 - Инвертирование состояния булевых устройств                                         
DIMMER_SETTING,             03 - Установка процента включения диммируемых устройств                           
DIMMER_TURN_OFF,        04 - Уменьшение процента диммера (значение увеличения в CommandValue)               
DIMMER_TURN_ON,          05 - Увеличение процента диммера (значение уменьшения в CommandValue)               
IMPULSE_REMOTE,            06 - Включение/выключение импульсных  устройств                                         
IMPULSE_INVERT,               07 - Инвертирование состояния импульсных  устройств                                 
PWM_SETTING,                  08 - Установка уровня диммируемых устройств PWM (значение в CommandValue)           
PWM_TURN_OFF,              09 - Уменьшение уровня PWM устройств (значение увеличения в CommandValue)           
PWM_TURN_ON,               0A - Увеличение уровня PWM устройств (значение уменьшения в CommandValue)           
PARAMETER_WRITE,         0B - Изменение значения выбранного параметра (массив parameter)

Этот способ должен соответствовать виду подключения. Например, нельзя рулить яркостью лампы, если она булевая. 

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

Я в классах к сожалению вообще не петрю. Научился блин if, for и millis пользовать и попёр умный дом строить. Это как только двумя пальцами печатать))

demid.net
Offline
Зарегистрирован: 02.12.2019

riv пишет:

Давай все же отработаем сначала структуру ID  и уровни абстракции (уровни виртуализации). 

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

Тогда "640кб хватит всем" (с)

По сути первые биты будут обозначать уровень абстракции, используемый в пакете. Наибольший приоритет у физических блоков на шине. Поскольку если такой блок не работает - не работает и modbus к нему подключенный.

Пытаться всё впихнуть в id жестко заданной структуры - избитая идея. Изначально CAN был 11 бит id. Потом решили что мало, надо 29. Сделали CAN 2.0. Потом еще раз сели, хорошо подумали и сделали CAN FD. Не удивлюсь если в CAN FD 2.0 будет килобитный айди.

riv
Offline
Зарегистрирован: 20.07.2017

Немного в сторону уйду.

Мы тут с Вами протокол стабильным делаем, а тут датчики виснут, наглухо причем.

BME280 по I2C через сутки виснет и требует аппаратного сброса по питанию, та же история и с MH-Z19, виснет RS232, PWM работает нормально.

С BME280 попробую уйти на SPI, может поможет. Z19 следует использовать только по аналогу. (RS232 для калибровки там и пр.). Как то так.

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Ниче не виснет, ни BME, ни BMP, ни MHZ, ни PMS. Работают месяцами, если питание ОК.

riv
Offline
Зарегистрирован: 20.07.2017

sadman41 пишет:
Ниче не виснет, ни BME, ни BMP, ни MHZ, ни PMS. Работают месяцами, если питание ОК.

BME по SPI или I2C? У Z19 используется аналоговый выход или rs232?

sadman41
Онлайн
Зарегистрирован: 19.10.2016

BME по I2C. Спешить мне некуда, а вот лишние провода раздражают.