RTC Module and DST/BST
-
Hi all,
I'm just getting started with MySensors. I've built a gateway which is working fine so I thought I'd try some of the sensor project. I had the parts for the Real Time Clock Module, LCD Display and Controller Time project so I assembled that.
It's working fine but I cannot figure out how to get it to account for DST (or, in my case, BST). My controller - a Raspberry Pi running Home Assistant - is set to BST
pi@house:~ $ date Fri 8 Jul 22:11:16 BST 2016But the controller sends epoch time which doesn't account for BST. A Google search seems to imply that the Arduino doesn't have a library for calculating DST which means I'd have to write my own - but I thought I'd ask here first in case there is a way to do this either through an existing Arduino library or some feature of MySensors that I can't find.
Thanks for your help
Steve
-
Hi all,
I'm just getting started with MySensors. I've built a gateway which is working fine so I thought I'd try some of the sensor project. I had the parts for the Real Time Clock Module, LCD Display and Controller Time project so I assembled that.
It's working fine but I cannot figure out how to get it to account for DST (or, in my case, BST). My controller - a Raspberry Pi running Home Assistant - is set to BST
pi@house:~ $ date Fri 8 Jul 22:11:16 BST 2016But the controller sends epoch time which doesn't account for BST. A Google search seems to imply that the Arduino doesn't have a library for calculating DST which means I'd have to write my own - but I thought I'd ask here first in case there is a way to do this either through an existing Arduino library or some feature of MySensors that I can't find.
Thanks for your help
Steve
@stetho Imho that should be a controller function. I had similar issues with Domoticz but these werecorrected. If you have MySensors compensate for it you would be controller dependent.. I assume your controller does take care of your time zone..
-
I see what you mean but I don't agree. The controller sends epoch time - which is an absolute value and you will get the same number no matter where you are in the world.
A better but less likely example - I have one controller in the UK but I have sensor nodes in the UK, West Coast USA, France and Cook Island. How does the controller know where these nodes are? Should the controller adjust the time it sends or would it make more sense for the local node to contain the localisation information and display the correct local time?
Another example - modern operating systems have a feature along the lines of "adjust my clock based on my location". If you go to another country the OS will automatically display the correct time based on your location, not because it's checked in with a central server and told it where it is but because the OS has a routine that allows it to do the calculation.
The calculation from UTC to GMT and on to BST needs to be done on the client not the server.
Steve
-
I see what you mean but I don't agree. The controller sends epoch time - which is an absolute value and you will get the same number no matter where you are in the world.
A better but less likely example - I have one controller in the UK but I have sensor nodes in the UK, West Coast USA, France and Cook Island. How does the controller know where these nodes are? Should the controller adjust the time it sends or would it make more sense for the local node to contain the localisation information and display the correct local time?
Another example - modern operating systems have a feature along the lines of "adjust my clock based on my location". If you go to another country the OS will automatically display the correct time based on your location, not because it's checked in with a central server and told it where it is but because the OS has a routine that allows it to do the calculation.
The calculation from UTC to GMT and on to BST needs to be done on the client not the server.
Steve
@stetho you can argue on many aspects of the equation and you are right that epoch is an 'absolute' time. But the way it works is that time is send in epoch format and that the controller should be considered as a client from a global perspective...
-
Before I knew about MySensors, if coded DLS into an Arduino that used an RTC. That was a big sketch ;-)
I agree with @AWI DLS is responsiblity of the controller. It's just an architecture principle. If I have multiple nodes that can tell time, I want the logic for DLS in one place and no more than one.
What controller do you use?
-
I don't agree. I can't think of one example where the server is responsible for knowing the client's time zone. I know in this case the sensors are all in my house and therefore in the same timezone.
I'm using Home Assistant but AWI mentioned that "I had similar issues with Domoticz". This was because the server is not responsible for knowing which of the 192 possible DST & time zone combinations applies to the client.
Further to this assertion, the code I'm using is the MySensors code from the page I linked to above. This means that the sensor is expecting epoch time. Recoding the servers to send the dates in ISO 8601 format doesn't fix anything if the client is in a different time zone - the client would still need to adjust the date to be in the correct time zone for its physical location. Again, I know that in my specific use case the sensors and the controller are in the same location, I'm just trying to clarify that the controller does not have responsibility for sending the correct time to client - that's not how the whole internet works.
Also, Epoch time isn't a "format". It's a linear counter that increases with time ad infinitum. In other words, it's just a number. 1468069791 is just a number - the question is, is it epoch time, an account number, the distance from here to Jupiter?
Anyway - I found this web page which answered my question.
-
I don't agree. I can't think of one example where the server is responsible for knowing the client's time zone. I know in this case the sensors are all in my house and therefore in the same timezone.
I'm using Home Assistant but AWI mentioned that "I had similar issues with Domoticz". This was because the server is not responsible for knowing which of the 192 possible DST & time zone combinations applies to the client.
Further to this assertion, the code I'm using is the MySensors code from the page I linked to above. This means that the sensor is expecting epoch time. Recoding the servers to send the dates in ISO 8601 format doesn't fix anything if the client is in a different time zone - the client would still need to adjust the date to be in the correct time zone for its physical location. Again, I know that in my specific use case the sensors and the controller are in the same location, I'm just trying to clarify that the controller does not have responsibility for sending the correct time to client - that's not how the whole internet works.
Also, Epoch time isn't a "format". It's a linear counter that increases with time ad infinitum. In other words, it's just a number. 1468069791 is just a number - the question is, is it epoch time, an account number, the distance from here to Jupiter?
Anyway - I found this web page which answered my question.
@stetho :ok_hand: glad you found a solution for your situation. Please don't quote me on "similar problems with Domoticz" these were correctly solved with the assumption that the (Domoticz) controller is located in the timezone and therefore sends a *number * which represents the local time.
