One more thought is EnOcean devices which don’t need batteries and have decent range. Must be much faster to report in than any button that has to join the wi-fi network first. Of course, yet more expense…
Another option could be setting up an IFTTT DO button that triggers the garage door opener (which you have?), then add DO to the iOS notification panel. I find it takes about 5-10 seconds from unlocking my phone, pulling down the notification shade, waiting for the buttons to load (common IFTTT), and waiting for the signal to reach my server. No app launching/screen navigation necessary.
@hagenbuch The IFTTT Do button is my current solution for my wife. Unfortunately your experience is not ours. It can be sometimes 30 seconds to a minute before the garage triggers after pressing the Do button. Of course in that time she has pressed the button half a dozen times in frustration causing the door to receive lots of signals in sequence. Though in the best case I’ve seen it is at least 10 seconds from button press to door opening.
I didn’t know that you can put Do buttons in the notification panel though. That might ease the pain somewhat.
@watou and @dan12345 , those are both options worth pursuing in the future and I plan on looking into them soon.
I actually have a spare IR transmitter/relay (which openHAB and zwave rendered redundant). Worth nothing to me - if you live in the UK/Europe I’d be happy to post to you.
Dan
Thanks! Unfortunately I’m in Colorado, USA.
For the time being I’m no worse off than I was plus I learned a lot about how Amazon Dash buttons work plus some new Python coding techniques so I’m calling this project a success. 
You may have figured out a good solution already, but I wanted to share mine for anyone looking for a quick way to send OpenHAB commands from iOS.
Instead of using the DO button (with iOS notification panel integration), I found a very flexible iOS app called Workflow that allows you to make custom “workflows” (like graphical scripts) that can be tied to buttons on the notification panel.
Workflows are designed by dragging and dropping pre-defined blocks into a sequence, where the output of one block feeds the input of the next block.
I built a workflow that calls the my.openhab.org REST API directly, which circumvents the IFTTT routing. All-in-all, this is much faster than the DO button because the Workflow buttons are immediately available in the panel (whereas I find the DO buttons take 2-3 seconds to load), and the web call is more direct.
The Workflow app costs like $5, but IMO it’s worthwhile. I did run across a couple gotcha’s though.
First, I had to make 2 separate web calls to my.openhab in order to authenticate, then send the command. Someone more savvy with HTTP may be able to find a way to do this in one call. Second, you need to encode your username/password in the URL, which means converting illegal characters such as “.” and “@” to “%2E” and “%40” respectively.
My Workflow looks like this, where the items in brackets need to be replaced with your information and be URL encoded:
Text block - https://[username]:[password]@my.openhab.org
Get Contents of URL block
Text block - https://[username]:[password]@my.openhab.org/CMD?[item_name]=[value]
Get Contents of URL block
What you end up with is a list of Workflow’s in the iOS notification panel, each of which can represent a command or sequence of commands to your my.openhab account. These can also be added as home screen icons.
1 Like
I looked at Workflow but didn’t want to spend the $5 on it if it, like everything else in iOS, wouldn’t allow me to embed the username and password in the URL. I may look into that but a higher priority for me right now is the fact that I will have a house sitter soon who doesn’t have a smart phone so I need to come up with something Dash like to get this working.Or just break down and get a new garage door opener. 
For your use case a real garage door opener is probably the way to go… but I admire your dedication to home automation 
Rich,
What is the best way to contact you directly? I had exactly the same situation as you, and wanted to use a Dash button as a garage door opener that was controlled from openHAB. I just set up your script this evening, and after some Python issues started to get some errors. However, I’ve worked through them and found that the GitHub code wasn’t quite complete … I’ve added some error handling and some functionality, and I want to get them to you somehow. I’m not very familiar with GitHub though, so I’d like to contact you directly to make sure I am doing things the right way for you to see them.
Thanks!
You can git clone https://github.com/rkoshak/sensorReporter.git, make your changes, then back on the github site create a pull request (green button in the upper left).
In stead of or in addition to that you can post your updated code here which might make it easier for future readers of this thread to know of and include your changes.
If you want to contact me privately you can PM me through this forum. Click on my icon on this post and choose “Message”.
I’m not surprised the GitHub code has some errors. I had it working once then tried some stuff to see if I could get it working better, failed, and never fixed it. I’ve since moved on to the Aeon Minimotes which seem to be working reasonably well. I’d love to hear about your experiences with the Dash. I still have my two sitting around. I still think the range may be too short to work for me as a garage door opener but I might be able to use them as lamp switches, if they are responsive enough.
FWIW, I have a Dash button mounted to the back of my bed’s headboard. Before going to sleep, I hit the button and it triggers rules which put the house into a sort of “sleep” mode. Things like turning off the lights, making sure the garage is closed (and closing it if not), lowering the thermostat temperature. It’s been very convenient and high SAF.
Also, I integrated my Dash button a bit differently than you did. Instead of using Python I run a bash script (configured to execute when my server boots). It’s very simple, no error handling or anything fancy:
#!/bin/bash
while read -r line;
do
curl http://localhost:8080/CMD?vSleep=ON;
done < <(tcpdump -i eth0 arp and ether host a0:02:dc:42:4f:c0 -l)
Where the MAC address is that of my Dash button.
2 Likes
I like that use case. It wouldn’t work for me as well as my current setup. With a toddler in the house our lives have become exceptionally predictable so timer and presence is all I need to drive that sheet of thing.
And I went with the Python script mainly because I already wrote about 95% of the code already getting the GPIO and Bluetooth detection working. It ended up being a handful of new lines to add Dash support. Though apparently I’ve broken it along the way.
But if all you need is Dash, I don’t think one could beat your script for simplicity.
After Dash Button starts in Germany i try to use that script to get it running on my system but with no luck.
I installed the complete git hub sensorReporter, startet the install script and run as service. I can not get getMac.py running, no really got error message here.
WARNING: No route found for IPv6 destination :: (no default route?)
Traceback (most recent call last):
File "getMac.py", line 10, in <module>
print sniff(prn=arp_display, filter="arp", store=0, count=30)
File "/usr/lib/python2.7/dist-packages/scapy/sendrecv.py", line 586, in sniff
r = prn(p)
File "getMac.py", line 6, in arp_display
if pkt[ARP].op == 1: #who-has (request)
File "/usr/lib/python2.7/dist-packages/scapy/packet.py", line 770, in __getitem__
raise IndexError("Layer [%s] not found" % lname)
IndexError: Layer [ARP] not found
No idea what is wrong or missing.
Also i can not understand with your items how do you know wich button is pressed?
String T_D_Dash_Tide "Tide Dash Button" { mqtt="<[mosquitto:actuators/tide:state:default]" }
I can not see any mac address here or in script and not in rule. So how do you know wich one has been pressed?
Thx for any help or tipps
Unfortunately, like I said above, the Dash script isn’t fully working. I’ve made some updates for things I know were wrong but I’ve not managed to test them fully. I’ve locked down my network and I can’t seem to be able to sniff the ARP packets anymore to do the tests and I’ve not had time to go back and test this.
That being said, the error is caused because the sniffing script is receiving a non-ARP packet You can try changing the code as follows and see if that makes a difference.
Try adding in a check to make sure that the packet is an ARP before trying to get at the data:
#!/usr/bin/python
from scapy.all import *
def arp_display(pkt):
if ARP in pkt:
if pkt[ARP].op == 1: #who-has (request)
if pkt[ARP].psrc == '0.0.0.0': # ARP Probe
print "ARP Probe from: " + pkt[ARP].hwsrc
print sniff(prn=arp_display, filter="arp", store=0, count=30)
This check is already in place in the dash.py code, it is only missing in the getMac.py script.
From default.ini:
[Sensor5]
Class: dash.dash
Connection: MQTT
; One Address/Destination pair per button, start with 1, increment numbers
; Mac address
Address1: 12:34:56:78:90:12
Destination1: actuators/bounty
Address2: 21:09:87:65:43:21
Destination2: actuators/tide
; -1 means this sensor doesn't need to use the main polling thread, it polls on
; its own
Poll: -1
The MAC addresses are listed as Address1, Address2, etc. Each button has its own unique MAC which you put into this parameter. Coupled with each AddressX parameter there is a DesinationX. If you are using the MQTT connection, this is the topic that the word “Pressed” will be published to when that Dash button’s ARP packet has been detected. If you are using REST, this is the Item name of the Item that represents that particular Dash button in openHAB and to which the word “Pressed” will be pushed when the button’s ARP packet is detected.
So in the example in default.ini, there are two Dash buttons.
Address1: 12:34:56:78:90:12 ; MAC address of the Bounty button as determined via getMac.py or some other means
Destination1: actuators/bounty ; MQTT topic that corresponds with the Bounty button
Address2: 21:09:87:65:43:21 ; MAC address of the Tide button
Destination2: actuators/tide ; MQTT topic that corresponds with the Tide button
Hopefully, as you can see now, the mapping takes place in the .ini file. openHAB never needs to know anything about the MAC address. It just needs to know about the MQTT topic.
Let me know if you get this to work. I’ll update the repo with the change to the getMac.py script to avoid that error now but I’d love to know whether or not it works so I can update the description.
OK, I made some updates to getMac.py and dash.py.
It looks like it is working now, at least it did for me one time.
Pull from the repo again and let me know if it works for you.
Ok i tried it now some hours, could get it work. Your updates seem to work, getMac delivered an mac i added to the default.ini and the install was ok. I install mosquitto and added the bindings to openhab. I added the items, the rule and updated it with my names. But i can not get the dash button work. I have no idea how to test if there are commands received or something. The rules has not been triggered.
Can someone maybe make a short step by step guide? Or give me some tips how to test if all is working?
Thanks Matt, worked for me on my RPi3 in only a few minutes - and I am a Windows guy 
-
Follow the instructions from Amazon to set up the Dash button but stop before selecting a product.
-
Install sensor reporter following the install.sh script in the config folder.
-
Run getMac.py in the config folder and press the button. You should see an address printed. If your network has lots of ARP traffic you may need to check your router to eliminate the addresses coming from your other devices.
-
Create a sensorReporter.ini file with a section for the dash, connection (MQTT or REST), and logger. Use the default.iini as a template. The MAC goes in the Address1 field and if using MQTT the topic to publish to guess in Destination1. If using REST the name of the Item goes in Destination1.
-
Create an Item to represent the Dash button in OH. If using the MQTT, configure the Item to use the MQTT binding for incoming messages in the topic configured in the initial file (Destination1). When the Dash button’s ARP packet is detected sensorReporter will publish “Pressed” to that destination so configure your Item’s transform accordingly.
-
Testing (in order):
- Test Dash detection is working: when you ours the button you should see two lines printed to sensorReporter’s log/syslog (depending on how you have logging configured). One says the button press was detected and the other says it is publishing to the destination.
- Test MQTT: use a command line MQTT client (e.g. mqtt_sub) to subscribe to the Destination1 topic and verify that “Pressed” is being published to the topic when the Dash button is pressed.
- Test openHAB: Watch openhab.log and verify there are no errors. Watch events.log and verify that your Item is being updated when you press the button. If everything else works up to this point you either have a configuration error in openHAB, your Item, binding config, transform, it rule trigger.
1 Like
Thanks very much,I will test that in the next days.
So, couldn’t wait so I tried direct, no success. I get an error no section logging but I have this section.