ZWave, Openhab and Door Sensor

Setup, Configuration and Use Beginners
, ,
1
  • Platform information:
    • Hardware: RPI 3+
    • OS: Rasbian
    • Java Runtime Environment: All versions were tested from 8-11, OpenJDK, Zulu
    • openHAB version: Started on Ver 3.0-Ended on Ver 2.4
  • Issue of the topic: Unable to get NAS-DS01Z Cyrus Door Window Sensor working with any version of Openhab higher than 2.4

Very simple/basic setup. I want a mechanism that turns on/off azigbee LED Light Bulb when a door opens or closes using a zwave NAS-DS01Z Cyrus Door Window Sensor. I am using a Nortek Husbzb-1 with the latest firmware as of Jan 2021.
I’ve been using Openhab since 2018, but repurposed my RPI3 for another project, and recently reinstalled Rasbian os from scratch. I did not want to use my backed up configuration, because things had changed to much in the interm. My prior Openhab version was 2.4 and it worked perfectly. The new version was Openhab 3.0.

I like Openhab3 interface, and configuring my Nortek Husbzb-1 dongle was a non-issue. The zigbee LED worked perfectly. Zwave discovery was also great, and found my door/window switch without issue.

The problem came when I tried to get any reading from the door/window. It would only report “null” for all fields. Of course I thought it was battery, or interference, or any other number of physical issues. So I corrected each one with new battery, put door/windows switch right next to RPI and Husbzb. I tried putting Husbzb on a USB Hub, and plugged in directly. Deleting and rediscovering. Verifying configurations over and over. I reinstalled Rasbian and starting from scratch again. I tried different versions of Java. I started digging into the forums and websites, trying to see if there is something I can do to correct the issue. But all I found were post of people with the same issue, and no resolution.
I finally found an old post describing the exact same issue with the NAS-DS01Z Cyrus Door Window Sensor on Openhab versions 2.5. So I just so happened to have a old image still on my hard drive from back in Jan of 2019, and loaded it up.

Of course, the first thing Openhab did was update itself to 2.51, and once again, I had the exact same symptoms. I found another post that showed how to downgrade Openhab to 2.4, and tried that…and after reboot, the Door/Switch started working!!!

I now have a working “refrigerator door” that turns the light on and off. It’s just unfortunate I had to downgrade to Openhab 2.4 to make it work. It seems this has been an unaddressed issue for quite some time.

As an aside, I did get it to work in Home Assistant as well, but hated the interface, so didn’t stick with it.

Hope this helps someone.

2

Is the device sending reports at all? What do you see in the log? If the device is sending reports, then maybe the binding isn’t decoding them. Alternatively the device might be misconfigured if it isn’t sending reports.

Apologies - I had a look at the issues list, but didn’t see this issue listed? Are you sure there is an open issue for this?

https://github.com/openhab/org.openhab.binding.zwave/search?q=DS01Z&type=issues

3

Hi Chris, Thanks for your reply! I just realized that in my post above, I said zwave when I meant zigbee,. and vice versa…I’ve corrected that in the original post, but the issue still remains on higher versions of OpenHab. As to your requests, I don’t have logs of the NAS-DS01Z Cyrus Door Window Sensor under OpenHab2.5+. I followed the postings I saw here: [Neo Coolcam NAS-DS01Z does not work with OH 2.5], hence the reason I believed it was a ongoing/reported issue that I was still experiencing.

4

Again, I’m not aware of any issue reported regarding this, and without some information on what is wrong, I’m afraid I really don’t know how to help.

5

Hello Everyone!
sorry, as a newbie here in the forum ( ok, years of experience in it ) may be I ask silly questions:

I had more or less the same experience as CRPerrryJR.
My first attempt to OPENHAB was with 2.0 and the Doors Sensor NAS-DS01Z worked. It was an openhab installation on my mac mini.
Now, after some time, i tried a clean restart on a raspberry with openhab 3.
And, yes, everything works as it should, the binding ist working, the controller is found.
The door sensors ( DS01Z ) are also discovered ( Very nice, the Thing type shows the manual ).

But, I always get the NULL as a result from all channels.
I put the log level to debug and see the messages similar to this (manual wake up):
2021-02-24 00:24:39.808 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=42, payload=2A 00

2021-02-24 00:24:39.809 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 5: SendData Request. CallBack ID = 42, Status = Transmission complete and ACK received(0)

2021-02-24 00:24:39.809 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 102: Transaction COMPLETED

2021-02-24 00:24:39.810 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Response processed after 33ms

2021-02-24 00:24:39.810 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: TID 102: Transaction completed

2021-02-24 00:24:39.810 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: notifyTransactionResponse TID:102 DONE

2021-02-24 00:24:39.811 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

2021-02-24 00:24:39.811 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 102: Transaction event listener: DONE: DONE ->

2021-02-24 00:24:39.812 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: Went to sleep COMPLETE

2021-02-24 00:24:39.812 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2021-02-24 00:24:39.813 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

But: As written above, always NULL is displayed.

I’m clueless… can anyone give me a hint what to do? A downgrade to 2.4 is not my preferred way.

Thanks in advance

Ralf

6

@Eddie_0
start a new thread dude
last post Jan 2017, previous to that Jan 2016
everything has changed since then, good on you for seaching something that seemed similar to your issue but it is not

1 Like
7

I’m sorry you feel that way “dude”…but I feel this thread provides context to the issue at hand and demonstrates the duration of the issue. Which I’m sorry to say, is more similar and lengthy than you give credit. And this post is not that old…It is January the 16th…not January 2016. I can validate that the issue I described above is still an issue. Everything Ralf said was exactly the same as I experienced, and still experience. I just choose to use a work around and utilize an older version of Openhab. I’d love to use the new versions…but it isn’t happening at this time.

I hope this clears things up.
Thanks!

8

Probably should not meddle as I have no particular expertise, but here goes.
I took a quick look at the zwave device DB and see that in Association 2 sends a basic set for your device. Have you tried to see if the device is can send that to another thing?

I personally use rules instead. Have you tired a rule “If sensor changed” turn on the light. The item may show null, but still send something.

Lastly I have the same requirement, but have all zwave and use Ecolink DWZWAVE25 door sensor. They are about $30 in the US and work fine with OH (I’m on 3.01).

If you want to stick with what you have, you are going to need to log:set zwave in Debug in the console and parse it in the Zwave tool.

Thats all I got

Bob

9

yep… you’re right… my mistake… dude

10

Thanks for your comment. I’ll try to test the “rules” way. I’d hoped to dive into the rules on a later stage :slight_smile:
I already increased the loglevel to debug. A command log:set wave ends up with error:
Error executing command: No enum constant org.apache.karaf.log.core.Level.ZWAVE

Ralf

11

Confusing… May be, there is a hint:
Suddenly, after a day or so, the Battery value (%) was shown on one sensor ( I ve got two )
Doing everything again, again NULL.
But, when I update the Thing ( Here: Association Group ) the log says:
2021-02-25 22:43:38.139 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Configuration update set action_heal to true (Boolean)

2021-02-25 22:43:38.140 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Starting heal on node!

2021-02-25 22:43:38.141 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: Can not start heal as initialisation is not complete (STATIC_VALUES).
2021-02-25 22:47:46.638 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling…

2021-02-25 22:47:46.640 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling deferred until initialisation complete

So it seems: Someone thinks, initialisation is not complete.
Good News, Error Message seen.

12

Sorry for writing so much, but:

It works now a little! Unfortunately I am not sure, why :frowning:

What I did ( may help the others )

1.) Repeated and “careful” including into the Z-network to ensure, everything is ok.
2.) Set the association group in the Thing configuration to controller ( may be, this was the root cause )
3.) Awake the sensor by three clicks

Then I see the values in the openhab.
But, without manual wakeup I get again “Polling deffered”, so I have to continue …

Regards

Update: Searched in the Web, but not found any hint…

Inclusion worked ( see above )
Data is seen by Openhab 3 ( new )
But:
After manual wake up everything is fine and then:
021-02-26 00:18:26.212 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null

2021-02-26 00:18:26.212 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Application Command Request (ALIVE:STATIC_VALUES)

2021-02-26 00:18:26.213 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0

2021-02-26 00:18:26.214 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: SECURITY not supported

2021-02-26 00:18:26.214 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 8: Received COMMAND_CLASS_SENSOR_BINARY V2 SENSOR_BINARY_REPORT

2021-02-26 00:18:26.215 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - Processing Sensor Type 10

2021-02-26 00:18:26.215 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - Sensor Type is DOORWINDOW

2021-02-26 00:18:26.215 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 8: Sensor Binary report, type=Door/Window, value=255

2021-02-26 00:18:26.216 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent

2021-02-26 00:18:26.216 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_BINARY, value=255

2021-02-26 00:18:26.216 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Updating channel state zwave:device:a61d79a547:node8:sensor_binary to ON [OnOffType]

2021-02-26 00:18:26.217 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Commands processed 1.

2021-02-26 00:18:26.217 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@a2f5de.

2021-02-26 00:18:26.218 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

2021-02-26 00:18:26.218 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

2021-02-26 00:18:26.219 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2021-02-26 00:18:26.219 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

2021-02-26 00:19:31.656 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Polling…

2021-02-26 00:19:31.658 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Polling deferred until initialisation complete

13

So I would say you have it working based on your log. The sensor binary state is updated to ON. If the Association group was not the controller initially that was the root cause

There is a polling frequency in the “Thing” setting. For a door sensor this should not be needed, so set to a high number. I use daily (86400).
Bob

14

Thanks a lot. I‘ll set the polling to once a day. But, it still doesn‘t poll, so I get no update, if the door doesn‘t move.

15

at least for me my two devices are working now… See Neo Coolcam NAS-DS01Z does not work with OH 2.5 - #15 by TomS