Closed SmartM-ui closed 4 months ago
How did you set timezone in the yi app?
How did you set timezone in the yi app?
Hi @roleoroleo
timezone in YIhome: UTC +1:00
Plase, try to set timezone = GMT in the app. Check this post: https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/203#issuecomment-918762012
Plase, try to set timezone = GMT in the app. Check this post: #203 (comment)
Perfect. I didn't set the same value, but I set UTC +0 in the YIHome app and set the correct timezone to YI-HACK. Now the time is correct everywhere
The name should be "Coordinated universal time".
The name should be "Coordinated universal time".
That's right, I set Coordinated universal time! Thanks
@roleoroleo Am I missing a step? I'm getting confused because it's not working as expected... Yi Home 1080p IFUS 9.0.36.02_202105081647 y211ga
UPDATE: Is this part something on the Yi-Hack side that could be updated, or something with Yi's firmware, which can't be touched? https://forum.filezilla-project.org/viewtopic.php?t=48775 https://forum.filezilla-project.org/viewtopic.php?t=37273#p136743 I see a few threads about servers not handling MDTM correctly.
Even if I disable NTPD, times don't seem to match up, universally. There seem to be different variables. For example, if the time is December 4, 2021 23:05:00 (GMT-6) and I've set the following and then rebooted: Yi-Hack: CST6CDT,M3.2.0,M11.1.0 Yi-Hack NTPD: disabled Yi app: Coordinated universal time
I'm rounding off numbers and keeping them consistent after observing the changes, for simplicity in showing the issue... Bolded are changes. I'm sorry for the wall of text, but I wanted you to see what changes.
My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes, not read/write) modified time shows "12/4/2021 17:05:00" (6 hours behind)
Now, if I remove the timezone set in Yi-Hack configuration page, save, power cycle completely (not a soft reboot): My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sun Dec 5 05:05:00 GMT 2021" (6 hours ahead) Recording folder being recorded to is "2021Y12M05D05H" (6 hours ahead) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 23:05:00" (correct)
Now, if I change the Yi app timezone to UTC-06:00, power cycle, nothing seems to change.
Now, if I change the Yi-Hack timezone to CST6CDT,M3.2.0,M11.1.0, save, power cycle: My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 17:05:00" (6 hours behind)
Now, if I "Disable Cloud", "Enable Recording without Cloud", "Enable NTPD", save, power cycle: My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 18:05:00" (5 hours behind)
Now, if I change the Yi app timezone to Coordinated universal time, power cycle, nothing changes.
Now, if I re-enable "Cloud" (keeping NTPD enabled), save, power cycle: My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 18:05:00" (6 hours behind)
@roleoroleo , I am also having issues with timestamp / time zone on my Yi 1080 Home.
BUT.... the issue only presents itself on the date/timestamp overlay that is overlaid on the rtsp stream.
My setup is:
Yi 1080 Home, QFUS
Using Yi App: Time zone set to UTC +0000
Yi Hack web: set time zone to my correct time zone, disabled cloud, enabled NPT time sync, reboot.
The result:
Yi Hack web reports the local time correctly - 10:14am (I am GMT-4, so GMT would be 2:14pm) However, the timestamp overlay on the rtsp stream shows 8 hours ahead! It's as if it has added 4 hours to GMT, rather than subtracted 4 hours. (it is showing 18:14, as shown below).
I have tried different combinations of Yi time zone, NTP on/off, Yi Hack time zone, and cannot get these to agree.
Your problem is different because is related to the overlay. And I don't know hot to solve it because it depends on the yi firmware.
But check if the "rmm" process has the correct environment variables.
Login with ssh.
Find the process id: ps | grep rmm
Check the environment: cat /proc/<PID>/environ
Thanks for the quick reply - appreciate it. The output is below. Looks cryptic to me, but maybe something will jump out at you.
TZ variable is absent. This is not ok. What is yout timezone setting in the web interface?
pasted from web interface: EST5EDT,M3.2.0,M11.1.0 (this is the America / Toronto TZ string)
I checked the script and I can't understand.
Try another command:
cat /proc/PID/environ | tr '\0' '\n'
di you fix it? i habe UTC-0 in Yi app. my timestamp up left in the video is incorret.
when i enable cloud feature. the time is correct.
I don't know how to fix it, at the moment.
FWIW I found using the setting GMT in the Yi app and TZ in Yi-Hack breaks the seek time in the Yi android app when trying to playback video. For those using RTSP and personal recorders I guess it doesn't matter but I ended up changing both yi app and yi hack to the proper timezone and only applying the timezone inline where needed in system.sh. For example with httpd, although others might be added.
export TZ=$(get_config TIMEZONE)
if [[ $(get_config HTTPD) == "yes" ]] ; then
mkdir -p /tmp/sd/record
mkdir -p /tmp/sd/yi-hack/www/record
mount --bind /tmp/sd/record /tmp/sd/yi-hack/www/record
httpd -p $HTTPD_PORT -h $YI_HACK_PREFIX/www/ -c /tmp/httpd.conf
fi
# maybe some other apps here too
export -n TZ
But what works for me might not work for others and I don't know if Yi use daylight savings, maybe someone with daylight savings can shed some light? :)
Example with above and +7hrs set for both Yi Hack (where needed) and the Yi app. The r30gb needs a workaround but the other camera's b091qp/h60ga seem fine.
I wanted to try to do the opposite: run rmm without TZ. But probably your solution is better.
To be clear rmm doesn't have the 'TZ' variable set and the yi-app time zone doesn't set the TZ variable but applies an offset as was commented here https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/203#issuecomment-920509721
@SeriousPat Try this system.sh (overwrite the original one). Set your timezone in the app (instead of UTC) and in the web gui. Reboot and check:
What about the date/time of the table in the "Events" page. Is it ok? Or is it shifted by an offset? I changed the system.sh and I reconfigured the correct time in the app. Now, the time of the events is not ok.
Not sure who you are asking, if it's me then my event page is fine. Don't use MQTT, CRON and SSH seems to do it's own thing with time, as I said before I'm a noob with Linux and not that much better with Windows so don't know.
TBH just telnet/ssh and ftp would be enough for me with these camera's but it's nice to learn so I try a few things. Even learning a little arm and wrote a test grabber with piped aac and video streams from fshare. Audio was a bit hit and miss with my modification to rtsp_server_yi, the newer one you submitted works better than my attempt. Not sure what to do with videofile.cpp to get the 265 working, all those brackets and semi colons do my head in. :/
Not sure what to do with videofile.cpp to get the 265 working, all those brackets and semi colons do my head in. :/
Check the last commit: https://github.com/roleoroleo/RtspServer/tree/yi
Forgot to mention I'm not using ONVIF either and RTSP is being used for learning purposes, no dedicated box for it's use. Cloud is enabled but no cloud storage.
Check the last commit: https://github.com/roleoroleo/RtspServer/tree/yi
Cool, will try it out later today. Will start another thread under discussions.
Thanks for the excellent software. Its magical to be able to ssh and play around into the camera.
Am facing similar date time problems.
I moved the export TZ
to just before the rmm
is executed, this seems to fix the folder label. However the overlay on top left is still 8 hours behind.
FYI: I am not using Yi App at all and all cloud features are disabled. Is there anyway to modify the firmware timezone offset? I am looking through #203 . Any tips?
I don't know how to set the internal timezone (I mean the same that the app changes) without using the app. You should configre the app just for the time to set the cam.
I'm having the same issue. The timestamp on the rtsp feed is off by 5hrs, whenever I disable cloud. I have the yi app set to UTC. If I set the timezone to EST (which should subtract 5 hrs from UTC), it adds 5 hours more to the timestamp, so it shows a time that is 10hrs ahead. I tried multiple combinations of turning off ntdp, timezones, reboot cycles, but the timestamp seems to be always off unless I don't disable cloud.
Is your TZ positive or negative?
It's supposed to be negative... my TZ is EST5 (Eastern time, which UTC - 5 hr)
Try to overwrite 2 files contained inside this archive: patch.tar.gz
/tmp/sd/yi-hack/bin/set_tz_offset /tmp/sd/yi-hack/script/system.sh
Thanks a lot, I'll try that. Do I just ssh into the cam and overwrite those files, and reboot?, or Do I turn off the cam, take the micro sd and change the files in my computer, and then power on the cam?
As you prefer. Normally I use ftp. No need to change permissions because the file system is a fat32. A reboot is required.
I can confirm that these 2 files corrects the issue! Beautiful!
Thanks @roleoroleo .... greatly appreciated!
the patch works!!! Thanks a lot @roleoroleo, no more incorrect timestamp!
Sadly, the system.sh file crashes both of my cameras on the current F/W (0.2.5) (model: y211ga) Back to normal on one my TZ is -5 but the camera stamp is showing +5. I can't reach the other camera atm to reset it and verify it is the same.
Pay attention when you copy the file to the cam. The file must be in linux format (LF line termination).
Pay attention when you copy the file to the cam. The file must be in linux format (LF line termination).
That should be easy since my daily is PopOs 😊 When it failed I also opened it up in VSCode to see what's up and I saw all \n no \r
Please, check this commit: https://github.com/roleoroleo/yi-hack-Allwinner-v2/commit/4db939ee69d7b134313dd2610be2b71cc328bf32
Please, check this commit: 4db939e
Just applied, if it fails, I only have 1 more shot til much later. At work right now. 😊 Technology is great.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
FWIW I found using the setting GMT in the Yi app and TZ in Yi-Hack breaks the seek time in the Yi android app when trying to playback video. For those using RTSP and personal recorders I guess it doesn't matter but I ended up changing both yi app and yi hack to the proper timezone and only applying the timezone inline where needed in system.sh. For example with httpd, although others might be added.
Hello former user (@ghost) who wrote this post, did you obtain this result when Cloud was disable? I meet trouble to set the good timezone for the built-in YI timestamp (time OSD) in the upper left (#606). Do you have any idea how to set timezone about built-in Yi timestamp (time OSD) in the upper left?
Hi, I applied the patch, but as soon as I set TIMEZONE to anything, the camera wouldn't boot.
I was trying the TZP_SET calculation in /bin/sh, and I kept getting a 'bad substitution' with the ${TZP:0:1} syntax.
I got it to work using sed:
TZP_SET=$(echo $TZP | sed 's/\(.\)/\1 /g' | awk '{ print ($1($2$3)*3600+($4$5)*60) }')
My camera boots now and the times seem to be correct.
Sadly, it's not doing motion detection anymore though, but that's probably a different issue.
Thanks -chuck
I was trying the TZP_SET calculation in /bin/sh, and I kept getting a 'bad substitution' with the ${TZP:0:1} syntax.
This is strange. What happens if you run the following commands?
root@yi-hack:~# export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3
root@yi-hack:~# export TZP=$(TZ=$TIMEZONE date +%z)
root@yi-hack:~# export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$2*3600+$3*60) }')
root@yi-hack:~# echo $TZP_SET
Hi,
/bin/sh sh$ export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3 sh$ export TZP=$(TZ=$TIMEZONE date +%z) sh$ export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$23600+$360) }') sh: 3: Bad substitution sh$ echo $TZP_SET
sh$
That syntax seems to work in bash, not sh though.
/bin/bash bash$ export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3 bash$ export TZP=$(TZ=$TIMEZONE date +%z) bash$ export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ( $1$23600+$360) }') bash$ echo $TZP_SET +7200 bash$
Thanks -chuck
On Thursday, June 22, 2023 at 10:46:01 PM PDT, roleo @.***> wrote:
  I was trying the TZP_SET calculation in /bin/sh, and I kept getting a 'bad substitution' with the ${TZP:0:1} syntax.
This is strange. What happens if you run the followin commands? @.:~# export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3 @.:~# export TZP=$(TZ=$TIMEZONE date +%z) @.:~# export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$23600+$360) }') @.:~# echo $TZP_SET
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Sorry bu I don't understand, inside the cam sh and bash are symbolic links to ash. Where are you running, these commands?
Hi
Yes, sorry, I was running them on a linux machine, I tried it on the camera there is no error.
Now I'm not sure why the camera wasn't booting with that code in there.
It's working now..
Thanks -chuck
Try to overwrite 2 files contained inside this archive: patch.tar.gz
/tmp/sd/yi-hack/bin/set_tz_offset /tmp/sd/yi-hack/script/system.sh
I can confirm that the set_tz_offset in this patch fixes the OSD timestamp for a negative tz offset (CST/CDT) but does not appear to be included in the latest version (0.2.9). I tested this on RFUS both Indoor (y211ga) and Outdoor (h30ga) cameras running version 0.2.9. Note: I did not need to replace system.sh.
To get this to work:
This is weird. I included the fixes in the master branch and tested again in this moment. It works with my h52ga (0.2.9) using "CST6CDT,M3.2.0,M11.1.0".
Please run the commands in this post, using your timezone and check the output.
@roleoroleo I actually did try those commands prior to replacing set_tz_offset on 0.2.7 and 0.2.9 and it always gave the correct offset for me of -18000. This lead me to think that the issue was with set_tz_offset and not system.sh. I should have included this in my last post but I am also using "CST6CDT,M3.2.0,M11.1.0" as my Timezone in the UI.
Here are the commands ran on one of my cameras: root@yicamout:~# export TIMEZONE=CST6CDT,M3.2.0,M11.1.0 root@yicamout:~# export TZP=$(TZ=$TIMEZONE date +%z) root@yicamout:~# export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$23600+$360) }') root@yicamout:~# echo $TZP_SET -18000
I did some more testing and tried replacing set_tz_offset from different patches on one of my RFUS cameras running y211ga 0.2.9 and below are the resulting OSD: From patch.tar.gz: OSD is UTC-5 (correct) y211ga (0.2.9): OSD is UTC+5 h52ga (0.2.9): OSD is UTC+5 y211ga (0.2.7): OSD is UTC+5 y211ga (0.2.6): OSD is UTC-5 (correct) y211ga (0.2.5): OSD is UTC-5 (correct) y211ga (0.2.4): OSD is UTC-5 (correct)
Ok, the last try:
set_tz_offset writes 4 bytes to the file /tmp/mmap.info
You can check if it writes properly reading the file:
hexdump -C -s 0x04e0 -n 4 /tmp/mmap.info
The offset depends on the model and it's in the following table:
{ 0x4a0, 1 }, // Y20GA_9
{ 0x4a4, 1 }, // Y20GA_12
{ 0x4a0, 1 }, // Y25GA
{ 0x4a0, 1 }, // Y30QA
{ 0x4e0, 1 }, // H30GA_9
{ 0x56c, 0 }, // H30GA_11 Already present
{ 0x4e0, 1 }, // H51GA
{ 0x4e0, 1 }, // H52GA
{ 0x560, 0 }, // H60GA Already present
{ 0x4e0, 1 }, // Q321BR_LSX
{ 0x4e0, 1 }, // QG311R
{ 0x4e0, 1 }, // R30GB
{ 0x56c, 0 }, // R35GB Already present
{ 0x560, 0 }, // R40GA Already present
{ 0x4e0, 1 }, // Y211GA_9
{ 0x570, 0 }, // Y211GA_12 Already present
{ 0x4e0, 1 }, // Y21GA_9
{ 0x564, 0 }, // Y21GA_12 Already present
{ 0x4e0, 1 }, // Y28GA
{ 0x56c, 0 }, // Y291GA_9 Already present
{ 0x570, 0 }, // Y291GA_12 Already present
{ 0x4e0, 1 }, // Y29GA
{ 0x000, 0 } // B091QP 0x560 or 0x56c but already present
Try to run set_tz_offset and check if the number is ok. For example:
root@yi-hack-h52ga:~# set_tz_offset -c tz_offset_osd -m h52ga -f 9 -v -18000
root@yi-hack-h52ga:~# hexdump -C -s 0x04e0 -n 4 /tmp/mmap.info
000004e0 b0 b9 ff ff |....|
000004e4
Hi, By leaving the timezone setting blank, the date in the event records have the correct date (real time 00.56 - Time reported: 00:56):
but the local time is two hours behind (real time sep 03 01:02:23 - time reported: sep 02 23:02:23
and also in the motion_files (see the end date) it is two hours behind (Real Time: 03.09.2021 00:58:22 - Time Reported: 2021.09.02 22:57:12)
If I set the timezone with the Italian value, the date in the event log is two hours ahead.
How should I set the value for the timezone to have a synchronization of all dates / times?
Thanks