homieiot / convention

🏡 The Homie Convention: a lightweight MQTT convention for the IoT
https://homieiot.github.io/
Other
715 stars 60 forks source link

date/time property #160

Closed mjcumming closed 4 years ago

mjcumming commented 5 years ago

Wondering if any thought has been given to a way to represent date/time and to set date/time.

Use case is for setting the hold mode on a thermostat where the hold mode can be permanent or temporary. When temporary, a time is supplied for when the hold mode expires.

davidgraeff commented 5 years ago

Not yet. We should pick a simple to parse RFC date/time representation

Thalhammer commented 5 years ago

Should probably stick with a common one: https://en.wikipedia.org/wiki/ISO_8601

mjcumming commented 5 years ago

looks good to me - there is python support for it :)

krocans commented 5 years ago

Isn't unixtime enough for that? To include some human readable time/time zone representation in specification means to force to implement additional code in every Homie implementation even on small devices where code/data size matters.

stritti commented 5 years ago

To implement timebased rules I also looking forward datetime support. Currently I split hh and mm in separate float properties.

davidgraeff commented 5 years ago

Another possibility is NTP

Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h. If only 32bit integers are used in both cases we run into trouble at some point.

stritti commented 5 years ago

I would prefer ISO. Then it is much easier to define for example time ranges too. For example to define when a switch is daily enabled/disabled.

mjcumming commented 5 years ago

ISO seems to be a more common standard. I am not sure that controller devices have to implement a datetime format? If they do not send that data, then do they need to be able to process it? How much overhead would this be? There are libraries in C, C++ and Python.

davidgraeff commented 5 years ago

I think ISO is fine. So we would allow the following patterns:

2019-04-17T23:59:33+00:00
2019-04-17T23:59:33Z
mjcumming commented 5 years ago

@davidgraeff are you suggesting we implement a subset of the ISO standard or implement the full standard as documented?

https://en.wikipedia.org/wiki/ISO_8601

davidgraeff commented 5 years ago

A subset. I don't want to support:

The standard also allows for calendar dates to be written with reduced accuracy. For example, one may write "1981-04" to mean "1981 April".

or

One may simply write "1981" to refer to that year or "19" to refer to the century from 1900 to 1999 inclusive.

or

Although the standard allows both the YYYY-MM-DD and YYYYMMDD formats for complete calendar date representations

stritti commented 5 years ago

But I think it should be possible to define a specific datetime-stamp and on the other hand returning times or durations which means just time without date.

davidgraeff commented 5 years ago

I meant my two lines above as example not as the final decision. Yes I agree, it should be possible to just specify date or time.

The Iso also covers a variety of short patterns and time zones. A subset should be sufficient for the Homie domain?!

stritti commented 5 years ago

First I thought timezone could be dropped, but what about communicating with some external clouds and daylight saving times 🙄 It will in this case be difficult to support just +1 or similar. But on the other hand, shall we really implement in every ESP timezone support?

What are your use cases/ user stories?

My user stories are:

Thalhammer commented 5 years ago

I think we should stick with UTC only, as it reduces the work needed on devices by a lot. Simple yyyy-mm-dd hh:mm to time_t can be done without much effort, in small code sizes and without looping (i.e. its cheap) while supporting Timezones would require A LOT of additional information either as a binary file or as generated code (neither of which I'd like to have, if I don't need to). A controller usually runs more powerful hardware anyway, so I guess its ok to assume it will have enough resources while a device might only have UTC times.

I don't see any reason where you would actually need anything else than utc except for convenience (the controller can just convert to utc and back as needed), but I might be wrong.

davidgraeff commented 5 years ago

UTC is fine. I would include the separating "T" like in the ISO. That format can be parsed by many programming languages directly.

stritti commented 5 years ago

Yes that is a good argument: timezone could be managed by controller.

mjcumming commented 5 years ago

Any device using time will need a way to get/set the current time. I would assume that most devices like the ESP (which do not have a RTC) will need to get that time using an NTP server. I don't imagine adding the ability to parse a time string be it ISO or other format will have significant overhead compared to the libraries already required to talk to an NTP service.

lorenwest commented 5 years ago

Agreed it would be valuable for the spec to define time strings consistently.

2019-04-17T23:59:33+00:00
2019-04-17T23:59:33Z

In my opinion, it's important for dates to have optional time, including optional milli/micro seconds. Sometimes it matters...

2016-06-10T21:42:24.76073899Z

FWIW, I synchronize time to my Homie devices from the controller using $broadcast. That's a lot simpler than NTP from each device, and may be a good addition to the convention. The time format would be (of course) whatever we decide in this thread :)

mjcumming commented 5 years ago

I would like to clarify some verbiage - in the Homie convention, there is no real concept of a "controller". Ie. there is no one device or instance that is in charge of other devices on the network - correct?

I understand that most will use the convention with something like OH being considered the controller or master device but that is not defined in the scope of the convention.

So, I am not sure that the idea that one device will define the time in that location for all other devices on that network fits within the convention. However, if devices are going to communicate date/time information we do need to describe the expectation that devices on that network know the local time.

davidgraeff commented 5 years ago

there is no real concept of a "controller".

Wrong. See https://homieiot.github.io/implementations/. We have controllers vs devices.

one device will define the time

That was not suggested?! And it will definitely not be part of the spec. And is offtopic ;)

mjcumming commented 5 years ago

My mistake regarding controllers. In terms of time, it was suggested by @lorenwest that one device/controller could define the current time by a $broadcast.

wwebers commented 5 years ago

I agree with @Thalhammer : UTC would be fine. Question is, will we support durations and intervals?

davidgraeff commented 5 years ago

This issue is purely about date and time. Duration/intervals would be a different Issue and a different ISO, DIN or other specification need to be used.

Thalhammer commented 5 years ago

@mjcumming Yes thats the way most implement clock distribution on the network but it is not specified anywhere in homie. Also I dont think it should be as there are a lot of ways to sync clocks (like ntp, which I use).

@wwebers We will support durations and intervals, but not in this issue.

mjcumming commented 4 years ago

DateTime payload added to the convention using ISO8601