But it would have a very limited range of use since it cannot store decimal unless another “decimal places” meta field was created and it also won’t do negative numbers either.
I would agree that there is a need for “other datatype/size” phpfina/timeseries feeds, but if there is only another one or 2 as opposed to a whole range, then a 64bit version of what we already have has to the be favorite for all round ability.
I’m sorry I’m really not sure what you are asking there, but it sounds like you are confusing the actual timestamp and the value, which in this instance is also a timestamp value.
a phpfina feed file is a string of end to end 4byte values, each 4byte location is a datapoint. bytes 0-3 are the first datapoint (datapoint) and 4-7 are the second (datapoint) and so on.
datapoint (for example) is the seventh datapoint and those 4bytes give you the value (32bit float)
the timestamp for datapoint is 6 x the interval (from the feeds meta file) plus the feed start time (also held in the meta file)
so if the feed start time was 1537708275 and the interval was 10s, then datapoint would be (6x10)+1537708275 = 1537708335.
The value however, (lets say for example you were posting data with a matching timestamp and value) would be something like 1537708000 due to the limited precision of the 32bit float, but it’s location in the file would tell you that values timestamp is 1537708335.
I can see no benefit to passing that timestamp to emoncms as a value for saving to a feed.
If you are getting data from an inverter and it is telling you this data applies to this timestamp, then any other timestamp is irrelevant and you should be using only that timestamp from the inverter as the actual timestamp for the data array being sent to emoncms.
If the inverter is saying this is the current data and also this is the current time, then the inverter timestamp has little or no value other than to check the time is right on the inverter.
If you believe that the sample period and data the inverter reports is not always current, then you might benefit from using the raw inverter timestamp, or potentially as a way to confirm the data coming from the inverter is current, if you are getting the same timestamp every 10s for an hour that would suggest your inverter is not updating the data, but currently you would need to store this as mysql, not as phpfina or phptimeseries.
Otherwise, if you are using phpfina you are much better off taking control of the timestamp and polling interval etc and dictating when the data is updated eg like my harmonized timestamps method, otherwise you are just polling the inverter and getting a timestamp over which you have no control and sending it to emoncms which will do what it can to place that data in the appropriate/closest time slot.
The only time I really see it is worth saving a timestamp is to test emoncms and/or other applications is to see if they are behaving or to test reporting accuracy etc ie if you send identical timestamp and values. are they coming out identical when graphing and downloading etc. It has no real world value to any energy data to have a timeseries database of timestamps. you are literally recording what time it was at the time it was recorded, that’s why it’s only real use is to check they are the same for debugging purposes.