Solenoid valve control

[Michael McSharry]

Using DC power for the board should be fine. Another option is to provide an independent 3.3V power source. Gnd, Rx, and Tx through the USB/Serial adapter. The adapter configured for 3.3V and not 5V.

It has been awhile since I flashed the 4CH, but I do usually do use a laptop for flashing and the 3.3V provided by the adapter. It could also be the adapter rather than the USB port is limiting the 3.3V output.

[Feral]

Thanks for you help, I managed to flash it with the DC power connected and just GND, RX and TX from the adaptor via an old laptop I had in the loft. I was cagey in connecting to my PC as i've only had it built a couple of weeks and one of the DIMMs has died.

Next thing i'll need to do it ensure the correct settings are in place via the pins and then see whether i can connect to HS but might not get around to it this weekend.

[Feral]

got this working now. I think for my needs, mcsSprinklers is going to be overkill by quite some margin but it looks impressive. I managed to set up the MQTT settings on the tasmota and mcsMQTT picked up the data. It was more straightforward than expected to turn the associations into controllable HS devices. All I need to do now is wire the Sonoff to the valvebox to test before connecting the pipes and create some events to manage the valves.

[richardfj]

I went a little bit of a different route and I'm actually quite happy with the solution.

I bought a regular weatherproof controller box at HD (https://thd.co/2DyKokG), and mounted four Shelly 1 relays inside (https://amzn.to/3i9TIKD) (on the back of the grey cover that sits inside the box). I used an Orbit 24V AC transformer meant specifically to power solenoid valves (https://amzn.to/30uoHeh), and then I mounted four manual switches in the face of the grey inside cover so I could manually control the zones if needed. The Shelly relays have been pretty rock solid so far (about 9 months of use and not a single failure of any kind).

Finished product looks pretty clean IMHO

[Michael McSharry]

got this working now. I think for my needs, mcsSprinklers is going to be overkill by quite some margin but it looks impressive. I managed to set up the MQTT settings on the tasmota and mcsMQTT picked up the data. It was more straightforward than expected to turn the associations into controllable HS devices. All I need to do now is wire the Sonoff to the valvebox to test before connecting the pipes and create some events to manage the valves.

If you have mcsMQTT for other MQTT integration then great. If all you are doing with MQTT is mcsSprinklers then mcsMQTT is not needed as mcsSprinklers talks MQTT too. A MQTT broker will still be needed and if you do not have one installed then the broker built into mcsMQTT is still an option.

[Feral]

I've got a Daikin Aircon which is integrated via mscMQTT on the TCP Daikin tab so it made sense to use that plugin to control the sonoff. Testing was fine and just need to connect the water feeds over the weekend.

[Feral]

that's a nice looking box Richard. I've just hiding my ugly one around the corner so i can pull it out if i need to.

[Feral]

I've got it plumbed in and tested the controls all of which are working fine. Something weird though when trying to control the device via events.

I can create an event to turn on the device and close after waiting a set time. If i create an event with multiple on and off commands for the different valves the MQTT commands seem to get parsed in a single group, all the ons and offs together. The same thing happens if i create and event for on and off for each valve and then have those events triggered by another event.

The only way i can get this to work smoothly is to have an event triggered by a time that will switch the valve on and off after a time, followed by a separate event time triggered, etc.

It seems that when the events are chained all the MQTT commands get grouped and sent. Is this expected behaviour?

[Michael McSharry]

The MQTT broker does not assure a FIFO message routing. I suspect this is where the alternate grouping is being performed. Wireshark could be used to confirm. If the QOS is changed to a higher assurance level it may affect the queuing.

mcsMQTT and mcsSprinklers do use a FIFO for queuing messages. If debug is enabled in mcsMQTT then the relative timing of each message will be shown.