Zooz ZSE70 Outdoor Motion Sensor

Is there any consideration for adding the Zooz ZSE70 Outdoor Motion Sensor to the Z-wave binding database?

  • It is one of the few outdoor rated sensors
  • It supports motion, temperature and lux

openHAB documentation > Things Summary - ZWave | openHAB (currently not supported)
Zooz support documentation > ZSE70 Outdoor Motion Sensor - Zooz Support Center

My current openHAB installation:

  • Raspberry Pi 4, 4GB RAM
  • AEOTEC Z-Stick Gen5 Z-Wave Plus
  • openHAB 4.3.0, Release Build
  • 46 Z-Wave binding things being managed

Welcome to the OH community.

Adding devices to the zwave binding is a community function. Having the device is required to obtain the information necessary to update the database. Some guidance Guidance for “unknown” Zwave Device - Tutorials & Examples / Solutions - openHAB Community. A link to the DB blog is included.

Thank you for the quick response and guidance!

I have the device, it has been included by the Z-wave stick

  1. I have located the XML file in the userdata/zwave folder:
    a) manufacturer>0x27a
    b) deviceId>0x6
    c) deviceType>0x4

  2. The device is not in the ZW DB, but there are other Zooz sensors

  3. I just ran the openHABian Configuration Tool to ensure my systems is up-to-date openHAB 4.3.0

  4. I reviewed the ZW DB Blog, but feel I am not technically qualified to add the device
    a) I attempted to register as a user at > https://www.opensmarthouse.org/user/register.php, but got the error “File not found.”

Due you have a recommendation for next steps?

Good start ! There was a DoS issue with the ZW DB. try the link in this post Opensmarthouse Database Registration Down - Off-Topic - openHAB Community

Everyone feels like they aren’t qualified, but with the XML and the manual it is not hard. The final entry is reviewed by the developer anyway for major errors.

Outstanding, I’ll give it a try!
Thank you.

I gained edit access to the Opensmarthouse Z-Wave Device Database and began the process of creating a device (i.e. Zooz ZSE70).

Thank you (again)!

No problem. Don’t forget the parameters and association groups. After you clear the errors, in the post above there is a method to add the db xml to your current binding. Good luck

In the OpenSmartHouse database the Zooz ZSE70 device was approved on 2025-01-01, also showing OH-SNAPSHOT.

I have looked for an openHAB 4.3 snapshot but cannot find one. Therefore, will this device only be available in openHAB 5.0?

It is noted that openHAB 5.0 requires Java 21. My current system is on a Raspberry Pi, openHAB 4.3.3, with openjdk version 17.0.13.

Can the current OH-SNAPSHOT be installed on openHAB 4.3.3?

By the way, there are several Zooz devices in the OpenSmartHouse database that have been “approved” back to 2022 but still indicate only available in OH-SNAPSHOT.

A couple of notes.

  1. As far as I can tell the ZWave DB binding updates have not been included in any OH4.3 patch release, just the 5.0 snapshots.
  2. the ZSE70 can be added to your current Zwave jar using this procedure. Some have also been able to add the XML with a compressed file editor (without all the java manipulation).
  3. The current OH5.0 snapshot won’t work in OH4.3.3. There are checks in OH that will kick out an error.
  4. The OH-SNAPHOT designation in the ZW DB has little meaning. The date rules. All devices with dates prior to about 12-16-2024 are in OH4.3.3, but as noted above, none after.

Hello! Just installed OH 5.0.0 and was happy to see this device appear in the database (that is, the Thing in my Inbox now has identification information beyond “unknown device”).

So I added it and proceeded to configure it. I discovered a problem:

The motion sensor only successfully reports when motion STOPS, not when it STARTS

I captured some debug output, shown here:

2025-07-24 19:58:34.995 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 78: Application Command Request (ALIVE:DYNAMIC_VALUES)
2025-07-24 19:58:34.995 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 78: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2025-07-24 19:58:34.995 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 78: SECURITY NOT required on COMMAND_CLASS_ALARM
2025-07-24 19:58:34.995 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 78: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2025-07-24 19:58:34.996 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 78: NOTIFICATION report - 0 = 0, event=8, status=255, plen=0
2025-07-24 19:58:34.996 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 78: Alarm Type = BURGLAR (0)
2025-07-24 19:58:34.996 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2025-07-24 19:58:34.996 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2025-07-24 19:58:34.996 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter processing NOTIFICATION
2025-07-24 19:58:34.997 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter NOTIFICATION event is 8, type OnOffType
2025-07-24 19:58:34.997 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter processing NOTIFICATION
2025-07-24 19:58:34.997 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter NOTIFICATION event is 8, type OnOffType
2025-07-24 19:58:34.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 78: Commands processed 1.
2025-07-24 19:58:34.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 78: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1dae478f.
2025-07-24 19:59:12.786 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 78: Application Command Request (ALIVE:DYNAMIC_VALUES)
2025-07-24 19:59:12.787 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 78: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2025-07-24 19:59:12.787 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 78: SECURITY NOT required on COMMAND_CLASS_ALARM
2025-07-24 19:59:12.787 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 78: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2025-07-24 19:59:12.787 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 78: NOTIFICATION report - 0 = 0, event=0, status=255, plen=1
2025-07-24 19:59:12.788 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 78: Alarm Type = BURGLAR (0)
2025-07-24 19:59:12.788 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2025-07-24 19:59:12.788 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2025-07-24 19:59:12.788 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter processing NOTIFICATION
2025-07-24 19:59:12.789 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter NOTIFICATION event is 0, type OnOffType
2025-07-24 19:59:12.789 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Updating channel state zwave:device:d343fb06:node78:alarm_burglar to OFF [OnOffType]
2025-07-24 19:59:12.789 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter processing NOTIFICATION
2025-07-24 19:59:12.790 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 78: Alarm converter NOTIFICATION event is 0, type OnOffType
2025-07-24 19:59:12.790 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 78: Commands processed 1.
2025-07-24 19:59:12.790 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 78: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6cd02d81.
2025-07-24 19:59:12.791 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Driveway_Perimeter_Node_078_Motion_Alarm' changed from NULL to OFF

And then I looked around for similar errors. I discovered a few posts which seem relevant:

  1. A similar set of symptoms for an older motion sensor from the same manufacturer, Zooz. Zooz ZSE02 motion sensor not working Although this was 2018, and the OP gave up, it is likely that the fix for my problem will also work for the ZSE02.
  2. A similar set of symptoms for an entirely different motion sensor, with a fix as well: Steinel MotionSwitchLED, Alarm converter NOTIFICATION event

I looked through the debugging messages I printed above, and discovered that when motion STARTS, the device sends a “burglar” alarm notification with value 8. However, the code for converting a burglar alarm doesn’t understand the value 8. But I did notice that the code for handling a “motion alarm” does handle the value 8. Unfortunately, the code doesn’t actually check to see if the notification value (8 in this case) is a legitimate value for the specified channel_type. It simply returns whatever it get()'s from the Hashmap, even if the value is null. I could maybe add a debug statement here as an assistance to users who end up using a device configured with the incorrect type. But I’ve definitely never pulled down the OH code and I don’t have any kind of test bench!

Alas, this device is in the database as a “alarm_burglar” type. Note: I modified the opensmarthouse.org database definition to change it to alarm_motion but I’m honestly not sure that I did this properly. I plan to try to modify the XML locally to confirm that I’m on the right track, and will post an update when possible.

Any thoughts on the above, both my suggestion for the ZSE70, as well as the suggestion for the ZSE02 too?

Thanks!

I modified the XML locally, based loosely on the instructions linked above. However, the XML format that the opensmarthouse website exported was rather different than the XML format which I discovered in my 5.0.0 org.openhab.binding.zwave-5.0.0.jar file. It could be due to copy/pasting from the dialog box (the website shows the XML file but doesn’t download the file, so the HTML in the dialog box is rendered, whereas the XML file contains unrendered <br> and <p> and other HTML tags).

So, instead of slapping in the exported XML from the database website, I hand-poked the XML file and here are my changes shown in a unified diff format:

1059 ~/git/openhab-local/xml/zse70-mods-202507/OH-INF/thing/zooz (main)$ diff -w -u z*
--- zse70_0_0.ORIG.xml	2025-07-25 00:58:43.698582157 -0400
+++ zse70_0_0.xml	2025-07-25 01:01:25.326892396 -0400
@@ -26,16 +26,16 @@
           <property name="binding:*:DecimalType">COMMAND_CLASS_SENSOR_MULTILEVEL;type=LUMINANCE</property>
         </properties>
       </channel>
-      <channel id="alarm_burglar" typeId="alarm_burglar">
-        <label>Alarm (burglar)</label>
+      <channel id="alarm_motion" typeId="alarm_motion">
+        <label>Alarm (motion)</label>
         <properties>
           <property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=BURGLAR</property>
         </properties>
       </channel>
-      <channel id="alarm_power" typeId="alarm_power">
-        <label>Alarm (power)</label>
+      <channel id="alarm_tamper" typeId="alarm_tamper">
+        <label>Alarm (tamper)</label>
         <properties>
-          <property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=POWER_MANAGEMENT</property>
+          <property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=BURGLAR</property>
         </properties>
       </channel>
       <channel id="battery-level" typeId="system.battery-level">

I am happy to report that after installing it with steps like these, and then Removing my Thing, and Re-Scanning/Adding it from the ZWave binding inbox, the motion detection works!!

Example steps, but see the aforementioned post for more details:

% jar uvf org.openhab.binding.zwave-5.0.0.jar OH-INF/thing/zooz/zse70_0_0.xml
adding: OH-INF/thing/zooz/zse70_0_0.xml(in = 9831) (out= 2585)(deflated 73%)
% sudo openhab-cli console
openhab> bundle:list | grep ZWave
280 │ Active │  80 │ 5.0.0                 │ openHAB Add-ons :: Bundles :: ZWave Binding
openhab> bundle:update 280 file:///home/rbrown/git/openhab-local/xml/zse70-mods-202507/org.openhab.binding.zwave-5.0.0.jar

For what it’s worth, I modified the XSE70’s “power” alarm to accurately be a “tamper” alarm as per the ZOOZ website FAQ. I tried shaking the device, but this didn’t trigger the tamper alarm. I have no experience with tamper alarms though, so I don’t know if I did anything good or bad here.

p.s. I looked also at the ZSE02 database entry, and it seems correct as of now, i.e. it’s using alarm_motion as the type, rather than alarm_burglar. so maybe that’s been fixed at some point since 2018.

1 Like

I had opened a ticket for the developer on the ZW database some time ago to provide additional guidance on the notification/alarm channels.
alarm-channel-mapping2.pdf (525.3 KB)

With a community driven entries, the channel names may sound right, but don’t match what the device sends and the binding maps them to. It also explains the only “OFF” symptom which is a ‘tell’ that it is the channel is wrong.

I wouldn’t worry about the tamper. You should see a 3 in the debug, along with the 8 (I do not see how to trigger the tamper without triggering the motion- except maybe an earthquake). However the tamper only is active for a few seconds and because they are on the same BURGLAR both will be cleared quickly

1 Like

I’m also having this problem, using the 5.0.1 docker image. Since I’m lazy, will this fix be included in a release soon? It looks like there’s a 5.1.0-snapshot docker image as of a few hours ago.

Based on my reading of the dates it should be in 5.0.1. You may need to delete the thing using the UI (do not exclude it) and then go to inbox/zwave/scan to pick it up with the new properties.

Looks like it’s not in 5.0.1. I’m still not getting motion (or burglar) alarms, and digging into zse70_0_0.xml shows it still has:

<channel id="alarm_burglar" typeId="alarm_burglar">
 <label>Alarm (burglar)</label>
 <properties>
  <property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=BURGLAR</property>
 </properties>
</channel>

Are “snapshots” reasonably safe? I think I’ll try 5.1.0-snapshot, unless you say otherwise.

I guess it wasn’t picked up by the updated release. Snapshot should be fine. If that doesn’t work you could bundle:update from the Zwave Jenkins openHAB-ZWave - Jenkins

The 5.1.0-snapshot docker image did the trick. Thanks!

1 Like

Today, I installed WIN 5.1.0.M1 and can confirm that the Zooz ZSE70 is correctly configured as a thing.

I needed to change the following in the thing configuration:
2: Motion Clear Time = 240 (default was 30) - I trigger lights and wanted them to stay on longer.
13: Threshold for Lux = 10 (default was 50) - I trigger lights and want them to come on/off with finer control.

“Thank you” to everyone who has contributed to making this device work. Job well done!