So, I've been experiencing generalized flakiness with Hub transmission and recording. I'm currently on 2.2.6.140. I had moved to the 2.2.7.x family and that was considerably worse.
One possible correlation I may have found (not yet enough data to rule out coincidence) is that things seem to crap out when the whole house fan is running.
I have an outlet controller on a hot water recirculator in the garage. In turn, I have a small night light connected to an outlet controller near the bedroom as a state indicator. In between I have a Simple Rule to turn the light on when the water circulator turns on and vise versa. I also have a separate off rule for backup due to flakiness.
This morning:
With house fan running, the light did not come on when one of the two separate buttons that controls the circulator was pushed. Checked logs: The light controller did not record an on event. The Sinple Rule did not report triggering. In fact, the controller for the circualtor did not report the on event. Yet, it was on. Tried this several times with the same result. Turned the fan off and it worked better.
In general, the light part of this is less reliable. Sometimes does what it's supposed to do, sometimes not. And this is independent of the fan.
Any ideas? Should the fan (which is nowhere near the garage where the ciriculator controller is located? have an impact?
Also, ideas for the general flakiness of the status light following a Simple Rule? Anything I could be doing wrong/could set up better? Z-Wave/Hubitat can't be this flaky in performance given all of the positive comments, so looking for things I could be doing better.
If this were X110, I could easily blame electrical noise. But it ain't
It does sound like RF interference. I'm assuming the light is zigbee. You could try changing channels and see if that cures you (let your mesh settle for a while before declaring victory) If it continues you could have a mildly corrupt database. Simply download your current config, do a soft reset, then reapply the database you saved.
Could a large piece of rotating metal (i.e., fan blade) disturb the RF route (when moving but not when still) enough to cause an issue? I have no idea - just trying to think of possible causes.
Certainly a thought. But the interesting point is that, in these cases, the signal that actually turned on the outlet controller was delivered reliably as the unit turned on. However, Hubitat has no record in the Event Log of this unit having a Turn On event. So, it seems more like a Hubitat than Z-Wave issue.
And, of course, if the main controller doesn't think it's on, the follow-on path to turn on the slave won;t be initiated.
So, what could it be about the fan that messes up the Hubitat controller enough to miss events?
The fan motor controller could be generating RF signals that are interfering with your Z-wave mesh.
If the rotating fan blades are in the signal path between the hub and any of your devices, the blades may either partially block or reflect the signals causing transmission errors.
If the problem is the former, you might need either to leave the fan off or replace it.
If the problem is the later, then adding one or more Z-wave repeaters/range extenders might allow the signals to bypass the fan blades. The problem is that the preferred routine might be different with the fan on and the fan off, which could affect the mesh stability.
The RF is the more likely of the two. The fan is not between the hub and the garage controller. Interestingly, it is between one of the switches and the hub. But the hub records the switch push, so that gets through.
I'm still stuck on the fact that the signal to turn on the controller did get to the controller and turn it on. It's just that Hubitat has no record of this in the event log. Not sure what would cause this.
The reality is that we can turn off the fan to take showers (main use for the hot water circulator).
Then there's the intermittent failure of the status light controller to log the events even though the path from circulator controller through Simple Rule app is just fine. This is without the fan on.
What I don't know is whether Hubitat logs Events on send (in which case this behavior is very odd( or upon receipt of an ack from the effector, in which case this seems to imply pretty reliable command send and almost equally reliable failure of the return ack,
To insure reliable operation, you might be able to create a routine that turns off the fan and then turn on the hot water circulator when you get your shower and then turns off the circulator and turns the fan back on when you are finished.
The fan is at least the 15 years since we bought the house old and is on a manual timer switch. I could swap this out for something Z-Wave, but it's really not worth it. Easier to just not have it on since they're physically close.
As well, I do have occasional flakiness even with equipment like this off that I can't explain. Things just sometimes fail to trigger/log with Hubitat for no good reason.
For the current case, it's still not clear to me why the signal to the circulator makes it just fine, but the logging fails consistently causing subsequent actions not even to launch.
It may be that the signal from the hub to the circulator is stronger than the signal from the circulator back to the hub. Thus, the hub might not be receiving feedback from the circulator that it is running, even though it is.
Event logging, for almost all Z-Wave and Zigbee devices, only occurs when the actual physical device sends a status update back to the Hubitat hub, with a status update that differs from the current state of the attribute for that device.
So, if a Z-Wave switch is currently off, and the device sends a sequence of status updates as ON, OFF, ON, OFF - then there will be 4 events logged for that device in its EVENTS section. If it sends ON, ON, ON, ON - then only the first event will be logged, as the others did not result in any change. (Note: There are always exceptions to this rule, for very specific situations. But for a typical 'Switch' device, the above holds true when using built-in Hubitat drivers, for Z-Wave Plus and Zigbee devices. Older Z-Wave (non-plus) devices may not reliably return a status update, and there are some special drivers for those.)
To test some of the theories above, simply open up the Device details page for the 'suspect' device. Click "On", then "Off" and watch the 'switch' attribute to see whether or not it consistently updates. Try with the House Fan running and with it stopped. If the attribute on the hub does not reliably update when changed via the hub only with the fan running, then you'll at least know that the fan is causing the issue.
What brand/model of Z-Wave device are you using that is not reliably reporting its status back to the hub?
If you know someone with a spectrum analyzer you could determine whether your fan doubles as a spark-gap transmitter. It doesn't even need to be on the same frequency (or harmonic) as your zwave devices if it is overloading the front end of the radio.
Is there any correlation between the non-functional devices and the distance to the fan?
The primary non-functional device is pretty far from the hub. It's in the garage through several doors. Interestingly, the furnace and fan are in the same place but the furnace does not impact the functionality. The fan itself is not in the path between the hub and this unit. The status light is very close to the fan, but it certainly won't update if the initial unit is not reporting properly.
While the fan is not in the path, it's not too far from the hub, even if in the other direction from the garage, so it may be that it's interfering with the hub receipt of the ack.
I'll see if anyone has a spectrum analyzer.
@ogiewon , thanks for the suggestions. I can try this experiment. Since I've looked at the logs after-the-fact, I have a good idea of what does,and does not, get registered. It makes sense that the logging is on the return ack.
Since the fan is at least 15 year old, it may well be that components like capacitors that are designed to minimize RF interference are deteriorating. Capacitors are part of filter networks to shunt stray RF to ground.
Since you mentioned spark-gap transmitters, I presume you are either an amateur radio operator or at least have some knowledge of that hobby. Spark gap transmitters have not been legally permitted for nearly 100 years, but that does some devices may act like one. Of course, lightning is the ultimate spark gap transmitter.
If the fan is generating wide band RF interference, you might be able to detect it using battery powered AM radio receiver.
I was really just suggesting to the OP that his fan might be the source of unwanted RFI and that was one way to confirm it if one had the right equipment and knowledge. Who knows... maybe it just needs to be grounded, though given the age of the fan I suspect your explanation is probably more likely.
Back on the RFI topic (and this really is the most likely), I had moved the hub more out-in-the-open on my desk for a somewhat better path. Well, I put it on a small platform that also held my wifi router. With that setup, additional things started to be very flaky even with the fan off. It is now back where it belongs and things are generally stable with the fan not on.
Still the periodic miss for no reason, but this is surely not a 100% reliable device or technology, so I can live with this.
The 2.4 gHz WiFi router band and Zigbee share the same frequency space. The channels are labeled differently, but Zigbee channel 20 fits in between WiFi channels 6 and 11. If you have WiFi devices on channels 6 and/or 11 and your Zigbee is on channel 20, the sidebands of the WiFi channels can interfere with the Zigbee signal. You can operate this way if you separate the WiFi router and Zigbee hub. If they are too close, you can expect problems.
You can try to keep your WiFI devices on channels 1 and 6 or use higher Zigbee channels like 25-26 to avoid interference, but only if all your Zigbee devices support the higher channels.
