[Patch] - 10_FS20.pm - Housecode

Begonnen von HomeAuto_User, 20 Februar 2018, 21:26:29

Vorheriges Thema - Nächstes Thema

HomeAuto_User

Hallo,

bitte folgenden Patch einpflegen.
Mit dieser Änderung werden via SIGNALduino alle Housecode´s verarbeitet.

Ohne diesen Patch werden manche Housecode´s nicht angelegt.

PS: Die Änderung fürs senden via SIGNALduino folgt später.  ;)
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

rudolfkoenig

Alternativ schickt SIGNALduino die Werte mit lc().
Vorteil: ich muss nicht Angst haben, dass einer der 1000+ Installationen mit FS20 deswegen warum auch immer ein Problem kriegt.

elektron-bbs

Wärest du denn prinzipiell bereit, eine Erweiterung des Moduls zum Senden über den SIGNALduino einzubauen?

Es ginge dabei nur um eine Ergänzung in der sub "FS20_Set" in folgender Art:


  my $io = $hash->{IODev};
  if ($io->{TYPE} eq "SIGNALduino") {   # das IODev ist ein SIGNALduino
... Umwandlung Sendedaten für SIGNALduino ...
    IOWrite($hash, 'sendMsg', $newmsg); # send SIGNALduino
  } else {                                 # das IODev ist kein SIGNALduino
    IOWrite($hash, "04", "010101" . $hash->{XMIT} . $hash->{BTN} . $c);     # send CUL
  }


Test läuft hier mit einem CUL und einem SIGNALduino bereits seit ca. 1/4 Jahr problemlos.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

rudolfkoenig

Waere der Aufwand der Umwandlung vom FHZ-Format in SignalDuino deutlich aufwendiger, als im 10_FS20.pm?

CUL muss diese Umwandlung genauso machen, und es waere nicht logisch, die Umwandlung in einigen Faellen im logischen Modul, in anderen Fellen im physikalischen Modul zu machen.

elektron-bbs

Ja, der Aufwand wäre höher. Eine Möglichkeit wäre noch, ein zweites FS20-Modul für SIGNALduino bereitzustellen, aber das halte ich eigentlich für übertrieben, da es bis auf ca. 30 Zeilen Code identisch zu deinem Modul wäre.

Was den ursprünglichen Patch angeht: Es zieht sich durch den gesamten Code der 00_CUL.pm und 10_FS20.pm, das Hex-Ausgaben in lower case gewandelt werden, warum dann logischerweise nicht auch in der FS20_Parse?
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

Ralf9

#5
ZitatWaere der Aufwand der Umwandlung vom FHZ-Format in SignalDuino deutlich aufwendiger, als im 10_FS20.pm?
In der 00_SIGNALduino.pm müssten wir für die ID 74 (FS20) beim dispatch eine Sonderbehandlung einbauen:
$dmsg = lc($dmsg) if ($id eq '74');
Log3 $name, SDUINO_DISPATCH_VERBOSE, "$name Dispatch: $dmsg, $rssi dispatch";
Dispatch($hash, $dmsg, \%addvals);  ## Dispatch to other Modules



Beim Parse im FS20-Modul wäre die folgende Anpassung notwendig:
  my $dev = lc(substr($msg, 16, 4));
  my $btn = lc(substr($msg, 20, 2));
  my $cde = lc(substr($msg, 24, 2));


Ich würde es besser und sauberer finden, wenn die Anpassung beim Parse im FS20-Modul gemacht würde.
Dies würde auch das Parse im FS20-Modul etwas robuster machen.
Da ich anfänglich bei mir das "lc" noch nicht drin hatte, kam es bei mir beim Testen zu seltsamen Effekten und Fehlern. Das FS20 device wurde per autocreate 2 mal angelegt. Einmal mit Grossbuchstaben und einmal mit Kleinbuchstaben.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rudolfkoenig

Wie du es so schoen demonstriert hast, gibt es keinen nennenswerten Unterschied zwischen den beiden Loesungen, beide sind im Prinzip Einzeiler. Ob die Umstellung im physikalischen oder logischen Modul besser untergebracht ist, darueber laesst sich streiten, ich habe aber aus einem anderen Grund Bedenken FS20.pm zu aendern: meiner Erfahrung nach kriegt man bei alten Modulen selbst mit eine Bugfix Aerger, weil die Leute sich darauf eingestellt haben. Deswegen bitte ich dich, die Anpassung im Signalduino durchzufuehren.

Sidey

Hi Rudi,

es sind zwei Anpassungen in FS20 notwendig.

$hash->{Match}     = "^81..(04|0[cC])..0101[aA]001";

und

my ($hash, lc($msg)) = @_


Klar kann man das jetzt auch im Physischen Modul nachbehandeln. Aber ich finde der Code des physischen Modules wird schwer wartbar, wenn dort Umwandlungen genau für ein logisches Modul eingebaut werden.

Da es bei Hexadezimalwerten keinen Unterschied der Wertigkeit zwischen groß und Kleinschreibung gibt würde ich dich bitten das in das FS20 Modul einzubauen.
Wenn es in FHEM ein Standard wäre, alle hex Werte immer in Kleinbuchstaben zu übergeben würde ich es ja verstehen, dass man so etwas in das physische Modul einbaut, mir ist so etwas aber nicht bekannt.


Mir ist natürlich bewusst, dass jede Änderung zu einem Fehler führen könnte, aber die Wahrscheinlichkeit ist wohl sehr gering, dass es zu einem Fehler kommt, denn die Werte die heute an das Modul übergeben werden können funktionieren weiterhin.

Im Sinne der Wartbarkeit ist die Lösung in FS20 aber Zukunftssicherer finde ich.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

Ich habe deine Argumente gehoert, und auch vorher verstanden.
Fuer mich, als FS20 Maintainer, ist Risiko/Gewinn Verhaeltnis zu gross.