Z-Wave ZCOMBO-G Initialisation NOT yet complete

[Brian Moy]

Hi,

I am having issues binding my First Alert Smoke/Fire and CO Alarm to OpenHAB.  My setup is as follows:

Server: OpenHAB 1.7.0 on Win7 64-bit
Binding Version: org.openhab.binding.zwave-1.7.0.jar
Controller: Aeotec Z-Stick Gen5 ZW090-A (NODE 1)
Device: First Alert Smoke/Fire and CO Alarm ZCOMBO-G (NODE 2)

I have attached a TRACE of z-wave logs but can't seem to find any issues besides the log
2015-05-31 20:07:19.663 [DEBUG] [z.internal.ZWaveNetworkMonitor:287 ]- NODE 2: Initialisation NOT yet complete. Skipping heal.

I let the device on and sit for hours now hoping it would "Wakeup" (as I read battery operated devices only wakeup on certain intervals) and initialize but has been sitting there doing nothing for hours with no message of initializing.  I have sent a "Heal Network" as well but nothing seems to happen.  NODE 2 does see NODE 1 as a neighbor and vice versa.  I do see that NODE 2 is not in a "Listening Mode" but am unsure if I can force that true in anyway.

I have tried org.openhab.binding.zwave-1.8.0.jar with no success.  HABmin just shows the device in a grey state while my Z-Stick shows a green state.

If anyone has any ideas or can make more sense of the TRACE logs, it would be much appreciated!

[Chris Jackson]

If you’ve not configured the unit before, then it won’t wake up by itself. You need to manually wake the device up, while it’s in direct range of the controller (i.e. reasonably close by) - hopefully this will allow it to set up the wakeup interval.

Chris

[Brian Moy]

Thanks for the suggestion, the device is next to the Z-Stick less than 4 inches away.  I have "Included" NODE 2 and I do see that NODE 2 is trying to communicate and after failed attempts goes into deep sleep.  I can't seem to figure why it fails.  I have "Excluded" the NODE and re "Included" it as well with the same messages, but with a different NODE number now.

2015-06-02 11:28:34.259 [DEBUG] [i.p.s.IsFailedNodeMessageClass:54  ]- NODE 2: Is currently marked as healthy by the controller
2015-06-02 11:28:34.260 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = IsFailedNodeID (0x62), type = Request (0x00), payload = 02
2015-06-02 11:28:34.260 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64  ]- Recv message Message: class = IsFailedNodeID (0x62), type = Response (0x01), payload = 00
2015-06-02 11:28:34.260 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65  ]- Checking transaction complete: class=IsFailedNodeID, expected=IsFailedNodeID, cancelled=false
2015-06-02 11:28:34.260 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:68  ]-          transaction complete!
2015-06-02 11:28:34.260 [DEBUG] [b.z.i.protocol.ZWaveController:682 ]- Notifying event listeners: ZWaveTransactionCompletedEvent
2015-06-02 11:28:34.261 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
2015-06-02 11:28:34.261 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:1005]- NODE 2: Node advancer - FAILED_CHECK: Transaction complete (IsFailedNodeID:Request) success(true)
2015-06-02 11:28:34.261 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:201 ]- NODE 2: Node advancer - checking initialisation queue. Queue size 1.
2015-06-02 11:28:34.261 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:207 ]- NODE 2: Node advancer - message removed from queue. Queue size 0.
2015-06-02 11:28:34.261 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:267 ]- NODE 2: Node advancer - FAILED_CHECK: queue length(0), free to send(true)
2015-06-02 11:28:34.262 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:333 ]- NODE 2: Node advancer: loop - FAILED_CHECK try 1: stageAdvanced(false)
2015-06-02 11:28:34.262 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:860 ]- NODE 2: Node advancer - advancing to WAIT
2015-06-02 11:28:34.262 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:333 ]- NODE 2: Node advancer: loop - WAIT try 0: stageAdvanced(true)
2015-06-02 11:28:34.262 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:380 ]- NODE 2: Node advancer: WAIT - Listening=false, FrequentlyListening=false
2015-06-02 11:28:34.263 [DEBUG] [z.i.p.i.ZWaveNodeStageAdvancer:398 ]- NODE 2: Node advancer: WAIT - Still waiting!

[Abhinav Khandka]

Hi,

Any success? I am facing similar issue.

Thanks

Abhinav Khandka

[James Stembridge]

I had similar problems with a Fibaro smoke sensor.

I worked around it be performing the inclusion independently of OpenHab. So:

1. Stop openhab

2. Remove the stick

3. Perform the inclusion with the necessary button presses

4. Replace the stick

5. Start openhab

6. Wake the device using the necessary button presses

[Chris Jackson]

If the device is included (as it is here according to the log which shows the device is included and the binding is waiting) then including it again won't help. If the problem is the same as previuosly discussed then you need to wake the device up to get it to progress past this phase of the initialisation process.

Chris

[Patrik Gfeller]

Hi all,

I'm using OH 1.7.0 and also have the problem that a battery driven motion sensor is not initialized. I've added and configured the node using HomeSeer. It is configured to wake up every 6 minutes and is not in direct range of the primary.

Wakeup and simple waiting did not help ... the node remains "generic" uninitialized in HABmin; but ruprisingly motion events are recieved and do trigger the rules I've setup. Any idea how I could make it visible the OH? Did also click on the re-init button and waited 48h ... no results.

with kind regards,

Patrik

[Brian Moy]

I have since returned the ZCOMBO-G as I was unable to get it working successfully.
If anyone else has any suggestions feel free to chime in, but I have moved on.

I was able to wake the device but no data was coming through.  I saw the commands come through, but no values were being populated.

2015-06-08 21:21:49.753 [DEBUG] [.ApplicationUpdateMessageClass:44  ]- NODE 4: Application update request. Node information received.
2015-06-08 21:21:49.753 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class BASIC
2015-06-08 21:21:49.754 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class BATTERY
2015-06-08 21:21:49.754 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class BATTERY to the list of supported command classes.
2015-06-08 21:21:49.754 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class CONFIGURATION
2015-06-08 21:21:49.755 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class CONFIGURATION to the list of supported command classes.
2015-06-08 21:21:49.755 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class ASSOCIATION
2015-06-08 21:21:49.756 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class ASSOCIATION to the list of supported command classes.
2015-06-08 21:21:49.756 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class ALARM
2015-06-08 21:21:49.756 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class ALARM to the list of supported command classes.
2015-06-08 21:21:49.756 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class MANUFACTURER_SPECIFIC
2015-06-08 21:21:49.757 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class MANUFACTURER_SPECIFIC to the list of supported command classes.
2015-06-08 21:21:49.757 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class VERSION
2015-06-08 21:21:49.758 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class VERSION to the list of supported command classes.
2015-06-08 21:21:49.758 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = RequestNodeNeighborUpdate (0x48), type = Request (0x00), payload = 01
2015-06-08 21:21:49.758 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64  ]- Recv message Message: class = ApplicationUpdate (0x49), type = Request (0x00), payload = 84 04 0A 04 A1 00 20 80 70 85 71 72 86
2015-06-08 21:21:49.759 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65  ]- Checking transaction complete: class=ApplicationUpdate, expected=RequestNodeNeighborUpdate, cancelled=false
2015-06-08 21:22:18.356 [DEBUG] [z.internal.ZWaveNetworkMonitor:509 ]- NODE 1: NETWORK HEAL - UPDATENEIGHBORS
2015-06-08 21:22:18.356 [DEBUG] [NodeNeighborUpdateMessageClass:33  ]- NODE 1: Request neighbor update
2015-06-08 21:22:18.357 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ]- NODE 255: Creating empty message of class = RequestNodeNeighborUpdate (0x48), type = Request (0x00)
2015-06-08 21:22:18.357 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:22:18.357 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:22:18.358 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:22:18.358 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:22:23.360 [ERROR] [WaveController$ZWaveSendThread:1356]- NODE 255: Timeout while sending message. Requeueing - 2 attempts left!
2015-06-08 21:22:23.360 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:22:23.360 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:22:23.361 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:22:23.361 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:22:28.362 [ERROR] [WaveController$ZWaveSendThread:1356]- NODE 255: Timeout while sending message. Requeueing - 1 attempts left!
2015-06-08 21:22:28.362 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:22:28.363 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:22:28.363 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:22:28.363 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:22:33.365 [ERROR] [WaveController$ZWaveSendThread:1356]- NODE 255: Timeout while sending message. Requeueing - 0 attempts left!
2015-06-08 21:22:33.365 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:22:33.365 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:22:33.366 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:22:33.366 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:22:38.367 [WARN ] [WaveController$ZWaveSendThread:1365]- NODE 255: Too many retries. Discarding message: Message: class = RequestNodeNeighborUpdate (0x48), type = Request (0x00), payload = 01
2015-06-08 21:23:48.362 [DEBUG] [z.internal.ZWaveNetworkMonitor:509 ]- NODE 1: NETWORK HEAL - UPDATENEIGHBORS
2015-06-08 21:23:48.362 [DEBUG] [NodeNeighborUpdateMessageClass:33  ]- NODE 1: Request neighbor update
2015-06-08 21:23:48.363 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ]- NODE 255: Creating empty message of class = RequestNodeNeighborUpdate (0x48), type = Request (0x00)
2015-06-08 21:23:48.364 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:23:48.364 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:23:48.365 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:23:48.365 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:23:53.367 [ERROR] [WaveController$ZWaveSendThread:1356]- NODE 255: Timeout while sending message. Requeueing - 2 attempts left!
2015-06-08 21:23:53.367 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:23:53.367 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:23:53.368 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:23:53.368 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:23:58.370 [ERROR] [WaveController$ZWaveSendThread:1356]- NODE 255: Timeout while sending message. Requeueing - 1 attempts left!
2015-06-08 21:23:58.370 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:23:58.370 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:23:58.371 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:23:58.372 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:24:01.908 [DEBUG] [.z.internal.ZWaveActiveBinding:192 ]- NODE 4: Polling list: item KT_FIRE is not completed initialisation
2015-06-08 21:24:01.933 [DEBUG] [.z.internal.ZWaveActiveBinding:192 ]- NODE 2: Polling list: item HW_BATT is not completed initialisation
2015-06-08 21:24:01.934 [DEBUG] [.z.internal.ZWaveActiveBinding:192 ]- NODE 4: Polling list: item KT_FIRE is not completed initialisation
2015-06-08 21:24:01.935 [DEBUG] [.z.internal.ZWaveActiveBinding:192 ]- NODE 2: Polling list: item HW_BATT is not completed initialisation
2015-06-08 21:24:03.373 [ERROR] [WaveController$ZWaveSendThread:1356]- NODE 255: Timeout while sending message. Requeueing - 0 attempts left!
2015-06-08 21:24:03.373 [DEBUG] [b.z.i.protocol.ZWaveController:667 ]- Enqueueing message. Queue length = 1
2015-06-08 21:24:03.373 [DEBUG] [WaveController$ZWaveSendThread:1258]- Took message from queue for sending. Queue length = 0
2015-06-08 21:24:03.374 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 04 00 48 01 B2
2015-06-08 21:24:03.374 [DEBUG] [WaveController$ZWaveSendThread:1315]- NODE 255: Sending REQUEST Message = 01 04 00 48 01 B2
2015-06-08 21:24:08.377 [WARN ] [WaveController$ZWaveSendThread:1365]- NODE 255: Too many retries. Discarding message: Message: class = RequestNodeNeighborUpdate (0x48), type = Request (0x00), payload = 01
2015-06-08 21:24:09.929 [DEBUG] [.z.internal.ZWaveActiveBinding:192 ]- NODE 4: Polling list: item KT_FIRE is not completed initialisation
2015-06-08 21:24:09.946 [DEBUG] [.z.internal.ZWaveActiveBinding:192 ]- NODE 2: Polling list: item HW_BATT is not completed initialisation
2015-06-08 21:24:09.947 [DEBUG] [.z.internal.ZW

[Brant Fischer]

I am still having the same issues with the ZCOMBO and ZSMOKE devices as described above. they wont wake up at all. I've included and re-included them dozens of times, pressed the button hundreds of times. I moved the stack of them next to the zstick and waited. Its been months and nothing comes through. I unfortunately am too far gone from being able to return them to the store. They work fine as smoke detectors, but I really want to make them work in Openhab.

On Thursday, June 11, 2015 at 11:27:52 AM UTC-4, Brian Moy wrote:

I have since returned the ZCOMBO-G as I was unable to get it working successfully.
If anyone else has any suggestions feel free to chime in, but I have moved on.

I was able to wake the device but no data was coming through.  I saw the commands come through, but no values were being populated.

2015-06-08 21:21:49.753 [DEBUG] [.ApplicationUpdateMessageClass:44  ]- NODE 4: Application update request. Node information received.
2015-06-08 21:21:49.753 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class BASIC
2015-06-08 21:21:49.754 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class BATTERY
2015-06-08 21:21:49.754 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class BATTERY to the list of supported command classes.
2015-06-08 21:21:49.754 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class CONFIGURATION
2015-06-08 21:21:49.755 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class CONFIGURATION to the list of supported command classes.
2015-06-08 21:21:49.755 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class ASSOCIATION
2015-06-08 21:21:49.756 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class ASSOCIATION to the list of supported command classes.
2015-06-08 21:21:49.756 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class ALARM
2015-06-08 21:21:49.756 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class ALARM to the list of supported command classes.
2015-06-08 21:21:49.756 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class MANUFACTURER_SPECIFIC
2015-06-08 21:21:49.757 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class MANUFACTURER_SPECIFIC to the list of supported command classes.
2015-06-08 21:21:49.757 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 4: Creating new instance of command class VERSION
2015-06-08 21:21:49.758 [DEBUG] [.z.internal.protocol.ZWaveNode:523 ]- NODE 4: Adding command class VERSION to the list of supported command classes.
2015-06-08 21:21:49.758 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = RequestNodeNeighborUpdate

...

[Hugo Donis]

Chris, 

I'm not sure if this will help, but i attempted to add some of these Zcombo detectors to OpenHab on a RasberryPi using a Razberry Z-Wave card and was unable to get them to work either. So i then tried using the Z-Way software that came with the Razberry card and It also failed.

The interesting thing is that it got about 75% through the initialization process (there are progress indicators on the Z-Way software) before the device went back into deep sleep. As far as i can tell the device only stays awake for about 15 seconds before it goes back to sleep. 

How long a period does Habmin need in order to properly initialize a device and all the command classes it supports? Is there a way to add the node.xml file for this device manually in order to speed up the initialization process by reducing the amount of information it needs?

I have over 40 devices on my network, with a number of those containing energy meter information, so its possible that initialization process takes longer than normal due to queuing priority. 

FYI to wake up this device. (this is the same process used to include your device in the network)

 1. Slide the battery out

 2. Press and hold the button on the from

 3. Slide the battery back in (still holding the button)

 4. Release the button after you hear the first beep

[Chris Jackson]

>
> How long a period does Habmin need in order to properly initialize a device and all the command classes it supports?

It depends - normally just a few seconds, but if the device is reacting slowly, or something is slowing it down, then it will take longer. Most of my devices will respond and complete pretty quick though.

> Is there a way to add the node.xml file for this device manually in order to speed up the initialization process by reducing the amount of information it needs?

In theory yes, but this would be very prone to error, and if you get something wrong, it could cause problems.

> I have over 40 devices on my network, with a number of those containing energy meter information, so its possible that initialization process takes longer than normal due to queuing priority.

I have a similar size network. The binding tries to prioritise traffic. It will do all mains devices first (since they normally complete very quickly) and then move on to battery devices, which by their very nature will be unlikely to wake up at the same time as other devices.

I would make sure that you have masterControl set to true in your openhab config file. Then wake the device up again when it’s in range of the controller - if it goes back to sleep before the initialisation is complete, then wake it up again...

> FYI to wake up this device. (this is the same process used to include your device in the network)

Wow- this doesn’t sound like the most user friendly device - normally there’s a button you can press to wake a device up…

Chris

[Brant Fischer]

Chris I would be willing to send you a device to get it to work. I am willing to do this because First alert is a good safe brand who has been making detectors for many years before these automation tools were around. These are also pretty inexpensive units. I would rather trust life safety with proven brands rather than some Chinese brand which is unproven. 

there has to be some way to get this working with OpenHAB. I mean it works with the terrible IRIS system at Lowes. 

[Brian Moy]

I'm glad I am not the only one that was facing this issue.  If someone gets it working I am willing to repurchase (Amazon is pretty good about returns). 
I posted my logs above hoping that it would help, but if there is other information you need, I can dig through my logs for more information.

Seems like from the Amazon reviews, that other controllers such as Vera and Iris were able to pair with it.  Not sure why it won't work for OpenHAB though.  Thanks everyone for testing out with me.  Hopefully we can get some support on this device.

[Brant Fischer]

Yeah I am reading everywhere people have successfully got them to work with SmartThings, Vera, Homeseer, Iris. Let me know if you would like to borrow a device. Ill pay to ship it and return ship. I really don't want to jump ship on OpenHab, but at this point I cant return all my units as they are hanging in every room. I have both ZSmoke and ZCombo.

[Chris Jackson]

> On 17 Jun 2015, at 03:59, Brant Fischer <bra...@gmail.com> wrote:
>
> Chris I would be willing to send you a device to get it to work.

I guess you are in the US? Unfortunately it won’t work for me as I’m in Europe and the frequencies are different (unless I can get hold of a US stick as well!).

If someone can get a log that shows the initialisation (or partial initialisation) I’m happy to take a look, but somehow it needs to get woken up to start communications. Well, I say that - that’s how it normally works, but maybe this needs to do something else.

Has anyone tried contacting the manufacturer/supplier to see if they have anything to say? They probably won’t, but if you don’t ask, then you won’t know :) Additionally, if there’s any other information, then I’d be happy to look over it - I did a web search and didn’t find a lot unfortunately..

Chris

[Brant Fischer]

Chris I called them and no one was helpful. They would only support if I had the Iris system.

Did anyone have the logs? I really want to get this working. Yes I am in the US.

[Hugo Donis]

Chris,

I'm attaching the z-wave log file for the addition and initialization process of this device. Im using an empty Aeon Stick 2 so it is the only node in the log.

Let me know if it helps.

Hugo

On Fri, Jun 19, 2015 at 4:28 PM, Brant Fischer <bra...@gmail.com> wrote:

Chris I called them and no one was helpful. They would only support if I had the Iris system.

Did anyone have the logs? I really want to get this working. Yes I am in the US.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/TvCiIM-TeYs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/19c09af0-362a-4f81-82ce-74647d82fa20%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Chris Jackson]

Thanks Hugo,

Can you please confirm what you did - just so I know what I’m looking at.  If you woke this up once in this log, can you provide another log where you do it two or three times please?

I might have a way forward - I just want to try and confirm my understanding before I look at changes…

Cheers

Chris

You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAEVi-DwXGhiLT-g4ZU0fYBUcL6WAfOPA-pe97Zv7Rd%3DPhoJQPA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

<zwave.log>

[Chris Jackson]

Scrub that request - I know what the problem is…

The issue is caused because this device doesn’t support the wakeup command class. The binding knows it’s battery operated as it’s flagged as ‘not listening’, but as it doesn’t report the wakeup class, the binding doesn’t progress through initialisation as it doesn’t pass a certain check… 

I have a couple of ideas on how to fix this so I’ll try and get something for you to try later today if I can.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/FF5EE840-C3BD-403C-A606-CB543C376F38%40cd-jackson.com.

[Brian Moy]

Here are my logs from when I was testing back then.  I no longer have the units anymore because I returned them before the return policy expired.

Controller: Aeotec Z-Stick Gen5 ZW090-A (NODE 1)

Device: First Alert Smoke/Fire and CO Alarm ZCOMBO-G (NODE 2 and NODE 4)

Where you see the words "Node advancer" in the logs is when i manually woke the device up.  This was done by pulling the batteries, holding down the Test button as I slid the batteries back in and releasing when I heard the beep.  After that the unit flashed for a brief moment and those logs after "Node advancer" were created.

I noticed upon first wakeup the device would try to look for the .xml file but does not exist.  The xml was never automatically created for me and from my understanding is that the xml files should be created automatically.

2015-06-02 11:28:34.049 [DEBUG] [.b.z.i.p.i.ZWaveNodeSerializer:138 ]- NODE 2: Serializing from file etc\zwave\node2.xml
2015-06-02 11:28:34.049 [DEBUG] [.b.z.i.p.i.ZWaveNodeSerializer:141 ]- NODE 2: Error serializing from file: file does not exist.

I appreciate you looking into this Chris!

[Chris Jackson]

Thanks - I think this confirms what I think is wrong. I’ve already submitted a fix - once Cloudbees compiles it you can download it here (probably in an hour or two)

https://github.com/openhab/openhab/pull/2767

I noticed upon first wakeup the device would try to look for the .xml file but does not exist.  The xml was never automatically created for me and from my understanding is that the xml files should be created automatically.

It’s only generated once the initialisation completes - since the initialisation hasn’t ever completed, it won’t create the file…   Hopefully the change I’ve made will change that :)

Chris

[Brant Fischer]

Looks like there was an error compiling last night. https://github.com/openhab/openhab/pull/2767

[Chris Jackson]

Yes, it looks like builds have been failing for a while :(

Attached is a version I compiled here - change the extension to JAR…

Chris

[Hugo Donis]

Looks good now Chris.

You're the man :)

Now to figure out how to test the actual communication with the device without having to start a fire.

I've looked at other forums and they all stated that pressing the test button on the device only does a local test and doesnt actually test the z-wave functionality.

[Chris Jackson]

Did it generate the XML file in the /etc/zwave folder?

If you put the mouse over the WiFi icon in node 2 (that is grey in the image you attached) what does the tooltip say? It should really be green, so it may still not be 100%…

Note that the device doesn’t support wakeup (as far as I can tell) so this will stay 0… It’s not a good implementation for zwave, but so long as it sends the alarm when it detects smoke, I guess it’s ok…

Burning the bacon normally sets mine off :)

[Hugo Donis]

No node.xml file was generated for the device.

The ambulance eventually turned green and now says "Heal is idle"

[Chris Jackson]

Have you got a log file - I don’t think it’s 100% still…

[Hugo Donis]

Here is a screenshot of the message i recieve when i hover over the wifi symbol  next to the device.

[Hugo Donis]

Here is the latest log file.

[Chris Jackson]

As a matter of interest, what happens if you wake the device up again - don’t restart the binding, just the sensor…

[Hugo Donis]

Chris,

Here is an updated log file.

I activated the initialization process 3 times on the device.

The first 2 times i did it without telling Habmin to "Refresh Device Configuration".

The third time i asked Habmin to "Refresh Device Configuration" before activating the initialization process on the device.

Nothing seemed to change.

[Chris Jackson]

Give this a try. I’m not convinced it will help, but this will (hopefully) stop it requesting the WAKEUP class when it doesn’t exist. It probably needs more work, but give this a try and send over the log (again, wake the unit up a couple of times but don’t click the reinit button in HABmin).

Chris

[Hugo Donis]

Here is the updated log. It doesnt appear to have changed anything.

[Chris Jackson]

Thanks - I’ll take a look when I get a chance (might not be for a day or so as I’m away for work). I note that from the image, it has progressed further than it did earlier - it’s now at static values rather than getting version info… I suspect it might be the same issue with the device not responding to the wakeup so I might have to rethink how I work around this.

[Brant Fischer]

Hi Chris,

Any progress with this one?

[Chris Jackson]

No. I've been away for work (a very busy few days) - I'm back home tonight so I'll take a look as soon as I can. 

Cheers

Chris

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/375a2df2-6a8d-4333-aa43-e69618fae7bb%40googlegroups.com.

[Brant Fischer]

Hi Chris, Just checking in to see if you were able to do anymore research on this issue?

On Monday, June 1, 2015 at 6:48:06 PM UTC-4, Brian Moy wrote:

Hi,

I am having issues binding my First Alert Smoke/Fire and CO Alarm to OpenHAB.  My setup is as follows:

Server: OpenHAB 1.7.0 on Win7 64-bit
Binding Version: org.openhab.binding.zwave-1.7.0.jar

Controller: Aeotec Z-Stick Gen5 ZW090-A (NODE 1)

[Brian Moy]

Hi Chris,

Thanks for all your work.  I have re-ordered the ZCOMBO-G as I think it would be beneficial to know if my house is on fire while I'm away.  I am still stuck with it not staying awake.  Let me know if there anymore progress and what I can provide to help get this working.  Thanks!

[Brant Fischer]

Has their been any development with this issue? I really want to get this detector working.

[Chris Jackson]

Unfortunately the change that I made a few weeks back to try and fix this didn't completely work - it got over the initial hurdle, but caused another failure later in the initialisation process...  I need to rethink how to fix this...

[Jim Howard]

I have a couple of these sitting here as well if you need any testing done.  I did see on another forum that this device is not capable of receiving any commands.  If there is anything the binding is requesting from the device, it will likely fail.

my debug log on forcing a wake-up with the battery door:

osgi> 2015-07-31 20:10:41 [DEBUG] [eController$ZWaveReceiveThread:1528 ] - Receive Message = 01 10 00 49 84 02 0A 04 A1 00 20 80 70 85 71 72 86 5F
2015-07-31 20:10:41 [DEBUG] [b.z.i.protocol.ZWaveController:1210 ] - Receive queue TAKE: Length=0
2015-07-31 20:10:41 [DEBUG] [eController$ZWaveReceiveThread:1452 ] - Receive queue ADD: Length=0
2015-07-31 20:10:41 [DEBUG] [o.b.z.i.protocol.SerialMessage:233  ] - Assembled message buffer = 01 10 00 49 84 02 0A 04 A1 00 20 80 70 85 71 72 86 5F
2015-07-31 20:10:41 [DEBUG] [b.z.i.protocol.ZWaveController:1211 ] - Process Message = 01 10 00 49 84 02 0A 04 A1 00 20 80 70 85 71 72 86 5F
2015-07-31 20:10:41 [DEBUG] [b.z.i.protocol.ZWaveController:190  ] - Message: class = ApplicationUpdate (0x49), type = Request (0x00), payload = 84 02 0A 04 A1 00 20 80 70 85 71 72 86
2015-07-31 20:10:41 [DEBUG] [.ApplicationUpdateMessageClass:44   ] - NODE 2: Application update request. Node information received.
2015-07-31 20:10:41 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class BASIC
2015-07-31 20:10:42 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class BATTERY
2015-07-31 20:10:42 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class CONFIGURATION
2015-07-31 20:10:42 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class ASSOCIATION
2015-07-31 20:10:42 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class ALARM
2015-07-31 20:10:42 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class MANUFACTURER_SPECIFIC
2015-07-31 20:10:42 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224  ] - NODE 2: Creating new instance of command class VERSION
2015-07-31 20:10:42 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63   ] - Sent message Message: class = IsFailedNodeID (0x62), type = Request (0x00), payload = 02
2015-07-31 20:10:42 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64   ] - Recv message Message: class = ApplicationUpdate (0x49), type = Request (0x00), payload = 84 02 0A 04 A1 00 20 80 70 85 71 72 86
2015-07-31 20:10:42 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65   ] - Checking transaction complete: class=ApplicationUpdate, expected=IsFailedNodeID, cancelled=false

Jim

[Brant Fischer]

Just checking to see if anyone has gotten anything to work with these devices.

[Chris Jackson]

Please give this a try. I’m far from sure it will work, and it’s a bit of a hack, but let’s see. If this doesn’t move in the right direction, then I’m running short on ideas of how to support this device without breaking support for all other devices….

Delete the XML before running this and let me know how it goes… Please send a debug log no matter what happens...

Cheers
Chris

[Rich Koshak]

Do I need to be running 1.8 for this addon to work? I too have this smoke alarm and am experiencing the problem described. However, when I tried to deploy the attached snapshot on my 1.7.1 install z-wave did not come up. I didn't get the "ZWave Refresh Service has been started" message in my logs and the zwave.log file did not get anything put into it. Before I go through the work of setting up a 1.8 snapshot I wanted to see if that is necessary or I'm causing some other problem.

Thanks.

Rich

[Chris Jackson]

No - you shouldn't need to use OH runtime 1.8.

[Hugo Donis]

Chris,

I had a similar problem with the file you posted.

Maybe its got curropted somehow during the upload.  Can you repeat and I'll test it again later today.

Hugo

On Aug 19, 2015 4:13 AM, "Chris Jackson" <ch...@cd-jackson.com> wrote:

No - you shouldn't need to use OH runtime 1.8.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/TvCiIM-TeYs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/0c3c2008-3bec-4f37-939b-904f2591711c%40googlegroups.com.