Ну а всетаки будет ли когда нибудь заявленная в рекламе поддержка китайского 433 МГц оборудования?

как пример Rubetec Evo

C Rubitek похоже не все так просто. Часть оборудования(датчики) использует 433 Mhz, а часть (исполнительные устройства) похоже Z-Wave.

Базовую поддержку датчиков Rubitek добавил в rfsniffer, могу выложить версию для тестирования. Пока проверял только на датчике открывания дверей/окон. Если тема актуальна и есть датчики для проверки работоспособности - можно докрутить поддержку остальных видов датчиков.

тема актуальна. Но у меня WB3.5 прошу помочь запустить rfsniffer на нем = смогу потестить датчику рубитек те которые 433MHz. Z-Wave мимо моего устройства

Давайте попробуем запустить.

  1. Лучше начать проверку с какого-то датчика/пульта, который точно поддерживается (Oregon, Noolite, RST, Livolo, Raex).
  2. Актуальная версия доступна https://www.dropbox.com/s/ymkgz7w69shmwd2/rfsniffer
  3. Теоретически, он должен подхватить параметры из переменных окружения, но в крайнем случае их придется задать явно (rfsniffer -?).
  4. Нужно запустить rfsniffer (Запись и воспроизведение произвольного сигнала 433Mhz).
  5. Если он успешно принимает сигналы хоть от какого-то устройства - можно продолжать с Rubitek или другими.
  6. Если стандартные датчики не работают - проверить, что стандартый wb-homa-rcd нормально работает.

Дело в том. что был неудачный эксперимент с @Ruslan_Stepanenko (Датчик движения 433 МГц от какой-то сигнализации данные от которого видны в /events/wb-homa-rcd/protocols/raw) и у меня была очень странная история с Что это могло быть?. Причины выяснить так и не получилось.

@EvgenyBoger, а вы не пробовали запускать rfsniffer на WB4 и WB3.5 ?
Там очень теоретически могут быть проблемы с:

  • драйвером lirc
  • производительностью (когда идет длинный сигнал, похоже, что драйвер потребляет заметное кол-во ядерного времени)
  • памяти (совсем маловероятно, но)

не пробовали, попробуем, если руки дойдут. По идее, процессорные ядра там идентичны и ядро линукса тоже одинаковое. Разница только в скорости и объёме оперативной памяти.

Вечерком сегодня выделю время попробую с noolite и оригонами для начала

  1. есть работающие датчики орегон TGN132 и выключатели и силовые блоки ноолайт
  2. скачал актуальную версию rfsnifer
  3. параметры из переменных окружения не подхватил
    root@wirenboard-AISNIH3K:~/rfsniffer# ./rfsniffer
    15/11 19:45:12 [24771] Using SPI device /dev/spidev32766.0, lirc device /dev/lirc0, mqtt on localhost
    15/11 19:45:12 [24771] SPI init failed
  4. запустил
  • root@wirenboard-AISNIH3K:~/rfsniffer# ./rfsniffer -s /dev/spidev1.5*
    15/11 19:46:38 [24798] Using SPI device /dev/spidev1.5, lirc device /dev/lirc0, mqtt on localhost
    15/11 19:46:38 [24798] CRFProtocol decoders use pauses 140-47000 pulses 20-3500
    15/11 19:46:38 [24798] mqtt::on_connect(0)
    15/11 19:46:38 [24798] RF got data 38 bytes. RSSI=-74
    орегон видит
    15/11 19:48:44 [24798] RF got data 9012 bytes. RSSI=-73
    15/11 19:48:44 [24798] RF Recieved: Oregon:type=1D20 id=114 ch=4 t=24.4 h=36. RSSI=-73 (-74)
    15/11 19:48:44 [24798] Msg from Oregon type=1D20 id=114 ch=4 t=24.4 h=36
    15/11 19:48:45 [24798] RF got data 3312 bytes. RSSI=-73
    ноолайты нет…

На noolite совсем не реагирует?

Попробуйте запустить “rfsniffer -w 20 -s /dev/spidev1.5”, несколько раз нажать на кнопки nooLite пульта/выключателя и прислать мне файлы capture* и /run/Main.log

Если есть датчики Rubetek, то для них так же записать пакеты (файлы capure*) и прислать. По идее, датчики движения Rubetek он должен корректно распознавать.

куда выслать ?

alexey.p@avp.name

отправил

Получил

Очень похоже, что у Вас перепутаны 0 и 1, приходящие в lirc драйвер. Я писал про эту проблему в соседней ветке. Лечится она пересборкой DevTree Запись и воспроизведение произвольного сигнала 433Mhz. В WB5 проблема полностью ушла. На WB3.5 возможно её никто не правил.

У Oregon и у NooLite симметричные нули и единицы, но драйвер немного удлиняет единицы и укорачивает нули. Т.е. на симметричных протоколах все может “как-то” работать даже при перевернутых значениях. Но на практике - работает плохо.

Нужна помощь @LexsZero или @EvgenyBoger, чтобы поправить драйвер GPIO и его настройки. :frowning:

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

Куда писать, если rfsniffer работает некорректно?
Использую (для примера) пульт от nooLite, две обычных кнопки и одна сценарная. rfsniffer определяет обычные кнопки как датчики движения PM111, а сценарные в логе видит (wb-homa-rfsniffer.log), но не добавляет их никуда. Соответственно нормально ничего не работает. Что делать?
rfsniffer установлен из deb пакета версии 1.0.3 альфа

Готов еще потестировать:
Куча датчиков Oregon (температура+влажность)
nooLite - датчики температур и влажности, пульты и переносные и стационарные, датчики движения,
но надо чтобы базовая часть пультов заработала.

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

  1. Кто-то из техподдержки WB сможет оперативно повторить проблему и поправить
  2. Я пришлю версию с отладочной печатью сырых данных получаемых с устройств, вы пришлете мне логи, и я поправлю.

Так. От меня что требуется? логи? устройства?

Для начала просто логи. Если в них все пишется, возможно, этого будет достаточно.

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

т.е. скорее всего достаточно логов + пояснений “когда что нажимали”, чтобы соотнести с логами