Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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
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_..")
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.
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...
@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.
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)?
- 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.
Falls/Wenn/Sollte/Eventuell/Vielleicht ... das umgestellt wird:
Featurewunsch:
Eine persistent-Datenbak. Etwas wohin mal Variablen aus Plugins schreiben kann ohne dass sie verloren gehen. Ich kenne den HS nicht aber dort gibts ja die IKOs und sowas wäre schon toll. Vor allem sollten die Werte nicht weg sein wenn man die plugin_db "aufräumt".
Vielleicht mit einem iko_write($name,$value) und iko_read($name).
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: