@sh00t2kill Firstly thank you for creating this integration, it should be much easier to control the LinkTap D1’s I have just brought/installed!
I am trying to work out how to create an automation to water one of my zones for 5 minutes. I can then link this to a CarPlay and Watch shortcut.
There appears to be a service to start_watering, but it seems to be labelled as a Pause. See attached screenshot.
Is this the best way to automate the watering or is a different service/method better?
I just looked at the services.yaml in the custom component and they are all named pause, assume by accident. I use the start watering service like this:
service: linktap.start_watering
target:
entity_id: valve.linktap_back_garden
data:
minutes: 20
EDIT: just edited my services.yaml and changed pause to start and restarted and now its labelled correctly
I will fix, that’s definitely a mistake.
So yes, the start watering service does that.
You could also set the relevant duration number entity to 5, and then turn on the switch or open the valve.
Its functionally equivalent.
I fixed the services.yaml as well.
When I called the start_watering service it actually watered for 20 seconds, not 20 minutes.
Been playing a bit more.
Not sure if it is just me but I am getting the sensors going Unavailable fairly regularly, but only for a minute or less. A look in the logs there are quite a few timeouts.
Is there something I can do to adjust this timeout?
The LinkTap MQTT Integration doesn’t seem to have these timeouts, or at least it doesn’t cause the sensors to go Unavailable.
Logger: custom_components.linktap
Source: helpers/update_coordinator.py:319
Integration: Local HTTP API for Linktap (documentation, issues)
First occurred: 12:01:16 PM (163 occurrences)
Last logged: 5:42:36 PM
Timeout fetching linktap data
EDIT: I seem to be getting these every 5 minutes, I am also getting the following errors
This error originated from a custom integration.
Logger: custom_components.linktap
Source: helpers/update_coordinator.py:326
Integration: Local HTTP API for Linktap (documentation, issues)
First occurred: 6:22:50 PM (1 occurrences)
Last logged: 6:22:50 PM
Error requesting linktap data: [Errno 104] Connection reset by peer
Fixed in 0.5.2. I changed it to seconds but didnt change it everywhere.
I get these occasionally, but certainly not on any sort ot schedule. I havent seen in for some time.
Do you also have mqtt set up at the same time?
Linktap support didnt confirm this, but I believe running both could lead to issues where it doesnt respond in a timely manner, especially if you have a few taps/valves
I did have the MQTT enabled as it was the only way to integrate it to Home Assistant whilst LinkTap updated my firmware.
I have now disabled the MQTT devices in Home Assistant, but this doesn’t seem to make any difference to the devices going unavailable.
My setup is two LinkTap D1’s, so four watering devices. I have tried disabling all but one of those and still get the timeouts.
Not sure if it is significant but the firmware version they upgraded me to is G0808642402291348I, which may be newer than the one mentioned in the integration read.me.
How odd.
Can you run some continuous pings or something, see if its dropping network packets?
I kept a close eye on mine today and it didnt go unavailable at all. Hasnt since my last reboot a few days ago.
1 have 7 taps (a g1, a d2, and a 4 channel valvelinker).
The integration does have some retry logic, but maybe the timeout needs to be set lower.
FWIW: The default timeout is 5 minutes, so making that higher doesnt sound like a good idea 
Thanks, I will see if the gateway will accept pings or not later.
Out of interest, is your Firmware Version the same as mine or older?
They updated it on Monday so I am guessing it might be fairly new version?
So it seems the gateway is losing pings at roughly the same time as the device is going unavailable when I ping it from my computer or my home assistant instance (HA Yellow).
Before I go back to LinkTap and indicate they have an issue (Firmware or Hardware) is it possible you could let me know what Firmware version you are using is for comparison?
My gateway is using the below version:
I have auto update turned on, so to be honest have no idea when it last updated, but i believe the final part of the string in front of the _ is the date, so that would make it Jan 2024.
Keep me posted if/when you hear back from Linktap support. They have generally been pretty responsive.
Thank you, from looking your firmware version you have different hardware (G v S) and firmware (08086 v 06085)
Think I will try moving the gateway on my network and see if it makes a difference and see if I the LEDs on the gateway do anything when it goes unavailable.
It is interesting that the LinkTap App and their MQTT integration don’t report any issues.
G or S is different revisions of the gateway. I got my first taplinker back in … 2018 maybe ? Could even be older than that.
I am trying to get the time from the gateway using local HTTP access. I think I am close because I am getting a response, just not the one that I want. I am sending as a post:
data: {"cmd":"14","gw_id":"86E8552E004B2122"}
header: {
"Content-Type":"application/json",
"Content-Length":str(content_length_of_data),
"Host": "192.168.1.250",
"Connection":"close"
}
I get back:
<html>
<head>
<title>api</title>
<meta name="robots" content="noindex">
</head>
<body>
<!--#RET-->{"cmd":255,"gw_id":"86E8552E004B2122","ret":1}
</body>
</html>
Header: {'Server': 'LinkTap Gateway', 'Content-Type': 'text/html', 'Expires': 'Fri, 10 Apr 2008 14:00:00 GMT', 'Pragma': 'no-cache'}
As you can see, I am close - however, the expected response should have JSON in it with the time.
Has anyone else who has experimented with this offer me some guidance?
Thanks.
The response is not raw json, its json embedded in HTML.
Its particularly annoying. I had to strip that out as part of each response.
Yeah - I’m ok to do that, but the embedded json is wrong. Instead of echoing the command back, it gives 255. I think that is an error commend, but I don’t know because I couldn’t find a reference to it.
I was expecting to get:
{“cmd”:14
“gw_id”:“CCCCDDDDEEEEFFFF”,
“ret” :0,
“date”:“20210501”,
“time”:“123055”,
“wday”:6}
why are you sending cmd 14?
14 is about setting a schedule (i think)
so you need day, time etc, as well as a device (ie a tap)
If its getting the schedule, you need to provide a tap (dev_id)
I left those out of the integration specifically, as it doesnt make sense – use the app for schedules.
the ret value is an error code. If thats not 0, something was wrong with your payload.
You actually need to sign an NDA with linktao in order to get the api documentation. Id suggest you do that if you want further information.
Thanks @sh00t2kill - I emailed tech support for some documentation and they sent me “LinkTap Gateway MQTT Client Interaction Messages.pdf”. In that document they say that command 14 is: “Fetch Gateway Time” and that it is an App–>Broker–>Gateway type message.
I chose this command because it looked like the easiest. But having said that - it isn’t working so I’ve stuffed something up somewhere. I’ll try a different command.
3 is status. You also need a dev_id.
Start there.
Lets take this off the thread as its not really relevant to the integration.
DM me if you like.