You would use refresh. So yes, if logging is on, it’s going to fill up with that. But that would solve your problem…
1 Like
We are going to have a better solution for you in the next release. Rule Machine is getting enhanced in two ways: First, it will support Periodic triggers in seconds, so you could trigger something every 10 seconds. Second, it will support Refresh as a built-in action – no need for a custom command.
With these two enhancements you will be able to refresh those lazy-reporting devices as needed to capture events not being reported by the device in a timely way. You would only expend mesh and cpu resources as required for your devices, and not waste same on every device.
With respect to the logging issue, we are looking at providing a filter mechanism so that you can weed out the non-events caused by refresh, and see just the real events from the devices actually turning on or off.
2 Likes
Awesome thank you! Just so I am clear is the Rule Manager refresh functionality the final solution to solve this problem or are you still working towards a better solution? I ask because 60+ GE Zwave switches and outlets in my home and I will have to setup rules for all of these which isn't ideal. Of course many of these aren't used as often as others, but it would still be awesome to have a built in feature that doesn't require setup through a rule.
Awesome thank you very much! I created this thread to suggest a few things about device events filtering if interested.
1 Like
No, you would only have to setup one trigger in Rule Machine for this, and select the devices you need to refresh. We will have a fix for the logging issue also, but don’t need the filters. This is the fix for this. Bear in mind that ST’s fix for it is to poll every device every 10 seconds. So this is better. There is plenty of CPU power for it, and obviously the mesh can take it, so there you go.
1 Like
Thank you for confirming. My only feedback is this isn't going to be that obvious to new users and it needs to be well documented. Some of the most popular threads in ST Community have been about GE switches going on sale or on clearance at various stores so I know I am not the only one with tons of them.
My low priority suggestion would be to create a specific GE driver with a preference to "enable automatic polling" with a selection of timings - similar to the generic zigbee outlet driver with the additional preference. Behind the scenes you could create rule that does this automatically for the user.
I know you are focused on new apps and I agree, but if you plan to market Hubitat to the masses, the little things will need to made easier.
Agreed.
I cant imagine new inexperienced user will ever research need for a refresh of a specific device.
This has to be built in, some sort at some point.
1 Like
You guys don't get it. This is superior to what you are used to in SmartThings. If you want snappier response from these lazy devices, crank the rate up. I don't know at what point that becomes counter productive, but no doubt that will depend on how many devices you run it against.
We will fully document this, and no doubt this Community will pitch in. "building it in" doesn't mean that people are immediately going to find it. We certainly wouldn't do this to the default driver. Even if, as suggested, we put it in a special driver for a lazy device, there is no guarantee that (a) that particular device even needs it, or (b) that the user would know to set it. Either way it's going to take some guidance. The approach we are taking is superior.
1 Like
I am sorry for the frustration over this issue. I am sure it is something no one anticipated and Jasco is to blame. I am in no way saying Hubitat is inferior to SmartThings. None of us would be here if you didn’t have a superior product.
I am not suggesting that you follow suit in how SmartThings solved this issue either. The reality is GE/Jasco devices are quite common and available everywhere and this issue is going to present itself more and more especially as you market Hubitat as an automation platform, which it most definitely is. So I do get it.
I am just simply trying to offer product suggestions with anticipation that many others are going to experience the same challenges and may not have the technical know how to fix it. End user experience is always on my mind as I work for an enterprise software company.
1 Like
I don’t think there should be a default or recommended option to do this ST style. The preferred method with the option to enable per device is the right option.
This is a situation where ease of use to the “normal” user is not the best approach. Users like that take the easy way out if offered to them. Education, and the option to enable per device, is the best solution.
If a user isn’t technical enough, they probably won’t be on this platform, but if they are, and run into this issue, they’ll research or ask hopefully. Don’t impact the intended user base due to the non intended user base I guess is what I’m saying.
3 Likes
@bravenel @patrick @mike.maxwell I updated my hub to v701 so I can leverage the Rule Machine updates for refresh. So far so good so thank you very much for your efforts with this solution.
Right now I have two rules, one that refreshes every 60 seconds for the ones that I don’t care that much about and one that refreshes every 30 seconds for the ones that have other automation associated to the physical event. Testing is positive.
I don’t want to overwhelm the hub which is why I have two separate rules. But if I were to change the 30 second rule to 10 seconds is that too much load? Again I would limit this to a smaller number of switches but I certainly don’t want to overwhelm or cause issues on the hub.
Thanks again for the quick turn around on this solution!
I think the great thing is you can try any value and measure if its too much. We know 10 seconds was ok for ST, so I’d start there and see if you notice slower app execution, etc.
1 Like
The issue isn't really the load on the hub, it's the load on the mesh network. Experiment, and let us all know. My bet is you can run @ 5 seconds if you want. It might help to break it into multiple triggers so they aren't all happening at the same instant.
1 Like
So… after creating a rule that states 'Refresh [device] every x seconds". I should be able to execute a rule that relies upon a physical event trigger (ie. turning off the light)?
Yes I have a switch that never logged physical on events and with this rule it now works. A GE outlet in the room automatically comes on in -10 seconds:
1 Like
I took your advice and set up some staggered refresh triggers for my three switches; works very well. But when happened to choose any seconds >=60 seconds for a switch, the rule doesn’t trigger (59 seconds does; I know should use minutes but I have a knack for breaking things inadvertently).
It can only do 1 to 59 seconds. That’s Cron under the covers…
I figured.
I see thatlogging of ’ debug refresh() is called’ is immune to the setting of the debug switch; is that intentional? It might actually be desirable in some way just as reminder of what’s going on under the covers.
Yeah, but you did discover a bug! We aren’t enforcing range limits on number inputs. So you get a prize. Not sure what, but I’ll think of something…
1 Like
Can you show a screenshot of that?
