InfluxDB+Grafana Openhabian 3.2 Probleme mit InfluxDB

[udo1toni]

Jetzt werden ja alle items persistiert und es gibt somit keine influxdb.persist mehr, in dem man früher die Strategien konfigurieren konnte, korrekt?

Nein, das ist nicht korrekt. Es ist nur so, dass, wenn keine zum Service passende *.persist Datei gefunden wird, alle Items mit dem Default Verhalten persistiert werden (sollen). Warum das nun bei Dir nicht der Fall ist, ist schwer zu sagen. Aus jeden Fall kannst Du nach wie vor eine influxdb.persist im Ordner /etc/openhab/persistence/ anlegen, in der Du das gewünschte Verhalten einträgst.

Wie viele Items betrifft es denn, die nicht persistiert werden? Und wenn Du schreibst "andauernd ändern", von welchen Zeiträumen reden wir da? Weil Items sich nie "andauernd" ändern, es gibt Messzyklen, die kein sein mögen, aber es gibt eigentlich immer mindestens einige Sekunden, bevor ein Item erneut einen anderen Wert erhält...

[sami77]

Hallo Udo1toni,

vielen dank für deine Antwort!

Also das Item was ich ich visualisieren möchte ist mein Smart Meter, was die drei Phasen des Hauses misst. Es wird jedesmal ein ein Wert übertragen, wens sich beispielsweise die Leistung um 10W ändert, was bei einem Haus relativ oft vorkommt, also etwa alle 1-10sec.

Da alle Z-wave items durchnummeriert sind ist das smart meter an Stelle 65 und ich kann eben wie im BIld zu sehen nur bis 45 scrollen, d.h. das item nicht auswählen!

Ich versuche mal eine influxdb.persist mit der passenden Strategie zu erstellen, um zu sehen, ob es dann auftaucht!

Viele Grüße und nochmal danke!

Uwe

PS: Sorry for the delay! Ferien!

[udo1toni]

Ähm... es sollte reichen, den Itemnamen in die Liste einzutragen... Abgesehen davon möchte ich dringend empfehlen, Itemnamen so zu gestalten, dass Du sie sinnvoll nutzen kannst. Ein Item MyZWaveItemNo365 ist Bullshit, das Teil sollte Zaehler_Verbrauch heißen. Channel, die Du nicht benötigst, solltest Du überhaupt nicht mit Items verknüpfen. Nur weil ein Channel zur Verfügung steht, bedeutet das noch lange nicht, dass man ihn auch nutzen muss.

[sami77]

Das stimmt schon, ich habe nicht alle Channels zugeordnet, sondern (fast) nur die, die ich auch wirklich brauche. Das Bild zeigt die Aktor Typen und die Nummer, sie auch wirklich eindeutig identifizieren zu können. Ich habe 12 Rollo Aktoren und die haben ja auch alle die gleichen Channel, sind aber zwei Herstellertypen... Also das muss jeder selber wissen und hat auch eigentlich nix mit meinem Problem zu tun, oder?

Ich sage mal bescheid, ob das geholfen hat. Ich gehe davon aus, dass es da eine Begrenzung gibt und man irgendwo einstellen kann, wieviele Items da max. auswählbar sind...

Viele Grüße!

[udo1toni]

Nein, Grafana fragt die Datenbank ab und erhält eine vollständige Liste aller Items, die in der InfluxDB vorhanden sind. Die Liste im Drop-Down-Feld enthält alle Einträge, die auf den Filter passen, der eingegeben wird. Die Länge dieser Liste mag begrenzt sein, aber es sollte reichen, ein paar Zeichen einzugeben, die (exakt in dieser Reihenfolge) im Itemnamen vorkommen, also z.B. wenn ich ein Item HugenDubel0815 habe, sollte es ausreichen, Dubel081 zu tippen, um nur die Items angezeigt zu bekommen, die auch diese Zeichenfolge aufweisen, unter anderem also auch das gesuchte. Die Liste wird also dynamisch generiert, das funktioniert auch mit tausenden Items.

Was die Itemnamen betrifft, natürlich kann man die Namen beliebig gestalten. Es ist dann halt die Frage, ob man einen sinnvollen Weg genommen hat. Best practice an dieser Stelle ist aber, in openHAB zwei Bereiche zu trennen, das sind die Channel und die Items.

Addons bilden die Schnittstelle zur Hardware. Things sind die Entsprechung der einzelnen Geräte. Channel sind die einzelnen Funktionen oder Funktionsblöcke einer Hardware. Hier ist es also äußerst sinnvoll, die Namen entsprechend der Hardware zu wählen, und zwar immer auf die Ebene bezogen, in der man sich befindet. ChannelUIDs enthalten z.B. Addon und Thing, weshalb man beides keinesfalls in den Channel hineinschreibt.

Items bilden Funktionen und Zustände ab. Items sind vollständig hardwareunabhängig (im Rahmen ihrer Eigenschaften). Es ist egal, ob ein Dimmer nun mit knx, Homematic, MQTT, HTTP, ZWave, Zigbee oder noch einem anderen System arbeitet, das Item ist für all diese Dimmertypen identisch. Und für den Anwender sollte es - innerhalb der UI - keine Rolle spielen, welche Technologie nun beteiligt ist. Entsprechend kann man natürlich dem Item im Namen mitgeben, dass es sich um knx handelt, oder um ZWave, das sind aber an dieser Stelle komplett irrelevante Informationen, die nur Platz weg nehmen. Beim Item ist es wichtig, auf welchen Raum sich das Item bezieht und um welche Eigenschaft es sich handelt, also z.B. GF_Wohnzimmer_Stehleuchte. Mich interessiert an dieser Stelle im System nicht, ob die Stehleuchte über ZWave oder Zigbee läuft. Mich interessiert noch nicht mal, ob der Aktor in der Lampe eingebaut ist oder in der Leuchte. Wichtig ist nur, dass dieses Item die Stehleuchte im Wohnzimmer im Erdgeschoss steuert und deren Zustand anzeigt.

Ich habe schon beide Formen der Namensgebung (hardwarebezogen und funktionsbezogen) genutzt und denke, mir da nach zehn Jahren auch ein Urteil erlauben zu können
Und gerade innerhalb Garafana bin ich so weit weg von der Hardware. Ja, mich interessiert vielleicht die entnommene Leistung an einem Aktor. Aber es geht dabei ja nicht um den Aktor, sondern um den dort angeschlossenen Verbraucher. Und gewöhnlich werden die Verbraucher an einem Aktor nicht gewechselt. Wenn man das tut, wird man mit hoher Wahrscheinlichkeit ohnehin Änderungen an der Konfiguration vornehmen müssen.

[GreenRover]

Hallo ich habe das selbe Problem.
Ich habe von OH2 auf OH3 geupdated und nutze InfluxDB als long term speicher. Für last value nutze ich MapDB
Habe es geschafft das die Daten in der InfluxDB landen.
Was ich mit Grafana geprüft habe.

Ich habe in den Pages probiert die default charts zu nutzen.
Ich sehe zwar den aktuellen Wert aber das chart ist immer leer.

79F59FC5-F8C9-4CB6-89B0-4DED3AF98947.png

Code: Alles auswählen

component: oh-label-cell
config:
  action: analyzer
  actionAnalyzerChartType: day
  actionAnalyzerCoordSystem: time
  actionAnalyzerItems:
    - Kueche_Temp
  expandable: false
  item: Kueche_Temp
  stateAsHeader: true
  title: Temperatur
  trendItem: Kueche_Temp
  

Fragen:
- Geht Intlux db für die Pages?
- Falls ja, hat jemand ein sample?

[udo1toni]

Gewöhnlich wird für die Grafen in den Pages die Default Persistence herangezogen. Hast Du die Default Persistence auf InfluxDB gesetzt? (Main UI -> Adminitration -> Einstellungen -> System Services -> Persistence -> Default auswählen (mapDB wäre eher ungeeignet...).

[GreenRover]

Thx für die Antwort.
nein default ist mapDb. Weil ich last value für alles will und graphen nur für einige.
Kann man die zu verwenden db per parameter angeben?

Den ich habe das gefühl das Influx db für last value zugriff in rules eher langsam ist

[udo1toni]

Nein, das ist ein Missverständnis.
MapDB speichert ausschließlich den aktuellen Wert. Der einzige Sinn von MapDB ist also, wenn man in der mapdb.persist als Strategy everyChange, restoreOnStartup angibt. Ob man das für alle Items macht, sollte man sich gut überlegen, aber sei's drum, der Punkt ist, für diese Funktion setzt Du nicht die default Persistence.
In Rules auf mapDB zuzugreifen ist sinnlos, weil per Definition .state und .historicState(<belieibger Zeitpunkt>,"mapdb").state immer identisch sind (es sei denn, man setzt eben für die Items nicht everyChange als Strategy, sondern speichert den Status gezielt entweder über einen Time cron Ausdruck oder innerhalb einer Rule über Item.persist("mapdb"), womit dann der Zustand zu diesem Zeitpunkt persistiert wird.)

Ich gehe stark davon aus, dass es Dir um die Werte vor einem Neustart geht, die beim Systemstart wieder gesetzt werden sollen, das hat nichts mit der Default Persistence zu tun.

EDIT: Eine weitere potenzielle Anwendung wäre der Timestamp des letzten .persist() aber auch das ist eher speziell, im Fall der Strategy everyChange bekäme man die Timestamp auch über .previousState(true).timeStamp (oder so ähnlich)

[GreenRover]

Ok thx für den Hinweis.
Das hat mir viel weiter geholfen.

Ich denke ich baue die mapDb aus und mache alles mit influxDb