Those are the same messages I get in my log but since I am still at work I have not been able to visually confirm that the state of the plug changes based on the command I send.
I must admit I have tested these plugs without any load or devices connected to them. Am I to understand that they behave differently if there are nothing connected to them?
Reason for asking is that I have now tested one them with a coffee maker attached and it behaves as expected.
I don’t think the devices act differently with or without load… That would be weird…? So is it working now with the original code?
I still don’t really understand what’s going wrong, but I’ve removed the version array from zwave.parse() and get the same results as before. I suspect the code should start working for you too if you removed the array like this:
def cmd = zwave.parse(description)
So to my reasoning around this:
The zwave.parse(…) method takes an optional map. This map can be used to change the version of the object parsed (to one lower than the one recived from the device). So with the array that was there 0x32 which is the MeterReport command would get version 1.
My hub doesn’t seem to respect this…?! Same seems to be for @Fredde. The map that was in the code should have made sure the MeterReport would come in as version 1…
My reasoning might be completely flawed, but hopefully someone can clarify. Maybe @JDRoberts can clear up our confusion?
I have now tested with your code and the following happens:
If the plug is connected to a device which continously draws current it will respond to any commands at all times
If the plug has NO device attached is does not respond (same behaviour as reported earlier)
If the plug is connected to a device which draws current and this device is powered off the plug will revert to previously reported behavior.
My 2 cent on this: It seems like if the plug stops communicating with the hub (when a device draws current the plug continously reports this usage to the hub - hench is online all the time) only the “reset kwh” is able to “wake” it again.
This is a first generation device, they probably never tested it without having a load connected. It happens.
I would definitely write Fibaro and ask them what’s going on, just so they know about it, although they’ll probably tell you that it works just fine with their controller. Which may or may not be true, doesn’t matter, you just want to give them a poke about the issue.
Glad you were able to figure out the fail condition, though, that was a strange one!
I am abit reluctant to accept this as a final root cause because it will more or less render the device useless. This could lead to situations where you belive you have turned off a heater but infact the heater was off (because of the interal thermostat) when you sent the command hench the plug does not respond because there’s no current.
I will drop them an email about the issue but hopefully there are more people here who could test the various situations to confirm.
Actually i have the same issue if there is nothinh connected to the plug. It will respond to one on/off and then nothing more but if i then wait like for an hour, it works with one more on/off. But as soon i attach something to the plug, it works again
I’ve emailed Fibaro asking about this behaviour and will report back when they respond. (Might take a few days because I was notified that they were swamped at the moment)
Confirmed to be similar here. I use mine mainly to do metering so I don’t see it as often.
Did a bunch of testing on the handler though, and not getting any different versions of the commands in weird states. I’ve committed the changes to Github if anyone wants to update.