openhabforum.de

Die Datei hab ich gefunden. Hatte im "/etc/..." gesucht
Muss ich in der .persist alle einzeln eintragen? Oder reicht der "default"?


Danke

Du musst alle Items eintragen, die von der Persistence beachtet werden sollen. Entweder, Du setzt es für alle Items (mit einem einzelnen * vor dem Doppelpunkt) oder Du packst alle Items, die persistiert werden sollen in eine (oder mehrere) Gruppe(n) und persistierst die Member der Gruppe(n) (das wäre dann der/die Gruppenname(n) mit einem Stern hinten dran, z.B. MeineGruppe wird dann in der *.persist Datei als MeineGruppe* angegeben, damit werden dann statt der Gruppe selbst ihre Member persistiert).
Oder Du gibst einzelne Items an (wie in Deiner Datei sZuhause).

Speicherorte im System: In unixoiden Systemen gibt es traditionell eine Aufspaltung der Daten nach Funktion. Konfigurationsdateien liegen unter /etc/, Log-Dateien unter /var/log/, temporäre Dateien (die nach einem Neustart einfach weg sein können) unter /tmp/, Programme unter /usr/, Userbezogene Daten unter /home/<userverzeichnis>/ Systemprogramme unter /bin/, Systemprogramme, die nur root ausführen darf unter /sbin/ und so weiter.

Mit openhab-cli info kannst Du Dir direkt anzeigen lassen, welche Verzeichnisse openHAB konkret nutzt.
Tricky in dem Zusammenhang, wenn man nicht an das Modell gewöhnt ist: openHAB kennt die statischen Konfigurationsdateien (liegen in /etc/openhab/* und für den Dienst selbst unter /etc/default/), aber auch solche, die zur Laufzeit des Programms von openHAB selbst erstellt und verändert werden, diese sind dann per Definition Userdaten, also liegen sie unter /var/lib/openhab/, weil es variable Dateien sind. Persistenz-Daten werden ebenfalls zur Laufzeit von openHAB erzeugt und liegen entsprechend ebenfalls an dieser Stelle.

Die Aufteilung hat ganz konkrete Vorteile: Man kann deshalb die verschiedenen Daten wunderbar unterschiedlich speichern. /tmp/ .z.B. kann man einfach in eine RAM-Disk packen und vergessen. Nach einem Neustart sind die Daten weg, so what, sie waren eh temporär. /boot/ als Bereich, in dem alle relevanten Daten zum Systemstart untergebracht sein müssen (bis zu dem Punkt, wo systemd läuft und die wichtigsten Dateisysteme eingebunden sind), kann ein anderes Dateisystem nutzen als der Rest des Systems (z.B. FAT32 statt ext4) und es können sogar komplexe Dinge wie LVM, Software RAID oder auch Verschlüsselung eingebunden werden. /home/ könnte man in einem größeren Netz ohne Weiteres auch über NFS einbinden, so dass die Daten gar nicht erst lokal gespeichert werden, sondern direkt auf einem Server liegen, der die Daten ganz unabhängig vom Login zur Verfügung stellt.

udo1toni hat geschrieben: ↑25. Jan 2022 13:25 Du setzt es für alle Items (mit einem einzelnen * vor dem Doppelpunkt)

Das scheint mir für die Zustände am sinnvollsten

udo1toni hat geschrieben: ↑25. Jan 2022 13:25 oder Du packst alle Items, die persistiert werden sollen in eine

Lieber nicht. Da steig ich irgendwann nicht mehr durch. Habs zwar alles in Textdateien...aber das wird dann trotzdem riesig. In der aktuellen Ausbaustufe sind alleine im ZigBee2Mqtt 102 Geräte.

HiG hat geschrieben: ↑25. Jan 2022 15:57 Das scheint mir für die Zustände am sinnvollsten

Ja, aber nein. Es gibt in einem Automationssystem jede Menge Zustände, bei denen es nicht sinnvoll ist, einen Zustand von "irgendwann" zu nutzen. Ich habe hier knx verbaut und (meiner Meinung) auch korrekt parametriert. In der Folge kann openHAB beim Start alle relevanten Zustände aktiv abrufen. Egal welchen Zustand ein Schaltausgang, Dimmer, Rollladen, Temperaturfühler... hat, dieser wird unmittelbar korrekt angezeigt. Warum sollte ich solche Werte über die Persistence künstlich mit einem potentiell falschen Wert wiederherstellen?

Wie gesagt, es ist eigentlich simpel, das vernünftig zu lösen. Lege eine Gruppe gMapdb an, setze in der mapdb.persist
gMapdb* : strategy = everyChange, restoreOnStartup
und packe alle Items, die das betrifft, in diese Gruppe (auch zusätzlich zu beliebigen anderen Gruppen).
Das ist weder aufwändig noch fehlerträchtig, Du kannst sogar am sprechenden Namen der Gruppe sofort erkennen, wozu das Item in der Gruppe ist.

udo1toni hat geschrieben: ↑25. Jan 2022 17:19 und packe alle Items, die das betrifft, in diese Gruppe

wieviele Gruppen kann ich denn einem Item zuordnen?? Das Beispiel liesse sich ja noch etwas "erweitern"

HiG hat geschrieben: ↑25. Jan 2022 17:40

Code: Alles auswählen

Dimmer gKuecheSpot20         "Spot 20"                          <light>             (gKuecheLights,gDimmer,gKuecheDimmer,gEG_Dim,gEG_KU_Sp_Dim,gKitchenAll_SW,gKitchenKochen_SW,....................)                         ["Lightbulb"]                           {channel="hue:0220:001788a2dba6:46:brightness"}

Das Beispiel liesse sich ja noch etwas "erweitern"

Wow

Warum sollte 1 Item in sooo vielen Gruppen sein? Würde mich interessieren.
2-3 oder in Einzelfällen auch mal 4, aber bei Dir ist da ja kein Ende.

Umgekehrt ist das schon anders, da sind dann z.B. 27 Lampen in 1 Gruppe.

Ich kann ja mal versuchen "aufzudröseln"...vielleicht mach ich es mir ja auch zu umständlich. Küche ist natürlich mit 21 Leuchten auch schon etwas... naja

gKuecheLights = Gruppe unter der die im Model angeordnet sind
gDimmer = Teil aller dimmbaren Leuchten im Haus
gKuecheDimmer =Teil aller dimmbaren Leuchten in der Küche
gEG_Dim = ....... im EG
gEG_KU_Sp_Dim = aller dimmbaren Spots
gKitchenAll_SW = Alle Leuchten in der Küche auf einmal aus
gKitchenKochen_SW=nur die zum Kochen benötigten

und dann kommen noch unterschiedliche "Lichtszenen" dazu...

Wie gesagt...gerne andere Lösungswege. Ich möchte ja das System hinter OH verstehen.

Grundsätzlich ist die Anzahl der Gruppenzugehörigkeiten unbegrenzt.
Gewöhnlich wird man Gruppen aber auch hierarchisch organisieren, also alle Dimmer der Küche in gKuecheDimmer, die Gruggen der Dimmer von Küche, Wohnzimmer usw. in der Gruppe g_EG_Dim, alle Stockwerksgruppen in der Gruppe gAlle_Dimmer. Innerhalb einer Rule verwendet man dann gAlle_Dimmer.allMembers.forEach[...] um alle Dimmer gemeinsam anzusteuern.
Wenn man in OH3 das semantische Modell korrekt konfiguriert, tauchen die Dimmer an den verschiedenen Stellen automatisch auf (also bei Equipment alle, im Raum die einzelnen Dimmer gemeinsam mit den restlichen Devices des Raums.

Du kannst die Gruppen so verwenden, wie Du willst, letztlich kommt es ja nur darauf an, was Du erreichen möchtest. Und welcher Weg dann der eleganteste ist, kann nicht pauschal beantwortet werden. Aber ob Du nun ein Item in 15 oder 16 Gruppen zuordnest, ist unterm Strich dann auch egal

udo1toni hat geschrieben: ↑25. Jan 2022 21:00 Du kannst die Gruppen so verwenden, wie Du willst, letztlich kommt es ja nur darauf an, was Du erreichen möchtest.

#hachmach... ich bin frei in meinen...ja...was denn eigentlich??

Hallo zusammen,
ich hätte da mal eine Frage.
Ich würde ebenfalls gerne sämtliche items persistieren um nach einem Neustart den letzten Zustand dieser wiederherzustellen.
Ist die Funktion auf einen Switch beschränkt oder können z.B. auch:

- Heizmodus meiner Thermostate (0=Aus, 1=Heizen)?
- Letzte eingestellte Temperatur der Thermostate?
- Ventilstellung in %?
- Jalousie Position in %?
- Letzte Öffnung eines Fensters?
- Gruppen-item ?
- Batteriezustände?

gespeichert und wiederhergestellt werden?

Für die Speicherung von Verbrauchsdaten (Aktuell sowie der Gesamtverbrauch) ist dann rrd4j oder influx die richtige Wahl?