NEWS
History für Datenpunkt per Javascript aktivieren
-
Ist es inzwischen möglich, aus JavaScript einen State für die Aufzeichnung zu konfigurieren? `
Das sollte per Javascript möglich sein. Versuche mal:var hist = { "history.0": { "enabled": true, "changesOnly": true, "debounce": 10000, "maxLength": 360, "retention": 31536000 } }; var obj = getObject("meindatenpunktid"); if(obj.common && !obj.common.custom) { obj.common.custom = hist; setObject("meindatenpunktid", obj); }
Natürlich je nach verwendetem History-Adapter.
-
Super!!
Am besten das JSON aus den Objektdaten eines manuell aktivierten Datenpunkts rausnehmen. Mit den letzten Updates sind da weitere Einstellungen hinzugekommen. Man kann auch die meisten der Daten (also "retention" und so) weglassen. Dann werden die genommen die im Adapter an sich eingestellt sind
-
Ich setze gerade eine komplett neue Installation auf um u.a. Bluefox' Änderungen für die vis-Performance zu testen.
Habe jetzt alle wichtigen Views einzeln ex- und importiert. Jetzt sind nur die Charts noch nicht gefüllt.
Besteht die Möglichkeit auf irgendeinem Weg die geloggten Datenpunkte von einem System zum anderen zu transferieren?
Nur die Datenpunkte - Daten müssen nicht übernommen werden.
Gruß
Rainer
-
Genial, danke!
-
Super! Dann kann man bei einigen Scripts ja gleich die History-Optionen für die mit createState erstellten Datenpunkte gleich mit schicken.
Wenn man dann das System neu aufstetzt, erspart einem das evtl. sehr viel Zeit.
Pix sagt danke!
-
Verstehe ich das richtig, dass ich per Script die Aufnahme eines History-Punktes für ein Wert triggern kann? Denn das wäre genial. Dann könnte ich explizit nur dann History-Punkte in die MySql schreiben, wenn ich das will. Bitte saht mir nicht, dass ich es falsch verstanden habe! :?
Danke,
a200.
-
Nein, mit dem Skript kannst Du History (geht analog für SQL/InfluxDB) für einen Datenpunkt ein oder ausschalten. Wenn eingeschaltet wird nach den definierten Regeln geloggt, sonst nicht.
Also wenn Du Zeiträume hast wo du es haben willst und welche wo nicht kannst du es per Skript ein und dann wieder ausschalten
-
Nein, mit dem Skript kannst Du History (geht analog für SQL/InfluxDB) für einen Datenpunkt ein oder ausschalten. Wenn eingeschaltet wird nach den definierten Regeln geloggt, sonst nicht.
Also wenn Du Zeiträume hast wo du es haben willst und welche wo nicht kannst du es per Skript ein und dann wieder ausschalten `
Ok. Das wäre semi genial. Ein Trigger um eine History-Speicherung zu forcieren ist nicht im Gespräch/in der Mache, oder? Wäre schön.Danke für die Erklärung.
a200.
-
Hm … Rein Formal könnte das sogar schon gehen.
Die ganzen History-Adapter haben seit neuestem eine Methode "storeState" die von meinen neuen History2DB-Converter genutzt wird.
Der methode kann man eine oder mehrere "State-Datenobjekte" übergeben und die werden direkt gespeichert.
Korrektur: SQL und InfluxDB haben storeState ... der History-Adapter bekommt es heute Abend noch dazu
Von daher sollte mit "sendTo" und dem Command "storeState" und entsprechenden Daten das jetzt schon gehen ... Ich hab nur noch kein Beispiel zusammengeklöppelt.
An sich sollte eine "Message" in dem storeState mit
{id: "hm-rpc1.BLUBB.1.BLA", state: {ts: ..., val: ..., ack: ..., from: ..., q: ... } }
Am Ende also ein sendTo("sql.0", "storeState", {id: … state: .... }) sollte das tun ...
Als "State" sollte es an sich gehen das State-Objekt was bei getState zurückkommt zu übergeben.
Achtung: Ungetestete Behauptung
-
Ein Trigger um eine History-Speicherung zu forcieren ist nicht im Gespräch/in der Mache, oder? `
Mit "changesRelogInterval" könnte man forcieren:// forcieren alle 20 s var obj = getObject("meindatenpunktid"); if(obj.common && obj.common.custom) { obj.common.custom["history.0"].changesRelogInterval = 20; setObject("meindatenpunktid", obj); } // forcieren ausschalten var obj = getObject("meindatenpunktid"); if(obj.common && obj.common.custom) { obj.common.custom["history.0"].changesRelogInterval = 0; setObject("meindatenpunktid", obj); }
-
Korrektur: SQL und InfluxDB haben storeState … der History-Adapter bekommt es heute Abend noch dazu `
Bitte History 1.4.1 installieren, da ist storeState drin.
Wenn das klappt erweitere ich die ganzen Dokus mal noch
Bei "History" können aktuell wirklich nur States geloggt werden für die auch History aktiviert ist. Ich überlege mal wie man das am sinnvollsten ändern kann.
Bei SQL und InlfuxDB können an sich auch komplett eigene "IDs" geloggt werden die gar nicht als States existieren, was aber ggf komische Effekte hat weil die Retention-Logik diese Werte niemals aufräumen wird. Sie werden also immer "forever" gespeichert. Rauskriegen tut man die Daten aber dann auch nur per Query Kommando (SQL/InfluxDB) oder GetHistory (alle 3 Adapter)
-
Habe jetzt endlich wieder Internet zuhause, sodass ich meine Pi auf die neuesten Adapter updaten konnte.
Das aktivieren/deaktivieren des Loggings für einzelne States per JS funktioniert einwandfrei. Kann ich den Adapter auch irgendwie dazu bringen, die Historie für einen bestimmten State komplett zu löschen? Löschen des States scheint die Historie nicht zu entfernen.
-
setzte mal "retention" auf 1, dann sollte der nächste Retention-Check alles bis auf den letzten Tag wegwerfen … ganz weg gibts aktuell nichts
-
Danke für die schnelle Antwort. Wäre super, wenn die Funktion irgendwann nachgerüstet wird, am besten per sendTo / Skript zugänglich. Nicht super dringend, aber nice-to-have.
Mein Problem gestaltet sich wie folgt:
Ich verwalte in einer skriptgesteuerten Anwendung diverse Räume, die über eine ID (Zahl) identifiziert werden. Ein State, der über diese ID referenziert wird, soll geloggt werden über einen längeren Zeitraum und später der Auswertung zugeführt.
Jetzt will ich nicht ausschließen, dass im Laufe der Benutzung Räume entfernt und IDs neu vergeben werden. Das würde bedeuten, dass möglicherweise die Daten eines neuen Raums unter der ID eines früher mal existierenden Raums abgelegt werden und so die Historien zusammenfallen. Das würde sich vermeiden lassen, indem ich beim Löschen des Raums die Historie ebenfalls lösche. Oder eben die IDs nicht neu vergebe, aber bleiben wir mal realistisch
-
Sööööö … Neue Version 1.5.0 von History auf Github verfügbar.
zwei neue Messages werden unterstützt: enableHistory und disableHistory.
Siehe Github-Seite für Beispiel.
Feedback und Testergebnisse bitte unter http://forum.iobroker.net/viewtopic.php?f=36&t=4356
-
Hi,
ich weiß es ist ein altes Topic aber ich evrsuche gerade massenweise DP anzulegen und möchte hsitory gleich aktivieren.dieser Code klappt aber nicht:
var hist = { "history.0": { "enabled": true, "changesOnly": true, "debounce": 10000, "maxLength": 360, "retention": 31536000 } }; var obj = getObject("meindatenpunktid"); if(obj.common && !obj.common.custom) { obj.common.custom = hist; setObject("meindatenpunktid", obj); }
obj unten meldet: No overload matches this call.
Ist das mittlerweile anders ?
LG
Nils -
@apollon77 kannst du da evtl. was zu sagen?
-
Also der Fehler kommt wohl eher von den Typescript checks ... da bräuchte man eher mal einen Screenshot mit dem Fehler.
Generell ist an sich der bessere Ansatz dafür das hier: https://github.com/ioBroker/ioBroker.influxdb/#history-logging-management-via-javascript (ja der Doku Link ist InfluxDB, aber History und SQL können das gleiche).
-
@apollon77 hi,
Danke dir für die Antwort. Ich könnte mir in diesem Fall mit dem Filter in der Objektansicht helfen.
Zum Hintergrund.
Ich habe Mal meine ganzen Objekte bei denen ich 600s Tages und Wochenwerte erfasse neu sortiert und vernünftig benannt und eingeordnet.Leider fehlen mir nun 3 Jahre Daten. Ich habe aber die History Dateien vom Pi gezogen und mir Bulk rename utility umbenannt und voila alles auf den neuen Datenpunkten. Ein Träumchen.
Jetzt noch schön gründlich alle bis und Scripte anpassen.Denke darüber nach die json Objekte per Ctrl+h zu bearbeiten.