Ring Doorbell not verry stable

#1

Hi,

I just purchased a ring doorbell just to have node red possibilities :slight_smile:

the node-red-contrib-ringdoorbell is quite easy. Just login and whenever there is action on the doorbell, a msg is passed in node red

Whenever there is motion OR someone pushed the doorbell, I send a specific value.My function 'ding or motion' is handling that.

The msg.payload.kind gives this info, or its value 'ding' or value 'motion'.
But half the time my messaes are not passing.

Now I'm wondering if there is a delay between to messages from the node 'ring doorbell'. Because usually motion and ding is right after each other.

Sometimes my function ding or motion is not passing the values even if the first node did send something. Why this is is even more strange to me.

For your info I'll give you my flow (without my credentials offcourse)

[{"id":"38ac6862.12ef28","type":"function","z":"27417de.18d4282","name":"ding or motion?","func":"var x = msg.payload.kind;\n\nif (x== \"ding\") {\n var msg_o = {payload : 110}\n \n} else if (x== \"motion\"){\n var msg_o = {payload : 120}\n \n} else {\n var msg_o = {payload : 999}\n \n}\nreturn msg_o;\n\n","outputs":1,"noerr":0,"x":420,"y":3040,"wires":[["7bcd2065.e63a4","7b3e5ab9.ac3f44"]]},{"id":"7b3e5ab9.ac3f44","type":"debug","z":"27417de.18d4282","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":630,"y":2960,"wires":[]},{"id":"9deaada6.a4c96","type":"ring doorbell","z":"27417de.18d4282","testmode":"N","verbose":"N","topic":"","name":"","x":180,"y":3040,"wires":[["38ac6862.12ef28"]]}]

anybody tips / suggestions?

Br

#2

It is not possible to import your flow.
Edit your previous post and insert a line containing three backtick characters before the flow and another such line after it. That stops the forum messing with the format so it will then be importable.

#3

Like Colin has already said - your flow cannot be imported, so it's difficult to help.

However, I did have similar issues which I tracked down to motion & ding being injected into the flow at almost the same time (as you have already suspected).
To overcome this, I use node-red-contrib-simple-message-queue to queue messages, so the second message isn't released until the first has been completed.
Works fine now!

1 Like
#4

@NickB said that the function node sometimes does not pass on the messages, which would have to be a different problem I think.
An alternative to your solution of using the queue, which might be simpler I think, would be to use node-red-contrib-semaphore.

Using node-red-contrib-semaphore
#5

I changed the export code in the start message. You can import it now.

About the passing:
Sometimes my Ring doorbell gives a payload, but the function not (tested with 2 debug block's)
That I can't explain, except if there is a fault in my function ding or motion.

But sometimes my ring doorbell simply gives nothing at all. At that point I don't think it's a 'queue' issue. I think it simply does not arrive at my Pi. I don't know if a message is pushed from the bell (ring servers) to the node ore if we are polling. If ring pushes someting I don't know how many times they push right after each other.

I will try both suggestions to start with, in the mean time my function can be double checked?

I do not know what the 'topic' option is that I can configure in the ring doorbell node. I have not used it. I only inserted my credentials.

Thanks

Nick

#6

It is not good practice to declare msg_o multiple times inside each if block. You would be better to declare msg_o once at the start and then just use it without var later. In fact it would be more usual just to change the payload of the message coming in and then pass that message on. So instead of msg_o={...} then return msg_o, just put msg.payload = 110 and then at the end return msg. However I don't think that is the problem. I suggest using node.warn("some message") liberally inside your node to try and see what is happening.
I wonder whether you are actually being confused by the fact that debug message outputs do not necessarily appear in the window in the order that you expect, due to the way messages down different wires can 'overtake' each other before being shown.

#7

@Colin I have changed the function just to be sure :slight_smile:
No, I'm not confused by the order. But when I push the bell, and I have a debug node behind the doorbell node I should receive something. And that is really not the case. So I think I really need to look to the doorbell node. But how? It's a closed block for me. I have no idea what it does. What do you mean with node.warn?

@Paul-Reed: How do you exactly implement this queue? It passes my first message and than it's done.
I definitly will give it a try, but as I said here above, I think it's something inside the doorbell node? Do you really receive every time you push your doorbell a message in node-red? Even If you push it several tims after each other?

Once again my flow:

[{"id":"a6eb6186.96c99","type":"modbus-write","z":"73876eca.24a1e","name":"Modbus Write 32017","showStatusActivities":true,"showErrors":true,"unitid":"","dataType":"HoldingRegister","adr":"32017","quantity":"1","server":"a7264232.7324b","x":820,"y":180,"wires":[[],["d8fdd90a.95cad8","61cedbc8.84b314"]]},{"id":"5a5f4e33.2cacb","type":"delay","z":"73876eca.24a1e","name":"","pauseType":"delay","timeout":"2","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":901,"y":310,"wires":[["a6eb6186.96c99"]]},{"id":"d8fdd90a.95cad8","type":"function","z":"73876eca.24a1e","name":"Standby 999","func":"var x = msg.payload.value;\nif (x< \"999\") {\n var msg_o = {payload : 999}\n\n}\nreturn msg_o;\n\n//We sturen een 999 naar ons modbus register van zodra\n//iets < 999 is gestuurd.","outputs":1,"noerr":0,"x":731,"y":310,"wires":[["5a5f4e33.2cacb"]]},{"id":"61cedbc8.84b314","type":"modbus-response","z":"73876eca.24a1e","name":"","registerShowMax":20,"x":1130,"y":180,"wires":[]},{"id":"57482f2a.fdf8e","type":"ring doorbell","z":"73876eca.24a1e","testmode":"N","verbose":"N","topic":"","name":"","x":130,"y":180,"wires":[["5f630e.82e80cf4","51077c85.18d7f4"]]},{"id":"51077c85.18d7f4","type":"function","z":"73876eca.24a1e","name":"ding or motion?","func":"var x = msg.payload.kind;\n\nif (x== \"ding\") {\n msg.payload = 110\n \n} else if (x== \"motion\"){\n msg.payload = 120\n \n} else {\n msg.payload = 999\n \n}\nreturn msg;\n\n","outputs":1,"noerr":0,"x":480,"y":180,"wires":[["a6eb6186.96c99","d1dcce46.90178"]]},{"id":"15300bf8.dc2c24","type":"debug","z":"73876eca.24a1e","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":430,"y":380,"wires":[]},{"id":"5f630e.82e80cf4","type":"debug","z":"73876eca.24a1e","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":370,"y":420,"wires":[]},{"id":"d1dcce46.90178","type":"debug","z":"73876eca.24a1e","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":490,"y":300,"wires":[]},{"id":"59660db0.542904","type":"inject","z":"73876eca.24a1e","name":"DING","topic":"","payload":"{\"kind\":\"ding\"}","payloadType":"json","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":130,"y":40,"wires":[["51077c85.18d7f4"]]},{"id":"5f5bcb80.e63d84","type":"inject","z":"73876eca.24a1e","name":"MOTION","topic":"","payload":"{\"kind\":\"motion\"}","payloadType":"json","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":120,"y":100,"wires":[["51077c85.18d7f4"]]},{"id":"53cb74bd.7dc4bc","type":"simple-queue","z":"73876eca.24a1e","name":"queue1","firstMessageBypass":true,"bypassInterval":"0","x":300,"y":180,"wires":[[]]},{"id":"a7264232.7324b","type":"modbus-client","z":"","name":"WAGO_PLC","clienttype":"tcp","bufferCommands":true,"stateLogEnabled":false,"tcpHost":"192.168.0.70","tcpPort":"503","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB","serialType":"RTU-BUFFERD","serialBaudrate":"9600","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","unit_id":2,"commandDelay":20,"clientTimeout":1000,"reconnectTimeout":2000}]

oh, and when deploying I get this faultcode

image

but I have no idea from where, Nothing lights up when selecting it.

#8

To be certain that nothing is being sent from the doorbell node you should set the debug node to "Output the complete message object" rather than just "msg.payload" Whilst it is good practice for the key info to be in msg.payload it isn't always the case,

Another way of finding the node with the error message is to copy the alphanumeric code after node: in the top line and do a search for it ( ⌘F on a mac - you can see what it is set to under the Node-RED menu keyboard shortcuts)

#9

OK, in that case it is definitely an issue with the doorbell node (or whatever drives it). I thought earlier you said that fewer messages came out of your function than went in, which would be difficult to understand given your simple function.

#10

I've just reworked the flow to use the semaphore node, and added a gif animation below.
In real time it all happens pretty quickly, so I've added a delay node just so that you can see how the flow works.
To trigger the flow, I've reached around the doorway and pressed the doorbell, triggering a motion alert first, followed less than a second later by a ding.
As can be seen, the google home node shows the IP of the device beneath it, so first it sends a motion alert to 192.168.1.11, followed by motion alert to 102.168.1.5, then a ring alert to 192.168.1.5, and finally a ring alert to 192.168.1.11.

Without the queue, all four msg's would arrive at the google home node almost together, which creates chaos!

There is an example flow of node-red-contrib-semaphore in this post, courtesy of @Colin