[Aufruf] Tests history/sql/influxdb neue Versionen!! Alias-Logging
-
Is ja n' Ding.
Ich dachte es liegt wieder an meiner Kiste.
-
Ne Du hast wirklich einen Fehler gefunden der bei influxdb und sql reingerutscht war. Die ganzen automatisierten tests sind nie auf den gestossen … congratulation!
Alle 3 Adapter haben jetzt eine ".1" Version auf Github. Die Maximale Länge der Alias-ID sollte jetzt bei 255 zeichen sein
Wer will nochmal wer hat noch nicht ... (genug) ...
-
Die Maximale Länge der Alias-ID sollte jetzt bei 255 zeichen sein
Ja, passt. Das ging ja fix
-
1.91. installiert.
Instanz wird grün.
-
Gleiches passiert jetzt in einigen Adaptern in Vorbereitung auf js-controller 1.4.2 bzw. 1.5.0 wo bestimmte Zeichen nicht mehr erlaubt sind für State-IDs. Hier ändern sich auch die IDs - allen voran im Smartmeter-Adapter, wo eine Stromverbrauchs-Historie komplett cool ist.
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. `
zu smartmeter:
Kann man dann die alten states unter Objekte dann löschen.
Die Werte müsste doch in der Datei sqlite noch gespeichert sein.
Richtig ?
andere Möglichkeit?
Gibt es ein Tool in dem man die Datenbank sqlite bearbeiten kann.
Also die alten gespeicherten Daten dem neuen Punkt zuordnen.
Man würde dann den alias sparen.
mfg
-
1.) Ja, kannst die alten IDs löschen und bei den neuen den namen des Alten als Alias hinterlegen. Das war die Idee.
2.) Es gibt viele SQLite Editoren. Was die so können keine Ahnung. "Google is your friend"
-
Vielleicht mache ich was falsch oder ich habe es noch nicht verstanden.
Also, ich habe bei einem HM-IP Lichtschalter bei der Leistungsmessung eine Alias-ID eingetragen "Gartenpumpe.power".
Ab dem Abspeichern der Alias-ID sind die bisher geloggten Daten weg und fangen ab dem Zeitpunkt des Abspeicherns an zu loggen.
Aber die ID bleibt weiterhin die gleiche. Nun weiß ich nicht was ich mit der Alias-ID mache bzw. wo ich sie finde.
Ich dachte es wäre alles wie vorher nur quasi doppelt durch einen neuen zusätzlichen Namen, der Alias-ID.
-
Ich dachte es wäre alles wie vorher nur quasi doppelt durch einen neuen zusätzlichen Namen, der Alias-ID.
Nein, es wird nicht doppelt gespeichert. Man kann lediglich das Speichern mit einer "alten" ID und einem neuen Datenpunkt fortsetzen.
@apollon77 sagte:
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.
-
Paul53 hat es richtig verstanden!
Und ja, wenn Du einen neuen Alias-ID-namen eingibst den es bisher nicht gab dann wird alles ab dem zeitpunkt dahin geloggt und auch Abfragen auf den echten Datenpunkt werden dahin "umgebogen".
-
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?
Dann eine Beobachtung: ich habe mal dem Alias-ID den gleichen Namen gegeben wie die ID, in dem konkreten Fall "landroid-s.0.mower.batteryCharging". Dann kommt erstmal eine Zeitlang Fehlermeldung, wahrscheinlich zu Recht, und Flot lädt den Graph nicht. Nach einer Zeit ist der reload wohl abgeschlossen und alles läuft wieder vorher. Läuft das alles wie gedacht?
sql.0 2018-06-21 09:16:08.557 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:16:08.557 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 sql.0 2018-06-21 09:15:35.840 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:15:35.839 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 sql.0 2018-06-21 09:14:35.040 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:14:35.039 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 sql.0 2018-06-21 09:14:04.339 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:14:04.338 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 -
Ohne Alias-ID mit SQL Server läuft es wie vorher.
-
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.
Dann eine Beobachtung: ich habe mal dem Alias-ID den gleichen Namen gegeben wie die ID, in dem konkreten Fall "landroid-s.0.mower.batteryCharging". Dann kommt erstmal eine Zeitlang Fehlermeldung, wahrscheinlich zu Recht, und Flot lädt den Graph nicht. Nach einer Zeit ist der reload wohl abgeschlossen und alles läuft wieder vorher. Läuft das alles wie gedacht?
sql.0 2018-06-21 09:16:08.557 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:16:08.557 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 sql.0 2018-06-21 09:15:35.840 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:15:35.839 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 sql.0 2018-06-21 09:14:35.040 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:14:35.039 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 sql.0 2018-06-21 09:14:04.339 error Please wait till next data record is logged and reload. sql.0 2018-06-21 09:14:04.338 warn For getHistory for id landroid-s.0.mower.batteryCharging: Type empty. Need to write data first. Index = 284 ```` `Muss ich auch anschauen.
-
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.
