Autor Thema: InfluxDBLogger: userReadings werden nicht übertragen  (Gelesen 857 mal)

Offline gromeck

  • New Member
  • *
  • Beiträge: 6
InfluxDBLogger: userReadings werden nicht übertragen
« am: 14 Dezember 2020, 17:30:15 »
Fortsetzung von https://forum.fhem.de/index.php/topic,114860.msg1110582.html#msg1110582

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

Offline timmib

  • Developer
  • Full Member
  • ****
  • Beiträge: 221
Antw:InfluxDBLogger: userReadings werden nicht übertragen
« Antwort #1 am: 14 Dezember 2020, 17:34:06 »
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.

Offline timmib

  • Developer
  • Full Member
  • ****
  • Beiträge: 221
Antw:InfluxDBLogger: userReadings werden nicht übertragen
« Antwort #2 am: 14 Dezember 2020, 17:41:31 »
Achja, und deine Definition vom Userreading wäre evtl hilfreich.

Offline gromeck

  • New Member
  • *
  • Beiträge: 6
Antw:InfluxDBLogger: userReadings werden nicht übertragen
« Antwort #3 am: 14 Dezember 2020, 17:52:13 »
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

Offline timmib

  • Developer
  • Full Member
  • ****
  • Beiträge: 221
Antw:InfluxDBLogger: userReadings werden nicht übertragen
« Antwort #4 am: 14 Dezember 2020, 18:44:56 »
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" }
« Letzte Änderung: 14 Dezember 2020, 18:49:52 von timmib »

Offline timmib

  • Developer
  • Full Member
  • ****
  • Beiträge: 221
Antw:InfluxDBLogger: userReadings werden nicht übertragen
« Antwort #5 am: 14 Dezember 2020, 18:47:34 »
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
« Letzte Änderung: 14 Dezember 2020, 18:49:23 von timmib »

Offline gromeck

  • New Member
  • *
  • Beiträge: 6
Antw:InfluxDBLogger: userReadings werden nicht übertragen
« Antwort #6 am: 14 Dezember 2020, 23:08:52 »
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

 

decade-submarginal