LSB Variablen remanent speichern

[phili]

Hallo zusammen,
ich habe schon ein wenig recherchiert und mir auch schon andere Lösungen in LBS angeschaut. Nun möchte ich aber noch einmal konkret nach der günstigsten Lösung für mein Problem fragen:

Ich möchte in einem LBS daten remanent speichern. So wie z.B. in dem von wintermute vorgestellten Betriebsstundenzähler. In dem Baustein wird ja in der aktuellen Fassung über die iKO-ID direkt auf edomis mysql-Datenbank zugegriffen.
Ist das die günstigste Lösung? Mir wäre es z.B. nicht so wichtig, dass ein iKO angegeben werden müsste. Es genügte, wenn die remantenten Daten direkt mit der Baustein ID verknüft wären.

[jonofe]

Von welchen remanenten Daten sprechen wir denn?
Grundsätzlich lässt sich das über ein remanentes iKO lösen, welches du dann über einen LBS Eingang einliest.
Oder wie schon erwähnt über die iKO-ID. Oder aber speichern im Filesystem. Oder auch direkt in einer mySQL Tabelle.

Die optimale Lösung hängt immer von der Problemstellung ab. Vielleicht kannst du das Problem etwas konkreter beschreiben.

[phili]

Hallo Andre,
also es soll eine "Kopie" des Lichtszenen-Baustein des HS werden (https://knx-user-forum.de/forum/%C3%...8043#post88043). Für jede der 128 möglichen Szenen müssten dann 5 Aktorwerte gespeichert werden. Also ich vermute, dass es ein Array von 128 Elementen wird. Jedes Element beansprucht vermutlich 1 Byte (das scheint bei PHP aber wohl ersteinmal egal zu sein).

Von welchen remanenten Daten sprechen wir denn?
Grundsätzlich lässt sich das über ein remanentes iKO lösen, welches du dann über einen LBS Eingang einliest.

Dann müsste ich das iKO aber (zusätzlich zum Eingang) auch am Ausgang bereitstellen, damit ich es beim Abschluss des LBS wieder speichern könnte, oder?

[jonofe]

Ja, du kannst es z.B. als JSON String auf den Ausgang schreiben (wenn du eine Szene änderst). An dem Ausgang ist dann ein remanentes iKO. Dasselbe dann an einem Eingang, an dem du dann ein JSON-decode machst und deine Szenen Datenstruktur initialisierst. Wichtig ist nur, dann dieser Eingang den Ausgang nicht triggert (muss er aber auch nicht). Das der Eingang beim Update einer Szene getriggert wird ist kein Problem, lediglich ein wenig Overhead.

[phili]

Danke für die gute Auskunft.

Können wir noch mal die verschiedenen Vorschläge zur remanenten Datensicherung vergleichen?

Ich versuche mal meine Gedanken dazu zu notieren:

Grundsätzlich lässt sich das über ein remanentes iKO lösen, welches du dann über einen LBS Eingang einliest (und auch auch dierekt wieder ausgibst).

Günstig bei geringen Datenmengen, die man prinzipiell gut in einem iKO abspeichern kann. Wahrscheinlich keine Daten, die von einer Streaming-Quelle geliefert werden (Kamera, ...)

Oder wie schon erwähnt über die iKO-ID

Scheint identisch zu der Lösung oben zu sein, nur mit dem Vorteil, dass es nur einen Eingang mit der ID des iKO benötigt.
Evtl. Nachteil: Variable muss existieren, es gibt keine direkt Verknüpfung im Logikeditor?

Oder aber speichern im Filesystem

Günstig bei große Datenmengen?

Oder auch direkt in einer mySQL Tabelle.

Zugriff von extrenen Quellen außerhalb von Edomi?

[wintermute]

Also.... der Betriebsstunden-LBS speichert erstmal nichts (remanentes), das muss das betreffende KO von sich aus hergeben. Er liest nur aus eben diesem KO beim Init einen Startwert aus. Das ist also generell schonmal eine andere Herangehensweise an die Problematik oder eigentlich ein ganz anderes Problem als oben aufgefuehrt.
Es macht (IMHO und wie woanders schonmal geschrieben) auch wenig Sinn wenn dieser LBS irgendwelche Daten "fuer sich" remanent speichert, denn es gibt ja bereits ein remanentes KO in dem der gewuenschte Wert liegt, alles was jetzt nochmalig irgendwo zwischengespeichert werden wuerde, waere nicht nur remanent sondern vor allem auch remanent-redundant

Wie André schon geschrieben hat: wie man das am besten macht haengt von der konkreten Problemdarstellung und der eigenen, bevorzugten Vorgehensweise ab. Ich finde fuer den Betriebsstunden-LBS ist das so schon der richtige Weg, vor allem deswegen weil das benoetigte KO ja bereits irgendwo existieren muss.
Wie in dem anderen Thread geschrieben: ein min/max LBS der Werte remanent speichert waere wohl ein besserer archetypischer LBS fuer sowas, wenn dort nur min ODER max irgendwo in einem KO abgelegt wird; der LBS muss intern aber beides kennen. Sind fuer den Benutzer aber ohnehin beide Werte von Interesse, so sind ja als KO bereits vorhanden und demzufolge waere es auch dort am sinnvollsten, einfach die bereits vorhandenen KOs beim init auszulesen anstatt sie nochmal irgendwo (wo auch immer) redundant abzulegen. Schon allein deswegen weil in dem Fall vermutlich nicht ohne weiteres sichergestellt werden kann, dass die entsprechenden KOs dann auch identische Werte vorhalten - beziehungsweise bereits allein dafuer ein wesentlicher Aufwand betrieben werden muss.

Wenn es jetzt um groessere Datenmengen geht, auch da gibts unterschiedliche Anforderungen (ich nehme mal Beispiele basierend auf meinen LBS, da ist es einfacher fuer mich ):
-Entweder sind es Daten, die man eh irgendwo her bekommt, zB die Liste aktuell verbundener Player und deren Playlisten an einem LMS. Die holt man beim Systemstart eh komplett neu, redundant macht da keinen Sinn, schon allein deswegen weil der aktuelle Zustand "woanders" festgelegt wird.
-Oder es sind Daten, deren Aktualitaet nicht wirklich lebenswichtig ist, bei denen aber "die Beschaffung" mit Aufwand verbunden ist, zum Beispiel Wetterdaten (siehe Weather Underground LBS Sammlung). Da macht es mitunter Sinn die Sachen als File abzulegen oder einfach neu abzurufen, aber das in die Datenbank zu packen ist nur mit unnoetigem Aufwand verbunden. Der einzige Vorteil waere, dass die Daten in einem Backup enthalten sind, wo sie aber ebenso voellig ueberfluessig sind.
-Oder aber es sind Daten, die Edomi selbst vorhaelt, manipuliert und verschickt - so habe ich das aktuelle Szenario verstanden. In meinen Augen waere aber auch dort das Zwischenspeichern des aktuellen Zustandes in einem File sinnvoller, als das irgendwo in der Datenbank einzurollen.

Also auch nach laengerer Ueberlegung ist mir noch immer nicht klar geworden wieso ein LBS unbedingt "fuer sich" irgendwelche KOs dafuer missbrauchen sollte interne Daten zu speichern. Der Sinn eines KOs ist ja, dass man anderweitig darauf zugreifen kann - es lesen und veraendern kann, also vor allem auch ohne den "zugeheorigen" LBS bemuehen zu muessen. In den bisherigen Szenarien ist das IMHO generell keine optimale Vorgehensweise, darum bin ich erstmal wieder davon ab irgendwelchen Beispielcode dafuer zu schreiben.

2¢ :: Michael

[phili]

Hallo Michael,
danke für diesen sehr ausfürlichen Beitrag!

Also.... der Betriebsstunden-LBS speichert erstmal nichts (remanentes), das muss das betreffende KO von sich aus hergeben. Er liest nur aus eben diesem KO beim Init einen Startwert aus. Das ist also generell schonmal eine andere Herangehensweise an die Problematik oder eigentlich ein ganz anderes Problem als oben aufgefuehrt.

Ja, das ist von Dir deutlich treffender formuliert und wie es scheint, ist die Remanenz eben nur gegeben, wenn man eben ein als remanent gesetztes iKO verwendet bzw. direkt über den Datenbankzugriff geht.

Es macht (IMHO und wie woanders schonmal geschrieben) auch wenig Sinn wenn dieser LBS irgendwelche Daten "fuer sich" remanent speichert, denn es gibt ja bereits ein remanentes KO in dem der gewuenschte Wert liegt, alles was jetzt nochmalig irgendwo zwischengespeichert werden wuerde, waere nicht nur remanent sondern vor allem auch remanent-redundant

Wenn ich das iKO aber nicht nach außen führe sondern den Baustein dazu nötige, einen Eintrag in der ko-Datenbank zu erzeugen, welches dann dem Remanentspeicher für den Baustein entspricht, dann habe ich keine "Remanent-Redundanz". Unschön dabei ist natürlich, dass hier verschleiert wird und die iKOs nach einem möglichen Löschen der Baustein-Instanz wieder entfernt werden müssten.

Wie André schon geschrieben hat: wie man das am besten macht haengt von der konkreten Problemdarstellung und der eigenen, bevorzugten Vorgehensweise ab. Ich finde fuer den Betriebsstunden-LBS ist das so schon der richtige Weg, vor allem deswegen weil das benoetigte KO ja bereits irgendwo existieren muss.

Finde ich auch geschickt, vorallem, weil der Baustein dann direkt selbst in die Variable schreibt, die das remanente iKO ist (sein kann). Das machen aber nicht alle Bausteine. Der zu speichernde Zustand kann sicher nicht immer in einer Variablen abgelegt werden (sie an einem Ausgang hängt).

Also auch nach laengerer Ueberlegung ist mir noch immer nicht klar geworden wieso ein LBS unbedingt "fuer sich" irgendwelche KOs dafuer missbrauchen sollte interne Daten zu speichern.

Würdest Du denn bei einem Baustein, der ein Gedächtnis über einen edomi-Neustart hinweg benötigt, die Gedächtnis-Daten aber nicht wie Dein Betriebsstundenzähler am Ausgang bereitstellt, den Zugriff auf das erforderliche, remanente iKO lesend und schreibend über einen SQL-Zugriff erledigen?

[wintermute]

danke für diesen sehr ausfürlichen Beitrag!

Gleichfalls

Ich beziehe mich mal (ganz bewusst ) nur auf den letzten Absatz:

Würdest Du denn bei einem Baustein, der ein Gedächtnis über einen edomi-Neustart hinweg benötigt, die Gedächtnis-Daten aber nicht wie Dein Betriebsstundenzähler am Ausgang bereitstellt, den Zugriff auf das erforderliche, remanente iKO lesend und schreibend über einen SQL-Zugriff erledigen?

Nein, wuerde ich nicht. Daten die nur vom LBS (intern) benoetigt werden, wuerde ich persoenlich immer in einem File ablegen. Das ist IMHO flexibler und mit weniger Overhead belastet als ein Datenbankzugriff. Zudem erspart man sich die Probleme mit den iKO-Leichen nachdem der LBS geloescht wurde und Detaildinge wie passende Kodierung und eventuelle Laengenbeschraenkung beim iKO, ueberdies wird der Code weniger komplex und leichter nachvollziehbar.
Da bleibt natuerlich der "Nachteil", dass die Daten nicht in einem Edomi-Backup enthalten sind. Ich kann mir grad kein Szenario denken bei dem das erforderlich sein wuerde - was natuerlich nix heissen mag - und schaetze die generelle Notwendigkeit dafuer als sehr gering ein.

Koenigswege gibts da vermutlich nirgendwo, aber ich finde in den allermeisten Setups reicht es durchaus dei Daten in einem /tmp File abzulegen und beim Systemstart einzulesen; das waere jedenfalls die Art auf die ich das loesen wuerde. Auf Systemen auf denen mal zufaellig grad kein Edomi laeuft wuerde ich auch nicht extra eine relationale Datenbank nachinstallieren um interne Daten von Skripten zwischen zu speichern

Aber das ist nur meine Meinung

[phili]

Hallo Michael,

Daten die nur vom LBS (intern) benoetigt werden, wuerde ich persoenlich immer in einem File ablegen.

Welches Verzeichnis würde sich unterhalb der edomi-Dateistruktur anbieten?

[wintermute]

Welches Verzeichnis würde sich unterhalb der edomi-Dateistruktur anbieten?

/tmp

IMMER /tmp

Und da moeglichst irgend was Eindeutiges, also ich nehme zB immer /tmp/EDOMI_LBS<LBS#>.<LBSID>.<TYP> wobei:
-LBS# zB 19000xyz ist
-LBSID die interne ID des LBS ist (die er selber feststellen kann)
-TYP der Typ File ist, also zB "txt", "json", "xml", "whatever"

Der Filename laesst sich natuerlich erweitern, klar. Aber um das /tmp kuemmert sich normal das OS von alleine (also von wegen Garbage Collection und so) und wenn man etwas Stringenz bei der Benamung walten laesst, kommt sich da normal auch nix ins Gehege
Es reicht also das File anzulegen und (wenn vorhanden) zu lesen, loeschen wenn zu alt oder sowas in der Art kann man dann vernachlaessigen.

HTH :: Michael

[phili]

Ja, danke!

Ich habe bisher nicht mit CentOS gearbeitet. Bei meinen Debian-Systemen wird /tmp beim reboot immer geleert. Das wäre hier natürlich nicht so günstig.

[wintermute]

Bei meinen Debian-Systemen wird /tmp beim reboot immer geleert. Das wäre hier natürlich nicht so günstig.

Err... ich bin eigentlich kein Freund (eher ein Gegner) von Debian-basierten Systemen, aber AFAIK wird seit 2010 oder so (und das ist ja IT, also so wie Hundejahre - also seit gefuehlt knapp 50 Jahren ) beim Reboot nur das aus dem /tmp geworfen was aelter ist als das in /etc/tmpfiles.d/conf (oder so aehnlich) angegebene Haltbarkeitsdatum.
Das mag bei speziellen System (Raspian oder so) unterschiedlich sein, vornehmlich dann, wenn /tmp ein ram-based-FS ist.
Ich mag mich da aber irren, wie gesagt bin ich nicht so fit in diesen Distributionen...

Wie auch immer: bei (Edomi-)CentOS6 sollte das nicht der Fall sein, CentOS benutzt tmpwatch (gestartet via cron.daily) - sofern installiert. Was bei der Minimalinstallation AFAIK aber gar nicht zutreffend ist

Aber - um das Distributions-uebergreifend und damit dem FHS entsprechend in Stein zu meisseln: nimm /var/tmp, das enthaelt gemaess Standard vor allem die temporaeren Dateien die einen Neustart ueberleben sollen. Das sollte also auch mit reinen RAM-based Distributionen funktionieren - wenngleich ich mir das nicht wirklich vorstellen kann