Smart Garden Tap Water - On and Off

@sh00t2kill - thanks for your input/help. I have daily water volume and hours water running working nicely using a combination of the History Statistics and Utility Meter integrations.

The solution is to create a history_stat template sensor to record time watering. I am using the mqtt binary sensor for this as it is the most accurate. Any reason why you have not included this sensor in the api integration? Code below if anyone is interested.

 # Front Tap switch - to work out time on per day
- platform: history_stats
  name: Tap Front Daily Usage
  entity_id: binary_sensor.tap_front_xxxxxxx_is_watering
  unique_id: stats_daily_tap_front
  state: "on"
  type: time
  start: "{{ today_at() }}"
  end: "{{ now() }}"

You then use the history stats entity in a utility meter helper/entity to collect daily LTS for watering time per day.

For volume, It is even easier as you can use the Volume entity from the API directly in the Utility Meter.

To test, I created a chart that looks at all the possible ways of calculating daily time/volume and it shows me it is working and shows a bug/issue in the history stats integration that is resolved using a utility meter entity to track LTS for time water on per day.

@sh00t2kill - see below for why I am using the mqtt is_watering sensor for calculating the time the watering is on. The three scenarios are:

  1. use the manual watering (physical button) to turn on and off the system (left hand side)
  2. use the API/HTTP switch to turn on and off the system (middle)
  3. use the mqtt switch to turn on and off the system (right hand side)

In all cases, the only consistently accurate sensor is the mqtt is_watering sensor. It would be great if you could add the is_watering and is_manual_mode binary sensors to the API / integration.

Thanks again for all your work here. It’s awesome! :slight_smile:

image

Im not 100% sure what you are asking for here RE is_watering

is_watering is used to determine the state of the switch entity, so they would always be in sync so not really adding any value there.

I have added a binary sensor for is_manual_mode

thanks for adding manual mode. Much appreciated.

is_watering is only on when the actual value is open. With the switch (both in mqtt and api), it is triggered when you set it and there is often a delay before the actual value is opened and closed.

In the chart above (scenario 3), you can see this in action. I turn on watering using the api switch in HA UI. At this point the mqtt switch is triggered (yellow) then some time after is_watering mqtt is set (grey) and the value opens. Then a few seconds later the api switch is set to on (green).

So in summary is_watering is not syncronised with the state of either the mqtt or api switch.

Interesting.
That’s actually slightly different to my experience.

I call switch.turn_on, but it doesn’t actually change state until watering starts.

What on earth is going on there!

Edit: could actually be a mushroom card thing.

Actually that is sort of correct. If I flip the switch in HA (normal entity card - not mushroom), it switches on and then off again, then you get the pattern I have described above.

In any case, you can see that the api switch on status is finally set to on a few seconds after is_watering is set.

The good news in all of this is that it works great so i’m not complaining at all!

The other great thing is that the sensor is_watering (via mqtt) is accurately synchronised with the value being open on the hardware device and that is great too.

Thanks for the updated integration. I am now running v0.1.4 and I see the two new sensors

If I compare mqtt and the api for is_watering, I see that they behave differently. What I have observed in my testing is this:

  1. mqtt is_watering sensor is updated when the value is triggered (I can hear the water start/stop)
  2. api is_watering is aligned to the state of the api switch but not physical value being open
  3. duration of is_watering can differ between the api and mqtt

So it looks like the api is periodically updated but mqtt is a combination of periodic and real-time.

I think I am chasing unicorns here! But it is good fun.

In the chart, left side is api and right is mqtt triggered

image

I added an additional binary sensor for is_watering anyway.

You shouldn’t need both mqtt and local http, seems silly.

Thanks. Agreed I don’t need both and I will remove one or the other once I have finished testing.

I just like that the mqtt is_watering seems to be a real-time on/off sensor for the value on the physical device/tap. So this works best for holding the time and duration the tap is on per day.

Thanks again for your help with this.

The delay between issuing a command and the watering starting is particularly annoying. Especially when it doesn’t do it to stop watering.

To reduce the latency, you can navigate to “Gateway Details” on the LinkTap App or Web App, and change the “Device Sleep Mode” from “Power Save Mode” to “Performance Mode” so that the delay will be reduced to 5 seconds. Please note that “Performance Mode” will shorten the battery life.

The new binary sensor should match mqtt, with a small tolerance for polling. The component polls the gateway every 10 seconds.

Thanks again @sh00t2kill - It’s really good work and I think these linktap products are great.

I get delays for both start and stop using the switch in HA on both the mqtt and api integration. the length of delay depends on time difference between the command to start/stop and next polling I guess.

I can confirm that mqtt is_watering is the only accurate sensor. I can hear the water start and stop so I know it is tracking the actual physical valve accurately. It is strange that the api is_watering is not working the same way. It would be great if you could raise this with the devs.

Good luck and thanks again for the great work here.

It’s all about polling duration.
The component polls the local api every 10 seconds, so there could be an up to 10 seconds delay between Tap opening and state being updated in HA.

Mqtt is a message bus so doesn’t have an issue with polling. Ha is constantly listening to the broker for messages, so it’s always going to be near real time.

@sh00t2kill - I have a second gateway and I need to move one tap to the new gateway. I’m trying to delete the tap from the integration but can’t find a way. Is there a delete device button that I am missing?

You would have to delete the integration and re-add it. As the devices are added automatically based on the gateway config, i dont think its possible to delete per device.

All good. I managed to fix everything quite easily. Here are the steps:

  1. Delete/remove the device from the gateway in the linktap app and reboot the gateway
  2. Delete/remove API integration from HA
  3. Restart HA and check all entities have been removed
  4. Add the integration and it should recreate all the entities with the same name but without the removed device entities

yep!

if its “just” a case of adding a new device, restarting HA would solve the problem, but im not sure what would happen if you removed a tap from a gateway tbh.
Its entirely possible it would have deleted it, but better to be safe than sorry!

Hi!

in the past, I had used a solution with a smart plug connected to a 240V magnetic valve. But now I switched to those devices which are Zigbee controlled and can thus be easily integrated with HASS via Zigbee2HA:

https://amzn.eu/d/33ZWjkC

The reviews are not so good but for me it works well.

Unfortunately the API integration gets confused with two gateways. I can add both and the taps/switches are visible/correct. They both work fine initially but after a restart of HA both the devices and most the entities are on the one integration and everything is broken.

Can you help?

Deleted both the integrations. Restarted HA. Added back the integrations one at a time with a restart in between.

All looking good, then restart and same issue. I had debug logging on so here is the error log where things start to go wrong. Not sure if this is much help.

2023-10-03 19:50:27.440 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_rf_linked_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_linked
2023-10-03 19:50:27.441 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_fall_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_fall
2023-10-03 19:50:27.443 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_cutoff_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_cutoff
2023-10-03 19:50:27.445 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_leak_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_leaking
2023-10-03 19:50:27.447 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_clog_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_clogged
2023-10-03 19:50:27.448 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_broken_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_broken
2023-10-03 19:50:27.449 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_manual_mode_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_manual_mode
2023-10-03 19:50:27.451 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform linktap does not generate unique IDs. ID linktap_binary_sensor_is_watering_185bae2d004b1200 already exists - ignoring binary_sensor.linktap_tap_front_is_watering
2023-10-03 19:50:27.453 INFO (MainThread) [custom_components.hacs] Stage changed: setup
2023-10-03 19:50:27.454 INFO (MainThread) [custom_components.hacs] Stage changed: waiting
2023-10-03 19:50:27.454 INFO (MainThread) [custom_components.hacs] Setup complete, waiting for Home Assistant before startup tasks starts
2023-10-03 19:50:27.455 INFO (MainThread) [homeassistant.components.weather] Setting up weather.bureau_of_meteorology
2023-10-03 19:50:27.458 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_signal_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_signal
2023-10-03 19:50:27.461 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_battery_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_battery
2023-10-03 19:50:27.462 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_total_duration_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_total_duration
2023-10-03 19:50:27.464 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_remain_duration_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_remain_duration
2023-10-03 19:50:27.465 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_speed_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_speed
2023-10-03 19:50:27.466 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_volume_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_volume
2023-10-03 19:50:27.467 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_volume_limit_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_volume_limit
2023-10-03 19:50:27.468 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_failsafe_duration_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_failsafe_duration
2023-10-03 19:50:27.469 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_plan_mode_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_plan_mode
2023-10-03 19:50:27.470 ERROR (MainThread) [homeassistant.components.sensor] Platform linktap does not generate unique IDs. ID linktap_sensor_plan_sn_185bae2d004b1200 already exists - ignoring sensor.linktap_tap_front_plan_sn
2023-10-03 19:50:27.472 INFO (MainThread) [homeassistant.components.light] Setting up light.twinkly
2023-10-03 19:50:27.475 ERROR (MainThread) [homeassistant.components.switch] Platform linktap does not generate unique IDs. ID linktap_switch_185bae2d004b1200 already exists - ignoring switch.linktap_tap_front

Can you enable debug logging, and share the logs upon HA restart?