Oregon - поддержка разных датчиков

В логах какая-то совершенная ерунда, такое ощущение, что у протокола этих датчиков другая частота (битрейт).
Вдвойне странно, потому что THGN132N работает и всегда работал у нас на стенде и никаких проблем с ним не было.

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

В том то и загадка - метеостанция купленная около 2.5 лет назад эти датчики видит вообще без проблем, она возможно конечно не использует фиксированный битрейт, а подстраивается к тому что идет с эфира (за счет преамбулы). Вообщем со всеми тремя моими датчиками с индексом 132 у меня сегодняшняя версия не работает (THN132 (куплен в октябре), и два THGN132(один октябрьский этого года, второй куплен два года назад)). С датчиками 122 серии проблем нет.

hamster, а что в итоге с pull request? Если это сложно, то давайте я тогда сам ваш код залью?

Евгений, заливайте. Я, похоже, на некоторое время выпал из процесса… Просто некогда. Сначала из-за работы :frowning: а теперь вот из-за отпуска :slight_smile:

Вопрос немного не по теме, но косвенно.
Вы используете модули RFM69H для связи с датчиками или модули на основе SI4432? Судя по схеме могут стоять и те и те.
Почему отказались от SI4432 ? (по схеме оно N/A).
Стоит задача на модулях SI4432 организовать прием с датчиков Oregon, как эти модули с этим справятся?

SI4432 даже не пробовали. RFM69 в итоге полностью устроили, разницы в цене большой не было.
Посадочные площадки рисовали на этапе проектирования ещё.

А можно еще раз куда то выложить файлы mqtt_devices.py и oregon.py, а то ссылка законцилась, а на GitHub так ни кто и не выложил.

Ситуация становится более интересной (с двумя датчиками THN132N и THGN132N).
Переставил я WSBH на второй этаж (подключил к сети изернет, т.к. с вайфаем я его терял постоянно). Раньше THN132N стоял на расстоянии 30 см от wiren, теперь около 4 метров, и что интересно в первом случае он не виделся, а во втором увиделся и работает без проблем. А вот второй датчик, который стоит в подвале продолжает быть не виден вообще.

Странно себя ведет скрипт который в MQTT выводит данные с орегона - перестает выводить данные.

Прилетает и раскодируется правильно:

/events/wb-homa-rcd/protocols/raw raw=66696966999696696999999699969666669999966996699969999996999669999966996669996696696000000070ffffffffffffffffff3333333333
/events/wb-homa-rcd/protocols/oregon code=7d    temp=23.3       humidity=31     raw=1010011101001011111101110100000111110011001110111111011100111110011000111001001    type=1a2d       channel=1

а тут ничего:
root@wirenboard:~# mosquitto_sub -v -t '/devices/oregon_rx_1a2d_7d_1/controls/#'

Если значение температуры и влажности равна данным из предыдущей посылки - выводится ли это значение?

Если значение температуры и влажности равна данным из предыдущей посылки – выводится ли это значение?

нет

Неправильно - иногда по 2часа нет показаний, кажется что датчик отвалился.
И тогда почему 1wire шпарит раз секунду?

такая логика только в драйвере радио. Проблема известная, будем исправлять.

Сегодня Иван принял мой пул реквест и на радостях от этой положительной новости хочу озвучить свои дальнейшие планы относительно Domoticz и wb-homa-ism-radio:

  1. Хочу произвести синхронизацию Domoticz на Git с SVN. Тот который сейчас это сентябрьский 1909, чейчас уже идет r22xx. Там уже было множество изменений.
  2. Потом хочу внести изменения в wb-homa-ism-radio: сейчас в mqtt данные летят по температуре и по влажности отдельно. Получается что в Domoticz эти два значения прилетают как два отдельных датчика и при большом количестве датчиков их связывать тяжело (у меня три датчика=6 устройств). В тоже самое время датчики температуры в Domoticz поддерживают комбинации: temp+hum, temp+bar. Так как датчиков поддерживающих давления у меня, то я буду объединять только температуру и влажность для Орегон. Также туда необходимо добавить передачу состояния батареи которое передает Oregon. При этом буду исправлять чтобы данные публиковались в MQTT при каждом получении, а не только при изменениях значения.

Что касается wb-homa-ism-radio то, там Python и хоть я его не писал на нем, по аналогии смогу исправить. А вот с хардкорным C++ придется повозиться дольше. Т.е. что касается увеличения версии Domoticz это скорее всего будет не очень долго - так как там фактически нужно получить патчи и попытаться применить их к новой версии + внести соответствующие исправления. А вот п.2 тут может затянуться.

Отлично. по поводу THGN132N который у меня не особенно работал. Удалось наконецто его поймать, только уменьшив длинну преамбулы в настройках rfm до 1. Как это повлияло не очень понятно, т.к. ниблы и синх байты остались на своих законных местах. При этом пришлось отключить расчет контрольной суммы, т.к. она всегда была неверная, надо будет проверить, ктонибудь знает внятное описание как она считается (т.к. в том текста что в начале этого треда написано, что у разных типов датчиков при использовании протокола 2.1 может быть разное начальное значение для подсчета контрольной суммы). Сегодня ночью тест, завтра попробую всетаки отписаться что сделал.

я буду объединять только температуру и влажность для Орегон

Получается, что это противоречит принципу формирования сообщений в MQTT. В наших соглашениях device - это физическое устройство (датчик температуры и влажности), controls - это одиночные ручки или измеряемые параметры (отдельно температура, отдельно влажность).
Задачу сборки этих данных вместе для красивого комбинированного виджета у нас выполняет веб-интерфейс.

Конкретно в domoticz у нас подобное объединение работает, просто для температура+влажность не сделано.
Смотреть сюда: https://github.com/contactless/domoticz/blob/master/hardware/WBHomaBridge.cpp#L823 . Надо добавить в этот список, кроме этого сделать класс комбинированного контрола (по мотивам имеющегося MQTTTempBaroControl например) и добавить логику в MQTTTemperatureControl::AddSlave, чтобы возвращало этот, скажем, MQTTTempHumControl.

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

Я понимал, что это противоречит духу MQTT. Ок, попробую разобраться и сделать как положено :slight_smile: В общем-то это даже кое в чем проще чем я изначально задумал. Вся проблема в том, что для меня весь код C++ WBHomeBridge выглядит как клубок классов, наследований и пространств имён. Сходу не получается разобраться, тем более не имея опыта программирования на C++.

А насчет Domoticz в целом - все же удобная штука. Тем более имеет приложение для мобильного и использует современные веб-технологии. Приложение я установил и настроил на Android. С мобильного можно посмотреть состояние датчиков. Можно пощелкать переключателями.
Также уже успел разобраться с привязкой пультов Noolite. Привязал чисто пульт и с него управляю состоянием выходов WB SH (тестировал только on/off). Есть уведомления на email, в том числе PUSH сообщения. Есть сцены и различные сценарии. Есть поддержка скриптового языка Lua (еще не тестировал). Для меня это все выглядит перспективно. Кроме того, вокруг него уже образовалось кое-какое сообщество. Также Domoticz кроссплатформенный - отсюда и код такой запутанный (как сказал мой друг).

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

Вот скажите, как быстро у Вас появится мобильное приложение? Когда Ваше приложение будет на уровне функционала Domotic? Я это веду к тому, что без ПО железо будет лежать мертвым грузом. Я вот, например, получил WB SH еще летом, а первый раз включил только в октябре. Реальное применение же начало вырисовываться только сейчас, в декабре, с появлением Domoticz. А заказ делал еще прошлой зимой…
Domoticz хорош тем, что у него невысокие требования к железу (приложение монолитное, кроме того это не ява как у OpenHAB или других подобных), у него хорошая кросс-платформенность и еще у него довольно-таки хороший спектр поддерживаемых железок и датчиков помимо MQTT написанного Вами.

PS: Похоже автор решил синхронизировать коммиты из Subversion в Git. Сейчас вся история в domoticz/domoticz есть. Вплоть до 18 января синхронизированы коммиты. Хоть и с небольшой задержкой.

Сделал пулл-реквест для ism-radio. В патче идет код поддержки орегон от hamster-a. Это добавляет кроме поддержки новых датчиков еще и поддержку информации о разряде батареи (для меня это важно - так как предполагается что пользователь может годами не видеть эти датчики, а так данная информация будет видна в Domoticz).
Сделал небольшой фикс: теперь в mqtt публикуются не изменения, а все данные полученные от датчика. В Domoticz теперь все датчики выглядят “живыми”.

Спасибо, на днях посмотрю. По орегону там есть замечания: надо будет исправить названия величин из camelCase на snake_case, как у нас принято. Ещё мне очень не нравится meta: units, я предлагаю всю представленную таблицу величин вынести в вики и зафиксировать. На самом деле нет никакого смысла иметь драйвера, которые отправляют давление в барах, паскалях и фунтах на квадратный дюйм - это сильно всё усложняет. Гораздо проще договорится о величинах заранее и делать так, чтобы тип (meta:type) однозначно определял величину, как это собственно сейчас и есть. Единственное, что возможно имеет смысл в будущем сделать - это вынести множитель или десятичную степень в meta, но и для этого пока нет необходимости.