360 Grad IR WLAN Gateway

Begonnen von gloob, 08 Juni 2017, 21:16:36

Vorheriges Thema - Nächstes Thema

Guenni1404

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...) :D

Hi Socksman,

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

JoWiemann

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
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Snocksman

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

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?  :o ... 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.  ;D
Shit happens. Ersatz ist unterwegs. Der Rest funktioniert noch - nur ohne Sendeleistung, HF-Technik hat ihre eigenen Gesetze.



"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Mad-at

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

benutzt du eine Bridge (br0)?


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

Mad-at

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

Mein einziges virtuelles device ist lo

habeIchVergessen

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

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

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

tcpdump -nnvv dst port 12345


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

in der Ausgabe von dmesg erscheint dann so was

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

Mad-at

Nein das ändert nix...


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

dann kommen die Pakete nicht auf der Netzwerkkarte an.

Mad-at

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



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

probier mal in fhem


reload 36_KVPUDP

Mad-at

#809
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.