So like many others the ability to run RM to refresh devices is a nice work around to issues where the hubitat will not detect a physical switch change.
My question revolves whether anyone has any best practices to prevent the hubitat from slowing to a crawl which means rules and actions take longer to execute because hubitat is constantly refreshing switches.
What I originally thought was that I would only need to refresh physical switches where I required the physical switch for a rule/autmation (ie. physically turn off switch A to set the mode to night).
However, I am learning that were a user a/k/a a child turns on a light that would otherwise be triggered by motion, sometimes the light will not go off where there is no motion (ie. 5 minutes). I think this is the result of hubitat not realizing the light is on in the first place and, therefore, not turning the switch off.
This makes me wonder whether I have to refresh all switches and, if so, what are best practices for the frequency of refreshes and whether I should stagger the refresh (ie. 5 switches at a time every minutes, then another group of 5 switches every minutes) in order to avoid the point where actions take longer to execute (delay) because the hubitat RM is constantly refreshing several switches.
No, this is an artifact of the app being used to turn it off. Consider this sequence of events: child turns on switch, light comes on. Motion is activated, light is already on, nothing happens. Motion goes inactive when child leaves the room. Now what happens?
That depends on how the app for turning off the light is set up. Assuming that whatever app is simply looking for motion inactive in order to turn off the light, it would not matter whether or not the system thought the light was on or off. A motion inactive event will cause a switch.off command irrespective of the state of the switch. If the app were testing the state of the switch, or keeping track of the state of the switch, that would be a different kettle of fish. You may have to experiment a little on how best to do this, but the failure of the switch state to be noticed should not prevent the right app from turning it off.
In general, you only need "physical" events from a switch when you intend the pressing of that switch physically to cause other actions in the system.
