adding support for virtual sensors

[Seeburg]

Hi,

I just recently discovered OpenSprinkler, liked the idea, ordered one and just started using it (OS3.0 AC).

I like the idea of “virtual” valves aka the ability to define http devices that can be treated just like regular valves.
What about driving this idea and create virtual sensors? Instead of having to physically wire the max of two sensors have N sensors(there’s no limit) that can be feeded via API? This could also be weather sensors for temp/humidity or virtual switches.
I already have quite a few weather, moisture and rain sensors deployed if this feature would be available I would not even need external weather data. This data could then be used for the watering algorithms as well. Or a virtual moisture sensor per valve etc.

Not sure if that has been brought up before or if it’s maybe a stupid idea.
I was just about to start integrating the sensors into node red and move all the logic there and use Opensprinker to turn on/off specific valves. But from a use for the community virtual sensors might make more sense. I also think it would be a shame to degrade OpenSprinker to a stupid valve switch.

Thanks,
Stefan

[Ray]

This can be done in two ways: the easiest is probably to use an external server, like a Raspberry Pi, which receives data from the sensors, computes watering level or any adjustment you need, and use OpenSprinkler’s HTTP API to send the result to OpenSprinkler, say, to modify the watering level, trigger a rain delay etc.

The more difficult route is to modify the OpenSprinkler firmware to read the sensors. This is harder due to the limited computation resources of the microcontroller, and also you will be restricted to use C++ as that’s what the firmware is written in. In contract, with the first approach you can use any scripting language you want.

[Threaded]

I had the same thought as @Seeburg. Since this post OpenSprinkler has added support for HTTP API and subscribing to MQTT. Could those API actions include setting existing sensor or virtual sensor values. E.g. if the user has a separate weather station, they could set a “mm of rain in last 24 hours” sensor that the OpenSprinkler could use, as it would a weather report. Or if the user has a separate flow meter, they could see the flow rates and total – even just by making the existing readable flow sensors, also writable. Not sure how minimal that would be in the C++, but an idea for the backlog anyway.

[Ray]

Hi,

1) Our German distributor, Stefan, has pioneered a lot of advanced software features, one of them is exactly the ‘Virtual Sensor’ feature discussed above. You can take a look at his firmware release here:
https://opensprinklershop.de/en/opensprinklershop-firmware/

2) In the age of AI, these features are not only possible, they are actually fairly easy to implement. Install Codex, or Claude Code in the source code folder, and start describing what you want in natural language, and they will go and implement them in astonishingly little time. You still need to do thorough testing afterwards, but the implementation can be completely taken over by AI. They ensure the program compiles and can perform smoke test automatically. We routinely use them for writing software features ourselves. So you don’t need to wait for the official firmware release to introduce these features, you can do them yourself now.

[Author]

Posts