/Streaming/Channels/1?transportmode=unicast&profile=Profile_1
But i also just tried vbr instead of cbr and it seems to like that maybe I should of said what settings i was using on the doorbell first.
New RCA HSDB2A 3MP Doorbell IP Camera
- Thread starter fleece
- Start date
But i also just tried vbr instead of cbr and it seems to like that maybe I should of said what settings i was using on the doorbell first.
onvif discovery was done after as I deleted the camera and then re-added to blue iris after upgrade to hikvison firmware
Last edited:
alexdelprete
Getting comfortable
alexdelprete
Getting comfortable
That's good. I think there's also a way to "refresh/rediscover" without deleting it from BI.
I also tried VBR and it doesn't work actually it just switches streams again or freezes its super weird when using the ezviz app or alexa integration I have to use batch config to change a setting and then the stream is fixed again, Does @David L use the hikconnect app or ezviz or just use blueiris for the notifications . I may switch back to the ezviz firmware and use rtsp or use the onvif triggers with blue iris to send alerts
Ya, I did the same thing, and yes, BI does NOT like the rez change AT ALL. I ended up doing the force rez on the VIDEO tab as well. I thought it was some how changeing BI config settings on you when I first seen the post...
I use BI and EZVIZ App
Also noticed you are missing the port on your IP. Did you redo Find/inspect... when you changed fw? May try that.
alexdelprete
Getting comfortable
He says it happens only when he opens the stream with EZVIZ app or Alexa.
1. IIRC, the powerkit was already disassembled long time ago, and pics were posted in this thread
2. IIRC, there hasn't been ONE case in which the little box created issue, got broken, failed, etc.
3. All the people with chime issues that were sent a replacement powerkit by ezviz support DIDN'T solve the issue. The powerkit wasn't the problem.
4. In the official ezviz documentation, in the 101 of this thread, in hundreds of old posts, it always clearly stated that the powerkit installation is MANDATORY when you have a traditional chime. It's some kind of "voltage regulator"
5. I don't use traditional chimes, but sensors to intercept the button press and announce that someone is at the gate, and even with sensors I had to install the powerkit otherwise the sensors wouldn't intercept the voltage change
So please, don't use that tone next time, you think you've discovered something new just because you've probably only recently joined this thread and didn't read all the OLD discussions about this topic. And I can assure you that there are people in this thread that know what they're talking about and spent many days tinkering with this doorbell.
It would be interesting to know, through your ability to use a scope, how it exactly works and what exactly happens when you press the button and the cycle completes.
Guess you missed the "not too be a jerk but we all need to stop posting things we have no clue about like its a fact that we know! "
1& 2) Never said it did and how would you know if the fuse was popped? My system works with and with out the power kit. The mechanical chime sounds a tad bit diff because the first tone does not pop off as loud but other wise works fine as does the extender connected to the wires for the wireless mp3 chime that is up stairs.
3) Never said the power kit fixed or was ANY kind of problem, never said my post had anything to do with what most are now thinking is a firmware or software problem that a lot of people are now having out of the blue from a system that was working fine. If some one has a chime that does need it and the fuse popped that person would have a chime that is not working. This is the FIRST time I have typed that but it is a FACT! BASED ON YOUR POSTED INFO
4) The Official documentation calls a "fuse" a "resistor" and say it is MANDATORY as well. I think it is a translation thing but who knows, you get the point.
5) Never said word one about the power kit working or not working with any sensors till this replay because YOU brought it up and YOU proved my point AGAIN. That power box COULD stop a chime or sensor from working for SOME PEOPLE! (like you) Would you like to have a blown fuse in your power kit and your system not working and some one telling you they KNOW it is NOT that box if you was here for your first time asking for help?
6) What tone would that be? You can look at the posts your self (not long ago) about the power kit being nothing electronic or nothing that can go bad or has nothing to do with a mechanical chime not working! The posts are BEFORE this new problem out of the blue people are now reporting. Just like some one (does not matter who or why) argued about a TRANSFORMER being INSIDE the VDB and voltage has nothing to do with temps. Guess what, no transformer. The higher voltage DOES get the DC-DC converter HOTTER so that was WRONG INFO just like the power kit not being some thing that could go bad or stop a door chime from working. I said WE not you, WE would include me, if I was looking to be a jerk I could have linked the posts or posted the names, or even compared them to my 10 year old kid like some one did in a post not long ago arguing some thing that was DEAD WRONG. Perhaps you could talk to them about tone?
I was in this forum back when people was asking others to buy it and see if it was any good LONG before we had any clue they are all the same hardware or a 101 or how to unbrick them. I came back after about 8 months when my mechanical chime stopped working because I burnt out the coils when I installed the 16v transformer with out checking the chime max voltage. When the next one needed 24v and I ungraded my VDB started rebooting because it started getting so hot I could not even hold it in my nand. Got lucky, others had posted about a heat problem and they helped me get it fixed with a 10v setup that fixed the problem. Now I have a POE 12vdc setup powering it with my security system and cams so it works when the power goes out and I can reset the power from my switch if needed. Thank god I did NOT pay attention to the person arguing with the person helping me because HE WAS WRONG about the voltage not being the problem.
As for the scope, I have one, I do NOT know how to use all of it yet. What I can tell you is this.
With the power kit hooked up, When the voltage drops to 0v (when you push the button) on the rising edge the power kit spikes the voltage to transformer output +0.25v for a split sec then it falls to about 1v then builds back up slower then with out the power kit being hooked up. Tested it with my 10v and 16v trans and the voltage matched up too each with a small 0.25v boost added ONLY for the short spike.
The power kit seems to spike then drag down how fast the voltage returns to full transformer voltage.
I can not give you much more info like the timings because I am still learning how to use this thing while trying not blow it or my self up as I do it.
I can tell you its safe to run the VDB on 12vdc (is about 3f hotter then 10vac) now though. No more mechanical chime is hooked up, just the wireless extender sensor for 2 wireless mp3 chimes that plug right into the AC wall outlets.
alexdelprete
Getting comfortable
Didn't miss it, it meant you knew it was a jerkie post. I was just underlining it.
in EZVIZ documentation it is clearly stated that IF you use a traditional chime you MUST use the powerkit. It's not a choice. And this is confirmed by many people on the field, including me. Yours works without? Well, you're not following the vendor's recommended installation guidelines, and also the suggestions of people in this forum. But you're free to do everything you want, as long as you don't pretend that others should NOT follow the best practices like you are doing.
No, it does not. In the kit they provide both the FUSE and the POWER-KIT. The FUSE is to be mandatorily used when you have NO CHIME connected. The POWER-KIT is mandatory when you have the chime connected. No errors of translation, the manual is very clear.
So you're admitting that you think the power-kits might be the cause of those problems now. They replaced the power-kits, and the problem was still there. Like I said, I can't remember one case in this thread where the power-kit was faulty.
Nobody ever said it's not the power-kit for sure, we always said that based on our experience, the power-kits never blew up. EZVIZ support was always WRONG when they sent power-kits as replacement, that NEVER solved the issue, so the experience we have here about the reliability of the power-kit is a FACT. You can never exclude anything, but EXPERIENCE on the field matters more than vendor's support people, IMHO.
A jerkie tone, like you admitted being in that post at the beginning.
Where did I say the power-kit is NOTHING ELECTRONIC? Show me the post please. If you don't find it, I'll wait for your apologies. I have ALWAYS said the powerkit is a voltage regulator, how can I have ever said it's nothing electronic? Check here, and there are many other posts like this: Oct 19, 2020 (ipcamtalk.com)
Yours is wrong INFO, higher voltage does not lead to hotter device. I tried with 12v, 24v at different VA, I tried also with a DC transformer, the damn camera is ALWAYS at the same temperature (HOT). It doesn't dissipate heat well. But we already made this discussion with @rafale, you can have your opinion, but don't try to accuse others to provide WRONG INFO since yours is just an opinion (and a wrong one, imho), not a fact. We agree to disagree on this point, like we disagree on the power-kit. Just don't use that tone, chill down, because you are no holder of THE TRUTH here.
Like I said: that is YOUR experience. Not mine. lower voltages didn't lower the temperature of my doorbell. Full stop. I don't want to lose 1s more to discuss about this. Since I replaced my transformer with a 24v one, my doorbell is working much much better, more stable, and the temperature is hot like it was with a 12v transformer. Full stop. This is my experience. If you're happy with your 10v, nobody will tell you to change that, but don't accuse others of spreading FALSE INFO pretending you know the truth and others get it wrong, that is pure arrogance.
This is what we expect the powerkit to do, but 0.25v looks a little bit low...are you sure about that value? In any case, thanks for the info.
I can not give you much more info like the timings because I am still learning how to use this thing while trying not blow it or my self up as I do it.
This made me laugh. Please don't blow up anything or anybody, including yourself.
I run it at 24v. Same temp as 12v: hot! But very stable.
James92TSi
n3wb
TLDR: Unbricking via TTL Serial was successful!
I was able to get connected with the TTL Serial adapter, and found that the Config file of the camera is what is causing it not to load. The magic bullet was to interrupt the boot and issue a format command to erase everything but the bootloader, then issue an update command (with sdcard inserted, having RCA firmware renamed to digicap.dav as the only file present). This loaded successfully and the doorbell booted to a blue flashing ring and voice prompt to configure via phone app.
Full details:
The USB TTL Serial adapter arrived this afternoon and I tinkered with it after work. For reference, I purchased this one which uses a Prolific chipset. Win10 picked it up and automatically installed functional drivers.
I'm already familiar with using Putty (years of IT work) but for anyone who's not, there are detailed instructions for setting up the connection on the thread I was referencing earlier about resetting Hikvision devices via TTL Serial.
Because of the packaging of the doorbell, Hik didn't put a JST-ZH connector on the 4-pin TTL Serial header. It does use the 1.5mm pin spacing of the JST-ZH connector, though. Lacking a connector and wanting a reliable connection, I temporarily soldered some 22AWG wires onto the pin pads, with a 3-pin PC fan header on the other end of the wires so I could slide the TTL adapter leads on. Not a clean soldering job at all, just going for quick, functional, and easy to desolder afterward, since I'll need to remove this in order to close up the camera case.
Not to worry, a little heat shrink to keep those wires separated.
I connected ground, TX and RX from the USB TTL adapter to the leads coming from the board.
JST Pin 1 (my black wire) -> TTL Ground (black)
JST Pin 2 (my red wire) -> TTL RX (white)
JST Pin 3 (my orange wire) -> TTL TX (green)
JST Pin 4 -> NO CONNECTION (do not connect the TTL red wire to JST pin 4. The TTL adapter outputs 5V and the camera runs at 3.3V.)
I powered it up, and my Putty window sprang to life with output from the camera. After pressing CTRL+U at the prompt to interrupt the bootloader, I found there is an update command which tries to read digicap.dav from the sdcard. I ran this, and it completed successfully and rebooted. BUT - the camera was still stuck in a boot loop, so I examined closer and found two errors:
[09 22:34:30][CONFIG][ERROR]config_file_to_json error
[09 22:34:30][CONFIG][ERROR]recover_config_file
I looked at the available commands (typing ? or help lists them) and found format - format flash except bootloader area. Sounded promising, so I executed format, followed by another update command to load the firmware from digicap.dav on the sdcard. Success! The doorbell booted to a blue ring and voice prompt.
I am going to further configure it on the RCA firmware I just loaded, flash it over to EzViz firmware, remove the EzViz logo from the video output (via Batch Config), then flash over to my final intended LaView firmware. That will get it to the same state as my other two RCA units. Once everything's done, I'll desolder my wires from the TTL header and close it up.
@davidew98 I am not really an expert on Linux and other embedded OS, but if there are any specific commands you'd like me to try to probe it with before I remove the TTL wires and close it up, let me know. In the Code block below is a listing of the commands available when the bootloader is interrupted (CTRL+U at the prompt).
I've attached the full text output from my Putty session to this post as a PDF file. For science!
I hope this helps someone who has a bricked doorbell kicking around and doesn't mind doing a little soldering and buying a $7 USB-TTL adapter to get it running again.
Code:
U-Boot 2010.06-svn-43155 (Oct 30 2018 - 10:01:33)
Find sd card.
DM9051-MAC
Hit Ctrl+u to stop autoboot: 0
HKVS # ?
? - alias for 'help'
arc_go - start application at address 'addr'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
dhcp - boot image via network using DHCP/TFTP protocol
echo - echo args to console
editenv - edit environment variable
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
format - format flash except bootloader area
go - go xxx.bin thru network
go_orig - start application at address 'addr'
gos - go xxx.bin thru serial
help - print command description/usage
iminfo - print header information for application image
imxtract- extract a part of a multi-image
loadb - load binary file over serial line (kermit mode)
loadk - load kernel to DRAM
loadm - load mini to DRAM
loads - load S-Record file over serial line
loadss - load safe system
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mmc - MMC sub system
mmcinfo - mmcinfo <dev num>-- display MMC info
mtest - simple RAM read/write test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pinctrl - Pin Ctrl
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sf - SPI flash sub-system
sleep - delay execution for some time
source - run script from memory
sspi - SPI utility commands
tftpboot- boot image via network using TFTP protocol
upa - update app image
uparc - update arc
update - update digicap.dav
updateb - update ramboot and uboot
updateu - update uboot
updevinfo- update devinfo
upf - update firmware, format and update (factory use)
upk - update uImage
upmcu - update mcu
upmini - update minisys
upram - update ramboot
upres - update res
version - print monitor version
wdt - WDT utility commands
Last edited:
Didn't miss it, it meant you knew it was a jerkie post. I was just underlining it.
in EZVIZ documentation it is clearly stated that IF you use a traditional chime you MUST use the powerkit. It's not a choice. And this is confirmed by many people on the field, including me. Yours works without? Well, you're not following the vendor's recommended installation guidelines, and also the suggestions of people in this forum. But you're free to do everything you want, as long as you don't pretend that others should NOT follow the best practices like you are doing.
No, it does not. In the kit they provide both the FUSE and the POWER-KIT. The FUSE is to be mandatorily used when you have NO CHIME connected. The POWER-KIT is mandatory when you have the chime connected. No errors of translation, the manual is very clear.
So you're admitting that you think the power-kits might be the cause of those problems now. They replaced the power-kits, and the problem was still there. Like I said, I can't remember one case in this thread where the power-kit was faulty.
Nobody ever said it's not the power-kit for sure, we always said that based on our experience, the power-kits never blew up. EZVIZ support was always WRONG when they sent power-kits as replacement, that NEVER solved the issue, so the experience we have here about the reliability of the power-kit is a FACT. You can never exclude anything, but EXPERIENCE on the field matters more than vendor's support people, IMHO.
A jerkie tone, like you admitted being in that post at the beginning.
Where did I say the power-kit is NOTHING ELECTRONIC? Show me the post please. If you don't find it, I'll wait for your apologies. I have ALWAYS said the powerkit is a voltage regulator, how can I have ever said it's nothing electronic? Check here, and there are many other posts like this: Oct 19, 2020 (ipcamtalk.com)
Yours is wrong INFO, higher voltage does not lead to hotter device. I tried with 12v, 24v at different VA, I tried also with a DC transformer, the damn camera is ALWAYS at the same temperature (HOT). It doesn't dissipate heat well. But we already made this discussion with @rafale, you can have your opinion, but don't try to accuse others to provide WRONG INFO since yours is just an opinion (and a wrong one, imho), not a fact. We agree to disagree on this point, like we disagree on the power-kit. Just don't use that tone, chill down, because you are no holder of THE TRUTH here.
Like I said: that is YOUR experience. Not mine. lower voltages didn't lower the temperature of my doorbell. Full stop. I don't want to lose 1s more to discuss about this. Since I replaced my transformer with a 24v one, my doorbell is working much much better, more stable, and the temperature is hot like it was with a 12v transformer. Full stop. This is my experience. If you're happy with your 10v, nobody will tell you to change that, but don't accuse others of spreading FALSE INFO pretending you know the truth and others get it wrong, that is pure arrogance.
This is what we expect the powerkit to do, but 0.25v looks a little bit low...are you sure about that value? In any case, thanks for the info.
This made me laugh. Please don't blow up anything or anybody, including yourself.
I run it at 24v. Same temp as 12v: hot! But very stable.
Every thing I was asking EVERY ONE to do is the same you are asking some one to do your self. (yes, this time I am saying you typed this word for word)
"This is an important thing, and we must be sure the information provided is correct, please provide some official documentation link or tell us how you measured it so we can reproduce it."
I can take some pics of the doorbell log in BI showing you the rebooting over and over again about every 10 min if you like by doing nothing more then putting it back on a 24vac (42va I think) transformer again and try to come up with a temp probe stuck too it and take some pics. Takes about 3min then it will just turn back on for another 10min or so. It was doing it for the better part of a week before some one in this forum had the same problem and helped me.
I NEVER said I was running my setup WITH OUT the power kit! "I said it does work with out it" (I tested it with out, JUST LIKE YOU DID or you would not know yours stops working) AGAIN you seem to add or skip over things people have typed AND add things no one has typed or point out some thing wrong that you are or have done again.
For the last time, I have gave no feed back to anyone on why the chimes have stopped working with this new thing going on. Mine works, I have no clue why a working chime just stops working out of the blue unless you over voltage it like I did to my 1st unit. So again, I NEVER SAID ANYTHING TO ANYONE ON THIS NEW SUBJECT and I have NEVER SAID YOU TYPED ANYTHING EVER. (except for that one line in this post that you did type or some one logged in as you did)
If your going to drag this out at the very least please get what I HAVE typed and what I have NEVER typed right before arguing about it and do it in a chat out of the open forum. Just about every thing your pointing out I typed was never typed by me. And things you have done you complaining about me commenting on but HAVE NEVER TYPED TO ANYONE THEY SHOULD DO So unless you plan on going back to some people calling others dumber then a 10 year old type posts again like we had in the past from some people and I do not see that helping ANYONE!
BTW just for fun...
Yes, the yellow highlighter was added by me, but here is the link to the pdf
Again, you just typing something does not make it a fact or true and this is just getting sad. As asked before, Let it go already please or at least do this in a private chat because this is helping NO ONE.
Last edited:
TLDR: Unbricking via TTL Serial was successful!
I was able to get connected with the TTL Serial adapter, and found that the Config file of the camera is what is causing it not to load. The magic bullet was to interrupt the boot and issue a format command to erase everything but the bootloader, then issue an update command (with sdcard inserted, having RCA firmware renamed to digicap.dav as the only file present). This loaded successfully and the doorbell booted to a blue flashing ring and voice prompt to configure via phone app.
Full details:
The USB TTL Serial adapter arrived this afternoon and I tinkered with it after work. For reference, I purchased this one which uses a Prolific chipset. Win10 picked it up and automatically installed functional drivers.
I'm already familiar with using Putty (years of IT work) but for anyone who's not, there are detailed instructions for setting up the connection on the thread I was referencing earlier about resetting Hikvision devices via TTL Serial thread I was referencing earlier about resetting Hik devices via TTL Serial.
Because of the packaging of the doorbell, Hik didn't put a JST-ZH connector on the 4-pin TTL Serial header. It does use the 1.5mm pin spacing of the JST-ZH connector, though. Lacking a connector and wanting a reliable connection, I temporarily soldered some 22AWG wires onto the pin pads, with a 3-pin PC fan header on the other end of the wires so I could slide the TTL adapter leads on. Not a clean soldering job at all, just going for quick, functional, and easy to desolder afterward, since I'll need to remove this in order to close up the camera case.
Not to worry, a little heat shrink to keep those wires separated.
I connected ground, TX and RX from the USB TTL adapter to the leads coming from the board.
JST Pin 1 (my black wire) -> TTL Ground (black)
JST Pin 2 (my red wire) -> TTL RX (white)
JST Pin 3 (my orange wire) -> TTL TX (green)
JST Pin 4 -> NO CONNECTION (do not connect the TTL red wire to JST pin 4. The TTL adapter outputs 5V and the camera runs at 3.3V.)
I powered it up, and my Putty window sprang to life with output from the camera. After pressing CTRL+U at the prompt to interrupt the bootloader, I found there is an update command which tries to read digicap.dav from the sdcard. I ran this, and it completed successfully and rebooted. BUT - the camera was still stuck in a boot loop, so I examined closer and found two errors:
[09 22:34:30][CONFIG][ERROR]config_file_to_json error
[09 22:34:30][CONFIG][ERROR]recover_config_file
I looked at the available commands (typing ? or help lists them) and found format - format flash except bootloader area. Sounded promising, so I executed format, followed by another update command to load the firmware from digicap.dav on the sdcard. Success! The doorbell booted to a blue ring and voice prompt.
I am going to further configure it on the RCA firmware I just loaded, flash it over to EzViz firmware, remove the EzViz logo from the video output (via Batch Config), then flash over to my final intended LaView firmware. That will get it to the same state as my other two RCA units. Once everything's done, I'll desolder my wires from the TTL header and close it up.
@davidew98 I am not really an expert on Linux and other embedded OS, but if there are any specific commands you'd like me to try to probe it with before I remove the TTL wires and close it up, let me know. In the Code block below is a listing of the commands available when the bootloader is interrupted (CTRL+U at the prompt).
I've attached the full text output from my Putty session to this post as a PDF file. For science!
I hope this helps someone who has a bricked doorbell kicking around and doesn't mind doing a little soldering and buying a $7 USB-TTL adapter to get it running again.
Code:U-Boot 2010.06-svn-43155 (Oct 30 2018 - 10:01:33) Find sd card. DM9051-MAC Hit Ctrl+u to stop autoboot: 0 HKVS # ? ? - alias for 'help' arc_go - start application at address 'addr' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation dhcp - boot image via network using DHCP/TFTP protocol echo - echo args to console editenv - edit environment variable fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) format - format flash except bootloader area go - go xxx.bin thru network go_orig - start application at address 'addr' gos - go xxx.bin thru serial help - print command description/usage iminfo - print header information for application image imxtract- extract a part of a multi-image loadb - load binary file over serial line (kermit mode) loadk - load kernel to DRAM loadm - load mini to DRAM loads - load S-Record file over serial line loadss - load safe system loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - mmcinfo <dev num>-- display MMC info mtest - simple RAM read/write test mw - memory write (fill) nfs - boot image via network using NFS protocol nm - memory modify (constant address) pinctrl - Pin Ctrl ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage setenv - set environment variables sf - SPI flash sub-system sleep - delay execution for some time source - run script from memory sspi - SPI utility commands tftpboot- boot image via network using TFTP protocol upa - update app image uparc - update arc update - update digicap.dav updateb - update ramboot and uboot updateu - update uboot updevinfo- update devinfo upf - update firmware, format and update (factory use) upk - update uImage upmcu - update mcu upmini - update minisys upram - update ramboot upres - update res version - print monitor version wdt - WDT utility commands
THANK YOU so much for all the time and info ! ! ! !
Now if only some one can tell me why a heater is stuck to the internal battery type that does not like to be hot....
Last edited:
Let me be clear, this device along with many other IOT devices are designed for an idiot to install. you MUST isolate if you don't want it to phone home. most IOT devices can poke a hole right thru a firewall.
let me try to elaborate. you can NOT just block people on the internet from the device, you must ALSO block the device from seeing the internet... basically think of it this way, if that VDB mac & ip was a PC could you browse the net. and this bidirectional blocking has to be on all known ports, basically a DENY ANY/ANY on that IP
look at your app CLOSELY! if the device is internet facing and you can see the VDB from app while not home then you should see 3 hours of video recorded to the cloud. look in settings related to cloud storage also. 2 options from what I remember: Free 3 hours or paid subscription.
This is out of line and out of control!
1. the power kit is required for mechanical chimes.
2. these doorbells are not designed for lower then 12 volts you should be running 12v, it's designed for a normal doorbell transformer. not sure if 24v was ever considered spec for this doorbell. the doorbell does run hot on 12v I can validate that.
What comes across serial NOW that it works from power up THRU a ring of the bell and connecting to it via app!.... Once uboot is done and it boots into firmware does serial go quite.TLDR: Unbricking via TTL Serial was successful!
I was able to get connected with the TTL Serial adapter, and found that the Config file of the camera is what is causing it not to load. The magic bullet was to interrupt the boot and issue a format command to erase everything but the bootloader, then issue an update command (with sdcard inserted, having RCA firmware renamed to digicap.dav as the only file present). This loaded successfully and the doorbell booted to a blue flashing ring and voice prompt to configure via phone app.
Full details:
The USB TTL Serial adapter arrived this afternoon and I tinkered with it after work. For reference, I purchased this one which uses a Prolific chipset. Win10 picked it up and automatically installed functional drivers.
I'm already familiar with using Putty (years of IT work) but for anyone who's not, there are detailed instructions for setting up the connection on the thread I was referencing earlier about resetting Hikvision devices via TTL Serial.
Because of the packaging of the doorbell, Hik didn't put a JST-ZH connector on the 4-pin TTL Serial header. It does use the 1.5mm pin spacing of the JST-ZH connector, though. Lacking a connector and wanting a reliable connection, I temporarily soldered some 22AWG wires onto the pin pads, with a 3-pin PC fan header on the other end of the wires so I could slide the TTL adapter leads on. Not a clean soldering job at all, just going for quick, functional, and easy to desolder afterward, since I'll need to remove this in order to close up the camera case.
Not to worry, a little heat shrink to keep those wires separated.
I connected ground, TX and RX from the USB TTL adapter to the leads coming from the board.
JST Pin 1 (my black wire) -> TTL Ground (black)
JST Pin 2 (my red wire) -> TTL RX (white)
JST Pin 3 (my orange wire) -> TTL TX (green)
JST Pin 4 -> NO CONNECTION (do not connect the TTL red wire to JST pin 4. The TTL adapter outputs 5V and the camera runs at 3.3V.)
I powered it up, and my Putty window sprang to life with output from the camera. After pressing CTRL+U at the prompt to interrupt the bootloader, I found there is an update command which tries to read digicap.dav from the sdcard. I ran this, and it completed successfully and rebooted. BUT - the camera was still stuck in a boot loop, so I examined closer and found two errors:
[09 22:34:30][CONFIG][ERROR]config_file_to_json error
[09 22:34:30][CONFIG][ERROR]recover_config_file
I looked at the available commands (typing ? or help lists them) and found format - format flash except bootloader area. Sounded promising, so I executed format, followed by another update command to load the firmware from digicap.dav on the sdcard. Success! The doorbell booted to a blue ring and voice prompt.
I am going to further configure it on the RCA firmware I just loaded, flash it over to EzViz firmware, remove the EzViz logo from the video output (via Batch Config), then flash over to my final intended LaView firmware. That will get it to the same state as my other two RCA units. Once everything's done, I'll desolder my wires from the TTL header and close it up.
@davidew98 I am not really an expert on Linux and other embedded OS, but if there are any specific commands you'd like me to try to probe it with before I remove the TTL wires and close it up, let me know. In the Code block below is a listing of the commands available when the bootloader is interrupted (CTRL+U at the prompt).
I've attached the full text output from my Putty session to this post as a PDF file. For science!
I hope this helps someone who has a bricked doorbell kicking around and doesn't mind doing a little soldering and buying a $7 USB-TTL adapter to get it running again.
Code:U-Boot 2010.06-svn-43155 (Oct 30 2018 - 10:01:33) Find sd card. DM9051-MAC Hit Ctrl+u to stop autoboot: 0 HKVS # ? ? - alias for 'help' arc_go - start application at address 'addr' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation dhcp - boot image via network using DHCP/TFTP protocol echo - echo args to console editenv - edit environment variable fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) format - format flash except bootloader area go - go xxx.bin thru network go_orig - start application at address 'addr' gos - go xxx.bin thru serial help - print command description/usage iminfo - print header information for application image imxtract- extract a part of a multi-image loadb - load binary file over serial line (kermit mode) loadk - load kernel to DRAM loadm - load mini to DRAM loads - load S-Record file over serial line loadss - load safe system loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - mmcinfo <dev num>-- display MMC info mtest - simple RAM read/write test mw - memory write (fill) nfs - boot image via network using NFS protocol nm - memory modify (constant address) pinctrl - Pin Ctrl ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage setenv - set environment variables sf - SPI flash sub-system sleep - delay execution for some time source - run script from memory sspi - SPI utility commands tftpboot- boot image via network using TFTP protocol upa - update app image uparc - update arc update - update digicap.dav updateb - update ramboot and uboot updateu - update uboot updevinfo- update devinfo upf - update firmware, format and update (factory use) upk - update uImage upmcu - update mcu upmini - update minisys upram - update ramboot upres - update res version - print monitor version wdt - WDT utility commands