Amazon Dash Button

Begonnen von gloob, 31 August 2016, 08:20:07

Vorheriges Thema - Nächstes Thema

gloob

Seit heute gibt es bei Amazon die Dash Buttons für 5€ zu bestellen. Es handelt sich dabei um einen batteriebetriebenen Schalter der sich ins eigene WLAN einbindet und normalerweise Sachen bei Amazon bestellt.

Es gibt schon mehrere Projekte wie man den Bestelltvorgang unterbinden kann und den Schalter für andere Sachen misbrauchen kann.
Vielleicht wäre das ja auch etwas für FEHM um günstig einen batteriebetriebenen Schalter zu haben.

Ich habe mir mal 3 Stück bestellt und werde mal schauen was man damit so treiben kann.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

kumue

unglaublich, was es alles gibt...   :o ::)

Rince

#2
Wenn du bestellt hast, geht es da weiter :)

https://medium.com/@edwardbenson/how-i-hacked-amazon-s-5-wifi-button-to-track-baby-data-794214b0bdd8#.fua9xka25


Finden des Services im Netzwerk (wobei die Dritte es sicher auch so anzeigt)

from scapy.all import *

def arp_display(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=10)



Hier das ausgebaut:

def arp_display(pkt):
  if pkt[ARP].op == 1: #who-has (request)
    if pkt[ARP].psrc == '0.0.0.0': # ARP Probe
      if pkt[ARP].hwsrc == '74:75:48:5f:99:30': # Huggies
        print "Pushed Huggies"
      elif pkt[ARP].hwsrc == '10:ae:60:00:4d:f3': # Elements
        print "Pushed Elements"
      else:
        print "ARP Probe from unknown device: " + pkt[ARP].hwsrc

print sniff(prn=arp_display, filter="arp", store=0, count=10)


Das ist das eigentliche. Statt der Print Ausgabe könnte man genauso gut einen http Aufruf an fhem senden. Im Wiki (optischer Sensor) ist funktionierender Python Code.

Damit dürfte es eine Sache von Minuten sein.

Dummy für den Button anlegen und ein Notify oder ein DOIF drauf triggern lassen, fertig.

Nur beachten, das Button Setup nicht abzuschließen!
(Steht im Blog schön beschrieben drin)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Hauswart

Damit könnte man ja im ersten Monat mal eine Klingel realisieren :D Meine Funk-Klingeln sind sowieso nicht so das gelbe vom Ei. Braucht es nur noch einen Actor...
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

malted

#4
Die Frage ist meines Erachtens, wie gut diese ARP-Catch Lösung skaliert. Und ob man jetzt wirklich zahlreiche Wifi-Buttons in sein normales Wlan einhängen will, bleibt auch zu überlegen.

Meine erste Idee wäre, dass man sich einen Nexx WT3020 als Gateway besorgt. Dort installiert man openwrt drauf. Dann richtet man ein eigenes Wlan-Netz für die Knöpfe ein und lässt man einfach auf dem Openwrt ein mini-script laufen:


while true; do
iw dev wlan0 station dump | grep Station | sed -e 's/Station \([^ ]\+\) .*/setreading dashbutton \1 pressed/g
'  | nc -q 1 fhem 7072
sleep 1
done


In Fhem legt man für alle Geräte ein Dummy an.

define dashbutton dummy

Mit dem Script wird dann für jeden tatsächlichen Button ein Reading mit dem Namen der Mac-Adresse befüllt und beim Drücken der Zeitstempel aktualisiert.

Das schöne ist, dass dann der openwrt-Router quasi als Netzwerk-Gateway für bis zu 255 Knöpfe fungiert, man die nicht in seinem normalen Netz hat und die auch trivial (über das Admin-Interface) aus dem Internet aussperren kann, sobald sie eingerichtet sind.

Nur mal so als Brainstorming-Idee.


distel

Mich jucken die Dinger ja auch schon in den Fingern... eigentlich hab ich aktuell gar keine Zeit zum Basteln, aber ich werd mal ein-zwei bestellen. Wo bekommt man denn so einen WT3020? China?
NUC-I37100
Docker: eBus, fhem, ha-bridge, unifi
Hardware: Homematic, FS20, Somfy RTS, 1wire, FBAHA, enOcean

gloob

Ich habe aktuell einen TPLink MR3020 zuhause und werde es mit dem probieren. Ich denke dafür sollte die Leistung locker reichen.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

beckerheinz

Also eine Integration der Dinger in FHEM würde mich auch stark interessieren!  8)
RPi mit FHEM 5.7, Jeelink +  9 LaCrosse TX29DTH, Jeelink +  10 PCA301 Funksteckdosen, CUL868 mit 9 MAX! Heizkörperthermostaten und Fensterkontakten, 3 Somfy RTS Rollos, Tahoma, CUL + Homematic  mit 2 HM-WDS30-OT2-SM-2

malted


Was mir gerade eingefallen ist... Wenn wir einen beliebigen Openwrt-Router als Gateway zu FHEM nehmen, geht das weiterreichen trivial mit der remote-logging Funktion.

Mit logread sieht man den Log-Buffer, in dem Zeilen auftauchen wie:

Wed Aug 31 09:41:18 2016 daemon.info hostapd: wlan0: STA ec:11:22:33:44:55 IEEE 802.11: authenticated


logread kann direkt den Buffer mit ner Regexp filtern und per udp an einen beliebigen Server im Netz schicken.
Das komplette Log schickt man z.B. mit

/sbin/logread -f -u -r 192.168.1.235 5555 -p /var/run/logread.1.pid

Auf dem Empfangsserver sieht man dann die Zeilen testweise mit
nc -l 5555 -u

Man muss also einfach nur in Perl für FHEM einen mini-udp-server bauen
my $server = IO::Socket::INET->new(LocalPort=>5555,Proto=>"udp")

Dann startet man auf dem wrt das remote-logging mit passender Regexp.
/sbin/logread -e ".*associated$" -f -u -r 192.168.1.235 5555 -p /var/run/logread.1.pid


Das geht dann auch ohne Delay, da es quasi vom Openwrt zum FHEM gepusht wird. Bei der vorherigen Lösung hat man durch das sleep 1 ggf. ein höheres Delay drin.


MadMax-FHEM

Hi,

ja was es nicht alles gibt...
...ich liebe ja so Spielereien (leider zu wenig Zeit oft).

Für einen Klingelschalter/Taster mag es wohl gehen allerdings als Lichtschalter wohl leider ungeeignet, wenn ich mir das "Tutorial" so durchlese:

ZitatYou'll see a message appear after a few seconds (the buttons take a while to power on!)

Habe mal ein wenig mit ESP8266 "rumgespielt" und versucht was mit Batterie zum Laufen zu bringen, da war auch: DeepSleep - aufwachen - mit AP verbinden - (Messung durchführen und) senden und wieder DeepSleep.
Hat nicht wirklich lange gedauert aber wie gesagt als Lichtschalter so eher ungeeignet...
...da müsste das Funkmodul schon 'an' bleiben.

Da ist dieser (zusätzliche) Delay auch nicht so entscheidend:

Zitatwhile true; do
iw dev wlan0 station dump | grep Station | sed -e 's/Station \([^ ]\+\) .*/setreading dashbutton \1 pressed/g
'  | nc -q 1 fhem 7072
sleep 1
done

Zitat von: malted am 31 August 2016, 11:49:36
Das geht dann auch ohne Delay, da es quasi vom Openwrt zum FHEM gepusht wird. Bei der vorherigen Lösung hat man durch das sleep 1 ggf. ein höheres Delay drin.

Wobei der Delay/Sleep wohl nur ist, um eine dauerlaufende Endlosschleife auch mal ein wenig zu pausieren...
...kann also wohl auch kürzer als eine Sekunde ausfallen!?
(sofern es einen kürzeren Sleep-Befehl gibt)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

zYloriC

Hallo zusammen,

es ist ein sehr spannendes Thema zu dem ich auch gerade einen Forum-Artikel eröffnen wollte... zum Glück hat mich die SuFu hier hin gebracht.

Ich bestelle mir auch Buttons und denke über deren Einbindung nach. Wie wäre es, wenn man für die Buttons das Fritz-Box Gast-WLAN nutzt und ihnen den Zugang zum Netz nach der Installation verweigert.
Über das Fhem Fritzbox-Modul sollte man beim Drücken des Buttons ja seine IP in Fhem auch sehen, wenn der Button im dedizierten Gast-WLAN ist, oder?

Ich versuche mit dem Ansatz die Buttons nicht ins Internet zu lassen, möchte aber auch ungern einen zweiten Router nur für 3 Buttons.... was denkt ihr dazu.

Gruß, zYloriC

malted

Zitat von: zYloriC am 31 August 2016, 13:17:14
Ich bestelle mir auch Buttons und denke über deren Einbindung nach. Wie wäre es, wenn man für die Buttons das Fritz-Box Gast-WLAN nutzt und ihnen den Zugang zum Netz nach der Installation verweigert.
Über das Fhem Fritzbox-Modul sollte man beim Drücken des Buttons ja seine IP in Fhem auch sehen, wenn der Button im dedizierten Gast-WLAN ist, oder?

Ich versuche mit dem Ansatz die Buttons nicht ins Internet zu lassen, möchte aber auch ungern einen zweiten Router nur für 3 Buttons.... was denkt ihr dazu.

Gruß, zYloriC

Aller Voraussicht nach wirst Du ARP-Pakete aus dem Gast-Wlan in Deinem normalen nicht sehen können. Sonst wäre die Netz-Segregation absolut bescheuert umgesetzt. Das heißt, du kannst die Erkennung bestenfalls auf der Fritzbox selbst laufen lassen.

Grundsätzlich kann ich verstehen, dass du keinen zweiten Router möchtest. Das WT3020 gibts aber bei Aliexpress für ~10€ und erlaubt einem eine saubere Trennung vom Heimnetz und irgendwelchen IoT-Wifi-Geräten, die ohnehin nicht ins Internet sollen. Das kann man dann auch auf einem anderen Channel laufen lassen. Sollten sich IoT-Wifi-Geräte durchsetzen, ist ein eigenes IoT-WLan-Netzwerk mit einem Proxy zu FHEM ohnehin die sauberste Lösung, insbesondere unter Sicherheitsgesichtspunkten.
Der Router entspräche dann im Prinzip einer Hue-Bridge oder einem HMLAN.


malted

Zitat von: arestant am 31 August 2016, 14:17:41
Im Netz sind bereits zahlreiche Hacks zu finden.

Die basieren alle auf demselben Hack und zwar ARP-Sniffing. Unterschiedlich sind nur die Aktionen, die ausgelöst werden. Das ist aber für eine FHEM-Integration zweitrangig.

Wichtig ist die Information, dass der Button komplett schläft, bis man drauf drückt und der dann aufwacht, sich im Wlan neu anmeldet und dann sein Request absetzt, um dann wieder einzuschlafen.

Im Grunde sehe ich drei Möglichkeiten, das an FHEM anzubinden.

Mit Stock-Firmware auf dem Dash:
1. Das Verbinden auf dem Wifi-Access-Point detektieren.
2. Das Aufwachen und Einbuchen im Wifi mit ARP-Sniffing mitbekommen
3. Man kann die Firmware auf dem Dash neuflashen, da kann man theoretisch direkt FHEM benachrichten.

Dafür muss man aber Drähte an den Button löten, was auf den ersten Blick ziemlich friemlig aussieht, da der Button sehr klein ist. Die Frage ist, ob sich das bei so einem 5€ Ding zeitlich überhaupt lohnt.
Dann wohl gleich einen Clone bauen. http://hackaday.com/2015/05/13/an-amazon-dash-like-button-for-the-esp8266/
.
Die ARP-Sniff Variante kann man direkt auf dem FHEM-Server laufen lassen, ist etwas frickeliger, braucht aber nichts weiter.
Einen beliebigen Openwrt als Pendent einer HUE-Bridge für beliebige Buttons zu nutzen, ist m.E. die aufwändigere, aber sauberere Lösung. Außerdem dürfte das die etwas schnellere Lösung sein, da man nicht erst den DHCP-Handshake abwarten muss, sondern via HOSTAP das Associate als Event nehmen kann.


Blackmore

Oder einen ESP nehmen, der die Buttons empfängt, die Daten an nen zweiten ESP übergibt, der die Daten an FHEM sendet...