Nexia Z-wave Doorbell Sensor

  • 312 Views
  • Last Post 01 March 2018
joey10e posted this 09 October 2017

Hi Everyone,

I was just wondering if anyone has tried this doorbell sensor. I read the reviews and it looks like it works with Samsungs Smarthings hub, but does not work with Vera. If anyone knows it this works with Axial Control I would greatly appreciate the info. The only thing I am looking for this to do is work as binary sensor when my existing wired doorbell is pressed.

https://www.amazon.com/Nexia-Z-Wave-Doorbell-Sensor-DB100Z/dp/B017VVO9QQ/ref=sr_1_3?ie=UTF8&qid=1507590507&sr=8-3&keywords=zwave+doorbell

Thanks

Order By: Standard | Newest | Votes
MadSci posted this 01 March 2018

Oops. Sorry, I thought I tried that. Anyway, I was able to download and test and it appears that it works as it should! Using ALARM_REPORT as the trigger. Hopefully it helps others!

Much appreciated!!! Thanks again.

rscott posted this 28 February 2018

@MadSci - not sure what the forum is doing, but go back to the original link and copy/paste it into your browser instead of click it. I'll try to re-link it tomorrow. Sorry!

 

MadSci posted this 28 February 2018

Thanks man, but link is dead...

rscott posted this 27 February 2018

Here, give this version a try: https://s3.amazonaws.com/axialcontrol/AxialServer_Setup_4.5.6632.exe

rscott posted this 24 February 2018

Ah, interesting :) I'll get you another version to try out shortly. 

MadSci posted this 24 February 2018

Ryan,

Thanks again for your help, but it's not quite working it seems...

When the scene trigger for the doorbell sensor is assigned to NOTIFICATION_REPORT (directly copied from the log), there is no scene trigger. There are two other notifications associated with the doorbell sensor trigger, ALARM_REPORT and BATTERY_REPORT. If I switch the scene trigger to ALARM_REPORT, the door bell does trigger the scene! But so do my motion and door sensors!! lol. It doesn't appear to be decerning by the device ID in that case but it does pick up the doorbell sensor.

 

MadSci posted this 23 February 2018

Awesome, thanks Ryan. I will try tonight and provide feedback.

rscott posted this 23 February 2018

@MadSci

Try out version 4.5.6628. In the device trigger, there's a new option to trigger when a command is received. You could use "NOTIFICATION_REPORT" as the command name and see if that helps in your scenario.

Ryan

MadSci posted this 23 January 2018

Hi Ryan,

Thanks for following up. Unfortunately it did not work. I set the trigger to any change and it didn't work. The point on it only sending the notification report on trigger holds true, however. I haven't yet looked to see if there is a way to update firmware and if something is available. Otherwise, I think the only way it will work is if we can modify the software to reconize the report as a trigger. Thoughts?

rscott posted this 23 January 2018

Any luck with the other attempted suggestion of always triggering?

  • Liked by
  • MadSci
MadSci posted this 16 January 2018

Ryan - Just checked the log remotely and I can confirm that the only time the node shows up in the log is when the bell is pressed. It sends 7 different versions of the reports when the device is triggered (see my log report in the github) but I can't make a hill of beans on what it all means. Maybe there is something useful there that can be used if the device can be set up properly in Axial.

Reguardless, I'll give your suggestion a try tonight to see if it will work and will let you know.

Thanks for the help.  

MadSci posted this 16 January 2018

Ryan - I will give it a try tonight when I'm home and see if I can make it work like that.

When I checked the log report previously, the only time I see a notification report is when the sensor is triggered (when sees the voltage from the dool bell being triggered) so I believe that would work and is very consistant. IIRC, there is a parameter to tell it when to report the battery status as well. The default is when there is a notificaiton report so it sends both reports at the same time and no other time. I think that is what is shown in the log report on github. I have had the sensor installed for several weeks now awaiting a solution so I will check the log report once more to verify that this is indeed the case and report back here.

rscott posted this 16 January 2018

Don't toss the device out, there may still be a way to salvage it, despite the wonky reports. 

I'm still curious about the "trigger on any change" - you would create a virtual device based on the report you see coming in, then set the trigger to be "any change." I don't know that it'll work if the value isn't changing, but it's worth a shot. 

The other option might be for us to add a new feature that would "trigger on any communication from device." Do you *only* see communication from the doorbell when a button is pressed or do you see it randomly throughout the day without any interaction from a person?

MadSci posted this 16 January 2018

Thanks for the reply Ryan. I wasn't aware that I could even update firmware on any device other than the USB hub so I'll look into that. So what you are telling me is that there is no way to configure the device such that it indicates a trigger when Axial recieves the notification report?

When I looked around on the interwebs, people did complain about the inconsistancy and some chalked it up to the device not detecting the voltage change when someone pushes the door bell quickly/normally. For sure, the device is very good at detecting the voltage and sends the notification report, it's just that I can't make sense of the parameters it sends and there doesn't seem to be an consistant way to use one of them to allow Axial to know that the door bell was pushed using the usual techniques which I'm aware. I was hoping this was just a problem of my ignorance.

Too bad if it turns out this device is useless. Though, if anyone wants to do something similar to this (i.e. simply detect when the door bell has been pushed), it seems that the magnetic (hall effect) door/window sensors may be useful for detecting the motion of traditional door bell chimes which utilize an electromagnet to strike the bell / plate.

  

  

rscott posted this 16 January 2018

The doorbell itself is the problem. After some research into it, I've found others who report the same problem with the door bell. It would seem that the manufacturer would need to put a fix in place - I'm curious, have you happened upon any new firmware updates that might fix it?

With the though about watching for any notification - if you have a trigger setup that says "any change" on your virtual device, does it trigger everytime? I'll ponder on some other ways to handle this as well; part of the problem is that if I make a special exception for this one mis-behaving device, it'll impact other devices that behave the right way (for example, a sensor may always send a 1 when open and a 0 when closed, if every notification triggered things, that sensor would not function properly.)

 

MadSci posted this 14 January 2018

Hi Ryan - Any ideas on how to improve the reliability of the door bell sensor notification? Like I said in the above post, all is needed is for Axial to reconise that the bell is being rung ( sensor is being triggered) anytime the device sends the Alarm/Notification report. It only sends those reports when the doorbell activation is sensed. The parameters it sends in the report that Axial parses don't appear to be consistant with the operation of the door bell, so creating a virtual device off of one of them is useless. I'm at a loss. Any ideas here?

In addition to the logs posted in github, I'd be happy to provide any additional information needed. Just let me know.

Thanks man.

MadSci posted this 03 January 2018

Ryan,

Thanks for  the reply. Unfortunately, it's not going to work like that. The issue with the setup seems to be that the Power management parameter which I thought was reporting triggers seems to be pretty unreliable or for some other purpose: doesn't always change from 0 to 1 and sometimes just stays at 1 after triggering. If it stays on, it seems to need constant voltage (i.e. holding the door bell button) or multiple triggers in a row to toggle back to 0, or sometimes to go from 0 to 1. Sometimes, it behaves like I originaly thought. Basiically, It doesn't appear to be consistant. See the log file in the link for when I was triggering multiple times in a row. It doesn't always report 1 for the Power Management parameter...

Based on my testing, it seems that the only 100% reliable method is to use the fact that it sends the Alarm / Notification Report, i.e. what shows up in the log every time I trigger the sensor. That report is only sent on trigger of the sensor from searching the log over based on the the last few days of leaving it it hooked up with no one pushing the door bell.

Anyway for me to work around this and somehow use the this notification report as the trigger? 

 

log file report: https://gist.github.com/anonymous/4db50c781bb49b781ee3cd69216138fe 

 

rscott posted this 02 January 2018

Using the Power Management reading with a virtual device is probably the easiest way to go. I couldn't find any reference to other methods that would allow it to work as a typical binary on/off device.

I don't see anything that turns "Power Management" to 0 in the logs; did you exclude that part?

  • Liked by
  • MadSci
MadSci posted this 31 December 2017

Hi Ryan  - Wasn't sure if you wanted me to make a new thread for this device but here is the log report data for when the sensor is triggered a few times by application of the doorbell voltage to the lead wires ~19V AC (confirmed trigger from the LED). The parameters it shows in the device manager are battery and two "power managers". One reads 255 and the other toggles from 0 to 1 when the doorbell is triggered so worst case, I can make a virtual device to track that parameter but I assume there is more elegant way to do this.

12/31/2017 11:33:53 AM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 21 alarm_report

12/31/2017 11:33:53 AM: parameter ZWave_Alarm_Type, value=8 from node 21 alarm_report

12/31/2017 11:33:53 AM: zwave_alarm_type set with value of 8 from value 8

12/31/2017 11:33:53 AM: parameter ZWave_Alarm_Event, value=1 from node 21 alarm_report

12/31/2017 11:33:53 AM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 21 alarm_report

12/31/2017 11:34:00 AM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 21 alarm_report

12/31/2017 11:34:00 AM: parameter ZWave_Alarm_Type, value=8 from node 21 alarm_report

12/31/2017 11:34:00 AM: zwave_alarm_type set with value of 8 from value 8

12/31/2017 11:34:00 AM: parameter ZWave_Alarm_Event, value=0 from node 21 alarm_report

12/31/2017 11:34:00 AM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 21 alarm_report

 

Here is another with auditing turned on:

12/31/2017 12:28:15 PM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 21 alarm_report

12/31/2017 12:28:15 PM: parameter ZWave_Alarm_Type, value=8 from node 21 alarm_report

12/31/2017 12:28:15 PM: zwave_alarm_type set with value of 8 from value 8

12/31/2017 12:28:15 PM: parameter ZWave_Alarm_Event, value=0 from node 21 alarm_report

12/31/2017 12:28:15 PM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 21 alarm_report

12/31/2017 12:28:15 PM: Node Audit:

Node: 21

Command: NOTIFICATION_REPORT

Version: 3

Data: 00,00,00,On,Power Management,00,0,0,false,,00,{113 5 0 0 0 255 8 0 0 0 }

Received: 12/31/2017 12:28:15 PM

 

12/31/2017 12:28:15 PM: Node Audit:

Node: 21

Command: NOTIFICATION_REPORT

Version: 4

Data: 00,00,00,On,Power Management,00,0,0,false,,00,{113 5 0 0 0 255 8 0 0 0 }

Received: 12/31/2017 12:28:15 PM

 

12/31/2017 12:28:15 PM: Node Audit:

Node: 21

Command: NOTIFICATION_REPORT

Version: 5

Data: 00,00,00,On,Power Management,00,0,0,false,,00,{113 5 0 0 0 255 8 0 0 0 }

Received: 12/31/2017 12:28:15 PM

 

12/31/2017 12:28:15 PM: Node Audit:

Node: 21

Command: NOTIFICATION_REPORT

Version: 6

Data: 00,00,00,On,Power Management,00,0,0,false,,00,{113 5 0 0 0 255 8 0 0 0 }

Received: 12/31/2017 12:28:15 PM

 

12/31/2017 12:28:15 PM: Node Audit:

Node: 21

Command: NOTIFICATION_REPORT

Version: 7

Data: 00,00,00,On,Power Management,00,0,0,false,,00,{113 5 0 0 0 255 8 0 0 0 }

Received: 12/31/2017 12:28:15 PM

 

12/31/2017 12:28:16 PM: Node Audit:

Node: 21

Command: BATTERY_REPORT

Version: 1

Data: 64,{128 3 100 }

Received: 12/31/2017 12:28:16 PM

 

12/31/2017 12:28:16 PM: Node Audit:

Node: 21

Command: BATTERY_REPORT

Version: 1

Data: 64,{128 3 100 }

Received: 12/31/2017 12:28:16 PM

 

rscott posted this 07 December 2017

Yes, Happy to help get it going for you @MadSci. The easiest way to go about it would be for to you enable the audits for that device then operate it a few times, then look in the logfile.txt to see what kind of commands its sending. I would recommend creating a new forum thread for each device, then posting the logs (please use something like a Github Gist to hold the contents, then link it in the post).

Show More Posts
Close