DevIo überschreibt STATE und state auch wenn stateFormat gesetzt ist

Begonnen von Christoph Morrison, 08 Mai 2021, 16:45:19

Vorheriges Thema - Nächstes Thema

Christoph Morrison

Hallo Rudolf,

in Bezugnahme auf https://forum.fhem.de/index.php/topic,119383.msg1138066.html wollte ich mal fragen, ob du DevIo dahingehend ändern könntest, dass weder STATE noch state im nutzenden Device hart von DevIo geändert/aktualisiert werden? Ist schon nervig, wenn man stateFormat in einem Device gesetzt hat, dann ein reconnect passiert und damit der formatierte State überschrieben ist.

Möglicherweise könnte DevIo ja stattdessen in ein Reading DevIo_connection_state o.ä. schreiben, damit man trotzdem auf Änderungen reagieren kann.

Danke
CM

rudolfkoenig

Der Haken an einer Aenderung ist, dass etliche Module im ReadyFn an state bzw STATE feststellen, dass sie was tun muessen.
Diese waeren danach kaputt:
> egrep -l 'STATE.*eq.*disconnected' *.pm | wc
     44      44     589
> egrep -l 'state.*eq.*disconnected' *.pm | wc
     15      15     225

Es gibt weitere Module, die STATE auf disconnected setzen, diese waeren zusaetzlich untersuchen.
Ich bin bereit, alle meine Module auf state zu beschraenken, es bleibt aber noch jede Menge zu koordinieren.

Christoph Morrison

Ich hatte leider vermutet, dass sich das schon weit verbreitet hatte. Ich schau mal, wie man das koordiniert bekommt.

Christoph Morrison

Ergibt die Prüfung auf DevIo_IsOpen() eigentlich das gleiche Ergebnis wie $hash->{STATE} ne disconnected?
Könnte man solche Konstrukte wie

  if ($hash->{STATE} eq 'disconnected') {
    $hash->{DevState} = 'disconnected';
    return DevIo_OpenDev($hash, 1, \&SIGNALduino_DoInit, \&SIGNALduino_Connect)
  }


auch damit ersetzen?

rudolfkoenig

DevIo_IsOpen prueft, ob ein Socket / USB / etc Hash-Eintrag existiert.
disconnected wird gesetzt, wenn eine Verbindung icht hergestellt werden kann oder zusammenbricht.

Theoretisch sollten die beiden Pruefungen das gleiche Ergebnis liefern, ob das immer der Fall ist, kann ich nicht sicher sagen. Bin aber bereit (falls noetig) Unterschiede zu eliminieren.

Vorschlag: wenn ein Modul den "noDevIoStateChange" hash Eintrag auf 1 setzt, dann wird DevIo auf das Setzen von state/STATE verzichten. Damit koennte eine Umstellung ohne Kompatibiltaetsprobleme erfolgen.

Christoph Morrison

Zitat von: rudolfkoenig am 18 Mai 2021, 11:13:36
Vorschlag: wenn ein Modul den "noDevIoStateChange" hash Eintrag auf 1 setzt, dann wird DevIo auf das Setzen von state/STATE verzichten. Damit koennte eine Umstellung ohne Kompatibiltaetsprobleme erfolgen.

Die Idee finde ich schon mal gut. Kannst du mir noch eine Einschätzung zu meiner letzten Frage zu DevIO_IsOpen() und dem konkreten Code-Beispiel geben?

rudolfkoenig

ZitatKannst du mir noch eine Einschätzung zu meiner letzten Frage zu DevIO_IsOpen() und dem konkreten Code-Beispiel geben?
Habs doch geschrieben:
ZitatTheoretisch sollten die beiden Pruefungen das gleiche Ergebnis liefern, ob das immer der Fall ist, kann ich nicht sicher sagen. Bin aber bereit (falls noetig) Unterschiede zu eliminieren.

rudolfkoenig

ZitatVorschlag: wenn ein Modul den "noDevIoStateChange" hash Eintrag auf 1 setzt, dann wird DevIo auf das Setzen von state/STATE verzichten. Damit koennte eine Umstellung ohne Kompatibiltaetsprobleme erfolgen.

Ich habe den Eintrag noDevIoSTATE genannt, und es bewirkt, dass STATE nicht direkt, sondern via evalStateFormat() gesetzt wird. Das state Reading bleibt unveraendert. Wenn ein Modul $hash->{noDevIoSTATE} setzt, dann sichert es zu, dass es STATE nicht direkt abfragt, sondern die DevIo_getState() Funktion verwendet.

Ich habe meine IO-Module (CUL, ZWDongle, MQTT2_CLIENT, FBAHA) aktualisiert. Falls keine Beschwerden gibt, dann werde ich die (wenigen) Anweisungen fuer die Umstellung der Module im Developer Bereich beschreiben.

Fakenius

#8
Sorry, wenn ich mich hier einmische. Da es z.B. schon ein "devioLoglevel" gibt, fände ich "devioNoStateChange" irgendwie konsistenter ;)
FS20, Homematic (RaspberryMatic), Zigbee (deCONZ), LaCrosse, selbstgebaute Sensoren und Aktoren via MQTT
 (CUL, HB-RF-USB-2, Jeelink, SIGNALDuino)

rudolfkoenig

Danke fuer die Einmischung: ich habe die Variable auf devioNoSTATE geaendert.

Das Wort Change waere irrefuehrend: STATE wird weiterhin geaendert, aber das Modul darf nicht auf STATE pruefen, weil der Benutzer es mit stateFormat ueberschreiben kann.

Fakenius

FS20, Homematic (RaspberryMatic), Zigbee (deCONZ), LaCrosse, selbstgebaute Sensoren und Aktoren via MQTT
 (CUL, HB-RF-USB-2, Jeelink, SIGNALDuino)

noansi

Hallo Rudolf,

zu
sub
DevIo_getState($)
{
  my ($hash) = @_;
  return ReadingsVal($hash->{NAME}, "state", "")
}

wäre es nicht besser, "disconnected" als default für DevIo_getState zurück zu liefern, wenn state nicht gesetzt ist?

Gruß, Ansgar.

rudolfkoenig

Ich glaube es ist irrelevant, ReadyFn wird vermutlich erst aufgerufen, wenn dieser Wert bereits gesetzt ist.

Meine Module hatten bei der gleichen Pruefung bisher den Leerstring als default gehabt, deswegen habe ich das uebernommen.
Ich sehe gerade, das CUL_HM und andere Module disconnected als Voreinstellung haben. Da ich nach einer Aenderung eher Probleme bei mir haben will, als bei anderen Modulen, habe ich die Voreinstellung jetzt geaendert.

noansi