360 Grad IR WLAN Gateway

Guenni1404 · 07 März 2021, 21:53:29

Zitat von: Snocksman am 19 Februar 2021, 11:12:43
Hat schon jemand so einen China Geeklink IR-Blaster mit dieser Lösung in Betrieb ? : https://de.aliexpress.com/item/32953822121.html?spm=a2g0o.productlist.0.0.68086db8KyM4D4&algo_pvid=55f24258-9087-44b4-8477-09406f95bd51&algo_expid=55f24258-9087-44b4-8477-09406f95bd51-0&btsid=2100bdd716137290468937638e0730&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

Ich frage aus folgendem Grund... Ich habe den Sketch https://github.com/phili76/IRBlaster360/ auf das Teil geladen und erfolgreich ins WLAN eingebunden. Leider schaltet es weder die LEDs ein, noch empfängt es irgendwelche IR-Codes. Ich vermute mal, das ich die PINs im Sketch anpassen müsste... Deswegen wäre es schön, wenn schon jemand so ein Teil im Einsatz hat und mir die PINs nennen könnte... (...oder ob noch etwas anderes angepasst werden müsste...)

Hi Socksman,

da schließe ich mich an. Läuft es bei dir? Wenn ja, wie hast du es zum laufen bekommen?

JoWiemann · 08 März 2021, 07:57:26

Zitat von: Guenni1404 am 07 März 2021, 21:53:29
Hi Socksman,

da schließe ich mich an. Läuft es bei dir? Wenn ja, wie hast du es zum laufen bekommen?

Hallo, habe das hier im Tasmota Forum gefunden:
Pin 5 GPIO14 is the IR Receiver
Pin 14 GPIO6 ? is the IR Transmitter(s)
Pin 12 GPIO10 ? is the red status LED on the front of the unit
Pin 13 GPIO8 ? is the orange L:ED on the front of the unit

Also, einfach mal ausprobieren.

Grüße Jörg

Snocksman · 11 März 2021, 22:04:25

Hat ein bisschen gedauert, da ich mir erstmal einen neuen Geeklink IR Blaster bestellen musste... Den alten hatte ich leider geschrottet. Ich hatte die Kabel an die Kontaktstellen angelötet, bin mit dem Pulli am Kabel hängen geblieben und hab eine Leiterbahn von der Platine abgerissen...

Aber jetzt ist der neue da und läuft auch schon (Kabel diesmal nicht angelötet, sondern zum flashen nur auf die Kontaktstellen gedrückt). Allerdings habe ich nach langem rumprobieren und immer wieder flashen erstmal tasmota geflashed und bin nun auch dabei geblieben. Für tasmota gibt es eine extra "Variante" für IR (Nennt sich sinnvollerweise "tasmota_ir").
Hier aber auf jeden Fall die richtigen GPIOs:
GPIO 0: Button
GPIO 2: ESP Onboard LED
GPIO 5: IR Reciever
GPIO12: rote LED
GPIO 13 orangene LED
GPIO 14: IR Sender

Pfriemler · 12 März 2021, 10:09:53

Zitat von: Snocksman am 11 März 2021, 22:04:25
... Den alten hatte ich leider geschrottet. Ich hatte die Kabel an die Kontaktstellen angelötet, bin mit dem Pulli am Kabel hängen geblieben und hab eine Leiterbahn von der Platine abgerissen...

irreparabel?

... Meist kann man das doch irgendwie retten. Ich hatte schon etliche batteriesäurezerfressene Leiterbahnen ersetzt. Wenn noch nicht weggeworfen: Versandkosten übernehme ich.
Richtig blöd ist, wenn man ein kleines Funkgerät nach dreimal Gucken (Platine liegt so, Batteriefach so, ah ja, nee, doch, ...) dann doch falschrum ans Labornetzteil anschließt, vergessen hat, die Strombegrenzung herunterzudrehen und man den Fehler zuerst am seltsamen Geruch merkt. Anschließend hatte der Transistor der Sendeendstufe so eine seltsame kleine Beule.
Shit happens. Ersatz ist unterwegs. Der Rest funktioniert noch - nur ohne Sendeleistung, HF-Technik hat ihre eigenen Gesetze.

Mad-at · 19 März 2021, 22:00:00

Zitat von: habeIchVergessen am 27 Februar 2021, 16:33:47
hier findest du ein kleines perl-Skript, das neben fhem auf die Muliticast-Nachrichten lauscht und auf der Konsole ausgibt.
wird etwas angezeigt, wenn IR-Codes vom Blaster gesendet werden?
wird auf einem anderen Rechner etwas empfangen (z.B. mit wireshark)?

Hi! Heute ist es erneut passiert. Die Sache ist: wenn ich Dein script starte zeigt es die multicast Nachrichten und das KVPUDP Device in fhem enpfängt die codes, wenn dein script nicht läuft, bekommt fhem nichts mit von den codes.

habeIchVergessen · 19 März 2021, 23:06:12

benutzt du eine Bridge (br0)?

Code Auswählen


brctl show
cat /sys/devices/virtual/net/br0/bridge/multicast_snooping

Mad-at · 19 März 2021, 23:13:14

Nicht dass ich wüsste...
Brctl - Befehl nicht gefunden
Cat [...] datei oder Verzeichnis nicht gefunden

Mein einziges virtuelles device ist lo

habeIchVergessen · 20 März 2021, 13:28:01

du benutzt keine Bridge!
was verwunderlich ist, dass fhem die Pakete empfängt, wenn parallel das Skript läuft.
scheinbar wird durch das Listen im Netzwerk-Stack von Linux eine Art "routing" aktiviert.
warum nach x Tagen der Kernel das Listen von fhem vergisst, kann ich dir nicht beantworten.

machst du andere Sachen, die das eventuell beeinflussen (z.B. Software-Update/-Installation, Firewall neu starten oder ähnliches)?

Mad-at · 20 März 2021, 13:45:31

Ich wüsste nicht was, natürlich läuft da viel auf dem Raspi, aber für mich gibt es keinen klaren Auslöser für das Problem. Manchmal ist es nach einem Neustart wieder gut, manchmal nicht. Derzeit will es garnicht.

habeIchVergessen · 20 März 2021, 16:19:50

beim ESP8266 erlaubt das SDK für den Multicast-Socket das Einstellen von TTL. Es wird auf 1 gesetzt.
Eventuell werden die Pakete gedropet, wenn sie über mehrere Hops im Netzwerk müssen.

probier mal folgendes

Code Auswählen


tcpdump -nnvv dst port 12345

bitte schauen, ob fhem dann auch wieder empfängt.

in der Ausgabe von dmesg erscheint dann so was

Code Auswählen


[15707963.692095] device eth0 entered promiscuous mode
[15707982.529719] device eth0 left promiscuous mode

Mad-at · 20 März 2021, 19:04:34

Nein das ändert nix...

Code Auswählen


tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel

habeIchVergessen · 20 März 2021, 23:29:42

dann kommen die Pakete nicht auf der Netzwerkkarte an.

Mad-at · 22 März 2021, 18:44:36

Aber wenn Dein Script im Hintergrund aktiv ist klappts auch mit dem dump.

Code Auswählen



sudo tcpdump -nnvv dst port 12345
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:38:04.838382 IP (tos 0x0, ttl 1, id 68, offset 0, flags [none], proto UDP (17), length 158)
    192.168.1.27.52186 > 239.0.0.57.12345: [udp sum ok] UDP, length 130
18:38:04.841434 IP (tos 0x0, ttl 1, id 69, offset 0, flags [none], proto UDP (17), length 426)
    192.168.1.27.52186 > 239.0.0.57.12345: [udp sum ok] UDP, length 398
18:38:04.842288 IP (tos 0x0, ttl 1, id 70, offset 0, flags [none], proto UDP (17), length 399)
    192.168.1.27.52186 > 239.0.0.57.12345: [udp sum ok] UDP, length 371
18:38:04.843415 IP (tos 0x0, ttl 1, id 71, offset 0, flags [none], proto UDP (17), length 158)
    192.168.1.27.52186 > 239.0.0.57.12345: [udp sum ok] UDP, length 130

4 packets captured
4 packets received by filter

Wie kann das sein???

habeIchVergessen · 22 März 2021, 21:48:53

probier mal in fhem

Code Auswählen


reload 36_KVPUDP

Mad-at · 23 März 2021, 20:15:41

Nein, leider, kein Erfolg - aber dann müsste ja auch ein Neustart das Problem verlässlich fixen, tut es ja auch nicht

edit: Aaber: jetzt nochmal "update all" und "shutdown restart" gemacht jetzt geht es wieder. Ist aber ja in der aktuellen Episode nicht das erste Mal dass ich das gemacht habe, nur das erste Mal dass es was ändert. Es ist aber nichts geupdated worden was irgendwas mit KVPUDP oder Multicast am Hut hätte. Alles sehr strange.