Closed walthowd closed 6 years ago
Bellows devices attached.
With HA 0.63 you pulled also bellows/zigbee 0.50+ You can try if the build-in zha+bellows works for you and switch away from my spin-off or downgrade bellows to 0.40. But mixing both not works
Sorry, I misread your ticket. What comes every 30 sec? And why not just disable debugging? This comes from a device asking for an OTA upgrade. 2018-02-12 19:23:32 DEBUG (MainThread) [bellows.zigbee.zcl] [0x2be9:1:0x0019] ZCL request 0x0101: [0, 4448, 3, 3, 0] 2018-02-12 19:23:32 DEBUG (MainThread) [bellows.zigbee.zcl] [0x2be9:1:0x0019] No handler for cluster command 1 Are you sure this is new and the device is properly paired? If yes to both, can you rejoin it. Also what kind of device is it?
Many thanks
Just reading you ticket again. Sorry. But is the bulb powered on? Are you able to switch the light on and off for this bulb? I need to catch the error and send something like "state unknow" to HA for bulbs that not answer anymore. Thus, it's easier to see, which ones loose the network
Do you see the IEEE ID of the device in the log? I'm missing it, but can start turning devices off to find what is misbehaving.
Looks like the "ZCL request 0x0101: [0, 4448, 3, 3, 0]" is coming from two SmartThings multi sensors (24:fd:5b:00:01:04:01:b2 & 24:fd:5b:00:01:04:01:4c) and "ZCL request 0x0101: [0, 4174, 34, 537415696, 0]" is coming from a Iris (Centralite) Smart Plug 3210-L (00:0d:6f:00:0b:4f:95:72)
The SmartThing sensors are not showing as entities in HA. Also chasing an issue where lights are turned on with a random brightness level -- not sure how to submit any useful debugging information for that yet.
Please check what logs show up 30 sec before. Your log starts to late to see what command was send 30 sec before. Also helpful: click through your list of bulbs and see which one has null RSS/LQI values. This one was never online after your restart. the lqi/rssi values are updated with any incoming packet
The OTA updates are a pain in the back but not realy do any harm. But are also usless. Maybe I should filter the cluster.
What kind of bulbs make the problem. All or only a specific brand? your zigbee.db would be helpful to see what clusters your devices support and what device_id they use.
Attached is the full log file. The "updating zha_new light took longer than the scheduled update interval" begins at 10:35:39 and then repeats every 30 seconds.
Also attached is the full zigbee.db (binary sqlite3 file, just renamed to upload)
All bulbs were reporting non null RSSI/LQI values when these errors were occurring. For what it's worth, my smartthings multisensors were not showing as binary_sensors and my Centralight switch is not showing as a valid switch anymore. (EDIT: Though after a HA restart, the Centralight switch will sometimes appear)
It looks for me your Zigbee device has not enough buffer sapce. HA triggers at 10:35:09 an update for all of your zigbee bulbs the same time. Did you used my code also with HA versions before? Just to understand if it started with 63.1 and was ok before?
In general it only affects the cababilty to have a current state of your light. And switching will not work persistent during such an 'update cycle'
During HA start I added 1 sec wait between each device init to not run in this problem. But this comes from the HA scheduler.
One option is to reduce the the source route table (32) on the controller, this frees some memory. You can change in
<HA-Dir>/lib/python3.5/site-packages/bellows/zigbee/application.py
this line
yield from self._cfg(c.CONFIG_SOURCE_ROUTE_TABLE_SIZE, 32 )
to 16
and if it not helps
yield from self._cfg(c.CONFIG_MAX_END_DEVICE_CHILDREN, 32 )
to 28
no update here, so I close the issue
HomeAssistant v0.63.1, latest master-0.61.plus zha_new, latest master of yoda-x/bellows release.
Every thirty seconds I receive the "Updating zha_new light took longer than the scheduled update interval 0:00:30" and this event is always preceded by the below log entries. This happens at all times, even when I'm not sending any on/off commands to any devices.