- √ - wiregated segfaulted laufend

[greentux]

Wofür bräuchte man über einen Reboot hinausgehende persistente Speicher?

[JuMi2006]

Für Plugins:

- letzter Sollwert eines Raumreglers
- Zählerstände, Betriebsstundenzähler (das wäre jetzt mein Anwendungsfall)
- Stati die übers WG gesendet werden und nicht über KNX wieder auslesbar sind
- letzte Ausführung von xyz
- Austausch von Daten zwischen Plugins (Weitergabe an Visu)

Das kann man letztlich mit $plugin_info($plugname,'_meinIKO') alles speichern aber wenn sich die plugin.db verabschiedet ist das auch alles weg.
Ausserdem sieht iko_read(RT_soll_Kind) besser aus und man muss sich nicht den Namen des Plugins merken aus dem der Wert kommt.

Anwendungsfall:
Die Zählerstände kommen vom Bus, jetzt müsste ich mir irgendwohin den Tageswert schreiben und am nächsten Tag wieder aufrufen um eine Differenz zu bilden. Diese könnte ich mir aber ganz einfach in ein iko schreiben und nächsten Tag wieder auslesen...bei einem Tag ganz unproblematisch, bei einer Woche oder einem Monat schon schwieriger.

[chriss1980]

Das kann man letztlich mit $plugin_info($plugname,'_meinIKO') alles speichern aber wenn sich die plugin.db verabschiedet ist das auch alles weg.
Ausserdem sieht iko_read(RT_soll_Kind) besser aus und man muss sich nicht den Namen des Plugins merken aus dem der Wert kommt.

Du kannst die Daten doch auch mit $plugin_info{'RT_soll_Kind'} ablegen. Dass der Plugin-Name vorgestellt wird ist nur eine Empfehlung, wahrscheinlich um Kollisionen zwischen verschiedenen Plugins zu vermeiden.
BTW, auch hinter der von Dir vorgeschlagenen Funktion iko_read/write müsste irgendeine Form der Datenablage (aka Datenbank) liegen. Wenn sich die verabschiedet sind die Daten wieder weg. Ich verstehe also nicht, warum eine neue Funktion die Datensicherheit vergrößern sollte.

Schöne Grüße
Christian

ps: Ist ein Fehler in plugin.db eigentlich ein häufigeres Problem oder eher ein Einzelfall (vgl. aktueller Thread)?

[greentux]

Vl. nimmt man da mal wirklich ne SQLite und baut ne WG API drum rum, so dass jedes Plugin einfach speichern kann, was es will.

Die ganzen Messwerte bekomme ich derzeit aus den RRDs Auch nur eine Datenbank.

Statuus die das WG sendet, aber nicht abfragbar sind, sollten ja zumindest regelmässig gesendet werden, oder?

Und WG und Visu würde ich nicht so arg verknüpfen. Das muss ja nicht mal auf der gleichen Kiste laufen. Derzeit schon mit den RRDs problematisch.

[JuMi2006]

@greentux:
Womit holst Du die Daten aus dem RRD, da fehlt mir noch ein Beispiel. Kannst Du das evtl. mal zeigen?

Zum plugin_info:
Das räume ich ab und zu mal auf ... wenn man ein neues Plugin testet hat es u.U. noch einen anderen Namen und andere Werte ... will man sich dann durch die "Debug-Tabelle" quälen wird es eklig. Bei derzeit knapp 20 Plugins sucht (scrollt) man sich den Wolf.
Gernerell fände ich es besser wenn Laufzeitabhängige Variablen (_cylce,_last) die der Daemon benutzt nicht in einer Datenbank mit "privaten" Variablen abgelegt werden. Der Umstieg auf eine mySQL wäre daher begrüssenswert. Im Daemon wären das geschätzt nicht mehr als 20 Zeilen Code für eine Trennung.

Wenn sich die DB verabschiedet ist eh essig, das ist klar. Generell ist das natürlich alles jetzt schon möglich. Ein iko_write/read würde aber Plugins übersichtlicher machen. Dass es bei plugin_info keines Namens bedarf wusste ich nicht.

Gruß

[chriss1980]

@greentux:
Womit holst Du die Daten aus dem RRD, da fehlt mir noch ein Beispiel. Kannst Du das evtl. mal zeigen?

bei den Plugins gibt es Beispiele, schau z.B. mal hier: SourceForge.net Repository - [openautomation] Contents of /wiregate/plugin/generic/MinMaxValueFromRRDtoGA.pl

Der Umstieg auf eine mySQL

ich hoffe, Du meinst SQLite

Im Daemon wären das geschätzt nicht mehr als 20 Zeilen Code für eine Trennung.

Warum nicht einen Patch entwickeln? Bei Elabnet besteht ja durchaus die Bereitschaft, Weiterentwicklungen in das Produkt aufzunehmen

[JuMi2006]

ich hoffe, Du meinst SQLite

Sag ich doch die ganze Zeit

Warum nicht einen Patch entwickeln? Bei Elabnet besteht ja durchaus die Bereitschaft, Weiterentwicklungen in das Produkt aufzunehmen

Den wiregated überblicke ich nicht ... das ist mir zu heftig...war ja auch nur ne Anregung falls makki das auf ne SQL umstrickt das vielleicht noch mit einzubinden.
Bislang komme ich auch ohne zurecht, würde aber einiges leichter machen...

Gruß

[StefanW]

ps: Ist ein Fehler in plugin.db eigentlich ein häufigeres Problem oder eher ein Einzelfall (vgl. aktueller Thread)?

Ich würde - aus dem Gedächtnis - eine handvoll berichteter Vorfälle von korrumpierten DBs schätzen, also kein sehr häufiges oder gravierendes Problem.

Aber für den Betreffenden dann durchaus lästig und wir wollen das schon gerne lösen.

lg

Stefan

[Chris M.]

Und wenn Du richtig Angst um die DB hast, sollte sich die doch per Cron oder Plugin mit langer Cycle-Time wegsichern lassen...

Ich halte es aber für sinnvoller die Plugins so zu schreiben, dass die sich sinnvoll selbst initialisieren.
Klar ist's doof wenn nach einem Desaster-Fall alle Soll-Raumtemperaturen weg sind - aber wenn die sich dann mit 21°C initialisieren, ist der entstandene Schaden sehr überblickbar.

[greentux]

Auftreten tut das ja auch erst, seitdem die Plugins wie wild dort Daten sichern. Früher (tm) war ein Plugin noch ein Plugin

Ich bin da ganz bei Chris. Man solle sich nicht so abhängig machen...

[JuMi2006]

Angst hab ich keine ... wäre aber ein "nice to have" gewesen ... bislang gibts bei mir nicht mal Stellmotoren im HKV

[makki]

Featurewunsch:
Eine persistent-Datenbak. Etwas wohin mal Variablen aus Plugins schreiben kann ohne dass sie verloren gehen.

Wurde zwar schon gesagt aber: GENAU DAS tut $plugin_info..

Dass der Plugin-Name vorgestellt wird ist nur eine Empfehlung, wahrscheinlich um Kollisionen zwischen verschiedenen Plugins zu vermeiden.

Jein. Der Hauptgrund ist das man gerne irgendwann aufräumen wollen wird, weil da Leichen liegen; aktuell nur manuell aber der Plan wäre das automatisch zu machen (alles wozu es kein Plugin mehr gibt, ausser "Global_..")

Makki

[JuMi2006]

Das benutze ich ja schon regelmäßig, ich wollts nur in "übersichtlich" in einer extra Datenbank.

Gruß

[makki]

Hmm, das braucht jetzt aber Überzeugungsarbeit:
Warum sollte es zwei Datenbanken geben, die exakt dasselbe tun?

Ich kann mir einen "Wrapper" für $plugin_info vorstellen (die Idee ist schon älter) - ansonsten: hey es ist 100% offen&echt, man kann sich auch jetzt schon seine eigene sqlite-db pro Plugin anlegen (nicht das es sonders effizient wäre - aber möglich.. siehe RSSlog)

Edit: der Unterschied ist: die eigene DB kann ich mitm nächsten Update nicht automagic reparieren

Makki