It does appear as though this frame is corrupt - there is no data in it. The 60 0D part says that this is a multi_instance message, but there’s then no encapsulated command class. I will update this debug message to add a little more information - maybe I can interpret the error differently which might allow the error to be removed, but the result will still be the same - this message has no data for some reason…
I’ve updated the binding to change this log message - please try tomorrow with the latest snapshot and provide an updated log… Also, if you can indicate what happens when you get this error (eg is it when you get motion) that would be good, and possibly also posting the XML file for this node would be interesting…
Thanks - it doesn’t show anything unfortunately… It basically looks ok except the frame has no information…
As a matter of interest, can you post the few lines before this log - I’d like to see the received data of the CRC_16 message…
Also, the XML didn’t come through - can you just paste it into the message - just encapsulate it within the <pre> tag to ensure it gets formatted correctly…
You have exactly the same device as I have - same version it seems. I don’t see the MULTI_INSTANCE command class in my XML files, but you have it in yours. This might be simply to do with the fact that you’re receiving commands from this class so the binding adds it to the class list - I suspect it’s not notified during initialisation as the version is 0 (which shouldn’t be possible during initialisation).
I have a suspicion that this might be caused by the MULTI_CHANNEL_ASSOCIATION - have you set this device up using different software, or only through OpenHAB? Currently the MULTI_CHANNEL_ASSOCIATION class is not supported in OH1, but I will add it for OH2. (I could also be wrong about this, but it’s my best guess at the moment ).
It might be interesting to completely reset the device to see if this changes.
I just wondered if you had configured this through other software (as you have), it might have used a command class that wasn’t supported by OH… I’m not sure of course - it’s a guess…
Even if this is the case, it still seems strange as this command doesn’t look correct, but maybe this is just my understanding of how it is used…
I would try to reset the device, and add it back in to the network.
Hi Chris!! There is no more problems in log. I reinclude FGMS-001 with habmin.
By the way what do you think about this messages? this messages are not WARNING. It’s normal message as i understand. m?
2015-08-21 23:01:44.501 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass:221 ]- NODE 4: Unsupported command class SWITCH_ALL
2015-08-21 23:01:44.690 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass:221 ]- NODE 2: Unsupported command class SWITCH_ALL
Great - I suspect the issue is the MULTI_CHANNEL_ASSOCIATION class which I will implement in OH2 (it’s mostly implemented, but for it to be used, it needs some extra functionality to be included in the ESH core)…
Yes - you’re probably right. These messages simply say that a command class isn’t (yet!) supported by the binding, but in most (not all) cases, this isn’t an issue as many of the classes aren’t really important…
).