Rule trigger for Zooz ZSE29 sensor

I have struggled with the Zooz ZSE29 outdoor sensor because when motion is detected it does not seem to generate anything “rule trigger-able” on any of the 4 available channels/items, at least not at my level of knowledge. About 6 months ago I commented on this “feature” and fell back to using the Association group to send Basic Set commands to the light switch I wanted to turn ON in response to outdoor motion. Now I am trying to add some sophistication that would require rules and therefore need a trigger. I thought I would make one last attempt to collect possible ideas from the OpenHAB community. That’s what I am looking for here.

I ran the following test (Debug file attached below); Rpi3 running Openhab 2.4.0 with the 2.5.0.201901280820 Zwave snapshot. The last ZSE29 update was Jan 6, 2019 in the device list, so the Zwave snapshot I am using has that included. All nodes discussed below have the Controller as lifeline.

  1. Walk through kitchen triggering indoor sensor (Node 6-Elexa DMMS1) that by my rules for that time of day turn on two lights (Node 26 and Node 27). My BasicUI sitemap also confirms all these actions immediately.
  2. Open front door and walk outside to activate (Node 17 Zooz ZSE29). I observe the lights (Node 18) go on. Although the initial “Alarm report” is similar to the indoor sensor there is no follow-up actions to change the item.state, so Node 17 is not shown as triggered in BasicUI. Also since Node 18 is triggered from Node 17 it does not appear in the log or show as “ON” in BasicUI. I had tried (unsuccessfully) in the past to infer that Node 17 sensed motion by monitoring the Node 18 item.state since the lights do go on.
  3. I then walked over to the driveway to trigger my other Zooz ZSE29 (Node 19) with similar results. The lights (Node 20 switch) did go on, but with no record in the log or BasicUI, etc.
  4. I walked back through the Kitchen (additional Node 6 activity) and ended the test.

To me only trigger possibility from the log is something like “When Controller receives Alarm_Report from Node 17”, but I could not find anything like that in the documentation. Thoughts?

How are your Items configured for node 17 and 19? I’m mainly interested in the Channels used.

Always handy to have a link to the device.

Hi Scott. Thanks for responding. I don’t entirely understand, so I might be providing the wrong information. I just configured them in PaperUI. Here are the images! PS good suggestion on the link to the device listing. Will do that next time. I have tried all the channels and the all the items (except the battery ones) in a rules file to no avail


How about your associations? Group1 (lifeline) should have the controller, but do you only have node 18 and 20 in group2, or do you also have the controller in there too? If you do, then your binary sensor Items should work. Are they switches or contacts? You should be able to see your Items under Configuration> Items.

I think the alarm_burglar Channel may be misconfigured. The manual also says your device has a tamper switch, but I don’t see a Channel for it, so maybe alarm_burglar is for tamper. Do you see any events when you open the cover?

Thanks again for your thoughts. I do have the controller in both Group 1&2. The three items (binary, power, burglar) are all described as switches, although on the sitemap the default icons are different.

I did a Debug test while removing the cover and confirmed the alarm_burglar is for tamper. Interestingly, while the lights (Node 18) did go on, the log shows the alarm_burglar state as OFF. This seems backward. I also attached the Node 17 XML file. I’m not an expert, but it looks okay to me.


network_de9088fc__node_17.xml (9.8 KB)

@sihui, I see some things I’d like to change about this device, but I don’t have one and wanted to get your thoughts before making any changes.

  1. The alarm_burglar Channel is currently configured with just type=BURGLAR. I think this Channel should be changed to alarm_tamper and configured for type=BURGLAR, event=3.

  2. A new Channel should be added for alarm_motion and configured for type=BURGLAR, event=8.

  3. The BASIC reports are coming in, but the sensor_binary Channel is not updating. I’m thinking it wouldn’t hurt to try ticking Treat as Basic for this Channel.

WDYT?

To be honest, I’ve never seen any of those event=x channel definitions :sunglasses: and don’t know what that means, sorry.

I second that.

1 Like

Okay, I tried to remedy my lack of knowledge: :grinning:

1 Like

@apella12, do you think you would be able to modify a jar following these instructions and using this xml zse29_0_0.xml (4.3 KB)? If not, I can try to make some time for it. If these changes work better for you, then we can make the changes in the db. You’ll need to delete and rediscover the Thing (not the same as exclude/reinclude) to pull in the changes. Also, your Items for this device will need to be linked again, and a new one added for tamper.

Scott- Thanks for all the work. I would like to try myself at this point.

Update 1: Made it through the procedures, put everything back together and am getting a rule trigger with the motion alarm, so I marked your post as the solution. Obviously, I could not have done this without your XML file.
However, before the DB is updated I want to run a few more tests. The remaining main concern is that the ZSE29 had an integrated light brightness sensor and only turned on the lights in the Association Group 2 when dark. I want to bypass my (now working) rule that currently turns the light on anytime motion is detected to ensure others that may be using this device with the DB config are not affected (Later I will update my rule to use Astro data or data from another nearby light sensor to cover the situations when it is dark.)

A minor nit is when I tested the Tamper and Power switches they still (same as before) only update to OFF, never On (Alarm) when I tampered with the device or cut the power. This is not important to me as I don’t plan on using them, and is unchanged from the current DB configuration, so is not worth additional work, except for on principle.

1 Like

Glad it’s working! A log with motion start, motion stop, tamper start, and tamper stop would be helpful. For the devices I have, tamper does not turn off, I have the Items configured with autoupdate=false, and use ‘received update’ for rule triggers.

I’m editing this post to add the ZWave logs from my tests of the ZSE29 with your XML file and take out the log I originally posted as it was work-in-progress.

The “alarm motion” is triggered anytime motion is detected. The device has a manual adjustment for how long the alarm stays active. Mine is set for about 5 minutes. Below is a daytime test of motion activation


The “binary sensor” is uses the ZSE29’s light filter and only triggers when dark and motion (There is a manual dial on the device for “how dark” you want it to be. Below is a motion test at night.


I have my new rules set to work with the “binary sensor” since I am controlling lights (The Basic set in the Log file for the lights). However, the “alarm motion” filter might be useful for someone with a camera who wants to capture any motion day or night.

Below is a nighttime tamper test (Code 3). After triggering motion, while unscrewing/reseating the device there are several very short OFF/ON sequences that I can’t explain. Eventually I get the tamper trigger, but it goes off quickly when the tamper switch is reseated.


I think the power alarm is mostly for when the batteries are low. The only way I simulated this was by removing a battery and then reinstalling it. There is a power alarm (Code 1) briefly generated, but it is OFF, not ON, so I don’t know if that is right. When I put the battery back the device reboots.

That should close the book on this unless you want more. Thanks again. Bob

Power_Management event=1 means that power has been applied, so it should go to OFF, which is what is shown in the logs. Are you saying this device reports event=1 when the battery is removed?

There’s something I’d like to run by @chris first.

Summarizing for Chris… the issues in the OP appear to be resolved by the changes suggested in this post (not yet in the db). But the alarm_tamper and alarm_motion Channels both respond to event=0 (OFF). I don’t see a way around this, but IIRC my devices (WADWAZ and WAPIR) are setup the same way and behave differently. I haven’t checked a log or deleted Things in a long while, but I believe alarm_tamper never changes to OFF, so I have them set to autoupdate=false and use received update to trigger the rule.

Is this expected?

As a generality, a few devices do signal “events” rather than “states”. Like a motion sensor, which could signal when motion starts - but not when it stops. You can legitimately get a series of “ons” and never an “off”.

I don’t know if your device(s) are in that category.

Thank you, but nope… just the tampers never turn off, event after motion stops. But as I mentioned, it’s been a while since I last played with this.

Nope? It’s a design decision by the manufacturer … if they consider a tamper to be an event rather than a state, there will be no OFF.

Are you saying this device reports event=1 when the battery is removed?

I realized I can’t tell, but you are probably correct. I had this idea in my head that the device would send out a “dying” code 1 signal when the battery was removed. However where would the power to send this signal come from? More likely nothing is generated when the battery is removed as it happens too fast and the Code 1 is generated when the battery is replaced meaning power is restored., so the STATE update is correct as OFF. Sorry for the confusion.

I meant nope for whether my devices fall in the category of not reporting motion stopping. :slightly_smiling_face: My devices are also ALARMv2 and the ZSE29 is v4.

The issue is how the binding handles this. For this device and my proposed changes for the Channels, closing the case also turns off alarm_motion. Which I could see as a real PITA if you were up on a ladder changing the battery and had the lights go off!

Not at all. Maybe this device can also be mains powered with battery backup and when the mains power is off it would send POWER_MANAGEMENT event=0? Actually, mains power looks like event=2 (no power) and event=3 (restored), and event=0 means ‘Event inactive (push mode) / Previous Events cleared (pull mode)(V4)’.

It depends on the device. Some devices will send events when tamper is activated and again to disable it, and some don’t - likewise with motion and other alarms.

OK… I’ve added these changes into the db, but I’ll leave it for you to publish.

1 Like