Trying to include an Aeon ZW099 Smart Dimmer 6 with the latest binding 2.5.0.201906272212.
I’ve included these in the past successfully and I don’t recall running into any problems.
It appears to be getting stuck here. I don’t understand how to fix this. There’s no endpoint2 in the DB, and I don’t understand the EP-1->EP-2 in the requests.
@chris @sihui Can you provide some insight to what’s happening here.
Full log is here.
No - but there is in the device. However it’s not reporting all the classes the binding is then requesting, so I need to find out why. There’s a bit that can be set to say that all endpoints are the same, so it might be that.
Can you also provide the XML if it’s generating one?
Yep - so that’s the issue. The device reports that “all endpoints are identical”.
It’s the 40 in the above data -:
The binding interprets this as all command classes are the same which seems to be the correct interpretation -:
According to the classes reported, they are not the same -:
So, I think that explains what is happening and why - the question then is what to do about it. It will take a binding / database modification to work around this as it looks to me like the device is incorrectly reporting the identical status?
Well, that certainly explains what’s happening.
A quick look at the manual confirms the two endpoints.
I think the only issue is that the Identical bit is set - but this is completely screwing up the initialisation of the device and in my reading of the spec, is incorrect. I’m a bit loath to just remove this from the binding and the only option I can think of is to add an option to the database to override the identical bit.
Thanks for getting to the root cause.
I agree. Removing it from the binding will resolve the issue for this device, but might break some other devices. An override for the identical bit seems to be a reasonable solution.
I’m going to try the include again today just to make sure the issue is repeatable and not just some “one-off” case where the bit got flipped somehow. I don’t have high hopes, but it’s worth a try.
@chris As I expected, it’s very repeatable.
Not that this would replace the database indicator, but why does it try each command class 9 times before giving up and moving on to the next command class? Especially when you consider that It takes about 10 minutes to get past each failed command class. Wouldn’t 2-3 failures be sufficient to determine that the command class is not supported? In fact, giving up after 3 failures would cost only about 15 seconds per command class.
2019-07-07 13:42:50.798 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 0)
2019-07-07 13:42:56.544 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 1)
2019-07-07 13:43:03.129 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 2)
2019-07-07 13:43:12.030 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 3)
2019-07-07 13:43:24.971 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 4)
2019-07-07 13:43:45.878 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 5)
2019-07-07 13:44:22.731 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 6)
2019-07-07 13:45:31.668 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 7)
2019-07-07 13:47:44.560 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 8)
2019-07-07 13:52:06.009 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 4: No data from device, but it was ACK'd. Possibly not supported? (Try 9)
Because in general, giving up will leave a device unusable. Yes, in this case, the device is behaving strangely, and giving up won’t break it any more than it already is, but for devices that don’t have this sort of problem, it seems better to try and get the information required so that the device has a chance of working.
I forget exactly how the backoff works in the initialisation, but the bottom line is that this stuff is needed, so we try hard to get it.
I get all that. I was just reacting to how long it takes before deciding to give up.
In any event, it finished initializing after a little over an hour, and appears to be functional.
Sure - and to be honest this detection of “possibly not supported” was intended to be used to abort earlier, but s with many of these sort of features, they are nearly never used, so don’t get implemented. In the (I think) 3 years since I implemented the OH2 binding (where this was added) this is the first time it’s come up.
If you want to open a feature request I’ll take a look at reducing the number of retries when it’s in this state.
Thanks. I opened an issue here.