NodeMCU + KeyValueProtocol + FHEM-Modul

Begonnen von habeIchVergessen, 11 Dezember 2015, 22:37:17

Vorheriges Thema - Nächstes Thema

habeIchVergessen

Zitat von: Shojo am 18 Juli 2017, 22:11:44
Da ich ja so die Flexibilität verliere, das ich mich nicht um die IP des Devices kümmern muss.
alternativ zur IP kann auch die ChipID benutzt werden glaube ich.
Das Device zu benutzen finde ich nicht gut, da ja folgendes intuitiver wäre

set <device> raw ...


Shojo

Zitat von: habeIchVergessen am 18 Juli 2017, 22:57:56
Das Device zu benutzen finde ich nicht gut, da ja folgendes intuitiver wäre

set <device> raw ...

Ok da stimme ich dir absolut zu.

Zitat von: habeIchVergessen am 18 Juli 2017, 22:57:56
alternativ zur IP kann auch die ChipID benutzt werden glaube ich.
Das probiere ich mal :)
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

habeIchVergessen

natürlich alles anders als erwartet.

- set raw Chip-ID habe ich eingebaut
- die Kommandos, die gesendet werden dürfen müssen diese regexp erfüllen

m/^(-{0,1}\d*,{0,1}\d*)([a-zA-Z]{1})$/;


In Anlehnung an LaCrosseGateway kann man dann z.B.

1l
-5,14r
d

senden. Soll heißen 1 oder 2 Zahlen mit Komma getrennt und ein Buchstabe. Ist aber nicht in Stein gemeiselt.

Shojo

Zitat von: habeIchVergessen am 18 Juli 2017, 23:56:00
Soll heißen 1 oder 2 Zahlen mit Komma getrennt und ein Buchstabe. Ist aber nicht in Stein gemeiselt.

Das ist ja schon mal was :)

Ich hatte aber vor eine Ganze Menge mehr zu sende :D
Einmal zum 360 Grad IR WLAN Gateway (https://forum.fhem.de/index.php?topic=72950)
Und noch ein anderes Projekt (eine LED Dotmatrix für FHEM)
Da kommen dann schon gerne 500 Zeichen beisammen  ;D
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

habeIchVergessen

würde gerne den Aufwand zum Parsen in FHEM belassen.

Skizziert doch mal kurz die Anforderungen auf der FHEM-Seite, die Übertragung und das Auslesen im Sketch.

Shojo

Ja ich hätte es nun gedacht:
set myKVPUDP raw <ChipID> <Funktion> <Wert>
set myKVPUDP raw  2354154 json.plain [{'data':'0', 'type':'RC6', 'length':1}]
set myKVPUDP raw  2354154 json.plain [{'data':[550,650, 1200,650, 1200,650, 1200,650, 550,650, 1200,650, 550,650, 550,650, 550,650, 550,25300, 2350,650, 550,650, 1200,650, 550,650, 1200,650, 1200,650, 1200,650, 550,650, 1200,650, 550,650, 550,650, 550,650, 550], 'type':'raw', 'khz':38}]
set myKVPUDP raw  2354154 msg.code 0:RC6:1


set <Device> <Funktion> <Wert>
Natürlich wäre natürlich  das ein Traum :)

FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

habeIchVergessen

263 Zeichen
set myKVPUDP raw  2354154 json.plain [{'data':[550,650, 1200,650, 1200,650, 1200,650, 550,650, 1200,650, 550,650, 550,650, 550,650, 550,25300, 2350,650, 550,650, 1200,650, 550,650, 1200,650, 1200,650, 1200,650, 550,650, 1200,650, 550,650, 550,650, 550,650, 550], 'type':'raw', 'khz':38}]
die bei SIGNALduino wahrscheinlich so aussehen würden und "nur" 124 Zeichen benötigen
set myKVPUDP raw 2354154 P1=550;P2=650;P3=1200;P4=2350;P5=25300;D=123232321232121212154212321232323212321212121;F=38;T=raw;

die sind ja sehr ähnlich
set myKVPUDP raw  2354154 json.plain [{'data':'0', 'type':'RC6', 'length':1}]
set myKVPUDP raw  2354154 msg.code 0:RC6:1



wo ist die Betrachtung der Logik zum Parsen auf dem Zielgerät (z.B. NodeMCU/Wemos D1)?
Die sollte aus meiner Sicht sehr "einfach" sein, da dort die wenigsten Resourcen zur Verarbeitung vorhanden sind.
Wie steht es mit dem Zeitverhalten? kleine Latenz gewünscht?

Shojo

Zitat von: habeIchVergessen am 20 Juli 2017, 22:49:50
wo ist die Betrachtung der Logik zum Parsen auf dem Zielgerät (z.B. NodeMCU/Wemos D1)?
Die sollte aus meiner Sicht sehr "einfach" sein, da dort die wenigsten Resourcen zur Verarbeitung vorhanden sind.
Wie steht es mit dem Zeitverhalten? kleine Latenz gewünscht?

Ja da dafür gibt es noch nichts, da ich ja nichts habe worauf ich aufbauen kann.

Sonst ist die Firmware von IR-Blaster ist hier zu finden.
Wenn es um die aktuellen Beispiele geht. 

Für die Dotmatrix habe ich noch nichts geschrieben,da dieses Projekt noch nicht geratet ist.
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

ext23

Nabend,

eine Frage, ich nutze das Modul um IR Codes im IRBlaster zu empfangen. FHEM läuft bei mir auch einem Linux Rechner, ich sehe die Multicast Pakete mit tcpdump aber das Modul legt mir per autocreate kein neues Gerät an. Hat noch jemand eine Idee? Ich habe via iptables eigentlich alles was Multicast ist erlaubt, aber irgendwie bin ich etwas Ratlos warum es nicht funktioniert. In den Logs sehe ich auch nichts.

Hat noch jemand ein Tip?

Internals:
   Clients    :KeyValueProtocol
   FD         41
   NAME       myKVPUDP
   NR         2003
   STATE      Opened
   TYPE       KVPUDP
   MatchList:
     1:KeyValueProtocol ^OK\sVALUES\s
   helper:
     bm:
       KVPUDP_Set:
         cnt        11
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        11.01. 20:59:16
         max        8.98838043212891e-05
         tot        0.000323295593261719
         mAr:
           HASH(0x849bb48)
           myKVPUDP
           ?
Attributes:
   verbose    5


/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

habeIchVergessen

schon das perl-Skript aus dem ersten Post probiert?
sollte ein neues Geräte KeyValueProtocol_Test_0 anlegen.

ext23

Ja das hat funktioniert und das entsprechende Geräte angelegt.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

habeIchVergessen

im FHEM ist dann nur noch das Limit vom autocreate (default 2 Nachrichten in 2 min.).
vor dem dispatch wird ins log geschrieben, das x Bytes von IP empfangen wurden.

Sind solche Einträge im Log?
Wieviele Ethernet-Devices sind aktiv?
Beim Empfang der ersten Nachricht, wird ein http-Request gegen die sendende IP ausgeführt. Ist der mit tcpdump zu sehen (inkl. Response)?

ext23

#42
>Sind solche Einträge im Log?
Nein

>Wie viele Ethernet-Devices sind aktiv?
3, Loopback, br0 und eth0

>Beim Empfang der ersten Nachricht, wird ein http-Request gegen die sendende IP ausgeführt. Ist der mit tcpdump zu sehen (inkl. Response)?
Nein, man sieht nur die UDP Multicast Pakete vom IRBlaster (tcpdump auf eth0)

Dann habe ich tcpdump mal auf dem br0 Interface gestartet und schon funktioniert es, sofort hat FHEM das Device angelegt und man sieht auch die Logs und Nachrichten die du beschrieben hast.

Jetzt frage ich mich aber warum. Das sieht ja so aus, als wenn der premiscous mode in den tcpdump ja die Interface setzt dafür sorgt, dass es funktioniert. Ich glaube ich muss mir die bridge config nochmal anschauen. (Die habe ich nur angelegt wegen KVM, da braucht man das wenn man mit virtuellen Maschinen arbeitet)

/Daniel

UPDATE: Ich hab die Bridge rausgehauen. Jetzt geht es.
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Mad-at

Hm, sorry, hänge gerade ein bißchen, FHEM will das Modul nicht laden weil "Bareword "KeyValueProtocol" not allowed while "strict subs" in use at ./FHEM/36_KVUDP.pm line 201."
Irgend eine Idee?

habeIchVergessen

#44
ich vermute einen Typo im Modul.
Welche Version benutzt du (Link)?
Kannst du bitte Zeile 196 bis 206 aus deinem Modul posten?