Topic: Barani FAQ section

[Tln7559]

Quoted from the MetOffice's format description

Frequency of submitting observations
It is recommended that the interval between automatic observations from your AWS is at least 5 minutes.

IMHO it means that you should no upload faster than once per 5 minutes .....

[Julius]

"Measurements are collected 12 times an hour, and the meeting is therefore at least 9 minutes and with the exception of 18 minutes behind reality, when there are measurements that are just on that edge (so exactly in the minute that the data is retrieved.) Then you will not see it in the NL map (the UK map uses different timing for the data so you will see it there, but sometimes other data will disappear for the same reason). If the used user waited 11 min and then looked at an old map, his data would still be there.

It is currently unknown whether and when this can be resolved.

Sincerely,
Mrs. E. Andriessen
KNMI Climate Desk / WOW"

So nope, the issue is that when you upload with an interval of exactly 10 minutes, for all the WOW interfacing sites, the second 5 minutes (of those 10) your data will not be shown on several maps, among which that of KNMI. It's easily replicated. Just try using a 10 min. interval for metoffice.uk, see what happens. Don't forget to refresh the page (f5).

[Tln7559]

Julius,
Correct me if I'm wrong in understanding!
Have a feeling what she tries to tell, but would have preferred to see the original dutch text from Mrs.Andriessen:
probably for a Dutchman much easier to understand .....

Reading and trying to understand the contents of Reply#25, it seems
- MetOffice is reading the received messages at a rate of 12/hour =? exactly each 5 minutes, that is sharp at 00, 05, 10, 15, etc.
- Data coming in at exactly the reading poll is missed & lost, or perhaps included in the next cycle
- WOW-sites get results from that reading (if valid enough) with an obvious delay, because reading & processing takes time.

Perhaps a 'naughtly' idea, but if you would upload with an interval of 5 minutes, but with an offset of 1 till 3 minutes, your data is always coming into MetOffice before it's next reading poll, matching each cycle of MetOffice's  reading, and dataflow to MetOffice and the following WOWs would be unhindered.
Correct?

Offset of upload 'spoils' the timing aimed at a nice grid of 5 minutes (or similar), but the solution for that aspect is including socalled 'validity time' into the messages of the dataflow: enables correction of delays in data transfer by extrapolation.
Never seen applied in public meteo information exchange, but well-known in realtime control systems.
Requires a different kind of processing both at transmitter end and at receiving end ........

[Julius]

Julius,
Correct me if I'm wrong in understanding!
Have a feeling what she tries to tell, but would have preferred to see the original dutch text from Mrs.Andriessen:
probably for a Dutchman much easier to understand .....

Actually, she sent it to me in english. Probably because my 'complaint' came in through MetOffice UK, where a similar issue exists, but with a different interval issue. For metoffice it's probably exactly 5 minutes for each update interval, instead of 9 minutes for KNMI.
Either way, all complexity aside, regardless of what they chose to do; I've tested quite a bit with that, and just found out that when you upload data with a 5m00s interval, all is fine. As soon as you change it to 6, 7, 8, 9, 10 minutes, there are dropouts from the WOW maps, all with different stages of severity. MetOffice told me they already changed 'things' with their database cache a little while ago, but the issue is still there.

[Tln7559]

'Fact of life'
With this knowledge, the info from MetOffice is correctly written:
we should just avoid a high tolerance and/or an offset for the upload to MetOffice.
Then copy to WOW_NL is also OK ......

[Tln7559]

Direct interfacing always to be preferred above an idirect route, but with BARANI unavoidably indirect because of use of SigFox or LoraWAN as medium for communication.

Found the interface description (= payload-decoding): https://www.baranidesign.com/meteohelix-message-decoder
Question:
somebody already realised 'his/her' own private chain from sensor to application (not with e.g. WU or WOW as intermediary party)?

[Julius]

Direct interfacing always to be preferred above an idirect route, but with BARANI unavoidably indirect because of use of SigFox or LoraWAN as medium for communication.

For LoRa devices you can use the direct output from TTN, but you'll need to set up a receiving server-end, with encryption key-exchange etc.

Found the interface description (= payload-decoding): https://www.baranidesign.com/meteohelix-message-decoder

I posted that info on the wx forums already. Thus far nobody seems interested yet, probably because very few users own barani devices. So yes, I need more time to do it myself. Or hope that Pierre Lannoy of the weather station wordpress plugin feels like decoding barani-stations data directly from TTN. That plugin can interface to other sites and even to weewx on the same server etc.

[Tln7559]

Because I mainly use Domoticz, I also asked in the Domoticz Forum whether they have a technical solution to read TTN for BARANI-Loran-devices.
It seems that the Domoticz' function TTNMQTT is an answer, but have to explore what it practically means.