Button press with ~6 sec delay

[simonnelli]

Describe the bug
Configuring a dingz button in Home.app works as expected but with a big delay (~6 sec).
Looking at the log I suspect a IPv6 vs. IPv4 problem. Could it be that it first tries to use IPv6, time out (fail) and then try IPv4?

This seems to be unrelated to the callback URL, as button presses are also triggered correctly (with 6sec lag) to Home.app even without working callback URL.

To Reproduce
Steps to reproduce the behavior:
Configure Docker host as IPv6/IPv4-Dual-Stack, check how long it takes for button presses to register in Home.app

Expected behavior
Very low latency for button actions

Plugin environment (please complete the following information):

• dingz/myStrom Device Firmware Version 1.49.0
• Homebridge Server: Homebridge Docker on Synology
• Plugin Version v1.5.1
• Node.js Version v12.17.0
• Homebridge Version: 1.1.0
• Special settings: without auto-discovery

Screenshots

Additional context
My IPv6 understanding isn't very deep, could be a wrong config as well on my network

[johannrichard]

Thanks for the bug report. This one might be tricky to debug, but let's see what we can do to find out what happens. I've had lags even when an IP (v4) was set so it might also be the dingz that needs just a bit more time or is busy replying to poll requests (:octocat: 😄 🙈 ).

First, can you provide the output from /api/v1/action in the ticket (feel free to obfuscate the IP's in a way that it's cleat if the plugin set a hostname, an IPv4 and/or an IPv6), and/or what you configured for the hostname (if you have set something) and whether this resolves to an IPv6 address or an IPv4 or both when you do a nslookup or dig from a Terminal? (again, w/ IPs obfuscated).

When it starts, the plugin also informs you about the callback URL it is setting. It should be the same as the one you will see in the action endpoint but please post this as well.

[6/2/2020, 1:43:30 PM] [Dingz SmartHome Device] Callback server listening for POST requests on 18081... use post://10.x.y.42:18081/button as URL for your dingz or MyStrom callbacks

[johannrichard]

In order to test your setup, you could also try the following in your terminal (Mac/Linux):

time curl -X POST -d "index=4&action=3&Mac=<MACOFYOURDINGZ>" http://192.168.227.10:18081/button

This should trigger button number 4 with a long press and the output from the command will give you an idea how long that request took. On my setup (Vanilla Docker on Linux, Dual-Stack Docker, but only IPv4 network otherwise) I get a response time of below 1s (typically a few ms) and I see the action appear immediately (<1 s) in the log and in the Home.app.

Let me know what you get in your setup: If there are any significant delays when using curl then something's amiss with the plugin - if not, it's probably related to the dingz, the way it resolves hostnames and/or timeouts with wrongly set callback urls (hence the need to see what's configured at /api/v1/action).

[simonnelli]

Thank you for the pointers. I have identified some problems on my setup which need to be resolved first before I debug this further (maybe even related or source of the problem):

• The lag seems to happen with other networked actions on dingz as well (hue and mystrom). Wasn't there before thats why I suspect another change I've made on the network. Will try to revert and see if it improves.
• The Homebridge hostname seems to be set to the same value as the name of the docker container This is either a 'bug' on Synologys docker client or the oznu/homebridge: Synology: Host name conflict homebridge/docker-homebridge#35)

As soon as I have solved these issues I'll retest and report if the issue persists

[simonnelli]

In order to test your setup, you could also try the following in your terminal (Mac/Linux):

time curl -X POST -d "index=4&action=3&Mac=<MACOFYOURDINGZ>" http://192.168.227.10:18081/button

This should trigger button number 4 with a long press and the output from the command will give you an idea how long that request took. On my setup (Vanilla Docker on Linux, Dual-Stack Docker, but only IPv4 network otherwise) I get a response time of below 1s (typically a few ms) and I see the action appear immediately (<1 s) in the log and in the Home.app.

Let me know what you get in your setup: If there are any significant delays when using curl then something's amiss with the plugin - if not, it's probably related to the dingz, the way it resolves hostnames and/or timeouts with wrongly set callback urls (hence the need to see what's configured at /api/v1/action).

Thank you, this will further help to pin down the issue

[johannrichard]

• The Homebridge hostname seems to be set to the same as the name of the docker container This is either a 'bug' on Synologys docker client or the oznu/homebridge: oznu/docker-homebridge#35)

Depending on how Docker is set-up, this scenario might be one reason to manually set the hostname in the plugin config (of your Synology in that case) or alternatively, to set the Synology's IPv4 address directly in the plugin config. There's no really easy way for the plugin to figure out the correct external IP in a local network so it's better to manually set this if you run into trouble.

Happy debugging, wish you good luck!

[simonnelli]

Success! After deactivating mDNS-reflector on the router and resetting dingz to factory (to clear everything from http://[dingz-IP]/api/v1/action), the HomeKit-Buttons work correctly and without delay.

Do you know of a way to 'clear' manually http://[dingz-IP]/api/v1/action if something is messed up? Resetting the whole device is quite time consuming (Controlling the native dimmers, Hue, myStrom, Sonos and HomeKit on one device 🤪)

Furhermore I've noticed your plugin sets following under PIR even when the dingz has no PIR installed. Doesn't impact any functionality but I wanted to report it.

"pir":	{
		"generic":	"",
		"single":	"post://192.168.227.10:18081/button",
		"double":	"",
		"long":	"",
		"press_release":	true
	},

[johannrichard]

😄 great to hear you got it working and good catch w/ the PIR. I have to see how I handle this -- the code is quite "simple" right now and sets the necessary endpoints.

You can reset the actions quite easily in fact, see the wiki for details. In essence, you POST empty callback URLs to the dingz, for the respective endpoints:

$ curl -X POST http://your-dingz/api/v1/action
$ curl -X POST http://your-dingz/api/v1/action/pir/single