Guys the amcrest app works terrible. I have now integrated Amcrest integration and working fine and i see live view in HA. And also in Blueiris working very fine.
BUT
i need to receive notification if someone push on the ring button. Just not the motion sensor if someone arrive on the door. Can i receive the notification in blueiris or on HA . If that can i really delete that stupid app…
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:
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:
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:
/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 has SSHD.Enable: false
/usr/local/etc/sshd_config exists and allows password authentication and has AllowUsers admin
/usr/local/etc/ssh_host_rsa_key is defined in sshd_config and is also in the filesystem (BAD AMCREST!)/usr/local/sbin/sshd existsThat’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