openhabforum.de

Hallo,

ich habe bei meinem Openhab Updates von der 2 schrittweise bis zur 5 vorgenommen.
Durch irgend eines der Updates schreibt Openhab in influxdb zu Zeit und value noch die Spalte item dazu mit der Bezeichnung des items. Das entspricht aber immer genau der Bezeichung des messurement - ist also völlig überflüssig.
Das ist mir erst jetzt aufgefallen, nachdem ich influxdb von 1.8 nach 2.7 geupdatet habe. Nun muss ich die Verbindung von Grafana zur influxdb neu konfigurieren und da zeigt sich plötzlich ein Unterschied, ob die zusätzliche Spalte item einen Wert enthält oder nicht.

Warum und seit wann gibt es diese Änderung und kann ich diese Spalte unterdrücken?

Ich verwende folgende Einträge in der influxdb.persist:

Code: Alles auswählen

Strategies
{
    everyMinute : "0 * * * * ?"
    every10Minutes : "0 */10 * * * ?"
    everyHour : "0 0 * * * ?"
    everyDay : "0 0 0 * * ?"
    default = everyChange
}
Items
{
    hz_mqtt_aussentemp  : strategy = every10Minutes
    
    ...
}

und neuerdings steht in der influxdb:

Code: Alles auswählen

select * from  hz_mqtt_aussentemp WHERE time > now() - 1h
name: hz_mqtt_aussentemp
time                item               value
----                ----               -----
1756831200340000000 hz_mqtt_aussentemp 16.8

VG

Es handelt sich bei "item" nur um einen Tag, nicht wie bei "value" um ein Field, verbraucht also nur unwesentlich Speicherplatz.
Dass sich da was geändert hat, ist mir neu. Ich kenne es nicht anders, nutze aber die InfluxDB erst seit OH 3.4, wenn ich mich recht entsinne.

Tags werden genutzt, um unterschiedliche sogenannte "Series" innerhalb eines "Measurements" zu unterscheiden.

Den Namen des Measurements als auch die Tags kannst du in der Item-Konfiguration angeben (s. https://www.openhab.org/addons/persistence/influxdb/). Du kannst auch mehrere Tags angeben. Damit könntest du zum Beispiel alle Temperaturen, die du misst, unter einerm Measurement "Temperatur" zusammenfassen und etwa die Räume durch Tags unterscheiden.

Tust du das nicht, ist standardmäßig der Name des Measurments gleich dem Itemnamen, und es wird zusätzlich ein Tag "item" hinzugefügt, das auch den Itemnamen enthält.

Wie gesagt, der Speicherverbrauch ist vernachlässigbar.

Danke,
mein item ist aktuell folgendermaßen definiert:

Code: Alles auswählen

Number hz_mqtt_aussentemp "Aussentemperatur [%.1f °C]" <temperature> {channel="mqtt:topic:MQTTBrokerBSB:bsblan:aussentemp"}

openhab2 hat das item-tag noch nicht in influxdb geschrieben. So habe ich nun zwei verschiedene tag-Einträge je measurement in der influxdb.

Kann ich mit einem Befehl in der influxdb in einem messurement jedem Eintrag den gleichen Tag zuweisen damit die alten Daten genau so aussehen, wie die neuen?

Ändere ich das item auf:

Code: Alles auswählen

Number hz_mqtt_aussentemp "Aussentemperatur [%.1f °C]" <temperature> {channel="mqtt:topic:MQTTBrokerBSB:bsblan:aussentemp", influxdb="temperatur"]}

dann schreibt er in temperatur und speichert das item dazu als tag. Das wäre in Zukunft eine mögliche Umstellung.

iTob hat geschrieben: 3. Sep 2025 16:28 Kann ich mit einem Befehl in der influxdb in einem messurement jedem Eintrag den gleichen Tag zuweisen damit die alten Daten genau so aussehen, wie die neuen?

Warum solltest du das tun wollen? Das Measurement ist dasselbe. Es sind nur zwei Serien (mit und ohne Tag). Ich vermute, dass du aus openHAB heraus auch auf die alten Daten zugreifenn kannst, wenn du das willst.

Und ein "select value from hz_mqtt_aussentemp" wird dir alte wie neue Daten liefern.

Ansonsten könnte folgendes gehen (nicht ausprobiert).

Sichere alte Daten ohne Tag in ein anderes Measurement: select * into temp from hz_mqtt_aussentemp where item is null
Lösche alte Daten ohne item: delete from hz_mqtt_aussentemp where item is null
Füge erneut ein (sollte automatisch das item - Tag hinzufügen): select * into hz_mqtt_aussentemp from temp
Lösche temp: delete from temp

Ohne Gewähr. Speziell bei Schritt 3 bin ich mir nicht sicher.

Anfangs hatte ich Anpassung der Measurement- und Tag-Namen per Konfguration gearbeitet, aber dann keinen Vorteil gesehen. Inzwischen lasse ich die Quelldaten unverändert und erstelle neue Measurements nach Bedarf.

My 2 Cents:

Tags in InfluxDB sind lediglich für InfluxDB "wichtig", in dem Sinne, dass man sie dort nutzen kann. Natürlich kann man auch z.B. über Grafana entsprechende Funktionen verwenden.
Für openHAB spielen die Tags zumindest bisher hingegen keine Rolle, sie werden also lediglich gesetzt, nicht aber genutzt.

Tags sind eine spezielle Funktion in InfluxDB, vermutlich gibt es auch noch andere Datenbanken, die so etwas können, viele andere aber können das nicht. openHAB verwendet gewöhnlich nur Grundfunktionen der Datenbanken, also Datensatz anlegen und Datensatz auslesen, eine einfache Abfrage (Datensätze innerhalb eines Zeitraums, Summe, Min/Max usw.), aber keinesfalls Spezialfunktionen, da die Bindings möglichst universell sein sollen.

Die Tags zu schreiben ist ok, weil sie "ehda" sind, so können nachgelagerte Systeme sie nutzen.
Viel Energie zur Konsolidierung der Daten würde ich aber nicht investieren, gewöhnlich werden die Daten ja nach einem Jahr gelöscht (default retention policy)

Das Tag wird aktiv von openHAB gesetzt, insofern denke ich, dass beim Zurückschreiben der Daten in die "Originalspalte" das Tag auch mit angegeben werden muss. Da müsste man in der Doku von InfluxDB nachschauen, wie das geht.
Eine erste Recherche "auf die Schnelle" liefert hier https://stackoverflow.com/questions/451 ... n-influxdb die Info, dass die Datensätze einzeln geschrieben werden müssen.
Es gibt wohl auch ein Tool (InfluxDB Fetcher mit dem man Datensätze im Line Protocol Format exportieren kann. Damit kann man dann das Tag per Text Editor ergänzen ("ersetze Zeilenumbruch mit tag=blah Zeilenumbruch") und die Daten anschließend über die UI neu importieren. Ist zwar nicht sonderlich elegant, aber vielleicht die einfachste semimanuelle Variante.

Ich nutze aktuell noch mein openhab 2.5.12 mit influx1.8 und grafana 11.4.

Nun habe ich parallel dazu im Docker der Reihe nach die Updates gemacht. Vermutlich seit openhab3 schreibt er die Tags mit.
Aufgefallen ist mir das erst nach dem Update von influx auf die 2.7. Ich musste Grfana von InfluxQL auf Flux umstellen und nun zeigt er die Daten mit und ohne tag als zwei getrennte Reihen an. Ist kein Riesen Drama - aber ich möchte es eben gern verstehen und vieleicht anpassen.

Eine "alte shell" kann ich unter influxdb2 noch mit

Code: Alles auswählen

 influx v1 shell

starten. Dort funktioniert zwar noch ein

Code: Alles auswählen

select

, aber ein

Code: Alles auswählen

into

funktioniert nicht mhr.

Nun muss ich mich wohl erst mal mit Flux befassen, um die Daten zu "manipulieren".

Oder ich erledige das noch in influxdb1.8
Dort funktioniert:

select * into temp from hz_mqtt_aussentemp where item = ''
delete from hz_mqtt_aussentemp where item = ''
select * into hz_mqtt_aussentemp from temp

da wird aber der Tag nicht hinzugefügt.
und Löschen der zwischengespeicherten Daten geht dann am Besten mit:

drop measurements temp

Mal sehen, ob ich dazu noch eine Anleitung finde, wie ich beim Umschreiben der Werte einen bestimmten Tag hinzugügen kann...

iTob hat geschrieben: 4. Sep 2025 21:31 Mal sehen, ob ich dazu noch eine Anleitung finde, wie ich beim Umschreiben der Werte einen bestimmten Tag hinzugügen kann...

Wenn der Tag mit "select into" nicht hinzugefügt wird, musst du die Points über insert einfügen. Es gibt ein besonderes Format, line protocol genannt, mit dem das zu bewerkstelligen ist.
Allerdings muss du, um das zu tun, wie von Udo beschrieben Code schreiben müssen.

Edit: Hatte die Sache mit Grafana überlesen, daher erste Zeile nun entfernt

Man könnte das wahrscheinlich auch über Tasks in der Influxdb WebUI anpassen.

https://docs.influxdata.com/influxdb/v2 ... t-started/

Aber einfacher wär sicherlich, die Abfrage der Daten in Grafana (die Filter) entsprechend anzupassen.

Thema "into". Es funktionieren einige InfluxQL Befehle in Influx 2 nicht mehr, hier eine Auflistung:

https://docs.influxdata.com/influxdb/v2 ... ql-support

Ich sammle die Daten nun seit über 5 Jahren und da währe es schön, die Reihen bleiben gleich.

Auf meinem originalen System läuft noch influxdb 1.8. Also könnte ich in influx1 mit dem Befhel into noch arbeiten. Aber ich habe nichts gefunden, wie ich bei into den Werten den tag zuweisen kann.

Ich kann mir das ja alternativ mal in influxdb2 mit Flux ansehen - vieleicht bekomme ich es da hin.

Du könntest auch folgenden Weg gehen:

Mit influx_inspect kannst du einen Export in Form des Line Protocol durchführen:

Code: Alles auswählen

influx_inspect export -datadir /var/lib/influxdb/data/ -waldir /var/lib/influxdb/wal/ -out <export_datei> -database openhab

wobei die <export_datei> auch - für stdout sein kann. Die Pfade müsstest du anpassen, wenn sie bei dir anders sind.

Damit kannst du den Output auch auf ein Measurement beschränken:

Code: Alles auswählen

influx_inspect export -datadir /var/lib/influxdb/data/ -waldir /var/lib/influxdb/wal/ -out - -database openhab | grep <Measurement>

Diese Datei sieht dann bspw. so aus:

Code: Alles auswählen

WP_W,item=WP_W value=6.9039998054504395 1724025718925000000
WP_W,item=WP_W value=6.579999923706055 1724025778868000000
WP_W,item=WP_W value=6.363999843597412 1724025838816000000
...

Bei dir dürfte dann bei einigen Zeilen das ",item=..." fehlen. Das musst du dann ergänzen.

Dann fügst du zu Beginn die beiden Zeilen

Code: Alles auswählen

# DML
# CONTEXT-DATABASE: openhab

hinzu und importierst die Datei mittels

Code: Alles auswählen

influx -host <hostname> -username <username> -password <password> -import <import_datei>

wieder. Danach liegen die Points, die zuvor kein Tag "item" hatten, zwei Mal vor, mit und ohne Tag.

Du brauchst dann nur noch die Points ohne Tag zu löschen:

Code: Alles auswählen

delete from <measurement> where item is null

Unnötig zu sagen, dass du das an nicht-produktiven Daten testen solltest.

Ich nutze influx_inspect in dieser Form fürs Backp und die Migration. Ob das so mit influxdb v2 funktioniert, weiß ich nicht.

openhabforum.de

openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb

Re: openhab schreibt neuerdings eine zusätzliche Spalte in die influxdb