ZCOMBO Device Unknown...Tried Every Thing. Help With Log Needed

Add-ons Bindings
1

RPi 3-b, Aeotec USB. OpenHAB 2.5.
I’m having a devil of a time getting my First Alert CO/Smoke detector to be recognized. My thermostat and Deadbolt work fine.
Apparently the device does not stay awake long enough. I have been thrashing around for hours, attempting everything I can find to get past this stage.
All I see in PaperUI Things is Node13 “Online Unknown Device”.
I know I am working with the correct device because each time I exclude it and include it, the Node number goes up by one count.

Apparently the device can be awakened by sliding out the battery, holding the Test button and sliding the battery back in. I have done that so many times the slider is jamming. Nothing helps.

As a test, I did the steps above and captured the log. I don’t know what to do with this. Can anyone give me a hint about how to analyze this log?

Blockquote2020-02-09 15:12:35.937 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=13, callback=132, payload=84 0D 0A 04 A1 00 20 80 70 85 71 72 86
2020-02-09 15:12:35.942 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=13, callback=132, payload=84 0D 0A 04 A1 00 20 80 70 85 71 72 86
2020-02-09 15:12:35.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2020-02-09 15:12:35.945 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
2020-02-09 15:12:35.947 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
2020-02-09 15:12:35.950 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=13, callback=132, payload=84 0D 0A 04 A1 00 20 80 70 85 71 72 86
2020-02-09 15:12:35.953 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update request. Node information received. Transaction null
2020-02-09 15:12:35.955 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Creating new instance of command class COMMAND_CLASS_BATTERY
2020-02-09 15:12:35.959 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Command class COMMAND_CLASS_BATTERY, endpoint 0 created
2020-02-09 15:12:35.960 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update is adding command class COMMAND_CLASS_BATTERY.
2020-02-09 15:12:35.962 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Adding command class COMMAND_CLASS_BATTERY to the list of supported command classes.
2020-02-09 15:12:35.964 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Creating new instance of command class COMMAND_CLASS_CONFIGURATION
2020-02-09 15:12:35.966 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Command class COMMAND_CLASS_CONFIGURATION, endpoint 0 created
2020-02-09 15:12:35.967 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update is adding command class COMMAND_CLASS_CONFIGURATION.
2020-02-09 15:12:35.969 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Adding command class COMMAND_CLASS_CONFIGURATION to the list of supported command classes.
2020-02-09 15:12:35.970 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Creating new instance of command class COMMAND_CLASS_ASSOCIATION
2020-02-09 15:12:35.974 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Command class COMMAND_CLASS_ASSOCIATION, endpoint 0 created
2020-02-09 15:12:35.975 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update is adding command class COMMAND_CLASS_ASSOCIATION.
2020-02-09 15:12:35.977 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Adding command class COMMAND_CLASS_ASSOCIATION to the list of supported command classes.
2020-02-09 15:12:35.978 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Creating new instance of command class COMMAND_CLASS_ALARM
2020-02-09 15:12:35.980 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Command class COMMAND_CLASS_ALARM, endpoint 0 created
2020-02-09 15:12:35.982 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update is adding command class COMMAND_CLASS_ALARM.
2020-02-09 15:12:35.983 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Adding command class COMMAND_CLASS_ALARM to the list of supported command classes.
2020-02-09 15:12:35.985 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Creating new instance of command class COMMAND_CLASS_MANUFACTURER_SPECIFIC
2020-02-09 15:12:35.987 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Command class COMMAND_CLASS_MANUFACTURER_SPECIFIC, endpoint 0 created
2020-02-09 15:12:35.989 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update is adding command class COMMAND_CLASS_MANUFACTURER_SPECIFIC.
2020-02-09 15:12:35.990 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Adding command class COMMAND_CLASS_MANUFACTURER_SPECIFIC to the list of supported command classes.
2020-02-09 15:12:35.992 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Creating new instance of command class COMMAND_CLASS_VERSION
2020-02-09 15:12:35.993 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Command class COMMAND_CLASS_VERSION, endpoint 0 created
2020-02-09 15:12:35.995 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update is adding command class COMMAND_CLASS_VERSION.
2020-02-09 15:12:35.996 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Adding command class COMMAND_CLASS_VERSION to the list of supported command classes.
2020-02-09 15:12:35.998 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 13: Application update - no transaction.
2020-02-09 15:12:36.000 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-02-09 15:12:36.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-02-09 15:12:36.250 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-02-09 15:12:36.254 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Is awake with 1 messages in the queue
2020-02-09 15:12:36.257 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: COMMAND_CLASS_WAKE_UP not found - setting AWAKE
2020-02-09 15:12:36.258 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Start sleep timer at 5000ms
2020-02-09 15:12:36.260 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2020-02-09 15:12:36.271 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 13: Node Status event - Node is AWAKE

==> /var/log/openhab2/events.log <==
2020-02-09 15:12:36.271 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:fe40ab17:node13’ has been updated.

==> /var/log/openhab2/openhab.log <==
2020-02-09 15:12:38.760 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF
2020-02-09 15:12:41.260 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF
2020-02-09 15:12:41.262 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: No more messages, go back to sleep

==> /var/log/openhab2/events.log <==
2020-02-09 15:16:00.896 [vent.ItemStateChangedEvent] - BackRightWindow changed from NULL to StillClosed

Blockquote

2

First, that log looks filtered. Only unfiltered logs are useful. There is alog viewer that can help you interpret unfiltered debug logs.

https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

3

I have been using Chris’s log viewer but it is also Greek to me.
I don’t think I did anything to cause the file to be filtered. But who knows.
Using the log viewer from Chris’s site I see only two lines from Node 13.
“Application Update” and
“Node is AWAKE”.
The first expands to “BASIC
BATTERY
CONFIGURATION
COMMAND_CLASS_ASSOCIATION
ALARM
MANUFACTURER_SPECIFIC
VERSION”
Where can I find out what to do with this stuff?

4

This needs to be done only once. Your problems are arising because you did this several times.

Include the device once (!), then wake it up several times. You may need to do this 10 or even 20 times.

1 Like
5

FTR, I had such problems with one of these that I threw it in the trash. Even when I got it included in the zwave network (which was a major PITA), sometimes it would just drop itself off the network. Drove me nuts!

Maybe I had a defective one. Nonetheless, I thought I’d share my experience…

1 Like
6

Same experience. I’ve basically given up on having them be connected to my openHAB. I was cooking the other day and the alarm went off. OH never heard about it. I do not recommend these. At least they still work as stand alone alarms.

But I’m probably going to replace them at some point with something better, maybe stand alone and use a siren detector to get the fact of the alarm to OH.

Even the battery level reporting, which does work BTW, isn’t useful because the darn things start to beep when the battery is only down to 60%.

1 Like
7

sihui,
I always excluded first, then included, tried multiple wake ups, then excluded to start over again. I might have done the wake up as many as 10 tries but probability not 20.
But I got in deeper doggie due. After starting this thread I kept trying to get this to work so I went to the Aeotec site and one of the things they recommended is installing Domoticz. I did without knowing that it is a whole Home Automation app. As soon as I did it my Pi slowed down to 0.001 speed. I wanted to uninstall it but couldn’t figure out a way so I posted on their forum. The first response was get a beer and burn a new SD. But today other responses may show me how to remove it.

Also, Aeotec has Windows only program, Zensys Tool. I am getting the sense that the Z-Wave network configuration is in the USB stick. I may try using Zensys to add these First Alerts on my Windows 'puter. If that works, maybe I can move the stick to the Pi and have the full network.

I guess I should have paid more attention to the 9% negative reviews on amazon. I bought them in December and installed them but didn’t try networking because I was busy switching my 2GiG sensors to OpenHAB. Too late to return but the warranty route is still a possibility.
But what is the alternative? My house had 2GIG CO detectors but they expired. Replacements cost twice the cost of First Alert and require their technician to install. But I don’t want them installed on the 2GIG system I want them on OpenHAB.

I was thinking that all I need is the CO function because I have other Heat/Smoke detectors tied to OpenHAB and they send me a Text and Email if triggered. I can rationalize that I don’t need CO remote alerts because if they trigger and no one is home, who cares? When someone comes home they hear the alarm sound. Unless the alarming runs down the battery.

Ponder, Ponder Ponder.

8

If there is a factory reset, you might want to try that after excluding and before including. I have found some devices behave better after a factory reset.

9

I’ll keep that in mind but I have two other devices and they were not the easiest to get installed.

The factory resets the whole network doesn’t it?

10

I mean factory reset the device, not the controller. Most devices have an option to factory reset them.

11

Thanks, I’ll check that out.

12

From our copy of the manual.

RESET DEVICE
If the device is powered up with the test button held down for 10+ seconds, the
device will reset all Z-Wave settings and leave the network. NOTE: The device
will not remain awake after resetting and will go into standby mode.

https://www.cd-jackson.com/zwave_device_uploads/238/first-alert-NXZCOMBO-instructions.pdf

1 Like
13

Bruce,
Thanks for bird dogging that for me. I was off installing the software recommended by Aeotec.
So far, I call it two hours of wasted time but I am still communicating with Aeotec.

I did the reset (but excluded the device first).
I think the reset worked because I got a beep pattern that was different from the usual ones.
On my Windows machine I opened up a putty session and started:
tail -f /var/log/openhab2/openhab.log -f /var/log/openhab2/events.log

This shows me each line of the openhab and events log that is updated in real time.
I then included the FA detector and added it as a Thing, now Node 14…Unknown…
I started the awake sequence and observed a burst of log entries each time, each ending in:
" [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:fe40ab17:node14’ has been updated."

I attempted to repeat this the recommended 10 to 20 times but after the 12th time, wake up did nothing. No more burst of log entries. A few more wake ups didn’t help.
After typing this message up to here I tried another wake up and the bursts came back for two wake ups then stopped again.
I can’t believe the crap. First Alert is part of Kiddie which is part of United Technologies, one of the Dow 30 Industrials and my son’s employer.

I need to think about where I take this next.

Thanks All

1 Like