Nexia Z-wave Doorbell Sensor

  • 6.8K Views
  • Last Post 18 November 2020
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
rscott posted this 10 October 2017

My guess is it should work, especially if it's just the binary sensor part. If not, just contact us with some info (we'll let you know what to give us) and we can generally get you an update with the correct compatibility.

nelis249 posted this 21 October 2017

I haven't read a lot into it but I have Trane thermostats for my air conditioners witch implements 'Nexia'. They seem to use some propritary zwave behind it. I've not been able to connect it to anything else. From what I read there's an nexia bridge of some sort but I never got into it.

joey10e posted this 23 October 2017

I thought I read something about the propritary zwave as well and that is why I wanted to ask. If I decide to roll the dice on this I will let everyone know if it works.

rscott posted this 23 October 2017

I've used other nexia devices as long as they are powered by zwave. If they use zigbee, you'll run into issues.

Last I heard, there was no such thing as proprietary zwave because the protocol is controlled by a single entity and they don't allow custom code.

nelis249 posted this 26 October 2017

Yea proprietary is probably the wrong word.  Here's a product example: here

The explicit words are:

Z-Wave certified for use with Nexia

*Requires the Nexia Bridge for connection to Nexia

In that statement they are using Zwave yet it's locked strictly to their bridge device. Yea not prorietary but still locked in some fashion. Perhaps in the pairing process they check to determine if the connecting device is their nexia bridge, if not, don't connect. I'm not exactly sure why they do that other than to force you to use their products (aka the bridge). I've tried numerous times to pair it to the zwave stick with no success. Perhaps other nexia devices work differently.

 

Also, it's amazon, give it a try, if not compatible send it back :)

rscott posted this 26 October 2017

If they forcing people to use their Nexia bridge, then they are probalby in breach of the z-wave agreement they signed with Sigma that states they need to stick with a given protocol so any 3rd party controller can use the device.

Which device are you talking about being unable to pair? Did you go through the standards of excluding it first to reset it, then doing the add? I assume it's the thermostat you mentioned - can you send me a link to it?

nelis249 posted this 27 October 2017

 The thermostat I have is the XL850 here. I can try to do a pairing again. I know more about zwave now than I did back when I first got the thermostat. Not sure what you mean by 'excluding' it though.  The manual is here. Looking at the zwave section it seems like maybe the thermostat I have activates itself as a hub when connected to Nexia. Maybe it's just not a device. Though it still doesn't explain the other thermostat I posted before which also says it only works with the nexia bridge. 

Eh I'm not worrying about it. I've been slowly writing a plugin. I just haven't finished reverse engineering their phone app to get the API calls. There's smart things code here that scraps the nexia web page but I've done that before with other things and frankly, it's hacky as they can change their site at will. Typically web API calls will be in json with some structured format that can be read and seperates from the presentation layer which allows the user interface to change without changing the underlying data format. Thats the part I'm after and I've pinged nexia support a long time ago and they said there's no open API. That may be true but there's gotta be an API in there for their phone app, just gotta figure it out :).

weidnerj posted this 27 October 2017

Excluding it means to use the ZWAVE protocol to remove a device from a ZWAVE network.  Once a device has been paried, it is locked until it is excluded.  You can do that within Axial Control by hitting the remove device button and then on the device put it in pairing mode, or I usually take my ZWAVE USB device and hit the button twice where it flashes faster than include mode (include mode is just one press of the button) to go in to exclude mode - where I then put the device into pairing mode and the light will flash acknowleging the exclusion.  And any ZWAVE controller can exclude another ZWAVE device, even if they are not part of the same ZWAVE network.   Think of a ZWAVE exclusion as a reset of the device so that it can be included by another network.

MadSci posted this 07 December 2017

just picked up one. paired ok but i cant get a response yet. any luck Joey?

joey10e posted this 07 December 2017

I have not got one yet but I'm guessing rscott will be able to help you get it working. I am realy excited to here if it works for you. I will really want to get one if it does.

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).

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 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 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 

 

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.

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 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

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

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.

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.  

Show More Posts
Change Language
Categories
Search
Popular Tags
Hot Topics
Close