A method for creating manipulable time and date values

One of the frustrations of the Zipabox is the fact that there appears to be no way to store time or date values as variables. You can *sort of* store them, but although you can see the values in an email, any attempt to test or manipulate them fails. This means you can't calculate, for example, the elapsed time since an event such as a sensor update or weather observation.

I've come up with a way around this that is working quite well. It's based on the same technique I use for importing Tado thermostat data, Roomba info and weather information - a Google App Script that runs regularly and send info to a virtual meter in the Zipabox (those running web servers can obviously use those in the same way). Since you can easily convert a date or time value to a number in an app script and send that number to a meter, you can create a date-time meter to hold the values and act as your virtual clock/calendar. Since I already have two or three different app scripts running every 10 minutes or so, I have added the code this time/date to each one so that I get pretty frequent updates. In addition, in my "master scheduler" rule that runs every minute, I update the time and date values.

There are some important restrictions on the values a meter will accept. In tests I found that 16777216 was the largest value you could reliably store and manipulate in a virtual meter to the left of the decimal point (24 bits), and that its floating-point behaviour was very shaky indeed. It will accept 2 decimal points at most, and when the number before the decimal point is large, increments of 0.01 are ignored (but not increments of 0.02!).

What all this means is that a meter value cannot possibly hold a date value that measures seconds, milliseconds or even minutes since 1st January 1970. So my compromise solution was to store hours (including fractions of hours). In theory, with two decimal places, this should be enough to store the minutes with decent accuracy, but unfortunately, as noted above, if you try to add 0.16 to a date value, very often nothing seems to happen. So I use an improved modulo rule to identify only even-numbered minutes, and add 0.3 to the date-time value in those minutes. For my purposes, this accuracy is sufficient. Since I get at least 2 updates from my app scripts every 10 minutes, the accumulated inaccuracies are fairly small.

In addition to the date value, I also include a time value in my meter, which is the number of elapsed seconds since midnight. There are no difficulties with that at all.

Once you have this, calculating elapsed time is trivial. For example, with each weather update I include an observation date-time stamp in the same format, so that I can calculate how old the observation is. You can easily think of other uses - for example, storing time values for sunset and sunrise.

This is a snippet of the app script that updates the meter:

1. // Prepare standard HTTP POST stuff
   
   

   var options =

   {

   "contentType" : "text/plain",

   "method" : "post"

   };

   
   

   // Get current date/time

   var dateNow = new Date();

   var nYear = dateNow.getFullYear();

   var nMonth = dateNow.getMonth() + 1;

   var nDay = dateNow.getDate();

   var nHour = dateNow.getHours();

   var nMinute = dateNow.getMinutes();

   
   

   // Create date-time value for the Zipabox (number of hours since 1 January 1970)

   var nZipaboxDateTime = dateNow.valueOf() / 1000 / 60 / 60;

   
   

   // Create time value (seconds since midnight)

   var dateTodayMidnight = new Date(nYear, dateNow.getMonth(), dateNow.getDate(), 0, 0, 0);

   var nZipaboxTimeValue = (dateNow.valueOf() - dateTodayMidnight.valueOf()) / 1000;

   
   

   // Send values to Zipabox date-time meter

   var resultZipaboxDateTime = UrlFetchApp.fetch(sZIPABOX_REMOTING_PREFIX+sZIP_DATETIMEMETER_SUFFIX+

   "&value9=" + parseFloat(nZipaboxDateTime) + "&value1=" + parseInt(nZipaboxTimeValue), options);

   
   

The attached screenshots show the date-time meter, the modulo rule, the updating of the meter each minute, and the calculation of the age of weather observations.

The modulo rule is an improved version of one I posted a while back, which takes advantage of the fact that the repeat loop now works. :-)