Once the mesh is solid adding switches, etc. to it usually goes smoothly, the exception being when you try to add a device past the range of the mesh.
2 Likes
Can you help me understand "solid adding switches". I still have I think all my LWR_RSSI numbers in the orange and red on "Hubitat Z-Wave Mesh Details". Thanks
I think @thebearmay meant -
Once the mesh is solid [,] adding switches to it....
Once your repeaters are in place your mesh should be "stronger". Adding devices should be less of an issue unless you are outside the range of the mesh.
2 Likes
Congratulations! You have now passed the Hubitat C-7 rite of initiation. It may be hard to believe, but it is so much better now than it was at product introduction.
3 Likes
The details on Amazon state this:
- Requires the Ring Alarm Base Station and only boosts the Ring Alarm system network
Can these be used without a Ring device to extend Z-wave? Or must I have a Ring device as well?
@mebejedi, you only need the extender itself nothing else is required... this is on my C-7..
3 Likes
Yes. I have 6 on my C-7, no other Ring devices.
No. The only possible thing that a Ring base station might be needed for is to update firmware. I havenāt seen firmware files on Ringās website for the Range Extenders (or anything else).
4 Likes
I have them all over my house and donāt have a ring base station.. They are my favorite repeaters because of the battery backup..
3 Likes
Apparently the Hubitat hub's favorite too. Lots of devices grab onto these repeaters very readily. Did you give these higher priority in the routing table or something? 
1 Like
Don't have that kind of control over the SDK .. Wish I did..
I have the opposite experience. I have moved my one Ring repeater all over house to try and get any devices to use it as repeater. No luck. My devices seem to prefer the Aeotec one.
1 Like
Yeah me too at least initially - over time (and subsequent firmware updates) things seem to have improved and more stuff is routing through them. I do think location is key I usually put it half or a third of the way from the hub to device that's furthest (farthest?) away erring on the side of closer to the hub.
Yes, choice of actuator is correct.
For the Rule, you have it backwards. The way you have it, you will get instant shutdown if any is mains. You have probably discovered this issue because your hub instantly shuts down on boot. My shutdown was in the ELSE clause, yours is in the THEN clause. Also, mine was ALL, yours is ANY.
The equivalent, since you donāt seem to want to notify if one fails but others donāt, is:
IF ALL of (the RINGS) are battery
THEN shutdown
Your only way to recover from this, if you saved and started the rule, would be to start the hub in safe mode, then disable the rule.
Another better way to recover, since you have it shutting down if all Rings are on mains (have AC power), would be to pull a Ring from the wall so that not all are on mains (one is on battery), start the hub, disable or delete the rule, edit it, plug Rings back in, check the device page for the Rings to make sure they are back on mains, refresh if not, then save the rule.
See, the reason I required none to be on mains (ELSE clause) was precisely so you could test each Ring by unplugging and plugging. Thatās why I had the notification.
You donāt have any delays, so the cancel delayed actions is not needed.
Sorry I didnāt see this before I went to walk the dogs, just got back.
This has motivated me to do the voting algorithm, which I will do today. Itās a bit complex because of deadly embrace and concurrency issues, but I have a solution in my mind.
Ok, I wrote the voting algorithm code, but I decided to leave things as they were (donāt shutdown until all Ring Extenders report power fail). Why? Fear that I could get into a situation like @ginnyaction, where the hub would do an immediate shutdown on boot.
Discussion:
The first problem is a concurrency retriggering issue in the shutdown rule. That doesnāt happen in the Rule given above, because the test for whether Any Ring is still on mains will be re-evaluated on each retriggered instance. And, my original concern about flapping of the house main power source during power fail events will still be correctly evaluated - if a Ring comes back online (switch back to mains), the shutdown will be prevented. The hub is on UPS, the Rings are battery backed up internally, power events will still be reported and evaluated.
On power return, the hub will eventually be rebooted, but will have missed the final power event (return to mains) sent while the hub was shut down, and the Rings come back online while the hub is shutdown, so the hub thinks all of the Rings are on battery, when they are not. However, the systemStart power up Rule (above) refreshes all of the Rings, so that their status becomes known.
The fact that the shutdown rule delays two minutes before shutdown means that, on power up, the systemStart power up rule has time to refresh the Rings before their incorrect status (all on battery) causes the system to immediately shut down.
All of this I thought through and tested before publishing and deploying these two rules. I have made no assumptions about Hubitatās scheduler, and believe that even worst case assumptions still cause these rules to work.
Now, a caution: I donāt have source to the systemStart code, to the Ring driver (itās built-in), or the Rule Machine scheduler. At some point about September-December 2020, there was a firmware release that caused the Ring Extenders to get stuck on battery status, and a refresh wouldnāt fix it. I turned in a problem report, never heard back. I believe that I had to switch the driver to Device and clear all states to get the proper status restored. But that issue seems to have fixed itself in subsequent releases.
Anyway, I have left it as above. My fear is that a proper voting algorithm that avoids missed power source events requires:
separate Rule for each Ring, triggering on that Ringās power source changed, then a critical region using Private Boolean exclusion, not with an Exit Rule (because that would drop events), but a Repeat While ā¦ Wait for Condition, Private Boolean True idiom at the start, then set a Global Variable to 1 / 0 based on state of the Ring power source.
Then, a Rule triggered on any of the Ring power sources changed, with a standard critical region on Private Boolean, Exit Rule if False, add up the Global Variables.Reset all Global Variables in the systemStart as well.
That would work, but would be more dependent on the systemStart scheduling, and might have a deadly embrace depending on how the Waits behave on shutdown, and how Private Booleans get left on shutdown.
So, I decided to leave as-is.
FYIj... still working this. Been unable to replicate your rule. Missing something... but still working it.... give me time... LOL
1 Like
I, or anyone else in the forum, would be glad to look your rule over before you install it.
The best way to do a first level test with something as dangerous as shutdown is to not have the shutdown initially, but to have a phone notification or logging statement instead. That way, you can watch operation of the rule as you pull one, then all, Rings. Then, for final test, put in the shutdown and let it rip, see it shutdown when you pull the Rings (to simulate power loss to them).
I believe I explained all the issues and design decisions in my previous post.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
