Not detecting Zcombo smoke alarm

[TC1]

I've installed the plugin on HS4 V4.1.10.0

I also installed a First Alert Zcombo smoke/CO detector about 12 hours ago.
I can see that the System Notification child device of the Zcombo is updating Heartbeat status approximately every hour.
I have "Log Poll and Wake-Up Messages" on my controller.
"MonitorHeartbeats" is checked in the SDJ config.
I do not see any heartbeat events in the logs beyond the initial device inclusion (log acknowledges the device heartbeat capable).

How does the plug-in recognize this device? Is it reading the System Notification child device for updates or is it dependent on the HS4 log for heartbeat messages?

[SteveMSJ]

I've installed the plugin on HS4 V4.1.10.0

I also installed a First Alert Zcombo smoke/CO detector about 12 hours ago.
I can see that the System Notification child device of the Zcombo is updating Heartbeat status approximately every hour.
I have "Log Poll and Wake-Up Messages" on my controller.
"MonitorHeartbeats" is checked in the SDJ config.
I do not see any heartbeat events in the logs beyond the initial device inclusion (log acknowledges the device heartbeat capable).

How does the plug-in recognize this device? Is it reading the System Notification child device for updates or is it dependent on the HS4 log for heartbeat messages?

My memory is a bit sketchy as it is a long time ago that I wrote that section of the plug-in. I don't have any heartbeat devices myself but I know it has been working for quite a number of people for some time. I will need to delve back into the code to refresh my memory, but the gist of what it does is as follows:

When you tick the 'MonitorHeartbeats' feature the pi scans your Z-Wave devices for any that have the 'Alarm Heartbeat' status pair. If I remember correctly the Zcombos have a Notification child device which amongst its many Status Pairs has 'Alarm Heartbeat' with a value of 13.255.
Now, in normal operation the Zcombos send this Alarm Heartbeat value every hour. The tricky problem is that HomeSeer only notifies plug-ins if the value changes not if it is set to the same value. To get around this SDJ-Health adds an additional status pair to the ZCombos with a value of 13.355 and a Status of 'Heartbeat Acknowledged'.

At startup SDJ-Health checks for any of those devices whose status is 'Alarm heartbeat' and changes it to 'Heartbeat Acknowledged'. That way when the device sends the next 'Alarm Heartbeat' it is a change so HS will notify SDJ-Health, which it records as a success, and then sets the status back to 'Heartbeat Acknowledged' ready for the next time. This allows SDJ-Health to monitor the Heartbeats.
NOTE that the value is only changed if the status is set to 'Alarm Heartbeat' so it doesn't interfere in any way with the operation of the device.

The first thing to do is look on the Status Graphics for the Notification device of the Zcombo. If there is a pair with a value of 13.355 and a Status of 'Heartbeat Acknowledged' then this indicates SDJ-Health found the device and setup the special status/value pair. If it has, then I would expect a monitoring child to have been created by now.

If it has the special pair, then try restarting the SDJ-Health plug-in. Shortly after Startup (10 to 20 seconds) you should see the Status of the notification device change to 'Heartbeat Acknowledged'. The next time a heartbeat is received SDJ-Health will create a monitoring child, if it doesn't already exist. If this doesn't work it would be worth turning loglevel to 2, restart the plug-in, run it until you are sure a heartbeat message has been received, filter the log for SDJ-Health messages.

Let me know how you get on.

Steve

[TC1]

Thanks Steve, that gives me enough info to go digging.

[TC1]

SteveMSJ maybe this is the problem? See below the status definitions assigned to the System Notification child device for the my Zcombo in HS4:

[SteveMSJ]

SteveMSJ maybe this is the problem? See below the status definitions assigned to the System Notification child device for the my Zcombo in HS4:

Yes, that's very different to the original ones! I was always baffled by why they had such strange status values, they now use more logical integers. I will need to update the plug-in to work with those.

Out of interest, does the Last Change Time of the System Notification device update hourly with the heartbeat?

Steve

[TC1]

Yes, that's very different to the original ones! I was always baffled by why they had such strange status values, they now use more logical integers. I will need to update the plug-in to work with those.

Out of interest, does the Last Change Time of the System Notification device update hourly with the heartbeat?

Steve

Correct, the Change time updates with the heartbeat.

Even better, I just found all the Z-wave parameter information on these devices, see link here:
https://1hwaqv35k3or3y079muiil4q-wpe...ication_V2.pdf

[SteveMSJ]

Correct, the Change time updates with the heartbeat.

Even better, I just found all the Z-wave parameter information on these devices, see link here:
https://1hwaqv35k3or3y079muiil4q-wpe...ication_V2.pdf

If the change time updated with the heartbeat then you can use the Activity Monitoring method. Just select the battery device in the list of devices that require activity checking. You can deselect MonitorHeartbeats.

The problem with the originals was that the time didn't update with the heartbeat.

Steve

[SteveMSJ]

If the change time updated with the heartbeat then you can use the Activity Monitoring method. Just select the battery device in the list of devices that require activity checking. You can deselect MonitorHeartbeats.

The problem with the originals was that the time didn't update with the heartbeat.

Steve

Also, looking at the Z-Save spec you linked, it looks like these new ones wake-up every 24 hours by default. If you leave it and do nothing you should find the plug-in detects it automatically after 24 hours.
I
These are obviously totally new devices not just an upgrade to the originals.

Steve

[TC1]

Also, looking at the Z-Save spec you linked, it looks like these new ones wake-up every 24 hours by default. If you leave it and do nothing you should find the plug-in detects it automatically after 24 hours.
I
These are obviously totally new devices not just an upgrade to the originals.

Steve

I think there's a problem with the wake up method in terms of "modern" z-wave devices.

For example, all of my Monoprice (same as the HS ones) z-wave+ door sensors ignore the wake-up set parameter and simply send updated info to the controller when an open/close event occurs. I never see a formal wake-up entry in the logs.

Though this Zcombo says it will wake every 24 hours, it hasn't happened, in that I haven't seen a log entry. Other parts of the documentation also says it will not update battery levels unless there's a level change (similar to how Zigbee battery devices work to conserve power). Either HST implemented the device definition incorrectly (not the first time that has happened!) or these devices simply do not do a traditional cyclic wake-up.

Using the Health plug-in I have yet to find any of my Z-wave devices that have been detected via wake-up (except for one old Monoprice regular Z-wave motion sensor).
For locks, I have them using your polling method, which works fine.
For everything else (other z-wave battery devices and zigbee battery devices) looks like activity monitoring is the only thing that will work.

Thanks again for the insights

[SteveMSJ]

TC1 Thanks for the additional information.
I'm interested to get to the bottom of what is going on here.

I think there's a problem with the wake up method in terms of "modern" z-wave devices.

For example, all of my Monoprice (same as the HS ones) z-wave+ door sensors ignore the wake-up set parameter and simply send updated info to the controller when an open/close event occurs. I never see a formal wake-up entry in the logs.

Whilst all my non-listening Z-Wave battery devices send open/close, motion, temperature, etc events instantly, they all send a 'Wake-up notification' at the regular wake-up interval set for that device. I have a mixture of Z-Wave and Z-Wave+ devices but nothing purchased in the last year. According to the Z-Wave document for your new ZCombo it will send a 'Wake-up notification' every 24 hours.



So, I don't understand why HomeSeer isn't logging this on your system. I'm pretty sure you said you have 'Log Poll and Wake-up messages' checked. Can you double check that?
I wonder if it is an S2 issue? Which version of the Z-Wave pi are you running and did you include the device(s) unsecure, or if secure what type of security?

I haven't had anybody else (so far) report any problems with wake-up detection of Z-Wave non-listening devices and there are a lot of users of this plug-in. I suspect it is either due to some change in the way the Z-Wave pi handles security or something unique to your system. Either way I would like to find out what it is.

The only times I have seen HomeSeer missing these messages is when the Z-Wave pi get's in an unstable state. This is a well documented, but unresolved bug, that usually occurs after including some devices and manifests in high CPU and Z-Wave slow downs, with one consequence being missing log messages. However, this is resolved by restarting the Z-Wave pi, so I don't think it is the cause of what you are seeing if you have been experiencing it over a period of time.

Though this Zcombo says it will wake every 24 hours, it hasn't happened, in that I haven't seen a log entry. Other parts of the documentation also says it will not update battery levels unless there's a level change (similar to how Zigbee battery devices work to conserve power). Either HST implemented the device definition incorrectly (not the first time that has happened!) or these devices simply do not do a traditional cyclic wake-up.

Using the Health plug-in I have yet to find any of my Z-wave devices that have been detected via wake-up (except for one old Monoprice regular Z-wave motion sensor).
For locks, I have them using your polling method, which works fine.
For everything else (other z-wave battery devices and zigbee battery devices) looks like activity monitoring is the only thing that will work.

Thanks again for the insights

Z-Wave Locks, sirens and other battery devices that have to respond to commands are 'listening' devices so don't send a regular 'Wake-up notification'. They use Beaming, FLiRS so that the appear effectively to be always awake. As you say these are best monitored by the polling method. Similarly the plug-ins for devices using other technologies don't log wake-ups and most aren't pollable, so Activity Monitoring is the best method.

Are any of your Z-Wave battery devices, other than the Z-Combos, non-listening? You can tell by looking at the Z-Wave Node Information page where for each device, after ID, it says 'Listens:' Yes or No.

Here is a 'Non-listening' device:



Here is one that is a 'Listening' device that uses FLiRS and therefore requires Polling or Activity Monitoring:



Your help in trying to to find any issues is welcomed.

Steve