MQTT topic :: "opensprinkler/station/#" not publishing for a master station when turning OFF.

[savageautomate]

When turning ON a station, I successfully receive a MQTT topic for both the target station and the associated master station.

I see a special set of code is used to publish the MQTT topic for the master station here during a NOTIFY_STATION_ON condition:

https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L900-L902

https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/d39115ff35778d8b8befe1660cbaf89cd5fbcdff/main.cpp#L900-L902

However when turning OFF the same station, I do receive the MQTT topic for the target station, but no MQTT topic message for the master station. In a quick look at the code, I did not see a corresponding location where NOTIFY_STATION_OFF is handled/pushed for master stations.

Running on firmware v2.2.1

[rayshobby]

The explanation is provided here: https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-2-10/#post-79779 it's certainly possible to implement the OFF message for Master too. It's just that the ON message was quickly implemented to address some customer's need. Also generally the OFF message needs to include the total run time, which for master is a bit more work because master zones don't appear in the running queue so will require additional variables and calculations to track the total running time.

Do you actually need the OFF message for master zones? What's your application?

[savageautomate]

Ray, Thank you for the clarification ...

From: https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-2-10/#post-79779

For that reason, we didn’t add ‘master off’ but this can be added in the future.

Can we please add that as a feature request?

I am sending ON and OFF signals to a remote location to control my master pump (and other zones)… far beyond hard wiring or WiFi distance. I need a reliable method from OpenSprinkler to know when the master pump is supposed to turn ON or shut OFF. Currently I am using my own long distance radio hardware and I’m polling the OpenSprinkler system against the API method to get the status of all stations every 5 seconds — but this is unnecessarily taxing the OpenSprinkler MCU and sometimes it becomes unresponsive for short periods.

Another helpful feature (at least for me …) would be to flag all the “opensprinkler/station/##” topic MQTT messages as RETAINED. If I had this I could use MQTT as the single source for existing station states. Well .. on second thought, maybe even better than retaining the message would be to set the message expiry on the MQTT message to equal the length of time the station is expected to run for ON states This way the message will remain available to MQTT subscribers while the zone is actively running. This handles a use case where the subscriber connects to the MQTT broker after stations are already actively running and the subscriber would have missed the ON notification message.

Thanks, Robert

Also responded in forum.

[rayshobby]

I am confused by this description: "a reliable method from OpenSprinkler to know when the master pump is supposed to turn ON or shut OFF" -- I thought you were talking about the MQTT publishing feature, i.e. OpenSprinkler sending information out to a MQTT broker, but this description sounds like you want OpenSprinkler to receive (subscribe to) information? Can you explain how exactly are you sending command to your remote pump?

I don't know how to set a MQTT message as RETAINED, or how to set the message expiry. I think you are far knowledgeable about MQTT than me. The firmware is completely open-source, you can feel free to modify the source code to fit your need. And if you think the changes are useful to other people, you can submit a pull request, we will review and integrate the pull request if we think it can be a commonly used feature.

[savageautomate]

I thought you were talking about the MQTT publishing feature, i.e. OpenSprinkler sending information out to a MQTT broker, but this description sounds like you want OpenSprinkler to receive (subscribe to) information?

Yes, I am only talking about specific feature enhancement to the MQTT implementation in the OpenSprinkler firmware. I am only talking about OpenSprinkler publishing MQTT messages; not subscribing to anything.

I have a separate device (lets call it ProxyTransmitter) that sits alongside the OpenSprinkler hardware and communicates with it over the network via the OpenSprinkler HTTP API . I am currently polling every 5 seconds against the HTTP API to get the current state for all stations. I was working on modifying my implementation of the ProxyTransmitter to use MQTT to actively get notified when stations change instead of having to constantly poll the HTTP API. It's all working great with the one exception of not getting notifications for master station OFF. The ProxyTransmitter then forwards the station states to a separate ProxyReceiver via long distance RF radio signals. The ProxyReceiver then controls relays to activate/deactivate the master pump and other remote zones/stations. It looks something like this:

[OpenSprinkler]  <----------> [ProxyTx] ----------> [ProxyRx] -----> [IrrigationPump]
                  (HTTP API)            (RF RADIO)           (HARDWIRED)

The firmware is completely open-source, you can feel free to modify the source code to fit your need.

Yes, I'll take a look at adding support for the MQTT message expiry. Since you are already including duration in the MQTT message payload ... it should be a simple change to the existing implementation and such as change should not negatively impact existing users. It will just cause the station change messages to linger on the MQTT server until they reach their expire time. Let's just ignore the comment about RETAINED messages. I think the TTL (expiry) on the messages is a better implementation.

And if you think the changes are useful to other people, you can submit a pull request, we will review and integrate the pull request if we think it can be a commonly used feature.

Yes, I'll submit a pull request. I do think it would be a useful enhancement for the MQTT integration. I also prefer to stay on the official firmware and not run too much custom stuff and have to mange manual updates as the firmware changes.

Thank You, Robert

[savageautomate]

Well .... that didn't take long to figure out message TTL (expiry) is not a simple change.

Apparently message expiry was only added in MQTT5 and the PubSubClient library does not support MQTT5. REF: https://github.com/knolleary/pubsubclient/issues/790

I'll have to rethink this one .... or wait until PubSubClient supports MQTT5.