Binding Request: LinkTap

Add-ons Bindings
21

Hi @Rickytr,

So big cavat here - technically 4.3 is the first version this is supported on, as its built specifically against that revision. That being said, my non development main system is also running 4.2.2. I’m pretty sure mdns updated in 4.3, so you will likely have to use a static ip, and set the linktap device to a static ip address (which is what I recommend in the docs), then I suspect it may work. (mdns allows the system to detect if people don’t following the static recommendations for the binding to attempt to auto recover based on mdns data).

If you download the snapshot of the bundles file, if in windows for example you can rename it from .kar to .zip. At this path in the zip file you’re find the jar of the build. repository\org\openhab\addons\bundles\org.openhab.binding.linktap\4.3.0-SNAPSHOT

The jar file inside this directory would need to go in your openhab installations add-on’s directory.

Normally if you use the standard system of installation it will ensure you have the extra dependencies that it requires. Installing it manually you’ll need ensure that you have them. It requires jsoup 1.15.4, so one way to install this is to use the console of openhab to install it with the command:

bundle:install https://repo1.maven.org/maven2/org/jsoup/jsoup/1.15.4/jsoup-1.15.4.jar

The console will then give you a bundle ID.so if it said on my computer Bundle ID: 267 after the above then id next run:

bundle:start 267

After the dependency is met the bundle should start. If you run

bundle:list

On the test installation I just did it appeared to accept the bundle and start it given the with the dependency found, as out of the many lines in the output are these two, which are required for it.

 ID │ State  │ Lvl │ Version               │ Name
────┼────────┼─────┼───────────────────────┼───────────────────────────────────────────────────────────────────────────
267 │ Active │  80 │ 1.15.4                │ jsoup Java HTML Parser
147 │ Active │  80 │ 4.3.0.202410090359    │ openHAB Add-ons :: Bundles :: LinkTap Binding

After this I would suggest restarting openhab, so it has a clean boot with everything installed from startup.

Again however this isn’t recommended, but may be enough for you to “test” it out. As soon as my system pulls a stable openhab 4.3 build, I plan on removing my development build jar and re-installing from the standard add-ons channel.

Hopefully the above works for you.

David

22

I downloaded both jars and putted them in addons folders. And it works like a charm! I can finally remove the configuration I made with mqtt for my Linktap sprinkler.
Thanks a lot.
Great work @dagoodyear .

23

@Rickytr, Glad it worked - I didn’t realize those other dependencies you could just add to the addon’s folder that’s a bit simpler. Assuming you’ve had a play and the functionality works as expected. Could you confirm the GW model, and LinkTap device. If I have to do any updates I’ll add a reference to the devices as also being verified. Many thanks.

24

I have a Linktap G1S with GW-02 gateway.

1 Like
25

Thank you @Rickytr :slight_smile:

26

Hi, I just upgraded Openhab to 4.3.1 and added manually gateway GW-01 (firmware S0609162412261403I_C0300051708152305). Unfortunatelly the gateway is in status ERROR:COMM. But what interesting the Taplinker appear in things inbox.

The gateway has static ip address, the configuration of local http api is:
“Local HTTP API settings
Function: Enable HTTP Client
Server URL: http://openhabIP:8080
Response: Wrap the gateway’s response in HTML”

More over earlier I used http binding for comunnication with Linktap and every thing was working OK.

What should I check/changed to have gateway online ?

27

Hi @Andy_Co,

I’ll have to dig the device out of the shed and connect it tomorrow. I removed it due to winter here in the UK. However, it was tested on 4.3 and 4.2 so am sure it should be good. If you migrated from one of the earlier builds a few bit’s, got cleaned up during the PR review. I suspect its likely a naming change that’s caught you out.

Can you confirm if your using hard coded config, and if it follows the conventions now in the doc’s (from memory I think bridge became gateway for example, as one of the changes): LinkTap - Bindings | openHAB

In theory if it connects if should unset: Wrap the gateway’s response in HTML setting, so I suspect the bridge isn’t connecting if I remember correctly. If the enableJsonComms attribute is true against the bridge.

I’ll plug in tomorrow and check that firmware ID you sent, worst case we may need to open a bug against the binding, but I suspect this is a migration issue from a earlier build.

It may be easiest if you can (if using config files - disable the thing file (I move my up a level on the disk, and then try adding it from the UI - this would then use the current id’s so we can rule out any migration issue there).

I’ll dig it out and connect it up in case tomorrow - if you can check the above first that would be great.

P.S.
Server URL look’s good
WrapResponse should be ticked if enableJsonComms is false, or unticked if enableJsonComm’s is true. (However it should handle both automatically).

28

Okay just dug it out. Yeah my home system had error’s as it was running on a pre-release build. After removing and adding the bridge, setting the username, it came online. Mainly I suspect to the previous bits that I mentioned.

Firmware here is: G0608832408121629I so I suspect this is older at the moment due to being offline - just trying to find a update option for the firmware. May have to email them if it doesn’t update overnight. Would be good to know what you have in your log’s, if it doesn’t play ball after checking the previous bits, as the protocol is pretty standardised.

As it is appearing in your inbox, then the device is responding to mDNS which is good and being identified. I suspect / hope therefore it’s just a naming thing. I presume you also only have a single gateway instance for the TapLink gateway device? (More than one may confuse it, so just ensure you have 1 instance of the bridge, and any others are removed - and the devices point at the new one that was added).

Just in case I’ve requested TapLink update my device, as I believe the firmware’s are the same pretty much for GW01 and GW02, but have also asked them to confirm, just in case there’s been any deviation - I doubt it personally).

29

@dagoodyear

Hi strange thing, today morning the gateway is online I do not see any special in the logs… besides some entries like that:

2025-01-02 22:45:59.377 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'linktap:gateway:517b3a82b6' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Cannot connect to LinkTap Gateway
2025-01-03 03:03:31.506 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'linktap:gateway:517b3a82b6' changed from OFFLINE (COMMUNICATION_ERROR): Cannot connect to LinkTap Gateway to ONLINE

Still, in the night gateway started to be online.

30

Hi @Andy_Co

I reached out to LinkTap - I suspect there will be a newer firmware pushed out shortly, I don’t believe from what they described however the next one will contain any fixes related to connectivity as there isn’t any known issues.

That being said, last night they updated my gateway to what I suspect is the GW02 version of what your running with ID: G0609162412261402I

I also had a weird error like you (typically they are caused by unknown host resolution or timeouts when trying to reach the device, but then we had people round for the day. I’ve just been looking at it now for the last few hours, and like yourself, its now responding as expected. Yet nothing changed. I wonder if after the update the device, watchdogs or reboot’s and then runs as expected as I cant explain it either and now it appears to be running flawlessly. I’ve tried Zula 17 as that what I started with and then Zulu 21 as my JVM’s as I wanted that to attach the debugger. However, it hasn’t mis-behaved once, since coming online, even after doing multiple new fresh install’s of OH4.3 on a dev laptop sitting on a firewalled VLAN that would block mdns (as GW01 doesn’t apparently have the mdns functionality - so this should match what you have).

At the moment, I cant replicate the issue to investigate further, or determine where it sources from. If you get it again, it would be good is if you can set the logger to trace for LinkTap in Settings, it will then give out the steps of initialisation. From those it can likely be pinned down based on what step’s it get fail’s it. I’ll try a bit more just in case I can replicate it, but at the moment it appears to be behaving perfectly.

I take it now your GW is detected as online its running as expected and discovering devices, and items for the relevant device(s).

31

Hi @Andy_Co,

I’ll open a bug against it. I see after some time the devices are offline but I can see the gateway giving the data and its online. Ironically with the dev systems running the later jvm version they havn’t given the same issue - that don’t have the mdns data. So will need to track down what has introduced this. There’s something fishy going on definitely, I will need to trace through the system a bit to locate the root cause. Ironically this was all soak tested, so its something new. Will ping you on the github issue, once its created. I just want to collate a bit more data, to pin down the root cause.

1 Like
32

Hi @Andy_Co,

I’ve added this bug outline here: [linkTap] Connectivity issues in 4.3.1 build · Issue #18076 · openhab/openhab-addons · GitHub

It’s a combination of causes after analysis, the biggest one is in the binding as in cases it doesn’t register the devices correctly, if the binding hasn’t got the data it need’s prior to the sequences running. I suspect this is the main cause of your issues). However could you possibly switch on trace logging for the binding, and check to see if you have any ExecutionException error messages please, just in case there’s any others I have not seen on my test systems here please?

33

ok, I try to catch some logs.

34

Hi @Andy_Co,

If you have any that would be great, it would be good to try and see if your behaviours fit one of the identified cases that I found.

I have a build that I suspect would work for you, but I’ve just requested my firmware is downgraded back to be aligned to yours to check the changes still work with that revision. TapLink did some enhancements to the protocol, which will be pushed out in due course, that I can use in addition to others for your version to ensure the stability of the initial connection. So I just want to verify as much as I can with a GW02 that it behaves as well, as it does with the later firmware.

35

Hi @Andy_Co,

Here is a link built to what has been submitted in the PR. I’ve been testing this with a slightly later firmware than yours but it should improve the connection regardless. LinkTap are currently rolling out a newer firmware globally, ideally when your Gateway receives the update the firmware version it will likely start S060920, or with a higher number. It would be ideal if you have this build or higher, as it’s optimised for a few new bits in that revision. I suspect what you will see after updating is it may take a bit longer for a GW01 to be considered on on-line (I don’t know the speed differences between the GW02 and GW01, for GW02 its usually almost unnoticeable, but a GW01 may take bit longer - it can take potentially up to 90 seconds I’ve been advised). Subsequent re-connections if your using static IP’s shouldn’t take long at all as the gateway wont need to reboot to apply the settings for the binding, which the binding then has to wait for it to fully startup.

4.3.2 snapshot built locally on the PR’s codebase

I had a bit of fun on my 4.3.1_1 core server updating it so I had to clear out the OpenHab’s tmp and cache directories to ensure it was picked up.

When its install I see this in the UI:

image
image900×792 37.1 KB

When I click on the one that installed from this build it should show:

image
image953×753 19.2 KB

Please let me know how you get on with it - I believe unless your hitting something else I haven’t found in different test’s this should stabilise the link detection, and a few internal behaviours relates to the connection handling.

36

@dagoodyear

Hi, at that moment I set logging to trace to separate file and I’m waiting for logs when the problems with connection appear.

37

Thank you :slight_smile: It would be good to see, to confirm there’s nothing else :+1: that I cant replicate here!

38

Hi, I just send you logs on PM.

39

Hi @Andy_Co,

Thank you, I can see a few thing’s after working through for the last few hours, cross analysing different bits from different angles.

A) The GW was definitely online and pushing data updates for the duration, and that it was responding to protocol requests, at least for the API endpoint.

B) It must have been using a static IP as I at first wondered if you had dynamic but, I can see on closer inspection, it has the same IP for the duration of that logging.

C) The place it failed is when its trying to connect to the web server to ensure the configuration is correct. What I cant determine without seeing it with more log’s is if its Java’s resolution glitching or something related to the config handling. As it would have loaded the hostname from your config, and its completed the previous checks using it which is now throwing me.

So a few more questions sorry:

When you migrated to the one from the main build did you shutdown. Delete the old builds jars before adding the one from the main addon’s page, and clear the tmp and cache directories? Just in case its got two versions of the jar somehow loaded?

Secondly, has this only happened this once and was it when you were migrating to the new official version? Or is this reoccurring? Finally if its re-occurring, could you advise of:

O/S
JVM version
OpenHab build please
How is it configured via discovered items, or all via configuration files
Please confirm whether the LinkTap Gateway has a static address, and its the IP that you used for the hostname of the gateway.

I’ll install the same setup to try and replicate to see if I can see the same thing happen, at that point, in the code.

P.S. I can tell the above as its successfully done APP->GW Requests for CMD 16, but its only much later on in your logs its completed the API’s bits given by these logs:

2025-01-11 22:02:31.198 [TRACE] [inktap.internal.LinkTapBridgeHandler] - Local address for connectivity is 192.168…REMOVED
2025-01-11 22:02:34.113 [TRACE] [g.linktap.protocol.http.WebServerApi] - Enabling mdns server on gateway
2025-01-11 22:02:34.114 [TRACE] [g.linktap.protocol.http.WebServerApi] - Setting Local HTTP Api on gateway
2025-01-11 22:02:34.115 [TRACE] [g.linktap.protocol.http.WebServerApi] - Found existing HTTP URL Server : http://REMOVED:8080/linktap

So because the Local address line has happened many times it’s definitely able to make a basic connection, but its when it try’s to connect then to adjust the settings its having the issue.

P.S For GW01 as it doesn’t have mDNS support I believe you can set Enable mDNS Responder to false in the bridges advanced settings.

40

Hi,

I did not use earlier versions of binding. I install official version from 4.3 version.
The problem was from the moment of first install - the gateway was offline beside the Tap link device was discovered and yes it is periodically online and offline - I will check logs in this week if the issus will occur again.

OS - ubuntu 22.04.5 LTS

Java- OpenJDK Runtime Environment (build 17.0.13+11-Ubuntu-2ubuntu122.04)
OpenJDK 64-Bit Server VM (build 17.0.13+11-Ubuntu-2ubuntu122.04, mixed mode, sharing)

Opehab 4.3.1

Configuration was done by GUI, IP address of gateway is static.