I acknowledge that a weak network can cause a lot of problems, and I have had my fair share of those issues. But my problems with Hubitat go much deeper than that. And I've only been using it for a month.
For example, I have tried to pool contact sensors 4 different ways, and none of them are reliable. I have used two apps, Device Groups and Simple Groups, and two different sets of my own rules in Rule Machine, and absolutely nothing works 100% of the time. Nothing. I have a Dashboard that shows status of the contact sensors, both real and virtual, and the real ones will open/close as expected, but I estimate around 30% of the time the virtual sensors simply do not react. How am I supposed to use this for security? Even if I don't pool sensors, triggers/actions just are not reliable.
Another example are two lights that I want to keep in sync. I have tried this three different ways, and none of them are 100% reliable. I've used the Switch Bindings app and two different sets of my own rules in Rule Machine to get this working. I can repeatedly click "on" and "off" in Hubitat and the secondary light will react, but using automated means to keep this light in sync with the master is met with frustration because it just... doesn't... work... at least not every time like it should.
The fact of the matter is that these things should require zero user intervention to work reliably. Even if an app has a bug that prevents it from working correctly, surely that shouldn't affect 3-4 different ways of doing the same thing, especially if two of them are using the built-in automation toolset AND work in testing. The commonality has got to be the underlying system, and it is.
In contrast, I have used Indigo for YEARS without a single question related to its reliability. Sure, I've had network issues that have kept things from working, Z-Wave and otherwise, but once those were resolved the reliability of the automation platform was never, ever in question. I don't want to go back to Indigo for a handful of reasons, but I simply cannot rely on Hubitat to work without fail. Rules should fire when they're triggered without my intervention or troubleshooting (aside from troubleshooting the rule itself), hands down.
The real answer to your questions are rooted in the above quote. I'm willing to help track down the reliability problem on your hub. If three or four methods aren't working then it's likely not the method that is the issue but rather a more systemic problem. It's annoying to spend time figuring out frustrating problems but once you get the kinks worked out it is blazing fast.
I mean, that would be great, but I still feel like that shouldn't be my or your responsibility in any way whatsoever. But that being said...
Here is my rule to keep two light switches in sync. This is about as efficient as I could get it. Initially I had it as two separate rules (when Porch Light turns on then turn on Garage Lights, and visa versa), but when it wasn't working I thought maybe I could lighten the load on the hub. Before that was the Switch Bindings app, and I just figured it was buggy. For the record, I no longer think that.
I mean, that should work. I still have not seen a time when Hubitat did not correctly process the physical "on" action, and there hasn't been a time when it couldn't turn on/off the Garage Outdoor Lights. Everything that leads up to this rule works as expected without problems - this is NOT a Z-Wave network issue.
Here's the rule that tries to pool Zigbee contact sensors.
Still pretty simple. These contact sensors work great. I don't know what else to say, aside from there are only two other rules in Rule Machine (one of which triggers based on the virtual sensor shown here).
As far as other apps, I have a few, but nothing that I would think would create a lot of load. The only one that I would think might is CoCoHue, only if because it has to stay in regular communication with the Hue bridge.
Anyway, thanks for your help. I'd sure like to get this ironed out so I can move forward with Hubitat (or not).
The ocd in me wants an endif to close it out but that's just me. The hub assumes an endif if it's missing. The logic in the rule is fine as it is. Are all your real sensors Zigbee or zwave? What brand? If zwave are they all plus? What build of hub firmware are you running 2.2.4.134?
The sensors are from Aqara, and they work great. I have another that doesn't work quite as reliably ("Garage Interior Door"), but that's not an issue for this particular rule.
The firmware is 2.2.3.148. It's all that's available to me via "Check for Updates".
Suspect devices will have either a high runcount or high average run time. Local devices should be around 15ms. Cloud devices will have much higher. A high total runtime varies widely but is based on the runcount and average run time.
The stats are a quick way to take a snapshot of what's going on on your hub to see if anything looks out of the ordinary or is aligned with expectations. If there is something misbehaving it can have all kinds of adverse visible effects, anything from missed executions to radio or hub lockups. For the later sometimes people reboot to temporarily alleviate the symptoms but they will almost always come back requiring a scheduled reboot or some other work around.
Device ID 67 is my Hue hub, and app ID 122 is Sonos Integration - those are my two biggest offenders, from what I can tell. And I'm not even using Sonos right now...
I've definitely noticed that a reboot will solve the problem temporarily.
The "Master Bathroom Multi Sensor (Old)" has almost-dead batteries and doesn't work that well anyway. I need to remove it, but I haven't gotten around to it.
As for errors in the logs, all that loads is the past 42 hours or so, and there are two from around 8:13 this morning:
java.lang.NullPointerException: Cannot get property 'location' on null object on line 521 (prefInstallChoices)
The S2 devices are Inovelli switches and a Light/Fan controller. I do not know their firmware version.
The repeater is there to make sure the "Garage Outdoor Lights" (the switch on the slave end of this broken sync relationship) can always talk. I've had network issues with that particular switch in the past, and since I installed that they've gone away. I acknowledge that nothing is using it now, but I don't know if I want to remove it or not.
That's fine. If it is indeed a non plus device just keep in mind they don't operate as fast as the newer plus versions so the end devices may be capped.
There is definitely a known issue with these. Take a look at version 1.48 firmware especially if using S2 inclusion. Well its 1.48 for the red v2's I don't know about the other models.
Here's the link for the red's... If you provide the model I can get you for any others.
Also shown in the last hubitat live video they showed that the firmware update tool was being included in the built-in apps. Just something to look forward to.
This looks like the latest for the light fan combo:
So looking into this more, the two switches in question are LZW30-SN devices, which are not dimmers. It looks like the more recent firmware on the web site is 1.19 (beta), and my switches report that they're running 1.20. I could probably stand to upgrade that of the light & fan controller, which is 1.34.
Maybe so, I'm pretty new to these devices. Either way, I don't see problems with these devices reporting their status to Hubitat, and I haven't seen any Z-Wave reliability issues (aside from the Garage Outdoor Lights, but I installed that repeater to resolve that) when trying to control them. I have all of this feeding into HomeKit, and remote/voice control of these devices is very reliable.
