Unterschiedlicher Inhalt des STATE bei "alter" und "neuer" Version

Begonnen von Reinerlein, 19 Januar 2013, 13:28:27

Vorheriges Thema - Nächstes Thema

Reinerlein

Hallo zusammen,

ich habe ein Modul für die Steuerung meines Sonos-Systems (Multiroommusiksystem) geschrieben.

Dort wird mein STATE von einem Hintergrundprozess mit dem gerade laufenden Liedtitel aktualisiert.

Nun habe ich auf meinem Entwicklungsserver mal ein SVN-Update durchgeführt (Stand war vorher 28.12.2012), und seitdem ein anderes Verhalten auf der Oberfläche bemerkt:

Ich habe in der Übersicht Steuerungsschalter (per WebCmd), die ein Set auslösen, und z.B. zum nächsten Lied wechseln oder die Lautstärke verändern.

Nun kommen unterschiedliche Verhaltensweisen von vorher und nachher zum Tragen:
Alte Version: Mein Set-Befehl liefert undef zurück, der State bleibt wie vorher (enthält also den aktuellen Titel) -> Erwartungsgemäß OK
Neue Version: Mein Set liefert immer noch undef. STATE wird nun aber auf den String meiner Set-Anweisung (z.B. VolumeD) geändert -> Das ist unerwartet und nicht so schön

Hat dieses neue Verhalten einen besonderen Grund, oder ist das ein Bug, der sich eingeschlichen hat?

Grüße Reinerlein

rudolfkoenig

STATE direkt zu aendern ist inzwischen politisch nicht mehr korrekt. Versuch es bitte mit  readingsSingleUpdate($hash, "state", "value"), dann sollte set STATE auch nicht mehr aendern.

Damit wird das Reading state das vom Modulauthor vorgeschlagene Vorlage fuer STATE (globaler Status), der Benutzer kann es aber mit stateFormat ueberschreiben.

Reinerlein

Hi Rudi,

naja, wenn ich den state ändere, tue ich das in einem Bulk:
readingsBulkUpdate($hash, 'state', 'Informationen');
das sollte ja im großen und ganzen identisch zu dem Sigle-Teil sein. Natürlich gibt es auch ein Start und End dazu...

Nur soll nach einem Aufruf z.B. des Setter "VolumeD" gar nichts am State verändert werden, was mein Code auch gar nicht tut. Das passiert durch einen anderen Einfluß ausserhalb meines Codes...
Und ja, ich habe auch ein Reading "state" (kleingeschrieben). Auch dieses wird mit z.B. "VolumeD" gesetzt.

Wenn ich einen String im Setter zurückgebe. z.B. "Success" wird nichts am State angefasst, nur wenn ich undef zurückgebe.

Grüße Reinerlein

rudolfkoenig

readingsEndUpdate muss mit $dotrigger=1 aufgerufen werden. Falls keine events generiert werden sollten, dann kann man das im vierten Parameter von readingsBulkUpdate so bestimmen.

Reinerlein

Hi Rudi,

aber es geht doch nicht um meine Aktualisierungen des State. Das funktioniert super.

Es geht darum, das ich genau nichts am State verändere, und in diesem Augenblick auch gar nicht verändern möchte.
Wenn ein Set-Befehl als Ergebnis regulär den State ändern müsste, dann passiert das bei mir grundsätzlich indirekt über ein Callback durch den Player. Manche Anweisungen an den Player resultieren in keiner (indirekten) State-Änderung...

Es geht darum, das ein Set von mir genau nichts am State ändert, und jetzt neu (irgendwann seit dem 28.12 halt) der State durch die Ausführung des Set auf den Namen des Set geändert wird. Vorher blieb der State einfach unangetastet...

Grüße Reinerlein

Markus Bloch

Dieses Phänomen habe ich ebenfalls beobachtet.

Man führt ein Set aus, dessen Funktionsinhalt allerdings keinerlei Änderungen am state-Reading oder direkt in STATE durchführen. Dennoch wird der State auf den Namen des Befehls geändert, welcher gerade mit Set aufgerufen wurde, obwohl das vom Modulautor nicht beabsichtigt ist.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

rudolfkoenig

Ich versuche es deutlicher zu formulieren:

seit Einfuehrung von stateFormat wird STATE (das von list und FHEMWEB angezeigte Status) auf das Argument des sets gesetzt, _es sei denn_ das aufgerufene SetFn des Moduls erzeugt selbst irgendwelche events mit den readings* Funktionen.

Mein vorheriger Vorschlag in dieser Diskussion, wie man events komplett vermeiden soll, funktioniert leider nicht.

D.h. wenn ein Modul nach einem set keine Aenderung von STATE wuenscht, dann muss es selbst irgendein event generieren, dieser kann, muss aber nicht state sein.

STATE direkt sollte man in einem Modul nicht setzten, das uebernimmt readingsEndUpdate.
Der Autor bzw. das Modul macht einen Vorschlag, indem man das "state" Reading setzt. Falls der Benutzer kein stateFormat gesetzt hat, dann wird das nach STATE uebernommen.

Reinerlein

Hi Rudi,

das war deutlich :-)
Jetzt habe ich den Zusammenhang verstanden, das ging aus den vorhergehenden Beiträgen, zumindest mit meinem Wissen, nicht direkt hervor.

Jetzt habe ich für mich das Problem gelöst. Da bei mir jedes "set" und "get" in einem Reading als "letzter Vorgang und sein Ergebnis" abgelegt wird, habe ich daraus einfach ein Event generieren lassen (bislang fand ich das nicht notwendig :-)

Für mich ist das Thema damit lösbar/gelöst, da ich bei mir ja der Modulautor bin.
Dann sollte Markus sein Phänomen vielleicht an den entsprechenden Modulautor formulieren...

Grüße Reinerlein

Markus Bloch

Wenns mir wieder vor die Nase kommt, mach ich das ;-)

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)