(gelöst)STATE vs state

Begonnen von riker1, 02 Dezember 2017, 08:32:50

Vorheriges Thema - Nächstes Thema

riker1

Hallo

dachte ich hätte verstanden, dass STATE und state nicht das gleiche sind.


in einem Thread stand. :d.h. du bekommst mit VALUE immer STATE aus dem vorherigen trigger. nicht dem aktuellen.

wenn ich jetzt testweise mal vergleich.

ReadingsVal("$NAME","state","") != Value("$NAME")}

Dies mache ich in einem Notify der jeden state wechsel abfragt.

defmod N_HM_1DCC51_STATE_DIFF notify HM_1DCC51:* .....

ist mein Ergebnis , dass die Werte immer gleich sind.

Wo ist denn mein Denkfehler?



Danke

FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

zap

state ist ein Reading, STATE ein Internal. Wenn man das Reading state aktualisiert, aktualisiert FHEM das Internal STATE automatisch mit diesem Wert.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

riker1

Hallo
wie würde ich denn an den state des vorherigen Triffers kommen?
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

marvin78

STATE kannst du als User verändern mit stateFormat.

Laut commandref bekommst du den vorherigen STATE mit OldValue(). Das ist jedoch gerade bei Homematic nicht ganz trivial, das es Zwischenstates gibt. Am besten machst du dir ein Userreading.

riker1

Hallo Marvin,

danke, das mit den Zwischen Status habe ich bemerkt....

hatte im Forum über userreadings so einiges gelesen, dass die dann für alle gelten und nicht device-spezifisch.

Muss mich mal einlesen. Danke für die Tipp.

Schönes WE

FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Benni

#5
Zitat von: riker1 am 02 Dezember 2017, 12:27:10
hatte im Forum über userreadings so einiges gelesen, dass die dann für alle gelten und nicht device-spezifisch.

nicht verwechseln:


  • Es gibt userattr (Benutzerdefinierte Attribute), die können sowohl nur für einzelne Devices am jeweiligen Device direkt definiert werden, oder aber auch über das global-Device für alle (!) Devices.
  • Es gibt userReadings, die müssen immer am jeweiligen Device direkt definiert werden und werden i.d.R. aufgrund eines Triggers durch ein anderes Reading (o. Event) des Devices gesetzt.
  • Und dann gibt es noch setreading. Damit kann man selbst für einzelne (oder auch mehrere, je nach devspec ) Devices Readings beliebig erzeugen, bzw. verändern.

Übrigens: Mit stateFormat kann man selbst bestimmen was im Device-Internal STATE angezeigt werden soll. Dieses Attribut ist auch Device-spezifisch. Ist das Attribut nicht gesetzt, dann wird bei den meisten Geräten in STATE der Wert des Readings state angezeigt. Es kann daher natürlich schon sein, dass wenn man ein notify auf das state-Reading (state-Event) eines Devices setzt und darin dann den Wert des Internals STATE (per VALUE() ) abfragt, quasi den "alten" Wert von state bekommt, da das Ereignis für state vor dem Neusetzen von STATE auftritt und das notify auch davor abgearbeitet wird.

Wie oben schon gesagt, ist das aber nicht wirklich sinnvoll, wenn es bspw. um HM-Geräte geht, da es hier noch so Zwischenstatus gibt wie 'set_on' oder 'set_off'.

Ich denke, hier macht vor allem die Verwendung von setreading Sinn. Damit kannst du dir den alten Wert genau dann wegspeichern, wann du es möchtest.

Zitat von: riker1 am 02 Dezember 2017, 12:27:10
Muss mich mal einlesen. Danke für die Tipp.

Gut erkannt! ;)
Einige Links habe ich dir ja oben geliefert.

gb#