Ecolink Tilt-zwave2 No longer working

@apella12 Success! I followed the instructions above, adding the “feature:install …” step. “Remove device from controller” did not remove the sensor Thing - I did a “Delete Thing”. I scanned and added the sensor - it appears as the original node and all existing channels/items/links are already there. The tilt test was successful - I could see the Binary Sensor/Door State (Deprecated) change as expected. I am going to repeat the procedure for the second sensor and then update the instructions above.

I left Parameter 2 as 0x00 - is there any point changing it to 255 and testing again? I have sent an email to Ecolink Support for the detailed TILT-WAVE2 sensor to see if that helps clarify how the v2 tilt sensor should be defineed in the device database.

Thanks for your help!

2022-06-02 15:04:39.157 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 FF 39
2022-06-02 15:04:39.161 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 15:04:39.163 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 15:04:39.168 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 15:04:39.169 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 15:04:39.170 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 15:04:39.171 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 15:04:39.172 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 15:04:39.173 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 15:04:39.173 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=255
2022-06-02 15:04:39.174 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 15:04:39.175 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=255
2022-06-02 15:04:39.176 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to OPEN [OpenClosedType]
2022-06-02 15:04:39.177 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 15:04:39.178 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1956688.
2022-06-02 15:04:39.180 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:39.180 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:39.181 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 15:04:39.182 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 15:04:55.638 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 00 C6
2022-06-02 15:04:55.641 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 15:04:55.643 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 15:04:55.644 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 15:04:55.645 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 15:04:55.646 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 15:04:55.647 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 15:04:55.648 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 15:04:55.649 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 15:04:55.650 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=0
2022-06-02 15:04:55.651 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 15:04:55.651 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=0
2022-06-02 15:04:55.652 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to CLOSED [OpenClosedType]
2022-06-02 15:04:55.654 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 15:04:55.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1bf71d9.
2022-06-02 15:04:55.657 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:55.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 15:04:55.661 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 15:04:55.662 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Great !

  1. Should cut myself off from responding late at night. Anyway “Delete thing” is correct to pick up the new XML. “remove device from controller” will never really work for a battery device.
  1. For the sake of science I would be interested in the Debug log from that test for comparison. I’m puzzled by why ECO would have a that parameter. I still have a remote hope it will send a notification instead and a test would put that to rest.

Anyway you have a working zwave binding that can be used until we get the DB figured out.

Bob

@apella12 I updated oarameter 2 to 255

openhabian@openhabian:/var/log/openhab $ grep "Configuration update set config_2_1" zwave.log
2022-06-02 16:44:49.556 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set config_2_1 to 255 (BigDecimal)

Here is the log from a door open/close. I am not sure what I am looking for, but it looks the same as the Parameter 2=0 log.

2022-06-02 16:52:02.849 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 FF 39
2022-06-02 16:52:02.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 16:52:02.856 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 FF
2022-06-02 16:52:02.857 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 16:52:02.858 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 16:52:02.858 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 16:52:02.859 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 16:52:02.860 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:52:02.861 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 16:52:02.862 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=255
2022-06-02 16:52:02.864 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 16:52:02.865 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=255
2022-06-02 16:52:02.866 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to OPEN [OpenClosedType]
2022-06-02 16:52:02.867 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 16:52:02.868 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1f26622.
2022-06-02 16:52:02.869 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:02.870 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:02.871 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 16:52:02.872 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 16:52:24.480 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 04 03 30 03 00 C6
2022-06-02 16:52:24.483 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 16:52:24.486 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 03 30 03 00
2022-06-02 16:52:24.487 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-06-02 16:52:24.488 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2022-06-02 16:52:24.489 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2022-06-02 16:52:24.490 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 16:52:24.491 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:52:24.492 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT
2022-06-02 16:52:24.493 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Sensor Binary report, type=Unknown, value=0
2022-06-02 16:52:24.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2022-06-02 16:52:24.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=0
2022-06-02 16:52:24.495 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:1f0d023507:node4:sensor_door to CLOSED [OpenClosedType]
2022-06-02 16:52:24.497 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2022-06-02 16:52:24.498 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@b26f5e.
2022-06-02 16:52:24.498 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:24.499 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-06-02 16:52:24.501 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-06-02 16:52:24.502 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 16:55:04.783 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling...
2022-06-02 16:55:04.785 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling zwave:device:1f0d023507:node4:sensor_door
2022-06-02 16:55:04.787 [DEBUG] [converter.ZWaveBinarySensorConverter] - NODE 4: Generating poll message for COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2022-06-02 16:55:04.788 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 4: Creating new message for application command SENSOR_BINARY_GET
2022-06-02 16:55:04.789 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:55:04.790 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Command Class COMMAND_CLASS_SENSOR_BINARY is NOT required to be secured
2022-06-02 16:55:04.791 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling zwave:device:1f0d023507:node4:alarm_tamper
2022-06-02 16:55:04.792 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 4: Generating poll message for COMMAND_CLASS_ALARM, endpoint 0, alarm null, event null
2022-06-02 16:55:04.793 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 4: Node doesn't support get requests
2022-06-02 16:55:04.794 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling zwave:device:1f0d023507:node4:battery-level
2022-06-02 16:55:04.795 [DEBUG] [rnal.converter.ZWaveBatteryConverter] - NODE 4: Generating poll message for COMMAND_CLASS_BATTERY endpoint 0
2022-06-02 16:55:04.796 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY not supported
2022-06-02 16:55:04.797 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured
2022-06-02 16:55:04.797 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Bump transaction 43 priority from Get to Immediate
2022-06-02 16:55:04.798 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-06-02 16:55:04.799 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 43 to queue - size 6
2022-06-02 16:55:04.799 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-06-02 16:55:04.800 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Bump transaction 44 priority from Get to Immediate
2022-06-02 16:55:04.801 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Adding to device queue
2022-06-02 16:55:04.801 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Transaction already in queue - removed original
2022-06-02 16:55:04.802 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Added 44 to queue - size 6
2022-06-02 16:55:04.802 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

That it does. Thanks for that. It is an odd parameter since it appears to have no effect with either the current binding XML (that does not work either way) or the one I modified to use the Sensor binary (that works either way)

Thanks again for humoring me.
Bob

@chris I finally got through to someone at Ecolink. The tiltzwave2 is based on the 300-series Z-Wave chip, while the tiltzwave25 uses the 500-series chip. I was told this explains the differences in the command classes.

My Ecolink contact could not find a tiltzwave2 manual that listed the command classes and configuration parameters described in the tiltzwave25 manual but was able to provide the attached summary. I hope this helps clarify the tiltzwave2 sensor operation. Please let me know if you need additional information.
Garage Door Tilt Sensor Zwave 300 series.pdf (415.2 KB)

Not really. You talk about hardware versions here.

In any case, we need to know how to tell the devices apart - normally the device will report different application versions if the software is different - in fact this is a requirement for them to do this. This is what we need to know - so that we can create two different database entries for the two different firmware versions.

@chris OpenHAB reports that the tiltzwave2 sensor as manufacturerId=014A and manufacturerRef=0001:0003, which is already described at https://www.opensmarthouse.org/zwavedatabase/139. My contact at Ecolink did not say that there were two versions of this device. The change to using the ALARM class for the door state was introduced with 2.5 version of the sensor described at https://www.opensmarthouse.org/zwavedatabase/581.

@mhilbush thought database update 1373 from 2020/08/09 introduced changes to the tiltzwave2 database definition that prevented OpenHAB from properly reporting the data sensor state.

Strange - but you said earlier -:

So do I understand then that there are actually two different devices?

If so it seems we already have two versions in the database? But this thread (if I understand correctly) is about two different tilt-zwave2 responses. If there is only 1 version, then why are there two different responses?

Or is it that the database incorrectly identifies the 2 and 2.5 versions? I think a clear understanding of the different versions is still needed.

Last March (15 months ago) I posted in this thread:

  • The database is wrong. It references (and seems to rely on) the “Updated Manual” Tilt-ZWave-Plus-Manual-R1-04-021816kgs.pdf which is not for this device. The manual is for product type 4 (see bottom page 4). This discussion is about is product type 1, not product type 4.
  • I speculate that at some point TILTZWAVE2 (product type 1) was erroneously updated to reflect the characteristics from the manual for TILT-ZWAVE2.5-ECO (product type 4).

I posted this again 10 days ago in this thread. If this is not the answer to the question that keeps getting asked over and over again, sorry about that, but don’t worry; this will be my last post here. Just trying to help.

Sorry if I missed your posts - I don’t read everything here.

Please feel free to provide an update to the database if you have the solution to this issue - clearly that is the best way forward!

@chris, You replied directly to my previous posts, so I’m not sure that’s the problem. This really is my last post here because as I described above I have switched to Home Assistant. I was just trying to help out here, but I want to be clear that you should not be waiting for me to update the database, just like I explained over a year ago. Thanks for all the fish.

Without going back and re-reading everything I can’t really say why you didn’t just update the database then, or what else was outstanding. Sorry for any confusion.

[edit] looking above, you didn’t reply to my message (you wrote a new message in the thread without replying to me) so I didn’t get notified. As this was 1 week before I moved from the UK to New Zealand I was quite busy at the time :wink: - again, apologies for missing this response.

Ok, but someone needs to update the database if it’s wrong. There are 1300 or more entries and I personally can’t maintain them all - I just don’t have the bandwidth - again - sorry but this is a community and it does rely on others helping out and not just expecting me (or “someone else”) to do everything.

I don’t have this device, or the bandwidth to try and work out what versions exist, so it’s really appreciated when others can chip in :slight_smile:

I normally don’t like messing with devices I do not have, but I can make the adjustments in the DB to match the XML I provided above. It is basically a copy of the window/door 2. This was in the Documentation for both the PIR and Window/Door
eco2advanced-zwave-configuration-v2.pdf (108.2 KB)
It appears Eco used the same software for three devices. As it was tested by @nh905 and works for him I’m okay with it. However if @nh905 or @chips wants to make the changes, I will defer.

Without the device from the person that modified the entry we can’t compare devices and create a new DB entry. If the changes flush out a problem we can deal with it then because we will have an XML for comparison at that point.

OK?

Bob

I have both version 2 and 2.5 of the Ecolink Tilt Zwave sensors. I’m working on a new application and would like to get the 2 older ones working. This will be my third Openhab installation but have not done much debugging of bindings or zwave. I can troubleshoot and test if someone can guide me.

This (the 2.0 issue; 2.5 work fine- I have a pair of them) should be fixed in OH 3.3. I think @nh905 was going to write a summary once he had a chance to test.

Bob

1 Like

@bjrootes it looks like the official 3.3.0 release is now available. It should contain the correct definition for the v2 Tilt Zwave sensors but I need to uninstall the modified Z-Wave binding with the changes provided by Bob Eckhoff, upgrade, install the official Z-Wave bionding, and retest to make sure. I will try to get this done by the end of the week.

1 Like

@apella12 @chris @chips I am finally back home and just successfully upgraded to OpenHAB 3.3.0 using the following procedure:

  • shut down OpenHAB
  • backed up my existing system
  • deleted the modified Z-Wave binding /usr/share/openhab/addons/org.openhab.binding.zwave-3.2.0.jar
  • ran openhabian-config to update the operating system and OpenHAB
  • started OpenHAB and waited for it to initialize (Z-Wave devices showed as Uninitialized)
  • installed the official 3.3.0 Z-Wave binding

The Z-Wave bridge and all devices initialized without any errors, including the Tilt-zwave2 devices. All rules associated with the Z-Wave devices appear to be working.

Bob and Chris, thanks for all of your efforts to get this problem resolved.

2 Likes