Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Parsing of Time in HTTP POST ?
-
In this case Mango hase tried to interpret the timestamp creating a date with 1441 as the year.
-
It sounds like the HTTP receiver is not designed to use a Unix style time. We can look at this and see if it's something we can add.
-
I tried also adding a decimal point :
This is the result (The time displayed is the server time because the 4 successive POSTs sent are "dated" with 1 second delay between each of them instead of 15" as the timestamp sent be the Gateway specifies) :
Source: 81.243.242.216
Device ID: PGP_001EC01EF773
Time: 17:19:23
FactorPhB=0.000
FactorPhA=0.980
FactorTotal=0.980
FactorPhC=0.000
WattPhC=0.000
WattPhB=0.000
VoltagePhA=234.000
IndexConsoTf1=30.110
IndexConsoTf2=0.000
VoltagePhC=0.000
VoltagePhB=0.000
WattPhA=1.720
IndexConsoPhC=0.000
IndexConsoPhB=0.000
IndexConsoPhA=30.110
__meter=14100021
IndexProdPhC=0.000
IndexProdTf2=0.000
IndexProdPhB=0.000
IndexProdTf1=0.890
IndexProdPhA=0.890 -
pascal,
You were using the correct format in your example post: __time=1441120275000
I just ran a few tests and did some debugging. I found a bug where the code was first converting the __time parameter via the 'yyyyMMddHHmmss' format, since the timestamp actually does translate into a valid date it was returning this.
I have fixed this bug in the 2.6.0 Core and just pushed out a new version of this module for the 2.5.2 core, the new module version is 1.4.8 and you should be able to do an automatic upgrade from the modules page if you are on Core 2.5.2 or later.
The new logic will first convert the value using the 'yyyyMMddHHmmss' format and then compare the date. If the data is before Jan 1 1970 then it will try the other formats. In your case the proper time is then used.
-
Thank you !
-
Keep in mind that in 2032 the timestamp will start with 1970.... and the decoded year will be > 1970.
:-)
-
After testing the updated version, it looks like there is a difference of 1 hour between the time decoded by Mango from "YYYYMMDDHHMMSS" and the UTC timestamp.
The first one is correct and the seconde one is 1 hour later ?
I have tried both and it is not correct.
Any clue ?
-
pascal,
Thanks for the note on the 2032 problem, if you are still using this module in 2032 I'll give you a free enterprise license to Mango with an upgraded module!
As for the 1 hour off problem, could it be a timezone problem? Is there a 1hr time difference between where your Mango server is vs where the http request is coming from? Mango will parse the UTC timestamp into a date using its local timezone. Then of course there is the User's timezone that will re-convert the timestamps into a Date when viewed through Mango.
One way to confirm this would be to check the ts column for the data point in the pointValues table. It should match exactly what you are sending through.
-
I will check but what looks strange to me is that I tried sending the same date+time in the 2 formats and one was correctly received the other one, with a difference of 1 hour.
-
If you still can't make sense of it just send me the strings you used for both formats, I can check them against my test Mango.
