Dome Motion Detector

This syncs & shows up as a Notification Sensor.

Code: Select all

Indigo Z-Wave Version: 2.0.111
Node ID: 44
Model: Notification Sensor
Model ID: 00030083
Manufacturer: Dome
Manufacturer ID: 021F
Protocol Version: 4.05
Application Version: 3.80
Model Definition Version: 0
Library Type: 6
Class Name: Notification Sensor
Class Hierarchy: 04 : 07 : 01
Command Class Base: 00
Command Versions: 20v1 80v1 84v2 85v1 86v1 30v1 70v1 31v7 72v1 73v1 71v1 59v1 5Av1 5Ev1
Encryption Status: Not Supported
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, battery, beaming, waking
Neighbors: - none -
Associations: 1:[1] 2:[] 3:[] 4:[]
Config Values: - none -


Am I missing something in configuring it? I really like its form factor and especially its range. While it is not outdoor rated, because it attaches with a magnet to its base, I can put the sensor itself in a baggie and have it be reasonably weather resistant. And it's talking to Indigo while being a solid 10 m away from the nearest other z-wave device!

Oh, and it reports battery status correctly.

This is what I got when I triggered Motion while running debug.

Code: Select all

   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 2C 09 71 05 00 00 00 FF 07 08 00 55
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 044, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 8, classSubKeyExt 7100000708
   Z-Wave Debug                    RCVD requestBinarySensorStatus: 01 0A 00 04 00 2C 04 30 03 FF 0C 19
   Z-Wave Debug                    . .  requestBinarySensorStatus: node 044, endpoint None, type 12, value 255
   Z-Wave Debug                    RCVD requestVarSensorStatus: 01 0C 00 04 00 2A 06 31 05 01 4A 1B C6 79

Adding that I tried the "match raw packet" condition, but what I had from the device (01 0A 00 04 00 2C 04 30 03 FF 0C 19 or similar) was not acceptable to Indigo when I click Save. Nor do I see anything in the log that looks like what's provided in Condition Dialog box's example.

DC,

Just do a packet match for 30 03 FF from that device.

30 is a Binary Alert, 03 is a Report, FF is "On" (ie motion detected).

The device, despite being new, is using both Alarm class 71 version 1 and Binary class 30 v1 - both of which are deprecated!

Peter

Thanks HowartP! (Even for the bad news.)

I just tried all of these:

Code: Select all

*30 03 FF*
*30*03*FF*
*FF*
FF


And none of them would validate in the Match Bytes field.

Sorry, forgot the hex.

0x30 0x03 0xFF

That's OK. The dialog box forgets about it too! It shows an example, but doesn't explain that it's required. I could tell I wasn't entering what Indigo needed, but I had no idea what it needed to be.

Thanks.

Here's another twist:

0x30 0x03 0xFF validates
* 0x30 0x03 0xFF * validates.
*0x30 0x03 0xFF* does not validate.

[matt (support)]

I would suggest using:

* 0x30 0x03 0xFF 0x0C *

Thank you, I'll try it. Is there an intro to this topic so I can understand what it is I'm doing here? I get that the dialog wants hex, though I'm not very conversant with it. The log dump provides numbers in one format, but the dialog box wants them in another. I don't know what the difference is, what the syntax (?) is or why spaces are so important for wild card characters.

If I knew what was required, maybe I could more easily figure out on my own why the device isn't triggering Indigo.

Matt,

Isn’t 0C 19 part of the checksum/sequence?

All my Zwave Command work has ignored the last two bytes, from memory...

Command Class Binary v1 only takes 30 03 FF parameters, as I described above.

DC, you either need to learn the Zwave Command protocol / how to interpret it - which I have done and hence why I respond to most of the Zwave threads and have 5 Zwave plugins - or just wait for our help. It’s not an easy thing to just look up the answer.


Sent from my iPhone using Tapatalk Pro

[matt (support)]

Isn’t 0C 19 part of the checksum/sequence?

For v2 of that command class (which I think must be this case) there is another byte. Only the last byte is the checksum of the entire incoming packet.

[matt (support)]

Thank you, I'll try it. Is there an intro to this topic so I can understand what it is I'm doing here? I get that the dialog wants hex, though I'm not very conversant with it. The log dump provides numbers in one format, but the dialog box wants them in another. I don't know what the difference is, what the syntax (?) is or why spaces are so important for wild card characters.

You want the format that is shown in the Event Log after you press the button from the Trigger dialog to dump the last 60 seconds of received commands. Generally you can match on the entire packet, except the last byte which is a checksum value. So if the log shows:

0.2 seconds ago from 002 - Some Device:
0x01 0x0B 0x00 0x04 0x00 0x02 0x05 0x5B 0x03 0xC3 0x80 0x03 0xEF

You could match on:

0x01 0x0B 0x00 0x04 0x00 0x02 0x05 0x5B 0x03 0xC3 0x80 0x03 *

There are shorter variations that will also match, but it is fine to just match on the entire command except the last byte.

But in DC’s first post, the log shows the device only advertises 30v1...


Sent from my iPhone using Tapatalk Pro

[matt (support)]

Yeah, it is lying. I also just encountered a new Aeotec module this weekend that mis-reported what version of a command class it supports. I think that is a common firmware buglet.

The 04 after the the node ID (2C) is the length of the packet that starts on the next byte so the 0C is included. The very last byte is always the checksum.

You want the format that is shown in the Event Log after you press the button from the Trigger dialog to dump the last 60 seconds of received commands. Generally you can match on the entire packet, except the last byte which is a checksum value. So if the log shows:

0.2 seconds ago from 002 - Some Device:
0x01 0x0B 0x00 0x04 0x00 0x02 0x05 0x5B 0x03 0xC3 0x80 0x03 0xEF

You could match on:

0x01 0x0B 0x00 0x04 0x00 0x02 0x05 0x5B 0x03 0xC3 0x80 0x03 *

Thanks. But here's the confounding thing: the log does not show those strings. It shows

Code: Select all

01 0A 00 04 00 2C 04 30 03 FF 0C 19

It's confusing because Indigo provides one thing, but wants another.