UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Scrounger]

Version 0.1.5 ist jetzt im latest verfügbar.

Da ich was an der struktur geändert habe, funktionieren die Experteneinstellungen für Eure parent objekte nicht mehr. Die müsst ihr neu konfigurieren.

Bei Fehlern bitte alle Verlinkungen löschen, Adapter neustarten und die Verlinkungen neu anlegen!

[paul53]

@Scrounger sagte:

Für das linkedObject kann man einen Wert für true bzw false eingeben der dann bei change des linkedObject an das parentObject übergeben wird.

Da die Konvertierung nur mit Zahlen erfolgt, kann man somit binäre Werte (0/1) nach boolean wandeln und umgehrt. Öfter kommen aber Strings vor wie "0"/"1", "false"/"true", "off"/"on", "OFF"/"ON", wobei häufig auch noch common.type: "boolean" angegeben ist.

[Scrounger]

@paul53
Genau das steht bereits auf der ToDo Liste. Aber eins nach dem anderen, erstmal wird jetzt number to X converter implementiert.

Hast vielleicht ne idee wie ich den String '>=10' elegant in ein 'if-statement' umwandeln kann, ohne aufwendig mit regex arbeiten zu müssen. Mit eval() könnte man das lösen, aber das ist ja evil() ;)

[Scrounger]

Version 0.2.0 ist jetzt im latest verfügbar.
Neue Funktion ist das man parentObjects vom typ number in boolean linkedObjects umwandeln kann.

[paul53]

@Scrounger sagte:

Version 0.2.0 ist jetzt im latest verfügbar.

Die Umwandlung funktioniert, aber der "Name des verknüpften Objektes" wird nicht mehr übernommen, sondern stattdessen der Originalname.

[paul53]

@Scrounger Mit der Version von Github wird der eingegebene Name wieder übernommen.

[Scrounger]

Version 0.2.1 ist jetzt im latest verfügbar.
Neue Funktion ist das man parentObjects vom typ boolean in string linkedObjects umwandeln kann.

[paul53]

@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 ?

[Scrounger]

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

[paul53]

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

[paul53]

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

[Scrounger]

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

[Scrounger]

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.

[bommel_030]

@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 ()

[paul53]

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

[bommel_030]

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

[paul53]

@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 ?

[bommel_030]

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

[paul53]

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

[bommel_030]

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