FHEM Forum

Hallo liebe Freunde von InfluxDB,

das neue Modul ermöglicht die effektive Übertragung von InfluxDB "Fields" nach FHEM.
Dies ist sehr nützlich um Werte,die direkt nach InfluxDB geschrieben werden (ohne FHEM) trotzdem in FHEM nutzbar zu machen. So entsteht anstatt einer Doppellieferung nach InfluxDB und FHEM eine Kette.
Ein Paradebeispiel dafür sind CPU und Memory Werte die man mit Telegraf sammelt.

Und nicht nur das, es kann die volle Macht von Kapacitor dabei ausgenutzt werden. Kapacitor erlaubt z.B. gleitende Mittelwerte über bestimmte Zeitfenster uvm.

Das Modul registriert automatisch einen einfachen Task beim Kapacitor und stellt einen TCP-Server bereit um die Werte zu empfangen. Dieser Task wird sogar automatisch aktualisiert, wenn ihr die Attribute ändert.

TODOs:

• jegliche Security
• jegliches Löschen des Tasks
• Unterstützung von mehreren Measurements/Devices. D.h. es wird ein primäres IODev geben was den TCP-Server stellt und die Werte an die Kind-Device weitergibt.
• InfluxDB2 support

Doku folgt.

Neue Version 28.01.2021:

• Task werden jetzt mit dem Device disabled/enabled und gelöscht
• Man kann die Stats direkt in FHEM abholgen mit get stats
• Der Kapacitor Host und Port können jetzt nurnoch beim anlegen gesetzt werden und nicht mehr als Attribut. Da das Ändern ohnehin keinen Sinn macht.
• Der Status vom Task wird als Reading in FHEM angezeigt.
• Besseres Logging
• Ändern des eigenen Ports startet den TCP-Server automatisch neu

Neue Version 29.01.2021:

• Auftrennung von Kommunikation und Tasks und damit Unterstützung von mehreren Measurements parallel
• WHERE Bedingung kann angegeben werden
• WINDOW und MEAN_FIELD kann angegeben werden

Neue Version 30.01.2021:

• Alter der Readings wird alle 10s berechnet (age)
• TCP-Verbindungen werden öfter geschlossen
• Fehlerbehandlung von HTTP Problemen
• Standard Attribute hinzugefügt

Neue Version 01.02.2021:

• Message Counter zählt nun richtig und es werde nicht immer weiter internals angelegt
• Temporäge TCP-Verbindungs Geräte werden direkt gelöscht

Neue Version 07.02.2021:

• command ref vorhanden(Englisch)!!!
• window kann feiner parametrisiert werden. period und every sind einzeln setzbar
• detach Attribut um Ändern des Tasks auszusetzen

Neue Version 04.02.2022:

• FUnktioniert nun auch mit der neuesten FHEM version. Dort wurde ein Bug gefixet der dieses Modul unbrauchbar gemacht hat.

Viel Spaß beim Testen und Feedback schreiben.

Tim

PS. Link zu  Kapacitor https://docs.influxdata.com/kapacitor/v1.5/ (https://docs.influxdata.com/kapacitor/v1.5/)

Hier ein kurzer Hinweis zur Benutzung.

UPDATE: 29.01.2021

define NAME Kapacitor KAPACITOR_HOST [KAPACITOR_PORT]
disable:1,0 An und Abschalten des TCP-Servers.
ownhost Optional eine bestimmte IP oder DNS-Name auf den Kapacitor die Daten schicken soll. Default ist die IP von FHEM.
ownport Optional ein bestimmter Port auf den Kapacitor die Daten schicken soll. Default ist 50226.

Dann ZUSÄTZLICH pro Task ein Device:

define NAME KapacitorTask KAPACITOR_DEVICE DATABASE RETENTIONPOLICY MEASUREMENT
database Der Name der Datenbank aus der man die Werte möchte.
retentionpolicy Der Name der Retention Policy aus der man die Werte möchte.
measurement Der Name des Measurements aus der man die Werte möchte.

Attribute:
where Optionale where Clause um z.B. auf tag oder field zu beschränken.
windowSize Optionale windowSize Die größere des gleitendes Fensters. Gemeinsam mit meanField zu nutzen
meanField Optionale meanField Das Feld für den Mittelwert. Gemeinsam mit windowSize zu nutzen

Setter
createorupdatetask Erzwingen des Anlegen/Aktualisieren des Kapacitor Tasks. Wird eigentlich beim Setzen der Attribute automatisch gemacht.

Viele Grüße

Tim

Hallo Tim,

klasse Idee von dir Kapacitor an FHEM anzubinden. Leider funktioniert das bei mir noch nicht so wie propagiert. Allerdings muss ich dazu sagen, dass ich sowohl INFLUXDB (und jetzt Kapacitor) und FHEM in Docker-Containern laufen habe. Und INFLUXDB die 2.0-Version ist.
Ich habe Kapacitor so aufgesetzt wie es von den Influx-Leuten im Zusammenspiel mit der 2.0-Version beschrieben wird. Die Kommunikation von FHEM zu Kapacitor scheint stattzufinden (die Log-Datei von Kapacitor enthält entsprechende Einträge) aber es werden keine Readings in FHEM erzeugt. Hier mal ein List des FHEM-Devices:
Internals:
   FD         47
   FUUID      60113a1b-f33f-bb67-9ad8-8822f3ea72c88c4f
   FVERSION   93_Kapacitor.pm:?/2021-01-27
   NAME       kapacitor
   NR         786
   PORT       50226
   STATE      opened
   TYPE       Kapacitor
   stacktrace  TcpServer_Close:378 Kapacitor_Close:127 Kapacitor_Set:3813 CallFn:1919 DoSet:1951 CommandSet:99 CommandCmdAlias:1251 AnalyzeCommand:2721 FW_fC:991 FW_answerCall:596 FW_Read:3818 CallFn:759
   READINGS:
     2021-01-27 18:37:03   state           opened
Attributes:
   database   telegraf
   host       192.168.x.xxx
   measurement temp
   ownhost    192.168.y.yyy
   ownport    50226
   port       9092
   retentionpolicy 3d
   room       Log

Hast du ad hoc eine Idee woran es liegen könnte?

Grüße
Stefan

Hi Stefan,

man muss die Seite neu laden, damit die Readings angezeigt werden.

Aber das hast Du wahrscheinlich schon gemacht.

Viele Grüße

Tim

Sonst könntest du Mal mit netcat(nc) testweise was nach FHEM schicken.

Was sagt kapacitor zum Task? Wie sehen da die Statistiken aus?

kapacitor list tasks

kapacitor show fhem.DEVICENAME

*** neue Version *** siehe oben.

ZitatSonst könntest du Mal mit netcat(nc) testweise was nach FHEM schicken.
Was sagt kapacitor zum Task? Wie sehen da die Statistiken aus?

Tim, ich habe dein aktualisiertes Modul eingespielt. Daten erhalte ich leider immer noch nicht.
kapacitor list tasks bringt:
ID             Type      Status    Executing Databases and Retention Policies
fhem.kapacitor stream    enabled   true      ["telegraf"."3d"]

kapacitor show fhem.kapacitor bringt:
ID: fhem.kapacitor
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 27 Jan 21 15:46 UTC
Modified: 29 Jan 21 11:07 UTC
LastEnabled: 29 Jan 21 11:07 UTC
Databases Retention Policies: ["telegraf"."3d"]
TICKscript:
stream
    |from()
        .measurement('temp')
    |alert()
        .info(lambda: 1 < 2)
        .tcp('192.168.2.11:50226')

DOT:
digraph fhem.kapacitor {
graph [throughput="0.00 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="0"];

from1 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
from1 -> alert2 [processed="0"];

alert2 [alerts_inhibited="0" alerts_triggered="0" avg_exec_time_ns="0s" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="0" ];
}


Hier ein aktuelles List des Devices:
Internals:
   CFGFN     
   DEF        192.168.xxx.xxx 9092
   FD         56
   FUUID      6013df3a-f33f-bb67-8325-6a22736c3cb4e550
   HOST       192.168.xxx.xxx
   KAPACITOR_PORT 9092
   NAME       kapacitor
   NR         18759
   PORT       50226
   STATE      opened
   TYPE       Kapacitor
   stacktrace  TcpServer_Close:556 Kapacitor_Close:134 Kapacitor_Attr:3818 CallFn:3049 CommandAttr:1251 AnalyzeCommand:2721 FW_fC:948 FW_answerCall:596 FW_Read:3818 CallFn:759
   READINGS:
     2021-01-29 12:13:45   age             63781906033.778
     2021-01-29 11:11:35   state           opened
     2021-01-29 12:07:17   stats           {"node-stats":{"from1":{"working_cardinality":0,"avg_exec_time_ns":0,"collected":0,"emitted":0,"errors":0},"alert2":{"warns_triggered":0,"errors":0,"avg_exec_time_ns":0,"working_cardinality":0,"collected":0,"emitted":0,"crits_triggered":0,"oks_triggered":0,"alerts_inhibited":0,"alerts_triggered":0,"infos_triggered":0},"stream0":{"working_cardinality":0,"avg_exec_time_ns":0,"collected":0,"emitted":0,"errors":0}},"task-stats":{"throughput":0}}
     2021-01-29 12:07:17   task            stats fetched
Attributes:
   database   telegraf
   measurement temp
   ownhost    192.168.yyy.yyy
   ownport    50226
   retentionpolicy 3d
   room       Log

Ein Auszug aus dem Kapazitor-Log:
ts=2021-01-29T11:11:16.629Z lvl=info msg="http request" service=http host=127.0.0.1 username=- start=2021-01-29T11:11:16.625013988Z method=GET uri=/kapacitor/v1/tasks/fhem.kapacitor?dot-view=attributes&replay-id=&script-format=formatted protocol=HTTP/1.1 status=200 referer=- user-agent=KapacitorClient request-id=b4c680a3-6222-11eb-8006-000000000000 duration=3.980783ms

Kann es sein dass es an diesem Sachverhalt bei Influxdb 2.0 liegt:

ZitatUse Kapacitor stream tasks
InfluxDB Cloud and OSS 2.0 do not have subscription APIs and do not support Kapacitor stream tasks directly. To use Kapacitor stream tasks, write data directly to Kapacitor using the Kapcitior write API.

Grüße
Stefan

Hi, ja ich befürchte das ist so.

Wie Du in den Stats siehst wird in dem Task schlicht nix verarbeitet. Entsprechend kann in FHEM auch nix ankommen.

ZitatInfluxDB Cloud and OSS 2.0 do not have subscription APIs and do not support Kapacitor stream tasks directly.

Die spannende Frage ist, wie man diese automatische Übertragung

ZitatTo use Kapacitor stream tasks, write data directly to Kapacitor using the Kapcitior write API."

hinbekommt.

Viele Grüße

Tim

*** neue Version *** siehe oben.

Nach der Definition von dem KapacitorDevice habe ich diese drei Warnmeldungen im Log:

2021.01.29 21:28:19.915 1: PERL WARNING: Use of uninitialized value $a[1] in subtraction (-) at ./FHEM/99_Utils.pm line 21.
2021.01.29 21:28:19.915 1: PERL WARNING: Argument "0;00" isn't numeric in subtraction (-) at ./FHEM/99_Utils.pm line 21.
2021.01.29 21:28:19.916 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.

Welche FHEM Version hast Du?

ZitatWelche FHEM Version hast Du?

FVERSION
fhem.pl:v6.0-s23613/2021-01-25

Die Logeinträge habe ich auch. Ist jetzt behoben, ist im Rahmen des "age"-Reading passiert.

Klappen die Module den soweit?

*** neue Version *** siehe oben.

ZitatDie Logeinträge habe ich auch. Ist jetzt behoben, ist im Rahmen des "age"-Reading passiert.

Klappen die Module den soweit?

Kann ich mit Bestimmtheit erst sagen, wenn die Influxdb2-Unterstützung implementiert ist  ;)

*** neue Version *** siehe oben.

Hallo Karflyer,

laut Doku ist dies der neue Weg das zu machen. Das sollte auch mit dem Modul harmonieren.

https://docs.influxdata.com/influxdb/cloud/tools/kapacitor/#use-kapacitor-stream-tasks (https://docs.influxdata.com/influxdb/cloud/tools/kapacitor/#use-kapacitor-stream-tasks)

Hallo Tim,

Hallo Karflyer,
laut Doku ist dies der neue Weg das zu machen. Das sollte auch mit dem Modul harmonieren.
https://docs.influxdata.com/influxdb/cloud/tools/kapacitor/#use-kapacitor-stream-tasks


Das habe ich versucht und mehrere Stunden damit verbracht das ans laufen zu bekommen. Leider ohne Erfolg. Heißt aber nicht, dass es nicht doch so funktioniert. Hast du mittlerweile selbst einmal probiert, dass in Verbindung mit InfluxDB 2.0 ans laufen zu bekommen?

Grüße
Stefan

Hi Stefan,

ne, noch nicht. Ich nutze produktiv InfluxDB 1 und bin auch happy damit.

InfluxDB 2 hab ich nur in einer VM zum Entwickeln damit das InfluxDBLogger Modul was zum testweisen hinschreiben mit API v2.

Was genau ging denn nicht?

Hi zusammen,

ich hab vor kurzem von RaspberryPi auf Proxmox im ThinkCentre mit Docker umgebaut. In dem Zusammenhang hab ich die mysql auf dem NAS jetzt auch als InfluxDB auf dem Proxmox laufen.

Aktuell errechne ich einen Mittelwert über 14 Tage mit der Mysql über DBLog. Dies würde ich aber gerne auch mit Influx lösen, deswegen teste ich gerade mit deinem Modul.

Fhem und Kapacitor funktioniert auch soweit. Kapacitor spricht auch mit der Influx. Allerdings bekomme ich aktuell alle Felder welche "temperature" enthalten. Das Attribut "Where" scheint nicht zu greifen. Eine Änderung an der RetentionPolicity scheint der Kapacitor auch nicht mitzubekommen.

Internals:
   DATABASE   fhem
   DEF        InfluxDB_Kapacitor fhem autogen temperature
   FUUID      601e7024-f33f-55ff-a196-30feae9ad4802b57
   IODev      InfluxDB_Kapacitor
   InfluxDB_Kapacitor_MSGCNT 143
   InfluxDB_Kapacitor_TIME 2021-02-06 11:45:39
   LASTInputDev InfluxDB_Kapacitor
   MEASUREMENT temperature
   MSGCNT     143
   NAME       Test
   NR         911
   RETENTIONPOLICY autogen
   STATE      not updated
   TYPE       KapacitorTask
   READINGS:
     2021-02-06 11:45:39   age             0
     2021-02-06 11:44:53   state           not updated
     2021-02-06 11:36:01   stats           {"node-stats":{"alert2":{"working_cardinality":1,"warns_triggered":0,"oks_triggered":0,"emitted":0,"infos_triggered":34,"crits_triggered":0,"collected":34,"errors":0,"alerts_triggered":34,"alerts_inhibited":0,"avg_exec_time_ns":11748653},"from1":{"collected":34,"avg_exec_time_ns":2226,"emitted":34,"errors":0,"working_cardinality":0},"stream0":{"avg_exec_time_ns":0,"collected":34,"emitted":34,"errors":0,"working_cardinality":0}},"task-stats":{"throughput":0}}
     2021-02-06 11:45:39   time            2021-02-06T10:45:39.338677742Z
     2021-02-06 11:45:39   value           39.625
Attributes:
   where      Aussentemperatur
   windowSize 5


root@InfluxDB:~# kapacitor show fhem.Test
ID: fhem.Test
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 06 Feb 21 10:32 UTC
Modified: 06 Feb 21 10:32 UTC
LastEnabled: 06 Feb 21 10:32 UTC
Databases Retention Policies: ["fhem"."autogen"]
TICKscript:
stream
    |from()
        .measurement('temperature')
    |alert()
        .id('fhem.Test')
        .info(lambda: TRUE)
        .tcp('10.0.0.9:50226')

DOT:
digraph fhem.Test {
graph [throughput="0.00 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="67"];

from1 [avg_exec_time_ns="1.675µs" errors="0" working_cardinality="0" ];
from1 -> alert2 [processed="67"];

alert2 [alerts_inhibited="0" alerts_triggered="67" avg_exec_time_ns="2.931826ms" crits_triggered="0" errors="0" infos_triggered="67" oks_triggered="0" warns_triggered="0" working_cardinality="1" ];
}

Kannst du dir erklären wieso alle Messwerte eintrudeln welche temperature heißen?
Sorry wenn es eigentlich offensichtlich ist, bin sehr neu mit Grafana bzw. Influx.

Gruß
Mark

Hallo Mark,

bei der windowsSize fehlt die Zeitangabe. z.B. "5s"

Deswegen steht der State auch auf:

STATE      not updated

Sieht so aus, als wenn die API das entsprechend mangels Zeiteinheit abgelehnt hat.

Viele Grüße

Tim

Ne daran liegts nicht. Grundsätzlich ist ja Leben in dem Modul, es kommen jegliche Fields mit temperature welche FHEM vorher nach Influx geschrieben hat. Nur das Where scheint nicht zu greifen, bzw. ein Ändern des Test-Devices ändert den Kapacitor Task nicht mit.


Internals:
   DATABASE   fhem
   DEF        InfluxDB_Kapacitor fhem autogen power
   FUUID      601e7024-f33f-55ff-a196-30feae9ad4802b57
   IODev      InfluxDB_Kapacitor
   InfluxDB_Kapacitor_MSGCNT 386
   InfluxDB_Kapacitor_TIME 2021-02-06 12:09:11
   LASTInputDev InfluxDB_Kapacitor
   MEASUREMENT power
   MSGCNT     386
   NAME       Test
   NR         911
   RETENTIONPOLICY autogen
   STATE      not updated
   TYPE       KapacitorTask
   READINGS:
     2021-02-06 12:09:34   age             23
     2021-02-06 12:09:21   state           not updated
     2021-02-06 11:36:01   stats           {"node-stats":{"alert2":{"working_cardinality":1,"warns_triggered":0,"oks_triggered":0,"emitted":0,"infos_triggered":34,"crits_triggered":0,"collected":34,"errors":0,"alerts_triggered":34,"alerts_inhibited":0,"avg_exec_time_ns":11748653},"from1":{"collected":34,"avg_exec_time_ns":2226,"emitted":34,"errors":0,"working_cardinality":0},"stream0":{"avg_exec_time_ns":0,"collected":34,"emitted":34,"errors":0,"working_cardinality":0}},"task-stats":{"throughput":0}}
     2021-02-06 12:09:11   time            2021-02-06T11:09:11.662242936Z
     2021-02-06 12:09:11   value           31.5
Attributes:
   where      ED300L

Nach ändern und Updaten von tempeature auf power die Ausgabe das Kapacitors:

root@InfluxDB:~# kapacitor show fhem.Test
ID: fhem.Test
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 06 Feb 21 10:32 UTC
Modified: 06 Feb 21 10:32 UTC
LastEnabled: 06 Feb 21 10:32 UTC
Databases Retention Policies: ["fhem"."autogen"]
TICKscript:
stream
    |from()
        .measurement('temperature')
    |alert()
        .id('fhem.Test')
        .info(lambda: TRUE)
        .tcp('10.0.0.9:50226')

DOT:
digraph fhem.Test {
graph [throughput="0.00 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="308"];

from1 [avg_exec_time_ns="1.794µs" errors="0" working_cardinality="0" ];
from1 -> alert2 [processed="308"];

alert2 [alerts_inhibited="0" alerts_triggered="308" avg_exec_time_ns="3.295656ms" crits_triggered="0" errors="0" infos_triggered="308" oks_triggered="0" warns_triggered="0" working_cardinality="1" ];
}
root@InfluxDB:~# kapacitor list tasks
ID        Type      Status    Executing Databases and Retention Policies
fhem.Test stream    enabled   true      ["fhem"."autogen"]
root@InfluxDB:~#

Grüße

Zitat von: timmib am 06 Februar 2021, 12:01:47
Hallo Mark,

bei der windowsSize fehlt die Zeitangabe. z.B. "5s"

Deswegen steht der State auch auf:

Code Auswählen Erweitern

STATE      not updated

Sieht so aus, als wenn die API das entsprechend mangels Zeiteinheit abgelehnt hat.

Viele Grüße

Tim

Also nicht falsch verstehen, ich weiss schon was du meinst. Aber auch vorher ohne windowSize scheint er das Where nicht genommen zu haben.
Allerdings hab ich keine Ahnung wieso.

Du musst alles beides setzten:
windowSize meanField


    if ( defined($windowSize) && defined($meanField) )
    {
        $windowAndMeanNode = "|window()\n.period($windowSize)\n.every($windowSize)\n|mean('$meanField')\n";
    }


und dein WHERE ist auch kein gültiger lambda Ausdruck. https://docs.influxdata.com/kapacitor/v1.5/nodes/where_node/ (https://docs.influxdata.com/kapacitor/v1.5/nodes/where_node/)

Also ca. so
lambda: "DEIN_TAG_NAME" == 'ED300L'

Ok das hat geholfen  ;)

Durch das Weglassen des where Attributes updated er dann auch auf power.

Ok dann schau ich mal wie ich das am besten einbaue damit er es erkennt.

Grüße

Super,

wie gesagt das where Attribut sollte so ähnlich aussehen.

lambda: "DEIN_TAG_NAME" == 'ED300L'

Magst du mir auch noch sagen wie sich

        .period(30s)
        .every(30s)

definiert setzen lassen? windowSize setzt bei 30s direkt beide. Ich muss doch für ... nehmen wir mal an 14 Tage Average alle 30s ein errechneter Messwert ...

        .period(14d)
        .every(30s)

nutzen? Oder kann ich mit movingAverage im meanField arbeiten?

Grüße

P.S.: Hab mir dein Modul gerade angeschaut, wird definitiv beides als windowSize gesetzt.

Yo,

das Feature fehlt noch.

Wenn Du das haben möchtest, kann ich das gerne ergänzen.

Viele Grüße

Tim

Moin

Wie gesagt bin erst neu in der Influx Umgebung und hab vorher viel mit Dblog und dbrep gemacht. In der Technikerschule habe ich auch nur SQL Statements genutzt.

Ich nutze den Mittelwert der Außentemperatur als schaltbedingung für die Heizperiode. Diese Berechnung über dbrep ist die letzte Sache um Mysql ganz einzustampfen, influx ist da schon Performanter.

Ich kann mir halt nicht ganz vorstellen wie der Kapacitor arbeitet, wenn ich den average auch über das meanfield übergeben kann brauchst du das Modul nicht komplett umbauen  :)
Sprich ich weiß nicht ob ich den Punkt oben mit Periode und Every richtig interpretiert habe.

Aber wenn die Funktion rein kommt wäre das natürlich schön 🤩

*** neue Version *** siehe oben.

@valvak
Window kann nun feiner parametrisiert werden. period und every sind einzeln setzbar. Siehe CommandRef(neu).

Plus neues detach Attribut um Ändern des Tasks auszusetzen.

Beachte, dass Kapacitor nur neue Mittelwerte berechnet wenn auch neue Werte kommen.

Hallo Tim,

ich habe deine Module nun auch in Verbindung mit InfluxDB 2.0 am laufen. Habe aber folgendes Verhalten:
Ich habe measurements, die von telegraf-clients beschrieben werden. Bei einem measurement (system) werden dessen Feldinhalte (load1, load2... ) vom Modul in die entsprechenden Readings geschrieben. Sobald ich hier das Attribut where (lambda: "host" == 'netpi') setze, kommen keine Werte mehr.
Bei einem zweiten measurement (cpu_temperature) kommen überhaupt keine Werte. Ich kann nicht feststellen warum es bei einem measurement wenigstens halbwegs klapp und bei einem anderen gar nicht.
Eine Idee?

Grüße
Stefan

Zeig mal bitte wie das Attribut where genau gesetzt ist, oder wie es bei

kapacitor show auf der CLI gezeigt wird.

ZitatZeig mal bitte wie das Attribut where genau gesetzt ist, oder wie es bei

in FHEM sieht das so aus:
Attributes:
   meanField  load1
   room       Log
   where      lambda: "host" == 'smartnuc'
   windowSize 5s

kapacitor show liefert:
stream
    |from()
        .measurement('system')
        .where(lambda: "host" == 'smartnuc')
    |window()
        .period(30s)
        .every(5s)
    |mean('load1')
    |alert()
        .id('fhem.kaptask01')
        .info(lambda: TRUE)
        .tcp('192.168.xxx.xxx:50226')

Schade, das sieht alles gut aus.

Und was sagen die stats?

Dort sieht man ja schön wo in der Pipeline wieviel Daten verarbeitet wurden.

Danke für die rasche Umsetzung tim, komme leider erst am Wochenende zum produktivem umsetzen.

Gruß Mark

Eine kleine Zusammenfassung was zu tun ist um Kapacitor mit InfluxDB 2.0 in Verbindung mit diesem Modul und Telegraf zu nutzen.
In der InfluxDB 2.0-Doku https://docs.influxdata.com/influxdb/cloud/tools/kapacitor/#use-kapacitor-stream-tasks gibt es eine Beschreibung wie die Telegraf-Config (telegraf.conf) aussehen muss, wenn Kapacitor genutzt werden soll. Die hier aufgeführten Beispielkonfigurationen sind fehlerhaft. Richtig muss es so lauten:
# Write to InfluxDB Cloud or OSS
[[outputs.influxdb_v2]]
  urls = ["http://URL zur InfluxDB:8086"]
  token = "Dein Token"
  organization = "Deine Organisation"
  bucket = "telegraf"

# Write to Kapacitor
[[outputs.influxdb]]
  urls = ["http://URL zu Kapacitor:9092"]
  database = "telegraf"
  retention_policy = "Deine RP"
  skip_database_creation = true

Beide Blöcke müssen in alle Telegraf-Konfigurationen über die Daten in die INFLUX-DB geschrieben werden.

In der Konfigurationsdatei von Kapacitor (kapacitor.conf) muss der InfluxdB-Block mindestens wie folgt aussehen:
[[influxdb]]
  enabled = true
  urls = ["http://URL zur InfluxDB:8086"]
  username = "Dein Username in der InfluxdB"
  password = "Dein Token" (nicht das Password)
  disable-subscriptions = true


Als Token reicht jeweils ein Token der Schreibrechte auf die Telegraf-Datenbank hat.

Weil ich selbst zunächst selber darüber gestolpert bin. Wer parallel zu InfluxDB 2.0 und Kapacitor Chronograf nutzt, um z.B. leichter die von Tim's Modul erzeugten TICKscript's zu sehen, braucht zwingend Chrongraf aus dem 'quay.io/influxdb/chronograf:1.8.9.1' Repository. Chronograf aus dem TICK-Stack funktioniert hier nicht.

Tim, damit müsste dein ToDo 'InfluxDB2 support' erledigt sein.

Grüße
Stefan

Super Beitrag,

wir brauchen echt mal eine Wiki-Seite rund um den TICK-Stack in Kombination mit FHEM.

Hi Tim

bin gerade dabei, Dein Kapacitor-Modul einzusetzen. Ich stolpere allerdings noch bei der Einrichtung, ich habe bei den Tasks eine ganze Liste von TCP-Adressen, die Kapacitator scheinbar nicht mag. Definiert habe ich es mit der .10 IP adresse. Mein Raspi hat sowohl wlan als auch lan, bie IF config wird diese TCP-Adressenliste gezeigt. Irgendwie greift sich Kapacitor die ganze IP-Liste im Task:

        .tcp('192.168.178.10 192.168.178.82 172.17.0.1 169.254.177.247 169.254.224.215:50226')


auf jeden Fall kommt noch nichts im Task bei FHEM an. Any hints? Wie kann ich die Verbindung schrittweise checken?

VG timmo

PS - danke für das INFLUX-Modul - läuft super!

Anbei die Lists:

Internals:
   CFGFN     
   DEF        192.168.178.10
   FD         25
   FUUID      608875a6-f33f-8338-d893-c01112509903f175
   HOST       192.168.178.10
   KAPACITOR_PORT 9092
   NAME       Influx_kapa
   NR         374
   PORT       50226
   STATE      opened
   TYPE       Kapacitor
   READINGS:
     2021-04-27 22:35:50   state           opened
Attributes:

Internals:
   CFGFN     
   DATABASE   plants
   DEF        Influx_kapa plants autogen sensor1
   FUUID      608875c6-f33f-8338-d980-08d6b246e21a582d
   IODev      Influx_kapa
   MEASUREMENT sensor1
   NAME       Influx_kapa_Task1
   NR         382
   RETENTIONPOLICY autogen
   STATE      created
   TYPE       KapacitorTask
   READINGS:
     2021-04-27 22:36:22   state           created
Attributes:

List task:
pi@sturmserver:~ $ kapacitor show fhem.Influx_kapa_Task1
ID: fhem.Influx_kapa_Task1
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 27 Apr 21 22:36 CEST
Modified: 27 Apr 21 22:36 CEST
LastEnabled: 27 Apr 21 22:36 CEST
Databases Retention Policies: ["plants"."autogen"]
TICKscript:
stream
    |from()
        .measurement('sensor1')
    |alert()
        .id('fhem.Influx_kapa_Task1')
        .info(lambda: TRUE)
        .tcp('192.168.178.10 192.168.178.82 172.17.0.1 169.254.177.247 169.254.224.215:50226')

DOT:
digraph fhem.Influx_kapa_Task1 {
graph [throughput="0.00 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="0"];

from1 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
from1 -> alert2 [processed="0"];

alert2 [alerts_inhibited="0" alerts_triggered="0" avg_exec_time_ns="0s" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="0" ];
}


Hallo Timmo,

dafür gibt es das Attribut ownhost beim parent Modul "Kapacitor".

Hier der Auszug aus der Doku:

ZitatOptional special IP or DNS Name of this server to be used by Kapacitor.

Die Doku erreicht man, indem man rechts unten auf "Device specific help" klickt.

Zum Debuggen bieten sich, auf dem Rechner wo Kapacitor läuft, die Befehle "watch" und "show" an.
Siehe hier: https://docs.influxdata.com/kapacitor/v1.5/working/cli_client/#core-commands (https://docs.influxdata.com/kapacitor/v1.5/working/cli_client/#core-commands)

Du kannst auch mittels "get stats" auf dem KapacitorTask in FHEM die Stats nach FHEM holen in ein Reading namens "stats".

Viele Grüße

Tim

Hi Tim,

super, das wars. Die ist irgendwie noch nicht in den Hilfe-Screen eingeflossen (wie triggert man das?), habe den Text nur in der Source nachgelesen, und das übersehen. Und dann hilft  es, wenn der entsprechende Sensor auch was sendet ... ;D

VG timmo

Hi Tim,

noch eine Frage:
im Log wird immer das Schließen des TCP ports genannt - kann man das abschalten? Verbose habe ich schon auf 0.
VG Timmo


2021.05.02 21:32:55.456 3 : Kapacitor (Influx_kapa_192.168.178.10_39588) - Socket closed.
2021.05.02 21:32:55.458 3 : Kapacitor (Influx_kapa_192.168.178.10_39588) - Connection closed for Influx_kapa_192.168.178.10_39588


Internals:
   CONNECTS   984
   DEF        192.168.178.10
   FD         11
   FUUID      608875a6-f33f-8338-d893-c01112509903f175
   HOST       192.168.178.10
   KAPACITOR_PORT 9092
   NAME       Influx_kapa
   NR         343
   PORT       50226
   STATE      opened
   TYPE       Kapacitor
   stacktrace  TcpServer_Close:167 Kapacitor_Close:106 Kapacitor_Attr:3888 CallFn:3116 CommandAttr:1265 AnalyzeCommand:1116 AnalyzeCommandChain:1403 CommandInclude:619
   READINGS:
     2021-05-01 23:21:49   state           opened
Attributes:
   ownhost    192.168.178.10
   verbose    0

Mit der Hilfe - habs rausbekommen. Scheinbar hat das Kopieren die Dateien als DOS formatiert, nach öffnen und ein Leerzeichen einfügen, und speichern wird auch die Hilfe richtig angezeigt. perl ./contrib/commandref_join.pl  ist der Syntax check für die CMD Referenz (siehe Wiki).

sudo perl ./contrib/commandref_join.pl /opt/fhem/FHEM/93_Kapacitor.pm

*** EN /opt/fhem/FHEM/93_Kapacitor.pm: ignoring text due to DOS encoding

Jetzt noch die Logmeldungen anschauen ..
VG timmo

Hallo,

ZitatHi Tim,

noch eine Frage:
im Log wird immer das Schließen des TCP ports genannt - kann man das abschalten? Verbose habe ich schon auf 0.
VG Timmo

Ja, da bin ich die Tage selber drüber gestolpert. Das stellt man beim verbose attribut vom IODEV also zentral am Kapacitor Modul um.
Der macht ja einen TCP Port für alle Kinder auf.

Das scheinst Du ja auch gepostet zu haben. Dann schau mal in global Device rein, wie da das verbose Attribut gesetzt ist.

Übrigens habe ich vorne beim ersten Post eine neue Version hineingebracht, die mit der neuesten FHEM Version wieder funktioniert.

Viele Grüße und sorry für die späte Antwort.

Tim