[LÖSUNG]
auch dem userReading TRIGGER musste ich einen Trigger geben. bzw. über {} eine 'Regel' hinterlegen dann geht es gut...
danke an alle die mir geholfen haben bzw. die Lösung hab ich in diesen Thread gefunden
https://forum.fhem.de/index.php/topic,92696.0.html
Zitat
Antw:userReadings monotonic wird nicht aktualisiert
« Antwort #6 am: Heute um 14:32:13 »
ein userreading ist wie ein notify, das aber nur auf events von seinem "herrchen" lauscht. wird es getriggert, legt es das entsprechende reading an und füllt es über die anweisung, die in den geschweiften klammern steht.
bei dir fehlen die geschweiften klammern, was wohl zum abbruch aller userreadings führt.
für einen konstanten wert wäre ein userreading die falsche wahl, da es unnötigerweise ständig ausgefürt wird.
wenn du einen festen wert zum rechnen brauchst, würde ich ein userattribut nehmem und mit AttrVal() darauf zugreifen.
Hallo Zusammen,
in den Thema userReadings bin ich noch am Anfang...
und leider funktioniert das Zeug nicht so wie ich es mir aus dem Wiki herauslese...
mein Plan ist das ich mir ein Standard Dummy Objekt erstelle....
welches über 'userattr' definiert wird...
als Beispiel würde ich gerne zwei Fenster Sensoren verknüpfen...
dafür hätte ich mir userattr angelegt welche definieren von welchen Hardwaregerät welches Reading ausgelesen werden muss das die unterschiedlichen Stati ausgewertet werden können...
attr OG_SZ_FL_MK ATTR_OPENED_DEVICE JABLOTRON_100_MQTT
attr OG_SZ_FL_MK ATTR_OPENED_READING JA100_OG_SZ_SS_WW
zusätzlich gibt es userReadings welche diese Werte erhalten sollen und über das Reading 'TRIGGER' angetriggert werden (also so zumindest die Theorie ;-) )...
OPENED:TRIGGER.* \
{\
my $VAR_OPENED_DEVICE=AttrVal("$name","ATTR_OPENED_DEVICE","check_device");; \
my $VAR_OPENED_READING=AttrVal("$name","ATTR_OPENED_READING","check_reading");; \
my $VAR_OPENED_VALUE=ReadingsVal("$VAR_OPENED_DEVICE","$VAR_OPENED_READING","check_device_reading");;\
\
$VAR_OPENED_VALUE\
}
das Reading TRIGGER wird aktuell manuel über setreading geändert
setreading OG_SZ_FL_MK TRIGGER none
so nun zu meinen Problem...
wenn ich den code bei den attr. 'stateFormat' eintrage werden die Werte korrekt von den Hardwaregeräten abgeholt...
wenn ich es nun in das userReading einfüge bleibt das Reading immer leer, bzw. wird nicht erstellt bzw. wenn ich es einmal über setreading erstelle wird der Wert nie geändert :(
was mach ich falsch?!?
DANKE für eure Unterstützung!!!!
LG.
Erwin
das ganze Dummy aus der fhem.cfg findet ihr hier...
define OG_SZ_FL_MK dummy
attr OG_SZ_FL_MK userattr floor ATTR_TRIGGER ATTR_OPENED_DEVICE ATTR_OPENED_READING ATTR_TILTED_DEVICE ATTR_TILTED_READING ATTR_CLOSED_DEVICE ATTR_CLOSED_READING ATTR_ARMED_DEVICE ATTR_ARMED_READING
attr OG_SZ_FL_MK ATTR_ARMED_DEVICE JABLOTRON_100_MQTT
attr OG_SZ_FL_MK ATTR_ARMED_READING JA100_area_3
attr OG_SZ_FL_MK ATTR_CLOSED_DEVICE JABLOTRON_100_MQTT
attr OG_SZ_FL_MK ATTR_CLOSED_READING JA100_PG12
attr OG_SZ_FL_MK ATTR_OPENED_DEVICE JABLOTRON_100_MQTT
attr OG_SZ_FL_MK ATTR_OPENED_READING JA100_OG_SZ_SS_WW
attr OG_SZ_FL_MK ATTR_TILTED_DEVICE JABLOTRON_100_MQTT
attr OG_SZ_FL_MK ATTR_TILTED_READING JA100_OG_SZ_SS_WW
attr OG_SZ_FL_MK devStateIcon READY_off_off:rc_GREEN ARMED_off_off:ewie_close ARMED_on_on:rc_RED READY_on_on:rc_RED ARMED_off_on:rc_YELLOW READY_off_on:rc_YELLOW ARMED_on_off:rc_BLUE READY_on_off:rc_BLUE
attr OG_SZ_FL_MK event-on-change-reading TRIGGER
attr OG_SZ_FL_MK event-on-update-reading TRIGGER
attr OG_SZ_FL_MK stateFormat {ReadingsVal("$name","ARMED","check_device_reading"). "_" .ReadingsVal("$name","OPENED","check_device_reading"). "_" .ReadingsVal("$name","TILTED","check_device_reading")}
attr OG_SZ_FL_MK userReadings TRIGGER,\
\
ARMED:TRIGGER.*\
{\
my $VAR_ARMED_DEVICE=AttrVal("$name","ATTR_ARMED_DEVICE","check_device");; \
my $VAR_ARMED_READING=AttrVal("$name","ATTR_ARMED_READING","check_reading");; \
my $VAR_ARMED_VALUE=ReadingsVal("$VAR_ARMED_DEVICE","$VAR_ARMED_READING","check_device_reading");;\
\
$VAR_ARMED_VALUE\
},\
\
OPENED:TRIGGER.* \
{\
my $VAR_OPENED_DEVICE=AttrVal("$name","ATTR_OPENED_DEVICE","check_device");; \
my $VAR_OPENED_READING=AttrVal("$name","ATTR_OPENED_READING","check_reading");; \
my $VAR_OPENED_VALUE=ReadingsVal("$VAR_OPENED_DEVICE","$VAR_OPENED_READING","check_device_reading");;\
\
$VAR_OPENED_VALUE\
},\
\
\
TILTED:TRIGGER.* \
{\
my $VAR_TILTED_DEVICE=AttrVal("$name","ATTR_TILTED_DEVICE","check_device");; \
my $VAR_TILTED_READING=AttrVal("$name","ATTR_TILTED_READING","check_reading");; \
my $VAR_TILTED_VALUE=ReadingsVal("$VAR_TILTED_DEVICE","$VAR_TILTED_READING","check_device_reading");;\
\
$VAR_TILTED_VALUE\
}
Klingt danach, als solltest du dir structure mal ansehen.
Ansonsten werden userReadings nur aktualisiert, wenn sich irgendein Reading des Devices ändert, zu dem es gehört, nicht irgendwelcher anderen.
Hallo,
DANKE für deine Rasche Anwort
structure hab ich mir schon angeschaut...
aber entweder etwas über sehen oder falsch verstanden...
Sensor A, Sensor B bzw. Sensor C liefern alle on und off...
Sensor A bedeutet gekippt
Sensor B bedeutet geöffnet
Sensor C bedeutet Bereich gesichert
bezüglich userReadings...
diese sollte ja über 'OPENED:TRIGGER.*' auf das userReading TRIGGER reagieren welches in diesen Dummy angelegt ist...
bzw. über den Befehl
setreading OG_SZ_FL_MK TRIGGER none
geändert wird und über diese Attr sollte auch das Event ausgelöst werden?
attr OG_SZ_FL_MK event-on-change-reading TRIGGER
attr OG_SZ_FL_MK event-on-update-reading TRIGGER
oder liege ich da bei meiner vermutung falsch?!
LG.
Erwin
OK, sorry, die Zusammenhänge zwischen diesen Sensoren hatte ich wohl missverstanden.
Da alle relevanten infos aus einem MQTT-Device zu kommen scheinen: ist da noch mehr? Kann man das ggf. in 2 oder mehr Devices splitten?
Dann würde ich zusammen lassen, was zusammen gehört und daraus ein userReading (oder gleich, ggf. mit einer myUtils-Routine ein stateFormat) basteln. Ohne dummy.
das mit der myUtils-Routine muss ich mir anschauen sagt mir aktuell nichts..
zu erklärung wieso ich auf ein Dummy Objekt gekommen bin...
in der Arbeitprogrammiere ich in einer Objekt orientiert umgebung...
also jedes objekt was ich dort angreife ist anschließend im Stromlaufplan ein Gerät mit unterschiedlichen Attributen...
also auf FHEM heruntergebrochen war das für mich 1 Dummy Objekt dieses Objekt ist ein Fenster mit den 3 Sensoren / Stati...
es kann auch sein das der zweite Sensor von einen anderen Device kommt (z.B 433MHz oder Homematic)
das ganze soll dann auch im Floorplan platziert weden so das ich hier den Status erkenne welches Fenster welchen Status hat, somit ist es mit aufteilen auf mehrere nicht möglich...
das Problem was ich bei den JA100 Reading noch habe ist, das diese nur einen sauberen OPEN Befehl senden... der CLOSE ist auf der RS485 Schnittstelle nicht sauber...
also ich kann den close Befehl nicht zuweisen... deswegen müsste der 'gekippt' Sensor bzw. der closed 'Sensor' den Status des open Sensors auf off zurücksetzten...
deswegen der zwischen Schritt noch über das userReading...
aktuell nutz ich für das ganze x notify die immer den Status wechseln...
LG.
So ganz komme ich nicht mit.
Mein Vorschlag lief schon darauf hinaus, am Ende ein Objekt pro Fenster zu haben; nur dass es eben kein Dummy wäre, sondern ein MQTT-Device. Allerdings lassen sich damit nicht unterschiedliche Quellen mischen. Das geht wirklich nur über echte Eventhandler wie notify.
Vielleicht schaust du dir mal im wiki den myUtils-Artikel an. Hier könnte ein Beispiel sein, wie man sowas etwas generalisiert, ohne zu viele notify verwalten zu müssen: https://forum.fhem.de/index.php/topic,36504.0.html
Nachbrenner: wenn du einen einfachen Weg suchst, ein einzelnes (user-) Reading als Objekt zu haben: readingsProxy
Und Workarounds für unzuverlässige Datenübertragung sind immer nur die zweitbeste Lösung. Gerade wenn eskabelgebundene Kommunikation ist, sollte das auch zuverlässiger möglich sein.
DANKE für die Info...
die Datenübertragung ist fehlerfrei...
das Problem ist das die Information nicht gesendet wird...
es wird nur ein alles geschlossen gesendet... (leider :( )
OPEN Information via RS485 Fenster A -> 001000000000 // Fenster B -> 000000040000 // usw.
CLOSE Information via RS485 Fenster A -> 000000000000 // Fenster B -> 000000000000 // usw.
Problem mit dem Trigger hab ich aber bereits gelöst. [siehe ersten Post]..
funktioniert jetzt alles wie gewünscht...
DANKE noch mal für deine Hilfe!!! :)
readingsProxy und myUtils bin ich grade am begutachten...
man kann ja immerhin alles optimieren verbessern bzw. überdenken :)
LG.
Erwin