I have a million of these types of errors in my log since adding ZHA via the Nortek stick. Have approximately 10 devices paired right now including open/close sensors, 1 motion sensor, and 1 plug. Do they meant anything bad? I used a SQL viewer to look at the database but those ID’s dont show up (converted to decimal). Any thoughts?
Also having the same issue after adding (3) Sengled Element Classic Model E11-G13 bulbs.
Using the Nortek Linear HUSBZB-1 hub.
The bulbs operate fine and function properly in HA, but throwing errors every 5 minutes.
2017-06-26 04:13:10 WARNING (MainThread) [bellows.zigbee.application] Unexpected message send notification
2017-06-26 04:13:12 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:13:12 WARNING (MainThread) [bellows.zigbee.endpoint] [0x60a1:1] Message on unknown cluster 0x0019
2017-06-26 04:13:15 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:13:15 WARNING (MainThread) [bellows.zigbee.endpoint] [0x60a1:1] Message on unknown cluster 0x0019
2017-06-26 04:13:18 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:13:18 WARNING (MainThread) [bellows.zigbee.endpoint] [0x60a1:1] Message on unknown cluster 0x0019
2017-06-26 04:13:20 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:13:20 WARNING (MainThread) [bellows.zigbee.endpoint] [0x60a1:1] Message on unknown cluster 0x0019
2017-06-26 04:13:23 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:13:23 WARNING (MainThread) [bellows.zigbee.endpoint] [0x60a1:1] Message on unknown cluster 0x0019
2017-06-26 04:15:33 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.my_thermostat is taking over 10 seconds
2017-06-26 04:17:31 WARNING (MainThread) [bellows.zigbee.application] Unexpected message send notification
2017-06-26 04:17:33 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:17:33 WARNING (MainThread) [bellows.zigbee.endpoint] [0x33a7:1] Message on unknown cluster 0x0019
2017-06-26 04:17:36 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:17:36 WARNING (MainThread) [bellows.zigbee.endpoint] [0x33a7:1] Message on unknown cluster 0x0019
2017-06-26 04:17:39 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:17:39 WARNING (MainThread) [bellows.zigbee.endpoint] [0x33a7:1] Message on unknown cluster 0x0019
2017-06-26 04:17:42 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:17:42 WARNING (MainThread) [bellows.zigbee.endpoint] [0x33a7:1] Message on unknown cluster 0x0019
2017-06-26 04:17:45 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:17:45 WARNING (MainThread) [bellows.zigbee.endpoint] [0x33a7:1] Message on unknown cluster 0x0019
2017-06-26 04:18:08 WARNING (MainThread) [bellows.zigbee.application] Unexpected message send notification
2017-06-26 04:18:09 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:18:09 WARNING (MainThread) [bellows.zigbee.endpoint] [0x9d3d:1] Message on unknown cluster 0x0019
2017-06-26 04:18:12 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:18:12 WARNING (MainThread) [bellows.zigbee.endpoint] [0x9d3d:1] Message on unknown cluster 0x0019
2017-06-26 04:18:15 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:18:15 WARNING (MainThread) [bellows.zigbee.endpoint] [0x9d3d:1] Message on unknown cluster 0x0019
2017-06-26 04:18:18 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:18:18 WARNING (MainThread) [bellows.zigbee.endpoint] [0x9d3d:1] Message on unknown cluster 0x0019
2017-06-26 04:18:21 WARNING (MainThread) [bellows.zigbee.zcl] Data remains after deserializing ZCL frame
2017-06-26 04:18:21 WARNING (MainThread) [bellows.zigbee.endpoint] [0x9d3d:1] Message on unknown cluster 0x0019
They’re harmless. The devices are trying to check for a firmware update (command cluster 0x19) and bellows currently doesn’t know how to respond. They keep trying periodically, which is why the messages show up regularly. Unless they actually need a firmware update due to some bug, this doesn’t affect anything. (Not a bad idea to keep your old Iris/ST/whatever hub kicking around for firmware updates for that rare occasion.)
@roothorick right, I get that. But something is still not right if the bulbs aren’t reporting their current state, right? I have Sengled element bulbs and HA doesn’t change the state if I turn them off at the switch, or if HA is restarted.
Your issues are unrelated to those warning messages then.
I’ve had !!FUN!! with my Cree bulbs as well. I think zha just needs a bit more work.
E: Wait, you’re turning them off “at the switch”? That’s not how smart bulbs work. They need to be powered (i.e. switch is on) at all times to function properly. (For that matter, dimmers can damage the bulb and even result in magic smoke!) You need a remote of some kind if you want to manually control them outside the app. (That’s something I’ve been investigating myself; Aeotec’s WallMote looks promising but doesn’t work with Hass yet.)
LOL, I just realized I’m an idiot. You would be correct! If the power is off there is no way for it to report it’s state… I’ve got Caseta switches for many of my lights, and these were my first ‘smart’ bulbs. Guess I was still thinking in terms of how the switches operate…
So yeah, I guess the only real issue I have is the constant error log…
Edit - wait, I did think of an instance I expected a state to update.
If I turn the lamp off with HA, and then it is manually turned back on at the switch, HA still doesn’t update the state.
If that’s not working, it’s most likely a bad interaction between bellows and the quirks of that particular bulb. It’s likely the bulb expects the coordinator to poll state changes upon noticing it’s back on the network. If only zha had a “poll” service similar to zwave.refresh_node.
Exactly. Yeah I was wondering if there was a ‘poll state’ or something I could configure in… Maybe I just need better bulbs instead of the cheap Sengleds!