Zooz ZSE11 Multisensor Manufacturer data not known

I cannot get device discovery to work properly on a new Zooz ZSE11 4-in-1 Sensor. The product page mentions specifically that it works with OpenHAB.
Here is the message I see in the log:

NODE 20: Device discovery could not resolve to a thingType! Manufacturer data not known.

I have tried excluding and reincluding the device; deleting and re-adding the device; using the “Z-Wave button” on the device to force it to wake up to send and receive info from the controller; removing the batteries and putting the back in. I discovered I was a couple minor versions behind, so I updated. I am on OpenHAB 3.3.0.

The thing entry in the Paper UI does not show anything for the manufacturer or device id. I turned on debug logging for a bit while adding the device through Paper UI’s inbox again. If it shows anything for the device id’s, I couldn’t spot it.

Is there something I can do to find or set the proper ID’s to let OpenHAB identify this device? It came with a manual showing the supported classes. Is there something I can do with that to make the device work?

I do have the device working for over a year, but I set it up with USB power. Battery devices can take several awakes, but on OH3.3 there should be only a couple as improvements were merged. Were most of your tries on the earlier version? I would need to see a Debug while waking the device. If there is no “awake” message, there could be a communication issue. How close is the device to the controller?

Bob

Thank you for the reply.

Yes, most of my attempts at forcing the device to wake were on the older version (3.1). I did try one forced wake after updating. Is that not going to be enough? It has now been sitting overnight, so with its default of a 4 hour wake cycle, it should have woken another 2-3 times, and another 2 or 3 by the time I get home from work.

The sensor is sitting not more than 5 feet from the controller. There is a little bit of a shelf between them that would interfere with line of sight, but it is only about 1/4" thick. I wouldn’t think there should be any interference with solid communication. I am using the Aeotec Z-Stick Gen5, so the inclusion process always involves me bringing the controller to the device I am including. Since this device is battery powered I figured I would just leave it on my desk until I got it configured.

I was really only using the batteries to get it set up quickly. It sounds like I might do better to locate an outlet and USB cable that will allow me to put it where I want it, exclude it on batteries and include it on wall power. I will try that this evening if I can find time (and it hasn’t magically started working :stuck_out_tongue: )

It needs to get to a certain stage before it will wake on its own. That stage is after the mfg is found, so forced waking is needed.
Bob
Edit: I would hope one wake on 3.3 would be enough. Also on the device UI page is the controller (node1) in group 1?

Ah. The device not auto-waking would ruin my plan, wouldn’t it? :stuck_out_tongue:

The controller is node 1. I am afraid I don’t know how to check if it is in group 1.

I confess my ignorance on the group question. I think you might be talking about association groups which would be in regards to device-to-device communication without involving the controller. I have not done any of those (at least not on purpose).

Group 1 is the lifeline group. The controller must be there for it to work. Other groups (2,3, etc.) are for controlling other devices based on what is going on. The ZSE11 has two groups.
Groups

also don’t include it using mains power if you intend to use it running on batteries. If you are going to use it on batteries, include it on batteries
Wake it numerous times a few minutes apart

1 Like

Thanks for the help fellas. I tried several forced wakes once I got home. That didn’t work. I gave up and excluded it as a battery device and included it as a USB powered device. It worked pretty much right away.

Are all battery-powered Z-Wave devices this troublesome, or did I just get lucky?

Prior to OH3.3 your experience was pretty typical. As mentioned above, there were zwave battery device optimizations in OH3.3 that should have helped. Several have reported one-time battery device initializations with OH3.3, but without a debug it is impossible to assess what happened. maybe you were lucky :wink:

However, if USB power is available that is a better option anyway for network performance (IMO). I have several Zooz devices all on USB.

Bob

I’ve just tried to include a ZSE11 this morning on battery power (I don’t think mains is going to work where I intend to install it). I’m running into the same issue. It’s gotten the ID, but no matter how many times I try to force wake, I don’t see any wake messages in the debug and I’m not getting an xml for the device.

Indeed, as Bob said, since the update to 3.3 I’ve had no trouble including any other battery devices.

I am wondering if the wake operation on the instructions (hold for 3 seconds) isn’t actually correct…

That is highly possible. You do need to get the “Node is Awake” message in the Debug file for things to get going. Maybe one brief push?

Bob

I’ve made some progress. There appear to have been 2 different issues going on.

  1. I wasn’t getting any messages at all from the device, let alone wake messages. ZWave log already reported that the device discovery/inclusion was complete and OH had the necessary IDs to lookup the device in the database, but I still needed to run and additional scan/inclusion sequence! After that, the device began sending messages, but OH still didn’t have the xml.

  2. The listed wake command of “hold for 3 seconds” is slightly misleading, but not wholly inaccurate. There is a significant delay while the device determines whether you are holding or multi-pressing. So the true instruction should be: hold button after 1 - 2 seconds the led will turn on solid. 3 seconds later led will begin to blink and device is awake."

Now I have the xml and communication with OH is established for all the channels…except the motion channel! Troubleshooting that now.

UPDATE: There’s something wrong with some part of the communication between the sensor and OH. The DEBUG log showed motion messages for a while. Then I changed the motion alarm timeout from the default 30s to 60s and now OH no longer gets any motion messages as far as I can tell. The notifications are properly sent out to the second association group. The sensor is properly activating the light I needed it for via that group and the timeout is the correct 60s, but the motion alarm channel does not register any of these events. As far as I can tell the other channels are working correctly with OH, I’m getting temp, lux, and humidity readings just fine (haven’t tested the burglar or binary channels).

For now, I’ll wait and see if a network heal fixes this one last issue before spending any more time on it.

After your post I noticed I had mine setup to use the binary channel to trigger a non-zwave camera (and light via rule. Do not recall if this was because of problems with the alarm motion or just what I did. Also do not recall if I played with the motion sensitivity.

Ah, yes. The binary channel does seem to be the one carrying the motion information.

I’m not the best wiz with the database, but looking at the ZSE11’s entry it looks like the motion alarm and tamper alarm channels have been placed under the Alarm command class. The xml file, on the other hand, appears to be expecting those under the binary switch class. Is this where the problem lies?

Can not answer.Not a wiz either. More of a try and see what happens kind of a person.
Sorry

This is normally the case, but sometimes devices can use other classes (especially older devices - most newer ones will use the alarm/notification class).

I don’t have the XML, but I’m wondering what you mean here? Firstly, what XML (there are 2 possible XML files - the one that OH creates, and the one the database creates)? It’s not really possible to tell what the device will send from either of these though.

Secondly though, from the database, it doesn’t even look like the device supports the binary switch command class, so I’m not sure I understand this.

Can you provide the logs please? I’d like to see what “motion messages” you are talking about - there are a few possibilities here. Did the binding actually decode these?

Note that I don’t have this device, and didn’t create the database, so am completely blind here, and it helps to provide as much information as possible :wink:

Probably not part of your normal problem-solving process, but I did trigger the device and captured via zniffer after seeing @JustinG post, just to see. I have had device working for about a year.

I highlighted the motion frame. What was somewhat strange is the notification was alarm tamper (3) not motion (8) (and I did not touch the device). 120 seconds later (per my parameter setting) the all-clear (line 4). The sensor reports (lines 5-8) are temperature and humidity.

Thanks. It would be good to see the logs as these are normally more useful for this sort of issue. While you have highlighted what you think is the motion frame, I can also see alarm reports here (aka the notification messages) so it may be that the device is sending multiple reports.

Sorry about that, I was referring to the OH created xml.

That’s interesting to learn. I was basing this assumption on the fact that this xml contained this block:

            <commandClass>COMMAND_CLASS_SENSOR_BINARY</commandClass>
            <COMMAND__CLASS__SENSOR__BINARY>
              <version>2</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <isGetSupported>true</isGetSupported>
              <types>
                <binarySensorType>TAMPER</binarySensorType>
                <binarySensorType>MOTION</binarySensorType>
              </types>
            </COMMAND__CLASS__SENSOR__BINARY>

and this block

            <commandClass>COMMAND_CLASS_ALARM</commandClass>
            <COMMAND__CLASS__ALARM>
              <version>8</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>8</versionSupported>
              <alarms>
                <entry>
                  <alarmType>BURGLAR</alarmType>
                  <alarmState>
                    <alarmType>BURGLAR</alarmType>
                    <reportedEvents/>
                    <outer-class reference="../../../.."/>
                  </alarmState>
                </entry>
              </alarms>
              <v1Supported>true</v1Supported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__ALARM>

which doesn’t really match the combination of command class and channel we see in the database:



As I said, however, I wasn’t sure if this discrepancy was meaningful in any way.

Here’s the whole OH xml file for you in case you want to see it.
node_110.xml (14.3 KB)

This section here should include all the times I had debugging on while working to get this device running. It is node 110.
zse11_inclusion.log

My ZWave network is the part of my system I have delved into the least, so I’m even more blind than you. As usual, any tid-bits you drop are eye-opening insights for me. :slightly_smiling_face:

Thanks for the log file. I’m kind of a data junkie and wanted to see how the zwave battery device changes are working in the “wild”. What was odd (compared to my testing) was that the “node is awake” message did not occur about 1 second after the second Add Node Stop message-(that takes 5 seconds to timeout), so initialization did not get started. This happened three times after a scan. I don’t know if this is device related since the original OP had a start-up issue that could be explained by this.

EDIT: So I realized the above observation is NOT an issue. The debug log doesn’t include the very first inclusion attempt. The “Node is Awake” is only created after a discovery Scan the first time (when the stage is IDENTIFY NODE). When initialization restarted the Node was already at APP_Version. The remaining mystery (from the inclusion perspective) is why the first attempt did not get further along. Prior to 3.3 the first attempt for battery devices was limited to 1 second. With 3.3 there is up to 6 seconds at the default setting, which unless a failed message takes up 5 seconds, still should be enough to almost or totally initialize most battery devices.

When the “node is awake” was finally received (maybe from a manual push?) at 11:37:06.138 the node almost fully initialized in one pass, but ran out of time (one message (200) timed out causing a 5 second delay and the cap is set at the default 10 seconds). After the next “node is awake” message at 11:47:13.176, the device finished initialization in 2.5 seconds and went to sleep. Total actual initialization activity 7 seconds. I was also pleased to see some of your other sleeping nodes were only awake for 0.5 seconds.

On unrelated and unsolicited notes :wink: Node 22 seems to have a problem and nodes 25 and 73 seem awful chatty. If you are using a percent trigger on wattage with a device that is normally off, stray reading can cause problems. I’ll leave the rest to @chris related to the alarms.

Bob