[Aufruf] Tests history/sql/influxdb neue Versionen!! Alias-Logging
-
Bei mir dauert es noch mit dem Verstehen…
Also, ich habe dann bei einem Gerät die Alias-ID wieder gelöscht. Im Flot taucht der Graph vor dem Zeitpunkt des Setzens des Alias-ID aber nicht wieder auf. Bug oder feature? `
Hm … good point ... neustart des Adapters sollte das fixen .. Muss mal nachdenken dazu. `
Stimmt. SQL neugestartet. Datenpunkte wieder da. -
Alle Adapter haben jetzt eine .2 am Ende als Versionsnummer auf GitHub.
Jetzt sollte auch das entfernen und Ändern von Alias-IDs problemlos funktionieren.
@lobomau: Bitte deine Fälle nochmal re-testen.
Vielen Dank für Feedback
-
Hab mit 1.9.2. getestet.
Also wenn ich die Alias-ID genauso benenne wie die ID, gibt es den Fehler. Ok, das soll man also nicht machen. Verstanden.
2018-06-21 15:03:18.206 - warn: sql.0 Ignoring Alias-ID because identical to ID for parser.0.DelignitDann habe ich einen neuen Alias-ID benannt. Im Flot beginnt ab diesem Zeitpunkt der neue Graph, Vergangenheit gibt es nicht mehr.
Nach Löschen des Alias-ID ist der Graph wie vorher mit Vergangenheit und Zukunft.
Wie mache ich es nun mit neuer Alias-ID und Vergangenheit? Ich muss dann den alten ID in der Datenbank dazu löschen?
-
Hab mit 1.9.2. getestet.
Also wenn ich die Alias-ID genauso benenne wie die ID, gibt es den Fehler. Ok, das soll man also nicht machen. Verstanden.
2018-06-21 15:03:18.206 - warn: sql.0 Ignoring Alias-ID because identical to ID for parser.0.Delignit ```` `Ja Du hast da durchaus nen Punkt gehabt. AM Ede sollte mit identischer alias-Id alles tun, macht nur keinen Sinn und wollte nicht alles nochmal durchschauen nach Edge-Cases :-))
Dann habe ich einen neuen Alias-ID benannt. Im Flot beginnt ab diesem Zeitpunkt der neue Graph, Vergangenheit gibt es nicht mehr. `
So soll es sein weil ist ja nix in der DB.Nach Löschen des Alias-ID ist der Graph wie vorher mit Vergangenheit und Zukunft. `
korrekt … nur die Werte in der Zwischenzeit fehlen.Wie mache ich es nun mit neuer Alias-ID und Vergangenheit? Ich muss dann den alten ID in der Datenbank dazu löschen? `
Was willst Du tun? Du möchtest eine neue Alias-ID angeben und dann die Vergangenheit eines bestimmten Datenpunkts drin haben und ab dann neu fortschreiben?
Das geht nicht bzw ist nicht supportet.
Der Haupt-usecase den ich im uage hatte für die das ganze Relevant ist, ist:
-
Ich habe heute einen Datenpunkt wo ich logging an habe und die Daten brauche
-
Jetzt ändert sich aus irgendeinem Grund die ID des Datenounktes (Gerät wird ersetzt, js.controller 1.5.0 oder sonstwas), ich will aber die Daten weiter haben und alle neuen dran.
-
Dann schalte ich beim alten Datenpunkt das logging aus
-
Trage die ID des Alten Datenpunkts als Alias beim neuen ein
-
voilla … die Alten Daten sind noch da und die neuen werden angehängt.
Wenn DU jetzt sagt "geile Idee ich stelle alles auf "geräteunabhängige Alias-IDs um" dann verlierst du einmalig alle Daten.
-
-
Für history sind wir jetzt bei 1.8.3 … Man kann dort jetzt das schreiben der Null-Werte am Ende ebenso abschalten wie bei sql.
-
Habe auf 1.8.3 upgdatet. piVCCU auf Orange Pi. Hat übersetzt, funktioniert bisher. Nach nichts mit Alias gemacht.
-
Danke an euch alle!!
Wenn es keine weiteren Anmerkungen oder bugs mehr gibt gehen die letzten Versionen morgen Abend ins latest.
-
Habe 1.8.5 auf dem OPi und begonnen alias zu nutzen.
Dabei stellt sich mir die Frage, was passiert mit den Daten? Werden die in einem Strom zusammengeführt und wenn ja, in welchem.
Was passiert mit den Daten, wenn ich ein der IDs lösche? Sind die weg oder werden die zusammengeführt?
Hintegrund. Habe T-H, Sensoren 433 MHz über RFLink, billig und ordentlich. Aber es stellt sich heraus, daß die nach einem Batteriewechsel nicht mehr erkannt werden. Sie scheinen auf einer anderen ID zu senden. Zumindest werden Sie mit nach einem Anlernversuch als neue ioBroker ID gehandelt.
Also schalte ich das Tracking auf die neue, lebendige ID um und gebe die alte ID als alias ein. Scheint so weit zu funktionieren.
Aber was mache ich beim nächsten Batteriewechsel?
Da würde ich gerne die neue ID löschen, in der Hoffnung, daß die Daten unter der alten ID abgelegt sind. Dann den Sensor neu anlernen und dann das Logging wieder auf die Ursprungs-alias velinken.
-
Habe 1.8.5 auf dem OPi und begonnen alias zu nutzen.
Dabei stellt sich mir die Frage, was passiert mit den Daten? Werden die in einem Strom zusammengeführt und wenn ja, in welchem.
Was passiert mit den Daten, wenn ich ein der IDs lösche? Sind die weg oder werden die zusammengeführt? `
Also die Datenspeicherung erfolgt komplett unabhängig von den ioBroker-Objekten. Wenn Du also ein Objekt änderst hat das erstmal keinerlei Auswirkungen auf die Daten. Die liegen immer noch da rum - werden halt nie wieder benutzt aber sind noch da.
In den History/SQL/InfluxDB werden Daten immer unter der ID des Objektes gespeichert.
Das Alias-Feature biegt beim Speichern quasi diese ID auf den angegeben Alias um. Wenn also der Alias für "StateA" ein "StateB" ist dann speichert der History-Adapter einfach die Daten unter der ID "StateB" wenn diese vom Objekt "StateA" kommen.
Theoretisch kannst Du bei mehreren Objekten das gleiche Alias angeben, dann landen alle diese Daten unter ID "StateB" in der History.
Was Alias-Feature noch macht ist auch alle Zugriffe auf die History-Daten (von Flot oder so) genauso umzubieten und erlaubt auch den Zugriff direkt über die Alias-ID auch wenn es da vllt gar kein Objekt mehr gibt..
Hintegrund. Habe T-H, Sensoren 433 MHz über RFLink, billig und ordentlich. Aber es stellt sich heraus, daß die nach einem Batteriewechsel nicht mehr erkannt werden. Sie scheinen auf einer anderen ID zu senden. Zumindest werden Sie mit nach einem Anlernversuch als neue ioBroker ID gehandelt.
Also schalte ich das Tracking auf die neue, lebendige ID um und gebe die alte ID als alias ein. Scheint so weit zu funktionieren.
Aber was mache ich beim nächsten Batteriewechsel?
Da würde ich gerne die neue ID löschen, in der Hoffnung, daß die Daten unter der alten ID abgelegt sind. Dann den Sensor neu anlernen und dann das Logging wieder auf die Ursprungs-alias velinken. `
Sollte tun -
Super, herzlichen Dank für die Erklärung!
Jetzt da Mitternacht vorbei ist, kann ich das auch ganz leicht an den Daten sehen :oops: Es gibt ein File unter dem alias-Ziel Namn aber keines unter dem Namen, bei dem man die alias-ID einträgt.
Wichtig auch die Info, daß beim Löschen eines Objekts dessen Daten dann noch da bleiben. Das könnte - je nach Arbeitsweise des RFLink Adapters auch noch andere Möglichkeiten eröffnen.
-
Hm … hast rech. Die retention (aufräumen) Logik berücksichtigt das noch nicht .. hm ... legst du bitte ein GitHub issue an?! Danke.
Gesendet vom Handy ...
-
legst du bitte ein GitHub issue an?! Danke. ` Kann ich gerne machen. Aber offengestanden weiss ich gerade nicht welchen Inhats. Habe eigentlich nur laut gedacht und rekapituliert, wa ich zu dem Thema verstanden habe. :oops:
-
Issue: aufräumen der Daten ignoriert alias.
fix das mal.Kannst gern netter formulieren
Gesendet vom Handy …
-
Hier habe ich noch einen kniffligen Sonderfall:
Bei Alias-Aktivierung wird ja das Logging des Ursprungs-Objekts deaktiviert.
Wenn man nun aber auf den "Abonniere alles" Knopf drückt, dann wird dieser auch wieder aktiviert und das aliasing schlägt fehl. Blöder Fall, mußte ich aber dieser Tage durch. Eine Hinweis und Liste der Kollisionspartner wäre da schon hilfreich, dann könnte man das in einem solchen Fall manuell nacharbeiten.
-
Bei Alias-Aktivierung wird ja das Logging des Ursprungs-Objekts deaktiviert. `
EIgentlich passiert das nicht. Rein Technisch kanst Du bei mehreren Objekten (auch dem mit dem Aliasnamen bei anderen) Logging an haben. Dann landet halt auch alles in diesem einen Datenpunkt …
Wenn man nun aber auf den "Abonniere alles" Knopf drückt, dann wird dieser auch wieder aktiviert und das aliasing schlägt fehl. Blöder Fall, mußte ich aber dieser Tage durch. Eine Hinweis und Liste der Kollisionspartner wäre da schon hilfreich, dann könnte man das in einem solchen Fall manuell nacharbeiten. `
Du meinst das Ativieren der History bei allen Datenpunkten? Hm … Da müsste man sich genau anschauen was dann passiert. Da wäre ein ebug-Log interessant -
Ja, genau diesen Button meine ich.
Wenn ich meinen Kampf mit der nicht mehr antwortenden Keymatic gewonnen habe (hat hiermt nichts zu tun, kann ich es mal nachstellen und das Log anschauen)
Und ja, automatsch passiert das deaktivieren de alten Datenpunkts nicht. Das macht man manuell, weil man auf Ingo hört:
@apollon77:Aber das ist jetzt simpel. Einfach beim alten Objekt das logging deaktivieren, beim neuen aktivieren mit den gleichen Einstellungen UND die alte State-ID einfach als "Alias-ID" bei der Konfiguration des Datenpunkts angeben. Dann landen alle Daten in der "alten" ID was das Logging angeht. `
-
Aber an sich sollte das dennoch klappen … also auch da an lassen ... Ist halt der Fall wo ich keinen Anwendungsfall kenne (ausser ich spinne rum) das man Daten von mehreren Dingen in einem History-Punkt haben will
-
Habe jetzt nochmals getestet und bin nun der Meinung, daß das Aktivieren der History bei allen Datenpunkten (slang "Alles abonnieren button") die alias-Einträge (Einträge im Feld Alias-ID) löscht. Das wäre meiner Ansicht nach ein bug.
Kann man auch nachvollziehen, wenn man nur die fraglichen Objekte aufklappt und dann den button drückt. Geht schneller und zeigt den Effekt auch.
-
Kannst du mal ein debug log davon schicken ? Und issue auf GitHub? Log würde mir helfen … Zeit ist gerade extrem knapp.
Gesendet vom Handy ...
-
!
2018-10-02 03:27:45.283 - debug: history.0 value not changed hm-rpc.0.JEQ0195286.1.HUMIDITY, last-value=61, new-value=61, ts=1538443665269 2018-10-02 03:27:46.680 - debug: history.0 value not changed hm-rpc.1.CUX9002002.1.TEMPERATURE, last-value=18.4, new-value=18.4, ts=1538443666674 2018-10-02 03:27:46.705 - debug: history.0 value not changed hm-rpc.1.CUX9002002.1.HUMIDITY, last-value=61, new-value=61, ts=1538443666699 2018-10-02 03:27:46.718 - debug: history.0 value not changed hm-rpc.1.CUX9002002.1.DEW_POINT, last-value=10.75, new-value=10.75, ts=1538443666710 2018-10-02 03:27:46.721 - debug: history.0 value not changed hm-rpc.1.CUX9002002.1.ABS_HUMIDITY, last-value=9.6, new-value=9.6, ts=1538443666712 2018-10-02 03:27:47.576 - debug: history.0 Min-Delta reached hm-rpc.0.JEQ0128927.1.BRIGHTNESS, last-value=136, new-value=15, ts=1538443667568 2018-10-02 03:27:48.327 - debug: history.0 Removed Alias: rflink.0.channels.Prologue_6.TEMP !-> rflink.0.channels.Prologue_4.TEMP 2018-10-02 03:27:48.339 - info: history.0 enabled logging of rflink.0.channels.Prologue_6.TEMP, Alias=false 2018-10-02 03:27:48.368 - debug: history.0 Min-Delta reached rflink.0.channels.Prologue_6.TEMP, last-value=null, new-value=14.3, ts=1538443668336 2018-10-02 03:27:48.419 - debug: history.0 Removed Alias: rflink.0.channels.Prologue_6.HUM !-> rflink.0.channels.Prologue_4.HUM 2018-10-02 03:27:48.423 - info: history.0 enabled logging of rflink.0.channels.Prologue_6.HUM, Alias=false 2018-10-02 03:27:48.427 - debug: history.0 Min-Delta reached rflink.0.channels.Prologue_6.HUM, last-value=null, new-value=52, ts=1538443668421 2018-10-02 03:27:48.501 - info: history.0 enabled logging of rflink.0.channels.Prologue_4.TEMP, Alias=false 2018-10-02 03:27:48.594 - info: history.0 enabled logging of rflink.0.channels.Prologue_4.HUM, Alias=false 2018-10-02 03:27:48.693 - info: history.0 enabled logging of rflink.0.channels.Eurodomest_2.SWITCH_02, Alias=false !Mehrere debug logs durchgeführt. Ergebnis ist reproduzierbar. Das Anstossen von "Aktivieren der History bei allen Datenpunkten" selbst wird im Log nicht aufgeführt. Das Löschen der Alias Ids ist hier vermerkt:2018-10-02 03:27:48.327 - debug: history.0 Removed Alias: rflink.0.channels.Prologue_6.TEMP !-> rflink.0.channels.Prologue_4.TEMP 2018-10-02 03:27:48.419 - debug: history.0 Removed Alias: rflink.0.channels.Prologue_6.HUM !-> rflink.0.channels.Prologue_4.HUM-> issue #32
