Oh yeah I think I needed to set my VM to bridged network so it was on the same subnet as the camera.
Oh yeah I think I needed to set my VM to bridged network so it was on the same subnet as the camera.
I think I found my culprit (n00b error = not setting the binary to executable). Is there any other way to revive the camera without using UART? I'm still waiting on my China delivery...
Netherlands right? (not sure if this is allowed or not): 123-3D.nl - 3D-printers | kits | parts | filament
4,50 without shipping
Btw, for audio, there is the HiMPP IPC V2.0 Media Processing Software Development Reference.pdf document which details how to play audio on the device. Long story short: you need to alter the raw audio streams a bit, but there is sample code in it for doing so.
Yesterday my UART TTL device arrived and I was able to chmod +x the patched npc binary. After this, the cam seems to be working.
Had/have some trouble adding the device to the YooSee app but the Synology finds the camera (with what seems to be a steady 15FPS stream) and Telnet is open!
Seems I still have some work to do with permission settings because during pairing the "Du Du" sound wasn't playing and I can't get the chime to link.
Had/have some trouble adding the device to the YooSee app but the Synology finds the camera (with what seems to be a steady 15FPS stream) and Telnet is open!
Seems I still have some work to do with permission settings because during pairing the "Du Du" sound wasn't playing and I can't get the chime to link.
I haven't visited this thread for a long time now. As you keep asking about things that I have done 2 years ago I decided to spend some time to describe my doorbell mod in detail. For two years it worked without any issue, thus can be recommended as a proven solution. Today I collected all info and made a public repository on Github where you can find all files and project documentation. For obvious reasons I cannot publish a modded FW package there. It is the only missing part left for your own research. Hope it helps.
TNX!!! I understand correctly that I can do without UART TTL if I download the original firmware 13.01.00.98, unpack it, add a telnet and pack it with the specified program (Firmware packing tools by @zzerrg). Hence the question Is there a link to the original firmware?) Will the newer firmware on the doorbell allow you to flash it old modified firmware?
UPD: if someone can share the firmware with the included telnet as described by s00025, please contact me (you can in telegram @sitx83) thanks in advance
Last edited:
Hi, yes you understand it right. You can download the official firmware package from the manufacturer's site using the following link:
I think a careful search can bring you even a telnet enabled firmware, not sure only what version... However... it would be safer to learn making your own packages.
Regarding your question on downgrade the newer FW versions -- I believe the upgrade method is coded into ROM and cannot be changed by newer updates. So the existence of a properly named file on a SD card will always trigger an update. But it is only my guess.
Last edited:
To confirm: Yes, a properly named update file on the SD card will be installed when using the App of YooSee to upgrade the firmware.
In the meantime, (thanks @sp00025 for your GitHub explanation) my patch is still running.
Welcome to HiLinux.
# /mnt/disc1/busybox uptime
09:58:51 up 2 days, 17:01, 0 users, load average: 5.96, 6.24, 6.18
So I am past the 24hr check for a reboot to occur, waiting to see if it also passes the 3-day check. The device is still disconnected from WAN (after initial setup) and the timestamp seems alright.
In the meantime, (thanks @sp00025 for your GitHub explanation) my patch is still running.
Welcome to HiLinux.
# /mnt/disc1/busybox uptime
09:58:51 up 2 days, 17:01, 0 users, load average: 5.96, 6.24, 6.18
So I am past the 24hr check for a reboot to occur, waiting to see if it also passes the 3-day check. The device is still disconnected from WAN (after initial setup) and the timestamp seems alright.
The problem with this HiSilicon Linux is that it is not stable. I suspect it is not Linux, but rather the npc app coded by an unknown artisan. It may reboot every now and then. If you use it, say to watch RTSP video (which it gives) often, things happen... Not to miss some visitors I made it self reboot with cron fairly often...
@petervk, I want to use your solution with sending a MQTT message upon reading "sHiRegCmd.dwBaseAddr = 0x20650000 0x2004".
Using cat /proc/kmsg and grep on the above, I can trigger the button press but I cannot get the camera to send to my MQTT broker running in Docker on my Synology. Any thoughts?
Using cat /proc/kmsg and grep on the above, I can trigger the button press but I cannot get the camera to send to my MQTT broker running in Docker on my Synology. Any thoughts?
Home Assistant + Doorbell + MQTT + Synology all working! Also no reboots for more than 3 days.
@sp00025 can you tell me how to solve the problem? in your cron, the call reboot every hour at 15 minutes) and the first call in doorbell after the reboot for some reason in the telegram always sends me an old photo(last before reboot) (( the delay of a few seconds in the script(send_photo_telegram) did not help
Rebooting once in an hour is an extreme. It is given as a cron example. Perhaps if a reboot is needed the best way do it once a day in night time when ringing is not likely.
I understand, but the problem is that after the reboot, it doesn't matter how much time has passed after it (10 minutes or 8 hours), the first doorbell ringing gave an old photo. But if before the first call I went to watch the video through the android application, then the first call work well. Apparently, at the first call, some kind of initialization occurs. I had to add an extra delay on the first call to the doorbellto send a photo at the first call.
maybe this does not happen for you, since you make a request to the MQTT broker before sending the photo.(this in itself gives a delay) or my SD is so slow
Bash:
FIRST=/mnt/disc1/MONITORING/first_call
touch $FIRST
# Monitor the npc log for a push button message
while true;
do
if /mnt/disc1/busybox grep -q "keyup" /npc/myfifo
then
if [ -f "$FIRST" ]
then
echo "$FIRST exists."
rm $FIRST
/mnt/disc1/busybox sleep 4
else
echo "$FIRST does not exist."
fi
echo "Button is pushed"
/mnt/disc1/MONITORING/send_pic_telegram
fi
/mnt/disc1/busybox sleep 2
doneHi Folks,
I also wanted to continue using my existing wired ~8V-chime in parallel to the doorbells video-stream to my Synology. As the 433MHz-receiver is still on its way from china, I played around with the doorbell and found an easy solution.
I'm using a 5V-relais with transistor-input-gate that was still in a box. I've connected the +5V and GND to the 433MHz breakout-board and grabbed the signal-line direct from the button. As the button is operated at +2.2V only, I had to adjust the working-point of the PNP-transistor by adding a 220 Ohm resistor on the base towards +5V (red circle on the relais-picture, connecting the right sides of the 2 bottom 1k resistors).
In order to reuse the existing connector, the red wire connects to GND, the brown to +5V and the yellow to the button.
I also wanted to continue using my existing wired ~8V-chime in parallel to the doorbells video-stream to my Synology. As the 433MHz-receiver is still on its way from china, I played around with the doorbell and found an easy solution.
I'm using a 5V-relais with transistor-input-gate that was still in a box. I've connected the +5V and GND to the 433MHz breakout-board and grabbed the signal-line direct from the button. As the button is operated at +2.2V only, I had to adjust the working-point of the PNP-transistor by adding a 220 Ohm resistor on the base towards +5V (red circle on the relais-picture, connecting the right sides of the 2 bottom 1k resistors).
In order to reuse the existing connector, the red wire connects to GND, the brown to +5V and the yellow to the button.
Last edited:
It can be indeed a slow SD card, and some more actions by npc on the first ring, but in any case the app needs to start taking snapshots on alarm and write those to the SD. For some strange reason on my device 12 shots are taken sequentially on each ring. To me it is a waste, and 2-3 would be enough.
A solution with a program delay seems a dirty hack. Perhaps better would be finding something in the log that better represents a needed moment of time. It is possible now to analyse the log and catch any pattern from it. Interesting would be to compare log messages immediately after a keypress in both cases: the first and the second ring. Please note, that the "keyup" event can be not the best match for the purpose -- it is dependent on how long the visitor is holding a button down. I noticed that some people pushing the button too shortly and it does not ring at all... Perhaps some kind of debounce is implemented in the code which we cannot change.