Autor Thema: DevIo überschreibt STATE und state auch wenn stateFormat gesetzt ist  (Gelesen 921 mal)

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1646
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24164
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.

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1646
Ich hatte leider vermutet, dass sich das schon weit verbreitet hatte. Ich schau mal, wie man das koordiniert bekommt.

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1646
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?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24164
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.

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1646
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?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24164
Zitat
Kannst du mir noch eine Einschätzung zu meiner letzten Frage zu DevIO_IsOpen() und dem konkreten Code-Beispiel geben?
Habs doch geschrieben:
Zitat
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.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24164
Zitat
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.

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.

Offline Stromzähler

  • New Member
  • *
  • Beiträge: 24
    • Wusstest Du schon, dass man das so schreibt?
Sorry, wenn ich mich hier einmische. Da es z.B. schon ein "devioLoglevel" gibt, fände ich "devioNoStateChange" irgendwie konsistenter ;)
« Letzte Änderung: 07 Juni 2021, 18:18:38 von Stromzähler »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24164
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.

Offline Stromzähler

  • New Member
  • *
  • Beiträge: 24
    • Wusstest Du schon, dass man das so schreibt?
Passt. Da war ich dann wohl nicht ganz aktuell  :)

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1252
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.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24164
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.

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1252
Hallo Rudolf,

danke!

Gruß, Ansgar.

 

decade-submarginal