Weihnachtsangebot 2025! 🎄

[apollon77]

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.

[klassisch]

Habe auf 1.8.3 upgdatet. piVCCU auf Orange Pi. Hat übersetzt, funktioniert bisher. Nach nichts mit Alias gemacht.

[apollon77]

Danke an euch alle!!

Wenn es keine weiteren Anmerkungen oder bugs mehr gibt gehen die letzten Versionen morgen Abend ins latest.

[klassisch]

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.

[apollon77]

@klassisch:

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..

@klassisch:

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

[klassisch]

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.

[apollon77]

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 ...

[klassisch]

@apollon77:

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:

[apollon77]

Issue: aufräumen der Daten ignoriert alias. ;-) fix das mal.

Kannst gern netter formulieren ;-)

Gesendet vom Handy …

[klassisch]

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.

[apollon77]

@klassisch:

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 …

@klassisch:

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

[klassisch]

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. `

[apollon77]

;-)

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

[klassisch]

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.

[apollon77]

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 ...

[klassisch]

! 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

[apollon77]

Aahhh jetzt verstehe ich … puhh... da muss ich mal schauen wie das Admin das macht bei leeren Feldern und so ... denke da brauche ich Bluefox ...

[klassisch]

In diesem speziellen Fall wäre die einfachste Lösung das alias-Id Feld beim “abonniere alles“ button gar nicht anzubieten. Es macht ja keinen Sinn, alle Datenpunkte auf einem alias zu mappen. Das Feld schadet hier allen, die alias verwenden, hilft aber höchstwahrscheinlich niemanden.

Alternativ Dropdown Menü (unverändert / Id Eingabe) oder Checkbox ob das geändert werden soll.

Gesendet von meinem ZTE A2016 mit Tapatalk