FHEM Forum

Ich setze stateFormat mit Perl ein.

Wenn ich jetzt fogenden Code in 99_myUtils.pm schreibe

sub jkGefrierschrank($) {
my ($geraet) = @_;
return "$geraet ist eiskalt";
}


... und in dann im Device nutze:
attr Gefrierschrank1 stateFormat { jkGefrierschrank("$name") }

... steht beim Device korrekt:
Gefrierschrank1 ist eiskalt

soweit so gut.

Ändere ich jetzt etwas in dem Perlcode, ersetze z.B. eiskalt durch bitterkalt ...

sub jkGefrierschrank($) {
my ($geraet) = @_;
return "$geraet ist bitterkalt";
}


... wird das in der Anzeige des Devices nicht geändert ... da steht noch immer

Gefrierschrank1 ist eiskalt

und nicht
Gefrierschrank1 ist bitterkalt

Was ich erfolglos probiert habe:

• Module reloaden
• Konfiguration neu einlesen
• fhem neu starten
• trigger Gefrierschrank1

Das einzige was geholfen hat:
Das Attribut "stateFormat" im Device zum Bearbeiten aufrufen und ohne Änderung speichern.

Jetzt steht oben beim Device richtig:
Gefrierschrank1 ist bitterkalt

Was ist  der korrekte Weg, um nach Perl-Code-Änderungen eine korrekte stateFormat-Anzeige zu erhalten?
Sieht jemand meinen/e Denkfehler? Und kann mir ein paar Anstöße geben, um Fhem noch besser zu verstehen?

Es muss einfach nur (irgendein) Reading an dem betreffenden Device aktualisiert werden; der stateFormat-Code wird am Ende jeder Reading-Aktualisierungsschleife ausgeführt.

Zitat von: Beta-User am 03 Dezember 2020, 12:58:24
Es muss einfach nur (irgendein) Reading an dem betreffenden Device aktualisiert werden; der stateFormat-Code wird am Ende jeder Reading-Aktualisierungsschleife ausgeführt.

Ein bißchen habe ich das befürchtet. Bei meinem Device kommen aber nur wenige und selten Readings an. Kann ich das stateFormat auch anders anstoßen?

Ich wüßte im Moment weder wie, noch wieso.

Evtl. fällt jemand was ein, wenn du den use-case etwas näher erläuterst.

hilft ein browser refresh?

Zitat von: frank am 03 Dezember 2020, 13:18:19
hilft ein browser refresh?

Vermutlich nicht. evalStateFormat() wird eigentlich nur innerhalb des initialen Setzen des Attributs (https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L3068) und eben gegen Ende von readingsEndUpdate() aufgerufen.

Aber wie angedeutet: ich verstehe nicht wirklich, für was man sowas braucht, für mich ist die Frage "von hinten durch ..."-verdächtig, aber vermutlich übersehe ich mal wieder was...

ZitatAber wie angedeutet: ich verstehe nicht wirklich, für was man sowas braucht, für mich ist die Frage "von hinten durch ..."-verdächtig, aber vermutlich übersehe ich mal wieder was...

ich bin auch schon neugierig!  8)

Zitat von: frank am 03 Dezember 2020, 13:18:19
hilft ein browser refresh?

War auch erfolglos ... auch Browser-Cache löschen.

Zum Usecase:
Der Temperatursensor des Gefrierschranks sendet alle 2 Stunden einen Temperaturwert. Also kommt nur alle 2 Stunden ein Reading an. Wenn ich zwischenzeitliche an meinem Perl-Code bastle und die stateFormat Ausgabe verändere, will ich nicht 2h warten, bis sich die Anzeige im Device aktualisiert.

Und ja: das Basteln am Perlcode kommt natürlich nicht häufig vor. Wenn man aber dabei ist, will man doch sofort die Ausgabe prüfen ... bzw. würde gerne ...

...dann wirf es doch direkt in die Kommandozeile:

{ jkGefrierschrank("Gefrierschrank1") }
PS: in stateFormat-Code kannst du die Quotes um das $name weglassen. Dann sieht man auch besser, dass es ein Parameter ist...

PPS: Falls du eigentlich farbige Aufgabe als devStateIcon haben willst (dunkelblau=eiskalt etc. ...): Schau mal nach pah-Color im wiki zu Color (aber nutze es nicht in stateFormat, sondern in devStateIcon, bitte).

Eins noch:

Ich hätte gerne dass wenn sich im Device Thermometer die temperature ändert sich automatisch auch die "Grad"zahl im Device Gefrierschrank ändert:

Zitat
DEVICE           reading                      attribut
----------------------------------------------------------------------------------------
Thermometer   temperature                -
Gefrierschrank  Grad                          userReadings Grad { ReadingsVal("Thermometer","temperature",0) }
                        dummyreading

Mein Gefrierschrank hat keine eigenen readings. Über userReadings soll er sich aber die aktuelle Temperatur vom Thermometer holen.

Behelfsmäßig habe ich beim Gefrierschrank ein dummyreading eingefügt und kann das per notify setreading Gefrierschrank dummyreading 9999
anstoßen. Schön finde ich das nicht. Aber ich nehme an, für userReadings gilt genau das Gleiche wie für stateFormat:
Das Device muss angestoßen werden, sonst reagiert sein "userReading" nicht.

Zitat von: Beta-User am 03 Dezember 2020, 13:26:20
für mich ist die Frage "von hinten durch ..."-verdächtig, aber vermutlich übersehe ich mal wieder was...

qed...

Und via userReadings auf "fremde" Devices hören geht auch nicht.

Schau dir mal readingsProxy (https://fhem.de/commandref_modular.html#readingsProxy) an, das müßte zumindest einen Teil der Aufgabenstellung erledigen können, wenn ich die wenigen Bruchstücke jetzt korrekt sortiert habe.

(Aber trotzdem bleibt dieses Informationsgeschubse "strange". Warum heißt nicht gleich das Thermometer "Gefrierschrank"? Warum soll alles mögliche in ein anderes Device? Zu Anzeigezwecken wäre dann z.B. ReadingsGroup m.E. einfacher... Fragen über Fragen...)

Zitat von: Beta-User am 03 Dezember 2020, 16:32:22
(Aber trotzdem bleibt dieses Informationsgeschubse "strange". Warum heißt nicht gleich das Thermometer "Gefrierschrank"? Warum soll alles mögliche in ein anderes Device? Zu Anzeigezwecken wäre dann z.B. ReadingsGroup m.E. einfacher... Fragen über Fragen...)

Das Thermometer heißt nicht "Gefrierschrank", weil ich eine ganze Reihe von Thermometern für die unterschiedlichsten Vorgänge habe, die ich je nach Wunsch gemeinsam über strukturierte Namen anspechen will. Außerdem habe ich auch noch eine WLAN-Steckdose, mit der ich den Stromverbrauch für den Gefrierschrank messe ... und ich kann ja nicht alles Gefrierschrank nennen :)

Aber ich verstehe schon, dass das Geschubse stange ist. Im Grunde kann ich die Daten ja jederzeit wieder da abfragen, wo sie angefallen sind (z.B. dem Thermometer). So liegen sie nicht redundant herum.

Mein dummy-Device "Gefrierschrank" werde ich aber beibehalten, um dort z.B. als Attribut zu speichern, wann er zuletzt abgetaut wurde oder welches meiner Device der Thermostat und welches die WLAN-Steckdose ist ... falls ich die mal tausche.

"ReadingGroups" kenne ich noch nicht.

Ok, dann wird das etwas klarer.

Neben readingsGroup würde ich dann noch folgende Stichworte zum Austesten in den Raum werfen:

- "setreading" => einfach beim "Hauptschalter" (der Steckdose?) die betreffenden Readings zum Abtauen, ... mit abspeichern (alternativ: comment-Attribut oder eben userAttr+eigenes Attribut, wie du das scheinbar bisher gemacht hast...). Aber den Dummy nur wegen der Attribute bzw. eigenen Infos...? MAn. unnötig.
- Wenn man in FHEMWEB Dinge strukturieren will, gibt's dafür z.B. auch "group"
- Über "alias" kann man Dinge schon gleich nennen, aber ob das sinnvoll ist, ist wieder eine andere Frage (in verschiedenen Räumen soll das angeblich hilfreich sein, weil man dann einfach sagen kann: "Mach das Licht im ...zimmer an"...)