[gelöst] Reading direkt beim Empfang umrechnen lassen

Begonnen von chunter1, 13 Oktober 2021, 08:22:44

Vorheriges Thema - Nächstes Thema

chunter1

Ich würde gerne ein Reading das von einem Sensor kommt direkt beim Empfang um rechnen (z.B. reading/1000).
Knackpunkt ist, dass ich dabei kein neues Reading anlegen, sondern das originale vom Sensor empfangene verwenden möchte.
Also so eine Art Preprocessing.
Geht sowas in FHEM?

Beta-User

readingsChange scheint für sowas gedacht zu sein.

Falls es MQTT2_DEVICE ist, geht es ggf. auch durch Perl in der readingList, siehe https://forum.fhem.de/index.php/topic,123372.msg1179259.html#msg1179259
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

chunter1

Danke!
readingsChange ist genau was ich gesucht habe.
Wäre super, wenn man es noch in die drop-down Liste von "attr" mit aufnehmen könnte. ;)

MadMax-FHEM

Zitat von: chunter1 am 13 Oktober 2021, 09:02:47
Wäre super, wenn man es noch in die drop-down Liste von "attr" mit aufnehmen könnte. ;)

Geht nicht, da es KEIN Attribut eines Devices ist sondern ein EIGENSTÄNDIGES Device!
Siehe: https://fhem.de/commandref_DE.html#readingsChange

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

...der Vorschlag war wohl eher so zu verstehen, dass sowas wie readingsChange Teil der readingFnAttributes sein sollte...?

Sowas könnte manche Problemchen lösen (wie das mV-Problem bei zigbee2tasmota@MQTT2_DEVICE (oder war es zigbee2mqtt...?)) aber generell sehe ich nicht den großen Bedarf und bin auch unsicher, ob das nicht die Event-Verarbeitung innerhalb readings.*update zu sehr aufblähen würde. Andererseits ist es ggf. lästig, für "jeden Pups" in diese Richtung ein separates readingsChange anflanschen zu müssen. Was generisches wäre schon nicht übel...
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

MadMax-FHEM

Ah, das klingt plausibel...

Also wie userReadings nur halt "auf sich selbst" statt "auf" ein "neues" Reading...

Naja Bedarf: oft klingen die "Anfragen" wo am Ende die Antwort userReadings ist schon nach "eigentlich wollte ich das Reading anders haben" (Antwort: mach doch ein neues Reading mittels userReadings und "arbeite" dann damit)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)