I bought an Amazon Dash button for experimentation (July 2017, in the UK). The part number I received was JK29LP (with FCC ID 2AETK-1013) which apparently is revision 2 of the hardware. There is a teardown here.
There are at least a couple of Node-RED nodes published but they both have dependencies which I wanted to avoid:
node-red-contrib-mydash requires tcpdump
node-red-contrib-amazondash requires libpcap
There is also a description here of a ping method but I did wonder if I could do it an alternative way without using the ping (which has its own complications due to needing root permissions on certain systems).
I configured the button using the Amazon app as far as the wireless SSID and password, and on a button press I could see the button appearing in my router Attached Devices table (DHCP address reservation). It only takes a short lease so it would appear and then disappear in the router table. This gave me a MAC address (and also an IP address but I would not need that).
At this point, a button press was generating a notification from the Amazon app that I hadn't finished the configuration process, as I had not selected a product. To resolve this, I added the MAC address into the filter list of my router so it would not be able to contact Amazon.
The revision 2 button makes a DHCP/BOOTP request over UDP on every button press , so I thought it would be easy to listen to the correct UDP port in Node-RED using the built-in node. Whilst the information here describes two UDP requests, the second request involving the IP address is not seen with the method below, so there is no need for deduplication.
I added a udp node to listen to udp messages on port 67 using ipv4, and output to a Buffer.
I extracted the MAC address as a hex string from the payload using a function node with a buffer copy:
The MAC address is inserted into the existing message. This then allows the MAC address of the request to be compared to the MAC address of the button in a flow, in order to determine a button press (and not a DHCP request from another device), or to differentiate between different buttons.
This method uses built-in nodes in Node-RED and is straightforward providing the MAC address can be determined for comparison purposes from your router DHCP table.
The behaviour if your system is already running a DHCP/BOOTP server on port 67 is undefined. In that case, I am not sure whether Node-RED will fail to bind to the port as a second process.
There are at least a couple of Node-RED nodes published but they both have dependencies which I wanted to avoid:
node-red-contrib-mydash requires tcpdump
node-red-contrib-amazondash requires libpcap
There is also a description here of a ping method but I did wonder if I could do it an alternative way without using the ping (which has its own complications due to needing root permissions on certain systems).
I configured the button using the Amazon app as far as the wireless SSID and password, and on a button press I could see the button appearing in my router Attached Devices table (DHCP address reservation). It only takes a short lease so it would appear and then disappear in the router table. This gave me a MAC address (and also an IP address but I would not need that).
At this point, a button press was generating a notification from the Amazon app that I hadn't finished the configuration process, as I had not selected a product. To resolve this, I added the MAC address into the filter list of my router so it would not be able to contact Amazon.
The revision 2 button makes a DHCP/BOOTP request over UDP on every button press , so I thought it would be easy to listen to the correct UDP port in Node-RED using the built-in node. Whilst the information here describes two UDP requests, the second request involving the IP address is not seen with the method below, so there is no need for deduplication.
I added a udp node to listen to udp messages on port 67 using ipv4, and output to a Buffer.
I extracted the MAC address as a hex string from the payload using a function node with a buffer copy:
var mac = Buffer.alloc(6);
msg.payload.copy(mac, targetStart=0, sourceStart=28, sourceEnd=34);
msg.mac = mac.toString('hex');
return msg;
The MAC address is inserted into the existing message. This then allows the MAC address of the request to be compared to the MAC address of the button in a flow, in order to determine a button press (and not a DHCP request from another device), or to differentiate between different buttons.
This method uses built-in nodes in Node-RED and is straightforward providing the MAC address can be determined for comparison purposes from your router DHCP table.
The behaviour if your system is already running a DHCP/BOOTP server on port 67 is undefined. In that case, I am not sure whether Node-RED will fail to bind to the port as a second process.
Comments