How to manually force-refresh a sensor?

I have about 10 of Iris iL06-1 contact sensors that have been behaving well over the last month. Today one of the sensors (87% battery) just stopped reporting anything around 10AM. I tried hitting "Refresh" and "Configure" on the sensor's Device page to no luck. No updates on Activity, Temperature, or Contact State. I ended up having to remove the battery and re-inserting and it's responding again.

Does this happen often with folks?

If so, are there suggestions on how to force-refresh?

I saw the Device Watchdog app. I take it that is one way of automating this? Or are there other alternate approaches methods to at least alert when a sensor has been inactive?

Generally speaking, you can’t force a battery operated sensor to refresh without physically interacting with it in some way. They are “sleepy” devices by design, as a battery saving measure, so they’re not always listening for a “refresh” command from the hub.

Apps like device watchdog are helpful for notifying you if a device hasn’t had some type of activity in a defined period of time, which could suggest it ran out of batteries or is offline for some other reason.

Most battery-powered Zigbee devices, in my experience, actually do listen for commands like "Refresh," but most battery-powered Z-Wave devices won't unless they are listed as FLiRS (beaming-capable), which is usually only things like door locks or motors (e.g., window coverings). But to conserve battery life, I wouldn't do this too often anyway.

I don't have any Iris v3 contact sensors, but my Iris v3 motion sensors are no exception to the above (there are indeed exceptions; the Eria Zigbee Remote, for example, and of course Green Power devices, but Hubitat doesn't support those anyway). Since yours wasn't working, my guess is that it's likely the result of another problem. Sometimes this would be a dead battery, but the fact that yours is still working after just removing it and reinserting it means that might not be the case (and 87% obviously doesn't sound like a bad measurement and shouldn't be, but battery reporting is notoriously unreliable on many devices, so I'd be hesitant to trust this--but that's still high enough I probably would unless you just had a dud battery that died before it could even send a new report).

That being said, like you and marktheknife, I do like to use a "Device Watchdog"-style app to monitor this. (I wrote my own, but that or a couple other community options should work fine.) I don't find battery reporting alone to be reliable; the tradeoff is that you need to have a feel for how often your devices normally check in. For devices that report temperature like the Iris v3 (and v2) devices, I usually get reports at least once every few hours, though you'll have to check your "Last Activity At" and event history for you particular devices to get a better feel.

1 Like

Yes sorry I should have clarified. Battery powered devices may listen for refresh commands, but I believe they do so on their own timeframe, and won’t necessarily refresh in real-time (to save battery life).

Zigbee sensors can certainly respond to refresh within a short time interval (usually just a few seconds; there is a max interval defined by the spec and it is in seconds, so it is not really indeterminate. Z-Wave is another story.). But the attributes that they update during the refresh are up to the device driver.

This has bothered me lately, what with the need to periodically reboot my hub, as sensor changes that happen during the hub's downtime won't cause automations to run when the hub is operational again; and the hub is not capable of seeing their current state if it has changed during the time the hub was offline. And since many (all?) of HE's built-in Zigbee drivers only seem to refresh temperature (but not wet/dry or open/closed), you can't recover (in an automated way) the current state of the things that really matter if it has changed while your hub has been rebooting itself.

So, if your leak detector says 'WET' while your hub is rebooting, too bad; when HE gets going again, none of your automations that trigger on a leak sensor reporting moisture will run... and there's nothing you can do about it, automation-wise. Running a refresh on these as a post-reboot cleanup won't do anything. Same thing for contact sensors; I got bit by this several times with my garage doors and mailbox so I resorted to using a ported (modified) version of the SmartThings driver for my Iris contact sensors... they do report the current contact state when refreshed. So I have my hub run a refresh on them and check their state when the system start event happens.

Unfortunately, they don't report temperature properly when the usual simple porting changes are made to adapt them to HE. So (until I can figure out how to modify the driver to report temp correctly) all my important contact sensors aren't useful for temperature... but at least I can refresh them and get the current state if HE has missed it somehow.

Is there any way to force-update a contact sensor's state? My use case is a door contact (Ecolink v2) that currently says open but I know is closed. I'm sure the door was just opened then closed too fast for the update to be acknowledged/confirmed. And in a normal situation this would be easily solved by walking over and opening/closing the door again but more slowly - however, this is at a second home and I won't be there for another month.

If the driver exposes a "Refresh" command, you can run that to see if it helps. For most Z-Wave devices, that is unlikely to help until they "wake up" again, which might happen once or twice every day or so, depending on the configuration (some drivers expose this as an option; many just use a default value), assuming the driver internally queues the command like it should. So, it might work, but you will probably need to wait a while. If you have the Zigbee version of this sensor (I can't remember if that actually exists...), then it will probably respond pretty quickly.

If the driver doesn't expose such a command, you're probably out of luck. "Configure" is unlikely to help (unless the lack thereof is the root of your problem in the first place), but either that or a "Save Preferences" in the driver is about the only thing you could try.

Also, unless you opened and closed the door within milliseconds, this seems like an unlikely cause of the problem, but I don't know your specific circumstances....anything human-speed would likely give enough time for the first event to finish processing before the second even comes in.

Depending on how the Zigbee driver is written, the refresh command may or may not cause the sensor to transmit the current open/closed state to the hub. If it is coded to do so, it will update its state within a few seconds. Z-Wave sensors will do so on their own 'wake up' schedule, which could be hours.

I found that Iris V2 Zigbee contact sensors when used with HE built-in drivers (Generic Zigbee Contact Sensor) don't update their current open/closed state when a 'Refresh' command is issued. This could be an issue if the sensor's state changes while the hub is rebooting, or for whatever reason the hub misses an open/closed event and gets out of sync with the actual state of the device. So a 'catch up' routine with refresh commands run after a hub reboot won't provoke the open/closed sensor to communicate its current state to the hub.

Using a modified version of the SmartThings contact sensor driver solves this issue (but creates another one, as the temperature conversion no longer works).

Try this:

https://raw.githubusercontent.com/thebearmay/hubitat/main/apps/forceClose.groovy

It’s a little app that does nothing except send a close event to contact sensors or an inactive event to motion sensors.

2 Likes

Would there be a way to schedule this to run or auto run from a virtual switch?

This one only has the contact sensor select, but does have the ability to create an optional button that could be “pushed” using a rule or other scheduling mechanism.

https://raw.githubusercontent.com/thebearmay/hubitat/main/apps/contactClose

Force Close does work quite well. I would hate to loose the motions but the button would be nice.

Should have time tomorrow to add the motions to the button version…

Thank you. I do appreciate it.

https://raw.githubusercontent.com/thebearmay/hubitat/main/apps/forceClose.groovy

now has the option to create a pushable button for rule and dashboard use.

Thank you so much. It works great.

1 Like

I may have spoken to soon. When in the app itself both contact and motion reports show the contact report. It may still be updating the motions and showing the wrong report not sure yet but I do not think so.

It’s probably grabbing the value before the event has fully updated.

Send close event button in the app and send inactive event button in the app both show the contacts updating and neither show the motion sensors. I would think that the send close report would show the contacts and the send inactive event report would show the motion sensors.

I see the problem wrong version of the code was pushed. Should be fixed now.