AD110 node stops reporting state changes after a while

[aaamoeder]

Since a week or two now I've been experiencing some strange behavior.

After an unknown amount of time (hours) the node just stops reporting state changes in nodered and automations no longer work. After re-deploying the node and restarting the flow it starts reporting again.

I have checked to see if the doorbell isn't dropping form the network, but except from the random 1 in a 1000 ping request timeouts, it is performing nominally.

I'm not sure if there is any logging or info you would like me to report ?

Since I'm using this to sound a chime on our googlehome when the doorbell is pressed it's annoying to not have a reliable doorbell.

Hopefully you find the time to look into this, and thank you for all the work you have put in already !

[bmdevx]

Hi,

I was also running into this same issue as well a while ago. It seems the doorbell stops reporting data even though the connection was still active. I fixed the base API (https://github.com/bmdevx/amcrest-ad110) in v1.1.0 to close and restart the connection every 10 minutes and it seemed to have fixed the issue for me.

Can you tell me what firmware your doorbell is running, as well as the version of your NodeRED and node-red-contrib-amcrest-add10. I will try and recreate the conditions and see if I can replicate the problem again. I will add some debugging options in the API as well and push an update if I am unable to find anything.

[aaamoeder]

thanks for your quick reply !

doorbell firmware = Eng_N_V1.000.00AC006.0.R.20200922 nodered version =1.2.5 node-red-contrib-amcrest-ad110 = 1.1.3 (I now see the option to update to 1.1.4)

Perhaps I should update node-red-contrib-amcrest-ad110 to 1.1.4 ?

[bmdevx]

Try updating to 1.1.4 and let me know if that works. I have the same NodeRED and firmware version as you and will run some long term tests over the next few days to see if the data stream or node is having issues.

[aaamoeder]

I'm also running home assistant and am using a flow to record a doorbell video stream (rtsp) each time movement is detected by the doorbell. I had disabled this flow a few days ago to see if there was any effect and it has not disconnected since (still running 1.1.3)

I'll update to 1.1.4 and re-enable the video flow to see if the problem reappears.

Thanks again for your time ! 👍

[aaamoeder]

so.. update.. I updated the node to 1.1.4 and re-enabled the video recording and this morning at 6.14 it stopped reporting again.

I then enabled "use raw codes" and deployed changes and it started reporting again.

What does "use raw codes" actually do ? It does not appear to hinder my flows so I've kept it enabled for now..

If you want me to do any other testing please let me know ;-)

[bmdevx]

Thanks for the update. So far I my node has not stopped reporting for me although I do not have a constant video stream going to HA for my setup. "Use Raw Codes" enables a flag for the api that talks to the doorbell to not format the incoming data. The data stream from the doorbell is in an odd format with several inconsistencies and I wrote the API to clean it up a bit. I am not sure why enabling raw codes would cause any changes in reporting as it is just a formatting option but I will look to see if there is a formatting bug that might causes a crash.

If possible, send me a raw stream of data from the doorbell and let me know when the node fails. I can try and see if there is something different coming down that I am not getting.

This can be done using an app like postman or using curl to a file. Make sure digest authentication is used (with the password to the device not the account used for the app) and just use a get request to "[ip addr of doorbell]/cgi-bin/eventManager.cgi?action=attach&codes=[All]" this should send out a constant stream of data. PS: don't have a timeout set otherwise the app will cut off the data after a minute or so.

My two main courses of though currently are data stream inconsistencies and the video streaming at the same time. Random codes from the doorbell may be throwing the parser off or the event stream may be stopped after a while on the doorbell itself. The doorbell does not have a great processing unit and easily bricks by sending the wrong command. The api being used to get the events is also unofficial as well and may be removed at any time from a doorbell firmware update.

[aaamoeder]

Trying to set up postman, will report back..

EDIT: not sure how all this stuff works, but I installed postman and then setup a get request with digest authorization to the ip of the doorbell ( xxx.xxx.xxx.xxx/cgi-bin/eventManager.cgi?action=attach&codes=[All] )

However when I press send nothing seems to happen ? the bar at the bottom keeps moving but apart from that I don't see any data ?

[bmdevx]

Sorry, forgot postman does not support streaming responses. Try this command with curl: curl -v -g --digest -u admin:PASSWORD "http://IP_ADDR/cgi-bin/eventManager.cgi?action=attach&codes=[All]"

And to save the file: curl -v -g --digest -u admin:PASSWORD "http://IP_ADDR/cgi-bin/eventManager.cgi?action=attach&codes=[All]" > output.txt

[aaamoeder]

just returns this `--myboundary Content-Type: text/plain Content-Length:135

Code=TimeChange;action=Pulse;index=0;data={ "BeforeModifyTime" : "2021-01-20 00:32:40", "ModifiedTime" : "2021-01-20 00:32:39" }

--myboundary Content-Type: text/plain Content-Length:135

Code=NTPAdjustTime;action=Pulse;index=0;data={ "Address" : "200.160.0.8", "Before" : "2021-01-20 00:32:37", "result" : true }`

didnt run long, and gave me this error

` no chunk, no close, no size. Assume close to signal end < 0 0 0 0 0 0 0 0 --:--:-- 0:04:49 --:--:-- 0{ [201 bytes data] 100 4334 0 4334 0 0 3 0 --:--:-- 0:19:17 --:--:-- 0 Recv failure: Connection reset by peer 100 4334 0 4334 0 0 3 0 --:--:-- 0:19:17 --:--:-- 0

• Closing connection 1 curl: (56) Recv failure: Connection reset by peer `

is there any way the listener node could accept a reset input to reset the connection if for example there has been no events for 15 minutes or something ?

[bmdevx]

I do not know how to get curl to do that. However I have updated the base API (https://github.com/bmdevx/amcrest-ad110) to be able to log errors and raw data. Try downloading the git and logging with it. You can change the default connection reset time from 10 minutes to 15 if you want using 'resetTime' for the AD110 config.

const AmcrestAD110 = require('../amcrest-ad110.js');
const fs = require('fs');

const ad110 = new AmcrestAD110({
    ipAddr: 'IP_ADDR',
    password: 'PASSWORD'
});

ad110.onError(err => {
    console.error(err);
    fs.appendFileSync('error.txt', `${(new Date().toString())}\nError:${err}\n`);
});

ad110.onRawData(raw => {
    console.log(raw);
    fs.appendFileSync('output.txt', `${(new Date().toString())}\n${raw}\n`);
});

ad110.start();

[aaamoeder]

I'm running node-red as an addon for home assistant so I don't have any direct console access.. would it be the right step to replace the current "amcrest-ad110.js" with the updated version ?

[bmdevx]

Replacing the API for the node will not start logging the raw data or errors. The node itself will need to be modified with that as an option. I may be able to get to that this weekend and push a update for it on NodeRED flows. In the mean time it may be easier just to download nodejs on another system and run the code above.

[aaamoeder]

I'm afraid that's a bit of a stretch for my capabilities.. I'll wait till you find some time ;-)

BTW, THANK YOU TONS for all the effort you've put into this. We actually had a break in to one of our cars 2 days ago and thanks to your work, I was able to capture some video when motion was detected. thanks to you the police now have a suspect and I might have a chance of getting our stuff back 👍

[bmdevx]

I'm so glad that it has helped you out! I would never have thought it would be so useful lol.

Anyway.. I had some extra time and updated the debugging API as well as added the debug option to the NodeRED monitor node. You should be able to log the 'raw', 'debug', and 'error' events to files. Example shown below. You just need to send the output from your preconfigured monitor node into the switch and turn on the new 'debug' option.

[{"id":"11462d15.2eb383","type":"switch","z":"5bb20615.3a1088","name":"Switch Type","property":"payload","propertyType":"msg","rules":[{"t":"hask","v":"raw","vt":"str"},{"t":"hask","v":"debug","vt":"str"},{"t":"hask","v":"error","vt":"str"}],"checkall":"false","repair":false,"outputs":3,"x":330,"y":640,"wires":[["9e596c10.846d6"],["64350916.95c728"],["9d10f91a.ff34e8"]]},{"id":"9e596c10.846d6","type":"change","z":"5bb20615.3a1088","name":"Set Raw","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.raw","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":500,"y":600,"wires":[["925174b2.a79fe8"]]},{"id":"64350916.95c728","type":"change","z":"5bb20615.3a1088","name":"Set Debug","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.debug","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":490,"y":640,"wires":[["170cfb3f.20fdc5"]]},{"id":"9d10f91a.ff34e8","type":"change","z":"5bb20615.3a1088","name":"Set Error","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.error","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":500,"y":680,"wires":[["170cfb3f.20fdc5"]]},{"id":"925174b2.a79fe8","type":"file","z":"5bb20615.3a1088","name":"","filename":"/data/rawdata.txt","appendNewline":true,"createDir":false,"overwriteFile":"false","encoding":"none","x":690,"y":600,"wires":[[]]},{"id":"170cfb3f.20fdc5","type":"file","z":"5bb20615.3a1088","name":"","filename":"/data/ad110-log.txt","appendNewline":true,"createDir":false,"overwriteFile":"false","encoding":"none","x":690,"y":660,"wires":[[]]}]

[aaamoeder]

i've updated to 1.1.6 and enabled debugging.

I Have however seem to have found an alternate fix to the connection issues. It seems that because of the IR kicking in at night it somehow is too much for the doorbell and it resets causing the connection errors

I now have set our front door light to max and it keeps the doorbellcam in daytime mode.

I do however have another issue that seems to be related to the update.

I use the snapshot node to capture an image but it is not working, a debug node linked directly after the snapshot node gives me "HTTPError: Response code 400 (Bad Request)"..

I also get "TypeError: Cannot read property 'ipAddr' of null" in de debug screen ?

[bmdevx]

For the connection issues at night, I would check on your doorbell transformer. Some older transformers may not be supplying enough or consistent power to the doorbell. If you are seeing an issue with the ipAddr being null, you may want to delete and create the config node again. I'm not sure why it would be null, but that is the most likely area that would cause it as the snapshot node gets it's credentials from there. The 400 response is most likely related to the null IP address.

[aaamoeder]

I already replaced the transformer (with a 63Amp one no less :p) so that's not the issue.. I guess it's purely the doorbell not being up to the IR switching..

I've deleted and recreated the config node and still I'm getting the "HTTPError: Response code 400 (Bad Request)" Mind you the sensor part (motion sensor, button press) is still working fine so the configuration node is supposedly ok ?

[bmdevx]

Not sure why the snapshot node is now having issues. I didn't change the code for it in the latest update and your config node seems to be fine if the monitor node is working. Try using postman w/ digest authentication with a GET request for:

IP_ADDR/cgi-bin/snapshot.cgi

It should show an image in the response if the doorbell is working correctly. If not, let me know what it responds with. 400 is a 'bad request', so it is pretty generic.

Also try disabling your live stream in HA and see if it works as well. It might not be able to do both at the same time.

[aaamoeder]

when doing the get request I get Error Bad Request!

And when using wrong credentials I get Error Invalid Authority!

Perhaps it's and update on the doorbell side ? I'm currently running Eng_N_V1.000.00AC006.0.R.20200922

Edit: WOW.. sorry for the trouble.. it seems simply rebooting the doorbell solved the issue .. sigh..

[bmdevx]

No problem, it happens. Are all nodes now working for you?

[aaamoeder]

Not sure if the original problem is resolved because the doorbell doesn't seem to lose connection now that it's not switching to night mode anymore.. But currently, YES all is working fine, thanks again for all your help ! ! !

[bmdevx]

For your night vision problem, you may want to look into time of day on/off for the night vision mode. I am not sure which setting it is but it can be done using NodeRED sending a digest Get request to the doorbell when the sun goes down or comes up.

For example, this disables the T2U Server

IP_ADDR/cgi-bin/configManager.cgi?action=setConfig&T2UServer.Enable=false

This is the request you can use to see the entire configuration of your doorbell

IP_ADDR/cgi-bin/Config.backup?action=All

Be careful when setting the configuration however, some settings are not meant to be changed.

[Hernanvb]

Hi bmdevx,

I have the same issue with the AD110 node stopping reporting after ~24 hours and once the node is refreshed and re-deployed it works for another day. I did some debbuging and ran you nodejs amcrest-ad100 code on a Linux machine for 3 days and I got 3 crashes.

{ time: 2021-04-12T04:03:10.165Z, debug: 'Resetting Connection' } { time: 2021-04-12T04:13:10.470Z, debug: 'Resetting Connection' } (node:16307) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'statusCode' of undefined at /home/asus/Documents/Projects/amcrest-ad110/amcrest-ad110.js:181:45 at processTicksAndRejections (internal/process/task_queues.js:97:5) (node:16307) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (node:16307) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Logs for crashes attached: crash.txt

[bmdevx]

I have pushed an update (1.1.7) to the repository which should catch the error above. Let me know if that solves the problem for you, otherwise let me know what version of NodeRED and the firmware of the AD110 you are running.

[Hernanvb]

Thank you! I'm currently running NodeRed 8.2.1 and AD110 has the latest firmware 1.000.00AC006.0.R.200922. I've updated the Amcrest Node and will report back in a few days if I see the issue.

[Hernanvb]

The node still stops reporting after a while. This issue can be easily recreated by cutting WiFi connectivity to the doorbell for at least 10 minutes (default reset time), then the code stops. Here's the error reported from my node program running the amcrest-ad110.js module: 3|doorbell | "Resetting Connection" 3|doorbell | "Status Code Not 401" 3|doorbell | "Status Code Not 401" My guess is that the node module doesn't try to re-connect after the attempt to reset connection fails because the doorbell is still off WiFi.

[bmdevx]

Pushed another update (1.1.8). The connection should now try and connect again no mater what error is thrown at it. It will be based off of the 'retryDelay' time value which has a default of 10 seconds.

[Hernanvb]

Tested the new changes and in fact it tries to re-connect every 10 seconds after the doorbell loses WiFi. Everything seems to be working well. Thanks for your time!