I have an Ikea tradfri zigbee outlet that I am controlling using a webCore piston.
On this piston, I have disabled automatic piston state and I am using the following expression to reflect the last action the piston took.
"outlet was turned " [outlet : switch] " by piston at " time()
The resulting piston state should be "outlet was turned off by piston at 12:00pm" when piston turned the outlet off, and "on" when piston turns the outlet on.
But even though the outlet successfully toggles, I was seeing the piston state report the opposite. The set piston state expression would use the state the outlet was in before the command to toggle the outlet was sent.
I even added a 1 second wait between the outlet being toggled and the piston state being set. But I was still seeing the issue.
I never came across a similar issue before. So I am wondering if the tradfri outlet is generally slow to update the switch state?
Does wait statement not work if it is nested inside a 'on event' statement which is executed asynchronously?
Is it slow to update or does it just not at all? The latter is a problem I've seen a lot. The fix is to run the "Configure" command on the device. This should run during pairing (if the right driver was selected), but this device in particular seems to have problems with that.
If this is the problem, it will likely fix the webCoRE issue as well; otherwise, there could be something else going on.
Thanks for the quick response.
I went ahead and hit Configure. Should I see anything on the interface change after hitting Configure button?
I will continue to monitor the piston and see if the problem reoccurs.
No, it just sends Zigbee configuration commands to the device (and should help if that was the problem with it not reporting state back on its own).
I generally find they very fast, responsive outlets... that is, until they fail. I've had 3 (of 8) just stop working, and no longer respond to on/off commands at all. But you can see this problem just on the device page (and you no longer hear the relay click).
Would also be good to see the piston (green snapshot) and the logs for the piston at 'full'
Here is the snapshot of the piston. I was mainly focusing on the bottom part for turning on a specific device, but feel free to suggest other ways I can make the code more efficient too.
Before I tried the configure button @bertabcd1234 recommended, I entered a line to refresh the device before setting piston state.
Now you'll never know if it worked. At least not from the piston; the device Details page would tell you the truth. (A refresh would work around the problem but shouldn't be necessary with the right driver send proper configuration, all a guess as to the problem, but it's a very common one with this device.n And if there are still problems, this was probably not the issue in the first place.)
I had a Tradfri Outlet acting this way. I simply repaired it and then it worked as intended.
If it happens again would be good to see the logs.
Actually, I noticed that when I send a on or off command from Hubitat's device page for this outlet I don't have to hit refresh like I did before to see the current state change. So I am sure your suggestion worked and I could remove that refresh line from the piston. Thanks again for the help.