Deconz-rest-plugin: ИКЕА горит время от времени теряется связь

То же самое и с 2.05.58. Один Tradfri GU10 кажется безответственным банкоматом:

Со мной тоже случалось со световой полосой оттенка за несколько дней до этого, поэтому я не думаю, что какая-либо проблема, связанная с IKEA. Устройства необходимо перезагрузить и после этого вернуться в нормальное состояние. В некоторых случаях все еще раздражает, в основном для моих панелей FLOALT, которые питаются напрямую и не имеют настенного переключателя для их включения.

1. Любая подсказка почему?

Плагин REST API помечает свет как недостижимый, если он не получает ответа несколько раз при опросе источника о его состоянии. Причина неполучения ответа в порядке вероятности:
а. Мощность света была отключена (например, настенным выключателем 20 века);
б. В сети Zigbee наблюдается сбой (например, из-за радиопомех или проблем с маршрутизацией в сети). В этом случае свет все равно реагирует на групповые команды;
c. Прошивка фары разбилась.

1. Можно ли восстановить соединение, кроме отключения / подключения питания?

В а) и в): нет. В б): да.

Плагин REST API отмечает свет как достижимый, когда получает от него сообщение. При включении света он отправляет сообщение _Device Announcement_. В б), как правило, свет возвращается самопроизвольно, когда следующий опрос успешен. Вы также можете выбрать узел в графическом интерфейсе deCONZ и нажать 0 .

Та же проблема и в версии 2.05.59.

У меня тоже такая проблема, даже после обновления до 2.05.59. Сегодня один из трех моих уличных фонарей "пропал".
Его лампочки Tradfri освещают все три из них.

@ebaauw Спасибо за ваше объяснение.

а. Мощность света была отключена (например, настенным выключателем 20 века);

Для этих светильников нет настенных выключателей, поэтому я не могу случайно отключить питание.

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

Свет не реагирует на групповые команды при потере соединения (свет назначается диммеру Hue в приложении Phoscon и не реагирует на диммер Hue при потере соединения).

c. Прошивка фары разбилась.

Прошивка 1.2.214 установлена ​​на все мои споты IKEA GU10. Получил их 20+ и случайный свет отключается, допустим, через 2-3 недели.

Вы можете попробовать последнюю версию deCONZ с https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c.

У меня был такой же опыт дважды за последние месяцы с двумя разными лампами E14 IKEA (IKEA fw 1.2.214).
В обоих случаях я работал с силовым циклом.

c. Прошивка фары разбилась.

Когда индикаторы не реагируют даже на групповые команды, это похоже на сбой прошивки.

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

Новая конфигурация будет применена после включения и выключения света.

Мы по-прежнему отправляем некоторые запросы на обслуживание, такие как запросы о членстве в группах и соседних таблицах, и можем ограничить их, если стабильность не улучшится с 2.05.59.

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

c. Прошивка фары разбилась.

Когда индикаторы не реагируют даже на групповые команды, это похоже на сбой прошивки.

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

Новая конфигурация будет применена после включения и выключения света.

Мы по-прежнему отправляем некоторые запросы на обслуживание, такие как запросы о членстве в группах и соседних таблицах, и можем ограничить их, если стабильность не улучшится с 2.05.59.

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

+1 на «не обязательно связано с deconz, но скорее с сетью Zigbee или FW производителя» в корреляции со стандартной интерпретацией Zigbee в FW производителей.

Я только что обновился до 2.05.59, и после перезапуска deconz тот же свет больше не доступен. Нажатие 0 в графическом интерфейсе не возвращает его. Любой другой свет работает. В моем случае это может быть проблема самого света.

@ peer69 @ thomas70 Вы снова включили свет, поскольку это необходимо, упомянутое @manup в https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127?

Новая конфигурация будет применена после включения и выключения света.

Хороший намек, этого не делал. На данный момент мне пришлось вернуться к .58 по другой причине (высокая загрузка процессора делает шлюз невосприимчивым), попробую это позже сегодня с .59 снова и включите все индикаторы ikea.

У меня тоже такая проблема, случалось дважды для одного и того же светильника ГУ 10. В настоящее время работает версия 2.05.59, и я выключил и снова выключил свет после обновления.

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

После выключения питания мои лампочки IKEA вернулись. Но моя панель IKEA FLOALT WS все еще отключена

У меня такая же проблема, и я делаю это довольно долгое время, и я бы сказал, что .59 действительно усугубил ситуацию. У меня есть 80 узлов, из которых 32 - это огни и выключатели Trådfri, 5 - лампы Hue, а остальные - разные устройства Xiaomi с батарейным питанием, такие как температура, движение, детектор дыма и т. Д. Каждый тип устройства не отвечал хотя бы один раз, поэтому в моем случае это не только огни Trådfri, но в то время у меня просто проблемы с лампами Trådfri и Hue.

Дело в том, что раньше я пропустил все источники света через мост Hue, а датчики Xiaomi - через шлюз Xiaomi, и тогда все они были надежными, поэтому я не думаю, что в моем случае виновата прошивка устройства, если только это не вызвано изменение обстоятельств.

У меня есть шесть ламп Trådfri GU10 в одном месте, которые и раньше работали отлично, но после обновления до .59 и нескольких циклов включения питания они теперь почти полностью не отвечают, и мне, вероятно, придется их сбросить. Что странно, так это то, что эта невосприимчивость также кажется "движущейся" от разных источников света в зависимости от того, какие огни имеют мощность. Если я отключу питание некоторых из не отвечающих огней, это может занять некоторое время, а затем внезапно появится другой свет, который не хочет работать должным образом. Возможно, где-то есть какое-то смещение, которое ломает вещи?

Дело в том, что раньше я пропустил все источники света через мост Hue, а датчики Xiaomi - через шлюз Xiaomi, и тогда все они были надежными, поэтому я не думаю, что в моем случае виновата прошивка устройства, если только это не вызвано изменение обстоятельств.

Интересно, а в сети Hue тоже были все 32 светильника Ikea? Я спрашиваю, потому что мост Hue использует только опрос и не настраивает отчеты по атрибутам.

Были ли у вас также маршрутизаторы, такие как Hue или Ikea, в сети Xiaomi?

У меня есть шесть ламп Trådfri GU10 в одном месте, которые и раньше работали отлично, но после обновления до .59 и нескольких циклов включения питания они теперь почти полностью не отвечают, и мне, вероятно, придется их сбросить. Что странно, так это то, что эта невосприимчивость также кажется "движущейся" от разных источников света в зависимости от того, какие огни имеют мощность. Если я отключу питание некоторых из не отвечающих огней, это может занять некоторое время, а затем внезапно появится другой свет, который не хочет работать должным образом. Возможно, где-то есть какое-то смещение, которое ломает вещи?

Хм, это довольно плохо, мне действительно интересно, как это происходит, 2.05.59 намного «знаком» для светильников Ikea, чем предыдущие версии. Конфигурация теперь происходит так же, как и в шлюзе Ikea.

Когда индикатор перестает реагировать, вы можете выбрать узел в deCONZ и нажать 0 если он снова станет отзывчивым / желтым, индикатор не нужно выключать и выключать. Обратите внимание, что свет, превращающийся в зомби в этом случае, скоро будет исправлен, это может произойти в определенном сетевом созвездии в настоящее время.

Кстати обычные вопросы:

• Какую версию прошивки вы используете?
• RaspBee или ConBee?
• Если ConBee вы используете удлинитель usb?

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

Я перезагрузил сервер, а также выключил и снова включил каждый световой индикатор в сети, чтобы убедиться, что они загрузили последнюю конфигурацию, но, несмотря на это, потребовалось несколько часов, прежде чем проблема исчезла, поэтому я был немного преждевременным в своем предположении, что проблема осталась, так как она не сработала сразу.

Интересно, а в сети Hue тоже были все 32 светильника Ikea? Я спрашиваю, потому что мост Hue использует только опрос и не настраивает отчеты по атрибутам.

Да вроде как. У меня был 31 светильник Ikea в сети Hue, а также светильник Hue. 32-е устройство Ikea - это розетка выключателя, которую я тогда не купил.

Были ли у вас также маршрутизаторы, такие как Hue или Ikea, в сети Xiaomi?

Нет, только датчики с батарейным питанием

Когда индикатор перестает реагировать, вы можете выбрать узел в deCONZ и нажать 0 если он снова станет отзывчивым / желтым, индикатор не нужно выключать и выключать. Обратите внимание, что свет, превращающийся в зомби в этом случае, скоро будет исправлен, это может произойти в определенном сетевом созвездии в настоящее время.

Я пробовал это несколько раз раньше, но безрезультатно. Что касается оборудования и настроек, я использую ConBee с удлинительным кабелем USB и 262F0500. Поскольку мне кажется, что сейчас все работает нормально, эта информация может быть бесполезной в данный момент, но я постараюсь не делать поспешных выводов и дать сети поработать несколько дней, чтобы убедиться, что проблема не возникает. возвращение.

Я бегаю с 0,59 с прошлых выходных, и все еще теряю случайные огни Ikea. (16 лампочек Е27 на фасаде дома.)
Bulb FW такой же, как и другие, все еще на Ikea Gateway.
Использование ConBee с 262F0500 FW.
На прошлых выходных я также купил мост HUE и как раз собирался начать переставлять фары, когда заметил примечание к выпуску «Под капотом» для .59. Решил подождать, но еще раз рассмотрим предстоящие выходные.
Deconz по-прежнему будет моим лучшим контроллером Xiaomi / mi Cube. Еще не пропустил ни одного жеста.

Я бегаю с 0,59 с прошлых выходных, и все еще теряю случайные огни Ikea. (16 лампочек Е27 на фасаде дома.)
Bulb FW такой же, как и другие, все еще на Ikea Gateway.
Использование ConBee с 262F0500 FW.
На прошлых выходных я также купил мост HUE и как раз собирался начать переставлять фары, когда заметил примечание к выпуску «Под капотом» для .59. Решил подождать, но еще раз рассмотрим предстоящие выходные.
Deconz по-прежнему будет моим лучшим контроллером Xiaomi / mi Cube. Еще не пропустил ни одного жеста.

У меня здесь примерно такая же ситуация, 16 ламп IKEA, 2 контрольных выхода IKEA, вилка Heiman и вилка innr и некоторые датчики Xiaomi (куб / датчики двери / датчик движения). Никогда не было проблем с устройствами сторонних производителей. Однако в настоящее время у меня почти ежедневно возникают проблемы, когда свет IKEA выпадает из сети.

Я использую Conbee с USB-удлинителем на прошивке 0x26300500 и deCONZ .59

Мои фары уже некоторое время работают нормально, но пару дней назад моя лампочка Trådfri E14 внезапно перестала отвечать. Через один цикл питания он вернулся к жизни.

Сегодня пора было выпасть одному из GU10. Он физически очень близок к ранее упомянутой E14, поэтому я не уверен, совпадение это или нет. GU10 вполне мог пройти через E14, хотя все мои фары находятся в пределах досягаемости ConBee.

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

Через 12 дней другой GU10 станет недоступен и не сможет подключиться снова без выключения и включения питания.

Рад поделиться любой информацией, необходимой для решения этой проблемы.

То же самое, вчера после 6 дней безупречного подключения я потерял одну из своих лампочек Tradfri .. включение / выключение и сброс не помогли. Он все еще желтый в deConz, но не могу подключиться или контролировать его.

Тоже самое. После нескольких дней без каких-либо проблем сегодня две мои лампы GU10 Tradfri перестали отвечать. Я смог оживить один из них, нажав 0 в графическом интерфейсе, но мне пришлось включить Powercycle для другого.
К счастью, это происходит только с банкоматами устройств GU10, у моих панелей FLOALT еще не было проблем (в моей настройке они могут быть выключены только с помощью автоматического выключателя).

Для меня тоже проблема. Теперь у меня было еще 3-4 лампы GU10, теряющие связь, а также одна из моих Hue E27 и дверной датчик Xiaomi (магнит). Некоторые индикаторы снова начали работать после отключения питания, другие - нет. Нажатие 0 ничего не делает.

Также примечательно, что датчик Xiaomi снова начал работать после того, как я выключил и снова включил соседний и не отвечающий GU10, поэтому я полагаю, что датчик проходил через этот свет, но не должен ли он автоматически перенаправлять, если есть какие-либо проблемы с подключением?

Здесь та же проблема. Вчера обновился до последней версии .59, теперь пара лампочек Ikea не отвечает

Привет, не могли бы вы дать больше информации об общей сети, например о размере сети и других устройствах с питанием от сети?

Несколько дней назад я реорганизовал свою домашнюю сеть, теперь в нее входят:

• 5x IKEA WS GU10 (прошивка 1.2.221, код товара LED1537R6GU10EU)
  С MAC-адресом 0x000b57ff ..... (старый пакет)
• 2x IKEA с регулируемой яркостью E27 (прошивка 1.2.214)
• 1x IKEA E14 WS light (прошивка 1.2.221)
• 1x ретранслятор IKEA (прошивка 2.0.019)
• 1x розетка IKEA (прошивка 2.0.019)
• 1x OSRAM GU 10
• 1x цветная лампа OSRAM E27
• 1x разъем OSRAM
• 1x цветная лампа Hue E27
• 1x регулируемая лампа люкс Hue E27

deCONZ 2.05.59; Прошивка ConBee 0x26300500 (но 0x262f0500 тоже подойдет).

У меня есть 4x FLS-PP LP, но они сейчас отключены для тестирования, так как они действуют как очень сильные ретрансляторы сигнала.

С датчиками и переключателями общий размер сети составляет 55.
Все фонари всегда включены и до сих пор не показывают отключений.

Вот еще несколько подробных характеристик моей сети, если они могут быть вам полезны. Я все еще использую версию 2.05.59 с 262F0500 и удлинителем для ConBee. Как упоминалось выше, после первого обновления до версии 2.05.59 и включения и выключения питания каждого устройства с питанием от сети и ожидания в течение нескольких часов сеть была безупречной почти неделю, поэтому, похоже, потребуется некоторое время, пока проблемы не начнут появляться. К сожалению, проблема возникла снова, и полный цикл питания всех устройств с питанием от сети, а также перезагрузка deCONZ больше не решают проблему. Также кажется, что проблема блуждает от устройства к устройству, потому что иногда свет может не реагировать на какое-то время, а затем устраняется сам.

Ранее сегодня у меня была проблема, когда Trådfri E14 не отвечал, а также один Hue E27. После включения и выключения E27 E14 ожил, и я даже не прикоснулся к нему. То же самое и с невосприимчивыми GU10, которые, кажется, время от времени меняются местами, поэтому каждый день появляется как минимум два неотзывчивых GU10, но это не всегда одни и те же индикаторы, поэтому некоторые начинают работать, а другие ломаются, и наоборот.

Моя сеть в настоящее время состоит из следующих 80 устройств, включая ConBee, и устройства с питанием от сети получают питание 24/7.

Питание от сети

| Количество | Тип | Прошивка |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 с регулируемой яркостью | 1.2.214 |
| 4 | Trådfri GU10 белый спектр | 1.2.217 |
| 1 | Trådfri E14 опал с регулируемой яркостью | 1.2.217 |
| 1 | Регулирующая розетка Trådfri | 1.4.020 |
| 3 | Hue E27 Белый и цветной A19 | 1.29.0_r21169 |
| 2 | Hue E14 Белый цвет LTW012 | 1.29.0_r21169 |

Батарея заряжена

Количество | Тип | Прошивка
--------- | ------ | -----------
1 | Выключатель Trådfri | 1.4.018
10 | Мультисенсор Xiaomi Aqara (квадратная температура / гул / давление) | 20161129
3 | Датчик движения Xiaomi Aqara (движение / люкс) | 20170627
4 | Датчик воды Xiaomi Aqara | 20170721
1 | Датчик движения оттенка | 6.1.0.18912
11 | Контактный датчик Xiaomi Aqara | 20161128
8 | Датчик дыма Xiaomi / Honeywell | Нет данных

На прошлой неделе deconz, казалось, работал в основном нормально, но вчера у меня была другая лампочка IKEA (белый спектр), теряющая связь с deconz. Даже выключение и повторное включение не помогло. Пришлось перезапустить деконз, чтобы он как-то снова заработал.

У меня есть сеть в основном с лампами IKEA, розетка Heiman и довольно много датчиков Xiaomi.

Некоторые характеристики моей сети zigbee:

Прошивка Conbee 262F0500 с удлинителем на NUC.
deCONZ 2.05.55 в Docker, поэтому первое, что мне нужно сделать, это перейти на версию 2.05.59.

Работает (24/7)

| Количество | Тип | Прошивка |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 белый | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 белый | 1.2.214 |
| 21x | Tradfri GU10 с регулируемой яркостью | 1.2.214 |
| 3x | Osram Smart + розетка | 1.04.12 |

Батарея заряжена

| Количество | Тип | Прошивка |
| ------------- | ------------- | ------------- |
| 3x | Диммер Hue | 5.45.1.17846 |
| 1x | Умный переключатель Aqara | 20180525 |
| 1x | Умный переключатель Aqara | 20161128 |
| 1x | Двойной беспроводной переключатель Aqara | 20170411 |
| 1x | Пульт TRADFRI | 1.2.214 |
| 6x | Мультисенсор Aqara | 20161129 |
| 10x | Контактный датчик Aqara | 20161128 |
| 5x | Датчик движения Aqara | 20170627 |
| 1x | Датчик утечки Aqara | 20170721 |
| 1x | Датчик вибрации Aqara | 20180130 |

Есть какие-нибудь обновления для текущей версии? Я использую .60 уже 3 дня и ни один свет еще не потерял связь.

К сожалению, у меня уже пропало соединение с обычной белой лампочкой Tradfri E27 на .60 и последней прошивке.

Это плохие новости ... если я правильно понимаю, интервалы опроса были изменены в .60, чтобы они были менее агрессивными. Агрессивный опрос, приводящий к зависанию света, казался мне совершенно логичным, жаль, что это не кажется решением нашей проблемы.

Вчера я отключил питание всех устройств с питанием от сети и обновился до версий 2.05.60 и 26320500 перед их повторным включением, просто на всякий случай. Свет тогда работал нормально около 24 часов, но всего несколько минут назад я заметил, что один из моих GU10 перестал отвечать. К счастью, через несколько минут он снова ожил без какого-либо ручного вмешательства с моей стороны, так что, возможно, сеть была просто забита.

@ JBS5 Я бы рекомендовал обновить 4x Tradfri E27 white на 1.1.1.0-5.7.2.0 до последней версии прошивки. Если я правильно помню, это все еще самая первая версия.

@jurriaan в какой версии установлена ​​ваша белая лампа Tradfri E27?

Это плохие новости ... если я правильно понимаю, интервалы опроса были изменены в .60, чтобы они были менее агрессивными.

Да, в основном очень похоже на шлюз IKEA. Теперь единственное оставшееся отличие - это периодический запрос соседних таблиц (который используется для отображения линий ячеистой сети).

Это можно отключить, щелкнув значок CRE в deCONZ и сняв флажок «Маршрутизаторы и координатор».
Возможно, стоит попробовать.

На Reddit было сообщение, в котором упоминалось, что шлюз IKEA теоретически должен поддерживать до 100 устройств, но это не очень хорошо протестировано. Было бы интересно узнать, какой обычный размер сети тестирует команда IKEA.

https://www.reddit.com/r/tradfri/comments/96yiq4/google_home_losing_lamps_and_rooms/e4x1scz/?context=1

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

Новые версии шлюза будут поддерживать такое же количество устройств (официально 50). Вы можете добавить еще один шлюз в свою систему, если хотите удвоить его.

@ JBS5 Я бы рекомендовал обновить 4x Tradfri E27 white на 1.1.1.0-5.7.2.0 до последней версии прошивки. Если я правильно помню, это все еще самая первая версия.

Те лампочки E27 со старой прошивкой не выходили из строя последние 6 месяцев, а другие ...

Очень интересно, а как насчет Е27 версии 1.2.214?

Очень интересно, а как насчет Е27 версии 1.2.214?

Они теряли связь только один раз за последние месяцы.

Прошло несколько недель назад с тех пор, как последний GU10 потерял соединение, при этом я все еще использую deCONZ 2.05.55 и прошивку 262F0500 на Conbee.

У меня тоже такая проблема. Только узлы Икеа, (43, в основном фары). Я ничего не знаю о zigbee, но, поскольку я не видел упоминания о нем: моя сеть кажется более стабильной с отключенным OTAU. На днях я также изменил настройки сети на менее безопасные. Не могу вспомнить, какой именно, но после этого я не потерял ни одного света.

Через несколько дней без каких-либо проблем несколько GU10 перестали отвечать.
Другая проблема может быть не связана, но также потеряна связь с лампой Osram. Несмотря на то, что он все еще отображался в графическом интерфейсе и, казалось, был связан, я больше не мог его контролировать. Пришлось удалить свет и прочитать его, ему был присвоен другой номер света, но вскоре после добавления ему было восстановлено прежнее имя. Понятия не имею, что здесь происходит, но это немного больше обслуживания, чем я хотел бы видеть для моей установки.

@ peer69 ты тоже пробовал просто снова включить свет? Обычно сброс к заводским настройкам не требуется.
Вы на 2.05.60? Не могли бы вы также предоставить более подробную информацию о вашей сети, количестве светильников и устройств с питанием от сети?

@manup Я отключил свет. Несколько раз. После отключения питания им можно было управлять в течение примерно 10 секунд, но затем он снова перестал отвечать (красные индикаторы мигали в графическом интерфейсе).
Между тем, эта проблема возникла снова даже после сброса настроек, а также затронула другой индикатор OSRAM. На данный момент я избавился от двух единственных ламп OSRAM в своей сети и заменил их лампами оттенка. Я могу предложить несколько тестов с огнями ORSAM, но для этого мне понадобится время.

Я использую 2.05.60. В настоящее время к сети подключено 57 узлов, из которых 27 устройств питаются от сети. Я использую 13 ламп IKEA GU10, 1 панель IKEA FLOALT, 2 штекера IKEA E14, 3 штекера OSRAM Smart +, 3 лампы оттенка E14, 5 ламп оттенка E27, световую полосу 1 оттенка.

В последние дни мне также приходилось включать и выключать некоторые IKEA GU10, которые не реагировали. После цикла питания все возвращается в норму, и я не вижу закономерности. У меня есть лампы с несколькими GU10, и не более одного GU10 перестали отвечать одновременно, несмотря на то, что они всегда управляются как группа.

На данный момент я вернулся на круги своя. Теперь у меня регулярно бывает 2-3 источника света, которые не реагируют, но они переключаются между разными огнями, поэтому иногда они работают, а иногда нет, в зависимости от того, какие другие источники света включены. Проблема кажется каскадной, потому что, когда я физически выключаю некоторые источники света, отключая их питание, проблема переключается на другие источники света.

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

Как я отмечал ранее, все сработало нормально сразу после полного цикла питания, но через несколько дней свет снова начал не реагировать, и так уже пару недель. Когда это случилось в первый раз, когда гость случайно отключил E14 на несколько часов, я не уверен, что это совершенно не связано или неожиданные нарушения сетки зигби привели к тому, что маршрутизация сошла с ума. Учитывая, что, по-видимому, я не единственный, у кого есть эти проблемы, я думаю, что это могло быть просто совпадением.

Мне очень нравится концепция объединения всех моих устройств zigbee в одну сетку, но я почти нахожусь на том этапе, когда загружаю старые шлюзы Hue и Xiaomi и кладу ConBee в ящик, чего я действительно не хочу делать. по ряду других причин. Есть ли у кого-нибудь советы по дальнейшему устранению неполадок, которые могли бы помочь мне точно определить, что происходит, и как это решить?

Одно из моих пятен IKEA GU10 теперь тоже не отвечает.

В сниффере я вижу, что он все еще «жив» и отправляет сообщения NWK Link Status, но, очевидно, думает, что он один в сети (Link Status Count: 0).

Он не отвечает на одноадресные команды, но периодически отправляет отчет об атрибутах ZCL для идентификатора модели.

Обнюхивание с ~ 2 часов, не уверен, когда он перестал отвечать и связано ли это, но порядковый номер отчета ZCL низкий:

Я проведу еще несколько тестов и какое-то время не буду включать его.

Моя розетка Tradri и сегодня вела себя очень странно и работала в циклах перезагрузки, чего раньше не было.

Только что заметил, что второй IKEA GU10 также является прогулочным светодиодом, симптомы такие же, как и у другого.

Оба устройства не отвечают ни на одноадресный, ни на групповой, ни на запрос адреса ZCP nwk (нажатие 0).
Они отправляют пустые команды NWK Link Status.

Второй GU10 также отправлял запросы ZCL OTA Query Next Image.

Кажется, что ответа нет.

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

Было бы хорошо, если бы они реализовали что-то вроде простой проверки работоспособности, чтобы прошивка могла перезагружаться через некоторое время, если уровень Mac работает (команды принимаются), но слои nwk и aps молчат.

У меня тоже такая проблема, даже после обновления до 2.05.59. Сегодня один из трех моих уличных фонарей "пропал".
Его лампочки Tradfri освещают все три из них.

не по теме. Как ты находишь во всем этом свой свет? Lol. У меня аналогичная установка, и я подумал ... нет времени для этого

по аналогии я имею в виду + ​​- 50 устройств

+ - 50 вроде нормально. В одной из наших тестовых сетей есть +180 устройств с deCONZ на Raspberry Pi 1, это весело :)

Мы планируем добавить в deCONZ улучшенный фильтр / сортировку, чтобы упростить поиск устройств, в настоящее время это действительно громоздко при определенном количестве устройств.

Фары все еще прилипли.

Одно интересное наблюдение: я отключил родительский элемент датчика движения Philips Hue (Hue Lux), чтобы ему пришлось искать нового родителя. Датчик теперь пытается подключиться через один из застрявших фонарей IKEA GU10.

Лампочка отвечает командой «Выйти (с повторным присоединением)». Итак, он обработал запрос на повторное присоединение!

К сожалению, датчик движения Hue упрям ​​и пытается навсегда воссоединиться с застрявшим светом GU10, вместо этого ища лучшего родителя.

Однако интересным здесь является то, что застрявший свет IKEA действительно отвечает на запрос на повторное присоединение, возможно, он также обрабатывает запросы NWK Leave, которые могут быть основой обходного пути, чтобы снова вернуть свет в рабочее состояние.

Коррекция, датчик движения Hue не слишком упрямый; через несколько минут датчик выбрал другого рабочего родителя (хорошо).

Однако интересным здесь является то, что застрявший свет IKEA действительно отвечает на запрос на повторное присоединение, возможно, он также обрабатывает запросы NWK Leave, которые могут быть основой обходного пути, чтобы снова вернуть свет в рабочее состояние.

Я тестировал это, но, к сожалению, это не работает. Пока индикаторы находятся в зависшем состоянии, они не обрабатывают NWK Leave с запросом на повторное присоединение.

В настоящее время я могу только сделать вывод, что IKEA необходимо исправить либо основную проблему, связанную с зависанием света, либо реализовать какой-то сторожевой таймер + проверку работоспособности для слоев прошивки NWK / APS.

До сих пор неизвестно, что именно вызывает переход света в это состояние - широковещательный шторм, определенные команды, проблемы с маршрутизацией ...?

Я перешлю свои выводы и журналы анализатора в IKEA, надеюсь, они смогут использовать их, чтобы отследить проблему.

Итак, @manup , как лучше всего вернуться к

По мне, цикл питания света явно работает лучше всего

@manup Я думаю, что если вы не знаете, как
Кроме того, разве эти огни не основаны на стеке Ember? Возможно, есть группы поддержки или форумы, которые могут пролить свет (каламбур).

Что касается IKEA, реагируют ли они на подобные запросы о поддержке? Или нам следует объединиться, чтобы привлечь внимание?

По мне, цикл питания света явно работает лучше всего

Не так уж и много для меня ...
Перезапуск Conbee - единственное, что временно исправит это.
А потом та же, а то и чаще другая лампочка ИКЕА через некоторое время застревает ...
Всегда только один свет! Это так странно ... И раздражает ...: /

@manup Замечательно ! Спасибо, что изучили это!

Я также отправил эту ветку команде IKEA Tradfri через Reddit. Только что получил ответ от них, что они отправили информацию. Будем надеяться, что они смогут использовать это, чтобы улучшить свою прошивку или найти решение этой проблемы :)

Похоже, что в ближайшие дни выйдет новая прошивка для шлюза tradfri, которая особенно нацелена на поддержку HomeKit. Также может быть новая прошивка для лампочек.

@ peer69 Это последняя версия прошивки:

[
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/190579-ncp572b444.ebl.ota.ota.signed",
    "fw_build_version": 444,
    "fw_file_version_LSB": 444,
    "fw_file_version_MSB": 5720,
    "fw_filesize": 166270,
    "fw_hotfix_version": 2,
    "fw_image_type": 2,
    "fw_major_version": 5,
    "fw_manufacturer_id": 4476,
    "fw_minor_version": 7,
    "fw_type": 1
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 204222,
    "fw_image_type": 4353,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed",
    "fw_file_version_LSB": 1571,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 182078,
    "fw_image_type": 4549,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035514-TRADFRI-bulb-ws-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8705,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035534-TRADFRI-bulb-ws-gu10-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8707,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 209790,
    "fw_image_type": 16900,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/1004764-TRADFRI-bulb-cws-1.3.009.ota.ota.signed",
    "fw_file_version_LSB": 38258,
    "fw_file_version_MSB": 4864,
    "fw_filesize": 178366,
    "fw_image_type": 10241,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159495-TRADFRI-transformer-1.2.245.ota.ota.signed",
    "fw_file_version_LSB": 21874,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 181118,
    "fw_image_type": 16641,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 8706,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 168318,
    "fw_image_type": 8449,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159697-TRADFRI-driver-hp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16898,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159698-TRADFRI-driver-lp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16897,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed",
    "fw_file_version_LSB": 13683,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 159806,
    "fw_image_type": 4545,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159700-TRADFRI-motion-sensor-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 157822,
    "fw_image_type": 4548,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159701-TRADFRI-wireless-dimmer-1.2.248.ota.ota.signed",
    "fw_file_version_LSB": 34162,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 172926,
    "fw_image_type": 4546,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed",
    "fw_filesize": 698748,
    "fw_hotfix_version": 25,
    "fw_major_version": 1,
    "fw_minor_version": 8,
    "fw_req_hotfix_version": 26,
    "fw_req_major_version": 9,
    "fw_req_minor_version": 9,
    "fw_type": 0,
    "fw_update_prio": 5,
    "fw_weblink_relnote": "https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotesltd.html"
  }
]

Только обновления:

• 10005777-4.1-TRADFRI-control-output-2.0.022.ota.ota.signed
• 10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed
• 10032198-2.1-TRADFRI-шлюз-1.8.25.p.elf.sig.ota.signed
• 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed
• 159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed

Так что в основном сосредоточился на торговых точках / шлюзе.

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

Есть новости для тех, кто обновляет deCONZ и прошивку Conbee?

Пока 1 или 2 GU10 отключатся через 2-4 недели. Время от времени, но включение и выключение питания меня раздражает, потому что в некоторых местах у меня нет выключателя питания.

Только что обновил прошивку до 0x26330500, так что давайте посмотрим.

К сожалению, сегодня один из моих GU10 недоступен ..
Использование deCONZ 2.05.64 с прошивкой 26330500 на Conbee.

Я думаю, был сделан вывод, что это проблема с микропрограммным обеспечением лампы, поскольку мы видим точно такую ​​же проблему на мосту Philips HUE. Я заметил в приложении Trådfri в разделе «Примечания к выпуску» упоминание о лампе CT v2. Может, дело даже в ламповом HW?

У меня пока не было проблем с 2.05.65.

То же самое, я не сталкивался с этой проблемой несколько недель

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

Несколько дней назад отключились несколько ламп GU10 и E27. Только включение и выключение питания вернет их в рабочее состояние.

Может быть актуально: это произошло во время моего отпуска, когда свет не включался в течение дня или 10.

Прошивка 26330500 с deCONZ 2.05.64

Как насчет этой проблемы для тех, кто сказал, что у них не было никаких проблем в течение нескольких недель пару недель назад?

У меня все еще есть эта проблема. Иногда ни один из них не отключается, и внезапно GU10 отключается, а через несколько дней - еще один ..

Насколько я понимаю, для Tradfri GU10 все еще нет новой прошивки.

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

Групповые команды у меня тоже работают, но всего несколько раз. После этого свет горит или гаснет и больше не реагирует. Даже при использовании привязанного диммера Hue Dimmer.

Мне то же. Такое впечатление, что вопрос отложен, более чем решен.
Я также работал над проблемой использования групповых команд.

Кстати, я заметил, что некоторые источники света кажутся гораздо более восприимчивыми к этой проблеме. Вы это узнаете?

@djwlindenaar Трудно сказать, но я полагаю, что у половины из 25+ GU10, которые у меня были, никогда не было этой проблемы, и я уверен, что у некоторых проблема возникала несколько раз.

@ peer69 @djwlindenaar Команда группы продолжает работать? Сегодня GU10 отключился и даже не ответил на групповую команду в первый раз (групповая команда от deCONZ и привязанный Hue Dimmer).

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

Рано или поздно также и групповая команда терпела неудачу, и ей приходилось выключать свет.

Что вы имеете в виду со временем? Несколько часов или несколько дней?

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

Ждал около 2 дней, когда GU10 отключился ранее на этой неделе, но он не вернулся. Нужен был powercycle, GU10 совсем не грелся.

Теперь у меня есть одна лампа GU10, которая отключилась, но не возвращается в сеть после отключения питания. Также нажатие 0 в VNC не решает эту проблему.

Также групповая команда или привязанный переключатель Hue DImmer больше не может включать / выключать свет.

Начиная с прошлой ночи, у меня в коридоре 4 светильника ikea, которые гаснут через x времени по таймеру (Домашний помощник), теперь 1 из 4 огней продолжает гореть и не может быть выключен домашним помощником / Deconz. По словам Деконца, он не в сети и не возвращался в течение 7 часов. Попробую включить цикл питания и посмотреть, поможет ли это.

Не работает свет: лампа TRÅDFRI E27 opal 1000lm с версией 1.2.214
Фары рабочие: Лампа TRÅDFRI E27 opal 1000lm с версией 1.2.214
Прошивка: 26330500
Деконз: V2_05_69

Я считаю, что с лампами белого спектра Ikea Trafri GU10 проблема с оборудованием. Также в моей настройке (шлюз Ikea, подключенный через локальный API к Home Assistant) по крайней мере половина моих 17 лампочек отключается каждые пару дней. Единственное решение - выключить и снова включить лампочки.

Это может быть причиной, по которой Ikea выпустила новую версию оборудования, на которой работает другая версия прошивки (2. * вместо 1. *).

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

Не уверен, что такое гарантия, но планирую попросить замену новой версией.

Я считаю, что с лампами белого спектра Ikea Trafri GU10 проблема с оборудованием. Также в моей настройке (шлюз Ikea, подключенный через локальный API к Home Assistant) по крайней мере половина моих 17 лампочек отключается каждые пару дней. Единственное решение - выключить и снова включить лампочки.

Это может быть причиной, по которой Ikea выпустила новую версию оборудования, на которой работает другая версия прошивки (2. * вместо 1. *).

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

Не уверен, что такое гарантия, но планирую попросить замену новой версией.

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

Была такая же проблема с двумя IKEA GU 10 WW сегодня. Переключение питания не помогло. Это помогло включить цикл питания и перезапустить деконз. Может быть, проблема с таблицей соседей? Оба источника света находятся в группе из двух и всегда управляются как группа.

Какое совпадение, что это происходит на нескольких установках в наши дни ... Или происходит что-то еще?

@ peer69

Какую версию прошивки deCONZ и Conbee вы используете?

Я использую:
deCONZ V2_05_66
Прошивка 26330500

Такая же прошивка здесь. deCONZ Версия 2.05.69.

И еще один Tradfri GU10 теплый белый теряет связь ..

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

http://fw.test.ota.homesmart.ikea.net/feed/version_info.json

10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.023.ota.ota.signed 10035514-TRADFRI-bulb-ws-2.3.007.ota.ota.signed 10035534-TRADFRI-bulb-ws-gu10-2.3.007.ota.ota.signed 159695-TRADFRI-bulb-ws-1000lm-2.3.007.ota.ota.signed

@manup Это для ламп белого спектра GU10 и, наверное, для новой версии? https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

Возможно, для них можно использовать 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed . Я протестирую его на одном из моих регулируемых фонарей IKEA E27, надеюсь, в худшем случае произойдет сбой, но не сгорает :)

Я попытался назначить файл вручную, но лампочка не видит обновления (не запускается).

Просто «я тоже» по этому поводу. Весь мой дом - это Tradfri, и после перезагрузки моего сервера сегодня я потерял всю сеть в третий раз за столько дней. Переключение на велосипеде не имеет значения. У меня дома только Tradfri, так что мне не с чем сравнивать. У меня смесь белого цвета е27, цвета е27 и GU10. Единственное решение, которое я нашел, - это выполнить полную перезагрузку лампочек и начать все с нуля - к сожалению, это не рационально.

Прошивка Conbee: 264A0700
Легкая прошивка: 1.2.214

Рад помочь с любой диагностикой, но мне нужно вернуть большую часть моего дома к шлюзу Tradfri, чтобы моя семья могла включать и выключать свет. Я оставлю пару ламп в наличии.

Я только что придумал, может быть, интересное дополнение к этому выпуску.

Некоторые комнаты оснащены несколькими точками Tradfri GU10, а большинство комнат - переключателем Hue Dimmer Switch с прямой привязкой к GU10 в комнате, созданной путем добавления их в группу Hue Dimmer Switch в приложении Phoscon.

• Только GU10 с прямой привязкой к переключателю Hue Dimmer время от времени отключаются и нуждаются в цикле включения питания, чтобы снова подключиться к сети.
• GU10 без прямой привязки к Hue Dimmer Switch не отключаются.

Мне кажется, что это не так. До сих пор только Hue Bulbs казались довольно устойчивыми. Все виды устройств IKEA (GU10, E14, FLOALT Panel) и Osram (лампы, световые полосы и садовые столбы) вышли из строя. Особенно устройства Osram полностью выходят из строя, цикл включения питания ничего не делает. Их нужно снимать и ремонтировать, что является проблемой для этих устройств.

Я потратил несколько дней на размышления о замене всех своих устройств zigbee на устройства для моей слишком дорогой установки KNX после того, как несколько устройств вышли из строя, и миграция на карту Conbee II также не удалась, вероятно, из-за несколько поврежденного zll-db. Затем я применил радикальный подход и настроил все с нуля. Я сбросил шлюз и отремонтировал все устройства. Что касается устройств IKEA, это было намного проще, чем раньше. Раньше мне приходилось перемещать их ближе к шлюзу, несколько раз перезагружать, использовать сенсорную ссылку, чтобы заставить их реагировать - на этот раз ничего из этого. Я просто сбросил лампочки, и они без проблем соединились. Тем не менее, сделать это для 70 устройств было проблемой, а некоторые датчики xiaomi сделали это немного сложнее, чем вещи ikea. Но это уже заставляет меня думать, что теперь у меня может быть более стабильная сеть. Пока ничего не вышло, но я скажу вам, если это произойдет.

Прошло некоторое время с тех пор, как я обновил свой raspbee, у моей старой версии были проблемы с считыванием температуры света, поэтому я решил обновить прошивку до последней версии и последней версии deCONZ. Получилось всего 2 фары (OSRAM 73674). 1 индикатор (вероятно, случайный) теряет соединение через несколько минут с последней версией deCONZ, и мне приходится вручную выключать и снова включать. Единственная версия, которую я смог найти, которая могла считывать температуру и не теряла свет, была deconz-2.04.40-qt5.deb, которая очень старая, но подходит для моего основного использования.

В последнее время у меня тоже случается намного больше с однотонным IKEA GU10. Какая-то боль в заднице. Однако для меня узлы не становятся красными, а только серыми. Они будут реагировать на удаленные нажатия кнопок, но не через Phoscon или HA.

DeCONZ по-прежнему обновляет состояние света, когда вы управляете им с пульта дистанционного управления?

Обычно это происходит, когда deCONZ теряет путь к лампе. Лампа все еще находится в сети, может достигать шлюза и принимать широковещательные сообщения. Однако шлюз не может достичь света по одноадресной передаче. В качестве обходного пути вы можете использовать команды /groups вместо /lights , чтобы вместо этого deCONZ отправлял широковещательные рассылки.

Иногда (~ раз в неделю) у меня все еще возникает та же проблема с моим контроллером штор Xiaomi (который является маршрутизатором ZigBee). _Объявление устройства_ после выключения и включения питания устройства заставляет deCONZ заново запоминать маршрут.

Эти проблемы с маршрутизацией возникли в связи с поддержкой обнаружения маршрутизации, используемой Trådfri lights, поэтому версия 2.04.40 кажется правильной.

@ebaauw Когда свет становится недоступным, у меня работают групповые команды, но только в течение ограниченного времени. После этого свет горит или гаснет и больше не реагирует на групповые команды. Использование привязанного переключателя Hue Dimmer (привязка создается путем добавления источников света в созданную по умолчанию группу, когда Hue Dimmer Switch сопряжен в приложении Phoscon).

DeCONZ по-прежнему обновляет состояние света, когда вы управляете им с пульта дистанционного управления?

Обычно это происходит, когда deCONZ теряет путь к лампе. Лампа все еще находится в сети, может достигать шлюза и принимать широковещательные сообщения. Однако шлюз не может достичь света по одноадресной передаче. В качестве обходного пути вы можете использовать команды /groups вместо /lights , чтобы вместо этого deCONZ отправлял широковещательные рассылки.

Я проверю эти предложения в следующий раз. Но да, они обычно возвращаются, я отключаю электричество на пару минут. Кстати, я использую пульт ИКЕА "хоккейная шайба".

Иногда (~ раз в неделю) у меня все еще возникает та же проблема с моим контроллером штор Xiaomi (который является маршрутизатором ZigBee). _Объявление устройства_ после выключения и включения питания устройства заставляет deCONZ заново запоминать маршрут.

Эти проблемы с маршрутизацией возникли в связи с поддержкой обнаружения маршрутизации, используемой Trådfri lights, поэтому версия 2.04.40 кажется правильной.

Хм, я не знаю, это было так плохо для меня так долго. Я постоянно обновляю его.

Хм, я не знаю, это было так плохо для меня так долго.

Это временная проблема. Мне не удалось воспроизвести его по желанию, см. №849. Фактически, все мои правила управления освещением основаны на действиях /groups , поэтому я никогда не замечал этой проблемы, пока не получил контроллер шторки.

Когда свет становится недоступным, у меня работают групповые команды, но только в течение ограниченного времени. После этого свет горит или гаснет и больше не реагирует на групповые команды.

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

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

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

Как было опубликовано в нескольких ответах выше, большинство моих огней GU10 привязаны к переключателю Hue Dimmer (3-8 в комнате с собственным переключателем Hue Dimmer). Некоторых нет, и они уже несколько месяцев онлайн. Ни один из них не выходил из строя. Совпадение или нет .. Что ты думаешь об этом @ebaauw?

большинство моих ламп GU10 привязано к переключателю Hue Dimmer

Это кажется маловероятным. Вы создавали привязку в панели _Bind Dropbox_ в графическом интерфейсе deCONZ от переключателя диммера к свету?

Обратите внимание, что «привязка» в терминах ZigBee означает: создание записи в таблице привязки устройства к тому, на какой адрес ZigBee следует отправлять команды из привязанного кластера. Я думаю, что (клиентские!) Кластеры _OnOff_ и _Level Control_ вашего диммерного переключателя привязаны к группе (плагином deCONZ REST API). Эта группа указана в ресурсе ZHASwitch под config.group . Затем в эту группу был добавлен свет. Группы ZigBee больше похожи на многоадресные адреса, поэтому, вероятно, правильнее будет сказать, что свет подписался на сообщения этой группы.

Теоретически я предполагаю, что в легкой прошивке может быть ошибка, из-за которой она зависает при обработке команд, полученных через группу. Однако я не думаю, что это вероятно. Я бы посмотрел, насколько близко (сколько прыжков по сети ZigBee) индикаторы находятся к RaspBee / ConBee и / или все ли индикаторы имеют одинаковую версию оборудования и прошивки. IKEA, похоже, выпускает новые версии ZigBee 3.0 (ZHA) для всех своих устройств.

большинство моих ламп GU10 привязано к переключателю Hue Dimmer

Это кажется маловероятным. Вы создавали привязку в панели _Bind Dropbox_ в графическом интерфейсе deCONZ от переключателя диммера к свету?

Обратите внимание, что «привязка» в терминах ZigBee означает: создание записи в таблице привязки устройства к тому, на какой адрес ZigBee следует отправлять команды из привязанного кластера. Я думаю, что (клиентские!) Кластеры _OnOff_ и _Level Control_ вашего диммерного переключателя привязаны к группе (плагином deCONZ REST API). Эта группа указана в ресурсе ZHASwitch под config.group . Затем в эту группу был добавлен свет. Группы ZigBee больше похожи на многоадресные адреса, поэтому, вероятно, правильнее будет сказать, что свет подписался на сообщения этой группы.

Нет, я не создавал привязку в панели de _Bind Dropbox_ в графическом интерфейсе deCONZ.

Вы имеете в виду, что добавление источников света в эти группы в приложении Phoscon не создает привязку между пультом дистанционного управления и источниками света? Я так предположил, потому что переключение добавленных источников света с помощью соответствующего переключателя Hue Dimmer также возможно, когда мой док-контейнер deCONZ или весь NUC отключен.

Хорошо, теперь у меня не отвечает. Он был неактивен в bth deCONZ и Phoscon.

Он действительно реагировал на удаленные команды, а также на то, когда я перемещал ползунок в «групповой» режим в Phoscon,

DeCONZ по-прежнему обновляет состояние света, когда вы управляете им с пульта дистанционного управления?

Не сначала, так как он был затемнен.

Затем я попробовал «сбросить выбранный узел» в deCONZ, и затем он в течение нескольких минут больше не выделялся серым цветом, хотя в deCONZ больше не было переключателя кластера.

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

Через некоторое время он снова стал серым в Phoscon.

Затем я попытался отключить питание на несколько минут. Не помогло.

Сегодня вечером произошла интересная ситуация:

Один из теплых белых ламп GU10 от Tradfri снова отключился через несколько часов. Переключатель Hue Dimmer Switch, который привязан к 8 GU10, включая тот, который сейчас отключен, включает / выключает, согласно deconz, автономный GU10. Как ни странно, только этот.
Другие GU10 не реагируют на подключенный переключатель Hue Dimmer.

Переключение группы с остальным API включит / выключит все индикаторы, включая автономный GU10.

Когда GU10 раньше отключался, привязанный переключатель Hue Dimmer включает / выключает все источники света в группе, включая, согласно tot deconz, автономный GU10 (рано или поздно, согласно deconz, автономный GU10 также перестает прослушивать групповые команды или).

Может ли это быть полезно?

\ Edit: «Имя» этого автономного GU10 в deCONZ через VNC пусто.

При повторном заполнении он не устанавливается (никогда не делал этого здесь, обычно в приложении Phoscon):

Все еще желтые:

Нажатие «0» или «Сброс выбранного узла» не возвращает GU10 в оперативный режим.

Изменить 2 : Примерно через 24 часа после того, как GU10 перешел в автономный режим, GU10 больше не отвечает на привязанный переключатель Hue Dimmer, как описано ранее. Ни один из индикаторов GU10 в группе сейчас не отвечает. Узел в графическом интерфейсе deCONZ по-прежнему желтый, но имя отображается серым.
После включения и выключения автономного светильника GU10 все 8 источников света в группе, включая тот, который был отключен, снова реагируют на привязанный переключатель Hue Dimmer.

@manup Это поведение / ситуация совсем другие, чем раньше, может быть, это поможет найти причину?

Я только что придумал, может быть, интересное дополнение к этому выпуску.

Некоторые комнаты оснащены несколькими точками Tradfri GU10, а большинство комнат - переключателем Hue Dimmer Switch с прямой привязкой к GU10 в комнате, созданной путем добавления их в группу Hue Dimmer Switch в приложении Phoscon.

• Только GU10 с прямой привязкой к переключателю Hue Dimmer время от времени отключаются и нуждаются в цикле включения питания, чтобы снова подключиться к сети.
• GU10 без прямой привязки к Hue Dimmer Switch не отключаются.

К сожалению, один из моих Tradfri GU10 warmwhite без привязанного переключателя Hue Dimmer отключен со вчерашнего дня.

Все еще не понимаю, почему несколько точек GU10 (такие же теплые белые) _ никогда_ не в сети.
\ Edit : Также GU10, который был в сети несколько месяцев, отключен со вчерашнего дня.

На прошлых выходных купил Tradfri Hub и соединил с ним все точки GU10 в одной комнате. Посмотрим, что будет в ближайшие недели ..

Случайные огни в моей системе начали не реагировать после того, как я добавил в свою систему четыре переключателя включения / выключения IKEA (для рождественских оконных огней) ... Розетки распределены по всему дому. По крайней мере, один из моих источников света в моей системе должен отключаться и выключаться ежедневно.

Могу ли я предоставить какие-либо журналы или информацию, чтобы облегчить устранение неполадок?

@tubalainen Что вы имеете в виду под невосприимчивостью? Участвуют ли они сами в том, нужен ли им цикл питания?

@tubalainen Что вы имеете в виду под невосприимчивостью? Участвуют ли они сами в том, нужен ли им цикл питания?

Они перечислены как «онлайн» (не выделены серым цветом) и являются частью меша, согласно моему изображению, но при переключении в Home Assistant (или через фоскон) ничего не происходит. Чтобы они снова заработали, мне нужно включить цикл питания.

Есть ли в этом прогресс? Становится немного смешно, когда свет на моем GU10 становится серым :(

Кажется, я видел, как кто-то упомянул контроллер шторки или переключатель включения / выключения. Мне действительно кажется, что проблемы стали намного хуже примерно в то время, когда я получил жалюзи FYRTUR. Это также была первая кнопка ikea, которую я добавил в сеть ... Не знаю ...

У меня нет настенных выключателей Tradfri или штор IKEA, и у меня есть проблема.

У меня была эта проблема летом. Мои GU10 все время выпадали. Я обновил все свои GU10 до последней «тестовой» программы и работал без проблем почти два месяца.

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

У меня была эта проблема летом. Мои GU10 все время выпадали. Я обновил все свои GU10 до последней «тестовой» программы и работал без проблем почти два месяца.

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

Какие лампочки GU10 у вас стоят и какую прошивку ставили?

На прошлых выходных купил Tradfri Hub и соединил с ним все точки GU10 в одной комнате. Посмотрим, что будет в ближайшие недели ..

Когда я использовал шлюз Tradfri, у меня почти каждый день не отвечали лампочки (Tradfri GU10 белого спектра, первое поколение). Я переключился на мост Philips Hue, и проблема, казалось, исчезла, но через 2 недели одна лампочка перестала отвечать (как обычно, цикл питания решил проблему).

Не знаю, почему и как мост Hue лучше работает с лампами Tradfri, но мне кажется, что настоящая проблема связана с лампами.

У меня нет ни одного GU10, и проблема все еще возникает.

Пожалуйста, скажите мне, как я могу помочь с журналами и т. Д., Чтобы попытаться решить эту проблему.
Кажется легким (здесь я предполагаю), что некоторые узлы "засыпают" и не просыпаются при первой попытке их разбудить?

Это проблема, только когда в сетке есть несколько узловых переходов? Для меня это вполне закономерно, когда к конби приходится более одного прыжка. Опять же, просто ощущение. Не подтверждено.

У меня 8 ГУ-10 около 18 месяцев. Один из них однажды поседел. Все они находятся в той же комнате, что и колбаса. У меня есть 3-х летние лампы 980 лм. Тот, кто дальше всех прыгает через gu 10, становится серым, может быть, раз в две недели.
@tubalainen может быть на чем-то.

Рядом с тем, что поседел, у меня есть Osram, который никогда не выходил из строя.

Да, @tubalainen может дать ключ к разгадке. На самом деле я вставлял свои серые GU10 в гнездо для лампы на шнуре, который использую при добавлении новых источников света, и когда они в нем, они много раз просто оживали. Но потом, когда я поставил их на место, они снова исчезли. То, что они возвращаются, не соответствует 100%, но все же может быть их сообщником.

Вот еще одна потенциальная подсказка. У меня никогда не было ни одной лампы, которая никогда не становилась серой (за более чем год работы с 8 лампами IKEA), но затем я обновил плагин Deconz Home Assistant с 3.8 до 3.9, и через два дня у меня два GU10 стали серыми, я восстановил резервную копию 3.8 версии плагина, и с тех пор проблем не было. Странно то, что плагин 3.8 и 3.9 использует одну и ту же версию deconz (если журнал изменений полный). Но даже в Phoscon лампы были недоступны. Все это довольно странно, но я предполагаю, что версия плагина 3.9 делает какой-то запрос на деконзирование, что делает лампы IKEA нестабильными.

Я не использую HA и все еще страдаю этой проблемой. Я купил новый GU10 и теперь заменяю каждую лампу, которая становится серой более одного раза. Ни одна лампа, которую я заменил, не стала снова серой. Может быть проблема с оборудованием, может и нет, но похоже, что в ближайшее время у нас не будет решения.

У меня похожие проблемы. Некоторые светлые узлы не реагируют на команды и становятся серыми. Странно то, что если я отправляю групповые команды, один и тот же световой узел каждый раз отлично реагирует.

У меня похожие проблемы. Некоторые светлые узлы не реагируют на команды и становятся серыми. Странно то, что если я отправляю групповые команды, один и тот же световой узел каждый раз отлично реагирует.

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

У меня похожие проблемы. Некоторые светлые узлы не реагируют на команды и становятся серыми. Странно то, что если я отправляю групповые команды, один и тот же световой узел каждый раз отлично реагирует.

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

Да, похоже, со временем тоже работает нормально. Но у меня есть теория, в чем дело. Когда световые узлы проходят через лампу TRADFRI E27 WS opal 1000lm, возникают проблемы. Итак, вчера я отключил два, которые были у меня в сети. С тех пор вроде все работает отлично.

У меня есть лампа TRADFRI GU10 WS 400 лм, лампа TRADFRI E14 CWS opal 600 лм и лампа TRÅDFRI E27 CWS opal 600 лм. Кажется, они не доставляют проблем.

Это могло быть связано со старой прошивкой Trådfri. Более свежие светильники поставляются с более новой прошивкой, но я не думаю, что IKEA опубликовала обновленную прошивку для всех светильников первого поколения. У меня нет спотов Trådfri GU10, но лампочка CWS получила обновление прошивки. Моя лампа с регулируемой яркостью 1000 лм - нет; Я не уверен насчет лампочки белого спектра.

Это могло быть связано со старой прошивкой Trådfri. Более свежие светильники поставляются с более новой прошивкой, но я не думаю, что IKEA опубликовала обновленную прошивку для всех светильников первого поколения. У меня нет спотов Trådfri GU10, но лампочка CWS получила обновление прошивки. Моя лампа с регулируемой яркостью 1000 лм - нет; Я не уверен насчет лампочки белого спектра.

Моя лампочка TRADFRI GU10 WS 400lm стоит на той же прошивке, 2.0.022. Кажется, они не вызывают проблем (пока :))

Это могло быть связано со старой прошивкой Trådfri. Более свежие светильники поставляются с более новой прошивкой, но я не думаю, что IKEA опубликовала обновленную прошивку для всех светильников первого поколения. У меня нет спотов Trådfri GU10, но лампочка CWS получила обновление прошивки. Моя лампа с регулируемой яркостью 1000 лм - нет; Я не уверен насчет лампочки белого спектра.

Я согласен. В первой версии ламп Ikea (на прошивке 1. *) была некоторая программная / аппаратная ошибка, не влияющая на вторые итерации (на 2. *).

К сожалению, похоже, что Ikea больше не поддерживает исходную версию и не будет предоставлять никаких обновлений прошивки. При этом невозможно вернуть лампочки и поменять их на новые (пробовал, в Великобритании).

Это могло быть связано со старой прошивкой Trådfri. Более свежие светильники поставляются с более новой прошивкой, но я не думаю, что IKEA опубликовала обновленную прошивку для всех светильников первого поколения. У меня нет спотов Trådfri GU10, но лампочка CWS получила обновление прошивки. Моя лампа с регулируемой яркостью 1000 лм - нет; Я не уверен насчет лампочки белого спектра.

Я согласен. В первой версии ламп Ikea (на прошивке 1. *) была некоторая программная / аппаратная ошибка, не влияющая на вторые итерации (на 2. *).

К сожалению, похоже, что Ikea больше не поддерживает исходную версию и не будет предоставлять никаких обновлений прошивки. При этом невозможно вернуть лампочки и поменять их на новые (пробовал, в Великобритании).

У меня лампочки cws на 1.3.009. Кажется, они не вызывают проблем.

Обновить:

Похоже, проблемы возникают и с другими лампами ИКЕА.

Вот мои лампочки ИКЕА. Пока что проблемы вызывает только лампа TRADFRI E27 WS opal 1000lm. Теперь они отключены, и все вроде работает. Но я отправляю обновление, если получаю новые ошибки.

Похоже, у меня нет устройств 2.x.
Некоторые GU10 работают нормально, некоторые нет. Я начал заменять неисправные на «новые», которые купил через несколько месяцев. Кажется, что они используют одну и ту же прошивку, хотя на сокете напечатан номер «1808-S», а на «более новых» - «1729-S».
Я заменил 3 лампы, и в течение 2 недель никаких новых проблем не возникало. У меня была проблема не только с GU10, но и с панелью FLOALT, которую я не заменял.

Похоже, у меня нет устройств 2.x. Некоторые GU10 работают нормально, некоторые нет. Я начал заменять неисправные на «новые», которые купил через несколько месяцев. Кажется, что они используют одну и ту же прошивку, хотя на сокете напечатан номер «1808-S», а на «более новых» - «1729-S». Я заменил 3 лампы, и в течение 2 недель никаких новых проблем не возникало. У меня была проблема не только с GU10, но и с панелью FLOALT, которую я не заменял.

Интересно! Я посмотрю на свои лампочки, чтобы увидеть, есть ли какая-то корреляция.

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

У меня есть лампа TRADFRI GU10 WS 400 лм, лампа TRADFRI E14 CWS opal 600 лм и лампа TRÅDFRI E27 CWS opal 600 лм. Кажется, они не доставляют проблем.

Похоже, что после того, как сетка проработала какое-то время, даже другие устройства IKEA вызывают проблемы, и узлы перестают отвечать на команды. Могут быть затронуты даже другие узлы IKEA, мне кажется, что проблемы начинают появляться, когда узлы маршрутизируются через узел IKEA.

Планируются ли какие-нибудь мероприятия по этому поводу? Я переставлю все свои устройства IKEA на свой шлюз оттенков, пока проблема будет решена.

узлы перестают отвечать на команды.

Вы уверены, что это так? Вы подтвердили это, проанализировав трафик ZigBee? Другие узлы больше не реагируют на беспроводные переключатели, которые управляют светом, не проходя через шлюз? Они больше не реагируют на групповые команды?
По моему опыту, проблема в том, что шлюз больше не знает маршрута к другим узлам, поэтому одноадресные команды от шлюза никогда не достигают других узлов. Сами узлы реагируют нормально, им просто не на что отвечать.

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

(Не?) Узел маршрутизации IKEA каким-то образом прерывает маршрут от шлюза и / или обнаружение маршрута к другим узлам.

Планируются ли какие-нибудь мероприятия по этому поводу?

Вам придется обратиться в службу поддержки dresden elektronik. Маршрутизация обрабатывается прошивкой RaspBee / ConBee (и базовой программой deCONZ?). Мы ничего не можем с этим поделать в плагине REST API.

На прошлых выходных купил Tradfri Hub и соединил с ним все точки GU10 в одной комнате. Посмотрим, что будет в ближайшие недели ..

Возможно, еще рано говорить, но 29 дней назад я переместил все Tradfri GU10 (8x теплый белый - 1.2.214) из одной комнаты в Tradfri Hub, и ни один из них не перестал отвечать до сих пор.

Возможно, еще рано говорить, но 29 дней назад я переместил все Tradfri GU10 (8x теплый белый - 1.2.214) из одной комнаты в Tradfri Hub, и ни один из них не перестал отвечать до сих пор.

Я ожидал этого. Проблема вызвана не столько устройствами от одного производителя, сколько взаимодействием между устройствами разных производителей, по-разному интерпретирующими стандарт ZigBee. Вот почему большинство концентраторов / шлюзов / мостов поддерживают только свои собственные устройства. Более интересным экспериментом было бы соединение точек Trådfri с мостом Hue или шлюзом OSRAM.

Кроме того, восемь источников света в одной комнате, вероятно, приведут к прямому соединению между концентратором и каждым индикатором: все соединения с одним переходом. Проблемы с маршрутизацией возникают только в более крупных сетях, где устройств больше, чем записей в таблице соседей (обычно около 20); и / или с устройствами, физически вне досягаемости от концентратора.

узлы перестают отвечать на команды.

Вы уверены, что это так? Вы подтвердили это, проанализировав трафик ZigBee? Другие узлы больше не реагируют на беспроводные переключатели, которые управляют светом, не проходя через шлюз? Они больше не реагируют на групповые команды?
По моему опыту, проблема в том, что шлюз больше не знает маршрута к другим узлам, поэтому одноадресные команды от шлюза никогда не достигают других узлов. Сами узлы реагируют нормально, им просто не на что отвечать.

У меня нет опыта или оборудования, чтобы отслеживать трафик. Вы, вероятно, правы относительно того, как ведет себя проблема. Мои узлы все время реагируют на групповые команды. Проблема в том (если я понимаю), что одноадресные команды никогда не достигают места назначения.

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

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

(Не?) Узел маршрутизации IKEA каким-то образом прерывает маршрут от шлюза и / или обнаружение маршрута к другим узлам.

Планируются ли какие-нибудь мероприятия по этому поводу?

Вам придется обратиться в службу поддержки dresden elektronik. Маршрутизация обрабатывается прошивкой RaspBee / ConBee (и базовой программой deCONZ?). Мы ничего не можем с этим поделать в плагине REST API.

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

Возможно, еще рано говорить, но 29 дней назад я переместил все Tradfri GU10 (8x теплый белый - 1.2.214) из одной комнаты в Tradfri Hub, и ни один из них не перестал отвечать до сих пор.

Я ожидал этого. Проблема вызвана не столько устройствами от одного производителя, сколько взаимодействием между устройствами разных производителей, по-разному интерпретирующими стандарт ZigBee. Вот почему большинство концентраторов / шлюзов / мостов поддерживают только свои собственные устройства. Более интересным экспериментом было бы соединение точек Trådfri с мостом Hue или шлюзом OSRAM.

Кроме того, восемь источников света в одной комнате, вероятно, приведут к прямому соединению между концентратором и каждым индикатором: все соединения с одним переходом. Проблемы с маршрутизацией возникают только в более крупных сетях, где устройств больше, чем записей в таблице соседей (обычно около 20); и / или с устройствами, физически вне досягаемости от концентратора.

Я сделал это, чтобы убедиться, что это не связано с прошивкой 1.2.214 старого GU10, которая часто упоминается здесь как возможная причина (и возможная причина для создания новой версии GU10).
Может в связи с подключением через другой роутер.

Я также рассмотрю возможность подключения других моих ламп GU10 (также теплого белого цвета 1.2.214) к Tradfri Hub (также на 2de / 3-м этаже).

Есть ли в этом прогресс? Становится немного смешно, когда свет на моем GU10 становится серым :(

Кажется, я видел, как кто-то упомянул контроллер шторки или переключатель включения / выключения. Мне действительно кажется, что проблемы стали намного хуже примерно в то время, когда я получил жалюзи FYRTUR. Это также была первая кнопка ikea, которую я добавил в сеть ... Не знаю ...

У меня не было переключателя включения / выключения фыртура в сети с момента моего последнего поста, и за это время ни одного выпадающего. Может быть совпадение ...?

Есть ли в этом прогресс? Становится немного смешно, когда свет на моем GU10 становится серым :(
Кажется, я видел, как кто-то упомянул контроллер шторки или переключатель включения / выключения. Мне действительно кажется, что проблемы стали намного хуже примерно в то время, когда я получил жалюзи FYRTUR. Это также была первая кнопка ikea, которую я добавил в сеть ... Не знаю ...

У меня не было переключателя включения / выключения фыртура в сети с момента моего последнего поста, и за это время ни одного выпадающего. Может быть совпадение ...?

Нет, у меня нет шторок Tradfri on / off или Tradfri, и у меня есть эта проблема.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

Случайно закрыл этот вопрос. Повторное открытие.

Более интересным экспериментом было бы соединение точек Trådfri с мостом Hue или шлюзом OSRAM.

У меня была такая же проблема с лампами Trådfri (первое поколение), подключенными к концентратору Trådfri. Проблема полностью исчезла, когда я переставил все лампочки на мост Hue.

Кстати - я все еще убежден, что первое поколение ламп Trådfri содержит жучки, но мост Hue по-другому обрабатывает свет (я заметил, что иногда свет выходит из синхронизации на долю секунды при подключении к Hue - никогда не случалось с Trådfri. ).

мост Hue по-другому обрабатывает свет (я заметил, что иногда свет выходит из синхронизации на долю секунды при подключении к Hue - никогда не случалось с Trådfri).

В настройке Hue светом всегда управляет только мост Hue: беспроводные переключатели и датчики отправляют уведомления на мост, вызывая правила, управляющие светом. Мост прогнозирует состояние освещения и обновляет свой кеш заранее при отправке команд на источники света. Он периодически опрашивает индикаторы для проверки / обновления кэшированного состояния.

В системе Trådfri управление освещением осуществляется напрямую командами беспроводных переключателей и датчиков. Затем индикаторы отправляют на концентратор отчет с обновленным состоянием.

При управлении освещением, подключенным к мосту Hue напрямую с беспроводных переключателей или датчиков (Trådfri), вы увидите задержку, потому что мост Hue не настраивает атрибут, сообщающий об источниках света. Чем больше индикаторов в вашей сети, тем дольше задержка, так как опрос проходит через большее количество индикаторов.

При подключении ламп Hue к концентратору Trådfri и управлении этими источниками света непосредственно с беспроводных переключателей или датчиков (Trådfri) состояние концентратора никогда не будет обновляться, поскольку световые индикаторы Hue не отправляют отчеты об атрибутах, а концентратор Trådfri не выполняет опрос.

Обратите внимание, что эти различия проявляются на уровне приложения и находятся под контролем плагина REST API. Маршрутизация находится на более низком уровне в стеке ZigBee.

Теперь все мои узлы маршрутизатора IKEA перемещены на мой мост оттенков. У меня все еще такая же проблема в моей сети. Так что я подозреваю, что причиной этого является что-то еще. И снова это влияет на узлы, которые маршрутизируются и не имеют прямой связи со шлюзом.

Теперь все мои узлы маршрутизатора IKEA перемещены на мой мост оттенков. У меня все еще такая же проблема в моей сети. Так что я подозреваю, что причиной этого является что-то еще. И снова это влияет на узлы, которые маршрутизируются и не имеют прямой связи со шлюзом.

Та же проблема с огнями Tradfri, которые теперь подключены к мосту Hue?

@ebaauw должна ли проблема с маршрутизацией возникать, когда источник света подключен к мосту напрямую И через маршрутизатор, или только когда он не подключен напрямую к мосту?

Теперь все мои узлы маршрутизатора IKEA перемещены на мой мост оттенков. У меня все еще такая же проблема в моей сети. Так что я подозреваю, что причиной этого является что-то еще. И снова это влияет на узлы, которые маршрутизируются и не имеют прямой связи со шлюзом.

Та же проблема с огнями Tradfri, которые теперь подключены к мосту Hue?

У меня всего 3 парные лампочки. Но никаких проблем, которые я не заметил.

@ebaauw должна ли проблема с маршрутизацией возникать, когда источник света подключен к мосту напрямую И через маршрутизатор, или только когда он не подключен напрямую к мосту?

В моей сети мой опыт заключается в том, что проблемы с потерянными командами влияют на узлы, которые маршрутизируются через другие узлы, а не напрямую со шлюзом. У меня такие же проблемы сейчас, даже когда к лампам не подключены ИКЕА.

У меня был один узел (1) без прямой связи со шлюзом. Он не отвечал (или, как упоминалось в ebaauw, возможно, они никогда не достигают узла из-за проблем с маршрутизацией) на одноадресные команды. Когда я выключил узел (2), он был направлен через узел (1), действительно получил прямой маршрут к шлюзу и начал работать идеально.

должна ли проблема с маршрутизацией возникать, когда светильник подключен к мосту напрямую И через маршрутизатор, или только когда он не подключен напрямую к мосту?

В ZigBee нет такого понятия, как «связи». Каждый маршрутизатор ведет таблицу соседей соседних устройств, к которой можно подключиться напрямую (на уровне MAC). Строки в графическом интерфейсе пользователя deCONZ являются не чем иным, как графическим представлением этих соседних таблиц (поскольку deCONZ фактически их прочитал).

Когда маршрутизатору необходимо отправить сообщение устройству, которого нет в его таблице соседей, он отправляет запрос на соседний маршрутизатор, чтобы они могли его переслать. Одиночное сообщение на уровне NWK повторно передается через несколько переходов на уровне MAC. RaspBee / ConBee (с этой точки зрения) - это просто еще один маршрутизатор. Afaik конечное устройство отправляет сообщения только своему родительскому маршрутизатору.

Поэтому, когда индикатор находится в таблице соседей RaspBee / ConBee, обнаружение маршрута не происходит, независимо от того, является ли этот индикатор таблицей соседей других маршрутизаторов. Когда это не так, RaspBee / ConBee должен выяснить, какой соседний маршрутизатор знает, как добраться до источника света. Если источник света находится на расстоянии нескольких переходов, каждый маршрутизатор на пути к нему рекурсивно должен делать то же самое.

Боюсь, что подробности для меня потеряны, но есть несколько способов найти этот маршрут. Когда маршрутизаторы на пути между шлюзом и лампой используют разные способы, что-то может пойти не так. Шлюз может в конечном итоге отправить сообщение не тому соседнему маршрутизатору (который не знает, как добраться до источника света), или шлюз может вообще не знать, как добраться до источника света, и вообще не будет отправлять никакого сообщения. На одноадресные сообщения обычно следует отвечать ACK, поэтому шлюз будет отмечать устройство как недоступное, если оно не получает ACK. Конечно, нет никакого способа узнать, было ли потеряно исходное сообщение или ACT (удаленному устройству необходимо знать маршрут к шлюзу для отправки ACK).

Широковещательные сообщения (используемые командами групп) не используют никакой маршрутизации; они просто повторно транслируются на уровне MAC всеми маршрутизаторами. Хотя они очень надежны, они потребляют большую часть пропускной способности сети. Кроме того, они не отвечают ACK.

В моей сети мой опыт заключается в том, что проблемы с потерянными командами влияют на узлы, которые маршрутизируются через другие узлы, а не напрямую со шлюзом. У меня такие же проблемы сейчас, даже когда к лампам не подключены ИКЕА.

Поэтому для решения проблем с маршрутизацией вам нужна сеть, достаточно большая, чтобы устройства не отображались в таблице маршрутизации RaspBee / ConBee. Либо из-за того, что количество устройств превышает размер таблицы маршрутизации, либо потому, что удаленные устройства физически находятся вне зоны действия RaspBee / ConBee и могут быть доступны только через другие маршрутизаторы. Я полагаю, что несколько прыжков усугубят проблему.

Опять же, это не столько вина IKEA, сколько то, что разные производители используют разные, несколько несовместимые способы обнаружения маршрутов. В прошивке RaspBee / ConBee можно обойти очень многое, особенно в случае маршрутов с несколькими переходами.

У меня был один узел (1) без прямой связи со шлюзом. Он не отвечал (или, как упоминалось в ebaauw, возможно, они никогда не достигают узла из-за проблем с маршрутизацией) на одноадресные команды. Когда я выключил узел (2), он был направлен через узел (1), действительно получил прямой маршрут к шлюзу и начал работать идеально.

Опять же, я боюсь, что детали для меня упускаются, но я могу придумать несколько сценариев, которые могли бы вызвать такое поведение. RaspBee / ConBee хочет отправить сообщение на node2 или node1, не получает подтверждение, делает вывод, что node2 недоступен, и удаляет его из своей таблицы соседей. В таблице теперь есть место для новой записи, которая используется для узла 1.

Опять же, это не столько вина IKEA, сколько то, что разные производители используют разные, несколько несовместимые способы обнаружения маршрутов. В прошивке RaspBee / ConBee можно обойти очень многое, особенно в случае маршрутов с несколькими переходами.

Для меня это звучит так, как будто подход платформы ZigBee от разных производителей обречен на дизайн до тех пор, пока не будет установлен и соблюден более тщательный стандарт. Тем не менее, я как бы заблокирован прямо сейчас, поскольку я не хочу использовать несколько шлюзов, которые, вероятно, в любом случае не будут работать в моей среде (например, для датчиков, которые не могут быть доступны напрямую через шлюз, если я удалю лампочки, которые в настоящее время работают. как роутеры).

Для меня это звучит так, будто подход многопрофильной платформы ZigBee обречен.

Я, конечно, надеюсь, что нет, но это определенно сложно. Размер здесь, кажется, имеет значение: если ваша сеть достаточно мала, вы можете вообще не столкнуться с этими проблемами маршрутизации. Кроме того, если (географический) центр вашей сети состоит из маршрутизаторов от совместимых поставщиков, некоторые менее совместимые маршрутизаторы на границе вашей сети, вероятно, не будут иметь значения (поскольку они не маршрутизируются для доступа к другим устройствам).

Я заменил свои лампы OSRAM, Trådfri и innr (которые вызывали проблемы) на лампы Hue. Теперь у меня 104 узла, 51 маршрутизатор и 53 конечных устройства. 2/3 роутера - это световые индикаторы Hue. Единственный маршрутизатор, который становится недоступным (но все еще отправляет отчеты), - это контроллер шторки Xiaomi. 20 конечных устройств - это Hue, 20 Xiaomi, 8 Eurotronic Spirit и 5 IKEA. Eurotronic Spirit и IKEA Fyrtur регулярно вызывают у меня проблемы (их выгоняет их родитель, но они не находят нового родителя - снова недоступны для шлюза, но все еще отправляют отчеты), остальные кажутся в порядке. Для всех устройств включение и выключение питания обычно исправляет ситуацию, но иногда мне нужно открыть сеть при выключении и выключении питания устройства.

Я подумывал о разделении моей сети не по продавцу, а по этажам или улице, а не задней стороне дома. Это большая работа, и я не хочу этого делать, пока я не буду лучше разбираться в том, что вызывает проблемы в деталях и какие настройки могут предотвратить их появление.

@ebaauw , подумав о том, что вы сказали в посте выше, было бы интересно рассмотреть своего рода предпочтение для таблицы маршрутизации deCONZ. Можно ли включить маршрутизаторы в «черный список», которые не являются предпочтительными в качестве первого перехода. Если вы можете построить свою сеть так, чтобы она содержала достаточное количество «хороших» маршрутизаторов, чтобы первый переход всегда проходил через них, а второй переход достигал всех других устройств в сети.
Это не будет окончательным решением, но позволит использовать гораздо более крупные (географические и количество устройств) сети, всегда используя «предпочтительные» маршрутизаторы.

Еще одна мысль: поскольку мы знаем, какие чипы используются IKEA (Silabs EFR32, движок gecko), и мы знаем (из различных источников в сети), что они используют движок zigbee, предоставленный Silabs, мы могли бы рассмотреть два действия.

1. Мы анализируем, как движок silabs выполняет маршрутизацию, и на основании этого выясняем, что вызывает эту проблему.
2. Мы создаем специальную версию прошивки лампы на основе того же движка silabs, исправляем проблему и выясняем способ OTA-установки этой прошивки.

Для обоих потребуется доступ к Silabs SDK, чего у меня нет. Есть здесь кто-нибудь активный, кто занимается ..? Я не собираюсь выкладывать 500 долларов на их комплект разработчика, который включает SDK. Может быть, Dresden Electronics готова на это?

мои 2 cts (меня очень расстраивают иногда теряемые соединения).

Можно ли включить маршрутизаторы в «черный список», которые не являются предпочтительными в качестве первого перехода.

Мы не. Полагаю, это должно быть реализовано в прошивке RaspBee / ConBee. Неплохая идея, imho, но я понятия не имею, насколько это возможно, учитывая ограничения по размеру в EEPROM и NVRAM устройства. @manup , что ты об этом думаешь?

1. Мы создаем специальную версию прошивки лампы на основе того же движка silabs, исправляем проблему и выясняем способ OTA-установки этой прошивки.

Это выходит далеко за рамки моих нынешних знаний и, честно говоря, моих амбиций - я делаю это для хобби. Я играл с XBee, чтобы посмотреть, смогу ли я написать приложение ZigBee (моей конечной целью было бы улучшить мои жалюзи), но я никогда не заглядывал в нижние уровни стека ZigBee, где происходит маршрутизация. .

Мы не. Полагаю, это должно быть реализовано в прошивке RaspBee / ConBee. Неплохая идея, imho, но я понятия не имею, насколько это возможно, учитывая ограничения по размеру в EEPROM и NVRAM устройства. @manup , что ты об этом думаешь?

Думаю, я считаю @manup частью We;)

Это выходит далеко за рамки моих нынешних знаний и, честно говоря, моих амбиций - я делаю это для хобби. Я играл с XBee, чтобы посмотреть, смогу ли я написать приложение ZigBee (моей конечной целью было бы улучшить мои жалюзи), но я никогда не заглядывал в нижние уровни стека ZigBee, где происходит маршрутизация. .

Я согласен, для меня это тоже хобби, но я надеюсь, что кто-то более осведомлен в этих деталях.

Я делал что-то подобное, используя платы CC2530. Я планирую зигбировать мою систему полива (я не могу согласиться, что мне нужно ходить по саду, чтобы вручную включать / выключать определенные дождеватели :)) Я смог скомпилировать Прошивка zigbee для моей платы CC2530, которая подключается к сети deCONZ как индикатор включения / выключения. Клапаны, которые я планирую использовать, имеют фиксирующий механизм, поэтому для переключения требуется определенный сигнал, поэтому мне пришлось создать свою собственную прошивку ...

Мы не. Полагаю, это должно быть реализовано в прошивке RaspBee / ConBee. Неплохая идея, imho, но я понятия не имею, насколько это возможно, учитывая ограничения по размеру в EEPROM и NVRAM устройства. @manup , что ты об этом думаешь?

Стек Zigbee в прошивке имеет параметр, позволяющий управлять использованием маршрута вместо прямой ссылки в зависимости от его качества (RSSI / LQI), это уже должно работать довольно хорошо и было изменено за эти годы.

Дальнейший путь может быть более общим подходом к управлению таблицами маршрутизации всех устройств.

Примечание. Вы можете запросить таблицу маршрутизации маршрутизатора, выбрав ее и нажав клавишу R , маршруты следующего перехода будут показаны синим цветом.

В настоящее время, когда сеть Zigbee открыта, всем маршрутизаторам разрешено быть родительским узлом, поскольку Mgmt_Permit_Joining_req отправляется как широковещательный. Однако если мы отправим этот запрос как одноадресный только определенному маршрутизатору, новое устройство сможет присоединиться только через это одно устройство. Это может быть полезно для конечных устройств Xiaomi, которые часто привязаны к своим родительским. Для других подключаемых устройств, таких как маршрутизаторы и, например, конечные устройства Philips Hue, это не очень поможет, поскольку они могут выбирать новых родителей и маршруты самостоятельно.

(Новый) Mgmt_NWK_IEEE_Joining_List_req в спецификации Zigbee R22 также выглядит интересно:

Команда Mgmt_NWK_IEEE_Joining_List_req предоставляется в качестве механизма для получения списка адресов IEEE, которые, как ожидается, будут присоединены к сети. Это позволяет локальному маршрутизатору фильтровать запросы расширенных маяков и отвечать только устройствам, которые присоединяются.

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

Серебряной пулей может быть использование Source Routing, где шлюз предоставляет полный маршрут в каждом кадре, но я никогда не видел, чтобы это использовалось каким-либо потребительским продуктом или шлюзом, и я предполагаю, что это может не поддерживаться (или плохо) поддерживаться текущими маршрутизаторами. Хотя, возможно, стоит попробовать.

Примечание. Вы можете запросить таблицу маршрутизации маршрутизатора, выбрав ее и нажав клавишу R , маршруты следующего перехода будут показаны синим цветом.

Круто, я этого не знал. Есть ли обзор всех клавиш / команд, поддерживаемых графическим интерфейсом? Можно ли вернуть синие линии перед запросом следующего узла? Кажется, это не работает для самого RaspBee / ConBee?

Таблица маршрутизации отличается от таблицы соседей? Обнюхивая, я вижу только сообщения ZDP _Link Quality Request_ и _Link Quality Response_, сообщающие о таблице соседей. Означает ли это, что линии к узлу, которые не окрашены в синий цвет, являются «входящими» маршрутами?

@manup , действительно интересная визуализация

Серебряная пуля может использовать Source Routing

Ну ... думаю, стоит попробовать. Мне кажется, что в моей сети больше всего страдают светильники IKEA, которые находятся на большем расстоянии от координатора. Я подозревал, что что-то, связанное с маршрутизацией, вызывает проблемы, как упоминал @ebaauw .
Я был бы готов протестировать для вас что-то подобное. Хотя, я должен признать, что потеря связи не очень надежна, поэтому тестирование может быть затруднено.

Я больше думал о том, чтобы координатор выбирал маршрутизатор для первого перехода. Если мы сможем найти маршрутизаторы, которые хорошо сочетаются с устройствами IKEA (возможно, это маршрутизаторы IKEA), маршрутизация всех пакетов через них должна сделать работу более надежной. Не уверен, что вы можете обмануть процесс обнаружения маршрута, чтобы предпочесть определенный маршрутизатор для первого перехода, но, вероятно, вы можете прокомментировать это, @manup

Примечание. Вы можете запросить таблицу маршрутизации маршрутизатора, выбрав ее и нажав клавишу R , маршруты следующего перехода будут показаны синим цветом.

Круто, я этого не знал. Есть ли обзор всех клавиш / команд, поддерживаемых графическим интерфейсом? Можно ли вернуть синие линии перед запросом следующего узла? Кажется, это не работает для самого RaspBee / ConBee?

Если кто-то захочет перечислить все комбинации клавиш и то, что они делают, я буду счастлив очистить это и написать вики-страницу.

Круто, я этого не знал. Есть ли обзор всех клавиш / команд, поддерживаемых графическим интерфейсом?

Дескриптор узла запроса = 1
Запросить дескриптор мощности = 2
Запросить Nwk-адрес = 0
Таблица маршрутизации запросов = R
Request Mgmt Leave = L (с повторным присоединением, не используйте с внутренним освещением!)
Запросить активные конечные точки = 7
Запрос простых дескрипторов = 8
Обновить = F5 / Cmd-R
Удалить = Delete / Backspace
Annce устройства шлюза = A (не очень полезно)

Можно ли вернуть синие линии перед запросом следующего узла?

Пока нет, это было просто быстрое и грязное дополнение, чтобы увидеть маршруты :)
Возможно, полезно добавить еще один ключ, например Shift-R чтобы очистить маршруты узла?

Кажется, это не работает для самого RaspBee / ConBee?

К сожалению, RaspBee I / ConBee Я не поддерживаю соответствующую команду ZDP, она работает с ConBee II.

Таблица маршрутизации отличается от таблицы соседей? Обнюхивая, я вижу только сообщения ZDP Link Quality Request и Link Quality Response, сообщающие о таблице соседей.

Это две отдельные таблицы, обычно таблица маршрутизации содержит только маршруты к узлам, которые не достижимы напрямую и являются предметом таблицы соседей (узлы с 1 переходом).

Для узлов, которые находятся в таблице соседей (и имеют сильный сигнал), обнаружение маршрута не требуется. Сама таблица соседей строится в основном с использованием команд состояния канала NWK с 1 переходом.

Означает ли это, что линии к узлу, которые не окрашены в синий цвет, являются «входящими» маршрутами?

Не синие линии (зеленый / оранжевый / желтый) просто представляют таблицу соседей с 1 переходом. Синие линии представляют собой исходящие маршруты к некоторому пункту назначения и представляют только следующий переход (не полный маршрут) в текущем представлении, адрес NWK пункта назначения не отображается, но, вероятно, имеются отпечатки отладки.

Мы не. Полагаю, это должно быть реализовано в прошивке RaspBee / ConBee. Неплохая идея, imho, но я понятия не имею, насколько это возможно, учитывая ограничения по размеру в EEPROM и NVRAM устройства. @manup , что ты об этом думаешь?

Стек Zigbee в прошивке имеет параметр, позволяющий управлять использованием маршрута вместо прямой ссылки в зависимости от его качества (RSSI / LQI), это уже должно работать довольно хорошо и было изменено за эти годы.

Дальнейший путь может быть более общим подходом к управлению таблицами маршрутизации всех устройств.

Примечание. Вы можете запросить таблицу маршрутизации маршрутизатора, выбрав ее и нажав клавишу R , маршруты следующего перехода будут показаны синим цветом.

Действительно полезная функция! Вчера я включил лампу TRÅDFRI GU10 WS 400lm (7 лампочек) с прошивкой 2.0.022. Сегодня проблемы вернулись, появилась на лампе TRÅDFRI E27 CWS opal 600lm с прошивкой 1.3.009. Благодаря этой функции я увидел, что лампочка E27 проходит через лампы GU10. Я выключил все GU10, и, как по волшебству, E27 снова заработал.

Таким образом, становится довольно ясно, что маршрутизация через Innr и IKEA вызывает проблемы. Я начал перемещать лампы Innr och IKEA в свой цветовой шлюз. Похоже, лампы Philips - хорошие маршрутизаторы и не вызывают проблем.

Итак, я провел небольшой эксперимент, переставляя свет в гостиной. Я удалил два роутера и переставил одну лампу. Et voila, один свет стал зомби, но не полностью. Он ведет себя точно так же, как я видел с лампами IKEA, которые иногда теряют связь.

Индикатор IKEA указан как недоступный, но по-прежнему реагирует на групповые команды. Кроме того, поскольку он все еще известен нескольким другим маршрутизаторам, похоже, они сообщают о том, что видели свет (это 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

и

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

Иногда кажется, что общение возможно:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

иногда нет:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

Информации о том, что происходит не так, очень мало. Что означает статус 0xA7 ..?

Любая дополнительная информация, которая может помочь выяснить, что происходит?

Итак, я провел небольшой эксперимент, переставляя свет в гостиной. Я удалил два роутера и переставил одну лампу. Et voila, один свет стал зомби, но не полностью. Он ведет себя точно так же, как я видел с лампами IKEA, которые иногда теряют связь.

Индикатор IKEA указан как недоступный, но по-прежнему реагирует на групповые команды. Кроме того, поскольку он все еще известен нескольким другим маршрутизаторам, похоже, они сообщают о том, что видели свет (это 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

и

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

Иногда кажется, что общение возможно:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

иногда нет:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

Информации о том, что происходит не так, очень мало. Что означает статус 0xA7 ..?

Любая дополнительная информация, которая может помочь выяснить, что происходит?

Это похоже на точную копию моих проблем!

Что означает статус 0xA7 ..?

Смотрите здесь: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Власть выключила свет

12:39:21:833 ZDP device announce: 0x000B57FFFEC52C7D, 0xD338, 0x8E
12:39:21:833 ZDP add fast discover for 0x000b57fffec52c7d
12:39:21:838 DeviceAnnce of LightNode: 0x000b57fffec52c7d Permit Join: 0
12:39:22:040 ZDP finished fast discover for 0x000b57fffec52c7d

И, кажется, с радостью сообщает о своем статусе

12:39:22:665 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:39:22:665 0x0000 12:39:22:665 ]
12:39:22:665 add task 10024 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 175
12:39:22:665 Poll APS request 175 to 0x000B57FFFEC52C7D cluster: 0x0006
12:39:22:753 Poll APS confirm 175 status: 0x00
12:39:22:753 Erase task req-id: 175, type: 19 zcl seqno: 167 send time 0, profileId: 0x0104, clusterId: 0x0006
12:39:22:920 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 1 s

тогда:

12:39:26:760 ZDP active ep request to 0x000b57fffec52c7d
12:39:26:760 ZDP send request id: 0x07 to 0x000b57fffec52c7d
---
12:39:32:520 node 0000B57FFFEC52C7D leave wait state
12:39:32:521 ZDP active ep request to 0x000b57fffec52c7d
12:39:32:521 Incr. ZDP retry count 2 on item 7
---
12:39:44:655 add task 10125 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 60
12:39:44:700 Erase task req-id: 60, type: 21 zcl seqno: 171 send time 0, profileId: 0x0104, clusterId: 0x0004
---
12:39:45:405 create binding for attribute reporting of cluster 0x0000
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0000
12:39:45:405 create binding for attribute reporting of cluster 0x0006
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0006
12:39:45:405 create binding for attribute reporting of cluster 0x0008
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0008
12:39:45:405 Force binding of attribute reporting for node HK houtlamp 2
---
12:39:50:760 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 28 s
---
12:40:06:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
12:40:08:905 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:11:881 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:11:881 0x0000 12:40:11:881 ]
12:40:11:882 add task 10241 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 205
12:40:11:882 Poll APS request 205 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:21:640 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:22:957 Poll APS confirm 205 status: 0xA7
12:40:22:957     drop item attr/modelid
12:40:22:957     drop item attr/swversion
12:40:22:957     drop item state/bri
12:40:22:957 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:22:957 Erase task req-id: 205, type: 19 zcl seqno: 175 send time 11, profileId: 0x0104, clusterId: 0x0006
12:40:22:957 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 78 s
---
12:40:28:904 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:30:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:32:050 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:33:568 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:39:481 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:42:987 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 10 s
---
12:40:43:276 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:43:276 0x0000 12:40:43:276 ]
12:40:43:277 add task 10380 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 157
12:40:43:277 Poll APS request 157 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:54:621 Poll APS confirm 157 status: 0xA7
12:40:54:621     drop item attr/modelid
12:40:54:621     drop item attr/swversion
12:40:54:621     drop item state/bri
12:40:54:621 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:54:621 Erase task req-id: 157, type: 19 zcl seqno: 180 send time 12, profileId: 0x0104, clusterId: 0x0006
12:40:54:621 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 22 s

он перестает работать. пока .. 2 минуты спустя

12:42:10:529 LightNode removed 0x000b57fffec52c7d
12:42:10:530 Node zombie state changed 0x000b57fffec52c7d
---
12:42:39:361 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 0 s
---
12:43:06:904 add task 11002 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 83
12:43:06:953 Erase task req-id: 83, type: 21 zcl seqno: 198 send time 0, profileId: 0x0104, clusterId: 0x0004
12:43:07:329 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 22 s
---
12:43:12:455 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:43:12:455 0x0000 12:43:12:455 ]
12:43:12:455 add task 11026 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 125
12:43:12:455 Poll APS request 125 to 0x000B57FFFEC52C7D cluster: 0x0006
12:43:12:498 ZDP status = 0x00 -> SUCCESS

Думаю, мне нужно обзавестись зигби-сниффером, чтобы выяснить, что происходит в эфире.

после этого он снова перестал работать, на этот раз более устойчивый.

Что означает статус 0xA7 ..?

Смотрите здесь: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Спасибо за это! почему-то это то, что я ожидал ...

Я попытался соединить свою лампу TRÅDFRI GU10 WS 400lm (7 лампочек) с мостом Philips Hue. Несколько других ламп в сети стали недоступны, и лампа TRÅDFRI GU10 WS 400lm имела такое же поведение, как и у Deconz, ответ на групповую команду, но не ответ на одноадресную передачу.

Лампа TRÅDFRI GU10 WS 400lm вроде как проблема. Я проведу несколько тестов, если это отдельные лампочки или все они не работают.

Сейчас я провел небольшое тестирование. Я пришел к выводу, что на самом деле сеть перестает отвечать на запросы от отдельных лампочек. Миндаль появился сразу на мосту Хюэ, и все снова заработало, как только я выключил их. Таким образом, из 7 лампочек поражены 3 . Я сообщу, если найду новые проблемы.

@MikaelHoogen , какая у вас версия лампочек и прошивки?

Я видел эту проблему на v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS и всех 3 панелях FLOALT на шлюзах Ikea, HUE и DeCONZ за последние полтора года.
Я убежден, что это проблема HW. Абсолютно случайно, какой узел умирает.
Здесь, в Норвегии, на всю электронику действует гарантия 2 года. Постараюсь открыть тикет и услышать, что говорят.
По поводу FLOALT. Несколько месяцев назад Ikea проводила распродажу на них. Возможно, это было для того, чтобы избавиться от всего v1?
Кто-нибудь видел там FLOALT v2? (возможно, с драйвером sy5882?)

Я видел эту проблему на v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS и всех 3 панелях FLOALT на шлюзах Ikea, HUE и DeCONZ за последние полтора года.
Я убежден, что это проблема HW. Абсолютно случайно, какой узел умирает.
Здесь, в Норвегии, на всю электронику действует гарантия 2 года. Постараюсь открыть тикет и услышать, что говорят.
По поводу FLOALT. Несколько месяцев назад Ikea проводила распродажу на них. Возможно, это было для того, чтобы избавиться от всего v1?
Кто-нибудь видел там FLOALT v2? (возможно, с драйвером sy5882?)

Это то, что я пытался сказать уже довольно давно. У меня проблемы только с лампами Trådfri v1. Мост Philips Hue помогает, но узлы время от времени становятся недоступными.

Пару дней назад решил заменить все 12 булпов IKEA GU10 на новую версию (теплый белый).
Это еще больше усугубило ситуацию. Теперь я также теряю белый оттенок Hue GU10 и цвет Hue E14.

Я использую deConz и IKEA light с самого начала, когда они появились. У меня в сети около 70 узлов. Большинство из них - светильники ИКЕА. Еще у меня есть несколько Philips Hue (4 лампы) и один Osram. Датчики У меня мало движения Ikea и много датчиков движения Xiaomi.

Я работаю с этой установкой довольно долгое время, и ни дня не проходит, чтобы один свет не застревал, поэтому мне нужно выключить и снова включить цикл питания. Моя жена не в восторге, и я тоже. Я очень близок к тому, чтобы отказаться от всех устройств zigbee и просто перейти на обычные огни старой школы. Это просто не работает. очень разочаровывает. Интересно, видят ли другие такие же проблемы при использовании чистых ламп Philips или Osram, или это просто дерьмо из IKEA?

Я использую deConz и IKEA light с самого начала, когда они появились. У меня в сети около 70 узлов. Большинство из них - светильники ИКЕА. Еще у меня есть несколько Philips Hue (4 лампы) и один Osram. Датчики У меня мало движения Ikea и много датчиков движения Xiaomi.

Я работаю с этой установкой довольно долгое время, и ни дня не проходит, чтобы один свет не застревал, поэтому мне нужно выключить и снова включить цикл питания. Моя жена не в восторге, и я тоже. Я очень близок к тому, чтобы отказаться от всех устройств zigbee и просто перейти на обычные огни старой школы. Это просто не работает. очень разочаровывает. Интересно, видят ли другие такие же проблемы при использовании чистых ламп Philips или Osram, или это просто дерьмо из IKEA?

Глядя на всех людей, имеющих одни и те же проблемы в этой ветке, и создатели deconz не могут понять, в чем проблема с лампочками IKEA - они пахнут и выглядят как проблема с прошивкой IKEA.

Многие пользователи сталкиваются с подобными проблемами даже с центром IKEA. Так что я думаю, это не уникальная проблема, связанная с деконзом. Однако, если кто-то может исправить это, «исправить / найти обходной путь», то это будут ребята! <3

У меня точно такая же проблема и с семьей, и с настройкой.

Это печально :( особенно то, что даже у новых, которые они продают сегодня, все еще есть эти проблемы. Я просто не понимаю. У меня есть мой с 2017 года, поэтому вы можете ожидать, что они исправили проблему к настоящему времени. Это не может быть исправлено здесь, @manup ранее заявлял, что это проблема в прошивке устройства, поэтому только IKEA может исправить это, и, поскольку они этого еще не сделали, нет никакой надежды.

Deconz версия 2.05.69
Прошивка Conbee II 264A0700

Это не на 100% идеально, и я заметил, что выпавшие лампы - это лампы E27 Ikea (Rev1).
Когда у меня были эти фонари Ikea с моим мостом Philips Hue, они были как скала, поэтому я, вероятно, переместил их обратно в Hue и оставил эту сетку Zigbee исключительно CC2531 (прошивка маршрутизатора) и датчики Xiaomi.
У меня также есть лампа Innr (E14) и SP120, но с Deconz они все еще подходят.

Я использую Home Assistant и Deconz для управления примерно 20 лампочками Ikea (и множеством других датчиков). Лампочки - это в основном лампы GU10, которые сгруппированы по 3 точки в один свет.

Я использую эту настройку более 15 месяцев, и с этого лета у меня были проблемы с одной или несколькими лампами, которые застревали и требовали цикла питания, или даже были удалены и повторно добавлены в сеть Zigbee. Это всегда были GU10, которые были определены в легкой группе в HASS.

Несколько недель назад я создал группы для своих светильников в Phoscon и начал ссылаться на эти группы в HASS.

После этого у меня не было ни одной проблемы с заклиниванием лампочек и требованием цикла включения. Единственная проблема, которую я вижу, заключается в том, что при одновременном выключении всего внутреннего освещения в помещении иногда остается включенной вся группа Phoscon / Deconz.

Мне кажется, что это проблема с Deconz API и, возможно, с быстрой последовательной обработкой нескольких лампочек.

У меня также есть проблемы с устройствами Ikea (лампочки, а в последнее время и с пультом дистанционного управления Symfonisk), которые становятся недоступными и требуют повторного сопряжения с deCONZ. Думаю, я занимаюсь этими проблемами в течение 6 месяцев или около того. Нечего добавить, больше, чем я думаю, это происходит чаще в последнее время. Лампочек GU10 у меня нет, только разные Е27 и Е14 (да и разные пульты). Кажется, что некоторые устройства более склонны к выпадению (может быть, в зависимости от того, как они связаны или что-то подобное). У меня около 20 устройств с максимальным радиусом действия 5 м от Conbee I с последними версиями FW / Phoscon / deCONZ.

У меня также есть проблемы с устройствами Ikea (лампочки, а в последнее время и с пультом дистанционного управления Symfonisk), которые становятся недоступными и требуют повторного сопряжения с deCONZ. Думаю, я занимаюсь этими проблемами в течение 6 месяцев или около того. Нечего добавить, больше, чем я думаю, это происходит чаще в последнее время. Лампочек GU10 у меня нет, только разные Е27 и Е14 (да и разные пульты). Кажется, что некоторые устройства более склонны к выпадению (может быть, в зависимости от того, как они связаны или что-то подобное). У меня около 20 устройств с максимальным радиусом действия 5 м от Conbee I с последними версиями FW / Phoscon / deCONZ.

Попробуйте Deconz версии 2.05.69. Довольно стабильно для меня с Ikea, Innr и Xiaomi

У меня аналогичная проблема и билет открыт https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

Я бы сказал, что после перехода на версию 2.05.67 моя сеть стала более стабильной, чем когда-либо. Было несколько лампочек, которые вышли из строя, но те же две и с ними можно было жить. Вчера все заработало как положено.

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

У меня также есть проблемы с устройствами Ikea (лампочки, а в последнее время и с пультом дистанционного управления Symfonisk), которые становятся недоступными и требуют повторного сопряжения с deCONZ. Думаю, я занимаюсь этими проблемами в течение 6 месяцев или около того. Нечего добавить, больше, чем я думаю, это происходит чаще в последнее время. Лампочек GU10 у меня нет, только разные Е27 и Е14 (да и разные пульты). Кажется, что некоторые устройства более склонны к выпадению (может быть, в зависимости от того, как они связаны или что-то подобное). У меня около 20 устройств с максимальным радиусом действия 5 м от Conbee I с последними версиями FW / Phoscon / deCONZ.

Попробуйте Deconz версии 2.05.69. Довольно стабильно для меня с Ikea, Innr и Xiaomi

Попробую это, а также

Несколько недель назад я создал группы для своих светильников в Phoscon и начал ссылаться на эти группы в HASS.

Итак, я наконец получил свое оборудование для сниффинга, а также немного взломал Wireshark, чтобы отображать имена для всех адресов ieee802.15.4 (что значительно упрощает чтение того, что происходит).

В любом случае, я не очень хорошо разбираюсь в зигби, поэтому, возможно, я задаю глупые вопросы. Однако я просмотрел несколько журналов обнюхивания, и, надеюсь, мы сможем увидеть что-то, что объясняет нестабильное поведение огней ikea.

См. Журнал ниже. Кажется ли это «нормальным» поведением? Оба задействованных источника света являются лампами Ikea. Сначала DeConz отправляет запрос в «Гараж», маршрутизируя его через «Золдер». Затем «Золдер» пытается передать его в «Гараж», но, похоже, это не удается (почему?) И повторяется 20 раз в очень быстрой последовательности (большинство из них в пределах 3 мс). В конце концов Золдер сдается и отправляет ДеКонцу сообщение об отказе соединения.

Должен ли он быть таким агрессивным при повторной попытке передачи?

Также: я заметил, что DeConz с радостью продолжает отправлять запросы в Garage через Zolder, хотя ссылка явно не работает. DeConz делает это даже тогда, когда Garage больше не отображается в отчете Zolder о статусе связи. Кроме того, если иногда в отчете о статусе связи Золдера есть Garage, он стоит 7 как входящий, так и исходящий. На самом деле путь от Гаража до ДеКонца не через Золдер ...
Почему DeConz продолжает маршрутизацию через Zolder даже после сообщения Link Failure?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

Итак, я потратил некоторое время на чтение документации по силабам ZigBee (IKEA основаны на чипах силабов).
Судя по всему, поведение повтора точно такое, как описано в документах.

Остается вопрос, почему ДеКонц настаивает на использовании этого маршрута. Стоимость канала высока, есть ответ Link Failure, но этот маршрут по-прежнему используется. Почему..?
(и есть маршруты получше ...)

Очень полезная информация @djwlindenaar, хотя я не могу помочь вам на этом уровне. Это немного подтверждает мои подозрения. У меня была приличная рабочая сеть (с пониженной версией программного обеспечения), пока я случайно не отключился от электричества, и весь дом отключился.

После этого я снова вернулся и думаю, что у меня снова плохие маршруты.

Еще одно. Каким образом deconz устанавливает состояния, даже если фактическое устройство не отвечает? Похоже, что лампочка на интерфейсах горит, но физически не горит (все еще под напряжением). Иногда срабатывает, чтобы включить его снова (через программное обеспечение), иногда он работает с циклом включения питания, но часто он вообще не реагирует даже после цикла питания. Та же лампочка может внезапно снова сработать через некоторое время

Еще немного интересного поведения (я показываю те же огни, но это происходит и в других местах в моей сети)

• DeConz отправляет many-to-one route Route Request пакетов. В результате любое устройство сначала обнаружит маршрут. Это должно обеспечивать концентратор (координатор) информацией о том, как связаться с этим устройством. Похоже, ДеКонз игнорирует эту информацию, потому что она направляет ...

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7544        747.873     DeConz      DeConz      Zolder      Garage      ZigBee ZDP  Link Quality Request
7546        747.876     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7547        747.882     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7548        747.887     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7549        747.892     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7550        747.919     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7551        747.925     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7552        747.929     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7553        747.932     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7554        747.980     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7555        747.985     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7556        747.990     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7557        747.995     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7558        748.046     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7559        748.052     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7560        748.055     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7561        748.061     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7563        748.066     Garage      Garage      Kerstver    DeConz      ZigBee      Route Record, Dst: 0x0000
7565        748.076     Garage      Kerstver    HK zoutlamp DeConz      ZigBee      Route Record, Dst: 0x0000
7567        748.084     Garage      HK zoutlamp DeConz      DeConz      ZigBee      Route Record, Dst: 0x0000

В последнем пакете есть информация о том, как добраться до Гаража:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 2
    Relay Device 1: 0x731e[Kerstverli]
    Relay Device 2: 0xa3f5[HK zoutlam]

Но следующий запрос в Гараж снова отправляется через Zolder.

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7569        748.112847  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7570        748.117327  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7573        748.126608  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request

Я не удивлюсь, что такое поведение как-то связано с шелушащимся светом в IKEA.

@manup , не могли бы вы это прокомментировать? Ваше заявление о том, что Source Routing поможет, имеет большой смысл.
В качестве альтернативы я ожидаю, что использование информации из записи маршрута для обновления таблицы маршрутизации DeConz уже может быть огромным улучшением ...
Или нам нужно выяснить, почему DeConz хочет продолжать использовать маршрут, который сообщает о проблемах со связью / имеет высокие затраты на маршрутизацию по сравнению с альтернативой.

Еще одно наблюдение ... Оба релейных устройства в вышеуказанном пакете - это вилки Xiaomi. У них никогда не запрашивается качество ссылки. Почему?
Может быть, DeConz использует информацию из ответа о качестве канала для построения своей таблицы маршрутов и поэтому игнорирует вполне допустимые маршрутизаторы? С хорошим качеством связи с некоторыми из моих несчастных фонарей из ИКЕА ...

Увидеть только это поведение для устройств ikea или общее поведение, чтобы игнорировать оптимальный маршрут? Думаю, у вас приличное количество устройств ikea?

Я не уверен, мне нужно это проверить. Хороший вопрос.

Да, у меня довольно много лампочек Ikea.

На мой взгляд, это объясняет большую часть поведения, которое мы наблюдали с недоступными светильниками ИКЕА. Хотя это пока лишь гипотезы, требующие проверки.

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

Я только вижу, что устройства Xiaomi не запрашивают качество связи, как и другие бренды. Думаю, это какой-то черный список ..?

Пример другого поведения маршрутизации:

От DeConz всегда:
DeConz --> WC Lamp --> Badkamer Ledstrip

Обратный маршрут часто меняется после запроса маршрута "многие к одному". Обратите внимание, что с географической точки зрения все это имеет смысл ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

Что касается освещения в гараже, я вижу от DeConz:
DeConz --> Zolder Noord Lamp --> Garage (очень нестабильный маршрут ..!)

Обратный маршрут вижу:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

Теперь, когда я смотрю на таблицу в отчетах о статусе каналов, я вижу, что приведенный выше маршрут от гаража до DeConz имеет смысл:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz общая стоимость: 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz общая стоимость: 4

из DeConz в Garage не:
DeConz --> Zolder Noord Lamp --> Garage общая стоимость: 12 (на основе входящей стоимости от DeConz до Zolder Noord Lamp)

@manup , не могли бы вы

Еще немного анализа сегодня ...
В моих предыдущих постах вы видели, что мой свет Garage проходит через мой свет Zolder. Обе лампочки ИКЕА. Радиосвязь от Золдера до гаража находится на грани возможного, поэтому часто дает сбой.

Сегодня, хотя Garage Light реагирует на групповые команды, он не отвечает на одноадресные команды. На самом деле иногда это так, а иногда нет. Это поведение должно быть знакомо тем, кто читал / вносил свой вклад в эту ветку.

Я могу найти это в журналах сниффинга. Иногда свет Zolder может взаимодействовать с Garage, а иногда - нет. Каждый раз, когда Zolder light не может связаться с Garage, он сообщает следующее:

ZigBee Network Layer Command, Dst: DeConz, Src: Zolder No
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0xd6b7[Zolder Noo]
    Radius: 30
    Sequence Number: 65
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: SiliconL_ff:fe:c3:4a:3e (00:0b:57:ff:fe:c3:4a:3e)
    ZigBee Security Header
    Command Frame: Network Status
        Command Identifier: Network Status (0x03)
        Status Code: Non-tree Link Failure (0x02)
        Destination: 0x9e0c[Garage]

Этот пакет должен сказать ДеКонцу начать поиск другого маршрута, чтобы добраться до гаража, но этого не происходит. Следующий пакет, отправленный в Гараж, снова проходит через Золдера. Для меня это ошибка, которую необходимо решить.
Следующий пакет для Гаража получает свет Зольдера, но этот свет даже не пытается отправить его в Гараж. Возможно, это плохое поведение прошивки IKEA, но основная причина проблемы - отказ DeConz найти альтернативный путь.
Я думаю, что если маршрут недоступен в течение длительного периода времени, возможно, светильник Garage не получает ACK на более высоком уровне, чем протокол 802.15.4, и это может вызвать отключение прошивки или даже сбой. И я согласен, что не должно, но основная проблема заключается в том, что ДеКонц отказывается найти новый путь к свету в гараже.

Сегодня я провел эксперимент, чтобы заставить ДеКонца найти другой путь к свету в гараже, поэтому я отключил питание от светильника Zolder и посмотрел на журналы нюхания. После нескольких попыток ДеКонц понимает, что Золдер ушел, и начинает искать альтернативный маршрут к Гаражу. Затем я повторно подключаю Золдера, и после объявления о его присутствии также для Золдера обнаруживается новый маршрут. ДеКонз (пока) не возвращается к маршрутизации «Гаража» через Золдера.

Забавно то, что в новой ситуации DeConz теперь напрямую общается с Garage Light, без маршрутизаторов между ними.
Zolder теперь доступен по маршруту через 2 других маршрутизатора (хотя он, очевидно, был доступен напрямую DeConz), поэтому мне кажется, что какая-то таблица (таблица соседей?) Заполнена внутри прошивки маршрутизации DeConz.

Может быть, это связано с его отказом создать новый маршрут в ответ на сбой маршрута ..?

@manup , я буду признателен за любые ваши комментарии к вышеуказанным сообщениям. Или, по крайней мере, дайте мне знать, как внести свой вклад в решение (помимо поиска основной причины).

Я хотел бы помочь в решении этих проблем, поскольку они меня беспокоят. Если вы дадите доступ к исходному коду прошивки, я могу внести свой вклад напрямую (даже если это не открытый исходный код). Я не против помочь Dresden Elektronik в этом :)

Отличная работа сделана! 💪🏼
Надеюсь, мы сможем привлечь внимание разработчиков, чтобы исправить это. Похоже, у вас есть хорошая настройка и процесс, поэтому исправление можно будет проверить довольно «легко».
Теперь я понимаю наблюдаемое мной поведение, которое я назвал «самовосстановлением», и почему некоторые лампочки внезапно начинают работать.

Хорошая работа @djwlindenaar, надеюсь, @manup сможет на это взглянуть.

@manup есть комментарии?

Спасибо за эту ветку и работу. У меня на себе работает 20 икеа с обновлением лампочек и прошивка одного года. Я с самого начала сталкивался с зависаниями или потерей лампочки, но не слишком часто. С более поздними обновлениями deconz ситуация ухудшилась. Я проверил свою сеть, оптимизировал ее в упакованной среде 2.4. Лампа по-прежнему выпадает каждый день, что делает кнопки или датчики бесполезными, поскольку они все еще проходят через эту лампочку и поэтому не отправляют никаких данных. Мне нужно выключить и снова включить датчики, когда лампочки снова начнут их направлять. Надеюсь, это привлечет больше внимания. Это расстраивает.

Еще одно наблюдение ... Оба релейных устройства в вышеуказанном пакете - это вилки Xiaomi. У них никогда не запрашивается качество ссылки. Почему?
Может быть, DeConz использует информацию из ответа о качестве канала для построения своей таблицы маршрутов и поэтому игнорирует вполне допустимые маршрутизаторы? С хорошим качеством связи с некоторыми из моих несчастных фонарей из ИКЕА ...

Запрос таблицы соседей (также известной как ZDP Mgmt_Lqi_req) был отключен для устройств Xiaomi, поскольку они не отвечают на эти запросы через некоторое время, и я подозревал, что ошибка в прошивке может вызвать некое недопустимое состояние или что-то еще хуже.

Таким образом, основным драйвером для ограничения определенных запросов является предотвращение ошибок в прошивке конечного устройства и точное имитация поведения соответствующего шлюза поставщика. Некоторые результаты расследования можно найти в https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / опрос конечных устройств

В качестве дополнительного примечания, запросы таблицы соседей используются только для построения визуального представления сетки и не влияют на работу сети или таблицы маршрутизации.

Итак, я наконец получил свое оборудование для сниффинга, а также немного взломал Wireshark, чтобы отображать имена для всех адресов ieee802.15.4 (что значительно упрощает чтение того, что происходит).

В любом случае, я не очень хорошо разбираюсь в зигби, поэтому, возможно, я задаю глупые вопросы. Однако я просмотрел несколько журналов обнюхивания, и, надеюсь, мы сможем увидеть что-то, что объясняет нестабильное поведение огней ikea.

См. Журнал ниже. Кажется ли это «нормальным» поведением? Оба задействованных источника света являются лампами Ikea. Сначала DeConz отправляет запрос в «Гараж», маршрутизируя его через «Золдер». Затем «Золдер» пытается передать его в «Гараж», но, похоже, это не удается (почему?) И повторяется 20 раз в очень быстрой последовательности (большинство из них в пределах 3 мс). В конце концов Золдер сдается и отправляет ДеКонцу сообщение об отказе соединения.

Должен ли он быть таким агрессивным при повторной попытке передачи?

Также: я заметил, что DeConz с радостью продолжает отправлять запросы в Garage через Zolder, хотя ссылка явно не работает. DeConz делает это даже тогда, когда Garage больше не отображается в отчете Zolder о статусе связи. Кроме того, если иногда в отчете о статусе связи Золдера есть Garage, он стоит 7 как входящий, так и исходящий. На самом деле путь от Гаража до ДеКонца не через Золдер ...
Почему DeConz продолжает маршрутизацию через Zolder даже после сообщения Link Failure?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

Хороший улов! Здесь я подозреваю, что прошивка deCONZ должна обработать эту ошибку и попытаться найти новый маршрут. Я проверю прошивку, будет ли это дело обрабатываться и как. Я могу представить, что маршрут фактически отбрасывается, но если по тому же маршруту получено новое сообщение. Например, из-за отчета об атрибуте ZCL от источника света запись просто сохраняется.

Маршруты можно установить, просто получив любую команду из входящего кадра. Но если последний переход не удерживает переход перед этим (что они обычно делают), обратный путь через тот же переход не будет работать. Ваши выводы могут отражать именно этот случай.

Благодарю.

В этом случае через Золдера никогда не поступает сообщение от света гаража. Поэтому я не ожидал, что DeConz продолжит использовать этот маршрут. Смотрите мои другие сообщения ...

Код состояния: сбой связи без дерева (0x02)

Кажется, у нас есть победитель, я проверил исходный код стека Zigbee (R21, ConBee II), и этот код состояния полностью игнорируется. : -O Нужно проверить и стек AVR Zigbee, наверно там та же проблема.

В качестве исправления я хотел бы обрабатывать этот код так же, как обрабатывается статус «Нет маршрута», то есть просто для того, чтобы освободить запись маршрута и позволить стеку определить новую.

Есть ли у вас также полный пакет команды, который ранее был отправлен координатором на светильник IKEA? Было бы интересно, если бы был установлен бит маршрута обнаружения.

Вот раздел из спецификации Zigbee о том, что должно произойти в этом конкретном случае:

При получении кадра команды состояния сети маршрутизатором, который является предполагаемым местом назначения команды, где поле кода состояния полезной нагрузки кадра команды имеет значение 0x01 или 0x02, указывающее на сбой канала, уровень NWK удалит запись таблицы маршрутизации соответствующий значению поля адреса назначения полезной нагрузки командного кадра, если таковой существует, и сообщить следующему более высокому уровню об ошибке, используя индикацию NLME-NWK-STATUS.indication, используя тот же код состояния.

Таким образом, исправление выше должно работать здесь для 0x02, 0x01 также не обрабатывается, я тоже добавлю это.

0x00 No Route Available  (already handled)
0x01 Tree Link Failure
0x02 Non Tree Link Failure

Отличный @manup! Вы упомянули Conbee II. Будет ли это исправление работать на Conbee I?

Да, у меня есть только исходники стека, используемые ConBee I и RaspBee. Такая же проблема, готовлю новые версии прошивок для тестирования до вторника. Было бы здорово получить обратную связь, если это решит хотя бы проблемы с маршрутизацией IKEA.

Обратите внимание, что были также другие проблемы, которые не будут исправлены этим, например, лампочки IKEA полностью бесшумны и даже не слушают групповые передачи.

Случайно закрыл этот выпуск ... Открыт повторно. Здорово, что мы добиваемся прогресса в этом.

Я предполагаю, что @djwlindenaar - это тот, кто может дать обратную связь после того, как новая прошивка станет доступной, потому что для этого необходимо оборудование для сниффинга?

Есть ли у вас также полный пакет команды, который ранее был отправлен координатором на светильник IKEA? Было бы интересно, если бы был установлен бит маршрута обнаружения.

Я не уверен, что понимаю ваш вопрос. Какой пакет вы ищете? А на какой свет (Гараж или Золдер)?

Да, у меня есть только исходники стека, используемые ConBee I и RaspBee. Такая же проблема, готовлю новые версии прошивок для тестирования до вторника. Было бы здорово получить обратную связь, если это решит хотя бы проблемы с маршрутизацией IKEA.

Обратите внимание, что были также другие проблемы, которые не будут исправлены этим, например, лампочки IKEA полностью бесшумны и даже не слушают групповые передачи.

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

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

Кстати, я на Raspbee.

Да, у меня есть только исходники стека, используемые ConBee I и RaspBee. Такая же проблема, готовлю новые версии прошивок для тестирования до вторника. Было бы здорово получить обратную связь, если это решит хотя бы проблемы с маршрутизацией IKEA.

Дайте нам знать, у меня много проблем с этой проблемой, и я могу протестировать ее, хотя и не обнюхивал.

Обратите внимание, что были также другие проблемы, которые не будут исправлены этим, например, лампочки IKEA полностью бесшумны и даже не слушают групповые передачи.

Вы относите это к проблеме, что программное обеспечение (deconz) сообщает и устанавливает состояние, но сама лампочка не реагирует или не меняет состояние? Возможно, проблема не будет такой же серьезной, если мы решим проблему маршрутизации.

Спасибо, что заглянули в это, очень признательны!

Да, у меня есть только исходники стека, используемые ConBee I и RaspBee. Такая же проблема, готовлю новые версии прошивок для тестирования до вторника. Было бы здорово получить обратную связь, если это решит хотя бы проблемы с маршрутизацией IKEA.

Обратите внимание, что были также другие проблемы, которые не будут исправлены этим, например, лампочки IKEA полностью бесшумны и даже не слушают групповые передачи.

Спасибо, manup! Я обновлюсь до новой прошивки, как только она станет доступна, и предоставлю обновления.

Может ли эта проблема быть связана с проблемой управления жалюзи Ikea Fyrtur?

Еще один, который мне кажется странным. @manup , это

Я вижу много таких последовательностей. Я начал разбираться в этом, потому что это последнее сообщение от houtlamp перед тем, как он перестает отвечать. DeConz настраивает 2 элемента отчетов по атрибутам и почти одновременно запрашивает членство в группах. В журналах de DeConz это выглядит так, как показано ниже.

Мне интересно, есть ли ошибка в выборе порядкового номера или, может быть, это разрешено (я не знаю), и такое поведение вызывает ошибку в прошивке Tradfri. Есть один запрос с номером 215 и два запроса с номером 216. Может быть, у нас есть какое-то состояние гонки, когда обработка запросов прошивкой tradfri вызывает утечку памяти или иным образом зависает из-за двух запросов с тем же номером почти в одно и то же время? Шоуд ДеКонз получил два запроса с одинаковым порядковым номером?

13:09:40:905 Force read attributes for node HK houtlamp
13:09:40:905 binding for cluster 0x0000 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 binding for cluster 0x0006 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 configure reporting rq seq 215 for 0x000B57FFFEDBFE18, attribute 0x0006/0x0000
13:09:40:906 binding for cluster 0x0008 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:906 configure reporting rq seq 216 for 0x000B57FFFEDBFE18, attribute 0x0008/0x0000
13:09:40:906 Force binding of attribute reporting for node HK houtlamp
13:09:40:908 add task 7435258 type 21 to 0x000B57FFFEDBFE18 cluster 0x0004 req.id 233
13:09:41:013 Erase task req-id: 233, type: 21 zcl seqno: 216 send time 0, profileId: 0x0104, clusterId: 0x0004
13:09:41:053 ZCL configure reporting rsp seq: 215 0x000B57FFFEDBFE18 for cluster 0x0006 attr 0x0000 status 0x00
13:09:41:077 ZCL configure reporting rsp seq: 216 0x000B57FFFEDBFE18 for cluster 0x0008 attr 0x0000 status 0x00
13:09:41:116 verified group capacity: 255 and group count: 2 of LightNode 0x000b57fffedbfe18
13:09:41:116 0x000b57fffedbfe18 found group 0x0001
13:09:41:116 0x000b57fffedbfe18 found group 0xFFF0

По воздуху это выглядит так: (кажется, я не вижу каждый пакет по воздуху, что странно, так как сниффер находится прямо рядом с raspbee. сниффер)

No.          Source       Transmit Dev Receive Dev  Destination  Protocol     Info
2196482      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL: Configure Reporting, Seq: 215
2196484      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196486      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196488      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196490      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196492      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196494      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 215
2196496      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196497      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196498      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196500      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196502      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196504      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196506      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196508      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 216
2196510      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196511      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196512      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196513      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196515      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196517      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196519      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL Groups: Get Group Membership Response, Seq: 216
2196521      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196523      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1

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

Вот первая тестовая прошивка для ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

Теперь перенос этого обратно в прошивку ConBee I / RaspBee будет в ближайшее время.

А вот и тестовая версия для ConBee I и RaspBee с исправлением ошибки маршрута.
Надеюсь, это принесет некоторые улучшения для обнаружения нового маршрута при возникновении ошибки.

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

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

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

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

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

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

@manup Может ли эта проблема быть связана? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

Может быть, да, по крайней мере, состояние достижимости тоже изменится на false, когда маршрут нарушится. Но это может быть вызвано и другими причинами.

Заметил, что на некоторые лампочки ikea есть более новые прошивки. В журнале изменений указано улучшение сети / подключения и управление сбоями. Я обновляю 20 лампочек ... Я предоставлю обновления, если они будут полезны.

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

Жалко, что там нет дат выпуска ...

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

Жалко, что там нет дат выпуска ...

Кажется, он выпущен, поскольку я смог загрузить фирму 2.3.007, описанную в примечаниях к выпуску.

Должно быть, это было примерно в январе https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

не программист ее. Думаю, мне не стоит устанавливать r21 на conbee 2 и ждать? Это бета прошивка?

Немного не по теме: также новая прошивка для диммера Trådfri, обновив его до ZB3. Перекрестная ссылка # 2485, у нас будет та же проблема для диммера ... Я ожидаю, что датчик движения старой модели будет следующим ...

А вот и тестовая версия для ConBee I и RaspBee с исправлением ошибки маршрута.
Надеюсь, это принесет некоторые улучшения для обнаружения нового маршрута при возникновении ошибки.

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

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Спасибо, @manup , только что установил. Посмотрим, что это принесет.

Хотя я ожидаю, что это принесет некоторые улучшения, как вы относитесь к прошивке DeConz, игнорирующей записанные маршруты (из-за маршрутизации mane-to-one)? В общем, я убедился, что записанные маршруты намного логичнее, чем те, что используются прошивкой DeConz.
Хотя я могу представить, что включение маршрутизации от источника - это большая работа, прошивка DeConz может (должна?) По-прежнему использовать информацию из пакета записи маршрута для обновления первого перехода к устройству. Может быть, просто проверьте, совпадает ли последний переход к координатору с тем, что хранится в таблице маршрутизации, и если нет, сделайте запись в таблице маршрутизации недействительной. Я не уверен, можно ли заменить запись последним переходом из записанного маршрута, поскольку устройства по пути, вероятно, игнорируют информацию, но, по крайней мере, это может инициировать обнаружение нового маршрута для этого узла с помощью прошивки DeConz.

Что Вы думаете об этом?

Я установил прошивку на свой raspbee (у меня 73 узла в основном ikea), сообщу о результатах.

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

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

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
39174           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 182
39180           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 183
39227           DeConz          DeConz          On/Off light 36 Badkamer ledstr ZigBee HA       ZCL: Read Attributes, Seq: 183

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

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/33d8a8b349c9f4967e8b94ed2657e038406317c8

А вот и тестовая версия для ConBee I и RaspBee с исправлением ошибки маршрута.
Надеюсь, это принесет некоторые улучшения для обнаружения нового маршрута при возникновении ошибки.
Для тестирования, я думаю, было бы хорошо, если бы он работал несколько дней / недель, и мы увидим, перестанут ли индикаторы реагировать на одноадресные рассылки. В этом случае попробуйте, по-прежнему ли индикаторы реагируют на групповые команды или полностью молчат.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Спасибо, @manup , только что установил. Посмотрим, что это принесет.

Хотя я ожидаю, что это принесет некоторые улучшения, как вы относитесь к прошивке DeConz, игнорирующей записанные маршруты (из-за маршрутизации mane-to-one)? В общем, я убедился, что записанные маршруты намного логичнее, чем те, что используются прошивкой DeConz.
Хотя я могу представить, что включение маршрутизации от источника - это большая работа, прошивка DeConz может (должна?) По-прежнему использовать информацию из пакета записи маршрута для обновления первого перехода к устройству. Может быть, просто проверьте, совпадает ли последний переход к координатору с тем, что хранится в таблице маршрутизации, и если нет, сделайте запись в таблице маршрутизации недействительной. Я не уверен, можно ли заменить запись последним переходом из записанного маршрута, поскольку устройства по пути, вероятно, игнорируют информацию, но, по крайней мере, это может инициировать обнаружение нового маршрута для этого узла с помощью прошивки DeConz.

Что Вы думаете об этом?

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

Что Вы думаете об этом?

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

Что ж, я получил то, что происходит с Zolder и Garage (из нескольких сообщений назад), и я получил такое поведение:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163778          Garage          Kerstverlicht   DeConz          DeConz          ZigBee          Route Record, Dst: 0x0000
163779                                                                          IEEE 802.15.4   Ack

Маршрутная запись показывала:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 1
    Relay Device 1: 0x731e[Kerstverli]

Следующее сообщение DeConz с Garage:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163788          DeConz          DeConz          Zolder          Garage          ZigBee          APS: Ack, Dst Endpt: 0, Src Endpt: 0

Так что это явно не берет на себя записи маршрута.

Что я заметил в это время, так это то, что, как только я отключил Zolder , ДеКонц сразу смог найти новый маршрут. Так что, возможно, некоторые из таблиц, связанных с маршрутизацией, заполнены внутри прошивки DeConz. Может ли это быть правдой? Насколько велики таблицы соседей / маршрутизации в прошивке? Может ли полная таблица блокировать принятие новых записей маршрута?

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

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
173142          DeConz          Buiten - R sch  Tuin rechtsach1 Tuin rechtsach1 ZigBee ZDP      Bind Request, Basic (Cluster ID: 0x0000) Src: SiliconL_ff:fe:16:47:5f, Dst: dresden-_ff:ff:00:c4:9a
173143          Buiten - R sch  Buiten - R sch  DeConz          DeConz          ZigBee          Network Status, 0x35b7: Non-tree Link Failure
173144                                                                          IEEE 802.15.4   Ack
173206          DeConz          DeConz          Broadcast       Broadcast       ZigBee          Route Request, Dst: 0x35b7, Src: 0x0000

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

33d8a8b

"swversion": "2.5.74",

: smile: Спасибо @manup, отличное время отклика: 1st_place_medal:

Дождитесь обновления до 2.05.74 или используйте http://phoscon.de/app, чтобы показать приложение Phoscon. Мы только что видели, что офлайн-страница шлюза отображается на некоторых страницах, где ее не должно быть, сейчас восстанавливается ~ 2 часа.

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

Вот первая тестовая прошивка для ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

Теперь перенос этого обратно в прошивку ConBee I / RaspBee будет в ближайшее время.

У меня эта прошивка не работает. Он показывает все мои устройства как соединенные, но сетка не создается. Ни подключения не отображаются в графическом интерфейсе, ни переключение с Phoscon (2.05.74). Прошил Conbee II обратно на 264A0700, и все снова работает, как ожидалось ...

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

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

Несколько минут. Я видел некоторые действия на некоторых устройствах (синие точки), но ссылок не было. И переключение вообще не работало. Стоит ли мне тестировать дольше?

Построение сетки может занять некоторое время, но через 5–10 минут вы увидите линии.

У меня эта прошивка не работает.

То же самое, Rasperry Pi 4B, deCONZ 2.05.74, ConBee II. Небольшая тестовая сеть с повторителем Trådri, вилкой Trådfri, XBee, диммером Trådfri, 2 датчиками движения Trådfri (старый и новый) и выключателем Trådri On / Off. Похоже, что шлюз не отправляет и не принимает трафик с любого устройства. Увидеть отключение USB в системном журнале. После перепрошивки на 4А опять все шустро дори.
log.gz

Просто снова промелькнул, чтобы проверить:

• в графическом интерфейсе нет строк (пусть поработает 15 минут)
• USB-соединение кажется стабильным
• Переключатели UBISYS C4 и D1 все еще работают
• Кнопки Tradfri не

@ebaauw журнал показывает, что координатор видит только двух соседей с этой версией.

Возможно дело в размере сети. Сейчас у меня здесь работает только 40 устройств. В этой версии прошивки есть два других изменения, которые могут быть причиной: увеличенный размер буфера сообщений (немного превышающий, насколько я могу судить, снова уменьшит его) и немного более низкое значение мощности передачи.

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

Вы используете удлинительный кабель USB или ConBee II подключается напрямую?

У меня на Raspbee работает нормально ...

На RaspBee и ConBee 1 в новую версию включено только исправление Route (другая прошивка).

журнал показывает, что координатор видит только двух соседей с этой версией.

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

Вы используете удлинительный кабель USB или ConBee II подключается напрямую?

Он был подключен напрямую с тех пор, как я его получил. К порту USB-2 на Pi, когда XBee подключен к другому порту USB-2; ничего на USB-3. Соединение было стабильным, за исключением случая, когда я настроил ConBee II как маршрутизатор (см. №2463).

На RaspBee и ConBee 1 в новую версию включено только исправление Route (другая прошивка).

Еще не пробовал. Придется подождать позже ...

Я вижу довольно много настраиваемых пакетов отчетов. После небольшого поиска кажется, что они отправляются периодически примерно каждые полчаса. По какой причине эти запросы отчетов о настройке периодически повторяются?
@ebaauw , правильно ли я помню, что вы проводили много этих расследований поведения координатора ИКЕА? Он тоже так делает?

Я заметил в de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

Я нашел еще одно свидетельство относительно поведения маршрутизации DeConz, игнорирующего записи маршрута многие к одному. Это заставляет некоторых маршрутизаторов определять маршрутизацию «старомодным» способом.
(обратите внимание, что в пакете 117130 есть некоторая дешевая интерференция :)

Маршрут для badkamer ledstrip , по словам ДеКонца, начинается с On/Off light 36 который, очевидно, не знает, как туда добраться. Итак, он начинает обнаружение маршрута и, наконец, обнаруживает, что может (едва ли) достичь самого ledstrip . Обратный путь через Gang 1

Похоже, On/Off light 36 забывает о Badkamer ledstrip каждый раз, когда обрабатывается запрос маршрута "многие к одному" ...

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177114            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177115                                                                                    IEEE 802.15.4     Ack
177116            On/Off light 36   On/Off light 36   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177117            On/Off light 36   HK plafond ledstrip                 Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177118            On/Off light 36   HK zoutlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177119            On/Off light 36   Zoldertrap Lamp   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177120            On/Off light 36   Kerstverlichting  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177121            On/Off light 36   HK stalamp        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177122            On/Off light 36   DeConz            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177123            On/Off light 36   HK houtlamp 2     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177124            On/Off light 36   Keuken links      Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177125            On/Off light 36   Keuken Rechts     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177126            On/Off light 36   HK houtlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177127            On/Off light 36   Keuken mid        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177128            On/Off light 36   Tuin linksvoor 2  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177129            On/Off light 36   WC lamp           Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177130            0x6666            0x6666            0x6666            0x6666            IEEE 802.15.4     Data, Dst: 0x6666, Src: 0x6666, Bad FCS
177131            On/Off light 36   Gang 1            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177132            On/Off light 36   Hal lamp          Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177133            DeConz            On/Off light 36   Badkamer ledstrip Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177134                                                                                    IEEE 802.15.4     Ack
177135            Badkamer ledstrip Badkamer ledstrip Gang 1            DeConz            ZigBee            Command, Dst: DeConz, Src: Badkamer , Bad FCS
177136                                                                                    IEEE 802.15.4     Ack
177137            On/Off light 36   Voordeur          Broadcast         0xfcfd            ZigBee            Command, Dst: 0xfcfd, Src: On/Off li, Bad FCS
177138            Badkamer ledstrip Gang 1            DeConz            DeConz            ZigBee            Route Record, Dst: 0x0000

следующее сообщение:

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177366            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 58

Еще одна попытка прошивки ConBee II:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Эта версия имеет настройки мощности передачи 0x264a0700. Буферы по-прежнему велики (но, согласно карте, они должны хорошо помещаться в ОЗУ), чтобы проверять только одну вещь за раз.

Я получаю эту ошибку каждый раз, когда пытаюсь обновить прошивку до последней версии. Какие-нибудь намеки, почему?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Перезагрузите устройство / dev / ttyACM1 (ConBee II)
Версия прошивки deCONZ 26490700
R21B18 Загрузчик
Версия: 2.05
сборка: 22 марта 2019 г.
прошивка 161378 байт: | ============================== |
проверить:.
Ошибка обновления флэш-памяти, недопустимый CRC. Пожалуйста, попробуйте еще раз.
rich710 @ RichHassPc01 : ~ $

Вы проверили сумму MD5 загруженного файла? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

Да, я проверял и скачивал несколько раз, даже пытался вернуться к старой прошивке, и до сих пор все шло хорошо. Теперь я застрял с этой ошибкой, я несколько раз перезагружал свой NUC, но все же я застрял, когда флешер пытается перезагрузить мой ConbeeII.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] пароль для rich710:
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Перезагрузите устройство / dev / ttyACM1 (ConBee II)

2139: Ошибка: сбой сброса uart, повторите попытку.

Заметил, что вы используете ttyACM1, когда используете

GCFFlasher -l

Он покажет серийный номер.
Вы можете использовать его, чтобы указать в команде более стабильное имя устройства.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(замените серийным номером вашего устройства)

Извините, не сработало, может мне стоит переместить его на свой компьютер с Windows и попробовать
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Путь | Продавец | Продукт | Серийный | Тип
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | Общий FTDI
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Перезагрузите устройство (ConBee II)

2139: Ошибка: сбой сброса uart, проверьте повтор.
rich710 @ RichHassPc01 : ~ $

Либо так, либо в качестве альтернативы вы можете попробовать следующее:

• Отключите ConBee II от сети
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• Подключите ConBee II снова

Параметр -t позволяет GCFFlasher в течение одной минуты пытаться обработать обновление.

Он работал для обновления прошивки в Windows, и когда я снова подключил его к своему NUC с ubuntu, он снова подключился. НО через час он только что подключился к 4 моим узлам ..: S

Еще одна попытка прошивки ConBee II: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Больше никаких отключений USB, но deCONZ, похоже, довольно часто повторно обнаруживает ConBee II. По-прежнему нет движения.
log.gz

РЕДАКТИРОВАТЬ В шутку, я отключил XBee и использовал удлинительный USB-кабель длиной 10 см для подключения ConBee II: без изменений.

Еще одна попытка прошивки ConBee II:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Эта версия имеет настройки мощности передачи 0x264a0700. Буферы по-прежнему велики (но, согласно карте, они должны хорошо помещаться в ОЗУ), чтобы проверять только одну вещь за раз.

Протестировал вашу новую версию, но через 10 минут ссылка все еще не отображается ... При стабильной прошивке все исправные (маршрутизатор) ссылки в сети отображаются примерно через 2 минуты. Кнопка ИКЕА срабатывает сразу, а с тестовой прошивкой вообще не работает.

Хм жутко, спасибо за тестирование. Затем я попытаюсь уменьшить размер буфера, как упоминалось ранее.
Тем не менее мне интересно, почему он работает на моей установке. Из скриншота выше я могу только сказать, что у меня больше конечных устройств, чем маршрутизаторов.

@manup имел те же проблемы после перепрошивки прошивки, но нажатие на перезагрузку устройства в деконзировании / перезапуске деконз вернуло ссылки.

А вот и тестовая версия для ConBee I и RaspBee с исправлением ошибки маршрута.

Кажется, работает нормально на моей тестовой системе Pi 3B +. Подожду до этих выходных, прежде чем обновлять свою производственную сеть.

@ebaauw , правильно ли я помню, что вы проводили много этих расследований поведения координатора ИКЕА? Он тоже так делает?

Я добавил поддержку большинства устройств Trådfri, но мне не удалось перехватить трафик ZigBee в / из концентратора Trådfri. Он использует только сопряжение сенсорных ссылок, и мне еще предстоит попытаться захватить это, чтобы восстановить сетевой ключ. То есть, если это вообще возможно.

Я запускал новую прошивку на флешке conbee 1 в моей установке ~ 40 узлов с момента выпуска новой прошивки, и она отлично работает без каких-либо проблем! (На рисунке неподключенные узлы либо разряжены, либо не питаются)

Спасибо всем, кто помог устранить неполадки и обновил код. Это ТАК ценится! <3

У меня не работает. Практически нет подключений в сетке. Ждали минут 20 после перезапуска.

Raspberry Pi 3 Модель B Ред. 1.2
Конби II
версия 2.05.74
версия 26530700

77 узлов

3 Подключение к
1 выключатель TRÅDFRI
1 мультисенсор Xiaomi
1 диммер Philips
Я могу запускать события с помощью диммера Philips.
Те, у которых есть соединения, довольно близки к палке Конби. Палка находится в гараже. У меня в гараже есть лампочки, к которым нет подключения.

Нет связи с
Очень много лампочек ikea, как E27, так и GU10
Много мультисенсоров Xiaomi
Много пультов дистанционного управления Ikea TRÅDFRI
И другие узлы.

Журналы
27 фев, 09:29:06 raspberrypi systemd [1]: Запущен deCONZ: ZigBee gateway - GUI / REST API.
27 фев, 09:29:06 raspberrypi deCONZ [7204]: предупреждение libEGL: DRI2: не удалось пройти аутентификацию
27 фев, 09:29:06 raspberrypi deCONZ [7204]: предупреждение libpng: iCCP: известен неверный профиль sRGB

При переходе на 264A0700 он начинает строить сетку напрямую.

@ebaauw , правильно ли я помню, что вы проводили много этих расследований поведения координатора ИКЕА? Он тоже так делает?

Я добавил поддержку большинства устройств Trådfri, но мне не удалось перехватить трафик ZigBee в / из концентратора Trådfri. Он использует только сопряжение сенсорных ссылок, и мне еще предстоит попытаться захватить это, чтобы восстановить сетевой ключ. То есть, если это вообще возможно.

Правильно, извините. Надо было проверить git blame. Код, который упоминает поведение шлюза IKEA, был фактически введен в 48d2c39a267b5c6d025577eed7530be27932aa2c пользователем @manup ...

@manup , вы действительно определили, что шлюз IKEA часто перенастраивает атрибут, сообщающий об этом? Почему потребуется перенастройка; нужно ли регулярно напоминать о свете?

Обновлен Conbee I до beta FW и deCONZ .74

Сетка сразу строится и выглядит очень красиво!

Большое спасибо @djwlindenaar . Я очень впечатлен тем, что вы пришли из ниоткуда и обнаружили такие серьезные ошибки. И, конечно, спасибо

Conbee I и .74 тоже. Обновил Ikea FW до 2.3.007 (некоторые другие 2.x).
Большое улучшение! Пока нет отсева!

Большое спасибо всем, кто вносит свой вклад, занимается разработкой, отладкой и тестированием в этой теме и за ее пределами.

Кое-что я узнал в процессе:
Обычное групповое включение-выключение работает быстро, но после вызова сцены (после постепенного исчезновения) и ее повторного выключения (<10 секунд) огни гаснут только в графическом интерфейсе (независимо от старого или нового интерфейса). Затем некоторые из них снова включаются. (в графическом интерфейсе) в группе, пока ВСЕ физические лампочки все еще горят. После второго или третьего нажатия OFF они иногда темнеют.

Восстановление / пересборка сцен после обновления прошивки - не редкость.
Но независимо от того, создаю ли я новую сцену или пытаюсь исправить старую, поведение остается прежним. Нормальное включение-выключение не влияет.

Я обнаружил, что он работает как обычно, когда я немного подождал. Скажем 15-20 секунд. Затем свет гаснет как обычно. Я предполагаю, что деконз запутается, как когда вы выключаете свет, пока он не исчезнет.

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

Я потестил еще немного. У нас есть изменение поведения. Раньше, когда bri изменялся с заданной скоростью или сцена имела более длительное время перехода, можно было прервать новую команду. Даже предыдущее действие все равно было выполнено, следующая команда была поставлена ​​в очередь. Теперь это потеряно. Напольные светильники Egmy управляются датчиком движения. Прежде чем они исчезнут, я затемняю их и жду 10 секунд, прежде чем выключить. Когда я запускал движение и вспоминаю сцену, пока они исчезают, команда теряется. До этого он был поставлен в очередь, а затем исполнялся. Это связано с. 74 или новая прошивка? благодаря

My Conbee II не создавал сетку в бета-версии. Единственное, о чем я могу думать, что может отличаться от "обычных" настроек, это установка канала на 25. Возвращение к 264a0700 исправило это.

@realwax , я думаю, вы столкнулись с ошибкой прошивки Trådfri, см. №2068. Вы можете легко убедиться в этом, введя в графическом интерфейсе команду с более длительным временем перехода, а затем введя вторую команду.

До этого он был поставлен в очередь, а затем исполнялся.

Прошивку лайта обновляли? Вы уверены, что используете тот же свет? Плагин REST API не отслеживает время перехода после того, как он отправил команду на свет.

@ebaauw Спасибо, что

Интересно, как IKEA справляется со своим собственным мостом, потому что это большая проблема удобства использования.

Хаб Trådfri гораздо менее активен, чем шлюз deCONZ или мост Hue. Контроллеры Trådfri (переключатели, диммеры, а также их датчики движения) напрямую управляют освещением. Индикаторы Trådfri отправляют на хаб push-уведомления с изменениями состояния. Хаб нужен / используется только для их приложения. Он может запускать некоторые аварийные сигналы, но не иметь правил для обработки событий кнопок или чего-то особенного.

Я не уверен, поддерживает ли приложение Trådfri даже указание более продолжительного времени перехода, но контроллеры, которые я видел, не поддерживают. Вероятно, вы не сможете отправлять команды от контроллеров быстрее, чем время перехода света по умолчанию. И если вы это делаете иногда, вы, вероятно, думаете, что не полностью нажали кнопку.

@ebaauw Понятно . Что меня до сих пор озадачивает, так это то, что я могу включать и выключать группу E14 (обеспечивая некую легкую дискотеку;)) в течение 1 секунды (вкл-выкл-вкл) работает! Но как только я нажимаю кнопку вызова сцены в деконе, я не могу, и поведение становится странным. Вот где я почему-то сомневаюсь, что это вина IKEA. Почему я могу включаться и выключаться очень быстро, но как только я вспоминаю сцену, я застреваю как минимум на 5-10 секунд?

Точно отмеренное время (20 попыток):
группа из 8 Е14
группа ВКЛ -> группа ВЫКЛ - время переключения 1 секунда
вспомнить сцену -> включить -> выключить, не отвечает до 10-12 секунд!

Я понимаю, что с отзывом создается больше трафика, и каждая лампочка получает больше сообщений, но разница в 10 секунд? Даже когда я меняю bri и ct для всей группы, я могу выключить его за секунду, но, опять же, отзыв подобен зависанию. Я думаю, это проблема деконца, не так ли?

Я могу записать это на видео. ;) Может быть, мне здесь не хватает знаний, тогда, пожалуйста, извините, что я не понимаю, но я как-то расстроен, потому что это борьба ...

Боюсь, я все еще немного запутался в сценах. Как и группы, они не существуют как объект в ZigBee, это просто номер, под которым устройство (свет) сохраняет состояние. При вызове сцены номер передается, и каждое устройство восстанавливает состояние из своей энергонезависимой памяти.

Нечеткая часть заключается в том, что не все устройства, кажется, правильно сохраняют свое состояние при сохранении сцены: в этом отношении цветовая температура печально известна. Я также видел забавные вещи, сохраняющие сцену, пока свет все еще находится в переходе. В этом случае ресурс /scenes не синхронизирован с состоянием, хранящимся в источнике света, в результате чего API отражает состояние ресурса вместо фактического состояния освещения, которое будет обновлено только при следующем включении источника света. опрошены. Обычно время перехода указывается при вызове сцены, но, похоже, оно также находится в сохраненном состоянии.

Я написал сценарий настройки моей производственной сети (используя ph ), поэтому я могу легко воссоздать ее. Мне было очень трудно написать сценарий создания сцен предсказуемым образом. Я закончил тем, что установил световые состояния, засыпал пару секунд, ждал, пока состояния установятся, сохраняю сцену и снова сплю пару секунд, ожидая сохранения состояния.

Вы можете попробовать воссоздать сцену, но никаких гарантий ...

Я мог воспроизвести рассинхронизированную тему с первого дня. Я привык к деконсу и необходимости время от времени менять конфигурацию сцены. Сейчас действительно хуже. В настоящее время мне нужно будет передать исходный код из deconz в iobroker и перестроить там все мои сцены. Но это большая работа. Надеюсь, это будет исправлено. Могу я создать проблему? Свет больше не надежен при использовании сцен ... - Я тоже пытаюсь воссоздать. Вчера я сделал "тестовую" сцену в дополнение к уже существующим, но она не показала другого поведения.

Не уверен, связано ли это, но после обновления моего Conbee I до бета-прошивки и deCONZ до .74 потребовался один день, и теперь deCONZ потерял соединение с Conbee. Никогда раньше не испытывал этого ... Но я хотел бы упомянуть об этом ... В журнале только что указывалось, что попытки подключиться к нему снова и снова ... Перезапуск deCONZ решил это ... (с использованием контейнера докеров)

Я просто попытался воссоздать группу, все сцены ... В процессе создания происходит так много ошибок. При использовании Phoscon и выборе лампочек «ВСЕ» значения сцен не сохраняются должным образом. Даже настроенные индикаторы показывают то, что вы хотите, а отзыв - нет. Вы должны управлять каждым светом отдельно, даже если вы выбираете одинаковые настройки. В частности, старый графический интерфейс должен использоваться для исправления ошибок цветовой температуры неправильно сохраненных цветов. Пока сцена не «заработает», вам придется повторить это пару раз, возможно, включать и выключать свет в процессе настройки сцены, чтобы она сохранялась должным образом. У меня здесь не так много технических деталей, но я хочу призвать всех вас в теме протестировать сцены, создание, хранение, вспомнить и выключить после отзыва. Я думаю, что это испорчено с лампочками IKEA, и становится еще хуже ... Может, это с IKEA, но я сомневаюсь, как и все остальное, и прямое групповое управление работает как шарм с deconz.

Я сейчас откат / понизлю прошивку до 1.x и посмотрю, работает ли она лучше. Я отчитаюсь.

ХОРОШО. Вернуться к доске для рисования. Вчера 2 светильника IKEA взяли отпуск только для того, чтобы вернуться после включения и выключения питания. Я не говорю, что исправленные ошибки не были ошибками. Они были. Только не те, которые вызывают проблему.

Я более глубоко изучил тему отчетов по атрибутам. Мне было интересно, не вызывает ли повторяющаяся настройка отчета об атрибутах каждые 30 минут (1800 с) зависания микропрограммного обеспечения.
Я заметил этот фрагмент кода, который явно не обрабатывает rq.maxinterval == 0 . Теперь, как правильно обработать этот случай, немного сложно, поскольку rq.maxinterval == 0 означает, что свет будет сообщать только об изменении, поэтому для этого случая нет `` хорошего '' тайм-аута ... Может быть, текущая реализация в порядке, хотя Интересно, может ли существовать лучшая идея.

bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt, const std::vector<ConfigureReportingRequest> &requests)
{
<hidden>
        if (val.clusterId == bt.binding.clusterId)
        {
            // value exists
            if (val.timestampLastReport.isValid() &&
                val.timestampLastReport.secsTo(now) < qMin((rq.maxInterval * 3), 1800))
            {
                DBG_Printf(DBG_INFO, "skip configure report for cluster: 0x%04X attr: 0x%04X of node 0x%016llX (seems to be active)\n",
                           bt.binding.clusterId, rq.attributeId, bt.restNode->address().ext());
            }
 ```

I Did some experiments, including asking the IKEA lights to report `ONOFF` and `LEVEL` periodically instead of only when a change is made. The lights happily report their status periodically, so that may be an acceptable way to avoid the above issue. To be verified properly of course.

Anyway, while doing these experiments, I stumbled upon an actual bug. I noticed the magical Default Response Command being returned whenever the IKEA lights now report their attributes. So I looked into what that thing is. Apparently that is supposed to conclude an ZCL/APS transaction when requested. There's a bit in the ZCL packet which dictates whether or not it should be sent `Disable Default Response`.

For attribute reports these are handled nicely by deCONZ

№ Время Источник Передача Dev Получение Dev Назначение Отключить Ответ по умолчанию Информация
208134 10 ч. 43 мин. 23,151 с. Gang 1 Gang 1 DeConz DeConz False ZCL: Report Attributes, Seq: 15
208136 10 ч. 43 мин. 23,158 с. DeConz DeConz Gang 1 Gang 1 APS: Ack, Dst Endpt: 1, Src Endpt: 1
208138 10 ч. 43 мин. 23,212 сек. DeConz DeConz Gang 1 Gang 1 True ZCL: ответ по умолчанию, Seq: 15

However for Configure Reporting Response command, deCONZ fails to send the Default Response. I'm not sure how the IKEA lights handle this situation, but it may be a cause for a memory leak. Remembering that the Default Response is a kind of closure of the transaction, it may be that the firmware only releases a certain amount of memory after it is received.

№ Время Источник Передача Dev Получение Dev Назначение Отключить Ответ по умолчанию Информация
207941 10 ч. 43 мин. 8,422 DeConz DeConz Gang 1 Gang 1 True ZCL: настройка отчетов, Seq: 41
207949 10 ч. 43 мин. 8,481 Группа 1 Группа 1 DeConz DeConz False ZCL: настройка ответа на отчет, последовательность: 41
207951 10 ч. 43 мин. 8.485 Группа 1 Группа 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1
207952 10ч. 43м. 8.487 DeConz DeConz Gang 1 Gang 1 APS: Ack, Dst Endpt: 1, Src Endpt: 1
207954 10 ч. 43 мин. 8.493 Группа 1 Группа 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1

I'm going to test this hypothesis with this patch in place:
```diff
diff --git a/bindings.cpp b/bindings.cpp
index 9607b09..0c2b5fc 100644
--- a/bindings.cpp
+++ b/bindings.cpp
@@ -443,6 +443,12 @@ void DeRestPluginPrivate::handleZclConfigureReportingResponseIndication(const de
         allNodes.push_back(&l);
     }

+    // send DefaultResponse if not disabled
+    if (!(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
+    {
+        sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
+    }
+
     for (RestNodeBase * restNode : allNodes)
     {
         if (restNode->address().ext() != ind.srcAddress().ext())

Я заметил этот фрагмент кода, который явно не обрабатывает rq.maxinterval == 0. Теперь, как правильно обработать этот случай, немного сложно, поскольку rq.maxinterval == 0 означает, что свет будет сообщать только об изменении, поэтому для этого случая нет `` хорошего '' тайм-аута ... Может быть, текущая реализация в порядке, хотя Интересно, может ли существовать лучшая идея.

Да, плагин REST API проверяет, работает ли отчет по атрибутам. Если нет, он пытается перенастроить его и, я думаю, также возвращается к опросу устройства.

Я провел несколько экспериментов, в том числе попросил индикаторы IKEA периодически сообщать ONOFF и LEVEL, а не только при внесении изменений. Светильники периодически сообщают о своем состоянии, так что это может быть приемлемым способом избежать вышеуказанной проблемы. Для проверки, конечно.

Я думаю, что мы использовали эту настройку довольно долгое время. Он был изменен вместе с менее частым опросом соседних таблиц и прекращением опроса состояния, потому что некоторая прошивка Trådfri зависала (требовалось выключить и выключить свет). Я сомневаюсь, что настройка отчетов действительно способствовала сбою прошивки.

В пакете ZCL есть бит, который определяет, следует ли его отправлять Disable Default Response .

Я не думаю, что отправка ответа по умолчанию принесет столько вреда, когда установлен бит Disable Default Response . Отказ от отправки ответа по умолчанию, когда бит не установлен, нанесет вред, поскольку устройство, ожидающее ответа, может решить, что координатор больше недоступен, и в конечном итоге покинуть сеть.

В пакете ZCL есть бит, который определяет, следует ли его отправлять Disable Default Response .

Я не думаю, что отправка ответа по умолчанию принесет столько вреда, когда установлен бит Disable Default Response . Отказ от отправки ответа по умолчанию, когда бит не установлен, нанесет вред, поскольку устройство, ожидающее ответа, может решить, что координатор больше недоступен, и в конечном итоге покинуть сеть.

@ebaauw , действительно. В том-то и дело. deCONZ не может отправить Default Response в ответ на Configure Reporting Response . Бывает, что светильники IKEA запрашивают Default Response за Configure Reporting Response .
Итак, как вы говорите, это может быть причиной того, что в сочетании с Configure Reporting Request каждые полчаса свет IKEA гаснет.

Просто напоминание:
Лампы Ikea (E27 и GU10 v1) иногда становятся недоступными, и им также требуется цикл питания при подключении к мосту HUE, поэтому эта конкретная проблема не является уникальной для Conbee I / II
Из 16 E27 и 12 GU10 на моем мосту HUE, я бы сказал, одна лампочка "зависает" примерно за 1-2 недели. Иногда дольше, иногда быстрее. Эта проблема устранена в последних выпусках прошивки HUE за последние полтора года.

@all Какую версию прошивки Tradfri вы используете?

Вы используете 1.x или 2.x? В версии 2.x они представили zigbee 3.0. Я обновился до 2.x и начались проблемы. Лампочки Е14. Я заметил улучшения в отношении скорости сети и возможности подключения. Но две вещи заставили меня откатиться на 20 лампочек вздохнул "Мягкое включение" больше не работало. Лампочки включались без угасания. Сцены не работали, как раньше. Точнее говоря, после вызова сцены требовалось время ожидания перед выключением света или вызовом следующего szene, в противном случае deconz переходил в асинхронный режим и повторно синхронизировался, в то время как лампа не выполняла никаких действий.

Я ценю ваш совместный опыт работы с версиями и безупречностью версии 2.x, кажется, не дано.

Есть рекомендация? FW v.? Помимо проблемы с потерей соединения и проблем с соединением в самой Ikea, похоже, что deconz может справиться с 1.x лучше.

Благодаря!

Я использую:

• Conbee 1 с прошивкой 0x26340500
• Deconz версии 2.05.73 (с использованием контейнера докеров marthoc в Debian)
• ~ 60 узлов, в основном IKEA Trådfri
• Conbee 1 (координатор) НЕ устанавливается централизованно в моем доме площадью 200 квадратных метров. Система сильно зависит от роуминга и создания сетей.
• Накопитель Conbee 1 устанавливается на удлинительном USB-кабеле длиной 0,5 метра и монтируется на той стороне полки, где находится компьютер, чтобы было больше свободного места для РЧ сигналов.

С момента обновления (в тот же день, когда было выпущено) прошивка Conbee 1 Sticks deconz работает как шарм ! Никаких проблем ни с чем.

Вчера обновил мою производственную сеть (RPi 3B +, stretch, RaspBee) до 2.05.74 и 0x26340500. Кажется стабильным, за исключением перечисленных ниже проблем.

Не уверен, связано ли это, но маршрут к моему контроллеру шторки lumi.curtain был потерян сегодня утром. Отчеты контроллера все равно будут доходить до шлюза. Маршрут не восстанавливается при выключении и включении контроллера. Мне пришлось открыть сеть и выключить и снова включить контроллер, прежде чем координатор снова подключится к нему.

Кроме того, один из моих радиаторных клапанов Eurotronic Spirit был недоступен для deCONZ после запуска deCONZ, но все еще отправлял отчеты. Включение и выключение питания TRV, как обычно, вернуло его обратно.

На этот раз у меня не было возможности провести какое-либо глубокое расследование, но оба устройства были проблемными с самого начала, время от времени проявляя эти симптомы. То же самое с моей шторкой IKEA Fyrtur. Я буду продолжать следить за ситуацией и сообщать, если у меня возникнут новые проблемы.

@tubalainen
Какую прошивку вы используете на своих лампочках tradfri? Насколько я тестировал, это имеет значение даже в этой теме в отношении проблемы потери соединения. Мои результаты заключаются в том, что предпринятые здесь шаги улучшили работу ламп tradfri с управлением 1.x на Conbee 1. Но сеть из 20 e14 с tradfri fw 2.3.x - беспорядок. Тайминги, сцены застревают, разгоняется, свет начинает мигать (потерялся?), .. как сообщалось выше. Я думаю, что этот момент следует обсудить и упомянуть, чтобы дать четкую рекомендацию по использованию ikea fw для получения хорошего опыта. Может быть, уже есть статья о git. Но по моему опыту не обновляйтесь 😅

Так что с моей точки зрения и часы тестирования и перепрошивки. Спасибо за улучшение ikea fws 1.x! Можно ли решить текущие проблемы при использовании 2.x? В противном случае в настоящее время невозможно будет перейти на zigbee 3 с помощью ikea. Похоже, что поведение изменилось, и управление ими в деконце необходимо адаптировать. Это, наверное, для того, чтобы разбирался ?

Ура
Хорошего воскресенья 😊

@realwax
Я попытался обновить прошивку всех своих объектов до последней прошивки. Вот мой список всех (активных на данный момент) узлов.

Договорились о неразберихе со всеми «движущимися частями», одновременно пытаясь пригвоздить первопричину проблем.

@tubalainen

Спасибо за ваш список.

Глядя особенно на маршрутизаторы (лампочки), я вижу, что вы используете 2.3.007 на своих E14. Вы можете воспроизвести мой список проблем. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Поскольку я не знал об автоматическом обновлении прошивки до 2.3.x, моя сеть была смешана с 1.x и 2.x не очень хорошо. Я вручную обновился до 2.3.x, а потом стало еще хуже. (Сеть быстрее, но большое удобство использования и выпадение мигающих лампочек) Так что я могу порекомендовать, если вы испытываете мигание лампочек на вашем e14 или "задержку" на сценариях, понизьте их до 1.2 ... Мне было бы интересно получить "официальный" / профессиональное заявление от наших профессиональных разработчиков по этому поводу. Я почти уверен, что было время, когда deconz обрабатывали 1.2 аналогичным образом и улучшали его. Я чувствую, что это нужно сделать и для 2.3.x, иначе Ikea все испортила самостоятельно. Сложно сказать, так как я не разбираюсь в коде.

@realwax
Я использую функцию otau программы deconz и ее скрипт обновления прошивки для загрузки файлов fw.
Я не знаю, почему не обновляются Е14 ... угу.

Как вы "вручную" обновляли / понижали лампочки?

Ну ну. Все работает нормально, и большая часть маршрутизации выполняется E27 с fw 2.3.x и драйверами панелей Jormen и FLOALT.

@tubalainen
Интересно, что у вас нет таких проблем. Может это из-за размера ячеек. У меня 23 лампочки от той 20 е14 на 2.3.007. Я отключил автоматический отау, поскольку он мешал мне использовать новую прошивку. Через Gui вы можете перейти на более раннюю версию, нажав кнопку обновления. Сначала выберите подходящую прошивку, нажмите обновить и, возможно, еще раз. Состояние формы приостановлено -> в очереди -> бездействует -> начать обновление прошивки (в процентах). Иногда зависает. Иногда требуется перезагрузка. Иногда достаточно силового цикла. Иногда нужно поднести лампочку ближе к координатору.

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

Не уверен, что вы здесь имеете в виду. Я исправил некоторые различия между прошивками ZLL и ZB3 для контроллеров (пульт Trådfri и беспроводной диммер Trådfri), см. №2485. Это находится на уровне APS в стеке ZigBee и обрабатывается плагином REST API.

Проблемы маршрутизации из этого раздела относятся к уровню NWK, который решается микропрограммой устройства. Как и у всех здесь, у меня нет доступа к источникам прошивки. Даже если бы я сделал это, я ничего не мог бы сделать, поскольку я не знаю деталей уровней NWK и MAC.

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Точно говоря. Я включил сюда свои результаты с сеткой 20 E14 2.3.007. Некоторые функции исчезли, и вызов сцены в значительной степени портит все на 10-15 секунд в этой группе. Я не знаю, связано ли это только с прошивкой или с деконзированием. Это то, что я имел в виду, говоря об изменениях. Так что для повседневной эксплуатации я считаю 2.3.007 бесполезным. Приведен пример удобства использования: простой переключатель поворота сцены, настроенный в фосконе, больше не работает, если не нажимать осторожно, что означает ожидание после поворота сцены. В то время как в 1.x все работает быстро и нормально, в 2.3.x оно застревает.

Спасибо, @manup , только что установил. Посмотрим, что это принесет.
Хотя я ожидаю, что это принесет некоторые улучшения, как вы относитесь к прошивке DeConz, игнорирующей записанные маршруты (из-за маршрутизации mane-to-one)? В общем, я убедился, что записанные маршруты намного логичнее, чем те, что используются прошивкой DeConz.
Хотя я могу представить, что включение маршрутизации от источника - это большая работа, прошивка DeConz может (должна?) По-прежнему использовать информацию из пакета записи маршрута для обновления первого перехода к устройству. Может быть, просто проверьте, совпадает ли последний переход к координатору с тем, что хранится в таблице маршрутизации, и если нет, сделайте запись в таблице маршрутизации недействительной. Я не уверен, можно ли заменить запись последним переходом из записанного маршрута, поскольку устройства по пути, вероятно, игнорируют информацию, но, по крайней мере, это может инициировать обнаружение нового маршрута для этого узла с помощью прошивки DeConz.
Что Вы думаете об этом?

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

@manup , ты нашел время посмотреть на это? Сегодня утром я обнаружил ситуацию, когда я включил и снова включил свет (IKEA), который находился в 4 прыжках от координатора. Каким-то образом промежуточный маршрутизатор (также IKEA) решил, что он больше не знает пути к этому свету. На самом деле я вижу, что светильник успешно выполняет свою работу по маршрутизации для других источников света, сообщает о состоянии канала и отвечает на Network Address Request от deCONZ. Последнее происходит только потому, что это широковещательные сообщения в сети ..!
Однако промежуточный маршрутизатор молча отбрасывает все одноадресные кадры, которые он должен направить на этот свет. Этот маршрутизатор, конечно, не должен молча сбрасывать их, но, опять же, deCONZ должен быть устойчивым к этому плохому поведению.
В то же время, индикатор также успешно отправляет сообщения записи маршрута в deCONZ, которые поступают и игнорируются deCONZ.

Я думаю, что должна быть какая-то логика, которая должна заставить deCONZ пересмотреть свои маршруты в этом случае. Особенно, когда он обнаруживает, что на запросы ZCL не отвечают. Что в конечном итоге приводит к тому, что свет помечается как зомби. Открытие, которое следует за пометкой как зомби, на самом деле приводит к ответу света. Может быть, когда начинается обнаружение зомби, оно также должно аннулировать любую доступную информацию о маршруте. Но даже лучше, если уже раньше маршрут становится недействительным, когда на пару запросов ZCL не отвечают (возможно, уже после первого или второго из них).

Что Вы думаете об этом?

Эта новая прошивка не решила мою проблему.

Я использую Raspbee на отдельном Pi и Home Assistant (работающем на NUC) и имею appx. 25 фонарей tradfri. В основном GU10 используется группами по 3 человека.

У меня были большие проблемы с одиночными лампами в группе источников света, которые не отвечали, и мне требовалось, чтобы цикл питания снова вернулся. Это произошло как с Ikea FW v1, так и после обновления лампочек до 2.3.007.

Решением было изменить мою конфигурацию с группировки источников света в HASS на определение групп источников света в Phoscon и ссылку на группы Phoscon как отдельные источники света в HASS. После этого изменения уже пару месяцев работаю без проблем.

Я действительно хочу иметь возможность выполнять группировку в HASS, поэтому я обновил свой Raspbee до 0x26340500 и Deconz до 2.05.74 и снова изменил свою конфигурацию на использование световых групп в HASS. После того, как я запустил это в течение недели, у меня 3 или 4 раза возникали устаревшие лампочки, и теперь я снова переключаюсь на использование групп Phoscon.

Я думаю, что должна быть какая-то логика, которая должна заставить deCONZ пересмотреть свои маршруты в этом случае. Особенно, когда он обнаруживает, что на запросы ZCL не отвечают. Что в конечном итоге приводит к тому, что свет помечается как зомби. Открытие, которое следует за пометкой как зомби, на самом деле приводит к ответу света. Может быть, когда начинается обнаружение зомби, оно также должно аннулировать любую доступную информацию о маршруте. Но даже лучше, если уже раньше маршрут становится недействительным, когда на пару запросов ZCL не отвечают (возможно, уже после первого или второго из них).

Я все еще использую новую прошивку и тестирую несколько вещей, включая записи маршрутов, надеюсь, что на этой неделе я выложу ее в Интернете.

Что Вы думаете об этом?

Это хороший момент, мне нужно проверить здесь ядро ​​и код плагина REST-API, так как я думаю, что прошивка должна ухудшить «качество» маршрута уже тогда, когда не получено ACK уровня APS. APS ACK - это флаг, который дополнительно устанавливается в запросах ZCL / APS и часто отключается для снижения сетевого трафика. Итак, приблизительная идея состоит в том, что мы должны включить APS ACK, если плагин обнаруживает, что одноадресные запросы приводят к тайм-аутам.

Возможно, часть этого уже на месте, нужно проверить код.

Однако промежуточный маршрутизатор молча отбрасывает все одноадресные кадры, которые он должен направить на этот свет. Этот маршрутизатор, конечно, не должен молча сбрасывать их, но, опять же, deCONZ должен быть устойчивым к этому плохому поведению.

Свет должен указывать новый маршрут, как только запускается обнаружение нового маршрута. Таким образом, целью должно быть как можно более быстрое обнаружение нарушенного маршрута (надеюсь, APS ACK поможет) и запуск обнаружения маршрута.

Конечный автомат для этого уже находится в ядре deCONZ (это то, что приводит к широковещательной рассылке запроса адреса NWK), это работает в случае односкачковых ссылок и для источников света, которые выбирают маршруты на основе входящих команд (ответ на трансляция). Широковещательная рассылка хороша, поскольку она также учитывает изменение адреса NWK, поскольку включен MAC-адрес. Я попытаюсь отправить одноадресную рассылку с включенным APS ACK в качестве следующего шага, если ответа не будет.

К сожалению, вчера мне пришлось выключить и снова включить лампочку IKEA E27 (белая 1000LM, прошивка v1). Он реагировал только на групповые, но не на одноадресные команды. Кажется, проблема еще не решена :(

(и да, я на v74 и бета прошивке для RaspBee)

См. Комментарии выше, следующие изменения могут помочь восстановить маршрутизацию.

Что Вы думаете об этом?

Это хороший момент, мне нужно проверить здесь ядро ​​и код плагина REST-API, так как я думаю, что прошивка должна ухудшить «качество» маршрута уже тогда, когда не получено ACK уровня APS. APS ACK - это флаг, который дополнительно устанавливается в запросах ZCL / APS и часто отключается для снижения сетевого трафика. Итак, приблизительная идея состоит в том, что мы должны включить APS ACK, если плагин обнаруживает, что одноадресные запросы приводят к тайм-аутам.

Возможно, часть этого уже на месте, нужно проверить код.

Похоже, что даже когда бит запроса APS ACK установлен, deCONZ ничего не делает с отсутствующим подтверждением (только одна попытка, а затем ничего ...)

BTW houtlamp 2 - это тот, кто отбрасывает пакеты, направленные на Tuin linksvoor 2

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
245915  10h 28m 42.108501s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245
245922  10h 28m 46.033452s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False

        .1.. .... = Acknowledgement Request: True

        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 107

Однако промежуточный маршрутизатор молча отбрасывает все одноадресные кадры, которые он должен направить на этот свет. Этот маршрутизатор, конечно, не должен молча сбрасывать их, но, опять же, deCONZ должен быть устойчивым к этому плохому поведению.

Свет должен указывать новый маршрут, как только запускается обнаружение нового маршрута. Таким образом, целью должно быть как можно более быстрое обнаружение нарушенного маршрута (надеюсь, APS ACK поможет) и запуск обнаружения маршрута.

Конечный автомат для этого уже находится в ядре deCONZ (это то, что приводит к широковещательной рассылке запроса адреса NWK), это работает в случае односкачковых ссылок и для источников света, которые выбирают маршруты на основе входящих команд (ответ на трансляция). Широковещательная рассылка хороша, поскольку она также учитывает изменение адреса NWK, поскольку включен MAC-адрес. Я попытаюсь отправить одноадресную рассылку с включенным APS ACK в качестве следующего шага, если ответа не будет.

Фактически, houtlamp 2 никогда не видит ответа на широковещательную передачу address request . Сообщения в deCONZ маршрутизируются через tuin linksvoor 3 , поэтому даже если houtlamp 2 выберет этот маршрут, у него никогда не будет шанса. Это снова вызвано тем, что deCONZ не выбирает route record в качестве нового маршрута.

ZigBee Network Layer Command, Dst: DeConz, Src: Tuin link
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0x0ea5[Tuin linksvoor 2]
    Radius: 29
    Sequence Number: 51
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: EnergyMi_ff:fe:e9:91:86 (d0:cf:5e:ff:fe:e9:91:86)
    ZigBee Security Header
    Command Frame: Route Record
        Command Identifier: Route Record (0x05)
        Relay Count: 1
        Relay Device 1: 0xc9fa[Tuin linksvoor 3]

Теперь Tuin linksvoor 2 отправляет ответ на широковещательную рассылку network address request и преуспевает, но APS ACK от deCONZ никогда не достигает Tuin linksvoor 2 , так как его отбрасывает houtlamp 2 . Таким образом, он отправляет несколько раз, прежде чем отказаться. Это будет иметь хороший шанс испортить Tuin linksvoor 2 .

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
246199  10h 29m  1.496384s  Tuin linksvoor 2    Tuin linksvoor 3    DeConz  DeConz      Network Address Response, Status: Success, Address: EnergyMi_ff:fe:e9:91:86 = 0x0ea5
246201  10h 29m  1.502056s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2        APS: Ack, Dst Endpt: 0, Src Endpt: 0

Conbee 1 + последняя версия fw + .74 не играет на 100%.
Было довольно много попаданий / промахов. Мне кажется, что с .73 лучше работает, но не на 100%.

Итак, вернемся к чертежной доске. С новой (бета) версией Conbee 1 fw все еще не все в порядке.

Через пару дней эксплуатации с .74 и 26340500 на Conbee 1 на Tradfir E14 с прошивкой 1.2.221 могу сообщить, что:

Свет IKEA стал более стабильным в плане отключения от сети, хотя у меня была только одна лампочка, которая потерялась за 4 дня. Я также узнал, что если вы сильно напрягаете свою сеть zigbee, управляемую deconz, работающую на E14 fw 1.2.221. Я запустил скрипт, который погаснет, отправляя отдельные запросы с измененным bri каждую секунду. Таким образом я очень быстро потерял 4 лампочки. Но кто все равно этого хочет;)

Все еще не решено:
Проблема и беспокойство, которые у меня есть, заключаются в том, что Tradfri FW 2.3.x не работает должным образом или плохо реализован для использования с deconz. Это нормально - оставаться на tradfri fw 1.2.x и не переходить на zigbee 3.0. Но наступит момент, которого нельзя будет избежать. Или, боюсь, новые лампочки будут понижены в цене.
Я обнаружил, что группа из 2-3 луковиц не так сильно проявляет эту проблему, как группа из 4-8 луковиц.
Я сообщил о своей находке здесь, и я счастлив и благодарен, если ее подберут. Я попытался повысить осведомленность здесь https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
поскольку я могу воспроизвести эту проблему, просто перепрошив всю мою лампочку на 2.3.x, и я надеюсь, что вы тоже сможете это сделать.

Итог - это имеет значение, какая прошивка tradfri используется и о которой идет речь. Существует огромная разница в удобстве использования и проблемах, возникающих при работе с deconz. Хотя прошивки 1.2.x, скорее всего, старше и работают как шарм рядом с известными выпадами, 2.3.x не потерял удобство использования, как описано в поднятом вопросе. Не могу представить, что я единственный, кто испытывает такую ​​разницу в FW.

Теперь я отправил электронное письмо в службу поддержки dresden elektronik на немецком языке, чтобы привлечь внимание к этому, поскольку я понял, что некоторые из вас увлекаются хобби, как

Прошивка Conbee II теперь тоже исправлена? Я видел в выпуске только Conbee I. Кстати, спасибо всем за вашу тяжелую работу.

Это снова вызвано тем, что deCONZ не принимает запись маршрута в качестве нового маршрута.

@djwlindenaar, оказывается, виноват я здесь, я проверил коммиты кода Route Record в репозитории стека (ConBee I и RaspBee I). В 2018 году я добавил «исправление» (или я так думал) для аналогичной проблемы, которая просто отключила обновление адреса следующего перехода во входящей записи маршрута.

Если мне не изменяет память, проблема в то время заключалась в том, что у нас была большая смешанная сеть из 150 узлов, и записи маршрутов, казалось, работали некорректно. Новый путь назад работал некорректно. Однако код мог работать с другим исправлением кодов ошибок команды состояния NWK.

Я верну это сейчас, поэтому запись маршрута должна обновить маршрут до лучшего пути.

Мне нравится этот абзац из спецификации Zigbee:

Маршрутизатор ZigBee или координатор ZigBee могут поддерживать таблицу маршрутизации. Информация, которая должна храниться в записи таблицы маршрутизации ZigBee, показана в таблице 3-66. Рекомендуемой практикой является устаревание и изъятие записей таблицы маршрутизации с целью повторного востребования табличного пространства из записей, которые больше не используются; однако это выходит за рамки данной спецификации.

Это означает, что каждый стек по-разному обрабатывает устаревание маршрута.

Итак, я проверил, как это работает в нашем случае. В стеке Bitcloud Zigbee маршруты имеют "скорость" маршрута, которая изначально равна 1.

1. При успешной передаче NWK скорость увеличивается, если она ниже максимума, который
   (1 << 8) - 1 = 255
2. При успешной передаче NWK, если достигается максимальное значение 255, все записи таблицы маршрутизации становятся "нормализованными".
   rate = (rate >> 1) + 1 (эффективно делится на 2, минимум 1)
3. При неудачной передаче NWK скорость записи соответствующего маршрута устанавливается как:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. При слишком большом количестве неудачных передач скорость становится 0 и маршрут удаляется.

Это означает, что верхняя ссылка ухудшится как:

255  top rate
127  first failed transmission
63   ...
31
15
7
3
1
0    the record gets removed

Следовательно, требуется 8 неудачных команд, пока запись не будет удалена и обнаружение не будет запущено снова.
Это нормально в обычных сетях, особенно когда они вырастают до 50..100 узлов, маршрут не следует отбрасывать слишком рано.

Меня беспокоит пункт (2), потому что, например, очень свежий маршрут или тот, который не используется, который часто будет ухудшаться из-за совершенно несвязанных высокопроизводительных узлов с хорошими ссылками, например, лампа Philips Hue, которая опрашивается каждые несколько секунд, будет trigger (2) довольно часто умножают это на количество источников света в большой сети. Не говоря уже об активных OTA-обновлениях.

Я думаю, что безопасно изменить (2), чтобы не ухудшать (нормализовать) все записи маршрута, а только верхний маршрут 255, связанный с успешной передачей. Это должно предотвратить потерю маршрутов, которые работали нормально, но не часто использовались и были удалены при первой неудачной передаче NWK.

Завтра я сделаю новую прошивку с этими изменениями, также одна для ConBee II, вероятно, там то же самое.

Я верну это сейчас, поэтому запись маршрута должна обновить маршрут до лучшего пути.

Окей, звучит хорошо. С нетерпением жду тестирования!

Мне нравится этот абзац из спецификации Zigbee:

Да, я полагаю, что такая спецификация мешает нам заставить всех поставщиков нормально сосуществовать. :улыбка:

В стеке Bitcloud Zigbee маршруты имеют "скорость" маршрута, которая изначально равна 1.

Я не совсем понимаю логику правила 2. Это похоже на версию старения для бедняков. Что работает нормально, если все узлы видят одинаковый объем трафика, но действительно, если он несбалансирован (что, я думаю, довольно часто), все пойдет не так.
Я заметил, что ZStack использует фактическое поле expiryTime в своей таблице маршрутизации рядом с байтом status .

3. On a failed NWK transmission the rate of the related route entry is set as:

Как это на самом деле работает?
Если я не ошибаюсь, неудачная передача NWK фактически означает только следующий переход, поскольку NWK проверяет только MAC ACK 802.15.4. Итак, чтобы проверить, в порядке ли сквозная передача, мы должны полагаться на APS ack. Это правильно? А в BitCloud так работает?
Также: если бит запроса подтверждения на уровне APS не установлен, считается ли это успешной передачей (поскольку не следует ожидать подтверждения) и увеличивает ли это «скорость» этой записи маршрута? Потому что в этом случае мы могли бы выстрелить себе в ногу, не запрашивая ACK уровня APS все время.

Если это основано только на сбоях NWK, то это не поможет в ситуации, когда промежуточный маршрутизатор ведет себя неправильно, и нам нужно добавить дополнительную логику, чтобы учесть не поступающие ACK уровня APS. Вероятно, на основе аналогичной логики для обнаружения маршрутизаторов «зомби», но сначала путем аннулирования записи в таблице маршрутов для этого маршрута.

Версия прошивки 0x26350500 для ConBee I и RaspBee I. доступна для тестирования.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26350500.bin.GCF

• Как и 0x26340500, все ошибки маршрута состояния NWK обрабатываются
• Исправьте нечестное ухудшение маршрута (см. Пункт 2. в https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• Исправить записи маршрута не обновляли следующий переход маршрута, обратите внимание, что теперь это будет работать, но только если текущая стоимость маршрута выше, когда запись маршрута
• Исправление неудачных запросов APS с включенным APS ACK не ухудшало маршрут

Теперь я смотрю код ConBee II, чтобы узнать, можно ли и где применить эти исправления. Отклонение 0x26520700 и 0x26530700 и основание этого на текущей стабильной версии 0x264a0700.

Я не совсем понимаю логику правила 2. Это похоже на версию старения для бедняков. Что работает нормально, если все узлы видят одинаковый объем трафика, но действительно, если он несбалансирован (что, я думаю, довольно часто), все пойдет не так.
Я заметил, что ZStack использует фактическое поле expiryTime в своей таблице маршрутизации рядом с байтом состояния.

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

Если это основано только на сбоях NWK, то это не поможет в ситуации, когда промежуточный маршрутизатор ведет себя неправильно, и нам нужно добавить дополнительную логику, чтобы учесть не поступающие ACK уровня APS. Вероятно, на основе аналогичной логики для обнаружения маршрутизаторов «зомби», но сначала путем аннулирования записи в таблице маршрутов для этого маршрута.

Казалось, что это так, и действительно, некорректно работающие маршрутизаторы, которые не отправляют команды состояния NWK с ошибками маршрута, могут поддерживать мертвый маршрут. Теперь это исправлено в 0x26350500, но оно зависит от команд с включенным APS ACK. Что должно быть в порядке и может управляться deCONz и плагином REST-API.

Версия прошивки 0x26350500 для ConBee I и RaspBee I. доступна для тестирования.

Прошил, сейчас тестирую.

Теперь это исправлено в 0x26350500, но оно зависит от команд с включенным APS ACK.

Что вы делаете в случае отсутствия ACK? Уменьшаете ли вы вдвое значение rate как при неудачной передаче NWK, или больше / иначе? Потому что я думаю, что недостающий APS ACK следует считать более серьезным по сравнению с неудачной передачей NWK. В противном случае, опять же, в случае некорректного поведения маршрутизатора, успешные передачи NWK могут увеличить rate больше, чем недостающие APS ACK уменьшат его.

Что вы делаете в случае отсутствия ACK? Уменьшаете ли вы вдвое значение скорости, как при неудачной передаче NWK, или больше / иначе? Потому что я думаю, что недостающий APS ACK следует считать более серьезным по сравнению с неудачной передачей NWK. В противном случае, опять же, в случае некорректного поведения маршрутизатора, успешные передачи NWK могут увеличить скорость больше, чем отсутствующие ACK APS снижают ее.

Я думал так же, вот что происходит в этом случае:

• Положительный MAC ACK при передаче NWK rate + 1
• Нет APS ACK rate = rate / 4

Таким образом, скорость падает довольно быстро, может быть слишком агрессивно, и rate / 2 достаточно, но давайте посмотрим, как это работает на практике.

Ницца. Я запустил и доложу.

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

Кстати, я также изменил код остального плагина, чтобы запрашивать APS ACK во всех сообщениях.

Я запускаю Deconz на Rpi 3B + с помощью Home Assistant
В настоящее время работает 2.05.75 с Conbee I и 26330500

Заметил, что в этот вечер некоторые огни не включались.
Пытался включить вручную, см. Логи ниже.
Проверил сетку VNC, она является частью ячеистой сети, но ни на что не реагирует.
Этот узел представляет собой сетевой выключатель Tradfri.

Странная вещь здесь:
_Я МОГУ включить переключатель при включении группы Deconz вместо отдельного переключателя. _

19: 23: 58: 979 задержка отправки запроса 57 dt 0 мс до 0x000D6FFFFEB1C9FF, ep: 0x01 кластер: 0x0004 onAir: 1
19: 24: 15: 744 Текущий канал 25
19: 24: 15: 776 Флаги TTL устройства 3920 с: 0x7
19: 24: 46: 764 0x000D6FFFFEB1C9FF ошибка APSDE-DATA.confirm: 0xA7 в задаче
19: 25: 10: 547 0x000D6FFFFEB1C9FF ошибка APSDE-DATA.confirm: 0xA7 в задаче
19: 25: 15: 749 Текущий канал 25
19: 25: 15: 782 Флаги TTL устройства 3860 с: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF ошибка APSDE-DATA.confirm: 0xA7 в задаче
19: 25: 49: 411 0x000D6FFFFEB1C9FF ошибка APSDE-DATA.confirm: 0xA7 в задаче
19: 26: 12: 765 0x000D6FFFFEB1C9FF ошибка APSDE-DATA.confirm: 0xA7 в задаче
19: 26: 12: 765 макс. Ошибок передачи для узла 0x000D6FFFFEB1C9FF, последний раз видели соседи 25 с
19: 26: 15: 742 Текущий канал 25
19: 26: 15: 774 Флаги TTL устройства 3800 с: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF ошибка APSDE-DATA.confirm: 0xA7 в задаче
19: 26: 48: 221 макс. Ошибка передачи для узла 0x000D6FFFFEB1C9FF, последний раз видели соседи 60 с
19: 27: 03: 845 сохраненное состояние узла за 9 мс
19: 27: 33: 634 sync () за 29789 мс

Последние исправления находятся в 26350500 ...

@djwlindenaar Я затаил дыхание в ожидании результатов ваших тестов :-)

Все идет нормально. Я вижу, как deCONZ радостно переключает маршруты. :улыбка:

Последние исправления находятся в 26350500 ...

Извините, неправильно прочитал версию FW.
Я хочу помочь с тестированием, используя официальное дополнение Home Assistant Deconz, но не знаю, как обновить его до бета-версии. (официальные обновления - OTA)

Уважаемый @manup , есть ли статус по обновлению прошивки Conbee ii?

@manup , похоже, что с Many-to-One Route Failure (0x0c) нет никаких действий. Я ожидаю, что deCONZ снова проведет MTORR (если он еще не начат). Я получаю эти сообщения регулярно.

Command Frame: Network Status
    Command Identifier: Network Status (0x03)
    Status Code: Many-to-One Route Failure (0x0c)
    Destination: 0x499e[Tuin rechtsachter 2]

@manup , похоже, что route record все еще не всегда передается deCONZ. Например:

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default Response              Acknowledgement Request               Info
700766             13h 27m 35.628249s Tuin linksvoor 2   Tuin linksvoor 2   DeConz             DeConz                                                   Route Record, Dst: 0x0000
700784             13h 27m 39.591343s DeConz             DeConz             WC lamp            Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700786             13h 27m 39.597002s DeConz             WC lamp            Tuin linksvoor 1   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700788             13h 27m 39.600699s DeConz             Tuin linksvoor 1   Tuin linksvoor 2   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162

Свет Tuin linksvoor 2 отправляется прямо на deCONZ , но путь от deCONZ проходит через несколько переходов ...
Было бы полезно, если бы вы могли дать некоторое представление о процессе принятия решения в deCONZ чтобы да / нет принять маршрут из сообщения route record .

--- отредактировал указанные ниже элементы, потому что в моих рассуждениях была ошибка. Надеюсь, теперь нет: wink: ---

Сказав это, маршрут, который использует deCONZ на самом деле намного более надежен, чем прямая связь с Tuin linksvoor 2 . Это заставило меня задуматься и изучить маршрутизацию "многие к одному". Я думаю, что, возможно, мощность передачи Распби не идеальна ...
Это мои рассуждения:

• Маршрутизация "многие к одному" основана на получении широковещательных сообщений.
• В отличие от обычной обработки маршрута, максимальная стоимость входящего и исходящего пути принимается в качестве стоимости следующего перехода.
• Теперь, если маршрутизатор или координатор намного лучше передает (высокая мощность передачи), чем прием (низкая чувствительность приема), это может привести к тому, что маршрутизация «многие к одному» не будет работать очень хорошо.

Еще я заметил, что deCONZ, похоже, (очень) оптимистично смотрит на входящую стоимость в своей таблице маршрутов. Когда Tuin linksvoor 2 отправляет сообщение deCONZ напрямую, ему все время требуется много повторных попыток. Теперь, если я загляну в таблицу маршрутизации, я вижу следующее, и я не ожидал бы сложной передачи при входящей стоимости 4. Обратите внимание, что в основном все элементы в таблице маршрутизации имеют гораздо более низкую входящую стоимость, чем исходящую.

Link 4
    Address: 0x0ea5[Tuin linksvoor 2]
    .... .100 = Incoming Cost: 4
    .111 .... = Outgoing Cost: 7

Так что, если бы deCONZ были менее оптимистичны в отношении входящей стоимости, мы могли бы увидеть лучшее поведение маршрута. Или, если бы мы увеличили мощность передачи, чтобы она была более сбалансированной (аналогичная стоимость для входящей и исходящей)
Или, если мы снизим мощность передачи deCONZ, я ожидаю, что ему потребуется маршрутизировать большее количество переходов (устройства стоимостью 7 выпадут из таблицы маршрутизации), но также будет легче получать входящие сообщения.

Общий список из сообщения о статусе ссылки deCONZ:

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0010 = Link Status Count: 18
    Link 1
        Address: 0x0118[Buiten - R schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 2
        Address: 0x0143[HK stalamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 3
        Address: 0x05b5[HK houtlamp 2]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 4
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .100 = Incoming Cost: 4
        .111 .... = Outgoing Cost: 7
    Link 5
        Address: 0x1ad3[HK plafond ledstrip]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 7
        Address: 0x4b4d[Keuken mid]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x5693[Keuken Rechts]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x68c4[WC lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6c35[Buiten - L schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 11
        Address: 0x731e[Kerstverlichting]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 12
        Address: 0x7d2a[0x7d2a]
        .... .011 = Incoming Cost: 3
        .101 .... = Outgoing Cost: 5
    Link 13
        Address: 0xa3f5[HK zoutlamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 14
        Address: 0xc7bc[Hal lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 15
        Address: 0xc9fa[Tuin linksvoor 3]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 17
        Address: 0xde81[On/Off light 36]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 18
        Address: 0xefd5[Zoldertrap Lamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1

Извините за задержку. Статус: мы все еще усердно работаем над новым выпуском и все еще отслеживаем ошибки в прошивке, которые кажутся более сложными, чем мы думали. Кажется, что-то в обработке nvram не работает. Мы также ищем решение проблем с перечислением USB / запуском.

Я буду размещать здесь обновления, как только они будут доступны.

Обновление: все еще идет хорошо!

Я не думаю, что когда-либо видел сеть такой стабильной. К настоящему времени я изменил различные правила, чтобы использовать одноадресную рассылку вместо групп. Вот уже 2 недели и 0 ламп ИКЕА пропали.

(Надеюсь, я не сглазил сейчас)

Обратите внимание, что я изменил плагин REST, чтобы запрашивать подтверждение APS для всех запросов.

У меня тоже значительно улучшилась сеть. Но не на 100%. Были случайные лампочки, которые не реагировали, но когда я вручную изменил лампочку IKEA, она действительно реагировала. Я также вижу, что состояние лампочки теперь такое же, как и физическое.
Однако одна из моих лампочек Osram стала безответной, как раньше у лампочек ikea. Положительно то, что это не такое суровое поведение, как у ikea.

Надеюсь, это может быть подтверждено другими или найденными результатами.

Я использую Conbee 1 с FW 26350500 и Deconz 2.05.75.
Это мой опыт последних недель

• Работает лучше, но не на 100%
• Некоторые из моих ламп IKEA E27 TRÅDFRI E27 WS opal 980lm с прошивкой 2.3.007 иногда не отвечают на команды ВЫКЛ.
• Я могу просто попытаться выключить их снова, и это обычно работает (не нужно выключать и снова)

@djwlindenaar здорово! Включено ли ваше исправление APS для REST API в выпуск .75? Просто чтобы я знал, может ли это объяснить некоторые различия в предыдущих сообщениях ...

Нет, это не так. Я даже не создавал для него пул-реквест. При этом вы можете построить его сами. Я сделаю это сегодня или завтра.
Также я могу поделиться встроенным плагином rest API, но у меня есть только один для Raspberry 3.

@tubalainen , я проверю, можно ли это объяснить с помощью APS ack. Также у меня нет 2.3 ламп ИКЕА.

Возможно, проблема с поведением повтора в deCONZ. Для этого мне нужно провести эксперимент, или, может быть, это уже есть в журналах сниффинга.

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

Вчера обновил мою производственную сеть (RPi 3B +, stretch, RaspBee) до 2.05.74 и 0x26340500. Кажется стабильным, за исключением перечисленных ниже проблем.
Не уверен, связано ли это, но маршрут к моему контроллеру штор lumi.curtain был потерян сегодня утром. Отчеты контроллера все равно будут доходить до шлюза. Маршрут не восстанавливается при выключении и включении контроллера. Мне пришлось открыть сеть и выключить и снова включить контроллер, прежде чем координатор снова подключится к нему.
Кроме того, один из моих радиаторных клапанов Eurotronic Spirit был недоступен для deCONZ после запуска deCONZ, но все еще отправлял отчеты. Включение и выключение питания TRV, как обычно, вернуло его обратно.
На этот раз у меня не было возможности провести какое-либо глубокое расследование, но оба устройства были проблемными с самого начала, время от времени проявляя эти симптомы. То же самое с моей шторкой IKEA Fyrtur. Я буду продолжать следить за ситуацией и сообщать, если у меня возникнут новые проблемы.

Очень сложно объективно зафиксировать эти периодически возникающие проблемы, но у меня сложилось впечатление, что 0x26350500 принес здесь улучшения. За исключением устройств, упомянутых выше, моя сеть очень стабильна. Некоторые TRV становились недоступными для шлюза, но в основном (только?) После перезапуска deCONZ. Я не думаю, что FYRTUR или диспетчер занавесей не прошли МВД за последние три недели.

Обратите внимание, что я изменил плагин REST, чтобы запрашивать подтверждение APS для всех запросов.

У меня есть APS Acks, включенные в _Network Settings_ в графическом интерфейсе, но я не уверен, относится ли это только к сообщениям, отправляемым графическим интерфейсом, или также к плагину REST API.

Если вы хотите запустить запрос на перенос выше, вы также можете проверить мою вилку и построить ее: djwlindenaar / deconz-rest-plugin

@ebaauw , насколько я могу судить, это относится только к командам, отправляемым из графического интерфейса

У меня постоянно работает сниффер, и я не отслеживаю время, когда возникает проблема. Обычно с этой информацией я могу довольно легко найти пакеты ...

Кстати, я переключил многие свои правила (особенно те, которые часто срабатывают) на одноадресную передачу. Пока что все работает отлично. Также я использовал один светильник IKEA, непрерывно меняющий яркость (каждые 4 секунды или около того) в течение последних 2 недель. Этот тоже в порядке.

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

Как я уже упоминал, у меня был запущен скрипт для изменения уровня света каждые пару секунд. Думая, что это может ускорить проблемы с освещением IKEA. Оказывается, это сбрасывает счетчик d->idleLastActivity , который предотвращает запуск любых неактивных задач. В том числе настройку отчетов по атрибутам: rofl:

Вы хотите сказать, что светильники IKEA теряют свои привязки и конфигурацию отчетов об атрибутах после отключения питания?!

Похоже, это ... Разве они не ..?

Моя проблема сейчас в том, что с тех пор, как я обновил свою установку до 0,75 и 50500, мой докер-контейнер теряет Conbee как минимум раз в неделю. Перезапуск контейнера снова запускает ... ОЧЕНЬ раздражает

@djwlindenaar , нет, я не думаю, что им следует. Большинство устройств, которые я видел, хранят эти настройки в энергонезависимой памяти. Я полагаю, что стандарт ZigBee оставляет место для любого поведения.

В то время как мои лампы IKEA теперь работают намного лучше, к сожалению, один из моих датчиков Xiaomi (круглый датчик температуры) через некоторое время перестает отвечать. Я попробую собрать улики, понюхав в ближайшие дни.

Я использую Conbee 1 с FW 26350500 и Deconz 2.05.75.
Это мой опыт последних недель

• Работает лучше, но не на 100%
• Некоторые из моих ламп IKEA E27 TRÅDFRI E27 WS opal 980lm с прошивкой 2.3.007 иногда не отвечают на команды ВЫКЛ.
• Я могу просто попытаться выключить их снова, и это обычно работает (не нужно выключать и снова)

@tubalainen Привет, я заметил другое поведение ikea с прошивкой 2.3.x по сравнению с 1.2.x тоже. Я попытался решить эту проблему, но не получил внимания. Я понизил рейтинг своих ламп до 1.2.x, и теперь это работает как шарм. На 2.3.x. Вы не можете выключить после изменения сцены в течение определенного периода времени. Нормально на выкл сработало. Странное поведение. Может быть, вы хотите протестировать и внести свой вклад здесь. ура https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

Вы хотите сказать, что светильники IKEA теряют свои привязки и конфигурацию отчетов об атрибутах после отключения питания?!

К сожалению, они теряют свои привязки после отключения питания, код был адаптирован некоторое время назад для решения этой проблемы. Привязки и конфигурация будут восстановлены после выключения и выключения источника питания, а также, если в течение некоторого времени отчеты не поступают, запускается процесс их восстановления.

@realwax снизится до 1.2.x на всех моих лампах E27 и сообщит об этом. (требует времени :)).

Вчера две фары E27 (с 2.3x FW) не погасли во время утренней последовательности.

@tubalainen вы используете групповые команды или одноадресные команды? (т.е. через REST api, установить состояние через / groups / или / lights /)

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

@tubalainen вы используете групповые команды или одноадресные команды? (т.е. через REST api, установить состояние через / groups / или / lights /)

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

Я использую Home Assistant и RESt api. Не знаю, что делает Home Assistant ...

В моем случае это iobroker с плагином deconz и Phoscon ... Так что оставайся API. Проблемы возникают при использовании igroups. При вызове групповой сцены группу нельзя выключить, быстро изменить на другие настройки групповой сцены или выключить должным образом, особенно в течение 15 секунд после вызова сцены. Похоже, что deconz раньше занят командой, или 2.3.x fw лампочки зависают (в чем я сомневаюсь). Пока не могу отлаживать на уровне zigbee, чтобы лучше понять. Является ли функция группировки deconz виртуальным слоем, который транслируется в командах uni cast или выполняется с помощью параметров группировки, доступных в gui / zigbee? В итоге я использую встроенную групповую функцию, иначе мне нужно было бы создать этот виртуальный слой в iobroker, и нет никаких причин, поскольку функция группировки хороша. Так что если это группировка ... Какая разница, кажется 100% с fw 1.2.x, а не с 2.3.x. Что изменилось? Это zigbee 2 почему они по-другому ведут себя.

@tubalainen Да, это большая работа, так как вам может потребоваться время от времени перезапускать или приближать лампочки. Я делал это дважды с е14 традфри 20. Вы должны увидеть огромное улучшение. Вы замечаете, что у вас лампочки с 2.3..x не включаются мягко. (исчезать) больше и 1.2.x делать?

НО скрестим пальцы, чтобы другие могли воспроизвести его, так что ikeas fw 2.3.x станет работоспособным в деконзальном режиме, так как наступит момент, когда нам нужно будет обновить. Или замените лампочки. Хотя zigbee 2 тоже подойдет.

Всем спасибо за ваши старания!

@realwax @djwlindenaar @manup

Прошлой ночью одна лампочка не погасла должным образом (IKEA E27 с прошивкой 2.3.x). Я попробовал изменить яркость того света, который не выключался, и он мгновенно изменился на выбранную мной настройку яркости. Через несколько мгновений после изменения яркости свет внезапно хорошо отреагировал и на команду выключения.

Я лично изменил все свои средства автоматизации в Home Assistant, чтобы сначала изменить яркость, подождать 2 секунды, а затем отправить команду выключения.

Пока 100% успех.

Надеюсь, это может быть ключом к расследованию.

РЕДАКТИРОВАТЬ: всегда по-прежнему не выключаются огни, которые находятся дальше всего от координации (палка Конби). (горит, что из-за характера полосы частот должна быть сеткой)

Эй, ребята!

Просто хотел рассказать о своих проблемах ...
После проблем со стабильностью моего ConBee II я проверил версию прошивки. Это было 26530700. Затем я понизил версию до 264a0700, и после этого ни одно приложение не может видеть флешку. Я пробовал HomeAssistant и deCONZ. ОС хоста определяет флешку в порядке, и GCFFlasher работает.

Эй, ребята!

Просто хотел рассказать о своих проблемах ...
После проблем со стабильностью моего ConBee II я проверил версию прошивки. Это было 26530700. Затем я понизил версию до 264a0700, и после этого ни одно приложение не может видеть флешку. Я пробовал HomeAssistant и deCONZ. ОС хоста определяет флешку в порядке, и GCFFlasher работает.

После перехода на

Любые обновления? Я очень хочу перевести весь свой дом на Conbee II, но на данный момент это очень нестабильно. Мой оттенок работает отлично, Conbee ii не очень

Мой опыт работы с последним deCONZ .75 с RaspBee FW 0x26350500 пока очень хорош.

Мои устройства:
4xTradfri 980lu WS фары - FW 2.3.007
17xTradfri 1000lu WS фары - FW 2.0.023
Заглушки 3xTradfri - FW 2.0.022
3xTradfri Round Remote E1810 - FW 2.3.014
4 датчика Aqara THP

Нашел еще одну вылетающую прошивку лампочки ИКЕА. (и я думаю это можно исправить в deConz)

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

Похоже, что deConz действительно получает ответ о членстве в группе, но каким-то образом APS ACK (подтверждающий запрос на получение членства в группе), отправленный светом, не принимается deConz (я также не вижу MAC ACK). В результате deConz повторно отправляет запрос. Этот запрос имеет тот же номер в ZCL, что приводит к сбою легкой прошивки.

Я предполагаю, что deConz мог бы считать запрос подтвержденным, как только будет получен соответствующий ответ, и избежать отправки другого запроса. Правильно? Есть ли у плагина API, который можно вызвать для отмены запроса? @manup?

Обратите внимание, что эту конкретную ошибку также можно обойти, не запрашивая APS ACK для этих запросов, что является значением по умолчанию в текущем подключаемом модуле REST API.

No.               Time              Source            Transmit Dev      Receive Dev       Destination       Disable Default Response            Acknowledgement Request             Info
74174             2h 48m 12.832154s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
74176             2h 48m 12.841977s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74178             2h 48m 12.847098s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74180             2h 48m 12.890302s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz            True              True              ZCL Groups: Get Group Membership Response, Seq: 32
74182             2h 48m 12.896074s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74183             2h 48m 12.899402s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74184             2h 48m 12.902460s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                              False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74185             2h 48m 12.904330s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74190             2h 48m 14.186599s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
76346             2h 52m 41.998416s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
76354             2h 52m 43.668838s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
202171            7h 39m 10.905361s HK houtlamp 2     HK houtlamp 2     Broadcast         Broadcast                           False             Device Announcement, Nwk Addr: 0x05b5, Ext Addr: SiliconL_ff:fe:c5:2c:7d

Запуск v2.05.75 с 0x26350500 уже пару недель. Он кажется немного более стабильным, чем предыдущие версии, но я все еще иногда теряю маршрут к моим TRV Eurotronic Spirit, моей шторке Fyrtur и контроллеру шторки Xiaomi lumi.curtain . Последний - маршрутизатор; остальные - конечные устройства. Все TRV имеют одинаковую версию аппаратного обеспечения / прошивки, но некоторые из них проходят MIA чаще, чем другие. Симптомы одинаковы: устройство продолжает отправлять отчеты координатору, но команды от координатора приводят только к неотвеченному _Route Request_.

В настоящее время отслеживает и анализирует трафик TRV, который пропадает чаще всего. Отчеты доходят до координатора за три прыжка с использованием двух ламп Hue по пути. Я также записал _Data Request_ от TRV к первому свету на пути, поэтому TRV кажется счастливым, что это его родитель. Запросы дескриптора сопоставления от TRV для кластера OTAU остаются без ответа. Родитель сообщает о следующем индикаторе в своем _Link Status_, но не о TRV (потому что это оконечное устройство?).

Сообщения _Link Quality Response_ показывают таблицу соседей из 20 записей, но TRV среди них нет. Датчик двери Xiaomi (который всегда был стабильным) есть. Как ни странно, координатор, но отчет от TRV координатору был ретранслирован через другой маршрутизатор (который также находится в таблице соседей).
Хорошо, теперь координатор также включен в _Link Status_, и следующий отчет от TRV пересылается непосредственно координатору.

Электропитание выключило TRV. TRV отправляет MAC _Data Request_ (бывшему) родителю; маршрутизатор отвечает _Rejoin Response_, передавая старый адрес NWK TRV как новый адрес. Затем TRV передает _Объявление об устройстве_ (одноадресная передача MAC родительскому устройству; родительский узел пересылает сообщение MAC-адресации). TRV отправляет родительскому объекту _End Device Timeout Request_; родитель отправляет _Update Device_ координатору, информируя его о том, что TRV безопасно воссоединился. Родитель теперь также отправляет _Route Reply_ _Route Request_ координатора. В следующую последовательность _Link Quality Response_ включается TRV.

Я продолжу работу анализатора, надеюсь, поймать момент, когда TRV снова пропадает.

Возможно, связанное с этим примечание: одна из моих интеллектуальных розеток innr SP120 по-прежнему считает себя родительской для кнопки Hue, которую я ненадолго присоединил к своей производственной сети при добавлении поддержки. С тех пор кнопка была подключена к моей тестовой сети на пару недель, и я несколько раз отключал и выключал питание. Нужно ли мне восстановить заводские настройки вилки, чтобы она забыла о потерянном ребенке?

@manup , давно

Я обнаружил еще одну проблему в поведении маршрутизации deConz.

В этом случае deConz пытается направить сообщение на Hal lamp через Tuin linksvoor 3 . Но глядя на отчет Link Status от Tuin linksvoor 3 он ничего не знает о Hal lamp . И видимо он тоже не знает, как до него добраться через роутинг. Конечно, этот свет (IKEA) должен вести себя сам и отвечать сообщением об ошибке, но это не так, и мы не можем это изменить.
Однако деКонц заключает, что Hal lamp - это зомби, не пытаясь найти новый путь к этому свету. Не знаю, как это взаимодействует с (новым) кодом маршрутизации, но почему-то он не ухудшил этот маршрут достаточно быстро, чтобы предотвратить его пометку как зомби. (Кстати, это действительно не так, смотрите дальше ...)

Это вызвало временную проблему, которая разрешилась через несколько минут (что, конечно, совершенно неприемлемо). Поскольку Hal lamp решает отправить отчет об атрибутах, для которого он не получает APS ACK и поэтому запускает процесс Route Request . Только теперь, после того, как это будет завершено, deConz изменяет свой маршрут на Hal lamp и связь возобновляется в обычном режиме.

Интересно, сколько бы времени это заняло, если бы свет не решил послать сообщение де Концу. (Обратите внимание, что в моей сети я запускаю светильники IKEA с регулярными отчетами об атрибутах для кластеров включения / выключения и уровня каждые 5 минут)

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default R  Acknowledgement Request               Info
392213             13h 31m 26.050526s Tuin linksvoor 3   Tuin linksvoor 3   Broadcast          Broadcast                                                Link Status
392241             13h 31m 26.182875s DeConz             DeConz             Tuin linksvoor 3   Hal lamp           True               True               ZCL Level Control: Move to Level with OnOff, Seq: 252

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0000 = Link Status Count: 16
    Link 1
        Address: 0x0000[DeConz]
        .... .111 = Incoming Cost: 7
        .100 .... = Outgoing Cost: 4
    Link 2
        Address: 0x0118[Buiten - R schuur]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 3
        Address: 0x0143[HK stalamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 4
        Address: 0x05b5[HK houtlamp 2]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 5
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .011 = Incoming Cost: 3
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 7
        Address: 0x23ec[Tuin linksachter 1]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x2b9e[Bijkeuken]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x325d[0x325d]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6339[Tuin rechtsvoor 3]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 11
        Address: 0x68c4[WC lamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 12
        Address: 0x731e[Kerstverlichting]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0
    Link 13
        Address: 0x7d2a[HK houtlamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 14
        Address: 0xc520[Badkamer ledstrip]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 15
        Address: 0xca27[Tuin rechtsvoor 2]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0

Ваше описание похоже на то, что я испытываю. У меня гораздо лучшая сеть (conbee 1) с последней прошивкой. Но по-прежнему получаются не отвечающие лампочки, которые через некоторое время снова начинают реагировать.
Я не выполняю никаких дополнительных обычных команд или настроек, чем предоставляет Home Assistant и мое обычное расписание для лампы. Хотя внутренние лампочки меняются в течение дня (вкл / выкл или яркость), тогда как мои внешние лампочки меняют только три раза в день. Иногда не отвечающие лампочки возвращаются довольно быстро, и если я даю команду, они реагируют. Редко, но бывает, это занимает намного больше времени, или мне нужно выключить цикл питания.

@djwlindenaar снова отличная работа. Большое спасибо! Вы делитесь своими обнаруженными ошибками в IKEA FW с IKEA?

@djwlindenaar :

Конечно, этот свет (IKEA) должен вести себя сам и отвечать сообщением об ошибке, но это не так, и мы не можем это изменить.

Ну, я не видел. Возможно, @manup сможет прокомментировать,
Также я не использую их последнюю прошивку.

Возможно, лучше было бы обратиться в силиконовые лаборатории, поскольку на этом и построена продукция IKEA. Я не уверен, связаны ли ошибки с кодом Ember или настройкой IKEA ...

@djwlindenaar Вы также можете попытаться связаться с вами через reddit: https://www.reddit.com/user/TRADFRI Они там довольно активны.

@manup Есть новости о прошивке Conbee II?

после возврата к предыдущей версии прошивки до 0x264a0700 я больше не могу подключиться к Conbee II. Пытался откатиться до 0x264a0700 и некоторых действительно старых прошивок, прошивка работает нормально, но не может подключиться. Подскажите, как сбросить флешку Conbee II?

@manup есть обновления? Следует ли мне искать что-то еще, кроме deConz, или работа над решением проблем продолжается? Пожалуйста, подайте знак жизни 🤗

Я просто хочу, чтобы мой Conbee II снова заработал после тестирования тестовой прошивки ...

@djwlindenaar Есть новости с вашей стороны? По-прежнему стабильная сеть с вашими исправлениями?

Приятно видеть, что ваш PR объединен

@djwlindenaar Есть новости с вашей стороны? По-прежнему стабильная сеть с вашими исправлениями?

Приятно видеть, что ваш PR объединен

@ JBS5 Я в среднем доволен ситуацией.

Для моей сети это явно улучшилось. Тем не менее, я все еще вижу ошибки в индикаторах ИКЕА, которые иногда сбивают с толку deCONZ.

Ключевым моментом является то, что иногда маршрутизатор IKEA незаметно сбрасывает пакеты для определенного маршрута. Это бесшумное отключение запрещено, но deCONZ должен отреагировать на это, найдя новый маршрут, а это не так.

Похоже, что изменения в прошивке deCONZ действительно улучшают ситуацию, но есть еще что добавить для этих ситуаций. Безусловно, отсутствие APS ACK должно немедленно запустить поиск нового маршрута.

Обратите внимание, что @manup упомянул, что маршрутизация от источника может решить проблему, и я считаю, что это особенно верно в данном случае, поскольку это означает, что мы не зависим от маршрутизаторов в сети, которые знают, как выполнять маршрутизацию к удаленному узлу.

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

Спасибо @djwlindenaar.
Поскольку это было некоторое время назад, когда @manup прокомментировал здесь, есть ли у вас какие-нибудь подсказки, если упомянутая маршрутизация от источника - это то, что будет реализовано?

Это изменение должно произойти в прошивке. Я не связан с deCONZ, поэтому не могу комментировать вероятность ...

@manup ?

Это заставляет меня задуматься о том, чтобы отказаться от deCONZ для моей домашней сети ...

@djwlindenaar , какие альтернативы вы рассматриваете? На данный момент я не впечатлен стабильностью моего Conbee II.

Это изменение должно произойти в прошивке. Я не связан с deCONZ, поэтому не могу комментировать вероятность ...

@manup ?

Это заставляет меня задуматься о том, чтобы отказаться от deCONZ для моей домашней сети ...

Zigbee2MQTT делает это лучше или вы не имели в виду это с альтернативой?

Да уж. Вот и все.

На самом деле я не знаю, работает ли это лучше. Обратите внимание, что используемые там прошивки предоставлены производителями микросхем. Эти прошивки не имеют открытого исходного кода. Так что, если у них есть проблема с прошивкой, вы, вероятно, застряли с меньшей поддержкой, чем deCONZ ...
С другой стороны, конфигурация этих прошивок имеет открытый исходный код. Также они уже поддерживают маршрутизацию от источника.

Производитель микросхем предоставляет только SDK, если вы так хотите, вы можете скачать SDK, пробную версию simplicity studio и самостоятельно скомпилировать прошивку. Z2M предоставляет исправления изменений, внесенных в прошивку.

Привет вместе,

Приносим извинения за то, что это заняло так много времени, вот новая прошивка для ConBee II, в которую были перенесены все исправления маршрутизации из прошивки AVR 0x26350500. Кроме того, улучшен запуск, чтобы устройство не отключалось. (Мы все еще тестируем различные случаи, чтобы окончательно исправить проблему с загрузкой).

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF

Эта версия, вероятно, будет частью предстоящего выпуска deCONZ 2.05.76, микропрограммы ConBee I и RaspBee I версии 0x26350500 будут установлены для установки с помощью кнопки обновления.

Спасибо, @manup. Установил эту версию в моей тестовой сети, и, похоже, она работает. По крайней мере, устройствами можно управлять, в отличие от 52 и 53. Тестовая сеть слишком мала, чтобы проверить, улучшает ли эта версия маршрутизацию.

@manup deCONZ по-прежнему не подключается к ConBee II даже после прошивки новой прошивки. Была эта проблема какое-то время.

@manup Я пытался прошить несколько раз, но продолжаю получать эту ошибку:

Flash update failed, invalid CRC. Please try again.

14:29:06:105 query bootloader v1 ID after 5 ms
14:29:06:122 RX 60 bytes ASCII
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
, 14:55:05
 after 22 ms
14:29:06:122 bootloader start after 22 ms
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
14:29:06:124 GCF_ResetDeviceDone
14:29:06:125 bootloader v1 update firmware
flashing 160930 bytes: |==============================|
verify: .
Flash update failed, invalid CRC. Please try again.

Это GCFFlasher 3.13?

Вот журнал моего обновления:

GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x26580700.bin.GCF 
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
deCONZ firmware version 26570700
R21B18 Bootloader
Vers: 2.05
build: Mar 11 2019
flashing 160930 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts

Да, это была версия 3.13, теперь она работает, я перезагрузил всю систему. Странно, просто повторное подключение ConBee II не помогло, но перезагрузка работает ..

Действительно странно, проверка CRC производится прямо на устройстве, мне интересно, как это может происходить.

@manup Я даже пробовал

Рад, что теперь это работает, спасибо! Я уже видел одно проблемное устройство, которое сразу подключилось к сети. Надеюсь, эта прошивка исправит некоторые проблемы :)

Рад, что теперь это работает. Только что обсудили с коллегами загрузчик. Версия 2.05 была из первой партии ConBee II в 2019 году (около 3500 штук), в некоторых случаях эта версия немного грубовата. С июля 2019 года мы выпускаем версию 2.07 с некоторыми исправлениями в работе сторожевого пса.

В разработке находится новый загрузчик 3.x, который уже является частью RaspBee II, он имеет гораздо более надежный дизайн и протокол для устранения проблем версии 2.x.

В настоящее время мы не обновляем загрузчик ConBee II с помощью GCFFlasher. Мы не выкатывали это, поскольку есть небольшая вероятность заблокировать устройство, если обновление загрузчика прерывается в момент изменения таблицы векторов запуска. Но я думаю, что мы можем это выяснить, используя аппаратный обработчик ошибок ARM. Идея состоит в том, что если обновление загрузчика завершилось неудачно и срабатывает аппаратный обработчик сбоев, он может проверить, действителен ли загрузчик, и если это не удастся, он перейдет в приложение, где обновление загрузчика можно будет повторить. Мы провели несколько тестов с жестким обработчиком ошибок, которые выглядят многообещающими, но потребуется некоторое время, прежде чем он будет готов к общедоступной версии.

Привет

Сегодня я прошил новую прошивку, но я все еще вижу логи вроде:

0x000D6FFFFE540E7C ошибка APSDE-DATA.confirm: 0xA7 в задаче

Это связано?

0xA7 указывает, что APS ACK не был предоставлен там, где должен был быть. Думаю, этому могло быть множество причин.

Привет, @manup , приятно снова тебя слышать. У вас также есть время для дальнейшего обсуждения оставшихся вопросов маршрутизации? И надеюсь решить их?

Привет еще раз,

У меня все еще есть проблемы, когда некоторые огни не реагируют на команды (вкл / выкл / тускло), и я действительно не знаю, почему, я думал, что я как-то связан с этой проблемой, но теперь я не уверен, так ли это?

Я до сих пор получаю много ошибок, подобных той, которую я опубликовал 4 дня назад.

количество кодов
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
всего 76

У меня есть 26 устройств, которые публикуют эти ошибки СЕГОДНЯ, похоже, что с 0x26580700 стало немного хуже

Может ли кто-нибудь сказать мне, связано ли это с проблемой маршрутизации? или я должен открыть вопрос с моей проблемой

Обратите внимание, что это, кажется, происходит только при отправке fx. "горит" до ~ 20 ламп "одновременно"

Привет, @manup , приятно снова тебя слышать. У вас также есть время для дальнейшего обсуждения оставшихся вопросов маршрутизации? И надеюсь решить их?

Привет, @djwlindenaar, да, безусловно, мне нужно

Привет, @djwlindenaar, да, безусловно, мне нужно

@manup , конечно, я думаю, что ключевой проблемой остается то, что deCONZ все еще упорствует в сохранении маршрута, который не работает.
Я считаю, что сообщения как от неправильного поведения, так и от затронутого света продолжают поступать (через какой-то другой маршрут), и это неправильно интерпретируется прошивкой, как будто нерабочий маршрут все еще работает. Также deCONZ имеет тенденцию довольно быстро отказываться от запросов уровня APS, если ACK не получен. Я думаю, он должен быть более постоянным и / или запускать обнаружение маршрута как часть процесса повтора.

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

Привет, @manup , приятно снова тебя слышать. У вас также есть время для дальнейшего обсуждения оставшихся вопросов маршрутизации? И надеюсь решить их?

Привет, @djwlindenaar, да, безусловно, мне нужно

Привет, Manup, я могу захватить эту ветку, так что если да, пожалуйста, не обращайте внимания. У меня есть Conbee II на Home Assistant, и он отлично работал примерно месяц назад. В этот момент все мои датчики Xiaomi станут ненадежными автоматическими устройствами. У меня есть несколько контроллеров dresden fls-pp, которые у меня были пару лет. Они подключены к светодиодным лентам и используются для того, чтобы время от времени отключаться от сети, вызывая перезагрузку, чтобы снова включить их. Я наконец удалил их все из своей сети Conbee, и сразу же вся сеть стала стабильной. Я оставил его на несколько дней, затем повторно представил тот, который работал несколько часов, а затем в течение ночи моя сеть Zigbee вышла из строя, и я не мог вернуть все свои переключатели / датчики в режим онлайн, пока не выключил контроллер Dresden. Понятия не имею, почему, но для меня использование контроллеров dresden теперь нарушает мою сеть zigbee. Я только новичок в этом, поэтому не уверен, что это полезно / актуально, но я искал какие-либо комментарии по этому поводу и наткнулся на эту ветку, поэтому подумал, что на всякий случай добавлю свой опыт в микс. Сейчас я просто удаляю их из своей сети - не стоит головной боли, которую они мне доставляли!
Ура

Привет, @djwlindenaar, да, безусловно, мне нужно

@manup , конечно, я думаю, что ключевой проблемой остается то, что deCONZ все еще упорствует в сохранении маршрута, который не работает.
Я считаю, что сообщения как от неправильного поведения, так и от затронутого света продолжают поступать (через какой-то другой маршрут), и это неправильно интерпретируется прошивкой, как будто нерабочий маршрут все еще работает. Также deCONZ имеет тенденцию довольно быстро отказываться от запросов уровня APS, если ACK не получен. Я думаю, он должен быть более постоянным и / или запускать обнаружение маршрута как часть процесса повтора.

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

Я решил перейти на zigbee2mqtt из-за проблем с маршрутизацией (больше всего раздражает необходимость периодически менять сопряжение Ikea / Xiaomi). Я опубликую здесь свои выводы через несколько недель ...

После прошивки 0x26350500 на моем Conbee I (и обновления deCONZ до 2.05.76) в прошлый понедельник, к сожалению, GU10 отключился.

В VNC он немного серый:

Фоскон:

Нужно ли выключить все индикаторы, прежде чем они воспользуются исправлением маршрутизации в новой версии прошивки?

@ JBS5 , я не думаю, что после обновления прошивки нужно
Вероятно, это связано с тем, что, несмотря на улучшение, мы не полностью избавились от проблем маршрутизации; см. мои предыдущие сообщения.

@djwlindenaar Спасибо. Я понимаю.

Как бы то ни было, потому что поведение примерно такое же, как и в предыдущей прошивке:

После того, как GU10 был помечен как недоступный, он все еще отвечал на групповые команды. Через несколько дней отключились 2 устройства с батарейным питанием (датчик движения Aqara и датчик дыма Xiaomi / Honeywell). GU10 все еще отвечал на групповые команды.

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

@ JBS5 , да, это похоже на типичное поведение. На самом деле с этим светом GU10 все в порядке. Просто deCONZ сбился с пути напрямую с ним общаться. Через некоторое время это также приводит к отключению конечных устройств, поскольку они также не получают никакой обратной связи от deCONZ. Наконец, когда GU10 становится достаточно голодным по сетевым пакетам, он действительно отключается.

Вероятно, в фазе, когда он все еще отвечает на групповые команды, вы сможете выключить и снова включить другой маршрутизатор, что, по-видимому, нормально, и GU10 восстановится. Этот другой маршрутизатор на самом деле не играет хорошо, и deCONZ плохо реагирует на ситуацию.
Так что не сердитесь на GU10;)

Привет, @djwlindenaar, да, безусловно, мне нужно

@manup , конечно, я думаю, что ключевой проблемой остается то, что deCONZ все еще упорствует в сохранении маршрута, который не работает.

Хм, маршруты должны быть ухудшены и отброшены после нескольких неудачных передач. Последняя версия прошивки будет ухудшаться каждый раз, когда в APS-DATA.confirm сообщается об ошибке (например, об ошибке маршрутизации или отсутствии полученного APS-ACK).

Я считаю, что сообщения как от неправильного поведения, так и от затронутого света продолжают поступать (через какой-то другой маршрут), и это неправильно интерпретируется прошивкой, как будто нерабочий маршрут все еще работает.

Это очень хороший намек, я проверю. это объяснило бы, почему маршруты не умирают. Я думаю, что единственный разумный способ оценить маршрут должен основываться на успешных передачах.

Также deCONZ имеет тенденцию довольно быстро отказываться от запросов уровня APS, если ACK не получен. Я думаю, он должен быть более постоянным и / или запускать обнаружение маршрута как часть процесса повтора.

deCONZ не обнаруживает никаких маршрутов, все это обрабатывается стеком Zigbee. Мы можем расширить REST-API, чтобы выполнять повторные попытки для некоторых команд (например, команд управления), но это хотя бы один.

Сам стек можно настроить для выполнения нескольких попыток APS до отказа. Но это может много чего испортить и надолго заблокировать очередь. Я думаю, что лучше рассмотреть это более детально в REST-API.

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

Теоретически маршрутизация от источника - это Святой Грааль, чтобы все это исправить :)

Но в реальном мире многие шлюзы не используют его (есть ли?). Это означает, что большинство продуктов либо не поддерживают маршрутизацию от источника, либо не тестировались с ней. ИМХО шансы заставить его работать в смешанных сетях очень низкие. Но прошло много времени с тех пор, как я сравнивал различные шлюзы на этом уровне. Было бы интересно получить текущий обзор того, какие шлюзы используют какой подход маршрутизации в настоящее время.

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

С радостью помогу тестировать / анализировать мост Hue (поколение 2 и поколение 1), шлюз innr, концентратор IKEA и шлюз OSRAM Lightly Home, но мне нужно немного узнать, какую тестовую установку использовать (сколько маршрутизаторов, конечных устройств, расстояния между ними , ...) и что искать.

Z-Stack FW - это один из примеров FW, который предлагает / использует исходную маршрутизацию и рекомендует ее для больших сетей. Но я также видел некоторые комментарии о том, что это не очень хорошо работает с более слабым CC2351.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

Также deCONZ имеет тенденцию довольно быстро отказываться от запросов уровня APS, если ACK не получен. Я думаю, он должен быть более постоянным и / или запускать обнаружение маршрута как часть процесса повтора.

deCONZ не обнаруживает никаких маршрутов, все это обрабатывается стеком Zigbee. Мы можем расширить REST-API, чтобы выполнять повторные попытки для некоторых команд (например, команд управления), но это хотя бы один.

Сам стек можно настроить для выполнения нескольких попыток APS до отказа. Но это может много чего испортить и надолго заблокировать очередь. Я думаю, что лучше рассмотреть это более детально в REST-API.

Стек делает несколько повторных попыток, я помню, что он пытается три раза, если я не ошибаюсь. Мне кажется, что вы могли бы добавить поведение в этот фрагмент кода, чтобы аннулировать связанный маршрут и повторить попытку еще один или два раза. Или, может быть, у вас может быть обратный вызов внутри стека для реализации этого поведения. Это должно вызвать открытие маршрута, верно?

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

Теоретически маршрутизация от источника - это Святой Грааль, чтобы все это исправить :)

Но в реальном мире многие шлюзы не используют его (есть ли?). Это означает, что большинство продуктов либо не поддерживают маршрутизацию от источника, либо не тестировались с ней. ИМХО шансы заставить его работать в смешанных сетях очень низкие. Но прошло много времени с тех пор, как я сравнивал различные шлюзы на этом уровне. Было бы интересно получить текущий обзор того, какие шлюзы используют какой подход маршрутизации в настоящее время.

Если честно, меня эта проблема не очень волнует. Поведение маршрутизаторов в случае маршрутизации от источника предельно простое. Особенно, если вы сравните его с поведением, необходимым для самой маршрутизации. По сути, единственное, что должен делать уровень NWK в маршрутизаторе, - это проверять, включена ли маршрутизация от источника, читать следующий переход из пакета и передавать его обратно на уровень MAC. Ни таблиц, ни памяти, ничего плохого. Я не уверен, проверено ли базовое поведение для сертификации zigbee, но наверняка это намного проще и вероятность ошибок гораздо меньше, чем при обычной маршрутизации.

Я ожидаю, что немногие координаторы реализуют это, потому что сложность заключается в прошивке координатора. Также очень немногие (потребительские) реализации zigbee на самом деле ориентированы на более крупные сети, которые выиграют от этого режима маршрутизации.

Наконец, я бы сказал, что это лучший режим маршрутизации для смешанных сетей, потому что нормальная маршрутизация зависит от отдельных реализаций маршрутизаторов и особенно от плохо определенных показателей качества связи. Поскольку исходная маршрутизация настолько проста (= низкая вероятность плохой реализации), я бы доверял этому до нормального поведения маршрутизации.

Итак ... сказав это, я готов протестировать это для вас, если вы можете предоставить прошивку. Я на распбее, мой сниффер готов к работе.

Наконец, я бы сказал, что это лучший режим маршрутизации для смешанных сетей, потому что нормальная маршрутизация зависит от отдельных реализаций маршрутизаторов и особенно от плохо определенных показателей качества связи. Поскольку исходная маршрутизация настолько проста (= низкая вероятность плохой реализации), я бы доверял этому до нормального поведения маршрутизации.

KISS - для меня много смысла.

Стек делает несколько повторных попыток, я помню, что он пытается три раза, если я не ошибаюсь. Мне кажется, что вы могли бы добавить поведение в этот фрагмент кода, чтобы аннулировать связанный маршрут и повторить попытку еще один или два раза. Или, может быть, у вас может быть обратный вызов внутри стека для реализации этого поведения. Это должно вызвать открытие маршрута, верно?

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

Если честно, меня эта проблема не очень волнует. Поведение маршрутизаторов в случае маршрутизации от источника предельно простое. Особенно, если вы сравните его с поведением, необходимым для самой маршрутизации. По сути, единственное, что должен делать уровень NWK в маршрутизаторе, - это проверять, включена ли маршрутизация от источника, читать следующий переход из пакета и передавать его обратно на уровень MAC. Ни таблиц, ни памяти, ничего плохого. Я не уверен, проверено ли базовое поведение для сертификации zigbee, но наверняка это намного проще и вероятность ошибок гораздо меньше, чем при обычной маршрутизации.

Я могу говорить только о продуктах на основе BitCloud, которые я принес через сертификацию (балласты FLS). В процессе сертификации они никогда не тестировались на маршрутизацию от источника. Я не уверен, был ли он включен в стеке во время компиляции. Обратите внимание, что большинство стеков настроено для компиляции с минимально необходимыми функциями для безопасного пространства.

Мой личный опыт работы с редко используемыми / тестируемыми функциями, какими бы простыми они ни были в теории, показывает, что в них всегда есть ошибки. Например, для FLS нам пришлось исправить множество ошибок в примере приложения стека BitCloud. Я знаю, что Philips также внесла множество улучшений в стек BitCloud для некоторых своих продуктов.

Я ожидаю, что немногие координаторы реализуют это, потому что сложность заключается в прошивке координатора. Также очень немногие (потребительские) реализации zigbee на самом деле ориентированы на более крупные сети, которые выиграют от этого режима маршрутизации.

Сложность должна быть реализована в подключаемом модуле deCONZ REST-API или новом подключаемом модуле маршрутизатора, поскольку прошивка не имеет достаточного представления о всей топологии сети и о флеш-пространстве. Для этой цели deCONZ::ApsDataRequest может быть расширен параметром исходного маршрута в форме std::vector<quint16> содержащего nwk-адреса маршрута.

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

• Рекурсивный запрос топологии сети (Mgmt_Lqi_req). Это самый простой способ, он уже работает для маршрутизации сетки и может быть адаптирован к исходным маршрутам.
• Узлы выключены. Здесь некоторая логика должна выбрать альтернативные маршруты, которые также могут не работать, если их ссылки тоже разорваны.
• Узлы снова включены.
• Узлы, меняющие адрес nwk.
• Конечные устройства меняют родителей.
• Присоединение конечных устройств, в многоскачковых сетях мы не узнаем родителя без запроса сети.

Чего мы еще не знаем:

• Все ли маршрутизаторы поддерживают маршрутизацию от источника?
• Существуют ли коммерческие шлюзы, использующие маршрутизацию от источника? Здесь нам нужно прослушивать трафик и смотреть на заголовки NWK, которые содержат исходные маршруты и имеют соответствующие установленные флаги.
• Насколько хорошо это работает для устройств, поддерживающих маршрутизацию от источника?

Я могу говорить только о продуктах на основе BitCloud, которые я принес через сертификацию (балласты FLS). В процессе сертификации они никогда не тестировались на маршрутизацию от источника. Я не уверен, был ли он включен в стеке во время компиляции. Обратите внимание, что большинство стеков настроено для компиляции с минимально необходимыми функциями для безопасного пространства.

Я не знаком с тем, как это работает, но разве стеки тоже не сертифицированы?

Мой личный опыт работы с редко используемыми / тестируемыми функциями, какими бы простыми они ни были в теории, показывает, что в них всегда есть ошибки. Например, для FLS нам пришлось исправить множество ошибок в примере приложения стека BitCloud. Я знаю, что Philips также внесла множество улучшений в стек BitCloud для некоторых своих продуктов.

Я ожидаю, что немногие координаторы реализуют это, потому что сложность заключается в прошивке координатора. Также очень немногие (потребительские) реализации zigbee на самом деле ориентированы на более крупные сети, которые выиграют от этого режима маршрутизации.

Сложность должна быть реализована в подключаемом модуле deCONZ REST-API или новом подключаемом модуле маршрутизатора, поскольку прошивка не имеет достаточного представления о всей топологии сети и о флеш-пространстве. Для этой цели deCONZ::ApsDataRequest может быть расширен параметром исходного маршрута в форме std::vector<quint16> содержащего nwk-адреса маршрута.

Я не понимаю этого утверждения. Маршрутизация источника полностью обрабатывается на уровне NWK в стеке. Стек bitcloud должен иметь некоторый флаг времени компиляции (или, что менее вероятно, времени выполнения), чтобы включить маршрутизацию от источника. Существует таблица исходных маршрутов, которая обновляется стеком на основе сообщений Route Record, которые уже находятся в нашей сети из-за MTORR, отправляемого координатором каждые несколько минут.

• Обычно для каждого устройства в сети маршрут к координатору известен через MTORR.
• Координатор знает каждый (полный) маршрут к каждому устройству через сообщения Route Record. Никакого анализа не требуется, просто скопируйте сообщение RR в исходную таблицу маршрутов.

См. Спецификацию zigbee в главах 3.6.3.5.4 и 3.6.3.3.

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

* Recursive query of network topology (Mgmt_Lqi_req). Thats, the easy one, this already works for mesh routing and could be adapted to source routes.

* Nodes are powered off. Here some logic needs to select alternate routes, which may also not work if their links are broken too.

* Nodes are powered on again.

* Nodes changing the nwk address.

* End-devices changing parents.

* End-devices joining, in multi-hop networks we don't know the parent without querying the network.

Я считаю, что все это обрабатывается слоем NWK внутри стека bitcloud. Это должно быть так же просто, как настройка некоторых флагов времени компиляции (аналогично включению поведения MTOR)

Чего мы еще не знаем:

* Do all routers support source routing?

Я ожидал этого, поскольку это часть базовой спецификации zigbee уровня NWK. Я не могу быть уверен, но я не видел никаких замечаний о том, что поддержка маршрутизации от источника является необязательной. Это похоже на поведение MTOR, которое мы уже используем в нашей сети.

* Are there any commercial gateways which use source routing? Here we need to sniff traffic and look at the NWK headers which hold the source routes and have respective flags set.

Не знаю этого, также не знаю, что он нам скажет?

* For the devices which support source routing, how well does it work?

Если бы вы могли сделать сборку прошивки с включенной маршрутизацией от источника, мы быстро научимся. Достаточно всего нескольких флагов времени компиляции, чтобы включить его в bitcloud.

Также в Zigbee2MQTT он включен для некоторых прошивок координатора, и я еще не обнаружил (после быстрого поиска в Google) каких-либо проблем с конкретными маршрутизаторами, которые не работают с включенной маршрутизацией от источника.

Я не знаком с тем, как это работает, но разве стеки тоже не сертифицированы?

Да, но во время сертификации включены определенные конфигурации, которые в дальнейшем могут быть недоступны в продуктах.

Я не понимаю этого утверждения. Маршрутизация источника полностью обрабатывается на уровне NWK в стеке. Стек bitcloud должен иметь некоторый флаг времени компиляции (или, что менее вероятно, времени выполнения), чтобы включить маршрутизацию от источника. Существует таблица исходных маршрутов, которая обновляется стеком на основе сообщений Route Record, которые уже находятся в нашей сети из-за MTORR, отправляемого координатором каждые несколько минут.

Обычно для каждого устройства в сети маршрут к координатору известен через MTORR.
Координатор знает каждый (полный) маршрут к каждому устройству через сообщения Route Record. Никакого анализа не требуется, просто скопируйте сообщение RR в исходную таблицу маршрутов.

См. Спецификацию zigbee в главах 3.6.3.5.4 и 3.6.3.3.

Ах ты прав, глупый я как-то неправильно истолковал это с общим обнаружением узлов (фейспалм).
Стек действительно может вычислить множество команд записи маршрута, но я уже сталкивался со случаем, когда ничего не было отправлено, см. Ниже.

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

Мой датчик движения Philips Hue создает проблемы и отправляет широковещательные запросы адреса NWK для получения адреса NWK шлюза. В этом случае кадры записи маршрута не отправлялись априори (я думаю, из-за трансляции). Поскольку маршрутизация сетки была отключена, шлюз не запускал обнаружение маршрута, поэтому связь с датчиком не была установлена.

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

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

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

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

Я на распби, поэтому не могу проверить это. Не могли бы вы создать его и для этого?
Мне интересно, можем ли мы обойти эту проблему с помощью своего рода статического маршрута, который мы можем загрузить в прошивку при запуске или, возможно, действительно на основе какой-то другой информации.
Кроме того, вы ремонтировали это устройство после изменения маршрутизации от источника? Интересно, требуется ли какое-то взаимодействие конечному устройству для распознавания MTOR и маршрутизации от источника. Конечно, они не получают широковещательные сообщения MTOR, когда их приемник выключен.
Кстати, я видел, как мои конечные устройства Xiaomi отправляют запись маршрута в моем нюхании ...

Я провел выше прошивку через ночь. Похоже, что маршрутизация от источника используется также при включенной маршрутизации по сетке, но очень редко. С ок. Только 2 миллиона пакетов <5 использовали исходный маршрут.

Я на распби, поэтому не могу проверить это. Не могли бы вы создать его и для этого?

Не уверен, мне нужно проверить другую конфигурацию стека, используемую ConBee I и RaspBee I, если это возможно.

Мне интересно, можем ли мы обойти эту проблему с помощью своего рода статического маршрута, который мы можем загрузить в прошивку при запуске или, возможно, действительно на основе какой-то другой информации.

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

Кроме того, вы ремонтировали это устройство после изменения маршрутизации от источника? Интересно, требуется ли какое-то взаимодействие конечному устройству для распознавания MTOR и маршрутизации от источника.

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

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

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

Я также мог бы вмешаться для тестирования, если мы сможем заставить его работать для Raspbee.

Я провел выше прошивку через ночь. Похоже, что маршрутизация от источника используется также при включенной маршрутизации по сетке, но очень редко. С ок. Только 2 миллиона пакетов <5 использовали исходный маршрут.

Интересно! Было бы неплохо получить представление о логике принятия решений, когда используется исходный маршрут, и о том, можно ли как-то повлиять / настроить на него.

Я на распби, поэтому не могу проверить это. Не могли бы вы создать его и для этого?

Не уверен, мне нужно проверить другую конфигурацию стека, используемую ConBee I и RaspBee I, если это возможно.

Было бы замечательно...

Мне интересно, можем ли мы обойти эту проблему с помощью своего рода статического маршрута, который мы можем загрузить в прошивку при запуске или, возможно, действительно на основе какой-то другой информации.

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

Согласовано

Кроме того, вы ремонтировали это устройство после изменения маршрутизации от источника? Интересно, требуется ли какое-то взаимодействие конечному устройству для распознавания MTOR и маршрутизации от источника.

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

Думаю, поможет ли это устройству Philips ...

Привет, ребята, я использовал прошивку Z2M Source Routing в течение 24 часов (допускает только 5 прямых подключений). Имею ~ 35 устройств. Он работает нормально, но я заметил, что устройствам Hue требуется цикл питания для повторного подключения после того, как я перешел с прошивки по умолчанию на прошивку SR. Ikea и Xiaomi подключились автоматически. Может быть, это может частично объяснить наблюдаемое вами поведение Hue?

Привет,
Я повторно протестировал свою лампу TRADFRI E14 WS opal 400lm с прошивкой ikea 2.3.050 и последней бета-версией deconz и последней прошивкой на моем Conbee I. Я могу подтвердить, что лампы и связь улучшились. Вызов сцены, включение / выключение, постепенное появление и исчезновение теперь работает лучше, но проблема осталась.

Проблемы, описанные здесь # 2518, в основном решены. Похоже, что групповые команды (из фосконового интерфейса) работают даже лучше. # 2518 закрыто

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

Появляется новая проблема # 2892: если в группе вызывается сцена и включаются все принадлежащие ей лампочки (из-за сцены), а затем - другая сцена в этой группе с включенными только несколькими лампочками (определяется сценой) вспоминается, "нежелательные" лампочки, которые должны выключиться, остаются включенными.
Более того, если вы выключите группу, то погаснут только лампочки текущей определенной сцены, а остальные из предыдущей сцены (предыдущая сцена из группы) останутся включенными. Им нужно несколько команд выключения перед тем, как уйти.
Проблема описана здесь, но она точно связана с API, поскольку не имеет никакого значения при использовании Phoscon или самого API. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

дополнительное примечание: используется последняя версия ikea fw 2.3.050 от 20.5.2020

Версия выпуска: 1.12.1
20 мая 2020
Новые функции и изменения в аксессуарах:
WS 1.0 (E14, E27, GU10) V-2.3.050.
Фиксированное состояние «Вкл. Выкл.» После обновления OTA.

Спасибо за постоянное улучшение и проделанную работу.

@manup , есть новости о версии прошивки исходного маршрута Conbee I? Я с нетерпением жду возможности проверить это :)

@manup , есть новости о версии прошивки исходного маршрута Conbee I? Я с нетерпением жду возможности проверить это :)

Моя первая попытка включить его закончилась ужасной ошибкой во время компиляции: / Еще не понял, в чем причина, и надеюсь каким-то образом его скомпилировать.

@manup , есть новости о версии прошивки исходного маршрута Conbee I? Я с нетерпением жду возможности проверить это :)

Моя первая попытка включить его закончилась ужасной ошибкой во время компиляции: / Еще не понял, в чем причина, и надеюсь каким-то образом его скомпилировать.

Хмммм, звучит не очень хорошо ... @manup , я бы хотел помочь, но у меня нет доступа к этому коду.

@manup , прогресс есть?

@manup , pssst! 😁

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

Все еще происходит. @manup есть ли прогресс и / или

@djwlindenaar @ JBS5 Я попросил @manup обновить.

Да, все еще проблема, хотя и гораздо меньшая, чем раньше.

Что нового по проблеме?

У меня около 20 GU10 белого спектра (первого поколения), подключенных к мосту Hue, и в рамках рационализации моей сети zigbee я хотел перенести все свои устройства на Deconz.

Оттенок довольно стабилен, но свет все равно время от времени отключается (например, один раз в неделю отключается один свет). Мне просто нужно перезапустить лампочки, чтобы их реанимировать.

Deconz более-менее стабилен?

Нет Deconz не стабильнее, у меня тоже около 40 ламп Ikea и иногда некоторые отключаются

@salopette У меня нет такого опыта. Не могли бы вы открыть отдельный выпуск? Есть журналы?

@Mimiix Эта проблема

Тоже самое. Свет по-прежнему иногда отключается. Но со временем он значительно улучшился. Когда я начал использовать deCONZ в 2018 году, мне приходилось ежедневно включать и выключать фонари ikea. Я чаще всего сталкиваюсь с этой проблемой с панелью FLOALT, но это также самый дальний от моего Conbee Stick источник света.

@ JBS5 Потому что мы ничего не знаем о настройке этого пользователя. Ни версии, ни логов, ни информации по настройке. Мы не можем определить, связана ли его проблема с этим.

Добавление комментариев без какой-либо информации в данном случае не помогает. Вот почему мне нужны отдельные проблемы, чтобы у нас был лучший обзор.

Однажды я попросил @manup в частном порядке разобраться в этом и расставить приоритеты.

@djwlindenaar глубоко

Общее сообщение:

Я только что поговорил по этому поводу с

`` Прошивка получит обновление в отношении проблем с маршрутизацией, а новая сеть, надеюсь, поможет воссоздать проблемы (что было невозможно раньше).
Я планирую, что следующая прошивка будет доступна в течение следующих 2–3 недель.

Некоторые изменения уже внесены, но еще не опубликованы.
``

Я буду держать вас в курсе.

Общее сообщение:

Я только что поговорил по этому поводу с

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Я буду держать вас в курсе.

3 недели спустя, есть ли обновления по этому поводу?

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)

Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)

Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)

Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

@lubbertkramer Пожалуйста, будьте разумны, устаревший бот был шуткой. Единственное обещание @Mimiix, сделанное ранее, - делиться обновлениями, как только они станут доступны, поэтому совершенно справедливо спросить о текущем статусе. Что касается ETA, то ничего не обещано, и я понимаю, что не будет, так как это сложный вопрос. Насколько я знаю, когда я говорю о неприятных вещах, это, к сожалению, не то, что можно разобрать в течение дня, проявляться только по прошествии значительного времени или вызывать какие-то непредвиденные побочные эффекты.

Так что в этом смысле, пожалуйста, наберитесь терпения и позвольте ребятам поработать над этим (кстати, это еще время отпуска). Если говорить о следующем выпуске, то через 1,5 недели можно поднять руку и спросить новости.

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)

Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Полагаю, проблемы с перезагрузкой не связаны с этой проблемой?
Что насчет изменений маршрутизации и упомянутых улучшений отладки? Связаны ли эти улучшения отладки с этой проблемой?

И основаны ли эти изменения маршрутизации на выводах @djwlindenaar или @manup уже может быть более конкретным?

@lubbertkramer Пожалуйста, будьте разумны, устаревший бот был шуткой. Единственное обещание @Mimiix, сделанное ранее, - делиться обновлениями, как только они станут доступны, поэтому совершенно справедливо спросить о текущем статусе. Что касается ETA, то ничего не обещано, и я понимаю, что не будет, так как это сложный вопрос. Насколько я знаю, когда я говорю о неприятных вещах, это, к сожалению, не то, что можно разобрать в течение дня, проявляться только по прошествии значительного времени или вызывать какие-то непредвиденные побочные эффекты.

Так что в этом смысле, пожалуйста, наберитесь терпения и позвольте ребятам поработать над этим (кстати, это еще время отпуска). Если говорить о следующем выпуске, то через 1,5 недели можно поднять руку и спросить новости.

Я думаю, что более чем разумно удерживать людей перед принятым сообщением или обещаниями, не делая «шуток», когда 2-3 недели прошли без последующих действий. Пользователи, которые много исследовали и ответили здесь, уже ушли из-за отсутствия последующих действий / общения.

Итак, вернемся к вопросу, какова последняя информация по этому вопросу?

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)

Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)

Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

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

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

_Будь переменой, которую ты хочешь увидеть в этом мире_

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)
Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

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

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

_Будь переменой, которую ты хочешь увидеть в этом мире_

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

Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы дальнейшие действия?

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)
Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

У меня нет проблем с тем, чтобы оставить эту проблему позади, когда вы так поступаете. Я ни в коем случае не представитель, я высовываю здесь шею, чтобы разобраться, поскольку у меня прямая связь. Устаревший бот, который я использую для отслеживания проблем, и я получаю уведомление. Я ожидаю, что человек вернется ко мне, и если время прошло, устаревший бот поможет мне напомнить.
Так что нет, прятаться за этим не «хромо». Если бы вы сделали то, что я сделал для сообщества, вы бы знали лучше. Также добавлю, что не то чтобы у меня не было других дел в жизни.
_Будь переменой, которую ты хочешь увидеть в этом мире_

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

Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы дальнейшие действия?

Все, что у меня было, это то, что я сказал. Позвольте мне посоветовать вам держать свои эмоции под контролем. Я понимаю ваш гнев, но проявление неуважения не помогает. Я не приемлю здесь никакого флейма. Держите его по теме и вежливо. Я просто объясняю, в чем состоят мои аргументы и почему я поступаю именно так.

Если вы хотите начать проблему, чтобы пожаловаться, пожалуйста, будь моим гостем. Только не делайте этого в этом выпуске.

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)
Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

У меня нет проблем с тем, чтобы оставить эту проблему позади, когда вы так поступаете. Я ни в коем случае не представитель, я высовываю здесь шею, чтобы разобраться, поскольку у меня прямая связь. Устаревший бот, который я использую для отслеживания проблем, и я получаю уведомление. Я ожидаю, что человек вернется ко мне, и если время прошло, устаревший бот поможет мне напомнить.
Так что нет, прятаться за этим не «хромо». Если бы вы сделали то, что я сделал для сообщества, вы бы знали лучше. Также добавлю, что не то чтобы у меня не было других дел в жизни.
_Будь переменой, которую ты хочешь увидеть в этом мире_

Никто не просит и не принуждает вас быть посредником в качестве пользователя, поэтому еще раз, вместо того, чтобы пылать и менять цветочную силу, оставьте эту проблему в качестве докладчика или вернитесь к проблеме и последней информации.
Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы дальнейшие действия?

Все, что у меня было, это то, что я сказал. Позвольте мне посоветовать вам держать свои эмоции под контролем. Я понимаю ваш гнев, но проявление неуважения не помогает. Я не приемлю здесь никакого флейма. Держите его по теме и вежливо. Я просто объясняю, в чем состоят мои аргументы и почему я поступаю именно так.

Если вы хотите начать проблему, чтобы пожаловаться, пожалуйста, будь моим гостем. Только не делайте этого в этом выпуске.

Единственное затруднение в этой проблеме - это manup и Dresden, очевидно, не в состоянии исправить эту проблему. Conbee - коммерческий продукт, и с этим связаны обязанности. Вот почему многие из нас уже оставили deCONZ / Conbee ради чипа TI и Z2M, который с тех пор работает безупречно.

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)
Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

У меня нет проблем с тем, чтобы оставить эту проблему позади, когда вы так поступаете. Я ни в коем случае не представитель, я высовываю здесь шею, чтобы разобраться, поскольку у меня прямая связь. Устаревший бот, который я использую для отслеживания проблем, и я получаю уведомление. Я ожидаю, что человек вернется ко мне, и если время прошло, устаревший бот поможет мне напомнить.
Так что нет, прятаться за этим не «хромо». Если бы вы сделали то, что я сделал для сообщества, вы бы знали лучше. Также добавлю, что не то чтобы у меня не было других дел в жизни.
_Будь переменой, которую ты хочешь увидеть в этом мире_

Никто не просит и не принуждает вас быть посредником в качестве пользователя, поэтому еще раз, вместо того, чтобы пылать и менять цветочную силу, оставьте эту проблему в качестве докладчика или вернитесь к проблеме и последней информации.
Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы дальнейшие действия?

Все, что у меня было, это то, что я сказал. Позвольте мне посоветовать вам держать свои эмоции под контролем. Я понимаю ваш гнев, но проявление неуважения не помогает. Я не приемлю здесь никакого флейма. Держите его по теме и вежливо. Я просто объясняю, в чем состоят мои аргументы и почему я поступаю именно так.

Если вы хотите начать проблему, чтобы пожаловаться, пожалуйста, будь моим гостем. Только не делайте этого в этом выпуске.

И опять же, вы не отвечаете и не обновляете статус, который запрашивают много раз, и единственное, что вы делаете, - это продолжаете обсуждение вне темы, где вы уже могли бы дать обновление, как его просят в конце каждого сообщения. Вы хвастаетесь своими прямыми связями / приглашениями на собраниях разработчиков, поэтому вы должны быть в курсе статуса этой проблемы и можете здесь сообщить всем читающим пользователям.

Так что еще раз опубликуйте обновление или перестаньте публиковать оффтоп, я думаю, это ваша работа как модератора сообщества, а не поддерживать оффтопические обсуждения :)

Общее сообщение:

Я только что поговорил по этому поводу с

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Я буду держать вас в курсе.

Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы последующие действия, чего мы можем ожидать пользователям?

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

У меня много tradfri без проблем работает уже больше года.
На данный момент у меня начались проблемы только с одним из моих фонарей Tradfri.
начал падать и подключаться к сетке примерно каждые 15 минут. 15 мин
достижимый, 15 мин недоступный. Провел много тестов, чтобы найти проблему.
Угадайте в чем .... проблемы были? Это был не deCONZ, а мой WiFi
расписание репитера с негодованием поставили на него.

Не будьте уверены, что проблемы всегда связаны с deCONZ, а иногда и нет.

В вс, 6 сентября 2020 г., 11:38 lubbertkramer [email protected] написал:

@ JBS5 https://github.com/JBS5 Еще нет трех недель. Ждал черствого бота
Вот ;)
Pmed @manup https://github.com/manup снова сегодня утром. Получил
следующий ответ:

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

Усовершенствования отладки появятся после выхода следующего стабильного выпуска.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, так что это нормально, они вас держат
к этому обещанию, 21 день / 7 дней = 3 недели
то хромо прятаться за stalebot, когда эта проблема уже
активен с февраля 2019 года. Если вы хотите быть представителем Дрездена
действуйте так или позвольте просто @manup https://github.com/manup справиться с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

У меня нет проблем с тем, чтобы оставить эту проблему позади, когда вы так поступаете.
Я ни в коем случае не представитель, я высовываю здесь шею, чтобы получить вещи
отсортировано, так как у меня прямая связь. Устаревший бот, который я использую, чтобы отслеживать
проблемы, и я получаю уведомление. Я ожидаю, что человек вернется ко мне и
если сроки прошли, мне помогает устаревший бот.
Так что нет, прятаться за этим не «хромо». Если бы вы сделали то, что я сделал для
сообщество, вам было бы лучше знать, чем это. Также добавлю, что это не так
У меня не было других дел в жизни.
Будьте тем изменением, которое вы хотите увидеть в этом мире

Никто не просит и не принуждает вас быть посредником в качестве пользователя, поэтому еще раз
вместо того, чтобы гореть и менять цветочную силу, оставьте эту проблему как
говорящего или вернитесь к проблеме и последней информации.
Прошло 2-3 недели, которые вы опубликовали в качестве общего объявления
больше 3 недель, так каковы дальнейшие действия?

Все, что у меня было, это то, что я сказал. Пожалуйста, позвольте мне посоветовать вам сохранить
эмоции под контролем. Я понимаю ваш гнев, но проявляю неуважение
не помогает. Я не приемлю здесь никакого флейма. Держите это по теме и
гражданский. Я просто объясняю, в чем состоят мои аргументы и почему я поступаю именно так.

Если вы хотите начать проблему, чтобы пожаловаться, пожалуйста, будь моим гостем. Только не
сделайте это в этом выпуске.

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

Так что еще раз выкладывайте апдейт или перестаньте выкладывать оффтоп :)

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 и @Mimiix Следующий выпуск, надеюсь, выйдет примерно через 2 недели, если вы посмотрите, как выпуск работает DE ("15th" = немного до выплаты). И неизвестно, находится ли в нем одно исправление с праздниками или без них.
Некоторые говорят (и я много раз) о том, как работает официальная поддержка, а у клиентов большие проблемы.
Не для протокола: ZHA через 1-2 недели начнет официальную поддержку Silabs EZSP всех версий своих протоколов стека, поэтому я думаю, что один Sonoff Zigbee Bridge или Elelabs-ELU013 / ELR023 лучше вложить деньги и получить больше мощности RF и SoC, чем продукты DE и лучшую поддержку со стороны сообщества.
Но я жду deCONZ REST-API версии 2, прежде чем позволить всем продуктам DE RIP.

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)
Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

У меня нет проблем с тем, чтобы оставить эту проблему позади, когда вы так поступаете. Я ни в коем случае не представитель, я высовываю здесь шею, чтобы разобраться, поскольку у меня прямая связь. Устаревший бот, который я использую для отслеживания проблем, и я получаю уведомление. Я ожидаю, что человек вернется ко мне, и если время прошло, устаревший бот поможет мне напомнить.
Так что нет, прятаться за этим не «хромо». Если бы вы сделали то, что я сделал для сообщества, вы бы знали лучше. Также добавлю, что не то чтобы у меня не было других дел в жизни.
_Будь переменой, которую ты хочешь увидеть в этом мире_

Никто не просит и не принуждает вас быть посредником в качестве пользователя, поэтому еще раз, вместо того, чтобы пылать и менять цветочную силу, оставьте эту проблему в качестве докладчика или вернитесь к проблеме и последней информации.
Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы дальнейшие действия?

Все, что у меня было, это то, что я сказал. Позвольте мне посоветовать вам держать свои эмоции под контролем. Я понимаю ваш гнев, но проявление неуважения не помогает. Я не приемлю здесь никакого флейма. Держите его по теме и вежливо. Я просто объясняю, в чем состоят мои аргументы и почему я поступаю именно так.
Если вы хотите начать проблему, чтобы пожаловаться, пожалуйста, будь моим гостем. Только не делайте этого в этом выпуске.

И опять же, вы не отвечаете и не обновляете статус, который запрашивают много раз, и единственное, что вы делаете, - это продолжаете обсуждение вне темы, где вы уже могли бы дать обновление, как его просят в конце каждого сообщения. Вы хвастаетесь своими прямыми связями / приглашениями на собраниях разработчиков, поэтому вы должны быть в курсе статуса этой проблемы и можете здесь сообщить всем читающим пользователям.

Так что еще раз опубликуйте обновление или перестаньте публиковать оффтоп, я думаю, это ваша работа как модератора сообщества, а не поддерживать оффтопические обсуждения :)

Общее сообщение:
Я только что поговорил по этому поводу с

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Я буду держать вас в курсе.

Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы последующие действия, чего мы можем ожидать пользователям?

Чтобы ответить прямо на ваш вопрос: это то, что @manup сказал мне после того, как я спросил его снова. Я не могу никого заставить что-то делать. Спрошу еще раз после выходных.

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

@ JBS5 Еще нет 3 недель. Ждал вот черствого бота;)
Pmed @manup снова сегодня утром. Получил следующий ответ:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Я попросил ETA, и он сейчас на нем.

Что ж, вы дали обещание сообществу, поэтому нормально, что они держат вас за это обещание, 21 день / 7 дней = 3 недели
тогда глупо прятаться за stalebot, когда эта проблема уже активна с февраля 2019 года. Если вы хотите быть спикером Дрездена, действуйте так, как это, или пусть просто @manup справится с этим :)
Итак, какое сейчас расчетное время прибытия, прошло 2-3 недели

У меня нет проблем с тем, чтобы оставить эту проблему позади, когда вы так поступаете. Я ни в коем случае не представитель, я высовываю здесь шею, чтобы разобраться, поскольку у меня прямая связь. Устаревший бот, который я использую для отслеживания проблем, и я получаю уведомление. Я ожидаю, что человек вернется ко мне, и если время прошло, устаревший бот поможет мне напомнить.
Так что нет, прятаться за этим не «хромо». Если бы вы сделали то, что я сделал для сообщества, вы бы знали лучше. Также добавлю, что не то чтобы у меня не было других дел в жизни.
_Будь переменой, которую ты хочешь увидеть в этом мире_

Никто не просит и не принуждает вас быть посредником в качестве пользователя, поэтому еще раз, вместо того, чтобы пылать и менять цветочную силу, оставьте эту проблему в качестве докладчика или вернитесь к проблеме и последней информации.
Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы дальнейшие действия?

Все, что у меня было, это то, что я сказал. Позвольте мне посоветовать вам держать свои эмоции под контролем. Я понимаю ваш гнев, но проявление неуважения не помогает. Я не приемлю здесь никакого флейма. Держите его по теме и вежливо. Я просто объясняю, в чем состоят мои аргументы и почему я поступаю именно так.
Если вы хотите начать проблему, чтобы пожаловаться, пожалуйста, будь моим гостем. Только не делайте этого в этом выпуске.

И опять же, вы не отвечаете и не обновляете статус, который запрашивают много раз, и единственное, что вы делаете, - это продолжаете обсуждение вне темы, где вы уже могли бы дать обновление, как его просят в конце каждого сообщения. Вы хвастаетесь своими прямыми связями / приглашениями на собраниях разработчиков, поэтому вы должны быть в курсе статуса этой проблемы и можете здесь сообщить всем читающим пользователям.
Так что еще раз опубликуйте обновление или перестаньте публиковать оффтоп, я думаю, это ваша работа как модератора сообщества, а не поддерживать оффтопические обсуждения :)

Общее сообщение:
Я только что поговорил по этому поводу с

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Я буду держать вас в курсе.

Прошло 2–3 недели, которые вы разместили в качестве общего объявления, более чем на 3 недели, так каковы последующие действия, чего мы можем ожидать пользователям?

Чтобы ответить прямо на ваш вопрос: это то, что @manup сказал мне после того, как я спросил его снова. Я не могу никого заставить что-то делать. Спрошу еще раз после выходных.

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

Это небольшой ответ, поэтому, когда я правильно прочитал, мы можем ожидать более подробного ответа позже на этой неделе, потому что прошло почти 4 недели вместо 2-3, которые @manup сообщил через вас в качестве общего объявления о том, что обновление будет имеется в наличии

@Mimiix, если вы видите желание закрыть эту проблему, которая почти открыта в течение двух лет с большим количеством информации от очень поддерживающих и преданных пользователей без решения, тогда я не тот человек, который может вас сдерживать, это зависит от вас как сообщества пресс-секретарь :)

@lubbertkramer Я сказал Лок, а не близко.

И с этим я заблокирую этот выпуск. Я разблокирую через несколько дней или когда здесь ответит Мануэль.

Еще раз привет, думаю, пришло время рассказать об этой проблеме.

Но обо всем по порядку, если кто и виноват здесь, так это я и только я. Я понимаю разочарование, но здесь нет места невежливости по отношению к @Mimiix , поэтому давайте будем

Обновление прогресса

(Превью для следующего выпуска)

Я много тестировал маршрутизацию от источника и экспериментировал с результатами этой проблемы и различными журналами снифферов. Потратьте много времени на то, чтобы «автоматическая» маршрутизация от источника работала надежно на основе входящих команд записи маршрута. Это в основном то, что делает большинство реализаций исходной маршрутизации - например, прошивка исходной маршрутизации для zigbee2mqtt. Иногда это работает, но, похоже, большая динамика в том, как / если исходный маршрут выбирается (и сохраняется) на основе значений LQI / RSSI, которые узел записи маршрута видит от своих соседей, в смешанных сетях это сложно из-за различий в стеке и железе. Качество связи также может быть довольно динамичным, если люди перемещаются между узлами, а двери открываются и закрываются, что, к сожалению, также влияет на маршрутизацию.

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

• Исходные маршруты могут быть дополнительно указаны для каждого узла.
• Каждый прыжок всегда должен быть включен.
• Позиции прыжков на пути должны быть разумными. В некоторых случаях у пользователя может быть лучший план маршрутизации пакетов, чем тот, который может определить автоматический алгоритм.

Для этого протокол микропрограмм был расширен, чтобы опционально предоставлять исходный маршрут для каждого запроса APS. Не существует ограничений на количество маршрутов к источникам, которые можно настроить, микропрограммному обеспечению требуется только сохранить несколько маршрутов в памяти для запросов и ACK.

deCONZ автоматически определяет, доступен ли каждый переход на маршруте, и только в этом случае использует исходный маршрут.
За кулисами исходные маршруты настраиваются с MAC-адресами узлов, чтобы быть устойчивыми к изменениям адреса NWK.

Создание фиксированного исходного маршрута

• В интерфейсе deCONZ выберите все переходы, удерживая CTRL (множественный выбор), начиная от координатора (источника) до узла назначения. Важно, чтобы между источником и местом назначения был хотя бы один переход.
• Щелкните правой кнопкой мыши целевой узел, чтобы открыть контекстное меню.
• Выберите «Добавить исходный маршрут».

Это создаст новый исходный маршрут, отображаемый синей линией и красными концевыми метками к узлу назначения.

(В более поздних выпусках можно будет указать альтернативные резервные маршруты, но мне нужно найти для этого хороший пользовательский интерфейс.)

Чтобы удалить исходный маршрут: Выберите «Удалить исходный маршрут» в контекстном меню узла назначения.

Маршрут будет использован для следующего запроса:

Это работает очень хорошо и позволяет при необходимости перезаписывать маршрутизацию вручную, что также может быть полезно для тестирования.
В настоящее время это работает только при настройке через графический интерфейс, но позже он должен быть доступен через REST-API.

Это все исправит?

Маловероятно, но это должно улучшить маршрутизацию к пунктам назначения (маршрутизация на самих узлах не может быть настроена). Обратите внимание, что фиксированные исходные маршруты подходят только для маршрутизаторов, поскольку конечные устройства имеют тенденцию изменять родительский объект, и исходный маршрут больше не будет работать, в этом случае автоматическая исходная маршрутизация может работать лучше.

Когда он выйдет?

Вскоре, в следующем выпуске 2.05.81, у меня появятся следующие (довольно легкие) пункты в списке дел для этого выпуска:

• Сохранение / восстановление исходных маршрутов в базе данных.
• Исправить обработку счетчика безопасности NWK, чтобы исправить резервную копию между различными ConBee / RaspBee и перезагрузить, ошибка ничего не работает.
• Позвольте GCFFlasher проверить, работает ли прошивка после обновления.

Итак, с его ответом @manup , ответ был дан. Пожалуйста, оставайтесь по теме и по теме.

Еще раз привет, думаю, пришло время рассказать об этой проблеме.

Обновление прогресса

(Превью для следующего выпуска)

Я много тестировал маршрутизацию от источника и экспериментировал с результатами этой проблемы и различными журналами снифферов. Потратьте много времени на то, чтобы «автоматическая» маршрутизация от источника работала надежно на основе входящих команд записи маршрута. Это в основном то, что делает большинство реализаций исходной маршрутизации - например, прошивка исходной маршрутизации для zigbee2mqtt. Иногда это работает, но, похоже, большая динамика в том, как / если исходный маршрут выбирается (и сохраняется) на основе значений LQI / RSSI, которые узел записи маршрута видит от своих соседей, в смешанных сетях это сложно из-за различий в стеке и железе. Качество связи также может быть довольно динамичным, если люди перемещаются между узлами, а двери открываются и закрываются, что, к сожалению, также влияет на маршрутизацию.

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

• Исходные маршруты могут быть дополнительно указаны для каждого узла.
• Каждый прыжок всегда должен быть включен.
• Позиции прыжков на пути должны быть разумными. В некоторых случаях у пользователя может быть лучший план маршрутизации пакетов, чем тот, который может определить автоматический алгоритм.

Для этого протокол микропрограмм был расширен, чтобы опционально предоставлять исходный маршрут для каждого запроса APS. Не существует ограничений на количество маршрутов к источникам, которые можно настроить, микропрограммному обеспечению требуется только сохранить несколько маршрутов в памяти для запросов и ACK.

deCONZ автоматически определяет, доступен ли каждый переход на маршруте, и только в этом случае использует исходный маршрут.
За кулисами исходные маршруты настраиваются с MAC-адресами узлов, чтобы быть устойчивыми к изменениям адреса NWK.

Создание фиксированного исходного маршрута

• В интерфейсе deCONZ выберите все переходы, удерживая CTRL (множественный выбор), начиная от координатора (источника) до узла назначения. Важно, чтобы между источником и местом назначения был хотя бы один переход.
• Щелкните правой кнопкой мыши целевой узел, чтобы открыть контекстное меню.
• Выберите «Добавить исходный маршрут».

Это создаст новый исходный маршрут, отображаемый синей линией и красными концевыми метками к узлу назначения.

(В более поздних выпусках можно будет указать альтернативные резервные маршруты, но мне нужно найти для этого хороший пользовательский интерфейс.)

Чтобы удалить исходный маршрут: Выберите «Удалить исходный маршрут» в контекстном меню узла назначения.

Маршрут будет использован для следующего запроса:

Это работает очень хорошо и позволяет при необходимости перезаписывать маршрутизацию вручную, что также может быть полезно для тестирования.
В настоящее время это работает только при настройке через графический интерфейс, но позже он должен быть доступен через REST-API.

Это все исправит?

Маловероятно, но это должно улучшить маршрутизацию к пунктам назначения (маршрутизация на самих узлах не может быть настроена). Обратите внимание, что фиксированные исходные маршруты подходят только для маршрутизаторов, поскольку конечные устройства имеют тенденцию изменять родительский объект, и исходный маршрут больше не будет работать, в этом случае автоматическая исходная маршрутизация может работать лучше.

Когда он выйдет?

Вскоре, в следующем выпуске 2.05.81, у меня появятся следующие (довольно легкие) пункты в списке дел для этого выпуска:

• Сохранение / восстановление исходных маршрутов в базе данных.
• Исправить обработку счетчика безопасности NWK, чтобы исправить резервную копию между различными ConBee / RaspBee и перезагрузить, ошибка ничего не работает.
• Позвольте GCFFlasher проверить, работает ли прошивка после обновления.

Спасибо за подробный ответ. Я думаю, что многие из нас ждут ответа, подобного приведенному выше, из-за всей тяжелой работы, которую сообщество проделывает над этой проблемой, а вы как разработчик делаете это.

Несколько дополнительных вопросов, которые у меня есть:

• Когда будет доступно обновление в бета / стабильной версии выше?

• Будет ли разница в том, как выше будет работать в отношении conbee 1/2 и Raspbee, или все будет одинаково?

• В обновлении 2.05.81 вы упомянули, что в списке дел будут довольно (легкие) элементы, когда мы можем ожидать этого обновления (может быть, это идея добавить дорожную карту к этому git?)

Привет @lubbertkramer

Я могу ответить на первый вопрос: версия 2.05.81 ожидается 15-го числа месяца (сборка Windows - несколько дней спустя). Я разместил это в анонсе ранее в Discord, но я просто подумал, что это не относится к Github. Я добавлю это в ридми! Виноват!

Изменить: сделал запрос на извлечение файла readme.md. Я не уверен, как работает стабильный канал, что нужно немного уточнить.

Будет ли разница в том, как выше будет работать в отношении conbee 1/2 и Raspbee, или все будет одинаково?

Он должен работать так же, теперь я перенес код на RaspBee I / ConBee I, и исходные маршруты используются там таким же образом.

В настоящее время у меня есть любопытный случай, когда ретранслятор IKEA работает, но не хочет играть с остальной частью сети.
Отправленные ему команды (с исходными маршрутами и без них) игнорируются без уведомления.

Повторитель отправляет свои кадры состояния канала NWK, но сообщает и пустой список соседей:

Команды от координатора, а также от датчика OSRAM, для которого репитер является родительским, игнорируются. Датчик, как и многие устройства Xiaomi, не пытается автоматически найти нового родителя ... плохая ситуация:

Этот сценарий работает уже два дня, не нашел способ восстановить ретранслятор. Возможно, цикл питания репитера решит проблему, но я пока оставлю это так, чтобы посмотреть, можно ли как-то решить эту проблему по воздуху.

Возникла проблема с повторителем Tradfri USB или вилкой Tradfri?

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

Можно ли проверить? У меня есть 3 разъема Tradfri, на которых установлена ​​последняя версия FW Rock Solid около 1,5 года. Если у меня возникнут проблемы с новой бета-версией, мне придется отложить обновление.

Благодаря!

Вот данные из базового кластера. Обратите внимание, что проблема впервые возникла два дня назад в моей домашней сети, в которой в то время не было новой прошивки.

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

Веб-страница с журналом изменений tradfri недоступна, чтобы проверить, что исправлено в последней версии встроенного ПО.

Последние файлы прошивки сейчас онлайн:

ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I и ConBee I

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• В них включена маршрутизация от источника с макс. 32 исходных маршрута, в которых самые старые записи автоматически заменяются новыми. Сумма, вероятно, будет увеличена в более поздних выпусках, но уже должна работать хорошо.
• Если существует исходный маршрут и «нормальная» запись маршрута, предпочтительным является исходный маршрут. Это нестандартно, но, похоже, работает лучше.
• Прошивка имеет общие улучшения для устойчивости последовательного протокола.
• ConBee II и RaspBee II получили улучшенную обработку счетчика кадров, чтобы смягчить проблемы, когда после выключения питания сеть могла казаться потерянной, пока счетчик кадров снова не достигнет своего старого значения.

@manup сделал прошивку для ConBee Сбросил version command id 0x0D ? Я больше не получаю ответа на эту команду

@Adminiuga @manup Сведения о прошивке: используйте # 3260.

Последние файлы прошивки сейчас онлайн:

ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I и ConBee I

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• В них включена маршрутизация от источника с макс. 32 исходных маршрута, в которых самые старые записи автоматически заменяются новыми. Сумма, вероятно, будет увеличена в более поздних выпусках, но уже должна работать хорошо.
• Если существует исходный маршрут и «нормальная» запись маршрута, предпочтительным является исходный маршрут. Это нестандартно, но, похоже, работает лучше.
• Прошивка имеет общие улучшения для устойчивости последовательного протокола.
• ConBee II и RaspBee II получили улучшенную обработку счетчика кадров, чтобы смягчить проблемы, когда после выключения питания сеть могла казаться потерянной, пока счетчик кадров снова не достигнет своего старого значения.

Как прошить эту прошивку (я использую образ Docker от marthoc deCONZ)?

Я загрузил файл (ConBee II), но инструкции по обновлению вручную не применимы к образу Docker deCONZ от marthoc, а руководство для deCONZ от marthoc не позволяет использовать прошивку, не включенную в образ (и этот файл не указан в списке) как есть).

Как прошить эту прошивку (я использую образ Docker от marthoc deCONZ)?

Я просто подключаю USB-ключ к ноутбуку с Windows и делаю это оттуда и обратно в свой Synology NAS, когда это будет сделано.

Как прошить эту прошивку (я использую образ Docker от marthoc deCONZ)?

Я просто подключаю USB-ключ к ноутбуку с Windows и делаю это оттуда и обратно в свой Synology NAS, когда это будет сделано.

Есть ли утилита Windows для прошивки прошивки? Если да, не могли бы вы поделиться ссылкой?

Как прошить эту прошивку (я использую образ Docker от marthoc deCONZ)?

Я просто подключаю USB-ключ к ноутбуку с Windows и делаю это оттуда и обратно в свой Synology NAS, когда это будет сделано.

Есть ли утилита Windows для прошивки прошивки? Если да, не могли бы вы поделиться ссылкой?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

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

• Исходные маршруты могут быть дополнительно указаны для каждого узла.
• Каждый прыжок всегда должен быть включен.
• Позиции прыжков на пути должны быть разумными. В некоторых случаях у пользователя может быть лучший план маршрутизации пакетов, чем тот, который может определить автоматический алгоритм.

Это все исправит?

Маловероятно, но это должно улучшить маршрутизацию к пунктам назначения (маршрутизация на самих узлах не может быть настроена). Обратите внимание, что фиксированные исходные маршруты подходят только для маршрутизаторов, поскольку конечные устройства имеют тенденцию изменять родительский объект, и исходный маршрут больше не будет работать, в этом случае автоматическая исходная маршрутизация может работать лучше.

Просто чтобы уточнить ... собирается ли эта новая прошивка исправить (или, по крайней мере, улучшить) случайное отключение устройств Ikea, если я не настрою вручную какие-либо новые маршруты статических источников? Или единственный способ извлечь выгоду из этого обновления - вручную установить маршруты тех устройств, которые имеют тенденцию терять соединение?

Без ручной настройки маршрутов происходит автоматическая маршрутизация от источника, если устройства продвигают их (как это делают устройства IKEA).
Таким образом, по сравнению с предыдущей прошивкой, для этих устройств будет использоваться маршрутизация от источника, если такой маршрут известен.

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

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

У меня 21 фонарь (4 - 980lu WS, 17 - 1000lu WS), 3 штекера и 3 (5 кнопочных) круглых пульта Ikea. Все они на последних прошивках Ikea. Я ни разу не испытывал с ними нестабильности за последние полтора года. Ночью с любой из предыдущих версий deCONZ или выпусков FW, ни с текущей. Я использую стабильный .81 с последней версией RaspBee FW 0x26370500, и также не испытываю никаких проблем за последнюю неделю их использования.

Я думаю .... (возможно, я не совсем прав) У Ikea нет общей проблемы, но она специфична для настройки. Существует множество различных факторов, которые могут повлиять на их поведение и производительность в deCONZ и в целом.

Я думаю, что больше всего проблем возникло с лампами Ikea GU10. Со временем стабильность значительно улучшилась, но в конце 2018 года, когда я начинал, все было плохо. В течение последних трех месяцев выпуска / прошивки мне приходилось включать и выключать один из 30 GU10 в среднем каждые две недели.

Я думаю, что больше всего проблем возникло с лампами Ikea GU10. Со временем стабильность значительно улучшилась, но в конце 2018 года, когда я начинал, все было плохо. В течение последних трех месяцев выпуска / прошивки мне приходилось включать и выключать один из 30 GU10 в среднем каждые две недели.

Может быть. Насколько мне известно, GU10 не получил обновления прошивки, как другие фонари Ikea. Недавно мы обсуждали это в каналах Discord. Такое поведение наблюдается у пользователя, использующего светильники GU10 Ikea. Никакой материи из того, что мы пробовали, похоже, ничто не решает его проблемы. Он даже поделился с нами, что купил Ikea Tradfri Hub, и у него такой же плохой опыт, даже с Ikea Hub и лампами GU10.

Итак, я думаю, что это вопрос времени, когда Ikea выпустит новую прошивку для этого типа ламп, чтобы, возможно, решить эту проблему ...

Мне интересно, обновился ли

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

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

Я обновил прошивку до последней версии 2 дня назад, и с тех пор один из моих настенных выключателей Xiaomi (ctrl_neutral2, 25.11.2017) переключился сам по себе 3 раза. У меня никогда раньше не было такой проблемы.

Он подключен к координатору через лампочку Tradfri E27 CWS на 1.3.009.

Кроме того, это не относится к этой проблеме, но мне так и не удалось получить обновление OTA с помощью Deconz (контейнер сообщества).

У меня лампочки Tradfri:

• E27 CWS на 1.3.009
• E14 W на 1.2.214
• Беспроводной диммер на 1.2.248
• 17 * GU10 WS на 1.2.221

Я вижу загруженные файлы Trafri OTA, но ничего не происходит. Что я должен делать?

Для справки, контейнер запускается так:

docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v /opt/otau:/root/otau -v /opt/deconz:/root/.local/share/dresden-elektronik/deCONZ --device=/dev/ttyACM0 -e DECONZ_WEB_PORT=801 -e DECONZ_WS_PORT=445 -e DECONZ_VNC_PORT=5930 -e DECONZ_VNC_PASSWORD=... -e DECONZ_VNC_MODE=1 -e DEBUG_INFO=1 marthoc/deconz

@ ReX1983 Это не связано с этой проблемой здесь, афайк. Пожалуйста, откройте отдельный вопрос. Я думаю, вам следует опубликовать репозиторий версии Docker. https://github.com/marthoc/docker-deconz

Примечание модератора:

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

Все, что связано с исходной проблемой: IKEA светится, время от времени теряя соединение, разрешено в этой проблеме.

Любые другие вопросы, связанные с прошивкой, можно публиковать здесь.

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

@ JBS5 , помог ваш триггер;)

Я только что установил прошивку и последнюю версию deCONZ .deb. Пока могу подтвердить, что маршрутизация от источника работает, по стабильности конечно никаких выводов. Я буду держать тебя в курсе

ZigBee Network Layer Data, Dst: 0x0ea4, Src: DeConz
    Frame Control Field: 0x0608, Frame Type: Data, Discover Route: Suppress, Security, Source Route Data
    Destination: 0x0ea4[0x0ea4]
    Source: 0x0000[DeConz]
    Radius: 10
    Sequence Number: 190
    [Extended Source: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)]
    [Origin: 366]
    Source Route, Length: 2
        Relay Count: 2
        Relay Index: 1
        Relay 1: 0xc803[0xc803]
        Relay 2: 0xf1e5[0xf1e5]
    ZigBee Security Header

@ ReX1983 Посмотрите, как работает плагин OTA https://github.com/dresden-elektronik/deconz-ota-plugin и обновляет ваши устройства.
Извините, но это единственная проблема со связью устройства IKEA.

@ morfei1 @ peer69
Могу подтвердить, что дело не только в лампочках GU10. У меня были проблемы с маршрутизацией и потерей соединения в течение долгого времени, так как в моей системе не было GU10.

У меня были некоторые начальные проблемы после выпуска .82 с новой прошивкой на моем conbee 1.
Но теперь, после того, как сетевая сеть успокоилась и несколько циклов включения питания, последние пару дней она работала как скала.

Каким бы я ни был тупой, я решил обновить прошивку до последней версии (OTAU) на всех своих лампах, чтобы иметь лучшую исходную информацию, с которой можно будет начать, если возникнут проблемы в будущем. Пожелай мне удачи. Будем держать вас в курсе, ребята, о прогрессе.

@tubalainen вы используете аддон HA?

@tubalainen вы используете аддон HA?

Нет, я использую HA Core в Debian в докере, поэтому я также использую https://github.com/marthoc/docker-deconz stand-a-lone docker package. Оба они используют файл .deb, предоставленный dresten, поэтому должны работать одинаково. Я не уверен, включен ли плагин OTAU в надстройку deconz HA ....

пока просто вмешиваюсь в мои наблюдения;

У меня есть проблемы только с моим Ikea GU-10 (23 из них), и я использую Home Assistant, который подключается к deconz (docker) через остальной api, и я вижу, что HA успешно запускает события для deconz.

Когда я использую HA для включения, 17 лампочек, одна за другой (сразу после друг друга), может быть, 3 из 17 dosnt включаются, но HA видит их включенными.
НО, если я сделаю группу в деконз. поместите все индикаторы в эту группу и скажите HA включить эту группу, еще не было никаких проблем, все индикаторы включаются.

Использование прошивки: 0x26650700 я не заметил каких-либо улучшений (кроме того, что мне по какой-то причине пришлось повторно соединить эти 17 лампочек, и даже после повторного соединения у меня были те же проблемы)

это может быть ограничение на rest-api?

@MartinTerp , если вы используете одну команду для каждого устройства за раз, а не одну команду для группы, она будет терпеть неудачу, возможно, не каждый раз, но в большинстве случаев случайные устройства, которые должны что-то делать, не будут этого делать.

Мое обходное решение - задержка 5 секунд между командами. Например
Если я хочу включить свет в своей спальне в 23:00 в bri: 127 и ct: 454, а также в коридоре, я даю 5-секундную задержку для одной из комнат. Если я не поставлю задержку, он случайно не сможет выполнить полную команду для одной из комнат или, возможно, для них обеих. Я много экспериментирую с этим. Это что-то похожее на ошибку Ikea, она не может одновременно переключать цвет и яркость.

Я не знаю, что это именно, ошибка деконзирования, ограничение зигби в целом или ошибка Ikea FW. Может быть, это мое незнание, как работает zigbee, но 5-секундная задержка всегда работает для меня.

Как правило, я всегда использую: sand как можно меньше команд за раз или использую задержку. Таким образом вы сохраняете канал в чистоте.

Если вам нужно переключать несколько групп / источников света за раз, как вы заметили, всегда лучше создать новую группу фоскон, включив в нее эти группы источников света, и отправить им одну команду группы. У вас может быть много разных групп, включая один и тот же свет. Мы не ограничены использованием одной группы для каждого источника света. Если вам не нравится иметь много групп в фосконе, то отсрочка - ваш лучший друг.

@ morfei1 Я использую аналогичный обходной путь, и в большинстве случаев он работает с задержкой 5 секунд между всеми командами.
@MartinTerp У меня также была эта проблема с другими устройствами, кроме светильников IKEA-Tradfri, например, с интеллектуальными вилками OSRAM и световыми полосами. Я предполагаю, что это возможно, хотя проблема была вызвана каким-то глючным Tradfri-Lights, не пересылающим команды.

Но ведь это не должно быть так, не так ли?
в тот момент, когда сценарий включает их 1 на 1 с задержкой в ​​1 секунду, ДОЛЖЕН ли он справиться с этим?

@ morfei1 @MartinTerp

Я также использовал задержки +, которые я отправляю команды включения и выключения от домашнего помощника дважды за срабатывание автоматизации.

Я удалил задержки и повторяю команды с .82.

Я почти уверен, что задержка в 5 секунд не нужна. Я думаю, что в некоторых более ранних версиях этого не было, но я бы не стал на это делать ставку, поскольку с тех пор моя сеть выросла. Возможно, 82 (еще не пробовали с уменьшенной задержкой) или будущие версии улучшат это поведение.

@ morfei1 @githtz @tubalainen @martinterp

Не могли бы мы обсудить, как обновить прошивку устройств еще?

Мы не занимаемся обновлением прошивки?

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

Я предлагаю открыть для этого отдельную задачу, например «Не все индикаторы реагируют на отправку одноадресных команд нескольким источникам».

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

Отредактировано Mimiix

Отредактировано Mimiix

@inconsx @ ReX1983 Я думал, что все ясно на https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 и https://github.com/dresden-elektronik/deconz- rest-plugin / issues / 1261 # issuecomment -696046160

Пожалуйста, придерживайтесь этих правил. Если хотите, откройте отдельные вопросы.

Итак, вот мой отзыв, я обновил прошивку до последней версии и deconz api. Я запускаю свою сеть из HA.

У меня порядка 72 узлов, большинство из них - фары IKEA GU10. После обновления я заметил два разных GU10, которые «умерли» в два разных дня, единственный способ вернуть их - это выключить питание. GU10 использует приспособления 1.2.217 и 1.2.221. Я постараюсь обновить их все до одной версии.

У меня всего 4 GU10, думаю это из первой выпущенной версии, работает на последней ота версии. Никогда не было проблем с ними с точки зрения доступности, просто мои сцены были испорчены после обновления прошивки.

У меня только что была одна из моих лампочек IKEA TRADFRI E14 W op / ch 400lm Версия 1.2.214 перестала отвечать. Эта лампа проделывала это много раз и на разных прошивках deconz. Щас использую deconz 26370500 и 2.05.82.

У меня всего 4 GU10, думаю это из первой выпущенной версии, работает на последней ота версии. Никогда не было проблем с ними с точки зрения доступности, просто мои сцены были испорчены после обновления прошивки.

Вы заметили улучшение стабильности этих лампочек GU10 после обновления до 2.3.050? Я сейчас на 0x26650700, и после обновления до 2.3.050 (из 17 лампочек) моя сеть стала более стабильной. Устройства не отключаются в одночасье, и мои кнопки / переключатели Aqara работают с первых попыток. Сейчас 4 дня, так рано говорить.

У меня всего 4 ГУ10, думаю это из первой выпущенной версии

На самом деле есть более дешевая версия IKEA GU10 (только W). Они никогда не обновлялись до версии 2.x и все еще работают на 1.2.214. И это были самые проблемные. Лично я просто сдаюсь, и теперь они работают нормально с центром IKEA.

Я думаю, что @antonbo приближается к решению проблемы.
IKEA использует одни и те же образы прошивки с разным оборудованием (блоки питания / светодиодные приводы) и имеют разные настройки в «пользовательских данных» для разного оборудования (и в них хранится идентификатор модели). Таким образом, одна прошивка может нормально работать на одном оборудовании (E14) и иметь проблемы на другом (GU10 / E27).
Одно отличие состоит в том, что IKEA GW работает в режиме ZLL (на Zigbee PRO) и не извлекает статус устройства, только прослушивает изменения статуса, которые устройства отправляют в сеть (как стандарт Zigbee PRO / ZB3) и смешивает их с HUE и другими поставщики, у которых координатор получает статус от устройств (не поведение ZB3), могут создать беспорядок в сети.
У меня есть самая старая IKEA RGBW и одна E27 Opal WW на старой обновленной (1.X) прошивке, которая работает нормально, и одна группа новых ZB3 GU10 WS, которая отлично работает. Моя основа - это около 10 вилок IKEA, которые обеспечивают стабильную сетевую связь, а также мои датчики Xioami работают нормально со всеми из них.
Я считаю, что это не одна общая проблема, больше HW и, возможно, FW в сочетании с сетевым макетом и избеганием некоторых проблемных устройств (например, OSRAM Outdoor Plug, который постоянно портит пакеты и теряет детей).

@manup Могу только сказать, что для моей системы новая прошивка сделала ее намного хуже, чем раньше. Будь то маршрутизация от источника или что это такое, у меня теперь каждый день застревает одна или две лампочки, и мне нужен цикл питания. Я даже видел, как одна из моих лампочек Philips Hue застряла, но для этого не требовалось перезапуска. Я не знаю, вызваны ли проблемы сейчас старой прошивкой, на которой я работаю, но опять же, я не могу обновить ее, так как она зависает. :(

Интересно, знает ли кто-нибудь, есть ли проблемы с более новым GU10 или нет? Я слышал, что на более новых устройствах используется zigbee 3.0, моя жена недовольна этими проблемами, поэтому я мог бы заменить их все, если это поможет?

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

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

@ JBS5 @djwlindenaar @lubbertkramer Есть ли отзывы о последних прошивках по сравнению с этой проблемой?

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

Однако необходимо добавить следующее

• перезапускайте контейнер с деконзированием каждую ночь
• переместил группировку из Home-Assistant в deconz / phoscon to handle.

До вышеуказанных изменений у меня было несколько менее отзывчивых лампочек, хотя это было лучше, но не сейчас.

@Mimiix , ну пока рано говорить.

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

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

Мои лампы E27 Ikea все вместе перестали сотрудничать.
Пока что для некоторых из них срабатывание силового цикла помогло. 3 еще не вернулись. Думаю, мне нужно добавить их заново ... :(

Прошивка: 26610700
Версия: 2.05.84 / 14.9.2020
(Raspbee2)

@umrath Кажется, это не связано с проблемой, рассматриваемой в этом выпуске. Пожалуйста, откройте отдельный вопрос :)

Симптом для меня очень похож: лампы перестают реагировать без видимой причины.

Как я только что сказал: это кажется несвязанным. пожалуйста, откройте отдельный вопрос. Мы всегда можем впоследствии определить, что это связано. Я твердо придерживаюсь этого мнения.

Да, я тоже думаю, что это связано. После нескольких месяцев отсутствия ошибки вчера у меня снова возникла проблема с двумя устройствами, (очень старым) IKEA E27 и более новой розеткой IKEA, оба с последней прошивкой.

Единственное, что я сделал в то время, - это перенес блайнд KADRILJ из зоны действия, а затем обратно, но это могло быть совершенно не связано.

Запуск сниффера показывает ту же проблему:

• Устройства по-прежнему периодически отправляют команды NWK Link Status;
• Но всегда с пустым списком кажется, что они игнорируют все окружающие маршрутизаторы;
• Они подтверждают входящие команды на уровне MAC;
• Они действительно реагируют на запросы маяка и отправляют маяк, но это единственный «ответ», который они дают.

Каким-то образом кажется, что стек Zigbee на устройствах IKEA частично выходит из строя для слоев NWK и APS и выше, или, возможно, входящие буферы NWK заполнены и никогда не освобождаются.

Я попытался вернуть устройства к жизни, отправив:

• ZDP Выйти с повторным присоединением;
• NWK Выйти с повторным присоединением (нижний уровень).

Оба подтверждены на уровне MAC, но в остальном игнорируются.

Затем я попытался подделать команды NWK Link Status координатора с действительной записью, которая указывает, что устройство имеет рабочую стоимость входящего и исходящего канала (3/3) в надежде, что устройство подберет координатора в своей таблице соседей. ... тоже не сработало.

К сожалению, не существует способа обойти ситуацию после того, как это произошло, и устройство IKEA переходит в это в основном мертвое состояние. Просматривая некоторые форумы, можно увидеть поведение со всеми видами шлюзов и лежащих в основе стека Zigbee. Что интересно, поскольку, например, мост Hue не выполняет каких-либо причудливых вещей Zigbee, таких как запросы соседних таблиц или привязок и отчеты, и все же ошибка возникает.

Что нужно сделать IKEA, так это по крайней мере реализовать Watchdog, который проверяет, что компоненты NWK и APS все еще работают, и позволяет устройству запускать Watchdog для перезагрузки. Это не исправит ошибку, но, по крайней мере, сохранит работоспособность устройства, когда это произойдет.

@manup У вас старый E27 one LL с диагностическим кластером?
Возможно, это может быть интересно, если что-то происходит с прилавками с промежутком в несколько недель.
Это не может решить проблему, но дает намек на то, что прошивка не работает.
Хороших наблюдений и выводов манде !!

Я думаю, что у Silabs немного больше поисков ошибок для одного из крупнейших клиентов ;-)

Привет, это сбивает меня с толку, поскольку с тех пор, как несколько месяцев назад я перешел на Z2M с помощью ZZH, я не видел этой проблемы. Возможно, в уравнении есть другая переменная. Было бы здорово, если бы кто-то другой, сделавший то же самое, подтвердил.

@mvjt Используете ли вы Rasp / CornBee с Z2M или каким-либо другим координатором?
Различные стеки zigbee работают по-разному и могут иметь / создавать разные проблемы.

Изменить: извините, я вижу ZZH = новый координатор TI.
deCONZ NCP = Atmel / Микрочип
Устройства IKEA / NCP = Sirlabs EFR32 / EZSP

Я могу подтвердить, что HA / ZHA / Zigpy / Bellows отлично работает с модулем Billy EZSP = IKEA ICC-1-A в качестве координатора с маршрутизаторами IKEA и конечными устройствами от IKEA и Xiaomi и без маршрутизаторов OSRAM или Xiaomi.

@MattWestb Да, у E27 есть диагностический кластер, но я еще не

По крайней мере, в прошлом проблема, которую я вижу, также возникала с TI CC253X, и в конце проблемы упоминается CC26X2R1, но это было состояние в январе, и тем временем, возможно, он улучшился. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

Это может быть не ошибка Silabs в целом, а какие-то нестандартные вещи на уровне приложения. Я думаю, что последние устройства Hue также используют Silabs. От моста Hue есть как минимум версии TI и Microchip.

Это действительно неприятная вещь, во многих случаях ошибка может не произойти вовсе или через несколько месяцев, в других сетях это происходит с гораздо меньшими интервалами. Я думаю, также важно то, как работают сети, и то, что освещение, которое регулярно отключается, менее подвержено влиянию.

@manup У меня есть один сценарий, который очень хорошо подходит для вашей "проблемы с IKEA".
Если вы настроили свою сеть, она начинается с одного сетевого ключа, а счетчик фреймов безопасности начинает тикать. Если вы не реформируете сеть или не меняете сетевой ключ в течение очень долгого времени, счетчик останавливается, потому что он достиг максимального значения 0xFFFFFFFF (32 бита) и не может увеличиваться.
Затем устройство выбрасывает все данные, которые поступают на уровень zigbee, потому что счетчик кадров неправильный, но нижний сетевой уровень все еще работает нормально.
Проблема: я не знаю ни одного метода получения статуса счетчика фреймов безопасности устройств. Я думаю, что это невозможно увидеть в Wireshark (мышление = незнание).

На это указывает то, что ранние сопряженные устройства, которые не были сброшены, останавливаются быстрее.
Новые подключенные / сброшенные устройства работают дольше, прежде чем счетчик остановится.
Привязка команд к одному устройству также заставляет его останавливаться быстрее, чем одно устройство, которое не так "коммуникативно".

Рекомендуется регулярно обновлять сетевой ключ в сети ZB3 для обеспечения безопасности, а затем также сбрасывать счетчик фреймов безопасности, чтобы он не зависал.
Немного информации AN1233: Zigbee Security 2.1.6 Счетчик кадров сетевой безопасности.

Это один безумный мозговой штурм, но, возможно, проблема возникает после долгой работы сети.

Один из тестов - это попытка перевернуть сетевой ключ, и «живое» устройство довольно долго работает нормально, но остановившееся устройство должно быть сброшено / повторно подключено для запуска счетчика кадров безопасности с нуля.

Хм, почти уверен, что установка сетевого ключа shr отбросит все сяоми.

Неправильная защита на 200%, что они не обновляются и не выходят из сети (старые не ZB3) !!!

@Adminiuga Вы пробовали накрутить сетевой ключ на EZSP?
Результат оказался интересным !!!

Не пробовал использовать сетевой ключ. На самом деле было бы интересно узнать, сколько реализаций накатывают ключ на регулярной основе.
Но я могу подтвердить, что изменение pan-id имеет очень высокие шансы на падение сяоми, примерно 4 из 5 шансов.

Я видел несколько тестов на проникновение в систему безопасности, которые вынюхивали pan-ID с улицы и возвращались несколько раз с промежутком в несколько месяцев, и ни один крупный поставщик света (не названный здесь) не переставлял сетевой ключ через год (Mariahilferstraße в Вене) ) так что вы, скорее всего, имеете право (аген).

Если и только если это счетчик кадров безопасности, который делает проблему, то он делает то же самое для всех реальных устройств zigbee 3, тогда он определен в «Спецификации поведения базового устройства» и рекомендован в старом LL, но, скорее всего, не без устройства zigbee PRO (старые HA и LL) или несертифицированные устройства (без имени .... mi).
Тогда лучше «вручную» перекатывать ключи сети или два раза в год, и не нужно больше раз сносить дом для сброса встроенных устройств во рту, тогда они останавливаются и выполняют сброс / повторное подключение старых датчиков Xiaomi, которые обычно не выполняются. интегрированы в структуру дома и их легче переустановить (обычно открытое соединение и нажатие кнопки, и они соединяются).
Мэнни «китайский Zigbee 3» выбрасывает «старый» счетчик фреймов безопасности после сброса питания и использует один новый из первого полученного пакета от своих соседей (видел, что затем тестировал проблемы с tasmotas zigbee 3, а затем счетчик NCP ​​был ошибочно сброшен при перезапуске) так что их только ремонт, и они вернулись.

Мы также провели несколько тестов в прошлом году, ни один шлюз не менял сетевой ключ. Как описано в спецификации, это единственный способ сбросить счетчик фреймов безопасности NWK при увеличении номера сетевого ключа. Я также разделяю опасения, что это поддерживается всеми устройствами, обычно функции, которые почти никогда не используются, плохо протестированы. Я искренне надеюсь, что я ошибаюсь, и это работает для большинства устройств.

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

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

@djwlindenaar Мне интересно, есть ли у вас какие-либо новые результаты, поскольку вы можете технически проанализировать свои результаты в дополнение к простому сообщению о том, что лампа снова отключилась, как и я. Мы очень ценим ваши открытия и идеи. :)

Что ж, спасибо за оценку ... Если честно, меня не совсем устраивает текущая стабильность сети. Он действительно вышел из строя после обновления до последней версии прошивки deconz. Некоторые индикаторы отключились в последние недели, чего не происходило долгое время до обновления. Я работал с патчами, которые позволяют регулярно сообщать атрибуты для светильников IKEA, которые я еще не применил в текущей ситуации.

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

Что ж, спасибо за оценку ... Если честно, меня не совсем устраивает текущая стабильность сети. Он действительно вышел из строя после обновления до последней версии прошивки deconz.

У меня такой же негативный опыт. Теперь большинство моих устройств Xiaomi (в основном настенные переключатели Aqara) часто отключаются в течение дня и возвращаются к работе через несколько минут (я полагаю, это связано с тем, что устройства Xiaomi перезагружаются, если они не получают ответа на запрос атрибуты временного кластера от координатора).

Новый выпуск v2.5.88 может улучшить ситуацию. Здесь конфигурация отчетов IKEA была сглажена, чтобы переходы между состояниями не забрасывали сеть отчетами. До перехода между состояниями каждый атрибут сообщался в очень быстром темпе.

Новый выпуск v2.5.88 может улучшить ситуацию. Здесь конфигурация отчетов IKEA была сглажена, чтобы переходы между состояниями не забрасывали сеть отчетами. До перехода между состояниями каждый атрибут сообщался в очень быстром темпе.

Звучит многообещающе :) Также, я думаю, включение / выключение - это переход между состояниями? Или в основном меняется яркость или цветовой режим?
Требуется / рекомендуется какая-либо минимальная версия прошивки для этого изменения?

Только яркость и все атрибуты, специфичные для цвета, такие как colorX, colorY и цветовая температура.
Для прошивки я всегда рекомендую последнюю версию 0x26660700 (в случае ConBee II и RaspBee II).

Новый выпуск v2.5.88 может улучшить ситуацию. Здесь конфигурация отчетов IKEA была сглажена, чтобы переходы между состояниями не забрасывали сеть отчетами. До перехода между состояниями каждый атрибут сообщался в очень быстром темпе.

@manup , я думаю, что это обновление решило также проблемы со стабильностью работы устройств Aqara. благодаря

Новый выпуск v2.5.88 может улучшить ситуацию. Здесь конфигурация отчетов IKEA была сглажена, чтобы переходы между состояниями не забрасывали сеть отчетами. До перехода между состояниями каждый атрибут сообщался в очень быстром темпе.

@manup , я думаю, что это обновление решило также проблемы со стабильностью работы устройств Aqara. благодаря

К сожалению проблема (№3605) все еще существует, я слишком рано поспешил с выводами