Open IngmarStein opened 2 years ago
Hi @IngmarStein By using this method: You can include multiple devices in a single request to the API. It will avoid overloading the gateway and reduce latency.
Thanks for the response! Is there a possibility that the gateway could batch incoming actions itself?
Afaik, homebridge-tahoma
receives single actions from HomeKit for every device contained in a scene, i.e. it doesn't know about all the actions contained therein. This means it would have to coalesce requests that are sent in quick succession and translate this into a non-persistent action group for the local API. This adds some latency, negating some of the benefit from using this endpoint.
As confirmed in the linked issue in homebridge-tahoma, it already uses temporary action groups and the exec/apply
endpoint. During actuation, it receives many ECONNREFUSED
errors from the box, maybe related to the concurrent native HomeKit requests?
@IngmarStein
The TaHoma accepts a maximum of 5 simultaneous connection on the local api endpoint. This could explain the ECONNREFUSED
errors you got.
Anyway, regarding your initial issue, overloading the gateway will not make blinds stop halfway. Furthermore, it happens on the HomeKit interface, not local api.
Are you using an Apple device or some kind of unofficial HomeKit controller? If so which one? Do you encounter the issue with a scene with only native HomeKit device?
Are you using an Apple device or some kind of unofficial HomeKit controller? If so which one?
I'm using an Apple device to trigger the scene (but there's also an automation that triggers it on a schedule). The non-native HomeKit devices are controlled by https://github.com/dubocr/homebridge-tahoma/ which uses the local API to communicate with the TaHoma box.
Do you encounter the issue with a scene with only native HomeKit device?
That's an excellent idea to try out. Indeed, the issue is identical for the following scene which only includes the 7 native HomeKit devices.
This is the state before triggering the scene which should close all blinds:
This is the state a minute after triggering it (the scene appears as "failed in Home"): One blind closed successfully, the other is stuck in "closing", but has actually only moved like 10%.
Pardon the German screenshots - I hope you get the idea regardless.
I also observed ECONNREFUSED
when testing locally:
% curl https://192.168.1.55:8443/enduser-mobile-web/1/enduserAPI/apiVersion
curl: (7) Failed to connect to 192.168.1.55 port 8443 after 14 ms: Connection refused
% nmap -A 192.168.1.55
Starting Nmap 7.93 ( https://nmap.org ) at 2022-10-17 21:37 CEST
Nmap scan report for gateway-1211-6131-8026.localdomain (192.168.1.55)
Host is up (0.0033s latency).
All 1000 scanned ports on gateway-1211-6131-8026.localdomain (192.168.1.55) are in ignored states.
Not shown: 1000 closed tcp ports (conn-refused)
One reboot later, the box was reachable again:
% curl -k https://192.168.1.55:8443/enduser-mobile-web/1/enduserAPI/apiVersion
{"protocolVersion":"2022.4.4-10"}
% nmap 192.168.1.55
Starting Nmap 7.93 ( https://nmap.org ) at 2022-10-17 21:44 CEST
Nmap scan report for gateway-1211-6131-8026.localdomain (192.168.1.55)
Host is up (0.0031s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT STATE SERVICE
443/tcp open https
8443/tcp open https-alt
Nmap done: 1 IP address (1 host up) scanned in 0.80 seconds
However, the original error (partial actuation of scenes containing only devices which support HomeKit natively) remains. Any idea what I could look into to diagnose the problem deeper?
@IngmarStein Could you open another issue this issue?
Now that it has been reopened, do you still want me to create a new issue (which I wouldn't mind at all)?
two bugs => two issues. It will be easier to track fixes.
The documentation says "There is no rate limiting on this local API. However, be aware that if you call the API too frequently, the gateway might be overloaded which will result in an unwanted latency during products control." - could it be the overload situation doesn't just mean longer latency but also failed actuation?
I have a goodnight scene with the following devices:
My TaHome box is running firmware 2022.4.4.
When I trigger a HomeKit scene to close the blinds (or the opposite scene to open them), the blinds with native HomeKit support sometimes fail to close completely, i.e. they stop halfway through and seem to indicate failure by "blinking" through the blade angle. The Home app then reports a generic "failure":
An identical automation via tahomalink.com doesn't have that problem.