Zooz 4-in-1 sensor ==> 3-in-1?

Add-ons Bindings
1

I have a Zooz 4-in-1 sensor that has lost its ability to report motion. Temperature, luminance, and humidity get reported just fine. The device was working, then was abandoned for 4 months (Covid related), and now we are trying to get the system working again. A fresh battery was installed, the device was excluded, factory reset, and reincluded. Still can’t get motion. We changed the reporting temperature to F in the parameters, nothing else. The light on the device does not blink for motion, so I don’t think the problem is communicating back to the controller. It’s almost as if the motion detection is turned off.

Firmware is 24.16, type / ID is 2021:2101.

Any suggestions? Below you can see it reporting away - just no motion (alarm) anywhere in the log.

Running 2.5.7. This has been upgraded recently. The prior version was probably 2.5.2 or .3, not sure. I don’t think the OH version is related, but I should mention it in case it makes a difference.

image
image1166×349 80.1 KB

2

Unless there are database changes in the binding there is no need to delete from openHAB and re-discover. Once included in the network there is usually no reason to exclude & re-include. If fact if the controller does not fully exclude, you can get zombie nodes on the network.

That device was last updated 14 days ago. The recently released 2.5.8 would have the latest changes. Delete & rediscover . add the node in OH to get thiose changes.

3

Hold up… I just realized that my device with the same firmware is also not reporting motion. I may have messed something up… I’ll take a look…

1 Like
4

I’m not sure of the cause yet. I’ll come back to this tonight.

5

If there is anything I can do to help let me know. I was thinking that the device itself failed, but maybe it is related to something in OH? I don’t see anything regarding alarm/motion in the logs, but I didn’t capture the log during inclusion which might show something.

6

I spent a long time troubleshooting this yesterday and finally took the device down and it is sitting next to me. I will take another look tonight. I was hoping to find a glaring difference between the different firmware versions, but I did not see any. Resetting the association did not help. I am currently using OH 2.9 snapshot 206. In looking back through my persisence data, I do not see ANY changes. Was this ever working for you?

I have 3 of these devices with different firmware versions. I’m starting to suspect that this firmware is a dud. The others (firmware 32.2 and 17.9) are working fine. I’m thinking this firmware 24.16 is a dud and I will contact Zooz to confirm. Either way, updating the firmware to the latest version should be the solution. Contact Zooz support for the OTA firmware file and then update using the Silabs PC Controller software.

1 Like
7

I am sure this device used to work for motion on this firmware. The changes that have happened are an OH upgrade, and battery replacement after sitting idle for several months. I will ask support for the firmware.

1 Like
8

After excluding the device and including again, I am now getting…

2020-08-25 18:12:45.006 [DEBUG] [org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 180: NOTIFICATION report - 7 = 255, event=8, status=255, plen=0

… so it should be working now after it initializes. Zooz asked me to change the device in the database because the Trigger Interval is supposed to go up to 255s for the newer firmwares, along with some other updates. I’m thinking that this firmware is also limited to 60s and goes nutty after it is set higher. That is the only explanation I can think of. Zooz will know more.

1 Like
9

It is great to have such dedicated vendor support. They reach out to their engineers to get the real answer if necessary.

10

I have 2 of these devices with identical firmware. One works for motion and the other does not. I realize that one was included on the earlier OH (probably 2.5.2) and the other was included on 2.5.8. I see a difference in the XML that looks suspicious. The working device has:

                <entry>
                  <alarmType>BURGLAR</alarmType>
                  <alarmState>
                    <alarmType>BURGLAR</alarmType>
                    <reportedEvents>
                      <int>3</int>
                      <int>8</int>
                    </reportedEvents>
                    <outer-class reference="../../../.."/>
                  </alarmState>
                </entry>
                <entry>
                  <alarmType>ACCESS_CONTROL</alarmType>
                  <alarmState>
                    <alarmType>ACCESS_CONTROL</alarmType>
                    <reportedEvents/>
                    <outer-class reference="../../../.."/>
                  </alarmState>
                </entry>

The non-working device has:

              <alarms>
                <entry>
                  <alarmType>BURGLAR</alarmType>
                  <alarmState>
                    <alarmType>BURGLAR</alarmType>
                    <reportedEvents/>
                    <outer-class reference="../../../.."/>
                  </alarmState>
                </entry>

What does your working device show in this area? I’m curious about the lack of ‘reportedEvents’ in the non-working one. Your log shows the event of ‘8’ which matches what I see is missing here.

Is it possible to simply edit the XML? I doubt it - just hopeful.

11

The xml file generates should just be information reported by the device & its firmware.

It would be interesting to see if there are significant differences. Og course the neighbors would be different.

12

I happen to have a backup that I generated quite some time ago that I could compare. That XML backup also shows the reported events that are not there in the re-included XML. Either the device has gone wonky, or OH itself is doing something differently. I’m leaning towards the latter, but it’s not easy to determine who is at fault.

13

The Thing definitions have changed, so delete both Things and rediscover. If that does not help, exclude and reinclude. The binding is working fine.

14

In case anyone reads this later, we had 2 problems. The first was that the “new” battery wasn’t good. We bought a pack of CR123A’s and they appear to be weak. Batteries from a different source worked much better. When I open a new blister pack of batteries I assume they are good, so I didn’t even consider this for quite a while. The second issue was that the device is apparently near the edge of the Zwave range, so it would sometimes work and sometimes not. Prior to all this it was working reasonably well, but things got moved around a little and that also contributed. So need to get a mains powered device in between. Thanks for all the suggestions and help above.

1 Like
15

I would like to add one last comment to this as I now have the root cause of the 4-in-1 behaving as a 3-in-1 in case anyone else sees this. I was working remotely with someone on this, and it turns out that these sensors behave as 3-in-1 if you have the back off of them. The remote person removed the back to replace the battery and had not yet put the back on while we got it working. With the back off the sensor will report temperature, humidity and luminance, but it won’t report motion. The Zooz instructions say to have the back on while including. I didn’t know the back was off and the sensor was mostly working, so I didn’t think to ask about the back or even realize that it mattered. But that was it. Keep the back on and your 3-in-1 will be a 4-in-1!

1 Like
16

Perhaps add a not in the database entry. It may help others.