Closed phurth closed 5 months ago
It's possible to change it, the issue is around usability.
5 minute increments from 5 to ~1400 is very unweidly in the UI.
What about a service call that allows you to s set the duration manually, in seconds, bypassing the number entity?
FWIW, turning on via mqtt does a very similar thing to your REST call, and "waters" for 1439 minutes.
A service call would be great. It's what I'm doing now with a direct REST call. I had all kinds of trouble getting turning on - and staying on - to work properly with MQTT. HTTP seemed much more reliable when I was testing.
Thanks!
Too easy. I'll add something over the next few days.
Side thought, have you tried setting the number duration entity to 0?
I cant recall what this does in my integration but I have a feeling that 0 may make it water for the defined max of 1439.
I believe I tried 0 but it didn't do what I needed (or didn't work at all, I can't recall). Working with their support, I landed on just restarting every 24 hours. It would be much easier if they just offered "always on" as an option, but they said that most of their dev effort was focused on new products and they didn't have much time devoted to enhancing the existing ones.
The resetting is a bit of an annoyance, but my use case also includes tracking volume over time so I can see when my softener needs to be regenerated and filters changed. The LinkTap valve stats and integration with Utility Meter in HA allow me to do this.
While I've been happy with the TapLink valve, I do have an eye on the new valve from Ecowitt (I have a bunch of their sensors and weather stations). There's no integration (yet) with HA, but it does have an always on setting.
@phurth - try this out:
https://www.home-assistant.io/integrations/ecowitt
Works well! I have a weather station, pool temp sensor and many moisture sensors for my fruit trees.
I believe I tried 0 but it didn't do what I needed (or didn't work at all, I can't recall). Working with their support, I landed on just restarting every 24 hours. It would be much easier if they just offered "always on" as an option, but they said that most of their dev effort was focused on new products and they didn't have much time devoted to enhancing the existing ones.
The resetting is a bit of an annoyance, but my use case also includes tracking volume over time so I can see when my softener needs to be regenerated and filters changed. The LinkTap valve stats and integration with Utility Meter in HA allow me to do this.
While I've been happy with the TapLink valve, I do have an eye on the new valve from Ecowitt (I have a bunch of their sensors and weather stations). There's no integration (yet) with HA, but it does have an always on setting.
I quickly checked, the integration checks if the duration is 0, and overrides it. I will see if changing how that works is a better solution than adding a separate service call, but the service call is a less risky change.
The whole reason this integration came about is because I didnt like the way their "Home Assistant" mqtt works, and doesnt have functionality to water for x.
I occasionally have comms issues with my linktap gateway due to where its located, so often it would turn on but never receive the command to turn off, leaving it running for ~24 hours.
I do have another potential option you could try, which id their more advanced MQTT mode. This isnt well know, but their MQTT implementation behaves differently if you disable the home assistant mode. It works in HA, just without MQTT discovery. Ive had some very insightful conversations with a dev on their end, who actually agrees that, in hindsight, they didnt need to develop 2 different modes of MQTT operation, but it is what it is.
Here is some working config for an mqtt switch, that has a duration hardcoded in the command. You could change this to a template very easily. I was actually using this for a while before i discovered the HTTP API, and decided to build an integration to make it easy for everyone.
This assumes you have regular MQTT broker set, the uplink topic set to linktap/uplink
and the downlink topic set to linktap/downlink
Note that it will break the existing MQTT setup/entities.
- name: My Tap
state_topic: linktap/uplink/TAP_ID
value_template: "{{ value_json.dev_stat.is_watering }}"
state_on: true
state_off: false
payload_on: '{"cmd":6,"gw_id":"GW_ID","dev_id":"TAP_ID","duration":86399}'
payload_off: '{"cmd":7,"gw_id":"GW_ID","dev_id":"TAP_ID"}'
command_topic: linktap/downlink
Of course, having said all this I will likely get it sorted out today, adding an additional service is quick and easy.
I had a meeting cancelled.
new valve.start_watering service released in v0.4.8 I havent tested it thoroughly, but it "should just work"
@phurth - try this out:
https://www.home-assistant.io/integrations/ecowitt
Works well! I have a weather station, pool temp sensor and many moisture sensors for my fruit trees.
I'm using the Ecowitt integration for my sensors and weather stations and it does work great. The problem is with Ecowitt's new water control valve (the WFC01) which does not yet work with Home Assistant.
Ah right. Thanks @phurth. Good to know as I have been looking at the valve as well.
I had a meeting cancelled.
new valve.start_watering service released in v0.4.8 I havent tested it thoroughly, but it "should just work"
Super fast - thanks! I'll give it a try as soon as I can. I'm up in the Northwoods where things will be winterized for a bit yet.
0.4.8 had a bug so make sure you try out 0.5.0
@phurth I will close this off, but please open it up again if there are any issues,
Hi! Nice work on this integration.
Sorry for the long background below, but I'd like to switch to using your integration so everything is working over HTTP rather than MQTT, but your integration seems to have a maximum configurable duration of 120 minutes. Would it be possible to change this so a longer duration could be selected?
I am using a Linktap valve in a somewhat non-traditional use case. Currently, I trigger a REST call to start/stop the valve and use the MQTT entities to provide sensor data from the valve. The reason I use REST is due to my use case: I use the valve to control well water to my RV, so it's not a normal "watering" scenario. Because of this, I use REST since this allows me to start the valve with a max duration of 86399 seconds (just under 24 hours). I have a Node-Red flow set up to restart nightly so long as I have a helper switch in Home Assistant "on". The net effect is the water stays on until I turn it off. As you may know, the valve will auto shut-off when the watering duration ends and there's no way to disable this.