@MathiasT I tried again today with the app version 1.2.24, with debug enabled. Removed all my devices, and added the main IP address again. Four devices detected and added, with the same result:
The device shown to the left, X20 ??, is a secondary (slave) device which currently is disconnected. The X60 to the right is the real main device that has IP address 192.168.xx.1.
I created an diagnosis report in the app if that helps: 580a06f6-2c9d-4290-8a4f-6a10b2f145ad.
Am I supposed to see the debug log somewhere in the app?
I tested a bit in the weekend and even if my phone is connected to the same deco im sitting beside it,then also now and then it says that my device is offline.
I have installed the app(1.2.24), and my deco’s are found but all the info remains empty. I have P7 decos. What strikes me is that they have the same ip address for all 3 and that this ip address is also incorrect
In the app version 1.1.9. He did find my head deco and then there was all kinds of info, that version worked for me. And my IP address was also correct. Unfortunately, I didn’t install it anymore. Unfortunately I don’t have any print screens of that anymore
Try my little test application above in the thread and DM me. Have not tested P7. You could try tplinkdeco.net where you enter IP as it should find your main deco and sub-decos (you have to delete the current ones as it matches on the MAC address of the deco
I actually tried that with tplinkdeco.net, but unfortunately it has the same effect. I really think it has something to do with the IP address. I’ll take a look at that test program.
Its a bit of porting to JavaScript or TypeScript. I suggest a separate app. Do you know how I could “talk” to a controller - then maybe I could start developing the API client and then a Homey app.
That is interesting profiling. With the latest test release you can now adjust the frequency of the requests that might lower this values. I will look in to how I could release resources and improve this behaviour. Big thanks I haven’t had the time to do this profiling.
Also interesting to see below effect when forced restarting - seems after restart (11:06 as 100%) base-load back to 0% and also can see that +10% peaks less freq. than before restart:
Does not look to me that polling freq. would be an issue (as only max. 10% jump from base line), but something related to longer App running time…