[RELEASE] Hub Information Driver

Thanks for the reply! Might be too far above my pay grade at this point. I currently use this integration to get my devices in HASS, https://github.com/jason0x43/hacs-hubitat

I'm using Jason's integration as well. However, as you have found, it only exposes temperature and last update time.

Or piggybacking a second 8 K chip on the OEM 8K chip with one leg lifted and switched by a little assembly code from the keyboard. I thought I was a genius..

Totally did that!

Curious if anybody has any experience with the two radio offline attributes of this awesome device? Are they reliable? I ask because this morning I had my zigbee radio go offline on one of my hubs, but zigbeeStatus didn't pick that up.

As @thebearmay points out, I suppose my notification rule should be based on the hubAlert attribute, not just zigbeeStatus. Still, made me wonder why these two don't align.

Can't say I have, but I expect most people will have "other avenues" that they will be notified if these comm's are disrupted.... :wink: I don't have those alerting systems in my household, but I still soon find out when the lights don't turn on or other Zigbee-related activities don't work. No dis-respect to the efforts of @thebearmay.... but some hub issues reveal themselves in various ways....

I wonder if it's because zigbeeStatus is reporting that the service itself is enabled (allowed to run) while online/offline is the service's current state (running or not running)?

2 Likes

Ultimately both conditions should agree, but they are derived from different sources. The hub alerts come from the UI Alerts (generally crash/threshold conditions or update notices), while the status is querying the hub's zigbee data to see if the channel is still actively assigned.

High CPU or temperature warnings tend to generate a zigbeeOffline alert, and may eventually lead to the zigbee channel being disabled if the condition remains unchanged long enough; this would then trigger the zigbee status. Whereas the user can decide to turn off the zigbee radio setting the zigbee status to disabled, but will not generate a zigbeeOffline warning.

3 Likes

Note that the Zigbee radio actually does not turn off when 'Zigbee Status' is set to disabled. It stays up and running at the PHY and MAC layers.

When you set Zigbee status to disabled, even when the Zigbee Details page shows 'Zigbee Network State: OFFLINE' , a sniffer trace still shows the coordinator broadcasting to the 0xFFFC destination address on its assigned channel (this is the 'all routers' reserved address). However, until you set Zigbee Status back to 'enabled', the hub won't directly address any individual routers (at least for the duration of the traces I tried). Apparently the OFFLINE Zigbee state is an indicator of the application layer's status.

2 Likes

@thebearmay Maybe I missed something, but don't see any obvious options nor any comments in here about it. Is there any way to log certain attributes (or all of them)? I use Splunk for monitoring, but that relies on getting a feed from the hub logs.

I use MakerAPI to feed Node Red and my graphing, but there is probably another way out there.

2 Likes

I'm using the syslog driver to forward the logs over to Splunk. So if it doesn't show in the event logs, then I won't be able to pull it in.

Should see an event anytime there is a change in the attribute value.

Sorry...wrong wording. I meant to say I won't be able to see the data in Splunk unless the attribute value is also logged.

Every event should have a value

Right, but not here:

And what is generating that? It looks like it’s a modified version of the driver.

This driver, unmodified, installed via HPM. Even did an update today because I was a few versions behind. I just had debug logging enabled. With debug logging turned off, the driver doesn't generate any logs.

I obviously haven’t run it in full debug mode for quite a while. Didn’t remember having many of those debug lines in there, but their purpose is to help diagnose logic issues or broken connections. Would actually be a simple 2 line modification to produce a log entry when an attribute changed (one to capture a prefence switch and one to log).

OK, I loaded this through HPM. Now what?