Must admit that nowadays I rarely visit this forum.
Personally looking at LoraWAN oriented for meteo-datacommunication perspectives towards internet.
For the more remote locations, for meteo-datatransfer LoraWAN offers further-reaching range coverage than the ‘usual’ solutions with WiFi, Zigbee etc.
Other perspective: being in city-area, LoraWAN has advantage being less crowded (till now), hence less disturbed by ‘neighbours’.
But for longer range meteo-applications see upcoming more and more 4G-mobile configurations for really ‘long’ distance channels:
for users often juist plug&play with simple instructions, with webserver at receiving end taking care of predefined conversions & transfers without much action required from user.
That ‘simplicity’ has appeal, while LoraWAN considered ‘difficult’ and expensive.
In my own case still struggling with my very basic setup of Nodes &Gateway to get data towards my website, is reason to prefer the other solutions.
If TTN-interfacing, datatransport and dataconversion would be as easy as for the other configurations as mentioned, probably more favorite ……
E.g. Would help me if some Dummy-instruction available for example end-to-end setup to get periodic 15minutes’ JSON-readout from TTN for a simple meteo-sensor like Dragino LSN50, or for a PWS like this Sensecap-setup.
At my user-side for read-outs using Domoticz, Python-scripts and lua-scripts/DzVents.
PHP-script at receiving end would be very nice, aimed at seamless integration with website scripts …
Sure, for a couple of weather stations which by definition are usually well spaced apart so even LW coverage becomes questionable. But for having CO2 sensors in every classroom in every school as required by Dutch law, or any other situation where many sensors are needed in a relatively close (up to a couple of km) area, LW beats cellular all day every day. So not really expensive as a half decent cellular modem costs me ~€30 whereas a LW radio + MCU costs ~€6.
Perhaps you should have come back and asked here rather than struggling for the last couple of years - in that time I’ve done at least two webinars for TTN on this exact topic (check them out on YouTube) and I’ve the most quoted (at me) code on the forum for free here: GitHub - descartes/TheThingsStack-Integration-Starters: Starter / Template code for various The Things Stack (v3) integrations. Any questions on this stuff please open a new topic, not here.
In the two years whilst you’ve been away, I’ve formed a symbiotic relationship with another forum member and we’ve gone on to “build stuff”, me doing the integration & dashboard, that’s just won an award: Community prize for Dutch school/student project "Measure your living environment"
So some might say that the community works, it’s just that LW is no longer the “Next Big Thing” so there’s less apparent activity.
Absence not so much due to lack of interest at my side (and a variant of your hinted PHP-script already running for a few years as support for a simple setup), but sometimes more attention required elsewhere => priorities.
In that perspective ‘struggle with setup’ not proper expression:
better expression = lack of urgency to cleanup and to improve&expand (also still Marvins laying idle, needing upgrade for TTNv3).
Although LoraWAN returning as an interesting topic for my meteo-hobby, because the ‘conventional’ configurations not always suitable in more challenging setups …
As moderator at a weatherforum more often see questions how to equip a PWS (= PersonalWeatherStation) for a remote location.
Such question requires a more robust, alternative solution (yet affordable) covering distance more reliably than the ‘usual’ setups with Wifi etc., and LoraWAN may play a role in that niche.
Most meteo-guys prefer to concentrate on PWS-aspects other than interfaces, and that is reason to state that ‘the easier the interface, the more favoured for application’.
IMHO for PWS-application of TTN as ‘datacarrier’ 2 important aspects to be solved:
- how to interface the sensor system to TTN? Now some example-Nodes, but most are ‘proprietary’ and relatively expensive.
- how to interface from TTN to ‘common’ meteosoftware like WeatherDisplay, CumuluxMX, WeeWX, Meteotemplate or PWSDashboard? And/or how to connect to meteo-organisations like WUnderground, AWEKAS, XWeather and CWOP?
To answer the 2 questions above, we need people which are in combination well-versed in LoraWAN@TTN and interface- and meteo-software, with practical knowledge of meteo-systems, and willing to invest non-profit time for development & experiment:
such people are hard to find ………
Split this away from the community in NL topic as it wasn’t so much that as a cry for meteo solutions.
This response is to edit #8 - please do not edit again if it changes the context of the reply.
Somewhat in reverse order:
Really? A well formed question on here that’s not blatantly answered in the docs gets you another free piece of the jigsaw. If you’re holding out for a hero, that is “well-versed in LoraWAN@TTN and interface- and meteo-software, with practical knowledge of meteo-systems” you may have a long wait. But if you state the nature of your emergency problem in a relatively abstract way so that the intricate details of how, for instance, a tephigram shows where the dew point is at a certain altitude, is kept away from the faint of heart, you may find that you quickly accumulate the parts you need.
Such is the nature of the community & collaboration.
Just add LoRaWAN - there are hundreds of different boards that can be wired up. If you don’t know how, research & ask!
Relatively expensive is a double relative term - relative to what? Tell us what is a reasonable price, we may be able to point you to things that can do the job, albeit probably needing a bit more weather proofing.
The output from a LW device is usually well documented. If these softwares are well documented then scripting a convertor in anything from PHP, Go, NodeRED etc etc is about joining up the dots.
Ditto.
It’s all there to be had, it strikes me that you are in a good position to co-ordinate such activity. You may not get a flood of response straight away but if the results are shared, something like a PWS in every school is obtainable.
Personally I’m a bit old school with the sensors - mostly because I can 3D print / laser cut / fabricate an anemometer, wind dir & rain tip bucket - the rest is wiring up the right sensors for temp/hum/solar/UV. And, if you look at the MJLO website, you can see the free to use dashboard that’s available.
A project that comes to mind is this:
It interfaces somewhat popular Bresser weather stations and relays their data through LW with decoders so that all you need to do is catch the TTN output with an integration.
matthias-bs is a prince amongst gentlemen, from his readme:
- This should not be the first Arduino sketch you are ever trying to flash to your board - try something simple first (e.g.
blink.ino) to get familiar with the tools and workflow.- If you are new to LoRaWAN
- Check out The Things Fundamentals on LoRaWAN
- Read the excellent article RadioLib LoRaWAN on TTN starter script
Now, @Toulon7559, there’s evidence of the community in action. Steven bought RadioLib LW up to compliance and I wrote the notes. So there are definitely peeps around willing help.
Over to you!
Thanks for the better fitting split & labelling for the direction of this thread.
Impressed with the reference to the solution for Bresser-interfacing, etc.,
Good to know the availability, but unfortunately fear that such setup is still ‘way too complicated’ as DIY-job for most meteo-guys&girls I know.
They often need practical help at a lower level, approaching plug&play.
More or less along lines as earlier exercised in Enschede and presently done in Amersfoort for Meetjestad.
Really on-the-job instruction & assembly & installation, with attached support.
Elsewhere also initiatives, like in DePeel, but those are more concentrating on specific aspects.
So work with Matthias to add a supplementary document to bridge the gap. That’s how this stuff happens. You get one of the supported boards listed, read the numerous how-to’s on Arduino 101, read the materials, go back over it all again, learn, digest, try, ask questions, make notes.
Then you can run workshops in-person or online to guide people. This way they are invested in what they create.
Or fund the creation of a product, a not inconsiderable investment if the user base is so inclined towards it being gift-wrapped. And then the individual cost would have to come with anticipated support costs.
It would be interesting to know how many PWS owners have a station so far away it needs to use long range radio. It may be that the use of LoRaWAN is an edge case. But that still leaves you with the challenge a FSK to WiFi setup - which Matthias’s code base can be adapted to do.
So perhaps research how much LW is actually needed before asking people to solve setup & usability issues.
I’ve run multiple workshops like them in Groningen, most of them developed from scratch and each one takes at least one hundred hours to develop, source parts, write documentation etc etc. All for a workshop of 2-3 hours. And without any financial gain (actually even without counting the hours all at a loss because developing hardware requires iterations of hardware that can’t be reused).
So basically you are asking someone to invest the equivalent of at least 5000 euros in hours and hardware to develop this for you. For something they don’t need themselves (no scratch your own itch).
What incentive could you offer that person?
Some examples of concrete questions at the end of this message.
Understanding the various comments, because somehow a matter of ‘chicken&egg’, or alternatively expressed ‘caught in the middle’.
Consider the text below as a view from ‘Meteo-Userside’.
To be ‘interesting’ the commercial companies depend on enough customers, and as alternative volunteers must be willing & able to practically cover the effort.
Nobody requests/obliges volunteers to heavily invest.
This discussion at WXForum.net is an typical example of meteo-buds’ view on LoraWAN, with contributions from all corners of the world.
In other popular meteo-forum WeatherWatch LoraWAN is rarely discussed.
For a PWS any location at distance beyond coverage of PWS’s own communication system or WiFi is a candidate for LoraWAN.
PWSes like those from Davis in some way can help themselves using repeaters or better antenna’s, but also that has practical limits.
In the Netherlands the ‘remote’ installations of PWSes by commercial companies almost exclusively apply 3G/4G for communication, because of ease of setup, range coverage, available knowledge&infrastructure and related cost&support:
examples are agricultural setups on farms and for orchards, at golfcourses and in natural parks like SallandseHeuvelrug.
In discussions on dutch meteo-forums indicated that some meteo-amateurs can meet the space-requirements for installation according to the WMO-guidelines, but are scared by the aspects of less-known communication-systems over longer distance.
Related to funding the PWS-owners may be split in 2 categories:
- serious meteo-amateurs know that serious funding & effort is required for use of equipment like Davis Vantage
- aspiring meteo-amateurs often think in much lower budgets (of max. Euro 200~300) and prefer plug-and-play.
Questions from users
Experiences are tell-tale: see this forum-thread => user is stuck, needing specific help from ‘colleagues’, because of lack of support from supplier, but as pioneer hardly any response.
Users of Barani-PWSes have similar experiences: TTN may be the carrier, but for individual users the data via LoraWAN ends at Allmeteo.com. Hardly any support from the supplier, and very few PWS-owners in the Netherlands with Barani_PWS have solved the interface-issues.
In Belgium (Wallony) BMCB.Club cleverly solved this aspect by reading the sensor-data via LoraWAN and/or SigFox to a server of the organisation, and from there distributing compiled display. From user-perspective this setup is a semi-commercial operation, in which BMCB.Club installs and maintains the PWSes and the server. However, copy of this model in the Netherlands implies heavy investment in funds & people, which IMHO is impossible.
Ships, I see no ships. Concrete questions are like “how do you change the cement, sand & aggregate mix for foundations” - they are not links to forum discussions. This still remains very woolly.
I’ve spoken of my motivations as an open source / knowledge contributor on the script enhancement thread. Commercially I’m at my best as a Proof of Concept hacker type that brings stuff together - like Lego. Which ironically is what you are looking for as, quite rightly, there is a chicken & egg situation going on with the mainstream WS providers that get locked in to having a Pointed Haired Boss in charge of product development that thwarts the plans of Dilbert & Co. Or the development team is mainly maintenance as the business coasts whilst it sells lots of product, only ‘innovating’ when they have to.
However I’d have to be as mad as a badger to try to create product(s) for what is a typical technical user group - technical in the sense of the application, one that you won’t find in many households, one that holds steadfast views on the right way to do things. Not many TV remotes aren’t about 4cm wide and 15cm long - that covers most bases for most users. But for the various protocols from the WS systems that are available and the API’s for the various websites, you’ve got all sorts of combinations to consider along with all sorts of views on how things should be done.
So it comes back to someone making some very clear requests with links to the source materials - I want to relay data from {insert make / model here} over up to 2km to a location that will have internet that then relays the information to {insert website API support docs here}. There are some attempts on websites / GitHub at {link1, link2, link3 etc) here. Then and only then can you go on your fishing expedition.
And if you don’t catch anyone with appropriate skills, you collectively need to put your money where your mouth is. Like a reverse Kickstarter - you come up with a spec, you all say what you will pay, people submit proposals, commercials occur, everyone pays in to the common fund and the developer gets stage payments. There are systems like OpenCollective that will handle the money issues for you.
If you want to make progress, time to take action as suggested above.
Especially the first question in my previous message seems very concrete from user’s perspective.
Elements summarized from the quoted thread in the other forum:
- the User has a PWS Sensecap S2120 and uses TTN for communication
- payload-formatter is “Device Repository”
- output-chain is via DataCake.de,
set for TTN console / Applications / End Devices / Integrations Webhooks - the output value for precipitation is a scale-factor 2.6 too high
- furthermore precipitation value is expressed as mm/hour, which is nice for rainrate,
but for meteo the usual, more important value is raintoday_since_CET00:00 resp. raintoday_since UTC00:00. Not present in firmware <2.0: in practise means that hourly values for mm/hour must be accumulated to get actual raintoday-value.
His related questions:
- how to scale down the output value for rain/hour?
[it feels like incorrect conversion inch <> mm] - how to get an output value raintoday_since_00:00?
- lacking support from PWS-supplier, can this ‘correction’ and ‘extension’ be realised in the accessible payload_formatter or in payload_decoder? If, how?
Manual is this pdf-file.
Any other info required to tackle his questions?
Maybe, if you happen to have the time to visit another website and be able to read Dutch at a reasonable pace to look at the other posts to get context. Sure, my user id is the name of a French philosopher, but I’m one of those dumb English only Brits.
Now you have summarised it in the agreed language for this forum, so let’s dig in. 
How does this relate to LoRaWAN on TTN/TTI?
Surely this is a maths issue, somewhat domain specific to rain gauges and, as observed on the HetWeerActueel forum [Yes, I know, turns out I can read Dutch], somewhat of a strange choice by Seeed, what do they have to say for themselves? [Yes, I know, they don’t respond]
If you know it’s 2.6 times too much, then divide by 2.6. Or do a full calibration / surface area calculation and utilise those figures.
As a generic issue it’s a bit more relevant in the world of IoT. This will need some server side calculations as there is no state (no persistent variables) in the payload formatter that can accumulate values. This can be solved but may need an intermediary database.
You’d benefit from looking at the console, exploring the options, read the docs, copy the suppository JS, switch to ‘Custom Javascript formatter’, paste and edit. The code is a typical intern special, has loads of warnings & flags in the console editor and the one linked in the PDF is more recent & different to the one in the repository.
Have you noticed that v2 firmware sends Cumulative Rainfall in message type 4C? So no conversion would be necessary but it will still need to be added up from the reference roll-over time. Does it accumulate between uplinks or from last reset per the function in the mobile app.
The default Packet Policy will consume TTN Fair Use Policy within 15 uplinks - another good example of the disconnect of a vendor leveraging TTN for their product.
The challenge with the accumulate rainfall is that you need to allow some slack on the ‘start of day’ - if the first uplink of the day arrives at 00:15, that has to be made the start. If it arrives at 23:55, that could be the start. So any script has to have knowledge of the uplink duration or a database so it can figure it out.
Subject to some clear API docs, converting data from a device to the website format is relatively trivial - and with a database on hand, if there is any rate-limiting on the website submission, it can accumulate the data for you and submit at appropriate intervals.