Mehrfach auf selber IP-Adresse lauschen
-
ich muss nochmal nachfragen.
du programmierst einen adapter?
der folgende befehl kann aus dem script-adapter und aus den widgets heraus aufgerufen werden, aber jedesmal etwas anders.mit diesem befehl kannst du alle datenpunkte abrufen, die einem muster entsprechen.
wenn ich davon ausgehe, das die datenpunkte mit der jeweiligen ip wie folgt heißt:
adaptername.0.datenpunktname
adaptername.1.datenpunktname
uswmüsste es wie folgt funktionieren
var key = "adaptername.*.datenpunktname" adapter.getStates(key, function (err, states) { for (var id in states) { adapter.log.debug('"' + id + '" = "' + states[id].val); } });im states-array hast du dann jeweils die gefundenen datenpunkte als objekt.
ich würde dann anhand des timestamps den jeweils zuletzt beschriebenen datenpunkt heraussuchen und da dann den wert (also die ip-adresse) weiter verarbeiten.
die verfügbaren properties und deren bezeichnung eines datenpunkts sind mir aktuell nicht geläufig. aber mit einem debugger kannst das ja schnell sehen. -
@oliverio Ja, ich programiere einen Adapter (kecontact).
Mit getStates bekomme ich nur die States eines Adapters (so habe ich es bisher verstanden). Wenn ich die Objects (der Instanz) eines Adapters brauche, muss ich getObjects() nehmen. Und mir geht es um eine Einstellung (native.host = IP-adresse der Wallbox), nach der ich in den Instanzen suche.Da ich die Daten einer anderen Instanz brauche, muss ich getForeignObjects() nehmen.
Hier mal mein Codeausschnitt dazu:
const prefix = "system.adapter."; const adapterpart = adapter.name + "."; const suffix = ".uptime"; adapter.getForeignObjects(prefix + adapterpart + "*" + suffix, function(err, objects) { if (err) { adapter.log.error("Error while fetching other instances: " + err); return; } if (objects) { for (const item in objects) { if (Object.prototype.hasOwnProperty.call(objects, item) && item.endsWith(suffix)) { const namespace = item.slice(prefix.length, - suffix.length); adapter.getForeignObject(prefix + namespace, function(err, object) { if (err) { adapter.log.error("Error while fetching other instances: " + err); return; } if (object) { if (Object.prototype.hasOwnProperty.call(object, "native")) { if (Object.prototype.hasOwnProperty.call(object.native, "host")) { if (object.native.host == remote.address) { adapter.setForeignState(namespace + "." + stateMsgFromOtherwallbox, message.toString().trim()); adapter.log.debug("Message from " + remote.address + " send to " + namespace); } } } } }); } } }wobei "remote.address" die gesuchte IP-Adresse der Instanz und "message" die er UDP empfangene Nachricht enthält.
Ich nehme das Pattern "system.adapter.kecontact.*.uptime", weil die getForeignObjects-Methode bei "system.adapter.kecontact.*" leider nur die Daten, aber nicht system.adapter.kecontact.1 findet...
-
@sneak-l8
ah ja verstehe.
ich nenne das für mich die Konfigurationseinstellungen einer Instanz.ja das kannst du so abfragen. ich würde es aber dennoch über datenpunkte machen.
dein adapter weiß ja erst einmal nicht ob es von ihm 1 oder mehr instanzen gibt.
daher muss er erst einmal das abfragen.
wenn mehrere instanzen laufen, dann passieren da konkurrierende abfragen.
es bleibt zufall, welche instanz als erstes den broadcast abfragt und das in das richtige setting schreibt.daher jede instanz hört auf den broadcast
jede instanz sucht nach anderen instanzen des adapters und abonniert auf die änderung des/der jeweiligen anderen datenpunkte, sowie schaut ob schon was drin steht und nimmt den jüngsten wert allerdie instanz die den broadcast erhält setzt den datenpunkt
die anderen erhalten den trigger
das übernehmen des jüngsten werts aus allen datenpunkten geschieht, falls eine instanz später (neu)gestartet wird. da kommt kein trigger weil der wert ja schon geschrieben ist.wie gesagt, ich würde das über einen datenpunkt machen und nicht über die instanzkonfiguration.
-
es bleibt zufall, welche instanz als erstes den broadcast abfragt und das in das richtige setting schreibt.
Nicht ganz.Broadcasts werden an alle Instanzen durchgereicht. Direkte Antworten auf einen UDP-Befehl eine beliebigen Instanz des Adapters gehen alle an die letzt-gestartete Instanz.
Sowohl bei Broadcasts als auch bei direkten Antworten prüft die Instanz zunächst, ob das Datenpaket von der der Wallbox mit der in den Konfigurationseinstellungen hinterlegten IP-Adresse kommt.
Bei Broadcasts werden fremde Antworten einfach ignoriert, nur direkte Antworten müssen an die anderen Instanzen weitergereicht werden.
Wenn ich wie von Dir vorgeschlagen einen Datenpunkt angelegen würde und die anderen Instanzen lauschen auf eine Änderung dieses Datenpunktes dann habe ich mehrere Nachteile:
- alle Instanzen müssen auf die Datenpunkte aller anderen Instanzen lauschen, denn sie wissen weder, wer die Daten empfangen wird, noch ist dies konstant
- wenn die letzt-gestartete Instanz eendet wird, bekommt künftig automatisch die vorletzt-gestartete Instanz die Anworten.
- es muss ein 2. Datenpnukt geschrieben werden oder die Antwort so verpackt werden, dass die "Absender-IP-Adresse" mitgeschrieben wird, damit jede Instanz erkennen kann, ob die Daten für sie sind
- wenn quasi gleichzeitig Daten von mehreren Wallboxen eintreffen und diese sofort in alle Instanz-Datenpunkte geschrieben werden, dann besteht die Gefahr, dass die zweite Nachricht die erste überschreibt, bevor die erste ausgewertet wurde (oder gibt es da ein saubere Queueing?)
Daher habe ich mich entschieden, dass der aktuelel Empfänger die Daten an die anderen Instanzen weiterreicht. Damit ich die Daten nicht mehrfach schreiben muss (und nicht zusätzlich die Absender-IP hinterlegen muss), hole ich mir alle Instanzen und schaue, wer für die IP-Adresse zuständig ist. Diese Instanz bekommt dann die Nachricht als Datenpunkt geschrieben.
Ich hoffe, ich konnte das verständlich erklären.
-
mal eine frage:
warum willst du eigentlich mehrere instanzen eines adapter laufen haben?
evtl ist da der logik-knick
so wie ich verstanden habe, kommuniziert dein entferntes gerät nur mit einer instanz.
das ist von netzwerks wegen auch so korrekt.
aber wenn du eine unterteilung machst (über mehrere instanzen des selben adapters,
dann kannst du das doch auch alles innerhalb einer instanz selbst machen? -
@oliverio Das ganze wird nur benötigt, wenn es mehrere Wallboxen gibt, die ihre Daten liefern. Je Wallbox eine Instanz. Jede Wallbox hat zwar eine andere IP-Adresse (die ich in der Instanz hinterlege), aber sie senden immer auf demselben Port.
Damit gehen alle Antworten aller Wallboxen immer an die IP-Adresse auf die der ioBroker lauscht und imemr mit demselben Port. Da braucht es einen Verteiler, der die Nachrichten der verschiedenen Wallboxen an die entsprechende Instanz verteilt.
Klar, ich könnte jetzt auch den Adapter so umbauen, dass er gleichzeitig mit mehrerne Wallboxen umgehen kann. Aber dann stellt sich wieder die Frage, ob das wirklich einfacher ist. Ich muss dann entweder mehrere IP-Adressen eingeben lassen oder versuche die Boxen über Broadcast-Pings selbst zu erkennen.
Und bei den States müsste ich die Wallboxen eindeutig zuordnen. Also z.B. je Serien-Nr. ein Channel. Laufende Nummerierung könnte ungeschickt sein... -
wer öffnet die kommunikation?
die wallbox oder die instanz?wenn die instanz öffnet dann wird lokal ein anderer port verwendet, nur der zielport muss passen.
-
@oliverio Die Kommunikation wird vom Adapter initiiert. Aber die Antwort kommt nicht auf demselben Socket zurück, der die anfrage sendet. Es wird ein weiterer socket geöffnet, der auf einem festen Port lauscht.
Ich hatte mal versucht, den txSockert auch für den Empfang zu nutzen, das war aber nicht von Eroflg gekrönt.Da es UDP-Pakete sind, sind es ja auch keine wirklichen Verbindungen mit einer Antwort, sondern wohl sowieso eine von der Wallbox initiierte Nachricht. Und die legt dann den Port des Empfängers fest.
-
@sneak-l8
also ich hab mir mal andere module bei github zu kecontact sowie den programming guide angeschaut. da seh ich nix speziell schwieriges
https://github.com/Bonnee/JuiceUp
https://github.com/dannerph/keba-kecontactinformationen empfangen
informationen von deiner wallbox wird per broadcast an alle geräte die darauf horchen verteilt.
also: alle instanzen horchen auf port 7090
broadcasts sind immer UDP nachrichten.
damit mehrere auf dem gleichen rechner auf den port hören können, dann muss reuse verwendet werden.Befehle an die Wallbox senden
var dgram = require('dgram'); var client = dgram.createSocket('udp4'); client.send('Hello World!',7090, '192.168.1.111');7090 ist der empfängerport
der absender port wird hier nicht definiert, den sucht sich der netzwerkstack automatisch
192.168.1.111
ist die empfänger ip, die du auf basis des broadcasts als absender ermittelt hast, oder den der benutzer konfiguriert hat.meines erachtens benötigst du nicht unbedingt mehrere instanzen bei mehreren wallboxen.
der adapter erkennt auf basis der eingehenden broadcasts alle im netz verfügbaren wallboxen und legt dazu dann die entsprechenden datenpunkte an.
wenn per broadcast neue daten kommen, werden die entsprechenden datenpunkte aktualisiert (ack=true).
wenn ein benutzer einen datenpunkt ändert(ack=false), dann wird die information an die wallbox gesendet. die Bestätigung kommt dann über den broadcast -
@oliverio Danke für die Links und die weitergehendes Infos.
Die Wallboxen senden periodisch Daten per Broadcast an Port 7092. Direkte Antworten (z.B. auf "report 1") sind keine Broadcasts und kommen somit - auch bei reuseAddr - nur bei einer Instanz an
Klar kann ich alle Wallboxen in einer Instanz verwalten. Dann muss der Adapter aber multi-device-fähig sein und wie zuvor beschrieben z.B. die States entsprechend strukturieren.
Ich wollte bewusst einen Ansatz mit einer Instanz je Wallbox.P.S. Bei Deinem 1. Link ist auch die PDf von Keba mit eingecheckt, die die Kommunikation mit der Wallbox beschreibt.
