Hauptmenü

Device Readings ändern?

Begonnen von Konfusius, 20 Januar 2021, 12:10:56

Vorheriges Thema - Nächstes Thema

Konfusius

#15
Das hatte ich so schon vorgestern und gestern probiert. Keine Reaktion.

2021.01.24 12:36:14 3 : ESPEasy ESP_RGB: set ESP_RGB pct 73
2021-01-24 12:36:14 ESPEasy ESP_RGB pct 73
2021-01-24 12:36:14 ESPEasy ESP_RGB ct: 2500
2021-01-24 12:36:14 ESPEasy ESP_RGB pct: 73
2021-01-24 12:36:14 ESPEasy ESP_RGB colormode: ct
2021-01-24 12:36:14 ESPEasy ESP_RGB onOff: on
2021-01-24 12:36:14 ESPEasy ESP_RGB rgb: 0000ff
2021-01-24 12:36:14 ESPEasy ESP_RGB col: ct ct: 2500 onO: on pct: 73 rgb: 0000ff
2021.01.24 12:36:15 3 : ESPEasy ESP_RGB: set ESP_RGB pct 0
2021-01-24 12:36:15 ESPEasy ESP_RGB pct 0
2021-01-24 12:36:15 ESPEasy ESP_RGB rgb: 0000ff
2021-01-24 12:36:15 ESPEasy ESP_RGB ct: 2500
2021-01-24 12:36:15 ESPEasy ESP_RGB pct: 0
2021-01-24 12:36:15 ESPEasy ESP_RGB onOff: on
2021-01-24 12:36:15 ESPEasy ESP_RGB colormode: ct
2021-01-24 12:36:15 ESPEasy ESP_RGB col: ct ct: 2500 onO: on pct: 0 rgb: 0000ff

Setze ich statt "onOff" mein selbst erstelltes Reading "PCTON" ein, dann bekomme ich mit dem Code "PCTON=off".
Das geht. Nur das "onOff" Device Reading will sich nicht beeinflussen lassen.

2021-01-24 12:44:38 ESPEasy ESP_RGB onOff: on
2021-01-24 12:44:38 ESPEasy ESP_RGB ct: 2500
2021-01-24 12:44:38 ESPEasy ESP_RGB pct: 0
2021-01-24 12:44:38 ESPEasy ESP_RGB PCTON: off
2021-01-24 12:44:38 ESPEasy ESP_RGB col: ct ct: 2500 onO: on pct: 0 rgb: 0000ff

Beta-User

Hmmm, OK...
Könnte man wohl mit einem sleep+setreading _innerhalb_ des Perl-Codes lösen, aber man. ist das Verhalten hier nicht OK und mal sollte den Maintainer fragen, ob das geändert werden kann (ohne userReadings).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Konfusius

#17
Wenn Du meinst, dass meine (funktionierende) Lösung ok ist? 
Ich war mir sicher, dass ich das als Anfänger viel zu kompliziert gemacht habe.

Ich sollte weiter lernen, dann finde ich das später selbst raus...

Vielen Dank nochmal für die schnelle Hilfe!

Beta-User

Ich glaube nicht, dass die OK ist, schau ins fhem-log...
Und informiere den maintainer.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Konfusius

Da es um das  "_P_123_Lights" Plugin für ESPEasy geht, habe ich den Developer des Moduls schon
vor Tagen angeschrieben. Das ist User "dev0" hier aus dem Forum.
Das Plugin ist für die aktuelle Version von ESPEASY zu alt und müsste angepasst werden.
Leider bekam ich keine Antwort.

Ich kann das leider nicht. Ich könnte höchstens einen Raspberry PI3 aus Einzelteilen zusammenlöten...

Beta-User

Na ja, wenn es um "Rückportierungen" geht, kann ich verstehen, dass du da wenig support bekommst; in der Regel sollte man eher weiterentwickeln...

Wie dem auch sei:
In userReadings MUSS der perl-Code von geschweiften Klammern umgeben sein, irgendwas außerhalb zu notieren sollte zu Fehlermeldungen im Log führen. Es kann schon sein, dass fhem.pl verhindert, dass dasselbe Reading manipuliert wird, das (auch) Teil des Readings-update ist.

Aus diesem Dillema führen afaik mind. zwei Wege raus:

1. readingsChange:
Das ist ein Spezialfall eines notify, leider habe ich selbst die Syntax noch nicht zu 100% durchschaut. Vorteil: das klinkt sich sehr früh in die Event-Verarbeitung ein und erzeugt daher (so mein möglicherweise falsches Verständnis) kein weiteres Event.
Weitere Info: https://fhem.de/commandref_modular.html#readingsChange (und hoffentlich jemand freundliches, der erklären kann, wie man es hier nutzbar macht.

2. Das bereits genannte "fhem-sleep" innerhalb des userReadings-Perl-Codes. Dazu habe ich mal hier ein Beispiel gefunden:
https://forum.fhem.de/index.php/topic,115904.msg1101829.html#msg1101829
Der Code ist allerdings vermutich auch nicht ganz optimal, aber daraus bastle ich mal folgendes:
attr ESP_RGB userReadings ONOFF:pct:.0 {fhem("sleep 0.1; setreading $name onOff off");return undef}Erklärungen:
- ONOFF brauchen wir wohl als anderen Reading-Namen, damit fhem.pl zufrieden ist;
- eine echte Wertzuweisung für das Reading brauchen wir nicht, daher geben wir am Ende ausdrücklich das (unschöne!) undef zurück;
- die eigentliche Musik spielt in dem kurzen fhem-sleep. Das entkoppelt das setreading von der Eventverarbeitung, damit wird es dann ein zulässiger Befehl, was innerhalb der Event-Verarbeitung nicht der Fall ist... Damit ist auch klar, was der Nachteil ist: Wir erhalten 2 Events, nämlich erst das (falsche) "on" und dann später erst das "off".
- und damit das ganze noch funktioniert, wenn man das Device umbenennt, machen wir den Namen noch dynamisch, $name müßte eigentlich in userReadings passend aufgelöst werden (sonst min $NAME testen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Konfusius

Nein, das geht so leider auch nicht.
Aber nochmal zum Verständnis, nicht das ich missverstanden wurde:

Ziel des Ganzen ist, das Device abzuschalten, wenn der Wert "pct" =0 ist.

Das Problem war, das wenn man den pct- Regler bewegte, das Device immer eingeschaltet wurde.
Auch, wenn der Regler auf "0" geschoben wurde. Im TabletUI wird das Gerät damit als "eingeschaltet" angezeigt,
obwohl es dunkel ist. Das führte immer zu Verwirrungen. Ist das Licht nun aus oder an???
(Bei Tasmota funktioniert das richtig, pct0 = Device off)

Das Reading des ESP Easy Devices (Plugin Lights) "onOff" ist, so sieht es für mich aus, eine reine Statusmeldung des Devices.
Damit sagt  das Gerät dem FHEM, ob es an oder aus ist.
Wenn wird diese Meldung"heimlich" zeitversetzt ändern, bleibt das Device doch eigentlich trotzdem an, oder?
Wir haben dann ja nur seine Meldung "gefälscht".

Ich bin als Anfänger ja auch nur darauf bedacht was zu lernen. Und wenn, dann auch "richtig".
Deshalb meine Frage, ob mein userReading so akzeptierbar ist, oder ob da noch dicke Fehler drin sind, die zwar die Funktion nicht beeinträchtigen,
aber mir später Probleme bereiten, weil ich falsche Schlüsse gezogen habe oder etwas überhaupt nicht verstanden habe.
Syntaxfehler und Formatierung eingeschlossen.

Ich will hier auch niemandem die Zeit stehlen.




Beta-User

Na ja, steht denn bei deiner userReadings-Fassung was im Log?
Wenn nein, kann es ja bleiben, wenn doch, kannst du statt setreading auch (in meinen "mini"-sleep-Vorschlag) ein "set ... off" reinbasteln, wenn man wirklich (!) was schalten muss. Einen firmware-Bug hatte ich eigentlich nicht vermutet, an sich sollte das schon ausgeschaltet werden, wenn man auf 0 stellt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors