New Device (I believe) Aeon Labs Door/Windows Sensor 7

Hi Matt.

I had tried the Modify Configuration Parameter... but did again, after a factory reset of the sensor (exclude, reset, add), making sure to wake the device, etc.

Here are the device details (written to the log) prior to attempting to change parameter 3:

Indigo Z-Wave Version: 2023.2.0
Node ID: 148
Model: Door/Window Sensor 7 Pro (ZWA012)
Model ID: 0102000C
Manufacturer: Aeon Labs
Manufacturer ID: 0371
Protocol Version: 7.15
Application Version: 2.02
Model Definition Version: 1
Library Type: 3
Class Name: Notification Sensor
Class Hierarchy: 04 : 07 : 01
Command Class Base: 00
Command Versions: 20v1 5Ev1 85v1 8Ev1 59v1 55v1 86v1 72v1 5Av1 87v1 73v1 80v1 9Fv1 30v1 71v1 70v1 84v2 5Bv1 6Cv1 7Av1
Encryption Status: Not Supported
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, battery, beaming, waking
Neighbors: 38, 56, 112, 115, 128, 156, 199, 200, 201, 205, 206, 209, 210, 213, 214, 215, 216, 218, 219, 220, 221
Associations: 1:[1] 2:[] 4:[] 5:[]
Config Values: 2:1 13:1 14:1 15:1

Parameter 3 is not listed among the Config Values, but that doesn't surprise me as presumably it is in its default state after the reset.

Then ... here is the result (log) when I used Modify Configuration Parameter... to read the value of parameter 3 (prior to attempting to change it):

Z-Wave retrieved parameter 3 value: 0 (size 1)

Here is the result (log) when I used Modify Configuration Parameter... to write a value of 1 to parameter 3:

Z-Wave device " TEST - Door/Window" parameter 3 changed to 1

Finally, here are the device details (written to the log) after attempting to change parameter 3 to 1:

Indigo Z-Wave Version: 2023.2.0
Node ID: 148
Model: Door/Window Sensor 7 Pro (ZWA012)
Model ID: 0102000C
Manufacturer: Aeon Labs
Manufacturer ID: 0371
Protocol Version: 7.15
Application Version: 2.02
Model Definition Version: 1
Library Type: 3
Class Name: Notification Sensor
Class Hierarchy: 04 : 07 : 01
Command Class Base: 00
Command Versions: 20v1 5Ev1 85v1 8Ev1 59v1 55v1 86v1 72v1 5Av1 87v1 73v1 80v1 9Fv1 30v1 71v1 70v1 84v2 5Bv1 6Cv1 7Av1
Encryption Status: Not Supported
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, battery, beaming, waking
Neighbors: 38, 56, 112, 115, 128, 156, 199, 200, 201, 205, 206, 209, 210, 213, 214, 215, 216, 218, 219, 220, 221
Associations: 1:[1] 2:[] 4:[] 5:[]
Config Values: 2:1 13:1 14:1 15:1

Note that the Config Values have not changed — parameter 3 is still not listed.

And then ... as I indicated above, the unit actually seems to stop working — the log shows "on" every time I move the magnet close — as if the reverse worked, but then nothing appears in the log when I move the magnet away; in addition the state remains "on" all the time in the main Indigo window (under DEVICES), no matter what I do with the magnet.

I've been in touch w/ an Aeotec support person (he has been very responsive and helpful in the past) but no luck there yet — he wanted to know whether I could tell if the parameter was changing, so I reported the same (above) to him.

When I can do so I will try to use a Windows laptop and the Aeotec diagnostic software (whatever it's called) to see if I can see and difference there.

[matt (support)]

The sync log in this case isn't relevant. Indigo only reads and logs the configuration parameters it is aware of that are in the device definition. In this case, because Aeotec added a new configuration parameter #3 (well I guess technically they moved #2 to be #3), Indigo isn't aware of it and doesn't read or log it during sync.

But based on your snippets above Indigo is able to read/modify the parameter using the manual Modify Config Parameter menu item, so I believe it is actually being changed correctly. The one thing you didn't do or show above was pressing the button to re-read the parameter (from the Modify Config Parameter window) after you set it to make sure it was indeed changed. You should be able to do that now though, presuming you haven't factory reset it again. You can then verify in the Event Log what value is read out (like you did above before you set it).

And then ... as I indicated above, the unit actually seems to stop working — the log shows "on" every time I move the magnet close — as if the reverse worked, but then nothing appears in the log when I move the magnet away; in addition the state remains "on" all the time in the main Indigo window (under DEVICES), no matter what I do with the magnet.

Turn on the debug Z-Wave logging (Interfaces->Z-Wave->Configure... menu item) and capture exactly what is being sent in the open/close cases. That will be useful information for us (and maybe for Aeotec).

Hi Matt. I used the Modify Config Parameter to read back parameter 3 as you suggested, and it says it is 1, so it appears the write was successful.

I tested more units, including more brand new, and it does seem to be consistently the case that setting parameter 3 to 1 does "sort of" reverse the magnet behavior. I say "sort of" because it reliably detects the magnet being close ("on" in the reverse mode), but almost never detects the magnet removal ("off"). I have discovered that if I move the magnet in and out enough times, I do occasionally see an "off." Even with Z-Wave debugging enabled as you suggested, I always see traffic when I move the magnet close, but I rarely see anything when I move the magnet away. It's very strange. I tried many magnet orientations, distances, and even different magnets, but still almost never an "off."

I did capture some Z-Wave debugging as you suggested, and did so long enough to capture both an "on" (works every time) and an "off" (took me ~20 attempts). Here's what I see.

Here is an "on" — this happens reliably every time I bring the magnet close:

Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 95 0A 71 05 00 00 00 FF 06 16 01 00 EE
Z-Wave Debug . . requestAlarmSensorStatus: node 149, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
Z-Wave Debug . . requestAlarmSensorStatus: typeExt 6, valueExt 22, classSubKeyExt 7100000616
Z-Wave Debug . . requestAlarmSensorStatus: defnStatusByte 255
Z-Wave received " TEST - Door/Window" status update is on

Here is an "off" — took me many attempts of moving the magnet away — something like 20 to get the following:

Z-Wave Debug RCVD requestAlarmSensorStatus: 01 0F 00 04 00 95 09 71 05 00 00 00 FF 06 17 00 F2
Z-Wave Debug . . requestAlarmSensorStatus: node 149, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
Z-Wave Debug . . requestAlarmSensorStatus: typeExt 6, valueExt 23, classSubKeyExt 7100000617
Z-Wave Debug . . requestAlarmSensorStatus: defnStatusByte 0
Z-Wave received " TEST - Door/Window" status update is off

In the majority of the magnet removal cases (move it away), when there should be an "off," there is nothing — nothing in the log nor anything in the Z-wave traffic that I can see.

For fun I tested an external magnetic dry contact switch — connecting it to the correct terminals and setting parameter 1 to 1 ("External / Dry Contact") and the results using that were flawless — every on-off is logged, etc.

The Aeotec support person suggested updating to firmware 2.03 (mine are all 2.02), and also doing some other testing, all of which while require me to dust of a Windows laptop. I will report back here if / as I learn more.

For "fun" here is an example of me moving the magnet in and out, trying to get an "off" command. I made the "off" occurrences bold in this post.

Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off

May 14, 2024 at 12:32:49 PM
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is on
Z-Wave received " TEST - Door/Window" status update is off

[matt (support)]

IMO this definitely looks like a firmware bug in the module since it is very rarely sending the corresponding OFF commands. Let us know if the firmware update fixes it.

I explained the "rare off" situation to the very helpful Aeotec tech support guy (Chris), and he just responded:

Ah, i think i know whats causing this. There is a delay to "Open" state for the tilt sensor. For this case, lets try disabling Tilt Sensor in this case.

Try setting:

Parameter 15 [1 byte] = 0

This will disable tilt and allow open/on state to trigger without any delay.

I did that, and voilà, the "off" commands now seem to be happening as they should — as reliable as the "on" commands. Woot!

I don't know whether this is something they can "fix" or work around in the firmware — I've asked (out of curiosity) — will share if I learn more.

So summing up: for the ZWA012-A02 unit, to get the reverse behavior you have to set parameter 3 to 1, and parameter 15 to 0. I believe that does it.

I agree — a bummer they moved the reverse parameter from 2 to 3 ... you guys rock so I am sure (hope) you will be able to figure something out, but at least now we know a workaround.

Thanks for all the help.

And ... the Aeotec support person said he would be submitting a request to address this in future releases.