ElabNET Technik Forum

Hallo.

Bei der Verwaltung der Modbus Schnittstellen werden unter "Statistik" auch die auftretenden Fehler gezählt.
Ich möchte diese Information an MQTT weiterleiten, was mir aber nicht gelingt.
Weiß jemand Rat?

Mein (erfolgloser) Versuch:
Der Abschnitt enthält ja auch einen Link zu Grafana, wo diese Information verfolgt werden kann.
Über diesen Link habe ich herausgefunden, dass die Fehler in der TWS InfluxDB protokolliert werden. Allerdings nicht in der Datenbank "Timberwolf Timeseries DB" (timeseries_db) sondern in der "Timberwolf Monitoring DB" (monitoring_db).
Nun sind meine Versuche, auf diese Datenbank zuzugreifen (analog zur 'timeseries_db' also mit dem user "docker") nicht erfolgreich gewesen. Anscheinend ist dieser Zugriff auf diese DB nicht möglich: Ich erhalte die Fehlermeldung: "error authorizing query: docker not authorized to execute statement xxx, requires READ on monitoring_db".


Wie komme ich an die Daten der monitoring_db ran?

Besten Dank für Eure Tipps!

Hallo Minor
Moderation:
[X] Notwendigen Versionsangaben zu der beteiligten Software fehlen im Titel. TWS Software Version in [] an den Anfang des Threadtitels nicht in die Signatur.
Die genauen Forenregeln: ‪https://wiki.timberwolf.io/Forenregeln‬

Bitte dringend ergänzen!
KEINE Antworten von ElabNet ohne vollständigen Angaben!

Ich habe es jetzt über Grafana Alerts gelöst: Ich habe einen Alarm erstellt, der von der Fehleranzahl getriggert wird. Dieser Alarm sendet dann einen Webhook via POST an ioBroker (Simple-API). Die JSON Statusmeldung werte ich dann über einen Alias in ioBroker aus.

Funktioniert, ist aber weder elegant oder gar Ressourcen-schonend und auch definitiv nichts für eine Vielzahl von Abfragen. Ein direkter Lese- Zugriff auf die monitoring_db wäre sicherlich besser.


Wenn jemand doch noch eine bessere Lösung für dieses Problems kennt: Rückmeldung weiterhin höchst willkommen!

Hi Mino R,

wir haben das Thema verstanden und es gehört in den Komplex "Systemobjekte" mit dem man alle essentiellen Parameter monitoren kann. Es gibt ja auch Gedanken, dass es eines Tages ein "SQL-Subsystem" gibt, mit dem man zyklische Anfragen auf die Influx geben kann, um damit die Veränderung von Werten über statistische Methoden zu erfassen, die dann als Objekte genutzt werden können.

Das ist ja das schöne an der Architektur des Timberwolf Servers, das solche Dinge prinzipiell machbar sind, weil grundlegend so ziemlich alles als separates Subsystem implementiert werden kann. ist halt noch eine Fleißaufgabe, es braucht ja auch in der Zukunft noch starke Features.

lg

Stefan