Amazon Dash Button

[betateilchen]

wenn du das raus findest könnte man das vielleicht sogar direkt ins fhem modul einbauen. dann müssten man dort hin umbiegen. vorausgesetzt die daten sind lesbar.

Also irgendwas tut sich inzwischen an meinem Apache, allerdings habe ich den ziemlich verbogen und er hört auf 443 und 80 identisch (ohne ssl)

Code Auswählen Erweitern

parker-gw-eu.amazon.com:80 192.168.123.222 - - [06/Sep/2016:22:03:50 +0200] "\x16\x03\x03" 400 0 "-" "-"

Aber für heute hab ich keine Lust mehr. Werde wohl mal ein selbstsigniertes Zertifikat für parker erstellen und dann ssl korrekt konfigurieren.

[CarstenF]

Paste mal den Output von 'logread' auf dem OpenWRT, wenn sich ein Dash-Button anmelden. Vermutlich passt die Regexp nicht.

Eventuell geht es mit
     if (($newmsg) =~ /^.*DHCPACK.*([0-9a-f:]{17}).*/ ) {
statt
     if (($newmsg) =~ /^.*hostapd:.*STA ([0-9a-f:]{17}).* associated/ ) {

Das ist der Output:

Code Auswählen Erweitern

Sep  6 20:08:42 iotgw daemon.info hostapd: wlan0: STA ac:63:be:a7:d7:e3 IEEE 802.11: authenticated
Sep  6 20:08:42 iotgw daemon.info hostapd: wlan0: STA ac:63:be:a7:d7:e3 IEEE 802.11: associated (aid 1)
Sep  6 20:08:43 iotgw daemon.info hostapd: wlan0: STA ac:63:be:a7:d7:e3 WPA: pairwise key handshake completed (RSN)

Ich versuche mal die Änderung
Danke erstmal

Gruß C.

[malted]

Also das Perl Script läuft jetzt: Awaiting UDP messages on port 5555
Auf Open WRT startet /sbin/logread -e ".* associated .*" -f -u -r 192.168.1.22 5555 -p /var/run/logread.1.pid   in der /etc/rc.local
Der dummy dash ist auch angelegt. Jedoch kommen keine Readings.  Oder muß ich jeden Dash Button anhand der Mac Adresse noch separat anlegen?
Ach so, in open wert meldet sich der dash natürlich an...

Gruß Carsten

Kommt denn das Log auf dem FHEM-Server an? Unter "Awaiting UDP messages on port 5555" sollten Zeilen auftauchen.
In Antwort #52 habe ich das Remote-Logging über das Webinterface beschrieben:
8. System -> System -> Logging  -> Dort als External system log server die IP von fhem eintragen, als Port z.B. 5555 nehmen. (Damit geht das komplette log an FHEM, das ist aber nicht viel Text/Traffic und  man kann es auf dem FHEM-Rechner filtern)

Probier das mal lieber so.

[CarstenF]

Also im Log vom Fhem Server kommen unter awaiting UDP Messages, keine Messages rein. Deshalb werden vermtl. auch keine Readings angelegt. Werde morgen nochmal alles in Ruhe durchgehen.
Die Antwort #52 habe ich so im Open WRT Router verarbeitet.  Einstellungen stimmen so überein. Naja, Rom wurde auch nicht in einem Tag erbaut. Danke Dir erstmal für die Unterstützung.!
Carsten

[justme1968]

also die dhcp modul variante scheint mir doch einfacher als die ganzen scripte und module die es für die anderen wege braucht

gruss
  andre

[CarstenF]

Ach ich finde beide Wege jetzt spannend und bin ja für alles offen um es auszuprobieren. Die Teile sind ja erst seit ein paar Tagen auf dem Markt. Außerdem hab ich wieder was dazugelernt.  . Aber könnte schon sein, das ich das dhcp Modul auch noch ausprobiere.


Gesendet von iPad mit Tapatalk

[betateilchen]

Im Moment klemmt es hier bei der Kommunikation zwischen button und apache noch am ssl-Gedöns.

Wen es interessiert, hier die gesamte Kommunikation vom Knopdrücken bis zum Erlöschen der roten Lichtorgel.

Code Auswählen Erweitern


23:05:12.863610 IP cubie.bootps > dash1.mowg.lan.bootpc: BOOTP/DHCP, Reply, length 300
23:05:12.865554 ARP, Request who-has cubie tell dash1.mowg.lan, length 46
23:05:12.865638 ARP, Reply cubie is-at 02:d4:07:42:e2:d7 (oui Unknown), length 28
23:05:12.867465 IP dash1.mowg.lan.59669 > cubie.domain: 27056+ A? time-c.nist.gov. (33)
23:05:12.867894 IP cubie.domain > dash1.mowg.lan.59669: 27056 1/0/0 A 129.6.15.30 (49)
23:05:12.869170 IP dash1.mowg.lan.59670 > time-c.nist.gov.ntp: NTPv4, Client, length 48
23:05:12.874341 IP dash1.mowg.lan.59669 > cubie.domain: 4242+ A? parker-gw-eu.amazon.com. (41)
23:05:12.874919 IP cubie.domain > dash1.mowg.lan.59669: 4242* 1/0/0 A 192.168.123.241 (57)
23:05:12.877200 IP dash1.mowg.lan.59671 > cubie.https: Flags [S], seq 3739696318, win 4338, options [mss 1446], length 0
23:05:12.877447 IP cubie.https > dash1.mowg.lan.59671: Flags [S.], seq 2743759839, ack 3739696319, win 29200, options [mss 1460], length 0
23:05:12.882978 IP dash1.mowg.lan.59671 > cubie.https: Flags [.], ack 1, win 4338, length 0
23:05:12.883062 IP dash1.mowg.lan.59671 > cubie.https: Flags [P.], seq 1:75, ack 1, win 4338, length 74
23:05:12.883265 IP cubie.https > dash1.mowg.lan.59671: Flags [.], ack 75, win 29200, length 0
23:05:14.692655 IP cubie.https > dash1.mowg.lan.59671: Flags [.], seq 1:1447, ack 75, win 29200, length 1446
23:05:14.692813 IP cubie.https > dash1.mowg.lan.59671: Flags [P.], seq 1447:2893, ack 75, win 29200, length 1446
23:05:14.694265 IP cubie.https > dash1.mowg.lan.59671: Flags [P.], seq 2893:4272, ack 75, win 29200, length 1379
23:05:14.695130 IP dash1.mowg.lan.59671 > cubie.https: Flags [.], ack 1447, win 4338, length 0
23:05:14.712339 IP dash1.mowg.lan.59671 > cubie.https: Flags [F.], seq 75, ack 2893, win 4338, length 0
23:05:14.712926 IP cubie.https > dash1.mowg.lan.59671: Flags [F.], seq 4272, ack 76, win 29200, length 0
23:05:14.714082 IP dash1.mowg.lan.59671 > cubie.https: Flags [.], ack 4273, win 4338, length 0
23:05:14.733131 IP dash1.mowg.lan.59669 > cubie.domain: 14970+ A? parker-gw-eu.amazon.com. (41)
23:05:14.733597 IP cubie.domain > dash1.mowg.lan.59669: 14970* 1/0/0 A 192.168.123.241 (57)
23:05:14.736913 IP dash1.mowg.lan.59672 > cubie.https: Flags [S], seq 3739696347, win 4338, options [mss 1446], length 0
23:05:14.737103 IP cubie.https > dash1.mowg.lan.59672: Flags [S.], seq 812506098, ack 3739696348, win 29200, options [mss 1460], length 0
23:05:14.741736 IP dash1.mowg.lan.59672 > cubie.https: Flags [.], ack 1, win 4338, length 0
23:05:14.741832 IP dash1.mowg.lan.59672 > cubie.https: Flags [P.], seq 1:75, ack 1, win 4338, length 74
23:05:14.742052 IP cubie.https > dash1.mowg.lan.59672: Flags [.], ack 75, win 29200, length 0
23:05:16.520391 IP cubie.https > dash1.mowg.lan.59672: Flags [.], seq 1:1447, ack 75, win 29200, length 1446
23:05:16.520448 IP cubie.https > dash1.mowg.lan.59672: Flags [P.], seq 1447:2893, ack 75, win 29200, length 1446
23:05:16.520540 IP cubie.https > dash1.mowg.lan.59672: Flags [P.], seq 2893:4097, ack 75, win 29200, length 1204
23:05:16.520858 IP cubie.https > dash1.mowg.lan.59672: Flags [P.], seq 4097:4272, ack 75, win 29200, length 175
23:05:16.522635 IP dash1.mowg.lan.59672 > cubie.https: Flags [.], ack 1447, win 4338, length 0
23:05:16.539916 IP dash1.mowg.lan.59672 > cubie.https: Flags [F.], seq 75, ack 2893, win 4338, length 0
23:05:16.540353 IP cubie.https > dash1.mowg.lan.59672: Flags [F.], seq 4272, ack 76, win 29200, length 0
23:05:16.541709 IP dash1.mowg.lan.59672 > cubie.https: Flags [.], ack 4273, win 4338, length 0


[Wzut]

also die dhcp modul variante scheint mir doch einfacher als die ganzen scripte und module die es für die anderen wege braucht

Richtig , elegant und schlank ist es nur fürchte ich wird nicht jeder User damit glücklich werden.
Denke das hängt stark mit der Struktur und den verbauten Komponenten des eigenen Netzes zusammen.
So sehe ich z.B. an meinem fhem Server extrem wenig DHCP Telegramme auf Port 6767 ganz im Gegensatz zu ARPs die etwa im Sekundentakt einfliegen. Ich hatte zum vergleichen deine Modul Version zeitgleich über einige Stunden mit meiner ARP Variante laufen lassen. Da ich (noch) keinen Dash besitze habe ich bei meinen Tests immer an meinem Smartphone WLAN an und aus geschaltet und auf dessen MAC getriggert ohne einen Treffer im Log (verbose = 5 ) zu sehen.
 

[justme1968]

so wie ich das verstehe sendet der dash button bei jedem aufwachen auf jeden fall die dhcp anfrage. vermutlich weil es keine uhr gibt und keinen speicher um die lease zeit zu nutzen.

alle anderen geräte im netz sollten die lease time nutzen und keine/wenig vorzeitige dhcp anfragen senden.

ich vermute diskrepanz der arp und dhcp zahlen bei dir liegt daran. um einen belastbaren vergleich zu haben muss man es glaube ich mit echten dash buttons testen und nicht mit etwas anderem.

zumindest hat bei meinen test gestern jeder druck bzw. jedes aufwachen zuverlässig eine dhcp anfrage erzeugt.


erst die variante die den echten request des button abfängt würde tatsächlich von der netzwerk struktur abhängen und einen dhcp server voraussetzen der für die buttons eine eigene route unterschieben kann um dann die dns anfragen und den server umzubiegen.

[Wzut]

muss man es glaube ich mit echten dash buttons testen und nicht mit etwas anderem.

@Andre, da hast du vermutlich Recht, gestern Abend hatte ich ein neues Gerät im Netz und für das wurde auch sofort ein neues Reading angelegt.

[Niko1987]

Hallo zusammen

vermutlich was ganze einfaches nur bin ich linuztechnisch ned fit und hab immer bissl Respekt davor, mit den Userrechten rumzuspielen.
Kann mit jemand nen Tip zu folgendem Fehler im Logfile geben?

2016.09.08 11:32:15 3: dash: failed to connect to  IO::Socket::INET: Permission denied

Hab nen Intel Nuc mit Ubuntu mit dhcp dash

Das es sich um fehlende rechte handelt ist klar aber weis nicht wie ich die rechte vergeben kann.

Danke & Gruß

Niko

[Wzut]

Was hast denn für einen Port angegeben ? 67 ? dann kann das nur root !
Daher ja der Vorschlag von Andre mit iptables umlegen auf 6767

iptables -A PREROUTING -t nat -i eth0 -p udp --dport 67 -j REDIRECT --to-port 6767

[gloob]

Kann man FHEM nicht irgendwie als Root ausführen.

[betateilchen]

doch, aber das macht keinen Sinn.

[fh168]

@wzut sag mal Bescheid, ob ich bei dir die Buttons dann funktionieren. ich bin hier am verzweifeln