NEWS
Custom-Attribute in Channels oder States
-
Hallo,
ich bin gerade dabei einen Adapter zu schreiben, welcher State-Updates in Elasticsearch speichern soll. Für die Visualisierung (Grafana oder Kibana) habe ich bei manchen Objekten (zum Bsp. aus hm-rpc) neue Attribute hinzugefügt, damit ich diese besser identifizieren kann ("friendlyName").
Das hat eine Zeit lang bestens funktioniert, doch nachdem ich in Homematic einen neuen Aktor angelernt habe, habe ich die Adapter-Instanz neu synchronisiert. Danach wurden offenbar alle Objekte neu angelegt und somit auch die selbst angelegten Attribute wieder entfernt.
Nun frage ich mich, wozu das Feature ("Custom Attribute") gut sein soll, wenn diese bei einer Neu-Synchronisation einfach überschrieben werden? Ist das ein Problem des hm-rpc-Adapters oder hätte ich einfach nicht neu synchronisieren sollen?
Version:
iobroker: 1.0.8
hm-rpc: 1.4.14
-
Wenn du wirklich in custom (wie History, InfluxDB oder sql Adapter) gespeichert hast dann verschwinden die nur wenn die Objekte neu angelegt werden. In jedem Fall bei hm-rpc. auch bei „neu synchronisieren“ bleiben die erhalten wenn hm-rpc die wieder erkennt. Was sagte denn das log beim synchronisieren? Nur wenn hm-rpc denkt das er löschen und neu anlegen muss dann verschwindet Custom weil ja das Objekt gelöscht wurde.
Für dein Vorhaben am besten von InfluxDB oder History anschauen.
Ich nutze influxdb mit nem grafana …
-
Naja, ich habe in der Objektansicht einen Channel manuell bearbeitet und über den Button "Hinzufügen" ein neues Attribut angelegt:
https://ibb.co/e4kxGH ~~Im Adapter-Code greife ich dann via obj.common.friendlyName darauf zu. Nach der erneuten Synchronisation waren diese Attribute weg.
Wenn ich nun den HM-RPC-Adapter neu synchronisiere, dann sehe ich im Log (wenn ich nach "MEQ0791548" suche) diese Ausgabe:
object hm-rpc.2.MEQ0791548 created
Ich schließe daraus, dass der Adapter sämtliche Objekte löscht und neu anlegt (warum auch immer). M.E. kann das nicht im Sinne des Erfinders sein, denn dann wäre die Möglichkeit, eigene Attribute hinzuzufügen eigentlich nutzlos.
Grundsätzlich ist es doch egal, welches Backend ich zur Historisierung der Daten verwende. Die selbst angelegten Attribute verschwinden doch unabhängig davon… oder übersehe ich da noch was?~~
-
Du triffst falsche Annahmen. Am besten schalte mal für einen hm Datenpunkte History oder sql oder InfluxDB ein.
Dann schau dir das objekt im tab „raw experts only“ an.
Daten in common sind Standarddaten. Da ist nichts spezifisches. Drin. Gehört quasi dem System. In native stehen ggf spezifische Daten zum Gerät und die gehören dem Adapter dem der State gehört. Eigene Änderungen sind gefährlich. Für zusatzinfos von anderen Adaptern gibt es den Custom Bereich wo dann unter dem Namen der anderen adapterinstanz Daten angelegt werden. Die lassen andere Adapter an sich in Ruhe.
Wenn du das bauen willst was ich denke dann kann ich nur History oder InfluxDB als blaupause empfehlen. Auch von den Einstellungen was andere User an Features erwarten würden. Und ggf musst du nur die Funktionen ändern die die Speicherung erledigen.
Ich habe viel Zeit investiert hier History, sql und InfluxDB gleich zu ziehen.
Wenn ein Adapter beim Sync aber Objekte löscht und neu anlegt (scheinbar passiert das bei hm-ip oder nicht-echten-ccus wie yahm oder so bei Updates,da meldet die ccu dann Löschungen und viele neue devices) dann ist History auch weg.
Es gibt ein github issue die Daten besser zu merken und ggf zu restoren aber dazu kam noch niemand. Nicht ganz trivial.
-
Vielen Dank schon mal für deine ausführliche Antwort. So langsam komme ich dahinter
Positiv finde ich schon mal, dass der Custom-Teil eine erneute Synchronisation "überlebt". Das konnte ich mit meinem bereits vorhandenen SQL-History-Adapter soweit überprüfen.
Bisher hatte ich auch gar nicht daran gedacht, den Elastic-Adapter als History-Backend zu implementieren, aber das scheint hier durchaus die bessere Wahl zu sein. Wenn ich das jetzt richtig verstanden habe, muss ich für den "friendlyName" ein Eingabefeld im Konfigurationspanel für Elastic-History-Backend "elastic.0" vorsehen.
Der Custom-Teil würde dann - vereinfacht - ungefähr so aussehen:
"custom": { "elastic.0": { "enabled": true, "friendlyName": "Thermostat Kinderzimmer" }
Ich werde mir dann mal die Implementierung von InfluxDB bzw. SQL mal näher ansehen.
-
Grob ja. Am besten schau dir InfluxDB an. Sql ist durch die 4 verschiedenen unterstützten DBs sehr Komplex geworden. InfluxDB kann Daten direkt schreiben oder aber auch sammeln und im Bulk schreiben falls das relevant ist.
Neben der normalen adapterkonfig (index_m.html) legst du noch die „datenpunktspezifische ui“ als custom_m.html an. Taucht dann beim Zahnrad/Schraubenschlüssel auf wo jetzt auch die anderen History Adapter sind.
Wenn du was hast, ich reviewe gern. Ich denke man kann auch beim Testing was wiederverwenden.
-
So ganz zufrieden stellt mich das Lösungmuster doch noch nicht: Das Problem ist, dass der sog. friendlyName eher ein Attribut auf Kanal- oder Gerät-Ebene ist (je nach Adapter). Bei hm-rpc, würde ich zum Beispiel dem Kanal MEQ0791548.4 einen friendlyName geben wollen und nicht jedem einzelnen State/ Datenpunkt. Angenommen, ich will die Datenpunkte SET_TEMPERATURE, ACTUAL_TEMPERATURE und VALVE_STATE historisieren: ich müsste nun an 3 verschiedenen Stellen denselben friendlyName vergeben. Das finde ich nicht gut (DRY: don't repeat yourself).
Ich habe noch eine andere Idee im Hinterkopf: Ich kann dem Kanal ja mittels Auszählung einem Raum und einer Funktion zuordnen. Der friendlyName würde sich dann aus den beiden Werten ergeben. Allerdings habe ich noch ein Verständnisproblem:
Ich kann in der Ansicht Aufzählungen einem Raum keinen Kanal sondern nur Datenpunkte zuordnen - in der Objekt-Ansicht kann ich die Zuordnung jedoch auch für einen Kanal vornehmen. In der Ansicht "erben" die Datenpunkte dann diese Information. Gehe ich zurück auf die Aufzählungen-Ansicht, dann ist dort auch tatsächlich nur der Kanal zugeordnet worden und nicht jeder einzelnen Datenpunkt. Gibt es einen Grund dafür, dass das nur über die Objekt-Ansicht funktioniert?
-
Naja, DU könntest das als optionales Feld mache. Wenn es leer ist könntest Du in den "übergeordneten Objekten" (getForeignObject) suchen was da drin steht und dann im Adapter quasi dynamisch "erben". Du solltest das beim Adapterstart einmalig machen und im Adapter cachen sonst wird es unperformant.
So wärst du am flexibelsten und kannst sogar einzelne friendlyNames überschreiben
Aufzählungen würde ich für soetwas nicht nutzen. Aufzählungen sind Gruppierungen die neben den Objekten existieren.
-
Naja, DU könntest das als optionales Feld mache. Wenn es leer ist könntest Du in den "übergeordneten Objekten" (getForeignObject) suchen was da drin steht und dann im Adapter quasi dynamisch "erben". `
Dafür müsste ich doch aber bei den "übergeordneten Objekten" den friendlyName festlegen können, oder? Die History-Einstellungen kann ich doch nur für Datenpunkte vornehmen?