I’m not sure what you are thinking looks odd? To me I think it’s ok. I guess you might be looking at the “Not the right scale” message (??) but this is ok - I should really remove this debug message. Since there are 2 meter channels, the system is checking both configurations, and one is updating the channel, and the next one it shows is not the right scale (correctly).
This is ok as well. This debug message is related to transaction management. It basically means that it received a message from the controller (node 255) but the last message sent was to node 32 and these two messages are not consistent, so it doesn’t complete a transaction. This happens normally when devices send unsolicited messages (such as meter updates, door notifications etc).
From my reading of the spec, this is non-compliant behaviour (which is surprising for Fibaro) but I’m trying to double check this. It might be worth resetting this device to see if that changes anything. If this turns out to be a bug in the device I’ll look at adding something to the binding to work around this.
Ok - that’s good to know, thanks. I’ve enquired about this with the zwave people, so let’s see what they have to say as in my reading of their spec, the device is non-compliant even though they have checked it, and it’s approved ;).
I have done little more testing and added 2 more new FGD212 Things (firmware 3.3) on OH2. One installed without errors on habmin2 and another give same STATIC VALUES ERROR than FGD212 firmware 3.2. Very strange.
I have used them with OH2 MIOS binding from Vera and they work very well. Now I have tested with ZME_UZB1 zwave controller. Maybe next I will try hard reset to problem Things.
[ERROR] [alization.ZwaveNodeInitStageAdvanced] - NODE 7: Node advancer: Retries exceeded at STATIC_VALUES
[ERROR] …Timeout while sending message. Requeueing…
[ERROR] Got an error while sending data. Resending message…
The reason it worked in 1.8 is because 1.8 doesn’t support this command class. I hope to have an update at some stage that will be more tolerant to devices not responding like this (unfortunately, it’s not that uncommon - I’m not sure what that says about the ZWave certification program!).
The other option is we can remove this command class - ie add something to the database that tells the binding not to use it - this is the easiest/quickest at the moment, and given this command class is just an ‘information’ class, it won’t change anything.