Notify Reading und DBLog Loggen nicht im Zusammenspiel

Begonnen von Juelo, 28 Dezember 2022, 20:49:00

Vorheriges Thema - Nächstes Thema

Juelo

Hey FHEM Profis,

ich brauche mal wieder eure Expertise.

In FHEM betreibe ich relativ viele dynamische MQTT Devices (30).

Jeweils wenn ein Wert "InternalReading" geschrieben wird, bearbeite ich diesen nach und schreibe ein entsprechend neues Reading. Klar könnte ich das auch über UserReading machen, würde jedoch gerne nur eine "Notify Funktion" verwalten müssen.

Jetzt hab ich jedoch das Problem, dass ich genau den neuen "Wert" mittels DBLog wegschreiben will.

Im Event Monitor ist die entsprechende Änderung sichtbar.


Zitat
2022-12-28 20:40:25 MQTT2_DEVICE MQTT2_af27c0598 InternalReading: 167225621
2022-12-28 20:40:25 MQTT2_DEVICE MQTT2_af27c0598 SomeReading: MyNewValue

Leider wird jedoch nur das "InternalReading" in die Datenbank geschrieben. Wenn ich es richtig gelesen habe, wird das erneute "Triggern" durch den Notify verhindert. Gibt es trotzdem eine Möglichkeit den DBLog zum Loggen von "SomeReading" zu bringen?

Danke und schon mal einen Guten Rutsch


define sys_dblog_001 DbLog ./contrib/dblog/db_fhem_heating_stat.conf MQTT2_.*:.*
attr sys_dblog_001 DbLogType Current/History
attr sys_dblog_001 asyncMode 1
attr sys_dblog_001 bulkInsert 1
attr sys_dblog_001 disable 0

define sys_notify_calc notify .*:InternalReading:.* {\
  my $device = $NAME;;;;\
  my $devhash = $defs{$device};;;;\
...
  readingsSingleUpdate($devhash, "SomeReading", "MyNewValue", 1);;;;\
  }\
}

frober

Probiere mal anstelle von readingsSingleUpdate

fhem("sleep 1 quiet; setreading $devhash SomeReading MyNewValue");
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

#2
Oder benenne das notify um, so dass es mit list .* vor dem DbLog-Device auftaucht.
userReadings (sauber getriggert) sind aber mAn. effizienter.
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