Hi guys,
I got myself 2 Sonoff SWV water valves. the installation was straight forward and the integration into Zigbee2Mqtt flowless.
my key issue is that the valves turn them self randomly off.
I wonder if I need to add additional settings in z2m, as all the areas been blank before.
I add now everywhere a zero:
the valve turns off, out of nowhere.
I just installed a Sonoff Zigbee SWV a couple days ago, but am using ZHA instead of Z2M. I too am having the valve randomly turn off. It doesnât matter if I turn on the valve manually, by a script, or an automation. All these result in the valve turning off by itâs self after 30 minutes.
Firmware is up to date and the battery reports 100%. There are no configurations that I see that tell the valve to turn off after a set amount of time. How can this valve be set to stay open for, letâs say, 4 hours?
Iâve a 2nd question to add,
how can I identify in the logs that the valve has been manually been triggered by push of the button?
Sorry, canât add too much because Iâm so new to this - just figured out thereâs a whole zigbee2mqtt interface because I was wondering about the whole cyclic and quantitative irrigation. Posting just so that I can be a part of the discussion.
I think the cycle and quantitative irrigation is straight forward.
at the total number you define how often your system is switching on,
the duration defines how long it stays on and the interval definds how many sec it stays off.
for example:
when you say 6 times for total number with a duration of 3600sec and interval of 3600sec, then your valve turns on every 2h with 1h pause inbetween.
or you set to to 2 times with a duration of 60sec with a interval of 30sec.
then your valve turns of for 1min goes off for 30sec and then turns one for another 1min and then off.
same you can do with liters, . only that you define the volume and in what interval the next cycle shall start to complete your total numbers.
I also have these issues.
Some units are consistent in when they shut off, others the time seems to vary.
Hoping its not somehow related to flow rate and that the units shut off in low flow scenarios.
Even if you set cyclic water up, once it turn off the configuration resets from what i can see.
FYI, I also started a thread a few days ago with similar reports of the valves turning off arbitrarily and not running for the set duration. One of the posters reported opening a ticket with Sonoff but will see if support takes it seriously.
the feedback is non-sense so farâŚ
I made them aware of all the different channels posting about the same issue in my last post to them.
the latest feedback was:
followed by:
any volunteers who run the valve via ZHA or can easily switch over over?
happy to hook you up.
Get yourself a working valve from AliExpress: GiEX QT06_2 control via MQTT | Zigbee2MQTT
I tried SONOFF as an alternative today and it is just creepy⌠The thing works only if I define a cyclic irrigation interval. And this is unfortunately not yet supported in HA (although it is shown in Z2M).
I did manage to get the SWV in home assistant + zigbee2mqtt. The device shows up as a switch with other thing including cyclic_timed_irrigation and cyclic_quantitative_irrigation. The cyclic irrigation donât show up as a switch though, just an eyeball.
It would be nice to have it set so that anytime it turned on physically or through HA, that it would automatically turn off after a specified time without additional input. I was able to get cyclic_timed_irrigation to deliver water 1x for 20 seconds, and it turns itself off. This was through the zigbee2mqtt web interface, not HA.
So question for the experts - is there a way to make cyclic_quantitative_irrigation into something like a field or button, like the switch?
@Apron3130
I created a helper to represent the on/off state and then publish an MQTT message in an automation. Of course, your automation will also need to react once the water valve turns off (use the available Z2M switch for this purpose).
@janrothkegel , there is a simpler way to achieve what we need, without the need to use cyclic_timed_irrigation. The right payload is:
{"state" : "ON", "on_time": 2}
where the value of on_time is in 10 seconds (very odd, I know). In my example 2 means 20 seconds.
I did a few trials and in this way I can turn on the valve for a fixed time. The valve translates the above payload to:
{'current_count': 1, 'irrigation_duration': 20, 'irrigation_interval': 0, 'total_number': 1}
I read the first option in the docs but it didnât work for my devices 
Which firmware are you on?
My valves just updated to 1.0.3 and maybe the feature has only been added with this update.
I updated to 1.0.3 the day I got the valve.
I currently run a automation which detects when the valve turns off and turns it back on again.
I own 2 valves, one is currently disassembled and the other one is fully connected.
I can confirm when the valve is without water-pressure that the valve turns itself off after 29:56min. the connected one has a average turn-on-time of 4:50h before it turns automatically off.
What is the valve reporting as irrigation_duration after you turn it on? It is a countdown timer. The value is in seconds, and it might be 5h (about) is the maximum supported value.
On a different note, what is the minimum water flow these valves can detect? They donât seem to go below 1.7 l/m (about 0.1 mÂł/h). Unfortunately, this is a problem for me as I have a drip feeding system that runs at 1.45 l/m and the valve reports 0 mÂł/h⌠I wonder if this is a reporting issue (one decimal digit) or a detection issue.
Hi,
I tried to do the same and I have very strange behaviour, the values are totally different from what I send by MQTT. If I want to open for 12 minutes, it means I have to ask for 720 seconds, so i send :
{
"state": "ON",
"on_time": 72,
}
But here is the result :
Itâs 751 instead of 720, and the irrigation interval doesnât make sense at all. Sometimes it gets the good value, but it has this problem most of the time.
Do you have such behaviour ?
Best regards
Yes, I noticed that the value is not always the one we pass with the command. In my case I have seen variations in order of 1 - 30 seconds, that donât bother me. I wonder what kind of weird conversion logic is there.
As for the interval, I think it is similar: it seems there is some sort of conversion logic that goes in overflow.
Feel free to report the bug, I have recently contacted them to add two digits flow measures and they have recorded the request (they seem responsive, but not sure if they are ever going to do it).
We can only imagine the kid of weird hacks that these brands put in their firmwares.
