Feature: MQTT notifications

[jbaudoux]

Allow to connect to MQTT broker.

Send notifications of the events:

• system start
  topic: opensprinkler/system
  message: {"state":"started"}
• station start
  topic: opensprinkler/station/<id starting at 0>
  message: {"state":1}
• station stop
  topic: opensprinkler/station/<id starting at 0>
  message:
  if flow sensor configured: {"state":0,"duration":[integer],"flow":[float]}
  else: {"state":0,"duration":}
• measured flow
  topic: opensprinkler/sensor/flow
  message: {"count":[integer],"volume":[float]}
• rain detection
  topic: opensprinkler/sensor/rain
  message: {"state":0/1}
• weather update
  not implemented yet

Allow to configure the events to be notified.

[jbaudoux]

I have created this issue to log what I initiated and to discuss any nice to have to integrate regarding MQTT.
Working in progress is available here: #113

#102
OpenSprinkler/OpenSprinkler-App#80

The url of the broker is currently hardcoded to localhost during compilation. Only ospi is currently supported but it should be easy to extend to other platforms.

[ruimarinho]

@jbaudoux this is great! Are you looking to add /set to switch stations on and off?

[PeteBa]

@jbaudoux , some thoughts on the notifications.

• Multi-OS setups: I suggest extending the Topic string to include the Site name of the unit to differentiate multiple OS setups, e.g. opensprinkler/site/station/id
• Flow Rate monitoring: having a regular notification, say every 30 seconds, with volume and average flow rate over that last period in the payload would let you monitor for leaking pipes and/or stuck valves
• Weather Call Failure: adding errCode to the payload of the Weather Call notification lets you track if there are problems getting an updated watering level and check if something has gone wrong
• Alternative UI: I show the currently running watering cycle on the UI of my home automation system (Home Assistant). To do this I need to have start, stop times as well as station name and water level added in the Station Start payload so you can provide a real-time status display
• Station Run Stats: adding duration, volume, average flow rate, water level as payload fields in the Station Stop notification let me explore zone usage and water savings over time

I am sure there are a whole bunch of additional uses but these were the ones that I have made most use of with my set-up. Happy to provide a view on the message structure that I use.

[nagyrobi]

Please add Water Level % and also Operation status (enabled/disabled as on/off) to MQTT notification.

[StohanzlMart]

ADS 1115 with CUSTOM_SENSOR MQTT : StohanzlMart@791d2be https://github.com/StohanzlMart/OpenSprinkler-Firmware/compare/791d2be..a2a3db3

[hansonap]

At a minimum, I'd really like the ability to modify, what I'll refer to as the prefix, the opensprinkler portion of the topic so that different location / devices can be differentiated. Taking it one step further it would be useful to modify the topic for each mqtt message with templating, so the flow sensor topic could be customized as such:

my/differentiating/prefix/{device_name}/volume/ Water Usage

My primary goal is to monitor water usage realtime to detect failures such as broken lines or stuck valves. Currently I have a service running on a server that subscribes to "opensprinkler/sensor/flow/#" and then publishes a new message with a new topic and format to be consumed downstream. Currently, this information is only published when a station ends and not in realtime so I can't create alerts using a time series like I do with other data, so it would be desirable to publish a message each time the flow sensor pulses.

[duanem]

modify, what I'll refer to as the prefix, the opensprinkler portion of the topic

Merging many systems together into one MQTT set of topics is often (usually?) handled by an MQTT bridge. A bridge is usually a separate MQTT broker configured to merge topics including renaming topics.

…

On Jul 11, 2024, at 3:24 PM, Alex Hanson ***@***.***> wrote: At a minimum, I'd really like the ability to modify, what I'll refer to as the prefix, the opensprinkler portion of the topic so that different location / devices can be differentiated. Taking it one step further it would be useful to modify the topic for each mqtt message with templating, so the flow sensor topic could be customized as such: my/differentiating/prefix/{device_name}/volume/ Water Usage My primary goal is to monitor water usage realtime to detect failures such as broken lines or stuck valves. Currently I have a service running on a server that subscribes to "opensprinkler/sensor/flow/#" and then publishes a new message with a new topic and format to be consumed downstream. Currently, this information is only published when a station ends and not in realtime so I can't create alerts using a time series like I do with other data, so it would be desirable to publish a message each time the flow sensor pulses. — Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOLKMCXA7GXYORDOKHYTY3ZL4A3RAVCNFSM6AAAAABKX2N2V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRUGA2TKNZQGM>. You are receiving this because you are subscribed to this thread.

[hansonap]

Yes, but if I am unable to modify the prefix to make each instance unique then I have to have a bridge per device.

[rayshobby]

We can modify the firmware to make the root topic editable via UI. In the meantime, you can always modify the firmware yourself. The root topic is defined here:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/mqtt.cpp#L80
you can change it to anything you want.

[chadkouse]

Hi - really appreciate what you've done / are doing here. Just had a quick question - what is the reason the weather update event isn't implemented for MQTT?

[rayshobby]

There is no particular reason. The developer who wrote the MQTT feature initially didn't include weather event, or didn't feel it was needed. In fact, we are working to improve the MQTT feature at the moment, so I just went ahead and added the weather event:
b727452

[chadkouse]

Awesome thank you for the incredibly fast response! I'll keep an eye out for a new release with these improvements!

[rayshobby]

@chadkouse, this addition has been addressed in PR #288 and will be released in firmware 2.2.1.