[chbot] No-code weather-station to web dashboard

[Stephen Irons]

In case anyone is interested in other weather-stations, here are two 
more.
<https://iot.irons.nz/dashboard/a8cc9220-ccc7-11ec-820b-4b7d98d3a1b6?publicId=6e6c2c50-a97a-11ec-9bda-613c875470bf> 
is installed in my garden shed. It is solar powered, but the solar 
panel gets a lot of shade from overhanging tree, and needs a bit of 
beefing up or re-siting. It uses a 1/4 wave whip (~500 mm long) on a 
magnetic mount stuck to the roof of the shed. This sensor measures only 
temperature and 
humidity.<https://iot.irons.nz/dashboard/1fbbfff0-ccc9-11ec-820b-4b7d98d3a1b6?publicId=6e6c2c50-a97a-11ec-9bda-613c875470bf> 
is installed on a vineyard near Waipara. It is also solar powered, with 
the same type of solar panel, but it gets enough sun to keep the system 
going. This one uses a 200 mm rubber-duck type of antenna on a 
drooping-radial ground plane. This sensor measures temperature, 
humidity, air pressure and light intensity.
These use Modbus-over-RS485 weather sensors connected to an 
RS485-to-Swarm satellite system gateway. They sample the weather hourly 
and create a report; when a satellite is visible, it packs as many 
reports as possible into a Swarm satellite message and sends it.

The Swarm satellite network is incomplete, so there are gaps of a few 
hours every day when there are no satellites. This is shown on the 
dashboards as 'Satellite delay', the time from when the measurement was 
taken until is was available at the Swarm web API. These gaps are 
reducing as they launch new satellites: there were 24 on the recent 
RocketLab launch from Mahia, where they caught the first stage by 
helicopter.

These installations are used as test sites for a sensor-to-Swarm 
gateway being developed by ioSphere. We have a number of other 
installations reporting different things, with different power 
arrangements and antenna configurations. The data from these 
installations is private, so we cannot share it.
an electrical substation, reporting phase currents and transformer 
temperatures;a solar power station on a dairy farm, reporting power 
yields, etc. Ironically, despite having 500 kW of power nearby, we have 
to provide our own 20 W solar panel;a coal mine, reporting water 
turbidity at a nearby stream. To install this, they took a 2 minute 
helicopter trip to save them a 2-hour walk;a car, connected to the OBD 
port, reporting engine hours, total distance, fuel usage, etc as 
available from the various ECUs in the vehicle

Stephen Irons


On Thu, May 5, 2022 at 08:53, Stephen Irons <stephen at irons.nz> wrote:
> An interesting little project I got going over the past few Covid 
> recovery days: connecting a weather-station to a web dashboard, 
> without writing any code.
> 
> <https://iot.irons.nz/dashboard/cfd3f2f0-c9cf-11ec-820b-4b7d98d3a1b6?publicId=6e6c2c50-a97a-11ec-9bda-613c875470bf>
> 
> I have a wireless weather-station, one of those ones that sends data 
> from an outside sensor (wind speed and direction, temperature and 
> humidity and rain-gauge) to an indoor console over a 433 MHz link. My 
> system is the cheap version where the console has no PC/USB 
> interface, and does not have Wi-Fi to upload to online weather 
> services; more expensive versions do.
> 
> I also have a Realtek RTL2832U DVB dongle, often used for cheapo 
> software-defined radios.
> 
> Duck-duck-going led me to RTL-433, a project that combines an SDR 
> project with the RTL dongle, and includes a whole bunch of decoders 
> for common 433 MHz devices: garage-door openers, car locks, remote 
> controls, and, of course, weather stations.
> 
> Installed the available package (sudo apt install rtl-433), fired it 
> up, waited a minute (the weather station sends data every 45 s or 
> so), and, sure enough, there was the decoded data: temperature in 
> °C, humidity in %, wind speed in °, wind direction in km/h.
> 
> There are options to
> restrict the type of messages decoded, so I don't hear any other 
> devicesformat the output as JSON rather than human-readable text
> Now, I have been playing around with Thingsboard, an 'IoT' telemetry 
> platform, which takes data from external devices, stores and 
> processes the data, and has a clicky control centre to create 
> dashboards with graphs, tables, etc.
> 
> You push data to Thingboard using either an HTTP rest-like API, or 
> using MQTT. In either case, the data must be a specific JSON format.
> 
> The JSON format from rtl-433 is not the same as expected by 
> Thingsboard.
> 
> jq to the resque.
> 
> jq is a command-line JSON processor, which can reformat incoming 
> JSON, changing the structuring, filtering out unnecessary fields, 
> etc. A little bit of playing go the rtl-433 JSON into Thingsboard 
> JSON format. It treats each input line as a single JSON document, and 
> transforms that into an output line of a single JSON document.
> 
> mosquitto_pub is a command-line tool to publish data to a MQTT 
> broker. It can send each line of input as a separate message to the 
> broker.
> 
> A single rather long command line does the whole thing: rtl_433 | jq 
> | mosquitto_pub
> 
> So, a bunch of environment variables and a single command line serves 
> to receive data from the weather-station and push the data to the 
> Thingsboard MQTT broker.
> 
> RTL_SERIAL, MQTT_VER, MQTT_HOST, MQTT_PORT, MQTT_TOPIC, MQTT_TOKEN 
> are set for your specific device, thenrtl_433 -d:$RTL_SERIAL -F json 
> -M time:unix:utc -M protocol -M level -C si | tee -a rtl-thing.log | 
> jq --compact-output --monochrome-output --unbuffered '{ ts: (.time | 
> tonumber * 1000), values: {battery_ok, temperature_C, humidity, 
> wind_dir_deg, wind_avg_km_h, wind_max_km_h, rain_mm, rssi, snr, 
> noise}}' | mosquitto_pub -V $MQTT_VER --host $MQTT_HOST --port 
> $MQTT_PORT --topic $MQTT_TOPIC --username $MQTT_TOKEN -l
> This runs on a Linux media server sitting near the TV.
> 
> A simple systemd .service file starts this up and keeps it going if 
> it crashes.
> 
> There was a bit of clicking around in Thingsboard to create the 
> 'device' that receives the MQTT data and stores it. Then much 
> clicking around to create the dashboard at 
> <https://iot.irons.nz/dashboard/cfd3f2f0-c9cf-11ec-820b-4b7d98d3a1b6?publicId=6e6c2c50-a97a-11ec-9bda-613c875470bf>
> 
> *Updates that need code*
> 
> Depending on when you look at the dashboard, you might see
> Wind-speed in knots rather than km/h, as I think of wind in knots. 
> There is a one-line Javascript function in Thingboard to do this 
> conversion for the wind-speed graph widget and the wind-speed numeric 
> display. I guess I could have done this in the jq transformation 
> step.The wind-direction is very noisy. I had to add my own smoothing 
> calculation. Thingsboard can do averaging, etc. However, smoothing a 
> compass reading is not a simple average: if the wind is hovering 
> around north, jumping from say 355° to 5°, a normal average gives 
> 180°, rather than 0°, definitely not what you want. DDG-ing leads 
> to <https://en.wikipedia.org/wiki/Circular_mean>. Essentially, 
> convert the angle to cartesian coordinates, smooth the x and 
> y-coordinates separately, then use atan2 to convert back to angle.The 
> rain gauge reports a single accumulated value since power-on. I have 
> processing to calculate rain in the past 1 hour and the past 24 
> hours. There was a tiny bit of rain yesterday evening.Pressure comes 
> from a different sensor via a different channel.
> 
> Stephen Irons

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20220505/8214337b/attachment.html>