i posted some time ago about my trusty old river level monitor. i am still receiving occasional enquiries about it - yes, unfortunately that product i used is no longer available. whilst it is still working for me, i have now deployed a new river level monitor in parallel, some details below
old river level monitor Aquagauge provided a radio receiver with serial interface and a number of sensor types with radio transmitters. a receiver could support up to 8 transmitters. the radio and serial protocols are proprietary i wrote a weewx service that read the serial interface and inserted the data values into weewx packets. later i migrated this to a daemon that emitted the data as mqtt messages, and weewx reads the mqtt messages. this works fine; it is still in use this river level sensor is pressure-based i.e. the probe sits on river bottom (in my case wrapped around a brick and tucked into a river bank nook) and measures the water pressure. there is a very inconvenient cable from the probe to the transmitter. the latter measures atmospheric pressure, the pressure difference is the weight of the water above the sensor thence deriving water depth. it proved to be quite accurate the transmitter has suffered many travails, the latest being going for a swim during a flood when the bridge it was on was swept downstream. it is very robust but now failing more often and i fear one day soon not being able to rescusitate it → motivation for replacement. this product is no longer sold or supported new river level sensor i decided to try an ultrasound sensor i.e. the probe measures round-trip time for a signal reflected from river surface back to probe with known speed of signal. this means there is no cable needed to run into the river my river level sensor must be a commercial off-the-shelf product, for which i am happy to write interface software. it also has to be wireless connection to RPi at least 50 meters away and be powered by long-life battery i picked a Dragino LDDS75 Distance Detector (https://www.dragino.com/products/distance-level-sensor/item/161-ldds75.html). i mounted it under the sparkling new bridge i built over the river, higher than the old bridge. it sends quite large and complex messages via mqtt, so i wrote a daemon that plucks the salient data and re-publishes as simple message, imported into weewx. my daemon also configures a fix-point height for the sensor, so the simplified mqtt message includes a ‘level’ field as well as ‘distance’ for easy digestion this is a LoRaWAN device so provides the long distance and battery longevity i require radio receiver server the new river level sensor is the first of several sensors on my new open radio network, as opposed to the closed proprietary radio network per Aquagauge, so i need a radio transceiver to talk to them. i assume familiarity with LoRaWAN (https://www.thethingsnetwork.org/docs/lorawan/architecture/) for the local LoWRaWAN gateway, i put a RAK 2245 LoRaWAN HAT (https://www.rakwireless.com/en-us/products/lpwan-gateways-and-concentrators/rak2245-pihat) on an RPi 4B and installed RAK’s gateway software from their GitHub i tried using the chirpstack LoRaWAN stack running on local server but couldn’t get it to work reliably, it seemed to work only intermittently. i think i was having trouble with not picking up the radio packet preamble but, not being a radiohead, gave it up as too much like hard work. i tried The Things Network stack (https://www.thethingsindustries.com/docs/getting-started/ttn/) and, to paraphrase steve jobs, ‘it just worked’. i am using the ’community edition’, which is a subscribed but free service. the downside is that the network server and join server run on TTN’s hardware over the internet so i lose device connectivity when internet link is down. they provide the software to run your own copy of the stack, which i plan to do in future so, the river level sensor emits radio packets, my RPi gateway receives the packets and sends to TTN stack, the TTN stack processes and emits them as complex mqtt messages, which my dameon picks up and simplifies, then weewx digests the simplified mqtt messages. (i have chosen to put LoRaWAN gateway on a separate RPi from the weewx RPi) the TTN stack’s mqtt broker is on their remote server. i have chosen to bridge that mqtt broker to my RPi gateway so that, from my home network’s perspective, all that LoRaWAN stuff is happening on my RPi gateway. this fits my plan to move the TTN stack to the RPi gateway in future the RAK 2245 includes an itty bitty antenna. i get a good signal and reliable connection at 100 meters, haven’t tested further distance. LoRa supports 10 km with a decent antenna additional sensors the LoRaWAN gateway supports a lot of LoRa devices simultaneously, it is just a case of joining them to the radio network and processing their dat i have also deployed a river temperature sensor (replacing the VP2 wireless temperature station crushed in a storm a year ago). i picked a multiple-probe Dragino LSN50v2-D23 Waterproof Temperature Sensor (https://www.dragino.com/products/temperature-humidity-sensor/item/193-lsn50v2-d23.html) to see how well multiplexing on single device is incorporated and, as you would expect, it is just additional fields in the mqtt messages for each probe conclusion reading back, it sounds more complicated than it is. i grabbed a separate RPi, stuck a bit of RAK hardware on it, installed RAK’s software, subscribed to TTN, configured my RPi into the TTN service, and i had connectivity. i wrote a daemon to make the sensor data more digestable for weewx what i got was an open, extendable radio network that supports long distance wireless sensors, for which there are multiple vendors competing to sell you their sensors see https://wx.geddy.au, pull up ’today’ charts cheers ⊣GE⊢ wx.geddy.au ⊣GE⊢ -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/4C49F8B2-EB4E-41AB-B9BC-A2AAE6FD40F5%40geddy.au.
