Support for RAK5801 4-20mA analog sensor module?

[BentBanana]

Feature Proposal

I've implemented and tested support for the RAK5801 4-20mA sensor module for industrial/agricultural monitoring.

Use Case

• Water level monitoring (currently deployed on farm)
• Works with any 4-20mA sensor (pressure, flow, soil moisture, etc.)
• Reports raw current values for user-side conversion

Implementation Details

• Follows existing TelemetrySensor pattern (similar to BME680, INA219)
• Simple ADC reading, no external dependencies
• Tested and working in production
• Clean, documented code ready

Question

Would this be a welcome contribution? The RAK5801 is official RAK Wireless hardware and fills the gap for analog sensor support.

Happy to submit a PR if there's interest!

[Pearo]

Just started looking for something like this for my farm.

[killermonkeys]

I'm about to implement precisely this, what sounds like nearly the same use case. I'm making a weather station that will mount on an old water well head and using 4-20mA hydrostatic pressure sensor to measure the water table level in the well. I already have the sensors, RAK5801s and RAK4631s. I thought meshtastic already supported this telemetry (I thought this was the "power" telemetry). But looks like I'll need to implement it.

Maintainers: 4-20mA sensors are very power efficient, so they are a perfect fit with the RAK4631. My use case fits into "environment monitoring" and I'm already consuming other environmental telemetry via MQTT. I don't think it matters how the sensor value is represented as long as it has full precision because it's easy to calibrate/scale the value somewhere else.

@BentBanana if you still have branch that has this implemented I would really appreciate if you'd upload it. Otherwise I'll probably hack it together.

[killermonkeys]

BTW in implementing this for myself, I see one potential issue: there's a PIN conflict with GNSS modules like RAK12500 and RAK1910 which use WB_IO1 as PIN_GPS_PPS (1PPS, a 1hz clock I guess?) when the GPS is installed in slot A. This conflicts with RAK5801 which uses that pin for reading sensor 0. The good news is you can have a GPS and RAK5801, but the GPS must be installed in SLOT D and if SLOT A is used, you'll have a pin conflict.

I'm not sure how to document where people can see it. This isn't an issue with meshtastic, it's a pin conflict with these RAK modules. RAK has some very basic warnings about minding pin conflicts but not much.

[BentBanana]

main.cpp

Hey, I didn't get many requests for it so I never put it on a public git. I do have it still though, maybe this might help. There are 2 references to region you may have to change if your not in AU. I have the Platformio.ini as well if your using VS. It's been working well now for a few months.

Feel free to add it to a public git if you want to maintain it.

[Ycg675]

All,

did you get the 5801 to work on meshtastic? I am working on a node to measure the lake height for flooding and tracking. Please LMK if you have it working and how I can get it to work?

[killermonkeys]

Hi, I did get it working and it's deployed on 2.7.15. I didn't base my code on BentBanana's because it was easier to start from scratch (with AI...).

However I never was able to verify it on develop (main) branch on ESP32 because when I did my node would crash due to OOM when it tried to do MQTT over TLS. There was a known issue for this but I'd have to go back and look at notes to find it. So nothing to do with the new code but it was stopping me deploying or end-to-end verifying it worked since part of my build was to use MQTT over TLS. Once that happened I didn't try to clean it up or generalise it to make a PR.

I can try to clean up my branch and publish it if that would help you?