[Neuer Adapter] LinkedDevices
-
@scrounger Hallo. Bisher keine Fehler mehr mit der Version über github, es scheint zu klappen. Das komische dabei ist aber, dass es vorher eigentlich immer ohne Probleme lief. Mal schauen, wie die neue Version 1.4.3 läuft.
-
@ryto sagte in [Neuer Adapter] LinkedDevices:
@scrounger
Hier die Einstellungen:Sieht soweit alles gut aus. Habs getestet funktioniert. Hat den der datenpunkt
s7.0.DBs.DB12.dali_ecg_set_color_COORDINATE_Yauch einen Wert?
Lösch mal das verlinkte Objekt und starte den Adapter neu.@palm_maniac sagte in [Neuer Adapter] LinkedDevices:
@scrounger Hallo. Bisher keine Fehler mehr mit der Version über github, es scheint zu klappen. Das komische dabei ist aber, dass es vorher eigentlich immer ohne Probleme lief. Mal schauen, wie die neue Version 1.4.3 läuft.
Wie gesagt ich hab nur das Error Handling optimiert, so dass der Adapter nicht mehr abschmieren sollte. Du musst aber trotzdem mal das Log beobachten ob da eine Fehlermeldung kommt.
-
@scrounger
Alles gelöscht, Neustart und alles neu angelegt. Keine Änderung.
Aber:
Wenn ich in Objekte den linked_xxx Datenpunkt ändere, wird der Wert ohne Nachkomma im verlinkten Objekt eingetragen, i.O.
Den Wert im linked_xxx Datenpunkt habe ich bisher über Blockly mit aktualisiere.... geändert, Ergebnis waren Nachkommastellen im Datenpunkt. Da linked_xxx für mich eigentlich eine interne Variable ist, habe ich mit aktualisiere... gearbeitet.
Nun habe ich aktualisiere mit setze... auf den linked_xxx Datenpunkt ersetzt, und die Nachkommastellen sind weg.
Problem gelöst, nur noch mit setze... auf den linked_ und es klappt.
Danke -
@ryto
Nachkommastellen werden auch nur auf den verlinkten Datenpunkt angewendet!Grundsätzlich solltest du nur noch mit den verlinkten Datenpunkten in Script vis, etc. arbeiten, das ist die Idee Konzept hinter dem Adapter
-
@scrounger
Ich hatte nur auf das verlinkte (linked_...) Objekt geschrieben. Es arbeitet aber nur richtig, wenn die Variable mit setze... und nicht aktualisiere... geändert wird. -
@scrounger said in [Neuer Adapter] LinkedDevices:
@sevenup sagte in [Neuer Adapter] LinkedDevices:
@Scrounger ist es möglich ein Boolean Wert negiert zu verlinken?
Habs eingebaut, v1.4.3 sollte demnächst im latest sein.Vielen Dank!
Funktioniert super -
@scrounger Hi. Es gab wieder Fehler. Hier der Logauszug:
2021-03-19 10:38:57.248 - error: linkeddevices.0 (1508) [getConvertedValue] sourceId 'Datenpunkte.0.Energie.Autarkie' targetId 'linkeddevices.0.Sensoren.Keller.Hobbyraum.Wechselrichter.Autarkie_Jetzt', error: Unexpected type of argument in function round (expected: number or Complex or BigNumber or Fraction or Array or Matrix or DenseMatrix or SparseMatrix or string or boolean, actual: null, index: 0), stack: TypeError: Unexpected type of argument in function round (expected: number or Complex or BigNumber or Fraction or Array or Matrix or DenseMatrix or SparseMatrix or string or boolean, actual: null, index: 0) at createError (D:\iobroker\KuhnHome\node_modules\typed-function\typed-function.js:555:19) at Function.generic (D:\iobroker\KuhnHome\node_modules\typed-function\typed-function.js:1077:15) at Object.round (D:\iobroker\KuhnHome\node_modules\typed-function\typed-function.js:1092:24) at Linkeddevices.getConvertedValue (D:\iobroker\KuhnHome\node_modules\iobroker.linkeddevices\main.js:1474:32) at runMicrotasks () at runNextTicks (internal/process/task_queues.js:62:5) at processImmediate (internal/timers.js:434:9) at async Linkeddevices.onStateChange (D:\iobroker\KuhnHome\node_modules\iobroker.linkeddevices\main.js:274:21)Der Fehler taucht immer wieder regelmäßig auf, obwohl der Alias-Datenpunkt und LinkedDevices sauber laufen. es handelt sich hierbei um einen manuell angelegten Datenpunkt, der per Blockly berechnet wird.
-
@palm_maniac
Zeig mal die raw daten von beiden datenpunkten.
Wird auch der richtige type vom blockly in den DP geschrieben? -
Hier die Daten von der Quelle:
{ "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1613475446191, "common": { "name": "Autarkie Jetzt", "role": "", "type": "number", "desc": "Manuell erzeugt", "unit": "%", "min": 0, "read": true, "write": true, "custom": { "linkeddevices.0": { "enabled": true, "number_unit": "", "linkedId": "Sensoren.Keller.Hobbyraum.Wechselrichter.Autarkie_Jetzt", "name": "Autarkie Jetzt", "role": "", "mergeSettingsOnRestart": true, "expertSettings": true, "number_convertTo": "", "number_maxDecimal": 2, "number_min": "", "number_max": "", "number_calculation": "", "number_calculation_readOnly": "", "number_to_boolean_condition": "", "number_to_boolean_value_true": "", "number_to_boolean_value_false": "", "number_to_string_condition": "", "number_to_duration_convert_seconds": "", "number_to_duration_format": "", "number_to_datetime_convert_seconds": "", "number_to_datetime_format": "", "number_to_multi_condition": "", "boolean_convertTo": "", "boolean_to_string_value_true": "", "boolean_to_string_value_false": "", "string_convertTo": "", "string_prefix": "", "string_suffix": "", "string_to_boolean_value_true": "", "string_to_boolean_value_false": "", "string_to_number_unit": "", "string_to_number_maxDecimal": "", "string_to_number_calculation": "", "string_to_number_calculation_readOnly": "", "string_to_duration_format": "", "string_to_datetime_parser": "", "string_to_datetime_format": "", "boolean_invert": false } } }, "native": {}, "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1636 }, "_id": "Datenpunkte.0.Energie.Autarkie", "type": "state" }Und hier vom Ziel:
{ "type": "state", "common": { "name": "Autarkie Jetzt", "role": "", "type": "number", "desc": "Created by linkeddevices", "unit": "%", "min": 0, "max": 100, "def": 0, "read": true, "write": true, "custom": { "linkeddevices.0": { "enabled": true, "parentId": "Datenpunkte.0.Energie.Autarkie", "parentType": "number", "isLinked": true, "mergeSettingsOnRestart": true, "number_maxDecimal": 2, "linkedId": "", "name": "", "role": "", "expertSettings": false, "number_convertTo": "", "number_unit": "", "number_min": "", "number_max": "", "number_calculation": "", "number_calculation_readOnly": "", "number_to_boolean_condition": "", "number_to_boolean_value_true": "", "number_to_boolean_value_false": "", "number_to_string_condition": "", "number_to_duration_convert_seconds": "", "number_to_duration_format": "", "number_to_datetime_convert_seconds": "", "number_to_datetime_format": "", "number_to_multi_condition": "", "boolean_convertTo": "", "boolean_to_string_value_true": "", "boolean_to_string_value_false": "", "string_convertTo": "", "string_prefix": "", "string_suffix": "", "string_to_boolean_value_true": "", "string_to_boolean_value_false": "", "string_to_number_unit": "", "string_to_number_maxDecimal": "", "string_to_number_calculation": "", "string_to_number_calculation_readOnly": "", "string_to_duration_format": "", "string_to_datetime_parser": "", "string_to_datetime_format": "", "boolean_invert": false }, "influxdb.0": { "enabled": true, "changesOnly": false, "debounce": "1000", "retention": 0, "changesRelogInterval": 4, "changesMinDelta": 0, "storageType": "", "aliasId": "Autarkie Jetzt" } }, "icon": "linkeddevices_small.png" }, "native": {}, "from": "system.adapter.linkeddevices.0", "user": "system.user.admin", "ts": 1616149703821, "_id": "linkeddevices.0.Sensoren.Keller.Hobbyraum.Wechselrichter.Autarkie_Jetzt", "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Das Blockly scheint richtig zu arbeiten, da nur gerechnet wird. Es handelt sich dabei um einen Prozentwert zwischen 0 und 100.
-
Ich hab nochmal nachgeschaut. Der Fehler taucht nur heute auf, 3mal. Gestern war noch nix drin.
-
@Scrounger Hallo, was mir aufgefallen ist, wenn ich für den Source Datenpunkt History aktiviere wird das auch auf den linked Datenpunkt gespiegelt und umgekehrt. Bisher habe ich keine Stelle gefunden an der ich dieses Verhalten konfigurieren kann - kann man es überhaupt konfigurieren ?
Was mich daran stört ist, dass History dann natürlich zwei Datenpunkte aufzeichnet. Das kann Sinn machen wenn man den Wert konvertiert, somit dann beide Werte aufzeichnet.
Aktuell kann ich History entweder für beide DP aktivieren oder für keinen.Gruß Bungee
-
@palm_maniac sagte in [Neuer Adapter] LinkedDevices:
Das Blockly scheint richtig zu arbeiten, da nur gerechnet wird. Es handelt sich dabei um einen Prozentwert zwischen 0 und 100.
Ich konnte es jetzt reproduzieren, der Fehler tritt auf, wenn der Wert
nulloderundefinedist.
Ich schätze das da was in deinem Blockly nicht korrekt läuft und eine der Werte schreibt.
Ich werd die log Ausgabe mal noch erweiteren, dass man sieht was zum Zeitpunkt des Fehlers für ein Wert verwenden wird.@bungee71 sagte in [Neuer Adapter] LinkedDevices:
Aktuell kann ich History entweder für beide DP aktivieren oder für keinen.
Stimmt nur halb
Wenn du History beim orginalen DP aktiviert hast, dann wird das automatisch beim verlinkten DP auch aktiviert, weil der orginale DP 1zu1 gespiegelt wird - das ist das Konzept des Adapters.
Wenn aber beim orginalen DP kein History aktiviert ist, kannst du das nur für den verlinkten DP aktivieren.Warum ist das so - nehmen wir mal an du hast einen Aktor von dem du Daten per History aufzeichnen willst. Wenn das jetzt nur beim verlinkten DP aktiviert ist, der Aktor defekt ist und getauscht wird, muss man nur die verlinkung reparieren und die Aufzeichnung der Daten per History läuft weiter, d.h. die alten Daten sind dann nach wie vor vorhanden. Genauso funktioniert dann auch alles wieder in VIS, Skripten, etc.
D.h. man sollte immer den roh datenpunkten zunächst verlinken und dann alle Einstellungen wie z.B. History am verlinkten Datenpunkt durchführen bzw. den verlinkten dann in VIS, Skripten, etc. verwenden.
Wenn man jetzt z.B. hier noch eine Umrechnung haben möchte für die VIS, dann kann man sich z.B. eine zweite Instanz vom linkeddevices anlegen, mit dem verlinken DP von Insanz 0 verlinken und z.B. umrechnen. -
@scrounger Den Gedanken hatte ich zuerst auch, dass es nur in ein Richtung gespiegelt was auch vollkommen richtig ist, aber aus irgendeinem Grund geht es bei mir in beide Richtungen.
Hab es jetzt nochmal getestet:
neuen DP angelegt --> verlinkt --> history im linked DP aktiviert.
Ergebnis:
History wird nicht im source DP aktiviert --> Passt.Bei dem DP mit dem ich dieses Verhalten habe war bereits vor dem Verlinken History aktiviert - scheinbar funktioniert es dann in beide Richtungen. Nachdem ich jetzt den Link gelöst habe, History am source DP deaktiviert, den Link wieder aktiviert kann ich History am linked DP aktivieren und es wird nicht zurückgespiegelt --> Passt
Den grundsätzlich Gedanken des Adapter kann ich nachvollziehen (mache seit 26 Jahren Automatisierung
) und finde den Ansatz sehr gut - wie alle deine Sachen 
- was mir aber noch fehlt sind Strukturen und der Vorteil nur ein Verbindung herstellen zu müssen, das zieht sich aber durch IO Broker. Dein Adapter bzw. die Datenpunkte davon werden ja vom Geräte Adapter erkannt, leider kann man beim Geräte Adapter keine eigenen Datentypen anlegen. Das Ziel wäre es einen Datentyp z.B. Shelly 1 anzulegen und dann nur noch eine (1) Verbindung zum Device zu erstellen die Member sind ja bekannt und könnten somit automatisch verbunden werden. Dann fehlt nur noch ein Widget das sich genauso verhält und ich bringe mit 2 Verbindungen mein komplettes Device in die VIS - wenn ich die original DP nehme sogar nur mit einer Verbindung. Das Corona Widget ist hier ein Paradebeispiel.Gruß Bungee
-
@scrounger sagte in [Neuer Adapter] LinkedDevices:
@palm_maniac sagte in [Neuer Adapter] LinkedDevices:
Das Blockly scheint richtig zu arbeiten, da nur gerechnet wird. Es handelt sich dabei um einen Prozentwert zwischen 0 und 100.
Ich konnte es jetzt reproduzieren, der Fehler tritt auf, wenn der Wert
nulloderundefinedist.
Ich schätze das da was in deinem Blockly nicht korrekt läuft und eine der Werte schreibt.
Ich werd die log Ausgabe mal noch erweiteren, dass man sieht was zum Zeitpunkt des Fehlers für ein Wert verwenden wird.Teste mal die aktuelle version von github. Da wird jetzt angezeigt, welchen Wert er hat zum Zeitpunkt des Fehlers. Achtung ich hab die Info von error auf warn umgestellt, d.h. schau nach warn meldung. Wenn der fehler wieder auftritt bitte log posten
@bungee71 sagte in [Neuer Adapter] LinkedDevices:
Den grundsätzlich Gedanken des Adapter kann ich nachvollziehen (mache seit 26 Jahren Automatisierung
) und finde den Ansatz sehr gut - wie alle deine Sachen - was mir aber noch fehlt sind Strukturen und der Vorteil nur ein Verbindung herstellen zu müssen, das zieht sich aber durch IO Broker. Dein Adapter bzw. die Datenpunkte davon werden ja vom Geräte Adapter erkannt, leider kann man beim Geräte Adapter keine eigenen Datentypen anlegen. Das Ziel wäre es einen Datentyp z.B. Shelly 1 anzulegen und dann nur noch eine (1) Verbindung zum Device zu erstellen die Member sind ja bekannt und könnten somit automatisch verbunden werden.Schau mal hier, evtl. hilft dir das bei der Strukturierung weiter:
https://forum.iobroker.net/topic/40609/organisieren-mit-alias-wie-macht-ihr-dasDann fehlt nur noch ein Widget das sich genauso verhält und ich bringe mit 2 Verbindungen mein komplettes Device in die VIS - wenn ich die original DP nehme sogar nur mit einer Verbindung. Das Corona Widget ist hier ein Paradebeispiel.
Mit den Material Design Widgets und skripten ist sowas schon möglich
-
@scrounger Da ich deinen Adapter liebe und ich mit alias überhaupt nicht klar komme hier meine Frage:
Ist eine neue Adapterversion geplant, so das man unter der neuen Reac UI Linkeddevice wieder nutzen kann?
Im Moment erscheint es leider nicht mehr unter den States mit dem Schraubenschlüssel.
Das hält mich von einem dauerhaften umstellen auf Reac UI ab. Wäre toll, wenn du dir die Mühe machen könntest. Deine Fangemeinde wird es dir danken
-
@docgame
Bin ich dran, wir aber sicher noch dauern, weil da noch ein paar Sachen im Admin Adapter integriert werden müssen. -
Hi,
ich erhalte just nach (angeblich erfolgreichem) Install-Versuch folgende Fehlermeldung:host.HALslave-08 2021-05-08 09:49:07.109 error startInstance system.adapter.linkeddevices.0: required adapter "admin" not found!
Ja, es handelt sich um eine Multihost-Installation auf einem Slave (Raspi 4 8GB).
Die in diesem Faden irgendwann in 2019 gefundene Diskussion zur Multihost-Tauglichkeit hielt ich in der Argumentation (damals und völlig zustimme: Ausfallsicherheit bei Wegfall der Verbindung zum Host-Master auch nicht gegeben) für sicher überholt, erstrecht nach nun erfolgreicher Installation. Andere nur Master-taugliche Adapter (zB IoT) geben schon bei Installation eine Meldung + Install-Abbruch aus.Warum auf Slave? - Lastverteilung!
- Rechenlast (im Cluster schwacher Slaves schon wichtig)
- passende Hardware, z.B. RAM-Last, noch dazu umverteilbar bei Bedarf
- Übersichtlichkeit durch Aufgaben- und Standortgruppierung, ja, auch Standort der Geräte (Reaktionszeiten)
Außerdem hat der Master wahrlich wichtigeres zu tun (Koordinierung der Slave-Prozesse), als sich selbst auch noch um ihn selbst unnötig zusätzlich belastende Detailaufgeben zu kümmern. Alle IOs wie HM usw. laufen ja auch eh längst und besser auf darauf "spezialisierte" Slaves (Erfahrung nach > 2 Jahren entsprechenden Betrieb).
Im Zusammenhang mit Redis im Clusterbetrieb (auch Master ist dann nur ein weiterer "Slave") und dabei erfolgter Verteilung / autom Verfügbarkeitsanpassung durch die Redis-Clustergeräte bei Ausfall einzelner, gibt es eher GAR KEINEN Grund mehr, das auf dem Master zu zentrieren. Wenn die Redis-Slaves untereinander einen anderen Primärserver wählen, ist der Master eh nicht mehr der, der primär auf die Daten zugreift (bei mir 3 Raspi 4er, alle je mit 1TB SSD USB3-"Platte" nur dafür, Stückpreis zZt ca. 59,- bei MM/Sat). Billiger, performanter und hochverfügbarer gehts kaum noch. Ausserdem ist in der Redis Anleitung angekündigt, auch den Admin/Hostmaster ähnlich zur echten Cluster/Hochverfügbarkeit zu bringen...
Schade, ich fand den Ansatz vom Linkeddevice-Adapter um einiges flexibler, als im Alias und hätte ihn gerne verwendet.
Übrigens Ziel bei mir:
Ablösung meiner >3 Jahre alten Lösung für verteilte Verwaltung zusätzlicher DP in einzelnen Devices (mit "Vorgabe"-Device eines Typs -> Verteilung/Anpassung/Löschung der Zusatz-DB bei allen anderen Devices dieses Typs. Anwendung: Als Basis/Parameteriesierung/Datenschnittstelle/Triggerpunkte für darauf aufsetzende kognitive Verfahren, ohne jedes mal bei jeder kleinen Anpassung bei ALLEN Geräten eines Typs (Jalousien, od. Heizungen od. Switches usw.) alles manuell anpassen bzw. initial dort überhaupt ergänzen zu müssen. Gilt auch für Wegfall/hinzukommende Geräte des passenden Typs usw.Seit den 3 Jahren haben die Adapter-Entwickler einige Restriktionen eingefügt, wodurch "zusätzliche / ihnen unbekannte" DP Probleme dort bereiten. Verständlich. Das nun herauszunehmen, quasi als Spiegel der wenigen benötigten Basis-DP der Adapter und diese dann wie gehabt extern im Clone zu verwalten und zu nutzen (und so aus den eigentlichen Adapter-DP rauszuhalten), wäre mein Ziel. Fertige Arbeit wäre da natürlich sehr willkommen!
Wäre übrigens nett, wenn man auch einen eigenen Ziel-Baum (dessen Root) angeben könnte für die Clone-Objekte, also nicht nur wie jetzt default unter "linkeddevice.0" sondern da, wo wirklich (auch künftig) alle Freiheiten für eigene Scripts und Objektmanipulationen herrschen (javascript.n oder 0_userdata.n usw.). Ich will die nicht NOCHMAL sinnlos nach Basissystem-Änderungen anpassen müssen! (was ja eigentlich sehr im ursprünglichen Sinn dieses Adapters sein sollte, oder?
)Mal sehen, was der Alias-Adapter zur gleichen Aufgabe sagt. Auf Slave installieren UND da auch arbeiten, kann der Alias-Adapter schon mal. Falls aber das alles auch da doch nicht gehen sollte, werde ich auch die Basis-Daten-Verwaltung generell ins SQL zurückziehen müssen. ioBroker würde dann nur noch (ein weiterer) externer IO dafür sein, allerdings dann auch an keinen der eigentlichen, da bestehenden Module teilhaben können.
Gruß von der Küste
-
Noch eine Idee zur Konvertierung / Formel usw. beisteuern möchte:
...die ich übrigens sehr gut findeBei o.g. SQL-Engine hab ich vor einigen Jahren eine Rule-Engine vorgeschaltet, die ähnliches macht. Würde mich aber viel lieber "aus Kapazitätsgründen" auf die Kernmodule (FFT, Fuzzy, Neuro...) zurückziehen und gerne auf vorgeschaltete fertige und breiter gepflegte Module zurückgreifen, bei denen ich mich bei Bedarf natürlich zumindest mit (auch praktischen) Erfahrungen gerne einbringen könnte.
Ein wichtiges Modul fehlt im Konvertierungs-Kontext: Zeiten und Verzögeungen
also statische sowie dynamische temporale Filter bzw. "Konvertierungen"Klingt komplizierter als es ist. Simples Beispiel: Fenstergriff
Zu(unten)-Offen(quer)-gekippt(oben)Realität: Von gekippt auf zu in "einem Zug" bedient.
ABER: dabei erstes abgegebenes Signal ist OFFEN! (Millisec vor ZU, was mitunter verloren geht)
Lösung: "Verzögerungs-Filter", nichts anderes als "Frage Quell-DP nach x (=1 sec, parametrisierbar) nochmal nach seinem Status und überschreibe ihn ERST DANN im Ziel-DP
Könnte SEHR hilfreich sein. Und Stabilität stark erhöhen!
...und wäre gleich ebenso anwendbar auf Verzögerte Trainingsprozesse etc.Andere Temporalfilter: (quasi die "basalen"):
- wenn (made/mody, also ts oder lc) am DP im Zeitraum liegen/getriggert wurden (Wert triggert)
- nach Zeitpunkt liegen (und Weitergabe (Werteübernahme) noch nicht erfolgt ist) - (Zeit triggert)
- schon (relative Zeitangabe) Status x haben (="laufen", "alt sind") - (Polling / def. Zeitpunkte triggern)
...
Nur mal so als ein paar Ideen, die sich woanders schon sehr bewährt haben
-
Hi,
ich habe den Adapter im Einsatz und bin super zufrieden. Ich hab dazu auch den Adapter Eventlist (ist auch im Test) am laufen. Der Adapter Eventlist erkennt Datenpunkte von LinkedDevice leider nicht als bool. Kennt jemand das gleiche Phänomen? -
Hallo,
falls sich noch jemand nach einem Update des Admin-Adapters gewundert hat, dass jetzt alles anders aussieht und LinkedDevices nicht mehr funktioniert: Man kann in den Adaptereinstellungen des Admin-Adapters wieder zur alten Ansicht zurück wechseln.
Vielen Dank für die Arbeit an diesem Adapter.
