Command to manually set time

[jziolkowski]

One of Discord users was creating a set of rules based on sunset and sunrise. Being able to temporarily disable NTP and set time manually would speed up testing/debugging of such rules tremendously. Especially related to night or sunrise.

I'm aware that it could be somewhat emulated by playing with timezone settings, but we're talking about losing an hour at best, when a simple command could enable one to literally save hours.

OR, keep the time setting as is, but be able to - again temporarily - override sunrise and sunset variable.

[underwoodblog]

I'm new to tasmota but can't you set the time-server ip in tasmota? Running a own timeserver on raspberry pi is easy and may help you with your testing.

[jziolkowski]

To have a NTP server send out wrong time on purpose means that the whole host of the time server must have wrong time set. Plus it's quite more work than issuing a simple command in Tasmota

[andrethomas]

I think the only drawback for not using NTP is that it would need to be set again after startup. Also the RTC on the ESP8266 is not entirely accurate.

If nothing else I would recommend at least using a DS3231 on the device to keep the time accurate.

EDIT: I suppose for initial setup/testing this does not make much sense. Wonder how many bytes we'd need...

[andrethomas]

I suppose the most simplistic way to implement would be to do

time 1550597400 which would be Tuesday, February 19, 2019 5:30:00 PM for timezone 0 (GMT/UCT)

[localhost61]

@andrethomas Yes, currently there is a function to convert epoc into string, but not the reverse :-)

One can imagine time <epoc> to bloc the NTP servers and initialize the RTC (with or without a DS3231) and time 0 to restore normal way to do. That could be a workaround for Tasmota devices in the wild that have poor WiFi [#5144] and can stand a clock shift... or an ease for testing.

[jziolkowski]

would a parser from "hh mm ss" would take a lot of ram? After all, we're talking only of setting time, not date. So counting from epoch is not required. For testing sunrise/sunset triggers time is enough. Even for testing timers on certain days, we could have analogous "day" command. The date itself is irrelevant in Tasmota. The only situation that comes to mind where exact date and time is important is when MQTT is used with TLS. I also like the suggestion from @localhost61 .

time hh mm ss

or

time hhmmss

for manual config

time 0

for standard NTP operation

[localhost61]

Date is needed for sunrise and sunset calculation, as well as for DST/STD offset for local time.

[jziolkowski]

Ahhh, indeed. So scratch the date part. We only need to alter time.

[localhost61]

So you imply that RTC is already synced with NTP, and then you require NTP is disconnected. This will only solve YOUR specific need. I was thinking to a wider case were it could initialize RTC in place of NTP. But I agree that an epoch is not user-friendly and one needs to connect to a website to get the value.

[jziolkowski]

The internals of what and when will be disconnected is not up to me and I trust in experience of Theo and other developers here for that part. I just stated a specific situation (of someone, not ME ;) ) which could be solved with this new function. If you want to give it a broader function - sure thing.

[localhost61]

You're right, IMHO the point is that if it is too specific or cost too much in terms of code size, it won't be done. ¯\_(ツ)_/¯

[mvincm]

Hello.

If any voice from the user side could help in the decision process please take note that IHMO Tasmota should work in standalone mode. What does it mean? No Internet, no mqtt, no ntp but base function should work even with a fake/start date. A sample use is the "thermostat". A thermostat (based on rules) should keep your home warm and prevent from freezing even if there is no correct time, mqtt connection or go further no wifi! Of course, if some rules/timers based on sunrise/sunset time there should be the correct time but if your device does not use sunset/sunrise time and instead use some events logics, the correct time is no so important at all.

So my vote is to enable rules/timers based on "fake" start value and no to hard look for NTP.

Best regards, MvincM

[jziolkowski]

@mvincm This device doesn't need NTP to function. It needs NTP to function properly. Even if you set time manually, the clock source inside isn't precise. It doesn't have a RTC chip. So you will get time deviations.

Also Tasmota was designed with MQTT in mind, so your "standalone" remark is unachievable. Even the WebUI is kept simple by design, because all the functions were meant to be made available over MQTT.

[andrethomas]

Most likely using epoch time as mentioned previously will be the most minimal on flash usage since that is the numeric value stored in the RTC iirc.

[mvincm]

@jziolkowski

Generally, I agree with you and your point of view but some "mission critical" fields of Tasmota use (for me like a thermostat) IMHO must work without MQTT or correct time. I'm not talking about configuration or beautiful readings (mqtt with fancy web dashboard), I'm talking about core Home Automation. For reliable Home Automation, all devices could work with Internet but "could" not "must work" and of course Intrent != LAN.

[andrethomas]

The main objective is to provide operability via mqtt - if you're going to set up an mqtt server it is just as easy to set up an NTP service on the same device. I don't believe this request is for devices to run autonomously without a network connection but even this can be achieved to keep accurate time by adding an external RTC with a backup battery is indicated in a previous post.

The RTC in the ESP is not battery backed up so it WILL lose its time if the power fails and even if that does not happen they are known to time travel a little slower or faster than us humans.

I support the idea of adding a minimalist command to set local time for testing purposes as it is a pain to hop through timezones and wait for a specific time to occur to ensure that the device acts as expected and then you set it back to the correct timezone and the behaviour is unexpected anyway...

I'm unsure of the implications of using a manual time setting because I think if there is an RTC or NTP service accessible it would almost immediately revert to what it is told is the correct time so it may not be as minimalistic to implement as one would want and it is therefore up to the project owner to decide on having this vs. the tradeoff of resources required to achieve this.

[arendst]

I'm fine with a command like time 12:34:56 which will disable NTP and allow user to set a time as suggested by @jziolkowski. Also time 0 should re-enable NTP.

The logic used for timezone 10:30 can be used for time too.

[localhost61]

@arendst So you alter utctime but don't initialize?

[jziolkowski]

I think whether this command should be persistent. If a user knows exactly what it means to disable NTP until reverted, then ok. But some users might do this because "hey, this is how you set the time" and run into issues due to not using NTP and dealing with ESP's innacurate internal timer.

[andrethomas]

Users will always find creative ways to turn features into bugs... I think NTP should be enabled automatically after a restart perhaps based on a #define which enables it by default in the user_config.h

[jziolkowski]

I think the same. That disabling NTP should be temporary until next reboot.

[mvincm]

but using "user_config.h" to make it permanent for more power user is an option too!

[localhost61]

@mvincm How do you want to make it permanent if you have to manually set time :-?

[joba-1]

It would be ok, if the intended usecase is to make timers work (as long as you dont care in which tz) -- iphone so i typo

[mvincm]

@joba-1 It is exactly what I need to have. Timers, rules should work without the current and proper time, they need "some" time, especially rules. If you ask me for use cases... in my case, I have at least two of them. A thermostat which prevents my home to become a ice brick, "smart" control of my water pump in a basement (float switch doesn't work properly in my case).

@localhost61 I know that Tasmota was designed to work with Internet, NTP, MQTT (as colleagues said earlier). I very like Tasmota and my way of thinking is to improve Tasmota and allowed to work in the environment without Internet or not stable Internet connection. So answering your question. Tasmota should always start from Unix epoch (as many hardware/firmware do), try to connect to NTP and if there is no NTP server declared or no NTP connection start to work in 1/1/1970 and allow to work Timers, Rules, Event with this time.

[arendst]

@mvincm did you ever try to use tasmota without correct time? Did anything not work?

Let's stop discussing non-issues as long as they haven't been observed. If observed than provide background/logging info for analysis.

[tlsvict]

I would not want things that depend on correct time to trigger (e.g. midnight is not known in 5571, and therefore the code chose to account for all power in 'today' and never rolled over - I see this as reasonable, others might have wanted the power accounting to rollover the day at 24hr after bootup if we still didn't have a valid time source -- that would also be valid and reasonable in my mind, but I suspect not written because when writing tasmota people probably assumed that it will get a valid time provider before that point..), I would also not want sunrise / sunset to trigger, regardless of how long the tasmota device had been up, I might even want to configure how long to run the internal esp8266 clock since last time sync before stopping executing those events even if we got valid time at some point, due to clock drift -- I would however want things like turn this off after 10 minutes to work, without valid time recently or ever.. do things like that not work? [not at home, so don't have a tasmota available to try, but given the valid time check in the code that 5571 pointed out, I'm thinking that the tasmotas likely do start counting time before actual time is known, so things like elapsed time likely do work..]

[jziolkowski]

Awesome. Thanks!