Issue with HS110

[iFac3]

Hi Anna,

First of all, many thanks for your work on TP-Link Homey app!

My issue is related to the HS110. I noticed, if the WiFi is goes off for a while (till FW upgrade for example), Homey looses the connection to all the HS110 plugs.

In a scenario like this, it’s not enough to restart the app, but Homey has to be restarted.

How can I help you to solve this issue?

Rgds,

Fac3

[iFac3]

Some details:

[abaretta]

Who's Anna? ;-)

It sounds like Homey exhausts the available sockets for connecting to the devices. The library used in the app for connecting to the TP Link devices attempts to close sockets after timing out, possibly this isn't effective. There's an updated library available, however it doesn't support Node.js v8, which is what Homey is currently still using. As soon as Homey goes to v10 (this is being planned) will update the library.

That brings me to the other possibility, there are many Homey users that experience connectivity issues with all kinds of apps. I too see this for the other apps I have in the Homey appstore. An indication this might be the issue is that fact that you need to restart Homey to get the app going again. Each app 'lives' in a sandboxed environment, restarting it should clear all sessions in use by the app. It seems this is not happening, which is not something that can be fixed in the app.

Are you using fixed IP addresses or DHCP reservations for the TP-Link devices? If not, try that if you can.

In case you are using dynamic IP assignments, have you enabled the optional connection setting in the advanced settings? This will make the app do an autodiscovery as soon as it can't reach the device for several polling intervals.

However, note that the autodiscovery mechanism itself can cause similar connectivity issues under certain circumstances, so it's best to use DHCP reservations.

[iFac3]

Sorry Anne,

Thanks for the detailed answer. There’s no fixed IP, but kinda. Have not changed for a very while. UniFi has been setting the same IP for years.

Optional connection setting was on, I tried to disable it for a test, but caused no controll on the plugs at all. Even restarting Homey not helped after a WiFi “drop” test. Finally I had to swich back OCS to get back the controll. (IPs have not changed yet).

[iFac3]

Other notice, ON/OFF LED switch never worked for me.

[abaretta]

I have a Unifi network as well, with two AP's, never have any connectivity problems, very happy with it. That shouldn't be the problem... Is your Homey generally stable? Mine has a memory leak which can cause any app to crash if you leave it, with regular reboots it can be managed.

I am aware of the LED ('Night mode') function not working but I keep forgetting about it... Thanks for the reminder. This broke with the latest library update... I will make an issue for it, and have a look at it at some point.

[iFac3]

My Homey is quite stable. No need on regular reboot. Actually I reboot it when WiFi AP restarts, or when I bug the WiFi settings and a Provisioning happens. It causes TP-Link app crash so I need to restart Homey. Other 11 apps work flawless.

I hope Node.js v10 update will let you solve this issue.

Thanks again!

Üdv,

G. On 2020. Feb 22. 19:34 +0100, abaretta notifications@github.com, wrote:

I have a Unifi network as well, with two AP's, never have any connectivity problems, very happy with it. That shouldn't be the problem... Is your Homey generally stable? Mine has a memory leak which can cause any app to crash if you leave it, with regular reboots it can be managed. I am aware of the LED ('Night mode') function not working but I keep forgetting about it... Thanks for the reminder. This broke with the latest library update... I will make an issue for it, and have a look at it at some point. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[iFac3]

Hi Abaretta,

Node.js v12 has come. :)

[abaretta]

Testing it at the moment 👍

[iFac3]

Cool!

Üdv,

G. On 2020. May 8. 19:11 +0200, abaretta notifications@github.com, wrote:

Testing it at the moment 👍 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[abaretta]

I have published a test version 0.1.8 here: https://homey.app/nl-nl/app/nu.baretta.tplink/TP-Link-Smart-Home/test/. It includes an updated tplink-smarthome-api library which may help with the connection issues some people have with Homey and TP Link devices.

Note that the app requires Homey version >=4.2.0. It works with 4.2.0rc11, the current experimental release, but not on 4.1 or lower releases. Also note that running Homey experimental releases is not recommended if you do any automation with Homey that is important to you.

[iAmRenzo]

It went quite silent after May 11th... my issue about the crashing app results in something like this... the plugs become unavailable but after a Homey reboot they’re back again. Does 0.1.8 also present crashing?

[abaretta]

I responded on the Homey forum, have you read my response? Wait, let me help you with that, this is what I wrote: “ I have seen the issue, without additional information it is completely useless. What do you expect me to do based on the supplied information (‘ The app keeps crashing on homey. At random.’)?

No Homey or app fw/sw details, no info on what you have tried to do about it, fixed or dymamic ip asignments? Did you go through the topic?

Of 1250 users there are a few (a handful, maybe fewer) that have intermittent issues with the app crashing. In most cases it seems to be related to network issues. As explained earlier, try to avoid dynamic ip assignments, instead use static ip reservations in your dhcp server.”

The issue is an interaction between Homey and the library used in the app. It is not fixed in 0.1.8, but the hints mentioned above may help.

[iAmRenzo]

I saw it now, didn’t get a notification. Still don’t know how to provide you with information though.

[abaretta]

Don’t worry about it, I am not going to look at it anyway. You are not the first or only one with the issue, in the topic you can find what others have done to avoid the issue (use static ip’s or dhcp reservations, make sure the ‘dynamic ip’ option is turned off).

[iAmRenzo]

This is now weird, communicating on both fora. But it’s also quite strange to have on one hand some sort of “your reaction is useless without details” and on the other hand “I’m not going to look into it”. Why do I need to provide details then? Maybe it is an idea to mention on your app page that you are not maintaining this app anymore. If I knew this on forward I wouldn’t buy tp-link devices.

I’ve used dhcp binding/reservations so they both have a fixed up address, but it did crash.

[abaretta]

You started a new issue in github, posted a message on the community forum to which I responded, including details on what could possible be helpful information to help you with the issue, namely Homey / app fw/sw details, info on what you have tried to do about it, fixed or dymamic ip assignments, etc. You then responded to yet another github issue, and now you complain to me that it is weird to communicate in different channels? I agree.

The issue you are running into is a known issue which has to do with the communication between Homey and the TP-Link devices. I can't change the Homey code, and depend on a 3rd party library on the TP-Link side. This is why I don't need to see your crashreports, I have them in the mail anyway, and I can't do much about it unfortunately. However, it is relevant to know that you are usin.g static DHCP assignments. This works around the issue for 99% of the users. Next thing to look at is your wireless network, because the trigger in all these crashes is network instability.

I am indeed considering dropping support for the different Homey apps I made, as there is little joy to be had in the interaction with Athom, Homey or the users. I made the app for fun, it can be used freely and I have no obligation to support it whatsoever.

[abaretta]

FYI, this issue is resolved in v1.1.12.