First Alert ZCOMBO Working Instance?

duh, I never thought to do that. Unfortunately, I tried that for each of my smoke detector heartbeats and even though

MyAlarmHeartBeat.lastUpdate

will print out the correct time in a log entry and my MapDB store looks right when checked through the REST api,

MyAlarmHeartBeat.changedSince(now.minusHours(24))

will always return false

and

MyAlarmHeartBeat.updatedSince(now.minusHours(24))

will always return true, even when i change it to minusMinutes(1)

I just gave up and replaced both calls with:


		var currentTime = now.millis
		var beatUpdate = beat.lastUpdate.millis
		if(currentTime - beatUpdate > (((1000 * 60) * 60) * 24))
etc

Sorry for stealing the thread.

Did anyone tried to trigger the zcombo with smoke? This thread helped me get things going and I can see that smoke alarm channel getting triggered when test switch pressed but when I actually let it off using a candle smoke, there was no triggers. Did I miss something? does anyone know how to debug it?

I tested it once a long time ago and it worked. I’ve not tried testing it in OH 2 but it seems to me that if it works when you trigger the alarm test it should work with actual smoke.

But in my experience, these smoke/CO detectors are not feature rich nor reliable enough to rely upon the zwave triggers for anything. If you really need that you would better off selecting a different alarm. Lots of people love the Fibaro alarms.

Thank you for the quick reply. I was planning on using this to turn off the outlet that powers the 3d printer. I have heard enough horror stories that I dont want to leave the printer running for 24/7, unless I rig something to notify and to prevent damage. Im going to do more digging and if it is not working as it intended. I’m going to send it back. There is no value in buying zwave smoke detector if it is not triggering the zwave channel when there is a actual fire :stuck_out_tongue: . I do have a fairly new device, manufactured in may 2017. Hardware could be slightly different.

Anyone have this working in 2.3? Cannot get it to switch from ‘uninitialized’ no matter how many times I’ve performed the inclusion process

@derfNamttog Yes, I have the ZCOMBO working in both 2.3 and 2.4. For me, it included fine and was recognized as the “ZCOMBO Smoke and Carbon Monoxide Alarm”. I’m curious if (a) you ever got your ZCOMBO to initialize and work normally, and (b) if you tried excluding the ZCOMBO from your ZWAVE network and then retried the include?

To elaborate on it “working”, I have the 4 switches (smoke, CO2, test, heartbeat), and number battery percentage. To note, the battery value did not first appear until I performed the alarm test. Apparently that woke up the device to send a report.

Perhaps I could be of more assistance if needed. Good luck. :slight_smile:

Finding this thread now since I’m in the process over move over my whole ZWave house over to OpenHAB from SmartThings after briefly touching on Home Assistant and OpenZWave.

I think I’ve tried every trick in the book but the ZCOMBO seems to get stuck on initialization. I’ve tried excluding and including it probably 20 times now. I’ve tried waking it up with the battery-out-button-down-battery-in method outside of the inclusion window but the zwave log keeps saying it’s either stuck in state MANUFACTURING or NIF_FRAME as seen below. Any ideas here?

This is after I wake up the ZCOMBO but outside of the include window:

04:06:40.230 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 49 84 50 0A 04 A1 00 20 80 70 85 71 72 86 0D
04:06:40.231 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=80, callback=132, payload=84 50 0A 04 A1 00 20 80 70 85 71 72 86
04:06:40.232 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=80, callback=132, payload=84 50 0A 04 A1 00 20 80 70 85 71 72 86
04:06:40.233 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction null
04:06:40.234 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
04:06:40.235 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Last transaction: null
04:06:40.236 [DEBUG] [ave.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=80, callback=132, payload=84 50 0A 04 A1 00 20 80 70 85 71 72 86
04:06:40.236 [DEBUG] [message.ApplicationUpdateMessageClass] - NODE 80: Application update request. Node information received. Transaction null
04:06:40.237 [DEBUG] [message.ApplicationUpdateMessageClass] - NODE 80: Application update - no transaction.
04:06:40.238 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
04:06:40.239 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
04:06:40.488 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: Is awake with 1 messages in the queue
04:06:40.489 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: COMMAND_CLASS_WAKE_UP not found - setting AWAKE
04:06:40.490 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: Start sleep timer at 2500ms
04:06:40.491 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 80: Got an event from Z-Wave network: ZWaveNodeStatusEvent
04:06:40.493 [DEBUG] [ave.internal.protocol.ZWaveController] - NODE 80: Node Status event - Node is AWAKE
04:06:40.493 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zwave:device:168ea7b4898:node80' has been updated.
04:06:41.741 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: WakeupTimerTask 1 Messages waiting, state MANUFACTURER
04:06:42.991 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: WakeupTimerTask 1 Messages waiting, state MANUFACTURER
04:06:42.992 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 80: No more messages, go back to sleep

I just went through this about a month ago.

I woke the unit up over and over and over again, usually about 20 times each time I tried, for a week to no avail. I would wait about a minute between each wake before trying again.

Eventually, I decided to watch the log update live, using tail, and just wake the unit over and over as fast as I could instead of waiting between wakes. Using this method I could see the unit advancing through the intialization in the log. I think it would take between 5-10 rapid fire wakes to get through each phase of initialization.

I don’t know if it’s the proper way to do it but it’s the only way I could get both my units working. Just be careful not to break off the battery door. :wink:

:+1:

Well I’m almost numb trying this but I think openHAB has changed since this trick worked. I saw a discussion on the ZWave addon repository that @chris is considering updating the timeout when adding devices. My issueis that WakeupTimerTask 1 Messages is just not willing go forward past the MANUFACTURER state and it doesn’t seem like the ZCOMBO is sending messages of that type.

I have never been able to get my ZCOMBO’s to get past this stage. An updated timeout for this device would be nice.

Me too… I submitted log files to @chris’s website, but he’s been busy. Rapid wakeups did not help. I’m past the return period now and antsy to get this working, so I’ll probably hack the XML with the needed data. Could someone please provide an XML from an initialized device?

<node>
  <deviceClass>
    <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
    <genericDeviceClass>ALARM_SENSOR</genericDeviceClass>
    <specificDeviceClass>NOT_USED</specificDeviceClass>
  </deviceClass>
  <homeId>0xc639cf57</homeId>
  <nodeId>10</nodeId>
  <version>4</version>
  <manufacturer>0x138</manufacturer>
  <deviceId>0x2</deviceId>
  <deviceType>0x1</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <supportedCommandClasses>
    <entry>
      <commandClass>MANUFACTURER_SPECIFIC</commandClass>
      <manufacturerSpecificCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <initSerialNumber>false</initSerialNumber>
        <deviceManufacturer>312</deviceManufacturer>
        <deviceType>1</deviceType>
        <deviceId>2</deviceId>
      </manufacturerSpecificCommandClass>
    </entry>
    <entry>
      <commandClass>BATTERY</commandClass>
      <batteryCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <batteryLevel>96</batteryLevel>
        <batteryLow>false</batteryLow>
        <isGetSupported>true</isGetSupported>
      </batteryCommandClass>
    </entry>
    <entry>
      <commandClass>NO_OPERATION</commandClass>
      <noOperationCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
      </noOperationCommandClass>
    </entry>
    <entry>
      <commandClass>ALARM</commandClass>
      <alarmCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <alarms>
          <entry>
            <alarmType>HOME_HEALTH</alarmType>
            <alarmState>
              <alarmType>HOME_HEALTH</alarmType>
              <reportedEvents/>
              <outer-class reference="../../../.."/>
            </alarmState>
          </entry>
        </alarms>
        <v1Supported>false</v1Supported>
        <isGetSupported>true</isGetSupported>
      </alarmCommandClass>
    </entry>
    <entry>
      <commandClass>VERSION</commandClass>
      <versionCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <libraryType>LIB_SLAVE_ROUTING</libraryType>
        <protocolVersion>3.52</protocolVersion>
        <applicationVersion>0.5</applicationVersion>
      </versionCommandClass>
    </entry>
    <entry>
      <commandClass>BASIC</commandClass>
      <basicCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <isGetSupported>true</isGetSupported>
      </basicCommandClass>
    </entry>
    <entry>
      <commandClass>CONFIGURATION</commandClass>
      <configurationCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <configParameters>
          <entry>
            <int>1</int>
            <configurationParameter>
              <index>1</index>
              <size>1</size>
              <value>0</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
        </configParameters>
      </configurationCommandClass>
    </entry>
    <entry>
      <commandClass>ASSOCIATION</commandClass>
      <associationCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <maxGroups>1</maxGroups>
      </associationCommandClass>
    </entry>
  </supportedCommandClasses>
  <securedCommandClasses/>
  <associationGroups>
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <associations>
          <associationMember>
            <node>1</node>
            <endpoint>0</endpoint>
          </associationMember>
        </associations>
      </associationGroup>
    </entry>
  </associationGroups>
  <nodeNeighbors/>
  <lastSent>2018-09-11 22:29:06.273 UTC</lastSent>
  <lastReceived>2018-09-11 22:29:06.305 UTC</lastReceived>
</node>

Except for fundamental issues with the limitations of the alarms I’ve never really had any problems with these. I suppose I’ve been lucky.

The above is the node XML for one of the three which is working.

1 Like

Thank you, Rich! This is an older format, so I must be using a new binding than you are, but I was able to get it reformatted.

Did you notice that your device hasn’t communicated since September?

I’m running 2.5 M1.

Hmmmm. I’m pretty sure it is communicating. It’s showing as online right now and I have a Rule that will send me an alert if the heartbeat channel doesn’t report after a couple of days. I just checked my persistence and the last heartbeat from the device was about two minutes ago.

I just did a sampling of my other node.xml files and they all are showing a lastReceived from September. But everything is working just fine.

When I upgraded from 2.3 to 2.4 and recreated my Things in PaperUI, I did not delete the node.xml files. So perhaps these are the old ones. Looking at the dates and they do have Sept dates on them.

Wait. Grrrr. The new XML files have a different name.

OK, here it is again just in case there is something missing from the old one.

<node>
  <homeId>0xc639cf57</homeId>
  <nodeId>10</nodeId>
  <version>4</version>
  <manufacturer>0x138</manufacturer>
  <deviceId>0x2</deviceId>
  <deviceType>0x1</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_BASIC</commandClass>
    <commandClass>COMMAND_CLASS_BATTERY</commandClass>
    <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_ALARM</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
        <associations>
          <associationMember>
            <node>1</node>
          </associationMember>
        </associations>
      </associationGroup>
    </entry>
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SENSOR_ALARM</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_NOT_USED</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <libraryType>LIB_SLAVE_ROUTING</libraryType>
              <protocolVersion>3.52</protocolVersion>
              <applicationVersion>0.5</applicationVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BATTERY</commandClass>
            <COMMAND__CLASS__BATTERY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <batteryLevel>100</batteryLevel>
              <batteryLow>false</batteryLow>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BATTERY>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>312</deviceManufacturer>
              <deviceType>1</deviceType>
              <deviceId>2</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <maxGroups>1</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ALARM</commandClass>
            <COMMAND__CLASS__ALARM>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <alarms>
                <entry>
                  <alarmType>HOME_HEALTH</alarmType>
                  <alarmState>
                    <alarmType>HOME_HEALTH</alarmType>
                    <reportedEvents/>
                    <outer-class reference="../../../.."/>
                  </alarmState>
                </entry>
                <entry>
                  <alarmType>SMOKE</alarmType>
                  <alarmState>
                    <alarmType>SMOKE</alarmType>
                    <reportedEvents/>
                    <outer-class reference="../../../.."/>
                  </alarmState>
                </entry>
              </alarms>
              <v1Supported>false</v1Supported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__ALARM>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
            <COMMAND__CLASS__CONFIGURATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <configParameters>
                <entry>
                  <int>1</int>
                  <configurationParameter>
                    <index>1</index>
                    <size>1</size>
                    <value>0</value>
                    <readOnly>false</readOnly>
                    <writeOnly>false</writeOnly>
                  </configurationParameter>
                </entry>
              </configParameters>
            </COMMAND__CLASS__CONFIGURATION>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>
  <lastReceived>2018-09-22 21:30:10.297 UTC</lastReceived>
</node>

Sorry for the confusion.

1 Like

Data point:
I could not pair my two Z-COMBOs last month and I think I tried 2.4, 2.5.0.M1, and 2.5.SNAPSHOT. My fingers were raw trying to pair them and wake them up during the various init stages. They were both seen as devices but stuck as “Unknown” and could not make it past an early init state.

Today I paired that same two using SNAPSHOT #1561 and it was flawless. One try for both and they are working great.

1 Like

Sorry to bump this but new user here … I just factory reset a bunch of ZCombo units that were connected to SmartThings for long time, HomeSeer more recently - worked fine on those platforms. I’m trying to add them to OpenHab and no luck … is there a trick that works? I have added other devices so far (all z-wave) without much challenge but these have me stumped … thanks! I’m on latest stable installed this morning FYI.

1 Like

FYI - the spec is published here: