Добрый день. Описал, отдал разработчикам. Думаю что исправим.
Еще раз здравствуйте, Фиксил на днях проблему которая обнаружилась в ходе тестирования интеграции - данные с датчика закрытия двери летели каждую минуту в яндекс, допилил, теперь летят только по смене состояния.
Может полезен будет отчет
Железные правила (откуда — реальные поломки, не теория)
Alice-конфиг только REST; кириллица — только через scratchpad+pscp; log_level только WARNING (DEBUG реально роняет сервис на этом железе); проверять retained перед capability; wb-rules адаптеры только односторонние; trackMqtt вместо whenChanged для команда-топиков; смена type требует пересоздания устройства; патчи в site-packages слетают при апдейте пакета (сейчас их 5, все в скилле); rm -rf pycache перед каждым рестартом после патча; не редактировать вендорские файлы sed’ом на живую — только download->Edit->py_compile->upload->py_compile; не рестартовать сервис сериями — ExecStartPre не защищён от прерывания, плюс подозрение на троттлинг Yandex.
Баги/дыры для разработчиков wb-mqtt-alice
- Relative range вообще не обрабатывался (пофикшено нами)
- Дедлок пула потоков в read_topic_once — таймаут не убивает поток (пофикшено)
- Нет дедупликации значения перед пушем в Яндекс (пофикшено, не подтверждено живьём)
- Поставляется nginx-конфиг с error_log debug (пофикшено)
- BATCH_WINDOW_NORMAL=1.0с почти для всех типов, недокументировано (смягчено env-override)
- on_connect/состояние сокета — чёрный ящик, link_status не отражает реальность, всё логирование на недоступном в проде уровне
- whenChanged-паттерн в их же стиле кода — ловушка на повторные одинаковые команды, нигде не задокументирована
- DEBUG-логирование способно убить сервис по памяти на референсном железе вендора
- ExecStartPre не переживает быстрый повторный restart — краш-луп
- Нет официального словаря mode/toggle instance/value в комплекте пакета
Благодарю. передал разработчикам.