Aeotec TriSensor

s4y · October 29, 2018, 9:14pm

FYI: When I woke up, I was still not allowed to reply to this thread. Hopefully it’s just a first day thing?

You’ve reached the maximum number of replies a new user can create on their first day. Please wait 5 hours before trying again.

OK. I distinctly remember seeing one version of the XML where the Lifeline section was named before the device was added to the DB, and another where it wasn’t. I’m not sure if there were other differences. It may have been different between the two sensors — I added one to my network later than the other, and it’s possible that OH hadn’t finished interrogating it — and apparently I picked the less-populated file. I should’ve just uploaded both! But if you’re confident that nothing is missing from the one I provided other than the names, SGTM.

I don’t know where to get this build (that’s why I asked how to try it, above). I’ve only been using OH for about a week . I checked the Releases page on GitHub and didn’t see anything new.

Here’s my current issue. If the sensor sees motion and debug logging is turned on, I see this in the log:

2018-10-29 09:40:26.748 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 07 09 71 05 00 00 00 FF 07 08 00 7E
2018-10-29 09:40:26.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=7, callback=0, payload=00 07 09 71 05 00 00 00 FF 07 08 00
2018-10-29 09:40:26.757 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=7, callback=0, payload=00 07 09 71 05 00 00 00 FF 07 08 00
2018-10-29 09:40:26.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-10-29 09:40:26.760 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Application Command Request (ALIVE:DONE)
2018-10-29 09:40:26.763 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: resetResendCount initComplete=true isDead=false
2018-10-29 09:40:26.765 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-10-29 09:40:26.767 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY NOT required on COMMAND_CLASS_ALARM
2018-10-29 09:40:26.769 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 7: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2018-10-29 09:40:26.771 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 7: NOTIFICATION report - 0 = 0, event=8, status=255, plen=0
2018-10-29 09:40:26.773 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 7: Alarm Type = BURGLAR (0)
2018-10-29 09:40:26.776 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-10-29 09:40:26.778 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-10-29 09:40:26.781 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 7: Alarm converter processing NOTIFICATION
2018-10-29 09:40:26.787 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 7: Alarm converter NOTIFICATION event is 8, type OnOffType
2018-10-29 09:40:26.790 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Commands processed 1.
2018-10-29 09:40:26.792 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5f9942.
2018-10-29 09:40:26.794 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

But, no events appear in /rest/events. I have items set up for each of the thing’s channels. When the motion timeout is hit, I see this in my debug log:

2018-10-29 09:40:37.760 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 07 0A 71 05 00 00 00 FF 07 00 01 08 63
2018-10-29 09:40:37.766 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=7, callback=0, payload=00 07 0A 71 05 00 00 00 FF 07 00 01 08
2018-10-29 09:40:37.770 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=7, callback=0, payload=00 07 0A 71 05 00 00 00 FF 07 00 01 08
2018-10-29 09:40:37.772 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-10-29 09:40:37.774 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Application Command Request (ALIVE:DONE)
2018-10-29 09:40:37.776 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: resetResendCount initComplete=true isDead=false
2018-10-29 09:40:37.779 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-10-29 09:40:37.781 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY NOT required on COMMAND_CLASS_ALARM
2018-10-29 09:40:37.784 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 7: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2018-10-29 09:40:37.786 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 7: NOTIFICATION report - 0 = 0, event=0, status=255, plen=1
2018-10-29 09:40:37.789 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 7: Alarm Type = BURGLAR (0)
2018-10-29 09:40:37.791 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-10-29 09:40:37.794 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-10-29 09:40:37.796 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 7: Alarm converter processing NOTIFICATION
2018-10-29 09:40:37.799 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 7: Alarm converter NOTIFICATION event is 0, type OnOffType
2018-10-29 09:40:37.801 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Updating channel state zwave:device:512:node7:alarm_burglar to OFF [OnOffType]
2018-10-29 09:40:37.807 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Commands processed 1.
2018-10-29 09:40:37.809 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@ed38f2.
2018-10-29 09:40:37.811 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

And, in /rest/events, I do see something:

data: {"topic":"smarthome/items/TriSensor1_AlarmBurglar/state","payload":"{\"type\":\"OnOff\",\"value\":\"OFF\"}","type":"ItemStateEvent"}

I only ever see OFF events, it never changes to ON. I can turn on binary sensor reporting, but I have a hunch that it would use somewhat more power than consuming the already-sent notifications. Any idea why the ON side isn’t being picked up?

chris · October 29, 2018, 9:48pm

I’ve updated the database to hopefully fix the processing of the motion sensors.

greigw · March 14, 2019, 1:35am

Should this work in openhab 2.4?

I have upgraded to this and still see no support in the Z-wave binding for ZW105?

dastrix80 · March 14, 2019, 2:12am

Id imagine you need to download the 2.5 Zwave snapshot Warren given this was added after 2.4.0 stable was released.

greigw · March 14, 2019, 4:13am

I am now running on zwave binding 2.5 but it still does not list ZW105 as a supported thing?

greigw · March 14, 2019, 4:20am

When I display the thing (in Paper UI) it says the device is not in the database?

I am definitely running the zwave 2.5 as I listed this in the Karah console and it is 2.5.

dastrix80 · March 14, 2019, 5:22am

You will need to delete your thing and readd this. This should then pick it up.

chris · March 14, 2019, 7:57am

What exactly does it say? Are there any properties shown for the device id/type. If not, have you woken the device so that the binding can interrogate it?

You only need to delete the thing if the thing type definition has changed. Since the device is not being detected, this is not needed and won’t do anything.

greigw · March 14, 2019, 11:06am

Hi Chris,

Thanks for getting back to me so quickly.

I have tried waking it up. I will take another look tomorrow to see exactly what it says.

But can you say for sure the zwave binding 2.5 supports the ZW105? I looked at the supported things and it does not list it I.e it only have the ZW100?

Warren Greig
E:greigw1968@gmail.com
M:0418 301 482

chris · March 14, 2019, 12:14pm

No - ZW105 does not seem to be in the database. As you can see above, the device that was added is the ZWA005 - I don’t know if it’s the same or not?

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/921

But the question still remains - is the device initialising, and if so, what are the device type/id. This will tell us if it is in the database or not?

Basically, there are multiple reasons for this, and to narrow it down, I would need to know exactly what is stated in PaperUI, and what the device properties are. If there are no device properties discovered, then you would need to wake it up so that they are discovered. If it’s then not in the database, it would need to be added as a new device as it would not be the same as the one that was discussed previously in this thread.

greigw · March 18, 2019, 4:12am

Hi Chris,

Sorry for the slow reply.

Here is a screenshot of the device properties

Do you need more info?

Thanks,

Warren.

chris · March 18, 2019, 7:55am

No, thanks - so from here I can tell that the device is not communicating with the controller and you need to wake it up so that the binding can interrogate it to find out what the device actually is.

greigw · March 19, 2019, 11:34am

Chris,

I have tried waking it multiple times ( many many times ).

I turned on the zwave debugging and I hope I have included the relevant log messages.

2019-03-19 22:23:33.192 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:e379148f:node3.
2019-03-19 22:23:33.210 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: MANUFACTURER not set
2019-03-19 22:23:33.211 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Controller status changed to ONLINE.
2019-03-19 22:23:33.211 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Controller is ONLINE. Starting device initialisation.
2019-03-19 22:23:33.242 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating node properties.
2019-03-19 22:23:33.252 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating node properties. MAN=2147483647
2019-03-19 22:23:33.253 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Properties synchronised
2019-03-19 22:23:33.262 [DEBUG] [ve.internal.protocol.ZWaveController] - Event listener added.
2019-03-19 22:23:33.263 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising Thing Node…
2019-03-19 22:23:33.266 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling intialised at 1800 seconds - start in 957600 milliseconds.
2019-03-19 22:23:33.266 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Device initialisation complete.

I notice in particular the message

2019-03-19 22:23:33.210 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: MANUFACTURER not set

Is this indicating that it is not recognizing the sensor at all?

Thanks,

Warren.

tandregbg · June 9, 2019, 1:26pm

Have you (and someone else) got this thing to work - mine are “unknown device”

mhilbush · June 9, 2019, 1:34pm

@tandregbg

Is this the device?
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/921

What manufacturer / device type / device id is your device reporting?

Andrew_Rowe · June 9, 2019, 2:01pm

Are these battery devices? If so, you need to wake them up, sometimes numerous times. The first time I tried this, I thought I had woken the device so many times, it must not be working. Later when I figured out what I was doing, I was actually resetting the device over and over
Figure out how to wake the device, from the instructions, and sit in front of the OpenHAB interface, start inclusion, wake the device, wait 5 mins, start inclusion, wake the device and repeat until the device pops up in OpenHAB

tandregbg · June 9, 2019, 5:01pm

Actually Habmin says;

No type/manufacturer and ID

mhilbush · June 9, 2019, 5:17pm

Then as @Andrew_Rowe suggests, you may need to wake it up multiple times for it to be fully discovered.

tandregbg · June 9, 2019, 7:34pm

now tried that 5 times… (without success)

mhilbush · June 9, 2019, 8:44pm

You can confirm that the wake up is being received by putting the zwave binding into debug mode, and watching the log when you wake up the device. If the device is sending the wake up notification, you’ll see it in the log.