InfluxDBLogger: userReadings werden nicht übertragen

Begonnen von gromeck, 14 Dezember 2020, 17:30:15

Vorheriges Thema - Nächstes Thema

gromeck

Fortsetzung von https://forum.fhem.de/index.php/topic,114860.msg1110582.html#msg1110582

Zitat von: kadettilac89 am 14 Dezember 2020, 16:45:05
Ist der gesetzte Wert unterschiedlich zum vorherigen? Teste mal ohne event-on-change reading oder andere Filter ob dann das Event im Event-Monitor auftaucht

Hmm, jetzt wird es gerade seltsam: im FHEM-EventLogger erscheint das Event, aber in meinem eigenen EventLogger (ein Trigger, der alle Events .*:.* ins Logfile schreibt) erscheint es nicht.
In der InfluxDB kommt der berechnete Wert aus dem userReading aber auch nicht an.
FHEM 6.0 @ RaspberryPi3 Model B Rev1.2, 2 CUNX, 101 HM devices, 6 MQTT devices, 612 definitions in 5845 lines in 36 FHEM configuration files

timmib

Demnach vermute ich mal, dass er in den Statistiken unter "e" auch nicht auftritt.

Ich hatte mal ein ähnliches Problem. Ich versuche das mal lokal nachzustellen.

timmib

Achja, und deine Definition vom Userreading wäre evtl hilfreich.

gromeck

Hier die Definitionen:

#
#   Kostal PV Inverter PIKO
#
define PV KOSTALPIKO inverter.site pvserver kost42naut
  attr PV delay 60
  attr PV userReadings generator.1.power,generator.2.power
  attr PV event-on-change-reading .*

#
#   String #1: compute the Power W out of current I and voltage U
#
define Trigger.PV.Power1 notify PV:generator.1.(voltage|current).* { \
        Log 1,"Trigger.PV.Power1: NAME=$NAME  EVENT=$EVENT";; \
        my $U = ReadingsVal($NAME,"generator.1.voltage",0);; \
        my $I = ReadingsVal($NAME,"generator.1.current",0);; \
        my $P = $U * $I;; \
        Log 1,"Trigger.PV.Power1: NAME=$NAME  generator.1.power=$P";; \
        readingsSingleUpdate($defs{$NAME},"generator.1.power",$P,1);; \
    }



Und hier mal ein Log:

2020-12-14 17:37:37 InfluxDBLogger InfluxDB.PV succeeded_writes: 167
2020-12-14 17:37:37 InfluxDBLogger InfluxDB.PV Statistics: t=992 s=167 f=0
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV total_writes: 993
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV Statistics: t=993 s=167 f=0
2020-12-14 17:37:43 KOSTALPIKO PV generator.1.voltage: 10
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV total_writes: 994
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV Statistics: t=994 s=167 f=0
2020-12-14 17:37:43 KOSTALPIKO PV generator.1.current: 0.2
2020-12-14 17:37:43 KOSTALPIKO PV generator.1.power: 2
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV succeeded_writes: 168
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV Statistics: t=994 s=168 f=0
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV succeeded_writes: 169
2020-12-14 17:37:43 InfluxDBLogger InfluxDB.PV Statistics: t=994 s=169 f=0


Da die Sonne mittlerweile untergegangen ist, setze ich zum Testen PV generator.1.voltage und PV generator.1.current manuell.
Mein Trigger berechnet daraus PV generator.1.power.
Eigentlich würde man erwarten, dass PV generator.1.power zweimal geloggt wird, da der Trigger auf Updates von Voltage und Current reagiert. Da aber im obigen Szenario beide Readings auf Null sind, ist Power auch bei voltage=10 noch Null und wird damit noch nicht geloggt, weil keine Änderung. Erst wenn auch Current von Null verschieden ist, ändert sich Power -- und wird dadurch geloggt.
FHEM 6.0 @ RaspberryPi3 Model B Rev1.2, 2 CUNX, 101 HM devices, 6 MQTT devices, 612 definitions in 5845 lines in 36 FHEM configuration files

timmib

#4
Ich habe mal einen einfachen Fall nachgestellt und mir Deine Definition noch nicht angeschaut. Da geht alles.

defmod d2 dummy
attr d2 setList on off
attr d2 userReadings test { ReadingsVal("d2","state","default")."Hello" }

timmib

#5
Siehe https://fhem.de/commandref_DE.html#userReadings

userReadings
Komma getrennte Liste von benutzerdefinierten Readings. Jede Definition hat folgendes Format:
<reading>[:<trigger>] [<modifier>] { <perl code> }


Das sieht bei Dir "etwas" anders aus. warum dieser Umweg?

Wie Du in meinem einfachen Beipiel siehst, braucht man auch kein event-on-change-reading

gromeck

Zitat von: timmib am 14 Dezember 2020, 18:47:34
Das sieht bei Dir "etwas" anders aus. warum dieser Umweg?

Naja, du hast ein sehr einfaches Beispiel gewählt mit
- nur einem userReading
- ohne einen Trigger
- mit nur einer Zeile Perl-Code

Wenn ich mehrere userReadings für ein Device habe, und diese mit dem entsprechenden Trigger versehe und die dann auch noch 10 oder mehr Zeilen Perl-Code brauchen, dann wir das alle in einer Zeile (ja, Umbrüche sind möglich) ziemlich hässlich.

Also habe ich einen Trigger dafür definiert.
FHEM 6.0 @ RaspberryPi3 Model B Rev1.2, 2 CUNX, 101 HM devices, 6 MQTT devices, 612 definitions in 5845 lines in 36 FHEM configuration files