When I started the migration process, I excluded a minimote from ST and paired to HE. I then used that minimote to do a general device exclusion for my devices to reset them, and the paired them to HE, and later went back and did a force delete of the device from ST after I had my automations moved over.
1 Like
Seems like that should have worked without any wonkyness... (that's a highly technical term 
)
There is a problem we have come to realize with using Rule Machine to poll devices the way people are doing it. We put a sniffer on a SmartThings hub to see what they are doing. We didn't have 50 devices to check with, only a few, so we don't know what changes with lots of devices.
The sequence goes like this starting every 10 seconds:
Poll device 1
Get response from device 1
wait ~1 second
poll device 2
Get response from device 2
wait ~1 second
poll device 3
Get response from device 3
wait ~1 second
We suspect that this approach may be why ST's polling works, but using RM does not. The difference being that with RM, one is throwing a bunch of polls out all at once, not waiting for a response, and not waiting 1 second in between. This could cause collisions in the Z-Wave mesh.
Next point is that ST hub doesn't do this routine for Z-Wave+ devices. It polls them very infrequently.
An important observation to be made is that you should only ever poll a device that meets three conditions: (1) the device does not report physical on/off events, (2) you need physical on/off events for an automation or Dashboard display, and (3) it is an older non-Z-Wave+ device.
We are investigating this further. Our thinking is that we can develop an app that does this for you, and get all of you out of Rule Machine for this purpose. With any luck, this may be in the next release -- no promises as I sit here not having a working app to test. In the meantime, we certainly recommend removing polling rules from Rule Machine, as these could very well be causing problems for your Z-Wave network.
7 Likes
Bruce, the exception being then for any GE/Jasco non-Plus switch & dimmer?
Isn't this what most of us with these switches/dimmers are already doing? We meet criteria 1 & 2 & 3... I for one don't poll / refresh any of my (very) few Zigbee or Z-Wave+ devices...
Thanks
J
I'm confused. Above in this thread you said you are having issues with your devices that you poll. Are you now saying that you are not polling any devices, but that they randomly turn on for you? If so, it sounds like you are talking about a separate issue than what is described in this thread.
Could we create individual actions similar to this in RM?
Lets say I have 5 device I want to Poll/Refresh, create 5 Actions, the 1st with 0s delay, 2nd with say 2s delay, 3rd with 4s delay etc. etc.
Will this work & overcome the issue you highlighted?
How literal should be interpret that RM doesn't wait for a response? As per your scenario, or definitely
for every Poll/Refresh issued, even when issues seconds/minutes apart?
Thanks
J
No, I poll/refresh on motion in groups by area (kinda "predictive polling"); I use to do so every 12s but was advised against doing so.
Yes, you could do this, minus the wait for a response part. In theory, if the device is alive, it will respond to a poll (if it doesn't, there's not much anything anyone can do about it, other than observe that it may be dead). RM does not wait for a response -- no app does. Responses come back to device drivers and may result in events if the state of the device has changed, or won't cause anything to happen otherwise. So the fact that RM doesn't wait for a response is not really germane.
We would write the app I describe to save you the effort of writing a gazillion actions to accomplish the same thing.
Thanks for checking on this @chuck.schwer and @bravenel , looking forward to seeing the solution. This has been the only thing that has really caused me concern in the migration process.
I'm wondering about the now expired "instant status" patent Lutron had... it was Dimmer specific if I remember right. The switches and wall socket/receptacles should/could have been supplying status all along. Why are we having to poll/refresh non-dimmers? I'm asking now because you might have that SmartThings sniffer still working. 
I did not realize that patent was for dimmers only. I just paused all of my refresh rules and went and flipped a switch and it updated immediately. That is very interesting. Now to check the rest...
Tested all of my non-plus switches. All are model 12338. I have 15 total, 8 of them do report instantly and 7 do not. Maybe a mid-cycle firmware update or something? I think the ones that don't report status were some of the first ones I bought, and the ones that do report were added later.
Is it possible to update firmware on these switches?
I don't know but I still have 3 of those non Plus Jasco/GE switches, they were reporting just fine and then in some point 2 just stopped reporting. Weird right, oh well, I created a rule for refresh them every 10 minutes, they are not very used.
To get me by until your update comes out, I did something like @GatVlieg described above.
After checking all of my switches for instant status updates (some apparently have that ability), it turns out that I only have 8 dimmers and switches that do not report state changes and are used in triggers and conditions. For these, I made the following rules:
YY0 - Runs actions for YY1 through YY8, repeats every 9 seconds
YY1 - delay 1 second, refresh switch 1
YY2 - delay 2 seconds, refresh switch 2
YY3- delay 3 seconds, refresh switch 3
...etc...
YY8- delay 8 seconds, refresh switch 8
This causes the trigger/condition switches to be refreshed every 9 seconds.
I have another 25 switches that do not report status and are not used as conditions or triggers. I want these to be updated as well, but only for dashboard display. For these, I made the following rules:
ZZ0 - Runs actions for ZZ1 through ZZ25, repeats every 130 seconds
ZZ1 - delay 5 seconds, refresh switch 1
ZZ2 - delay 10 seconds, refresh switch 2
ZZ3 - delay 15 seconds, refresh switch 3
...etc...
ZZ25 - delay 125 seconds, refresh switch 25
This causes these 25 switches to be refreshed about once every 2 minutes.
Obviously I can't check for responses before moving on to the next switch, and once every 5 seconds there will be two refresh requests sent out instead of just one. Other than that, do you see any glaring issues or potential problems with this approach?
1 Like
This doesn't really matter for what you are doing. As for the "every 5 seconds" part, it is possible these guys collide, which could be a problem, but no way to know. That's a good reason for the special app...
1 Like
I'm also hesitant to mention this... The only reason I even noticed is because I am currently hyper sensitive to light bulb & switch behaviour...
I had this happen today with a Cree Connected A19 light using the "Generic Zigbee Bulb" type. It is a dimmable light, but I never use it in this capacity.
- light physically off
- dashboard shows as on
- all "off" rules (to automagically switch it off when On or motion stops) show True but with no scheduled event (meaning, as per a conversation with Bruce yesterday, the event has come & gone)
It is only when I refreshed it in HE that the dashboard showed Off & all rules showed False. Means it didn't report back methinks.
J
This refresh problem is only applicapable to zwave devices.
Zigbee devices either were excluded from the patent or are new enough that they are excluded. In any event I have yet to find a zigbee device that's part of a solid mesh that does not report events from physical or command activation.
If you have refresh a zigbee device to fetch it's current state (excluding sensors, as these have specific reporting intervals) then there's something up with the device, but more likely the mesh.
Hi
Was there any update to this issue? I think I am having similar issues with fibaro dimmers.
Depends on the driver and device being used.
Generally physical/digital cannot be reported accuratly using refresh.
