Weather Station Hardware > Barani Design Weather Stations and Accessories

Forwarding and publishing of weather data

(1/2) > >>

Been experimenting with the FTP output/forwarding options, in order to get the data of 3 different devices (or 2 in my case, still waiting for the MeteoRain IoT LoRa unit) into one display via WeeWX. This ends up being harder than expected with the Barani devices, since the FTP output lacks a lot of options. We can't bind 3 device outputs into 1 ftp upload file, let alone properly pre-format the way the output units look. The way allmeteo allows setting this up now is not very useful. It's lacking in how it uploads the data. It either sends a file every upload (and overwrites the existing one), or it adds to an existing file. It misses precisely those options I hoped would be there, and so within seconds I would have to script it all on a server with each new ftp upload, causing even more delay before it can be accurately merged and viewed. I tried doing this server-side, it's one huge conversion mess, where each value needs scripting and binding with timestamps.

Similar issues exist with forwarding to sites like WU; It cannot easily bind MeteoHelix, MeteoWind and MeteoRain output into one ID, if WU even allows receiving them separately. allmeteo can provide parts, but WU expects miles/hour output, which MeteoWind does not provide, to name one. So, again, you first have to convert it from an FTP inflow, then upload it separately to WU, causing delays and time-mismatches.
This is just WU. It would be better if barani could, for example, work in full cohesion with weewx or openweather formatting, and stack or concatenate data somewhere before doing the upload(s).
Anyone that has parsed all outputs into one dashboard already? If so, how did you go about it?

It's disappointing to find out that the visualizations are entirely locked behind auth, and lack theming. I'd much rather embed parts of it publicly for some other website. For now, the only viable option seems to be using raw output from The Things Network for whatever display view allows for that as a source. I don't understand why they've chosen to re-invent the wheel here, limiting their output this way. Not one api that understands all devices and allows for embedding or viewing on a self-hosted or *public* site? And why should each device visually reside in separate 'stations'. As long as they all are located within meters apart, the dashboard should show it all on 1 page, at the very least.

Can someone please tell us where to get the embed code for the widgets used here?
Why is this all so hard to find for allmeteo data?


The widgets used by BMCB are their own production at their own server.
Reading your previous message, IMHO it boils down to:
- if you have multiple datastreams and less 'end-applications', in some way you must merge the datastreams before you feed data to the 'end-applications'.
- even more important is that organisations often have a limitiation on calls/day, and/or they limit the intervaltime between calls
[at least for the 'free' subscriptions. For paid services different rules apply]

Data-merging needs an 'intermediary' script of some kind.
In my own system configuration I apply 'Domoticz & Auxiliaries' for that function:
- script types are lua/dzVents or Python (dependent on best availability&features vs required functions, and due to 'matter of taste')
- data from various sources is received 'at own speed & time, in own layout' and feeds devices or virtual devices in Domoticz
- result is that sensor-data is 'harmonized' at those devices
- from the collection of (virtual) devices a new data collection is compiled (in appropriate format & units as required by the 'end-application') and the related uploadfile is built, and transferred in the appropriate layout & timing.
In that way I realised working solutions for uploads to WU, MetOffice/WOW, PWSW and AWEKAS, as well as for my own website.


--- Quote from: Tln7559 on February 21, 2021, 04:17:14 AM ---The widgets used by BMCB are their own production at their own server.

--- End quote ---
Yes, I can see that, everybody sees that. It's not their own production, since it pulls data from barani devices' output. The point is: ALL barani users would like to be able to show these widgets. They look exactly like the widgets barani provides on its website, but more elaborate, even showing the allmeteo logo. This is really weird, comes across as very strange for all (new) owners of barani devices. They will all wonder where to get the code to run widgets that way, only to find it's nowhere to be found. BMCB apparently uses some kind of vendor lock-in, if you want to show your data, you need to use their server(s) and software. This is not what the meteorological community is looking for.


IMHO this is more or less the characteristic of a 'closed' network:
for the Barani-systems you need to go through the SigFox-netork or through a LoraWAN-network:
usually the apllication at the 'exit-point' then determines how you get the data.
They are rather clear for the description of this exit at data-level.
Widgets is another aspect.


[0] Message Index

[#] Next page

Go to full version