Обмен это как раз для виртуальных устройств. Обмен данными 11 например сенсор CO2 а 22 это контроллер вентиляции. (это условно, могут быть мульти функц. устройства с кучей датчиков и иу, которые для тебя черный ящик только с протоколом управления и датчиками и иу)
Я хочу и на сервере их видеть и ими управлять в ручном режиме но и пусть они сами трудятся в автоматическом режиме.
нода 22 запрашивает датчик CO2 (пусть адрес будет 06 и номер датчика 2) на Kitchen (адрес 11).
ок, у нас системы разного уровня. У тебя прям ЦУП, а у меня так, лампочками по шине помигать. Поэтому и подходы разные , трудно прийти к общему знаменателю.
Я вообще то думал, что мы общую систему сделаем. В библиотеке куча твоего кода. Много идей и пр.
Мы ведь пока макетируемся.
И идея в начале топика указана к ней вроде и идем
>>Краткая суть идеи такая:
>>1. Система управления должна состоять из полностью автономных и независимых модулей.
>>2. Каждый модуль легко может быть отключен (выключателем) и система будет функционировать без него по упрощенному или ручному режиму
>>3. Все модули умеют общатся друг с другом по единому протоколу и иметь универсальный программный интерфейс сопряжения.
Обмен это как раз для виртуальных устройств. Обмен данными 11 например сенсор CO2 а 22 это контроллер вентиляции. (это условно, могут быть мульти функц. устройства с кучей датчиков и иу, которые для тебя черный ящик только с протоколом управления и датчиками и иу)
Я хочу и на сервере их видеть и ими управлять в ручном режиме но и пусть они сами трудятся в автоматическом режиме.
нода 22 запрашивает датчик CO2 (пусть адрес будет 06 и номер датчика 2) на Kitchen (адрес 11).
-------ID------- -payload-
CAN фрейм запрос от ноды 22: 1 3 22 11 06 02
Так у нас так и работает. О чем спорим 2 страницы )))
да, эти понятия в мажор доме обильно используются. Я так их понимаю .
Объект – наш девайс в массиве девайсов; Свойство – это состояние девайса , которое можно изменить; Метод – это команда, которая используется для изменения свойства объекта; Значение – это новая установка свойства. Событие - выполнение команды. Почти теже термины, что и у меня.
Так у нас так и работает. О чем спорим 2 страницы )))
дак я и твержу, что в общем то ничего сильно не собираюсь менять. Всего лишь хотел узлам одной комнаты одинаковые адреса дать, и добавить им ещё адреса физические. и всё.
Так у нас так и работает. О чем спорим 2 страницы )))
дак я и твержу, что в общем то ничего сильно не собираюсь менять. Всего лишь хотел узлам одной комнаты одинаковые адреса дать, и добавить им ещё адреса физические. и всё.
А я и твержу что не надо, сделай им выше групповой адрес.
Например в моем случае 7,8,9 1 группа. 9,10,11 - 2 группа, и т.д. Плоть до использования блока данных для этой адресации. 16 групп хватит? 4 бита.
да, эти понятия в мажор доме обильно используются. Я так их понимаю .
Объект – наш девайс в массиве девайсов; Свойство – это состояние девайса , которое можно изменить; Метод – это команда, которая используется для изменения свойства объекта; Значение – это новая установка свойства. Событие - выполнение команды. Почти теже термины, что и у меня.
Скорее так
Свойство - включено-выключено - состояние при опросе, но можно и поменять
Метод - включить-выключить - команда
Событие - включилось выключилось, приходит по исполнению команды или по внешнему воздействию.
И классы в библиотеке это тоже объекты, поэтому и рекомендую уходить в ООП. Объем кода уже огромный без классов дублирование сумашедшее. Я уже к Template подбираюсь.
P.S.
Объектом является сеть для PC, в нем контроллеры и ниже и ниже и ниже
я подумаю над всем этим и что-то исправлю. Действительно смысла не много в том, чтобы рулить пинами напрямую с верхнего уровня. Это должен делать сам узел. А мы ему просто должны говорить , сделать то-то, сделать то-то, а пины это чисто его прерогатива . Но удалённое хард управление тоже оставлю, на всякий.
Готов поработать совместно, я займусь функциями датчиков и иу. Как раз дошел до этого уровня. Нужно продумать универсальный вызов функции и возврат параметров. Чтобы была одна функция запросчик параметров сенсоров, одна запросчик состояния иу, одна командная А внутри в зависимости от типа устройства вызывались функции обработчики.
Начнём с ИУ . Этими ИУ рулит тип фрейма команда. У каждого ИУ в конфиге указывается вид подключения. Дак вот, до этого момента варианты вида подключения были только GPIO:
LONG // надстройка для команд, которые выполняются дольше 0,5 секунды.
DIGITALWRITE // булевое устройство, подключено к цифровому
DIGITALWRITE_INVERT // булевое устройство, инвертирована логика (например, как у релейных модулей)
PWMWRITE // устройство управляемое ШИМ сигналом, подключено к PWM выходу ардуино
PROCENTWRITE // устройство управляемое градацией от 0 до 100%
IMPULSE_GND // устройство, импульс GND , меняет своё состояние на противоположное
IMPULSE_POWER // устройство, импульс HIGH, меняет своё состояние на противоположное
Теперь нужно это завернуть в отдельный подтип GPIO. При получении команды на девайс на нём проверяется вид подключения, если GPIO вызывается отдельная для этого функция. Так же и для остальных видов подключения - нужно сделать отдельные функции, которые будут вызываться по результатам проверки какой вид подключения. Не забываем что в команде присутствует способ управления :
Давай все же отработаем сначала структуру ID и уровни абстракции (уровни виртуализации).
Возможно на первый взгляд глупость посоветую, но так по крайней мере у себя сделал, выделить в самых старших битах ID 1 бит (может 2-3 в вашем случае + резерв) под "режим сети" и в зависимости от него по-разному дробить ID в зависимости от того, что вы хотите получить.
Тогда "640кб хватит всем" (с)
По сути первые биты будут обозначать уровень абстракции, используемый в пакете. Наибольший приоритет у физических блоков на шине. Поскольку если такой блок не работает - не работает и modbus к нему подключенный.
Пытаться всё впихнуть в id жестко заданной структуры - избитая идея. Изначально CAN был 11 бит id. Потом решили что мало, надо 29. Сделали CAN 2.0. Потом еще раз сели, хорошо подумали и сделали CAN FD. Не удивлюсь если в CAN FD 2.0 будет килобитный айди.
Я хочу и на сервере их видеть и ими управлять в ручном режиме но и пусть они сами трудятся в автоматическом режиме.
нода 22 запрашивает датчик CO2 (пусть адрес будет 06 и номер датчика 2) на Kitchen (адрес 11).
-------ID------- -payload-
CAN фрейм запрос от ноды 22: 1 3 22 11 06 02
ок, у нас системы разного уровня. У тебя прям ЦУП, а у меня так, лампочками по шине помигать. Поэтому и подходы разные , трудно прийти к общему знаменателю.
Я вообще то думал, что мы общую систему сделаем. В библиотеке куча твоего кода. Много идей и пр.
Мы ведь пока макетируемся.
И идея в начале топика указана к ней вроде и идем
>>Краткая суть идеи такая:
>>1. Система управления должна состоять из полностью автономных и независимых модулей.
>>2. Каждый модуль легко может быть отключен (выключателем) и система будет функционировать без него по упрощенному или ручному режиму
>>3. Все модули умеют общатся друг с другом по единому протоколу и иметь универсальный программный интерфейс сопряжения.
Я хочу и на сервере их видеть и ими управлять в ручном режиме но и пусть они сами трудятся в автоматическом режиме.
нода 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
да, эти понятия в мажор доме обильно используются. Я так их понимаю .
Объект – наш девайс в массиве девайсов; Свойство – это состояние девайса , которое можно изменить; Метод – это команда, которая используется для изменения свойства объекта; Значение – это новая установка свойства. Событие - выполнение команды. Почти теже термины, что и у меня.
дак я и твержу, что в общем то ничего сильно не собираюсь менять. Всего лишь хотел узлам одной комнаты одинаковые адреса дать, и добавить им ещё адреса физические. и всё.
дак я и твержу, что в общем то ничего сильно не собираюсь менять. Всего лишь хотел узлам одной комнаты одинаковые адреса дать, и добавить им ещё адреса физические. и всё.
А я и твержу что не надо, сделай им выше групповой адрес.
Например в моем случае 7,8,9 1 группа. 9,10,11 - 2 группа, и т.д. Плоть до использования блока данных для этой адресации. 16 групп хватит? 4 бита.
16 хватит
да, эти понятия в мажор доме обильно используются. Я так их понимаю .
Объект – наш девайс в массиве девайсов; Свойство – это состояние девайса , которое можно изменить; Метод – это команда, которая используется для изменения свойства объекта; Значение – это новая установка свойства. Событие - выполнение команды. Почти теже термины, что и у меня.
Скорее так
Свойство - включено-выключено - состояние при опросе, но можно и поменять
Метод - включить-выключить - команда
Событие - включилось выключилось, приходит по исполнению команды или по внешнему воздействию.
И классы в библиотеке это тоже объекты, поэтому и рекомендую уходить в ООП. Объем кода уже огромный без классов дублирование сумашедшее. Я уже к Template подбираюсь.
P.S.
Объектом является сеть для PC, в нем контроллеры и ниже и ниже и ниже
я подумаю над всем этим и что-то исправлю. Действительно смысла не много в том, чтобы рулить пинами напрямую с верхнего уровня. Это должен делать сам узел. А мы ему просто должны говорить , сделать то-то, сделать то-то, а пины это чисто его прерогатива . Но удалённое хард управление тоже оставлю, на всякий.
Начнём с ИУ . Этими ИУ рулит тип фрейма команда. У каждого ИУ в конфиге указывается вид подключения. Дак вот, до этого момента варианты вида подключения были только GPIO:
01RESERVE, 00 - Резерв02DIGITAL_REMOTE 01 - Включение/выключение булевых устройств03DIGITAL_INVERT, 02 - Инвертирование состояния булевых устройств04DIMMER_SETTING, 03 - Установка процента включения диммируемых устройств05DIMMER_TURN_OFF, 04 - Уменьшение процента диммера (значение увеличения в CommandValue)06DIMMER_TURN_ON, 05 - Увеличение процента диммера (значение уменьшения в CommandValue)07IMPULSE_REMOTE, 06 - Включение/выключение импульсных устройств08IMPULSE_INVERT, 07 - Инвертирование состояния импульсных устройств09PWM_SETTING, 08 - Установка уровня диммируемых устройств PWM (значение в CommandValue)10PWM_TURN_OFF, 09 - Уменьшение уровня PWM устройств (значение увеличения в CommandValue)11PWM_TURN_ON, 0A - Увеличение уровня PWM устройств (значение уменьшения в CommandValue)12PARAMETER_WRITE, 0B - Изменение значения выбранного параметра (массив parameter)Этот способ должен соответствовать виду подключения. Например, нельзя рулить яркостью лампы, если она булевая.
Я в классах к сожалению вообще не петрю. Научился блин if, for и millis пользовать и попёр умный дом строить. Это как только двумя пальцами печатать))
Давай все же отработаем сначала структуру ID и уровни абстракции (уровни виртуализации).
Возможно на первый взгляд глупость посоветую, но так по крайней мере у себя сделал, выделить в самых старших битах ID 1 бит (может 2-3 в вашем случае + резерв) под "режим сети" и в зависимости от него по-разному дробить ID в зависимости от того, что вы хотите получить.
Тогда "640кб хватит всем" (с)
По сути первые биты будут обозначать уровень абстракции, используемый в пакете. Наибольший приоритет у физических блоков на шине. Поскольку если такой блок не работает - не работает и modbus к нему подключенный.
Пытаться всё впихнуть в id жестко заданной структуры - избитая идея. Изначально CAN был 11 бит id. Потом решили что мало, надо 29. Сделали CAN 2.0. Потом еще раз сели, хорошо подумали и сделали CAN FD. Не удивлюсь если в CAN FD 2.0 будет килобитный айди.
Немного в сторону уйду.
Мы тут с Вами протокол стабильным делаем, а тут датчики виснут, наглухо причем.
BME280 по I2C через сутки виснет и требует аппаратного сброса по питанию, та же история и с MH-Z19, виснет RS232, PWM работает нормально.
С BME280 попробую уйти на SPI, может поможет. Z19 следует использовать только по аналогу. (RS232 для калибровки там и пр.). Как то так.
Ниче не виснет, ни BME, ни BMP, ни MHZ, ни PMS. Работают месяцами, если питание ОК.
BME по SPI или I2C? У Z19 используется аналоговый выход или rs232?
BME по I2C. Спешить мне некуда, а вот лишние провода раздражают.