[Neuer Adapter] LinkedDevices
-
@Scrounger sagte:
wenn ihr mal die Hardware tauschen müsst, dann müsst ihr nur die verlinkten Objekte auf die neue Hardware anpassen und die Skripte und vis funktionieren sofort wieder.
Ein Hardwaretausch wird erst dann komfortabel, wenn man den verlinkten Datenpunkten per Select ID Datenpunkte des neuen Gerätes zuweisen kann. Hast Du diese Funktionalität in Planung ?
-
Das geht doch heute schon. Wenn die Hardware sich ändert musst du nur die gleiche id des linked object beim neuen Datenpunkt eintragen und schon funktioniert wieder alles.
@paul53 sagte in [Neuer Adapter] LinkedDevices:
den verlinkten Datenpunkten per Select ID Datenpunkte des neuen Gerätes zuweisen kann.
Erklär mal bitte was du damit genau meinst, evtl. wäre das ja noch komfortabler
-
@Scrounger sagte:
Wenn die Hardware sich ändert musst du nur die gleiche id des linked object beim neuen Datenpunkt eintragen
Da muss man sich aber einiges merken, denn der Ursprung existiert ja nicht mehr.
@Scrounger sagte in [Neuer Adapter] LinkedDevices:
was du damit genau meinst,
Der linked Datenpunkt besteht ja noch. Wenn diesem (bei deaktiviertem Link) der Datenpunkt des neuen Gerätes per Auswahl (Select ID) zugewiesen werden könnte, wäre es komfortabler.
-
@Scrounger Einfacher wäre es sicherlich, wenn das parentObject anstelle der vielen Eigenschaften:
"custom": { "linkeddevices.0": { "enabled": true, "unit": "°C", "linkedId": "Aussen.Temperatur", "name": "Aussentemperatur", "maxDecimal": 1, "conversion": "/1.8", "readOnlyConversion": "/1.8-32/1.8", "expertSettings": true, "number_converTo": "", "number_unit": "°C", "number_maxDecimal": 1, "number_calculation": "", "number_calculation_readOnly": "/1.8-32/1.8", "number_to_boolean_condition": "", "number_to_boolean_value_true": "", "number_to_boolean_value_false": "" }nur die "linkedId" erhalten würde und alles andere (Name, Konvertierung, ...) dem linkedObjekt zugeordnet würde. Dann würde beim Gerätetausch nichts verloren gehen.
-
@paul53 sagte in [Neuer Adapter] LinkedDevices:
Der linked Datenpunkt besteht ja noch. Wenn diesem (bei deaktiviertem Link) der Datenpunkt des neuen Gerätes per Auswahl (Select ID) zugewiesen werden könnte, wäre es komfortabler.
Ok verstanden. Ist geplant, im Config Menu des Adapters soll es eine Liste geben, das alle verlinkungen anzeigt. Hier könnte man dann ein SelectId für nicht mehr verlinkte Objekte hinzufügen.
@paul53 sagte in [Neuer Adapter] LinkedDevices:
Dann würde beim Gerätetausch nichts verloren gehen.
Das ist heute schon, allerdings werden im linkedObject nur die wirklich verwendeten gespeichert.
Hier ein Beispiel:
parentObject:"custom": { "linkeddevices.0": { "enabled": true, "number_unit": "", "linkedId": "number", "name": "", "expertSettings": true, "number_convertTo": "boolean", "number_maxDecimal": "", "number_min": "", "number_max": "", "number_calculation_readOnly": "", "number_to_boolean_condition": ">12", "number_to_boolean_value_true": "30", "number_to_boolean_value_false": "", "number_to_string_condition": "", "number_to_multi_condition": "", "boolean_convertTo": "", "boolean_to_string_value_true": "", "boolean_to_string_value_false": "", "number_calculation": "" } }und das linkedObject dazu:
"custom": { "linkeddevices.0": { "enabled": true, "parentId": "virtualpowermeter.0.number", "parentType": "number", "isLinked": true, "number_to_boolean_condition": ">12", "number_to_boolean_value_true": "30" } }Heißt wenn dann mal irgendwann per SelectId in der Config des Adpaters einem nicht mehr verlinkten Object ein neues parentObject zugewiesen wird, müssen diese Daten nur ans parentObject übergeben werden, inkl. natürlich ggf. von abweichenden common werten.
-
Hab jetzt angefangen die Dokumentation für den Adpater zu erstellen. Ich hoffe Sie ist verständlich - ist etwas schwierig die Funktionen zu beschreiben.
https://github.com/Scrounger/ioBroker.linkeddevices
Könnte noch Unterstützung bei der Übersetzung ins Englische benötigen. Falls jemand mit helfen einfach bei mir melden.
-
@Scrounger
Danke für den Adapter, erleichtert das Loggen und wechseln doch ungemein.
Teste nebenbei noch Statistics und Sourceanalytix, die Daten würde ich ja dann jetzt auf die Datenpunkte in deinem Adapter umleiten.
Also eigentlich muss ich ja neu anfangen mit loggen, oder siehst du ne Möglichkeit die alten Daten zu erhalten?Habe mir für meinen Slave eine zweite Instanz angelegt und wollte diese auch auf dem Slave laufen lassen. Da bleibt Sie aber rot.
Sobald ich die Instanz wieder auf den Master schiebe läuft sie einwandfrei.host.rock64 2019-07-17 10:59:43.947 info Do not restart adapter system.adapter.linkeddevices.1 because disabled or deleted host.rock64 2019-07-17 10:59:43.947 error instance system.adapter.linkeddevices.1 terminated with code 156 () -
@bommel_030 sagte:
Statistics und Sourceanalytix, die Daten würde ich ja dann jetzt auf die Datenpunkte in deinem Adapter umleiten.
Welche Daten ? Die Quelldaten für diese Adapter oder die Ergebnisse ?
@bommel_030 sagte:
Habe mir für meinen Slave eine zweite Instanz angelegt und wollte diese auch auf dem Slave laufen lassen.
Wozu soll eine 2. Instanz auf dem Slave gut sein ? Die Datenpunkt-Datenbank existiert nur auf dem Master.
-
@paul53
Da Master und Slave räumlich sehr weit voneinander entfernt sind war der Grundgedanke eigene SQL Instanz, eigene LinkedDevices und eigene Sourceanalytix Instanz.
Der Slave könnte dann brav weiterloggen wenn die Telefonleitung mal wieder von nem umgestürzten Baum gekappt wurde.
Wenn der Slave aber nur bei bestehender Verbindung zum Master die Datenpunkt-Datenbank hat geht das natürlich nicht. Hab den Multihostbetrieb erst seit gestern und teste noch....Ich habe z.B. einen Datenpunkt der mir den Verbrauch eines Shellys darstellt. Dieser wird mit Sourceanalytix geloggt. Wenn ich diesen Datenpunkt nun in linkedDevices abbilde weiß Sourceanalytix ja davon noch nichts. Quasi das Szenario was der Adapter ja zukünftig umgehen soll.
Nach meinem Verständnis bleibt mir nur die Möglichkeit den neuen Datenpunkt aus linkedDevices mit Sourceanalytix zu loggen und den bisherigen Verlauf damit zu verlieren. Ist nicht dramatisch, aber falls jemand ne Idee hat wie man das umgehen kann probiere ich das gerne aus. -
@bommel_030 sagte:
wenn die Telefonleitung mal wieder von nem umgestürzten Baum gekappt wurde.
Dann ist Multihost wohl nicht die richtige Wahl, denn Multihost erfordert eine stabile Netzwerkverbindung. Was läuft auf dem (geplanten) Slave ?
-
@paul53
Der Klassiker... CCU, TR-064, DECT, Telegram und KM200...
Ohne Internet sind die meisten Sachen sinnlos, daher kam der Gedanke mit dem Slave.
Dann lass ich die kleine Beere eben weiter eigenständig laufen. -
@bommel_030 sagte:
TR-064, DECT, Telegram
Also befindet sich der Router in der Nähe des RasPi ? Was läuft dann auf dem (geplanten) Master ?
@bommel_030 sagte:
Dann lass ich die kleine Beere eben weiter eigenständig laufen.
Die Daten können auch per MQTT (Broker / Client) ausgetauscht werden.
-
@paul53
Der Master ist ein rock64 neben der Fritzbox in Deutschland. Der Slave steht neben ner Fritzbox in der Schweiz. Also aktuell ist er noch eigenständig ^^.
Sämtliche Kommunikation zwischen Slave und Master muss ja über das Internet erfolgen, und dann ist es egal ob MQTT oder Multihost an mangelnder Verbindung scheitern.
Unter der Voraussetzung Internet ist nicht da wäre der worst case: der Brennkessel fällt aus und ich bekomme das nicht mit.... Allerdings könnte ich der CCU vor Ort einprogrammieren, wenn die Temperatur zu gering ist soll er die Elektroheizung befeuern...
Mir würden dann nur die geloggten Daten fehlen... -
@bommel_030 sagte:
dann ist es egal ob MQTT oder Multihost an mangelnder Verbindung scheitern.
Das ist nicht egal, denn bei MQTT läuft der RasPi in der Schweiz autark weiter, es findet zu der Zeit nur kein Datenaustausch nach Deutschland statt.
-
@paul53 genau...
@bommel_030 das mus eine master - master verbindung sein
der slave rennt ncith weiter ohne den master -
@paul53
Soweit so klar, aber speichert er denn im MQTT Betrieb zwischen und schickt dann die gesammelten Daten nach Deutschland?
Wenn ich die CCU in der Schweiz auf dem Master in Deutschland direkt einbinde bekomme ich während des Internetausfalls natürlich keine Daten. Sobald die Verbindung wieder steht kommen die aktuellen werde wieder rein. Das kann der MQTT Betrieb sicherlich auch. Und zusätzlich noch die Daten während des Ausfalls puffern?
@arteck
Master - Master Verbindung höre bzw. lese ich gerade zum ersten Mal. Vielleicht war ich auch nur zu sehr auf Master - Slave festgenagelt...
Ich hab halt nen Pi in der Schweiz und der soll auch grundsätzlich die Adapter für die Schweiz beherbergen.
Ob das nun als Master-Master oder Master-Slave in Deutschland oder der Schweiz geschieht ist mir egal. Zumindest momentan wo ich das ganze noch nicht vollständig verstanden habe. -
@bommel_030 sagte:
speichert er denn im MQTT Betrieb zwischen und schickt dann die gesammelten Daten nach Deutschland?
Das glaube ich nicht. Satistiken, die von fortlaufenden Daten abhängen, sollten deshalb auf dem RasPi erstellt werden.
@bommel_030 sagte in [Neuer Adapter] LinkedDevices:
Wenn ich die CCU in der Schweiz auf dem Master in Deutschland direkt einbinde bekomme ich während des Internetausfalls natürlich keine Daten. Sobald die Verbindung wieder steht kommen die aktuellen werde wieder rein.
In der Zwischenzeit steht der Slave und alles, was in dieser Zeit passiert, wird nicht registriert.
-
@bommel_030 sagte:
Grundgedanke eigene SQL Instanz, eigene LinkedDevices und eigene Sourceanalytix Instanz.
Eine eigene Sourceanalytix Instanz braucht es nicht, denn es genügt, den absoluten Zählerstand per MQTT zu übertragen. Zeitliche Lücken stören nicht oder nur wenig (wenn sie über Tagesgrenzen gehen).
@bommel_030 sagte in [Neuer Adapter] LinkedDevices:
Master - Master Verbindung höre bzw. lese ich gerade zum ersten Mal.
Das ist der Datenaustausch mittels MQTT oder Simple API (bei wenigen Daten).
-
@paul53
Also ist es am sinnvollsten den kleinen Schweizer selbstständig laufen zu lassen,und alle Daten die ich in Deutschland sehen will per MQTT auf den Master zu schieben.
Urlaub steht vor der Tür, kann ich mich mal ein wenig in MQTT einlesen... Hab den Thread dann glaube ich auch genug mit meinem Multihost missbraucht
Aber zum eigentlichen Adapter nochmal.
Ich habe nen Verbrauchszähler der mir die Werte in Wh liefert und bei einem Reboot wieder von Null anfängt.
Also hab ich mir nen Skript gebastelt was die Werte in kWh ändert, die Nullung abfängt und das in einen Datenpunkt schreibt.
Nun hab ich heldenhafterweise den nullenden Datenpunkt in LinkedDevices eingefügt in nicht den eigenen der brav weiterzählt.
Kann ich den LinkeDevices Datenpunkt auf den richtigen umllinken ohne den anderen zu löschen? -
@bommel_030 sagte:
Nun hab ich heldenhafterweise den nullenden Datenpunkt in LinkedDevices eingefügt in nicht den eigenen der brav weiterzählt.
Das ist auch richtig, denn der nullende DP ändert sich bei einem Hardwaretausch. Mittels MQTT (iobroker.mqtt-client) sendest Du nur den eigenen Datenpunkt, der brav weiterzählt.
