It looks like there is a bug in the refresh of WatchLists (old version).

We experienced similar problems within report which were not querying the last Data Point values.

Any clue ?

Pascal

Screenshot of the Watchlist:

You can see that current value of certain Data Point are not displayed.
Screenshot of the Details of first Data Point of the above Watchlist at the same time:

Export from the same Watchlist at the same time :

Hi,

I have used CRON to schedule report and noticed the following behavior :

The CRON expression is evaluated towards UTC time, which is OK to me.

The report itself is timestamped with UTC time instead of the User time and the timestamps included in the attached Excel file are also UTC ones.

So, I wonder :

1. If it is possible to adjust the timestamp to the User location ?
2. What is the behavior of the CRON expression when DST (daylight saving time) adjustments apply

Kind regards,

Pascal

I experienced the absence of graphic in the WatchList and Data points details.
The graphics appears as an Icon named "Image Chart".
Any solution to bring back the graphics ?
Regards,
Pascal

Where is it possible to get some information on the integration of the Publisher with Twilio ?

Is it possible to send SMS to users instead of e-Mails like standard Mango features ?

Best regards,

Pascal

OK, I found it
.
It works automatically by settings : Logging type = When timestamp changes.

Does anyone know a way to eliminate the duplicate datapoint value : same timestamp and same value.

Those duplictes are generated when in the communications process the same date is sent twice because of a lost acknowledge (for example).

Best regards,

Pascal

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.

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 ?

Keep in mind that in 2032 the timestamp will start with 1970.... and the decoded year will be > 1970.

:-)

Thank you !

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

In this case Mango hase tried to interpret the timestamp creating a date with 1441 as the year.

It doesn't work that way.

Mango is replacing the timestamp with the server one as if there were no timestamp in the POST.

When publisher sends data out it looks like the timestamp is like "123245654.1123" with a decimal point (I see that on the

This is what I do in the Gateway :

Format the number of seconds since Epoch, adding 3 x '0' at the end. :

snprintf(WorkBuffer, sizeof(WorkBuffer), "%ld000;", ModbusTimestamp);

This the resulting POST contents :

POST /httpds HTTP/1.1
HOST: mangolocal.pgpsmartsensing.be
Content-Type: application/x-www-form-urlencoded
Content-Length: 438

__device=PGP_001EC01EF773&__time=1441120275000&__meter=14100021&VoltagePhA=234.200&VoltagePhB=0.000&VoltagePhC=0.000&Frequency=50.010&WattPhA=1.720&WattPhB=0.000&WattPhC=0.000&FactorTotal=0.980&FactorPhA=0.980&FactorPhB=0.000&FactorPhC=0.000&IndexConsoTf1=29.840&IndexConsoTf2=0.000&IndexConsoPhA=29.840&IndexConsoPhB=0.000&IndexConsoPhC=0.000&IndexProdTf1=0.890&IndexProdTf2=0.000&IndexProdPhA=0.890&IndexProdPhB=0.000&IndexProdPhC=0.000

This is what is decoded by Mango :

Source: 81.243.242.216
Device ID: PGP_001EC01EF773
Time: 1441/12/15
FactorPhB=0.000
FactorPhA=0.980
FactorTotal=0.980
FactorPhC=0.000
WattPhC=0.000
WattPhB=0.000
VoltagePhA=234.500
IndexConsoTf1=29.960
IndexConsoTf2=0.000
VoltagePhC=0.000
VoltagePhB=0.000
WattPhA=1.740
IndexConsoPhC=0.000
IndexConsoPhB=0.000
IndexConsoPhA=29.960
__meter=14100021
IndexProdPhC=0.000
IndexProdTf2=0.000
IndexProdPhB=0.000

Peter,

You can use the following URL :

https://posttestserver.com/post.php

Mango will display the URL you can check the data as received by this application.

Here is the link to the site explaining details : http://www.posttestserver.com/

I have been using "YYYYMMDDhhmmss" format for date without any problem.

Now because the same device should send data to two different Host I have to move to the UTC format (millis seconds from 1, 1, 1970).

I experienced bad parsing of the timestamp while the same string is correctly parsed by a Web UTC -> Date string application.

Can anyone explain exactly how such timestamp should be formatted for Mango :

• 1231233112
• 1231233112. (decimal point)
• 1231233112.000
• 1231233112.0000
• 1231233112000 (no decimal point)

Thanks in advance for your assistance.

Pascal

I would like to know if it is possible to abort a Meta Datapoint script before creating its instance.

Let's suppose that :

• Raw data are acquire from remote sites
• Final value 'Meta Datapoints) are calculated using Raw data value.
• I would like to eliminate duplicate datapoints that have same value and same timestamp.

Would it be possible to check first the timestamp against previous value timestamp and if equal discard calculation WITHOUT creating an instance of the resultiong Meta Datapoint ?

Pascal