Irrigation control with mcsTasmota

[Michael McSharry]

Filtering for RSSI I can see one Sonoff with a payload of 68 and the problem Sonoff of 58. I can't access the webpage for the other values you were curious about.

You can see from my garage door LWT graph that RSSI values in the range you have have resulted in going offline with some regularity. Since my others with higher RSSI don't exhibit this behavior I think the solution path I would take is to improve the signal strength. One concept is to add an external antennae, but this is a more serious hack. The other is to setup another AP closer to the Sonoff units. Suggest also looking for congestion. Changing the channel of the AP may improve the situation. I'm not a network guru, but just talking out loud.

Is there some way to program the modules to turn off if contact is lost? I was looking at your image of publishing but wasn't clear if I could just have the relays default to open.

While this is possible, I think the current design is preferred. Each relay accepts max on and off times. Take for example an irrigation schedule that has been programmed with max on of 32 minutes and HS is setup with an event to turn relay OFF after 30 minutes. If the Sonoff drops offline after 10 minutes and HS OFF command is not delivered then the Sonoff itself will turn the relay off in another 22 minutes. (2 minutes after HS would have).

The same logic is applied to assure that irrigation happens at some minimum interval. This min irrigation feature is not something that devices such as Rain8 can provide.

Note also that MQTT protocol is designed for devices that tend to drop offline at random times. The MQTT broker knows the device is offline and will hold the command until it comes back online. With other protocols one must put this logic in HS/plugin to assure the device receives the desired command.

[donstephens]

Thanks for the explanation. I'll implement your backup technique. I'll try and boost the signal strength, although both sonoff units are in the same spot.

Appreciate the help.

[donstephens]

To revisit this, I have switched AP's on the offending Sonoff, and as of now it has been solid for three days. I hope this declaration of success isn't the kiss of death.

Thanks Michael and Pete for all the help.

[donstephens]

I'm having a bit of an issue with one of the Sonoff's dropping off the network for a bit and then coming back to life. I'm going to see how long it stays deaf. I need to come up with a strategy to deal with this. Probably the smartest thing would be to put it on the same AP as the other Sonoff, which seems to be much more consistent.

All in all, still pretty happy with this.

[BeePee]

Hi Michael, Thank You for the tremendous amount of work you have put in to mcsMqtt and the extensive documentation provided, it has provided me with hours of reading and a growing list of to do items.
I have just received some CH4 hardware, 2 Pro and 2 Basic units and I'm about to set them up for irrigation use. I am considering using your tasmoda build but have one concern which you may be able to easily clear up. In my Valve setup I have a master Valve. which needs to energize at the same time as any other of the 7 valves. How do I accommodate this as I expect only one valve is allowed to be on at a time. Also if a command is sent to open another valve while one is still on will it auto change over to the next commanded valve? The other option I was considering was to use EspEasy as I'm a little more familiar with it rules policy.

Thanks once again

B

[Michael McSharry]

The Sonoff 4CH Pro can be configured to operate the relay's independently so having a relay dedicated to master is not an issue. mcsSprinklers does support the use of a master on/off to protect from power inrush so in this case it would just be just part of standard process. I would need to check if MQTT for the valve protect device is an option. It should be.

If you use ESPEasy then you can still control relays, but you will not have the protection logic that I included in mcsTasmota to assure a relay does not remain on too long. It also has logic to assure that some minimum irrigation cycle is performed should HS not do its job as expected.

If you do not expect to use HS for irrigation control then you are depending upon reliable operation from the Sonoff. Irrigation is not critical as flight control, for example, but do consider your architecture that will achieve the desired reliability.

[BeePee]

Hi Michael, thanks for the clarification, In Australia it is a local law to have the master valve in series with the station valves as a belt and braces approach, especially towards saving water which is becoming more scarce by the day. I sure appreciate what you are saying about the necessary protection logic. Your method of sending the duration of watering is a lot more flexible than what I would have used, single timers for protection. (Aka Rain 8) which is where I'm coming from. Now that you have clarified the Master valve question, the next question is. Will I be able to run two units with the master valve residing on the only 1 of the two units?

[Michael McSharry]

A single master across all other valves is the mcsSprinklers approach. It is not clear to me where you are planning on putting your scheduling logic. It if is with Rules in ESPEasy or Tasmota then you need to incorporate a mechanism for multiple Sonoff units to exchange data. If you are using some external scheduler such as HS Events then you can control each relay independently across multiple Sonoff's with event logic for a single master. mcsSprinklers is setup for this and the integration already done so that would seem to be the simpliest. You can run mcsSprinklers as a HS plugin or independently on something like a RPi or old laptop. UPS backup of whatever you do is usually a good idea if you have any type of issues with power interruption.

[BeePee]

Hi Michael, I'm basically looking at a simple scheduling via HS3 events talking MQTT to the Sonoff's. I realize many HS3 Plugins are written for the US market, so I wanted to check if the preferred route mcsMQTT + mscTasmota would work or if not. I could fumble my way through ESPEasy and get something working as I find the rules easier to understand than the Tasmota rules. I have Schedules already setup in HS3 for a Rain 8 module but I want to replace it to improve reliability.

I am presently running the other MQTT plugin for some control and also have mscMQTT installed but disabled. It is clearly superior in its capabilities but I didn't have time to read the documentation so I put it on hold. My next question was going to be what is my best (quickest) upgrade path without breaking the existing MQTT stuff. I can deal with them later on a one by one basis or should I just bite the bullet and change over?

[Michael McSharry]

The easiest path is with mcsSprinklers. mcsSprinklers does not depend upon a MQTT plugin. It is just a client just like the other MQTT plugins.

If you want to install ESPEasy on the Sonoff 4CH Pro then you can setup rules as a monitor. This would likely be your simplest approach since you are familiar with ESPEasy rules. Note that Tasmota rules were inspired by ESPEasy rules, but for me the Tasmota rules were not that intuitive. Of course you do not even need rules. Just setup the switches on the Sonoff 4CH Pro so that relays are independent and then control them with HS Events. It is just a decision on the protection you desire.

If you use my variant of Tasmota and want to do scheduling by HS Events then you have to do some reading to understand the MQTT protocol that mcsTasmota is expecting. IT is documented in the mcsMQTT manual. Likley you will not want the auto mode that does protection from both off too long and on too long failure cases.