My issue seems quite particular. I used the dash button with the Amazon Dash Button Binding without problem for a while, but after changing the wifi extender, the button works only in the area directly covered by the router AP, while it does not work in the rest of the house (Openhab runs on a raspberry connected via ethernet). Nothing else was changed except the extender (same SSID, same psw, etc.). In the log (openhab and events log) there are no notification at all when I press the button.
Any idea how to solve this issue?
I just guess what may be happening based on what I know about how the Dash Button detection works.
When the Dash Button is pressed it joins your wifi network. As part of that it sends out an Address Resolution Protocol (ARP) request. The binding captures that ARP packet and determines that the button was pressed. The ARP request is basically asking “Who has IP address X”.
The problem is that ARP packets do not get transmitted across networks. It only gets transmitted to its closest switch/router. So when your Dash Button is in the part of your home covered by the repeater, the ARP packet is not getting past the repeater so the rest of your network doesn’t see it.
What is happening is the repeater sees the ARP packet, looks in its routing tables to see if it knows what MAC address is at IP X. If it does it responds. If it doesn’t it sends out its own ARP request to ask the WiFi AP if it knows who has the given IP address. But at that point the ARP will show it coming from the repeater, not the Dash button.
I do not think there is anyway you can solve this problem short of eliminating the repeater.
Thanks Rich, I suspected something like this.
What I do not understand is why previously with the other extender the Button worked perfectly. Furthermore I launched the ARP command on the raspberry but the IP address of the Dash Button is not present in the table (I wanted to delete the entry) and I do not understand why.
The other extender probably operated in a more transparent manner. If I’m right (above is only a theory, there is no way I can test it) the extender you are using is ARP aware and is acting like a switch instead of a hub. When it acts like a switch, it maintains its own ARP table and does like I described above. If it acts like a hub, it simply rebroadcasts all the packets it receives and lets something upstream handle the ARP table.
I would expect more expensive and nicer extenders to work like a switch.
By default entries in the arp table will time out and be removed after 60 seconds.
Rich, I guess your theory is correct, it would be great to find a solution (changed the topic title for a more precise description). Thanks
If I’m right, the solution is:
- get a repeater that acts like a hub. the fact that you said this used to work with a different hub implies that might be possible, though I’ve no idea how to tell without getting one and trying it out.
- eliminate the repeater and use a more powerful AP or move the AP to reach the areas covered by the repeater
- put a program running on the part of the network covered by the repeater to capture the arp packet and inform OH of the Dash button press using the REST API or MQTT
The problem is in the repeater so you either need to eliminate it or set up something that is on the other side of the repeater so it can get the arp packets.
The second option is not feasible for me (I changed the extender due to coverage issues).
I am going to get in touch with the provider of my FRITZ!WLAN for assistance for the first option.
I fear that the third option goes far beyond my technical competence, however I will try to implement something.
I’ll publish the solution if I can get it. Thanks for these suggestions.