I have some devices that display the time. The time is sent to the device over NTP and this is relayed to the rest of the unit via TuyaMCU.
This works fine. ntp_timeZoneOfs is used to set the timezone.
BUT: Australia has daylight savings. I need to go in and adjust this offset in autoexec.bat code twice a year on about 5 devices.
So, I have been looking to see if the NTP driver can handle daylight savings. looks It cant.
Can I do it via autoexec.bat scripting? Theoretically I could wait for the first NTP sync, then check if the date is within a range and set ntp_timeZoneOfs accordingly. But, I don't know how I achieve this without ANDs and ORs or nested IF's
So: Are there any AND or OR operators? Can I make code blocks? Is it possible to have nested if's?
There seems to be plenty of rather advanced examples but very limited documentation about how scripting works. Have I missed the scripting documentation?
Do you think it is possible to set the NTP offset based on date, through scripting or some other mechanism?
I imagine the NTP driver could be modified. Give it a base offset, daylight saving start date, daylight saving end date, daylight saving offset for example:
ntp_timeZoneOfs = 10
// Daylight saving, when active, adds 1 hr
ntp_daylightSavingOfs = 1
// Add daylight saving offset: October, sunday, 1st <day> of the month, 2am
ntp_setDaylightSavingStart oct sun 1 02:00
// Rem daylight saving offset: April, sunday, 1st <day> of the month, 2am
ntp_setDaylightSavingEnd apr sun 1 02:00
Needs to be expressed in local time to cover the possibility that the 1st of the the month falls on a sunday
Time whether universal or astronomical has a deep meaning, and our 'civil' time will not eliminate it.
In my opinion, certain devices should work in universal time without summer/winter time. E.g. in an automation system "something" happened between 2:00 and 3:00 a few days ago - there is no way to express this in jumping "civil" time.
NTP rightly works as it does - in my opinion. The desire to change it stems from erroneous assumptions elsewhere
And the conversion to local is, in my opinion, a matter of PRESENTATION at the viewer's interface, they may want it (they often do) or they may not.
>>21301146 You're not wrong. For logging UTC is fine, even preferable. But, in this case the time is displayed on LCD screens throughout my house. It is for presentation. Yes, the main purpose of these devices is to log temperature and humidity, but if they are going to display time, I want it to be useful and correct. If we have an option for setting offset, it's not too much of a stretch to add in daylight saving adjustments The device on elektroda
It would be nice to have timezone support, but that probably takes too much space in flash to do properly....
If supports && and || operators , so it should be possible to write a script to do timezone change. Except that it might not be exactly correct during the changeover hours, but that should be ok.
I'll try to do an example later this weeek
but that probably takes too much space in flash to do properly
That depends. I think it's quite possible with a decent memory footprint:
You will need to code the DST "rules" (e.g. in Europe "start last sun in march at 2 local time" and "end last sun in October at 3 local (dst) time") and a function to convert this to timestamps (like e.g. tasmotas "RuleToTime").
I did a realisation of the code, you can find the relevant parts starting here:
Yeah, if its up to the user to specify the daylight saving rules, unlike windows linux that maintain a database of selectable timezones, I can't imagine it would take much flash.
I'll have to brush up on my C and read your code.
If I were to write it, I'd do something like this:
Start with NTP supplied UTC time.
Apply base timezone offset.
If that time is within the range of daylight saving time:
Apply the daylight savings offset.
To calculate the start and end of the daylight saving period based on days, what you'd need is a reliable function to calculate the day of the week from a date. Then:
Start with NTP supplied UTC time.
Apply base timezone offset. (incase you've specified a day in the first week of January)
Calculate what day of the week the 1st of the specified month is for the current year. (ie in this example, what day of the week October 1st is)
Compute the day of of the month based on the rule (1 + [specified day of the week index] - [1st week day of month index] - + 7*(1-[occurrence] if [specified day of the week index] > [1st week day of month index] + 7)
For example, say Monday to Sunday are indexed 0 to 6, we want the first Sunday of October. Say, the 1st of October is Tuesday:
The 1st of of October is Tue and therefore gets the index 1. Specified day is 1st Sunday, index 0. 1 !> 6
Day = 1 + 6 - 1 + 7*(1-1) = 6th
Say Sunday to Saturday are indexed 0 to 6:
The 1st of of October is Tue and therefore gets the index 2. Specified day is 1st Sunday, index 6. 2 > 0
Day = 1 + 0 - 2 + 7*(1-1) + 7 = 6th
You could do something similar if you needed the last day in a certain month.
EDIT: A quick read reveals that this is basically what you've done
You might be able to specify that in the function call with negative indexing, like python
The basic idea was to enable time keeping without network connection (without NTP), so this is the focus of the branch.
This made it necessary to move a lot of functions to a "neutral" code, for most time related functions were flagged as "ntp_XY" for this was the only time source....
You can e.g. set the clock simply to the browsers clock by clicking a link in the GUI.
Timezone settings are done with a new (and kind of complex) command clock_setConfig (at least I tried to explain it in the source code, I can also give the needed code for a region).
O.k.. let's start, but I'm afraid it will not directly be shown on the display, I'll need to do some adjustments (if I got it right, tuya clock is "set" by ntp time, which actually is not set by my DST code.)
But this can be changed ...
Clock_SetConfig 99,1,1,4,1,3,600,1,10,1,2,60
Meaning:
99: Use DST
1: Southern Hemisphere
1,4,1,3: DST ends / standard/winter time starts at first Aprils sunday at 3 (local summer time)
(yes, sounds a bit strange, but the words should match the numbers ;-))
600: during "standard" time you are 600 Minutes = 10 hours ahead of UTC
1,10,1,2: DST starts at first Octobers sunday at 2 local time
60: DST is 60 minutes ahead of standard time
That looks o.k. for me
The settings of "Clock_SetConfig ..." are kept in flash, so you only need to set them once, unless you need a change.
Actually DST is not used with NTP (to keep NTP exactly working as before).
To test the Clock without NTP you can "fake" any time you whant by setting the time with an HTTP-Request:
//Sydney tome zone
alias winter_time ntp_timeZoneOfs 10
alias summer_time ntp_timeZoneOfs 11
summer_time
alias check1 if $month>4 then winter_time
alias check2 if $month==4&&$mday-$day>0&&$day>0 then winter_time
alias check3 if $month==4&&$mday-$day>0&&$day==0&&$hour>=3 then winter_time
alias check4 if $month>10 then summer_time
alias check5 if $month==10&&$mday-$day>0&&$day>0 then summer_time
alias check6 if $month==10&&$mday-$day>0&&$day==0&&$hour>=3 then summer_time
alias set_time backlog check1;check2;check3;check4;check5;check6
waitfor NTPState 1
set_time
addClockEvent 04:00 0xff 1 set_time
The tricky part is $mday - $day being positive on first Sunday or later which is what we need for time zone change
Good work!
Just one additional note: The script should work with the release version, so no need for the automated approach in the alternate firmware version.
Added after 7 [hours] 46 [minutes]:
miegapele wrote:
addClockEvent 04:00 0xff 1 set_time
Since we did call "set_time" once before the recurring event, we can be sure, the time is set correctly to winter_time/summer_time.
So if I'm not missing something, it should be o.k to do the recurring event
only on Sundays
at 3:01
so we have a maximum "derivation" for 1:01 hours?
We always will have the event called twice when turning time back, no matter when
Had a difficult time using cloudcutter on these units for some reason. Eventually got there. I think running it off the VM on my main machine was changing modes on the WiFi device too slowly. Worked better on a dedicated Linux machine (that I had to set up 😒)
Anyway, keen to try both approaches now I can update the firmware easily.
But hey, are there any docs that describe the autoexec "language"?? Really keen to get an answer on that. Here is the list of constants, functions, etc and a few examples but nothing more general, like list of operators, setting variables, i.e. general syntax. Is it just bash? A simplified bash? If so, what is the subset? Like, I couldn't find out that && and || operators existed till you told me miegapele.
Can I set my own simple variables? If so, how? Is it just like bash?
There is no general description, what you found is probably everything, you can read code or search this forum for more
There is no variables, but you can use channel values to simulate that to some extent(there is 64 channels to use I think)
There is if statement and then there is backlog to run multiple statements. if statement now supports parenthesis I think
Also, there is also label and goto.
>>21302925 Hey mate I couldn't get your build to work properly.
Got it flashed (like this)
This is what one of my existing sensors looks like
This is what the one with the new firmware is doing. I note that on the bottom of the page, near the build version, there is an extra field called device time. When no time has been set, there is a hyperlink to set it to browser time.
Note that I have set my PC to Korean time (randomly selected) to test whether the page was getting the time from the device (in which case it would have needed to know the timezone string, which I doubted it did) or from the browser. It seems to get it from the browser.
Note that the time is a couple of minutes fast compared to the NTP supplied time and the local PC time.
Having the Clock_SetConfig in autoexec does not seem to alter the time displayed on the page.
With NTP turned off in autoexec I can set the time displayed on the page using the browser command /pmntp?EPOCH=1731205706&OFFSET=0 (as an example)
In neither case is the time correct on the LCD screen of the physical device. So the time is not getting passed through TuyaMCU. It just shows UTC time.
Thanks for your test.
Before I forget it: The Clock_SetConfig command only needs to be set once, no need to set in autoexec (though afaik setting the same values again shouldn't trigger a flash write).
The "Clock_SetConfig" setting should set the clock according to the UTC time and DST.
randomalias324 wrote:
It seems to get it from the browser.
Yes, time is taken from the browser and if the clock is set via HTTP-Link (with wget or from the gui) the time received is taken as "correct", as Javascript should always report the correct local time depending on the local settings (with or without DST). After the time was reported, the routine only checks, whether we are in DST or not to decide, if the offset reported is "only" TZ offset or "TZ+DST" offset. But in the end, the time of the clock will be the time reported by the browser.
The clock is only changed if there is an DST switch after the initial setting, otherwise the clock simply counts on.
The accuracy of the time depends on the time of the browsers device, so it might wrong if the browsers device clock is not exact (plus a little overhead from the handling). This method is not as exact as ntp, but it should be sufficient for many cases.
So, which time is displayed on the LCD? I expected it to be the NTP time including the offset?
So in this case it's neccessary to start NTP and setting the clock via NTP to some seconds before an DST change (e.g. to Oct 6th 2024 at 01:59:55 UTC+10) then I would expect at least the NTP time on the main page to switch to 3:00:0X during the first few seconds after 2:00).
I'll try this later.
If you can confirm the "LCD time" is the same as the "NTP time as seen on main page" I also can take a look if I can change the time source to the "device-time" as reported in the bottom lines.
Added after 1 [hours] 34 [minutes]:
O.k, found some errors in the code, so DST isn't working as described atm:
I did something wrong or command handling changed, so now you will need another syntax for Clock_SetConfig (comma no longer works, need space):
And there was an error when calculating the switching time in UTC.
In your case it will be "one (UTC) day earlier" and I didn't take this into account...
Please stay tuned...
Added after 17 [minutes]:
Hope it's fixed now.
Using "Clock_SetConfig" as above.
Getting epoch from "5 seconds before switch":
Oops, didn't correct the display for "DST in next year" - but it's only an information, the calculation should be o.k.. Will be fixed in some minutes ...
Still have LCD issues. Now, it doesn't seem to actually crash, can still load the landing page. But, the LCD looks like it resets. Including the wifi level indicator. This happens every minute to every few minutes Could it be setting the clock often? Is it sending junk via TuyaMCU that upsets the LCD driver?
Thanks again for your testing!
I understand that the issues with the LCD are not present in the release firmware?
I can try to silence the version a bit, since it's using new features there might be to much "debugging output".
And if compared to the other firmware please check if this might be related to the usage of the web gui, which takes quite some resources.
>>21307760 Yeah I have 4 that are flashed with the release firmware ntp_setOffet 10 and they are flawless (except for daylight savings rollover, of course)
I've played around with it a little tonight. It feels like MCU load could be a possibility. The LCD is still pausing regularly, every couple of minutes.
Its running currently, but I can't load the page to check up time, but I think its been up this whole time.
I was able to get into the main page and open the javascript app which let me take a few logs. You know how it normally trickles in, through a constant stream of messages maybe 1 or two lines a second with some faster bursts. When the LCD stops and goes 00:00 the logging pauses for maybe 15 seconds. Twice I was able to pause logging, clear history, and re-enable while it was paused. When it comes back you immediately get about 30 lines or so appear nearly instantly. And they all come back with the same set of messages. One in particular is noteworthy:
Actually, just pasting in the snapshots, I think it could be resetting - Looks like its running autoexec.bat and reinitialising the drivers each time. Although WiFi doesn't drop, so its not like a hard reset?
Anyway I don't fully understand. I just power cycled it, still cant get into the web page.
nges count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:Using SSID [homearseistant]
Info:MAIN:Using Pass [MonItoring_Various_Sheeite]
Info:MQTT:MQTT_RegisterCallback called for bT obk066B1CE5/ subT obk066B1CE5/ /set
Info:MQTT:MQTT_RegisterCallback called for bT bekens_t/ subT bekens_t/ /set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obk066B1CE5/ subT cmnd/obk066B1CE5/
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bekens_t/ subT cmnd/bekens_t/
Info:MQTT:MQTT_RegisterCallback called for bT obk066B1CE5/ subT obk066B1CE5/ /get
Info:NTP:CLOCK driver initialized.
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:NTP:NTP driver initialized with server=217.147.223.78, offset=0
Info:MAIN:Started NTP.
Info:GEN:Channel 1 type changed to temperature_div10
...
nges count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:Using SSID [homearseistant]
Info:MAIN:Using Pass [MonItoring_Various_Sheeite]
Info:MQTT:MQTT_RegisterCallback called for bT obk066B1CE5/ subT obk066B1CE5/ /set
Info:MQTT:MQTT_RegisterCallback called for bT bekens_t/ subT bekens_t/ /set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obk066B1CE5/ subT cmnd/obk066B1CE5/
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bekens_t/ subT cmnd/bekens_t/
Info:MQTT:MQTT_RegisterCallback called for bT obk066B1CE5/ subT obk066B1CE5/ /get
Info:NTP:CLOCK driver initialized.
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:NTP:NTP driver initialized with server=217.147.223.78, offset=0
Info:MAIN:Started NTP.
Info:GEN:Channel 1 type changed to temperature_div10
...
Hmm, this is strange. I just set up the WiFi connection on one with release firmware to capture a baseline log and I'm getting the same behavior with it... v1.17.689, same as all the others in my house that operate with no issue
I can see MQTT is changing channels before some of the crashes, and I haven't enabled MQTT...
I might try setting the one with the modified firmware with a connection to the MQTT broker and see if that alters the behavior
Also grabbed a log from one of my working sensors which has 20 days up time
Well there you bloody go. When connected to the MQTT broker, the new build works fine. Before that I also added in the IR pins to spin up the IR driver, but that did not appear to do much. Attached is a log for good measure
So I think I'll flash this to the ones I'm giving to my father, that way we can reconfigure everything through the native webpage and avoid the javascript app (which, unless I'm wrong, needs connectivity to the internet and the IoT wifi, if they're separate)
For mine, I might now play around with miegapele's script which will let me avoid flashing them. And it will test another approach that some others might like to use.
Great firmware max4elektroda, it's an excellent feature to support clock-like devices.
I wonder if the MQTT thing is a bug in release? Surely being off MQTT shouldn't cause resets
>>21308139 Well I hope it's not crashing your devices. Keep an eye out for it. I guess it could be an interaction between MQTT and TuyaMCU, but the only other thing I had running was NTP. I hadn't even touched the MQTT settings
Anyway no problem! Thank you for sharing your great feature! ❤️ The least I could do was test it
I've seen this thread a bit late, but can you check what is the cause of the reboot, more specifically, is it really a crash in the WiFi module firmware, or maybe it's just that WiFi module CEN pin is connected to the MCU (TuyaMCU) and TuyaMCU forces WiFi module reboot when there is no WiFi state 0x04?
Can you check if the "crash" occurs if you do:
in autoexec.bat? tuyaMcu_defWiFiState 4 means that OBK sends to TuyaMCU wifi state "connected to cloud", it's only send either if forced with command or if there is MQTT connected...
So, I suspect, that there may be no "crash", it's just the MCU resetting WiFI module... but I will investigate.
Added after 27 [minutes]:
EDIT: There is nothing related to MQTT in the send time function:
For now, I need one thing to progress. Please check if it also crashes if you add mentioned "default wifi state" setting to autoexec.bat.
Added after 49 [minutes]:
I've also added a self test so you can debug it yourself on Windows:
>>21310759 Hey mate, I don't know how to determine what is causing the 'crash', I don't understand the logs well enough. I have listed quite a few logs above, if you wanted to dig in.
All I know is that: When I configured MQTT, without changing anything else, the behavior stopped.
Considering the web page doesn't load after the LCD drops out, and when the LCD information comes back it does so in the following sequence: 1) Time is displayed as the NTP offset 2) WiFi indicator displays signal a second or so later 3) The time is set to the correct time and date, indicating NTP has synced suggests that the WiFi is dropping out.
I have added tuyaMcu_defWiFiState 4 to autoexec.bat, and it looks like it's stopped the behavior. So autoexec.bat now it looks like this: (I am currently experimenting with some things)
EDIT: Oh now I completely understand you. It must be connected to that pin, like you said. Sounds like it's an uncommon issue, as it requires the other MCU to be connected in this particular way AND be programmed to send the reset command.
I wonder if it is a good idea to send the 'connected to cloud' signal regardless of MQTT when MQTT is not configured? Same with WiFi. It might suppress confusing issues / random resets with some of these devices while people are setting up their system
Thank you for testing and your activity (I mean, all users in this topic), I really appreciate it.
randomalias324 wrote:
I wonder if it is a good idea to send the 'connected to cloud' signal regardless of MQTT when MQTT is not configured
Well, now it brings another issue - there are TuyaMCU door sensors (or water sensors, or humidity sensors) that are using this MQTT mechanism to know when they can report state to HA and then go back to sleep ...
But from what I can see, you want to specifically add an exception to when MQTT is not configured, not just "not connected"?
Very well, I can agree to that. Here's the first draft:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1434/files Can you check it that's what works for you? Shall I merge it?
>>21312619 OK, I'll give it a flash when I have time tonight :)
Quote:
You want to specifically add an exception to when MQTT is not configured, not just "not connected"?
Yeah exactly The default behavior I guess seemed like a surprise, as I thought there were use cases for devices without MQTT.
But yeah, the case with the door sensors is interesting let's think about it. So, for people with the door device, with the modified logic they will now be going to sleep before they've set up MQTT. Do you know time delay? Is there a confirmation mechanism that confirms an MQTT message has been successfully sent, if so do the devices use that? I'm just trying to put myself in the shoes of someone with one of those devices. So I've just connected it to WiFi, and I'm now in there setting up the MQTT user password and it goes to sleep. I suppose I might be expecting it to go to sleep when connected, so I would go back and put it in hot-spot mode for further config or try to keep it awake with multiple door opening closings? I'm not sure what it would be like.
When I'm setting these up I usually put WiFi settings and MQTT in at the same time. I am just not currently doing it because I am concentrating on the clock functionality
I guess that's a long winded way of saying the new logic seems more logical from my perspective and any biases I have from working with these clocks. But not everyone is me
The discussion revolves around automating daylight saving time adjustments for NTP (Network Time Protocol) devices using OpenBeken firmware. Users express the need for a solution to avoid manual changes to the timezone offset twice a year due to daylight saving time in Australia. Various scripting approaches are proposed, including the use of logical operators (AND, OR) and nested IF statements to determine the correct timezone offset based on the date. Some users share scripts that successfully implement these adjustments, while others discuss the limitations of memory and firmware capabilities. The conversation also touches on the integration of MQTT and TuyaMCU for device communication and the challenges faced with LCD displays and firmware stability. Overall, the community collaborates to refine scripts and firmware features to enhance timekeeping functionality in their devices. Summary generated by the language model.
![[ZIGBEE] 20A Zigbee socket with energy metering (Tuya TS011F_plug_3)](https://obrazki.elektroda.pl/1000454900_1749493372_thumb.jpg)
):
