You need to read the thread. Yes you can get a notification through HA with a button press, mostly reliably using an addon or customcomponent listed in this thread.
Not been here for a while, my install has stopped showing a static image on my HA dashboard (lovelace not used yet) if I click on the box the picture opens up and is displayed. But no static image as normal.
My config has not changed, anything else I need to do?
Re Dave
Iāve read this entire thread repeatedly. The only solutions Iāve seen are:
- A (possibly flaky) solution using NodeRed, which I havenāt used. And apparently it can overwhelm RPiās, which are a lot more common than custom docker setups.
- Using Tasker, which only works on Android, and requires the notification to come from the phone (so not really useful for an in-home doorbell for the family).
- Some external Docker container, which doesnāt really work for anyone using HA OS.
Did I miss an option? It would obviously be best if they upgraded the internal python library to support it natively, but that doesnāt seem to have had much activity.
Iām working on understanding the NodeRed solution, but itās kind of dismissive to expect someone to figure out how to get this working in a 220-message thread that contains tons of side discussions about lights and video stream options.
Update: I got the notification to work using NodeRed. Iāll try to write something up for the next person later tonight. There were a lot of steps.
Super short summary:
- You need NodeRED and the NodeRED Integration installed in HomeAssistant
- You need to add the AD110 palette installed (I think thatās the right term)
- You need to get the basic flow set up within NodeRED. Thereās a few confusing things, like setting up the entity or the configuration for the AD110 node.
Iām going to see if I can export the entire flow (I turned off motion since I can get motion via the HA Amcrest integration, and I donāt want to trigger a doorbell event everytime someone walks by).
The docker container can be used with the portainer add on and HASS OS.
Thatās what Iām doing. Though I have a NUC and not using RbPi
There are a couple options in this thread: Amcrest Doorbell AD110 API/Local Only - #19 by omayhemo
the callinfo sensor works fine for most but some have mentioned a delayed response time from the button push.
Great, thanks for sharing! Since I have the NodeRED setup working, and it looks like that would be more work (I have 2 doorbells), Iāll stick with my current setup, but itās nice to have more options.
For anyone who wants a (hopefully) complete set of steps to get NodeRED working, hereās what I did:
-
Inside the Supervisor, install NodeRED
-
Using HACS, install the NodeRED Companion Integration (needed to get the entities into HA)
-
Start NodeRED from within Supervisor, and open itās web UI
-
Click the hamburger menu in the top-right, and choose Manage Palette
-
Click on Install
-
Search for AD110 and install the node.
-
Close that dialog, click the hamburger menu in the top-right, and choose Import
-
Paste in the following code and click Import. It should be a complete flow from AD110 to HomeAssistant.
[ { "id": "5c215168.c111c8", "type": "node-amcrest-ad110-monitor", "z": "39edc67e.009942", "name": "", "config": "", "rawCodes": false, "debug": false, "x": 210, "y": 340, "wires": [ [ "6334b526.0a78cc" ] ] }, { "id": "2724db6b.3d39d4", "type": "change", "z": "39edc67e.009942", "name": "", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "on", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 700, "y": 260, "wires": [ [ "8e6a12be.027aa8" ] ] }, { "id": "d6a6c07b.1d8a6", "type": "change", "z": "39edc67e.009942", "name": "", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "off", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 700, "y": 320, "wires": [ [ "8e6a12be.027aa8" ] ] }, { "id": "6334b526.0a78cc", "type": "switch", "z": "39edc67e.009942", "name": "", "property": "payload.code", "propertyType": "msg", "rules": [ { "t": "eq", "v": "CallNotAnswered", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 1, "x": 390, "y": 340, "wires": [ [ "c0b754ea.8a3f68" ] ] }, { "id": "c0b754ea.8a3f68", "type": "switch", "z": "39edc67e.009942", "name": "", "property": "payload.action", "propertyType": "msg", "rules": [ { "t": "eq", "v": "Start", "vt": "str" }, { "t": "eq", "v": "Stop", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 530, "y": 280, "wires": [ [ "2724db6b.3d39d4" ], [ "d6a6c07b.1d8a6" ] ] }, { "id": "8e6a12be.027aa8", "type": "ha-entity", "z": "39edc67e.009942", "name": "Front Doorbell Pressed", "server": "1bc04557.74400b", "version": 1, "debugenabled": false, "outputs": 1, "entityType": "binary_sensor", "config": [ { "property": "name", "value": "Front Doorbell Pressed" }, { "property": "device_class", "value": "" }, { "property": "icon", "value": "mdi:doorbell" }, { "property": "unit_of_measurement", "value": "" } ], "state": "payload", "stateType": "msg", "attributes": [], "resend": true, "outputLocation": "", "outputLocationType": "none", "inputOverride": "allow", "outputOnStateChange": false, "outputPayload": "$entity().state ? \"on\": \"off\"", "outputPayloadType": "jsonata", "x": 980, "y": 300, "wires": [ [] ] } ]
-
Double-click on the first node. In this panel youāll need to add a new
node-amcrest-ad110-config
. I donāt remember the details, but itās pretty easy. -
Double-click the last node if you want to change any of the entity values. I discovered if you give the node a human-friendly name, itāll automatically generate a sensible entity ID.
-
Click Deploy in the top-right of NodeRED.
This is my first NodeRED flow, so if something doesnāt work, I probably canāt help. Hopefully the complete flow import actually works, I stripped out the system-specific nodes so it may or may not work. I found NodeRED to be have a really tough interface to understand. It might be more āvisualā than HA, but simple HA automations are a lot easier to understand for me.
For the rest of the camera functionality, Iām using the normal Amcrest camera integration, with the following settings:
- host: Ā«your-camera-ipĀ»
name: "Front Doorbell"
username: !secret amcrest_username
password: !secret amcrest_password
scan_interval: 1
stream_source: rtsp
binary_sensors:
- motion_detected
- online
sensors:
- sdcard
This gave me camera and motion detection, which are easy to drop in using the normal picture glance card.
Hi
just got AD110 doorbell and installed Daniel Chesterton`s docker Amcrest2MQTT and it works great and pulls door bell press information straight into HA.
https://hub.docker.com/r/dchesterton/amcrest2mqtt
Works like a charm, see page you can add as a Portainer easly.
I have successfully dumped the 16MByte SPI flash EEPROM from my doorbell. Iāve spent a little time today working on pulling apart the dump to look for anything of interest. I am no expert at pulling these types of things apart but I have noted the following:
- This is definitely just some modified Dahua firmware
- There are references to update.img
- There are logging strings such as āSD update fail !!!ā and āSD update success!ā possibly indicating update via SD
-
/usr/bin/sonia
does exist in the firmware (but possibly not being loaded?) -
/usr/pd/product/IPC-HF3100/CustomConfig
is a JSON config file (looks like standard Dahua firmware config) and hasSSHD.Enable: false
-
/usr/local/etc/sshd_config
exists and allows password authentication and hasAllowUsers admin
- A host key of
/usr/local/etc/ssh_host_rsa_key
is defined insshd_config
and is also in the filesystem (BAD AMCREST!) -
/usr/local/sbin/sshd
exists - References to updating via TFTP are there. Maybe another exploitable avenue, but maybe being WiFi only hinders that?
Thatās about all I can tear into tonight, but thereās some interesting stuff there.
This is on the latest version firmware available at the time of writing. binwalk shows a creation date of 2020-07-03 01:53:34.
Very interesting indeed @patharti!
Yes, Amcrest devices are mostly just rebranded Dahua with some minor firmware changes. And in the case of the AD110, a redesigned plastic shell that differs from the DB11. SmartHome devices have significantly more firmware changes than non-SH, and the omission of the web UI being the most unfortunate change.
I was intrigued by your discovery that sshd was present in the firmware. I was able to enable ssh access via this command:
<ip_addr>/cgi-bin/configManager.cgi?action=setConfig&SSHD.Enable=true
Now you can ssh into the AD110 (or any Amcrest/Dahua device). Userid is admin, and your normal admin password is used but prefaced with 7ujMko0<password>
You will then be logged into a ādshā shell and provided with a very limited set of commands - āhelpā, ādiagnoseā, "getDateInfo"and āshellā. When entering āshellā, you will be asked for a domain account. ā888888ā is accepted which then displays a QRcode image. The scan will return an https url to svsh.dahuatech.com with a long encrypted key. Connecting to this Chinese site will then prompt you for a password for the 888888 agent which is as far as I can get.
BTW - if anyone is needing to install a back-level firmware, it is possible to obtain the zip file from Amcrest Support and install it via the ConfigTool app update option. There is no known way to update firmware via the SD-Card if the device is bricked but it sure sounds like from your investigation that it is possible.
Spent a little more time looking at the update process. It looks like updating via SD should work, and it should work via the Amcrest IP Config desktop tool (rebranded Dahua tool). By looking at the Dahua DB11ās firmware update files (available from the Dahua wiki) theyāre just ZIP files. Iām assuming sign.img
is used to sign the update file and check.img
is used to specify which hardware itās applicable for. These two might have to be stripped out of a legitimate Amcrest update file.
The real stuff thatās interesting to us is probably the Install
file. This is just a config file that specifies which images to write and what hardware itās applicable for. I would assume getting SSH on the device would be as simple as unpacking user-x-squashfs.img
, enable sshd in pd/product/IPC-HF3100/CustomConfig
and then repack the image. By reducing the install configās Commands
section to only do burn user-x.squashfs.img user
we should be able to safely replace whatever is on the doorbell without touching things like the bootloader or kernel.
I also followed the trace for the button back to the main board and while hard to follow on a black PCB, I believe it runs straight back to the CPU which makes me believe itās just on GPIO. All of this could mean that a completely custom firmware might be possible. Dumbing down the AD110 (as well as the DB110 to just do MQTT with an RTSP stream would make it a pretty great DIY solution. My unit is still in pieces at the moment so I havenāt tried flashing anything yet. I think the next steps would be to figure out how to grab the update file from Amcrest so we can move forward with getting SSH enabled.
Hah @GaryOkie I was typing up my second reply as you posted yours, hence any lost context. This is AWESOME! Sounds like dsh
is a bit too limited. If we could craft our own update maybe we could get a better shell loaded up.
Hi Pat - I sure appreciate your efforts! Here is a link that you might find usefulā¦
And if you are wanting Home Assistant triggers to ANY events the AD110 (or any Amcrest/Dahua) device can issue - here is a nifty amcrest2MQTT docker app.
https://hub.docker.com/r/dchesterton/amcrest2mqtt
Dahua makes Amcrest FWIW
One peice of Software gDMSS (DMSS from the wiki) will let you view video and 2 way talk over port 37777 with the AD110 - itās the sofia/DVRIP protocol - Iāve been looking for a way to tanslate this to SIP with no luck as of yet - Pat you mention Sonia - do you know what this is - is it a more modern version of sofia?
I say itās sofia/DVRIP - I canāt be certain of that, Iāve spyed on it using wireshark but itās all small UDP packets - doesnāt appear to be anything understandable
Thereās also a QUIC heartbeat that gets sent out - the doorbell reboots if thereās no response from this (easy to fake though)
Watching this thread with interest
Iām in the market for a doorbell at the moment and it sounds like the amcrest would be perfect if there is some hackability to enable native mqtt.
I donāt fancy having yet another docker container running just to integrate the doorbell!
We wouldnāt even need MQTT and/or another Docker app if the PR to update the Amcrest Integration to incorporate full event processing would move forward. Itās stuck now due to the requirement to enable config flow since any YAML updates are a no-go. The PR developer is asking if someone else would take that on. Meanwhile, the amcrest2MQTT is an effective workaround.
Regarding sonia - hereās an excerpt from the unbricking Dahua link I provided earlierā¦
The main application which provides all the camera capabilities (web interface, streaming, etc.) is /usr/bin/sonia. This process is what makes most firmware different from version to version (sort of). There are also changes to the web partition which contains the web server pages that /usr/bin sonia hosts on port 80. The sonia process is invoked by a shell script in init.d
Iām not sure, but I think any references to the āSofia protocolā were typos, and Sonia DVRIP protocol was what was meant. See this: Reference codes for the DVRIP/Sonia TCP protocol used by the Net Surveillance ActiveX plugin Ā· GitHub and also this: https://security-tracker.debian.org/tracker/CVE-2017-3223
This protocol may only be used by the near obsolete ActiveX clients. Is it still relevant?
/usr/bin/sonia
is as what your quote describes. Doing strings
on it has a bunch of references to the libs on the system, most being hi3518 modules. Itās also the largest binary at around 7MB.
With the event-based integration existing Iām not sure how far Iāll actually take this as I donāt have the actual skills to craft/maintain an alternate custom firmware, but I think itās worth documenting these types of devices and how they operate / how or when they phone home.
I took some more shots in the dark. The system wonāt take a DB11 update file, assumingly because of differences in hardware IDās or signing. The system contains busybox, naturally, so doing a symlink from dsh
to bash
would probably net us a proper shell.
Does anyone have a readily available update bin from Amcrest? The next step should probably be to unpack its user-x.squashfs.img file, symlink the shell and change the default CustomConfig file to have SSHD enabled by default.
Some slight confusion - Iām going on this entry:
"MCASTAddress" : "239.255.42.42",
"MCASTEnable" : false,
"MCASTPort" : 36666,
"MaxConnections" : 128,
"MonMode" : "TCP",
"RegisterServer" : {
"Enable" : true
},
"SSLPort" : 37776,
"StreamPolicy" : "None",
"TCPPort" : 37777,
"UDPPort" : 37778
},
From my config.backup, I then did research into the DVRIP protocol - from that research Iāve picked up the name āsofiaā as another way the protocol is referred to (NetSurveillance/DVRip/sofia/x- it getās called slightly different things all over the place) - but the important thing is that I can get 2 way talk working over port 37777 using a 3rd party app - itās slightly off topic but Iām trying to put together a SIP<>doorbell bridge such that I can call a hunt group when the doorbell is rang
From the config.backup thereās also the VSP_PaaS entry - the DMS and RS server ports are hit at bootup, and the ātypeā attrib of easy4ip is a dahua project (https://open.easy4ip.com/) - also looking at the specified domains and ports, they seem to be HTTP based APIās of some sort - Iāve got a ātodoā of having a look at the wireshark for these next
Thereās also the T2UServer attribute but Iāve not been able to find anything out about that at all
Whilst composing this reply I was having a wee flick through - I actually see RemoteDevice.uuid:xxxxxx.GB28181.Port == 5060 - which is a SIP port, so that might be a starting point for what Iām looking for
Re. Hi3518 - have you looked at this: https://openipc.org/ - specfically designed for Hi35xx chipsets
I donāt, but I do know that someone reported on the Amcrest forum that they were provided one by Amcrest Support. I tried to find that post but the forum is badly broken for over a week now.
Try contacting Amcrest Support - tell them you upgraded the firmware and now some feature you need is broken and to send you the previous version zip file. Meanwhile, Iāll try to find another source.
UPDATE: Amcrest forum is back online and I PMād the guy who said Support sent him a link to download the firmware. His last activity on the forum was 4 months ago, so not likely to hear back soon.
UPDATE2: Here you go @pathartl ! Firmware can be downloaded from google drive: https://drive.google.com/file/d/1JwkAh9nroFd49ZBrTjVsKfplpnX4fjaA/view
(DB=Doorbell LEXUS=AD110 codename)