EQ-3 ESA2000WZ: falsches dispatching?

Begonnen von hjgode, 06 Juli 2015, 20:04:01

Vorheriges Thema - Nächstes Thema

hjgode

Hallo

habe seit kurzem einen EQ-3 Energiesparampel Sender im Betrieb.

Leider wurde er von meinem nanoCUL mit 433MHz nicht empfangen. Da habe ich mir noch einen nanoCUL mit 868MHz zugelegt. Aber auch damit erschien kein ESA2000 in fhem.

Am WE habe ich mir das genauer angesehen und festgestellt, das die Daten des ESA2000 falsch verteilt werden. Genuaer gesagt wurden die Daten an TCM970001 weitergereicht. Dieses Modul kann aber damit nix anfangen und nix ist mit ESA:

2015.07.05 08:48:06 5: CUL/RAW: SE76117011E000051660004000000/002
2015.07.05 08:48:06 5: CUL/RAW: SE76117011E000051660004000000002/A3A
2015.07.05 08:48:06 5: CUL/RAW: SE76117011E000051660004000000002A3A^M/

2015.07.05 08:48:06 4: CUL_Parse: nanoCUL433 SE76117011E000051660004000000002A3A -45
2015.07.05 08:48:06 5: nanoCUL433 dispatch SE76117011E000051660004000000002A
2015.07.05 08:48:06 4: CUL_TCM97001 Unknown 231 (E76117011E000051660004000000002A) length: 32 RSSI: -53
2015.07.05 08:48:06 4: CUL_TCM97001 Device not implemented yet name Unknown msg E76117011E000051660004000000002A
2015.07.05 08:48:06 5: Triggering CUL_TCM97001_Unknown (1 changes)
2015.07.05 08:48:06 5: Notify loop for CUL_TCM97001_Unknown Code: E76117011E000051660004000000002A


Ja, richtig, auch der nanoCUL433 empfängt die Daten. Keine Ahnung warum...

Da ich eh keinen TCM... im Besitz habe, habe ich die Datei 14_CUL_TCM97001.pm in 14_CUL_TCM97001.pm.OFF umbenannt und siehe da, jetzt bekommt das Modul 64_ESA2000.pm die Daten:

2015.07.05 09:00:41 4: CUL_Parse: nanoCUL433 S6C6117011E000051750001000000002A3A -45
2015.07.05 09:00:41 5: nanoCUL433 dispatch S6C6117011E000051750001000000002A
2015.07.05 09:00:41 5: ESA2000 msg s6c6117011e000051750001000000002a
2015.07.05 09:00:41 5: ESA2000 seq 6c
2015.07.05 09:00:41 5: ESA2000 device 6117
2015.07.05 09:00:41 5: ESA2000 code 011e
2015.07.05 09:00:41 4: ESA2000 Stromzaehler: CNT: 108- CUM: 0.000 CUR: -1.000 TICKS: 75 LR
2015.07.05 09:00:41 5: Triggering Stromzaehler (15 changes)
2015.07.05 09:00:41 5: Notify loop for Stromzaehler repeat: -


Dann habe ich gedacht, es muß doch auch mit dem TCM Modul zusammen funktionieren, aber da stimmt was nicht. Soweit ich das verstehe, bekommt zuerst das Modul 00_CUL.pm die Daten. Dort steht:

my %matchListSlowRF = (
    "1:USF1000"   => "^81..(04|0c)..0101a001a5ceaa00....",
    "2:BS"        => "^81..(04|0c)..0101a001a5cf",
    "3:FS20"      => "^81..(04|0c)..0101a001",
    "4:FHT"       => "^81..(04|09|0d)..(0909a001|83098301|c409c401)..",
    "5:KS300"     => "^810d04..4027a001",
    "6:CUL_WS"    => "^K.....",
    "7:CUL_EM"    => "^E0.................\$",
    "8:HMS"       => "^810e04....(1|5|9).a001",
    "9:CUL_FHTTK" => "^T[A-F0-9]{8}",
    "A:CUL_RFR"   => "^[0-9A-F]{4}U.",
    "B:CUL_HOERMANN"=> "^R..........",
    "C:ESA2000"   => "^S................................\$",
    "D:CUL_IR"    => "^I............",
    "E:CUL_TX"    => "^TX[A-F0-9]{10}",
    "F:Revolt"    => "^r......................\$",
    "G:IT"        => "^i......",
    "H:STACKABLE_CC"=>"^\\*",
    "I:UNIRoll"   => "^[0-9A-F]{5}(B|D|E)",
    "J:SOMFY"     => "^Y[r|t|s]:?[A-F0-9]+",
    "K:CUL_TCM97001"  => "^s[A-F0-9]+",
);


Also Nachricht mit GROSSEM S und 32 Zeichen bis Ende ist eine ESA Nachricht.
Nachrichten mit kleinem s und einer beliebigen Folge von Hex Zeichen ist eine TCM Nachricht.

Frage 1: Unterscheiden die Grep Ausdrücke die Groß/Kleinschreibung nicht?

Laut Modul Datei 14_CUL_TCM970001.pm ist der Match-Ausdruck nicht beliebig lang sonder nur Kleines s am Anfang plus 5 Bytes:

sub
CUL_TCM97001_Initialize($)
{
  my ($hash) = @_;

  $hash->{Match}     = "^s.....";


Allerdings ist hier kein Zeilenende im Match drin.

Frage 2: Wie soll 00_CUL.pm die Daten korrent weitergeben, wenn Groß/Kleinschreibung nicht berücksichtigt werden und zwei RegEx Ausdrücke passen?

Die 64_ESA2000.pm sieht so aus:

sub
ESA2000_Initialize($)
{
  my ($hash) = @_;

#                        S0119FA011E00007D6E003100000007C9 ESA2000_LED

  $hash->{Match}     = "^S................................\$";
  $hash->{DefFn}     = "ESA2000_Define";
  $hash->{UndefFn}   = "ESA2000_Undef";
  $hash->{ParseFn}   = "ESA2000_Parse";
  $hash->{AttrList}  = "IODev do_not_notify:0,1 showtime:0,1 ignore:0,1 ".
                       "model:esa2000-led,esa2000-wz,esa2000-s0,esa1000wz-ir,esa1000wz-s0,esa1000wz-led,esa1000gas base_1 base_2 ".
                       $readingFnAttributes;
}


Also GROSSES S am Anfang und 32 Zeichen bis Ende.

Ich hätte gerne eine korrekte Installation inklusive der 14_CUL_TCM970001.pm. Eventuell ist meine Umbenennung mit dem nächsten Update wieder rückgängig gemacht.

Ansonsten bin ich sehr zufrieden mit FHEM, obwohl ich noch vieles lernen muß und nicht immer verstehe.

~Josef

Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose

rudolfkoenig

ZitatUnterscheiden die Grep Ausdrücke die Groß/Kleinschreibung nicht?
Wir reden ueber Regexps, und die unterscheiden je nach Option. Im gegebenen Fall nicht (aus historischen Gruenden), siehe fhem.pl, Zeile 3169.

ZitatWie soll 00_CUL.pm die Daten korrent weitergeben, wenn Groß/Kleinschreibung nicht berücksichtigt werden und zwei RegEx Ausdrücke passen?
Das ist in der Tat ein Problem, und man muss in culfw oder 00_CUL.pm dafuer sorgen, dass die Regexps sich auch ohne klein/grossschreibung unterscheiden. Die Pruefung laeuft so ab:
- erst werden alle geladenen(!) Module gefragt, ob sie mit den Daten was anfangen koennen ($module->{Match}).
- danach wird der matchList der CUL konsultiert, welches Modul geladen werden soll. Hier wird der sortierten Reihe nach geprueft, damit sollte C:ESA2000 vor K:CUL_TCM97001 kommen.
- Falls man beide Module (ESA und TCM) verwenden will, dann hat man in der Tat ein Problem, vmtl. das Einfachste waere, wenn das TCM Modul eine Laengenbegrenzung im Regexp einfuehren wuerde.

Bei meinem Test mit den angegebenen Daten:
{ Dispatch($defs{CUL}, "SE76117011E000051660004000000002A", undef) }

hat FHEM auch ein ESAx000WZ_6117 angelegt, und kein TCM.

Ich sehe fuer diesen Fall (nur ESA, kein TCM) noch kein Handlungsbedarf, und ich verstehe nicht, wie in deinem Fall zum Problem kommen konnte, weder durch Lesen der Quellen, noch nach Experimenten. Falls es bei dir trotzdem auftritt, koennte ein Workaround sein, das TCM Modul umzubenennen, ESA anzulegen, und danach TCM wieder zurueckzubenennen. Das funktioniert aber nur solange, bis dein Geraet keine TCM Daten empfaengt.

Trotzdem waere es schoen, wenn der TCM Autor dem Regexp eine Maximallaenge geben koennte. Ich habe dem Autor hier eine Nachricht hinterlassen.

hjgode

Hallo Rudolf

danke für die Erläuterungen.

Bei mir war seit Anfang ein TCM970001 definiert (ist wohl default in der fhem.cfg bei einem frisch installierten System). Ich habe mich da nicht weiter drum gekümmert, bis jetzt.

Wahrscheinlich hat fhem die ESA Nachrichten empfangen, TCM gefunden und dahin weiter geleitet. Entsprechende Fehlermeldungen, dass TCM damit nix anfangen kann, habe ich nicht bemerkt, bzw. war de verbose-Level zu niedrig.

Nun habe ich ESA am Laufen. Habe die TCM97001.pm in TCM97001.pm.OFF umbenannt. Dann ein ESA2000 Device angelegt und fhem routet die "S...-" Nachrichten jetzt korrekt.
Mal sehen, was nach dem nächsten Update passiert. (Noch weiß ich ja wo ich eingegriffen habe)

~Josef
Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose