WC & HE device status out of step?

#1

I have a piston which turns on a cloakroom light when motion is detected. I won’t post as it’s rather complex, handling all such lights, and works well.

That said, today it seemed to stop working for the one light. It last worked at 11:30am. I performed the usual checks - the battery in the motion sensor - ok, then suspected the bulb had gone - but it looked ok. So I asked alexa to turn on - it worked, turning on. I then used alexa to turn it off. After that the piston operated the light again as expected.

Looking at the logs for the light (a fibaro dimmer 2) I noticed it was turned off by the piston at 11:30, and then reported 0w power, as expected. There was nothing else until this evening when I asked alexa to turn it on.

So, my WC piston was running, but the code thought the light was already on, so didnt do anything.
Unfortunately I didnt check the device status to see if HE thought the device was on.

I’m wondering if the HE log entry for “off” was created, the device turned off, but then either

  • HE didnt update the device status or
  • The device status was not synchronised to WC (if that happens)

I’m also wondering whether there’s any merit in writing a piston to periodically call a refresh on all devices to ensure their current status is reported?

#2

If you have mesh/device issues and reports are not accurate life can become ‘fun or exciting’ (not).

You can with ‘minimal’ logging enabled have logs for what the piston did.

Sometimes there are also issues that device reporting is not accurate, and webCoRE’s command optimization may not help. See:

Also note that some older zwave devices, may need zwave poller enabled (generally a good idea if you have these to think about replacing)

#3

I think you’re right about it being a network issue. Sometimes it can take around 20 secs to turn on, however most of the time it’s fine.

I dont think disabling command optimisation would help. The piston has already checked to see if the device is on and I suspect this is incorrect. This particular issue has only happened once as far as I know.

I’m curious how HE handles devices.
My HE log shows the device being turned off (is this logged when the command is sent or when/if the device responds that it is off?). The HE log then shows a report of 0watt power (and the device is off). However, the WC piston still sw the device as on (I’m assuming as I didnt capture any logs at this point)
After an on/off via alexa the piston then worked as usual. (goes alexa implement some and optimisation? - I suspect not, but don’t know)

#4

HE relies on the devices report correctly in general. If you have older devices you can use zwave poller, but that in general is not great for your mesh.

You do want to ensure your zwave mesh is healthy/strong, and no ‘ghosts’. If you have ghosts, all bets are off.

You need to monitor if your hub is down / rebooted, that device states could have changed while the hub was down, and that won’t be corrected until the device checks in again, or you do a refresh. ie there is not automatic refresh on a reboot.

You can handle this if it is common with the systemStart event, and your own refresh…just remember after a reboot the hub is already pretty busy for 3-4 mins…

#5

Maybe a hub 8 would help