"Sketch Time" (I_TIME) Handler

[cranky]

This flow takes care of the I_TIME call made to the gateway.

The confusing part about this Internal call is: do we return UTC, or local time? It would be trivial to have a sensor pass as

[id];255;3;0;1;(timezone)

rather than

[id];255;3;0;1;\n

so that Time local to where the sensor was placed could be recorded. The only caveat is that DST would mess it up... However, since the Arduino sketch "Time Aware Sensor" polls the gateway every hour for time, at most your logs/data will be off by at most 1 hour. This can easily be changed to the tolerance your need desires.

[{"id":"8e3e8f02.7fd0c","type":"mqtt-broker","z":"63842e72.893f78","broker":"localhost","port":"8883","clientid":"","usetls":false,"verifyservercert":true,"compatmode":true,"keepalive":"15","cleansession":true,"willTopic":"","willQos":"0","willRetain":null,"willPayload":"","birthTopic":"","birthQos":"0","birthRetain":null,"birthPayload":""},{"id":"71e13b71.966fa4","type":"mqtt in","z":"63842e72.893f78","name":"Sensor Requests Time ","topic":"MySensors/+/255/3/0/1","broker":"8e3e8f02.7fd0c","x":102,"y":852,"wires":[["24b5e719.a8a1d8"]]},{"id":"92a5ad9d.a8b328","type":"function","z":"63842e72.893f78","name":"seconds since epoch","func":"var timezone_offset = -5  // As hours against UTC\n\nmsg.payload = Math.floor( Date.now() / 1000 ); // seconds since jan 1 1970\nmsg.payload = msg.payload + ( timezone_offset * 3600);\nreturn msg;","outputs":1,"noerr":0,"x":465,"y":851,"wires":[["b7cc49b4.1520c8","4686a23a.28493c"]]},{"id":"b7cc49b4.1520c8","type":"mqtt out","z":"63842e72.893f78","name":"Time to Topic","topic":"","qos":"","retain":"","broker":"8e3e8f02.7fd0c","x":657,"y":850,"wires":[]},{"id":"e059f1d.9421f1","type":"comment","z":"63842e72.893f78","name":"I_TIME handler ([0-255];255;3;0;1;[sec since epoch])","info":"Whenever a sensor announces itself to the network as [any];255;3;0;1;(null),\nit returns to the same topic the amount of seconds since Jan 1 1970 (also called Epoch)\n\nA rate limiter was required as to keep NR and the sensor from a spam-loop","x":301,"y":899,"wires":[]},{"id":"4686a23a.28493c","type":"debug","z":"63842e72.893f78","name":"","active":false,"console":"false","complete":"false","x":642,"y":817,"wires":[]},{"id":"24b5e719.a8a1d8","type":"delay","z":"63842e72.893f78","name":"","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":284,"y":852,"wires":[["92a5ad9d.a8b328"]]},{"id":"46b988b9.969a88","type":"comment","z":"63842e72.893f78","name":"Change timezone here","info":"","x":450,"y":818,"wires":[]}]

[hek]

It returns local time adjusted for DST.

[cranky]

Really? I'd rather handle absolute time of "Seconds since the Epoch". If you use that, there's no reason or need to mess with DST, time zones, or anything else. It's only when you convert "Seconds Since Epoch"->"String of Current time/date" do you get into having to deal with TZdata and all that garbage.

Then, on the local device, the user can bake in the Arduino sketch the timezone they are using. Of course, then they have to deal with the horrors of DST and timezones... that is if they want to.

I log most of my data in seconds(or ms) since epoch. All my logs are then completely synchronized, as much as an NTP client can manage.

Sincerely,
Cranky

[hek]

What I mean is that the TimeAware-example sketch expects to get seconds since 1970.
It does not adjust. for summer time by itself or know anything about timezones. So the controller must make these adjustments.

[cranky]

Ah cool So yes, make the user do it. I like the sound of that.

Time stinks. Only thing I can say about that is, "Never again."