New RCA HSDB2A 3MP Doorbell IP Camera

Here is a drawing of the Monocle gateway.

monocle-gateway.jpg

Here run the Monocle gateway on a new Automation Microserver - BeeLink BT3 Pro - 64Gb eMMC and 4 Gb of Ram. Got a deal on the BeeLink at $65 on Ebay for a new one. Wiped W10 on it and put Ubuntu and Oracle VB (VB is running W7e). Automation Leviton OmniTouch and Homeseer touchscreens display CCTV.
Box is running:

1 - Home Assistant - MQTT - OmniPanel Plugin - Alexa TTS
2 - Node Red
3 - Mosquitto Server (MQTT)
4 - Homeseer - also doing MQTT, ZWave, Zigbee, UPB, WiFi (Espurna / Tasmota firmware modded) and X10
5 - Monocle Gateway
6 - Oracle Windows 7 embedded for SAPI Text to speech
 
Not at all. Alexa devices actually have local capabilities which is what monocle exploits. For example, you can control hue hubs locally without any skills (I use that to control my entire house automation). Monocle forwards the url of the rtsp to the alexa show so that the alexa device goes directly to that local url to get the stream. It does not go through the cloud. Google doesn't allow that. It is fully and completely cloud dependent.
Gotcha, I get the forwarding, Chromecast works the same way in Casting to it locally, forwarding URLs. I remember looking at Philips but ended up going with Lifx, cost a bit more but not dependent on a priority Hub. I went also the Z-Wave route on Door Locks, some switches, etc. Though I have a Smart Things Hub I want to replace one day. Hopefully one day we can all get off Alexa/Google clouds for Assistants...
 
Well I am not using a Philips hub per say, I am using the fact that the amazon echo devices have a built in local API bridge to the hue and exploited that to make it control my vera, all locally... I am also using zwave/zigbee but repudiated SmartThing for their cloud dependance. So comparing Google and Alexa should give you a good parallel to comparing SmartThing with Hubitat. On the left: The cloud dependent devices, on the right, the devices which are almost cloud independent (It is a stretch for the echos since they still rely on the cloud for voice processing)
I wish more information would be shared on the pros and cons of the approaches and what devices are doing in terms of cloud vs. local. There has been such a surge of cloud dependent devices and so many reviews of devices online which completely ignore that, focusing only on the novelty but never mention the dependence which compromise: Long term viability of the device (They kill the cloud server, you end up with a brick), Stability (Code can change any time, servers can go down any timer, leaving you unable to do anything), Security (The company server gets hacked, you pay the price), Performance (Why the heck do I want to send all my data to the cloud for it to come back to my network on a second device, consuming power and adding latency?), Reliability (Multiplying device dependancies by going through multiple servers, cloud to cloud multiplies the probability of failure.). The cloud is great for a lot of things. Home control/security/cameras is not one of them. Having cloud capabilities as an optional addition is great for some added benefits, making it dependent is absurd. Just my 2c.
 
Last edited:
Well I am not using a Philips hub per say, I am using the fact that the amazon echo devices have a built in local API bridge to the hue and exploited that to make it control my vera, all locally... I am also using zwave/zigbee but repudiated SmartThing for their cloud dependance. So comparing Google and Alexa should give you a good parallel to comparing SmartThing with Hubitat. On the left: The cloud dependent devices, on the right, the devices which are almost cloud independent (It is a stretch for the echos since they still rely on the cloud for voice processing)
Thank you rafale and Pete, for explaining this to me. So in me trying to figure this out in my simple minded way, the Echo uses a special API to talk to the Hue through your local network, but not like Z-Wave via RF? Or is Echo a Z-Wave device?
 
Here is a drawing of the Monocle gateway.

View attachment 54270

Here run the Monocle gateway on a new Automation Microserver - BeeLink BT3 Pro - 64Gb eMMC and 4 Gb of Ram. Got a deal on the BeeLink at $65 on Ebay for a new one. Wiped W10 on it and put Ubuntu and Oracle VB (VB is running W7e). Automation Leviton OmniTouch and Homeseer touchscreens display CCTV.
Box is running:

1 - Home Assistant - MQTT - OmniPanel Plugin - Alexa TTS
2 - Node Red
3 - Mosquitto Server (MQTT)
4 - Homeseer - also doing MQTT, ZWave, Zigbee, UPB, WiFi (Espurna / Tasmota firmware modded) and X10
5 - Monocle Gateway
6 - Oracle Windows 7 embedded for SAPI Text to speech
As usual, you are talking French to me Pete, :) lol

One thing is for sure, i will be adding another link in the 101 :)
 
I happen to be French... maybe that's why... :p Pete just means he setup a homeseer hub using a very cheap PC bridging his home automation locally to his echo.
The echo has a built-in capability to discover the hue bridge and other devices (TP-Link KASA and one other). I cannot find that developer page at the moment.
I have set up a bridge which technically is an emulator, broadcasting the vera as if it was a hue bridge.
Without any skills (meaning no cloud to cloud or login), the hue discovers all the devices on my vera (zigbee and zwave) and can control them locally.
Likewise, it is able to stream local rtsp urls... which GH cannot. For google everything needs to come from google cloud servers.
 
  • Like
Reactions: David L
I happen to be French... maybe that's why... :p Pete just means he setup a homeseer hub using a very cheap PC bridging his home automation locally to his echo.
The echo has a built-in capability to discover the hue bridge and other devices (TP-Link KASA and one other). I cannot find that developer page at the moment.
I have set up a bridge which technically is an emulator, broadcasting the vera as if it was a hue bridge.
Without any skills (meaning no cloud to cloud or login), the hue discovers all the devices on my vera (zigbee and zwave) and can control them locally.
You French guys, haha...No actually, thank you from this message and your previous you actually explained a whole lot in how today's cloud services work. The Machines are trying to collect all they can from us humans to one day, if not already, control us through their AI, Skynet (Terminator) :) Very much appreciate getting into ya'lls brains lol.

So one last question, for today that is :)

What is your take on the recent RCA owners bricking their DBs, upgrading to Nelly's firmware? I am almost through with my search here going back to when Chad first installed the firmware, he actually did both LaView and Nelly's on his RCA I found. But he is the only one I found, so far, who actually installed Nelly's on a RCA, that posted here that is.
My thought is it is something to do with Nelly's firmware since there is quite a few RCA owners running LaView's FW and no one has posted any issues.
 
Wow. You guys are light years ahead with smart homes. I will be reading up on this stuff.

Sent from my LG-LS997 using Tapatalk
 
  • Like
Reactions: David L
Wow. You guys are light years ahead with smart homes. I will be reading up on this stuff.

Sent from my LG-LS997 using Tapatalk
Haha, seems like every time one of them post I am spending the next 30 minutes, or more, searching for what they talking about :)

I may have some Google Minis for Sale in the near future :) Could give them to people I don't like haha, problem is I like Everyone :)
 
So on a more serious note, all I could only find one person who posted, Chad, that has a RCA and loaded Nelly's firmware without bricking. This bricking issue has kept me up at night. I keep thinking about getting the Doorbell, all excited, wife can't wait, install goes great, then bricking it because of my 101. Last year we only had one brick, COotto1984 an EZVIZ DB1 owner.

Nelly’s firmware on RCA owners:

New RCA HSDB2A 3MP Doorbell IP Camera Chadsturgill (build 190625 of Nelly’s firmware)


I still feel there are more RCA owners out there running Nelly's firmware. When you go back on this thread you will see like a wave, first RCA's, of course, then a few other brands, then LaView released ONVIF, firmwares were discovered, most went with LaView firmware but once Nelly's announced their ONVIF support, the wave went that way, new owners buying Nelly's, then came the price drop on the EZVIZ DB1, wow that was a big wave, which made sense being end of the year, Winter and all (Big Surf I guess), Amazon was even out of stock a few times I saw. So many new users, so many questions which gave birth to the 101. My hope for this year, No More Drownings...
 
Yeah Sorry can't help much on the Nelly's firmware as I did not try it. I can just say that my doorbell factory reset itself a few days ago for mysterious reasons. I am suspecting that it is related to my wifi APs testing a lot of ubnt beta firmware but I can't be sure.
I see no reason why specifically the Nelly's firmware would brick the device unless it was incompatible. I would just put a work of caution whenever updating firmware because there is always a risk of bricking due to 1. corrupted downloads from the web or upload through wifi and 2. the hardware flash drive being defective just enough to corrupt the firmware and going undetected prior to it. Other than that... I would desperately try to reflash but short of that... not much I can think of.
 
  • Like
Reactions: David L
Is there anyway to force the internal battery to run down faster? I'd like to keep messing with my bricked RCA, but taking 30+ min for it to actually power off once turning off the breaker is a bit rough
 
  • Like
Reactions: David L
OFF Topic!

@David L

Thoughts and prayers for your upcoming procedure.
Hey thanks, appreciate prayer... Hopefully someone will answer your Alexa/Google question with ONVIF firmware. I know there are advantages to ONVIF, I don't understand them all, but you can always enter your RTSP manually...Most of the time it works, just some NVRs might give you trouble. In Blue Iris I have went both ways, manually RTSP and ONVIF no problem...
 
Is there anyway to force the internal battery to run down faster? I'd like to keep messing with my bricked RCA, but taking 30+ min for it to actually power off once turning off the breaker is a bit rough
Not sure about a good battery drain, maybe cover the DB in case the IRs can turn on, but being bricked I doubt it. I do have a question, have you by chance tried other firmwares on your SD-Card? Also, I assume being Red Lit, you don't see any network broadcast from the DB anymore, either on your phones WiFi or your router correct?
 
Not sure about a good battery drain, maybe cover the DB in case the IRs can turn on, but being bricked I doubt it. I do have a question, have you by chance tried other firmwares on your SD-Card? Also, I assume being Red Lit, you don't see any network broadcast from the DB anymore, either on your phones WiFi or your router correct?

Nah, haven't tried other firmwares, but I'll give that a go in the morning and will report back! And nope, don't see any network broadcast from it, that's actually how I knew something was wrong before I knew the solid red meant bricked
 
  • Like
Reactions: David L
Nah, haven't tried other firmwares, but I'll give that a go in the morning and will report back! And nope, don't see any network broadcast from it, that's actually how I knew something was wrong before I knew the solid red meant bricked
My thought is, rafale mentioned possible corrupt firmware file, which it is a long shot, but worth a try. I had a virus once corrupt a motherboard firmware/BIOS once, it is just ironic all of these happened around the same time...
 
Here is PDF for doing a de-bricking of a Hikvision camera.

TFTP Automatic Update Tool

Historically here have de-bricked a Foscam PT camera via a JTAG connecion and an Ubiquiti IP camera via a similar TFTP methodology.

Attached is the TFTP-Update file required.

Here is an easy to read document:

How to reflash the firmware on Hikvision cameras (Hikvision TFTP procedure)

What do you need
1. The TFTP software (download here). Make sure to unzip it.
2. The right firmware for the camera. This is the tricky part, you need to get the right firmware version for your camera, otherwise the reflash procedure won’t go through. For the Hikvision USA equipment the firmware can be found on the Hikvision US website, for the OEM versions you need to contact your supplier/reseller. You can check this page containing the firmware for Hikvision IP cameras.
3. A switch/router. The computer and the camera with hook up to this switch. The scheme will be: laptop/computer and the camera goes to the switch. The camera can be powered via PoE or on separate power adapter.

The steps to reflash the firmware
1. After you download and unzip the TFTP files, place the folder on your C:/ drive (C:/TFTP-Update/). In this example we labelled our folder “TFTP-Update”.

image001.jpg


Place the folder on the C:/ drive.

2. Place the firmware file inside the TFT-Update folder. The firmware is named: digicap.dav. Don’t paste the firmware as a zip file, otherwise the procedure will fail.

image003.jpg


Paste the firmware inside the TFTP folder.

3. Change the IP address of your computer/ laptop. You can do this on the TCP/IP section of your Network Settings.
a) Open Network Connections by clicking the Start button, and then clicking Control Panel. In the search box, type adapter, and then, under Network and Sharing Center, click View network connections.
b) Right-click the connection that you want to change, and then click Properties. At the same time make sure there’s not internet connection to the computer (turn off the Wifi or disconnect the internet cable from the computer)

image005.jpg


Here you can modify the IP of your computer.

4. Click the Networking tab. Go to Internet Protocol Version 4 (TCP/IPv4) and then click Properties.

image007.jpg


Click Properties.

5. Modify the computer’s IP address to: 192.0.0.128, Subnet mask: 255.255.255.0. This step is crucial.

image009.jpg


Set the settings as shown above.

6. Go to the TFTP folder and double click tftpserv.exe

image011.jpg


Run the TFTP server.

7. You should see the same screen as shown below. If you see there 192.0.0.128 it means you’re on the right path.

image013.jpg


When you run the TFTP server you should be able to see 192.0.0.128.

8. Plug the Ethernet cable on the camera, then the power cable. If your switch is PoE, then there’s no need to power the camera separately (via a power adapter). Note: The camera should be plugged in the router or in any other switch. It must be on the same network as the computer.

9. The TFTP tool will automatically detect the camera’s IP address and it will start with the update process. Be patience as this will take about 2 or 5 min. No additional operation is needed.

image015.jpg


Wait for the procedure to finish.

6. “System Update Completed“ message will show up when the procedure is done. Close the TFTP window, unplug the camera, and then plug it back on. Go to SADP and the camera will show up there inactive. You can modify the IP and access the camera via web browser.

image017.jpg


The reflash is completed when you see “System Update Completed”.

Note: Don’t forget to remove the 192.0.0.128 IP address you assigned to your PC/laptop, otherwise the internet may not work.
 

Attachments

As an Amazon Associate IPCamTalk earns from qualifying purchases.
After tinkering with batch configuration here my EZVIZ software on Android and Windows shows my camera disconnected these days. It does show my three test cameras but they are all disconnected. If I do a LAN view I can see them all.

For Alexa Show not using the EZViz application due to reported issues on how slow it is. I am using the Monocle IP camera application with Alexa Show except that it doesn't work with my doorbell at this time. It does work with my other two test Hikvision cameras. The Monocle IP camera application does a reverse local proxy and does not use the cloud to access your camera. It is really fast with my Amazon Show.

I found that adding the @fakefmtp command to the TAGS section on the Monocle Gateway configuration allows the doorbell camera to display. It is somewhat slower than the other cameras to display but it does work. I haven't tested it for audio though.


IMG_8994 (1).jpeg