Mehrfach auf selber IP-Adresse lauschen
-
Hallo zusamen,
ich habe einen Adapter, der per UDP-Kommandos mit einer Wallbox spricht. Dazu gibt es drei UDP4-Sockets: einer der Befehle sendet, einer der die direkten Antworten entgegen nimmt und einer der Broadcasts (auf einem anderen Port) empfängt.
Wenn nun zwei Wallboxen angeschlossen sind und ich eine 2. Instanz des Adapters nutzen will, um auch die 2. Wallbox zu steuern, dann habe ich das Problem, dass die "Listening"-Address bereits in Gebrauch ist (EADDRINUSE).
Ich vermute, dass liegt daran, dass ja alle Instanzen auf demselben Rechner liegen und man jede Kombination aus IP-Adresse und Port nur einmal nutzen kann. Ist das richtig?Gibt es eine Möglichkeit, das "Lauschen" auf eine Sender-IP-Adresse zu begrenzen um mehrere Sockets mit verschiedenen IP-Adressen nutzen zu können?
Oder kann ich auf einem Port mit allen Instanzen nur genau ein mal lauschen?
Falls ja, bliebe mir wohl nur die Wahl, mehrere Wallboxen in einem Adapter zusammen zu verwalten oder eine Master-Instanz zu bestimmen, die dann mit den anderen Instanzen kommuniziert, indem sie diesen die empfangenen Daten weiterleitet.
Wenn dem so ist: welche Variante würdet Ihr empfehlen? Gibt es da evtl. schon ein how-to?Da kenne ich mich zu wenig mit Sockets und dem üblichen Vorgehen in ioBroker bzw. Node-Js aus.
Viele Grüße
Sneak-L8 -
@sneak-l8 Soviel ich weiss heisst die Lösung "reuseAddr", allerdings habe ich das mit Node noch nie versucht.
-
@unclesam Super, viiiieeelen Dank. Das war genau, was ich gesucht habe. Einfach die reuseAddr beim createSocket dazupacken und schon kann man mehrere Verbindungen gleichzeitig auf derselben IP nutzen. Klappt!
-
@sneak-l8 Hallo zusammen, der Tipp von @UncleSam hat geholfen, aber nun komme ich zu einem zweiten Problem.
Wenn mehrere Instanzen auf demselben Port lauschen, bekommt nur eine Instanz alle "normale" Antworten mit, die anderen empfangen die Nachrichten nicht.
Broadcast-Nachrichten from externen Gerät dagegeben kommen bei allen Instanzen an.
An was könnte das liegen? Die Adresse die ich beim .bind angeen kann, bezieht sich ja auch den lokalen Rechner und nicht auf die IP-Adresse des Gerätes, auf das ch lauschen will.
Gibt es sonst noch eine Möglichkeit?
Oder kann ich von einer Instanz zur anderen eigene "Nachrichten" schicken?Dieser Seite zufolge ist es eben genau so wie ich es beschrieben habe. Broadcast kommen überall an, andere Nachrichten nur bei der zuletzt gebundenen Instanz (Für Details wird auf diese Seite verwiesen)
Damit rückt die FRage oben stärker in den Fokus: wie können Instanzen von ioBroker-Adaptern miteinander kommunizieren?
-
-
@oliverio https://github.com/iobroker-community-adapters/ioBroker.kecontact/tree/newAdapterBase
reuseaddr mache ich bereits, das war ja der Tipp von UncleSam. Bind funktioniert auch, nur kommen wie auch im Link beschrieben nur beim zuletzt gebundenen Adapter die Nachrichten an. Das hat mir ein Tester auch sehr gut durch ein Log-Mitschnitt gezeigt.
-
schau mal hier.
ich hab den bind-befehl etwas anders.
die angabe von 0.0.0.0 ist wohl noch sowas wie ein filter (also hier alles)
und ich setze nochmal explitzit die setbroadcast funktion -
@oliverio Danke für die Rückmeldung. Ich vermute, hinter "hier" sollte sich ein Link verbergen. Der scheint aber nicht da zusein.
Ich verstehe bisher nur so viel. setBroadcast sollte ich auch bei der normalen Verbindung setzen und 0.0.0.0 expliziet angeben anstatt keine IP-Adresse anzugeben? -
-
@oliverio Ok, danke , probiere ich aus.
Sollte ja keinen UInterschied machen, ob ich den Broadcast in "on listening" oder als function beim bin mache. Passiert ja mehr oder minder zur selben Zeit, oder? -
@sneak-l8
Ich denke nichtAus der Node Doku
Specifying both a 'listening' event listener and passing a callback to the socket.bind() method is not harmful but not very useful. -
@oliverio Genau den Satz hatte ich dort auch gelesen und genau daher gefragt (nicht , dass ich ihn falsch verstanden hatte)
-
@sneak-l8 So, Test war leider nicht erfolgreich. Es empfängt weiterhin nur der letzte der sich eingeklinkt hat die Daten.
Hab jetzt nochmal bei Stackoverflow nachgelesen. Zwei Möglichkeitne sehe ich noch.
Das eine wäre REUSEPORt anstelle REUSEADDR und das zweite wäre der Versuch mit Connect auf die konkrete IP-Adresse der jeweiligen Wallbox zu binden. -
@oliverio So, ich hab's nochmal versucht. reuseport gibt es bei NodeJs unter Linux wohl gar nicht. Das klappt schon mal nicht. Und mit connect komme ich auch nicht weiter, da muss ich ja beim send.Objekt auch lauschen und bekomme nicht zurück.
Ich befüchte, die Beschreibungen haben recht, dass es nur bei Broadcast-Messages geht.
Dann bliebe die Frage, ob ich zwischen den Adaptern kommunizieren kann? Also entweder über eine Art Message oder direkter Aufruf einer Methode einer anderen Instanz des Adapters?
-
Hm schwierig. Eigentlich h dachte ich seh das das funktionieren müsste. Evtl mit noch anderen Einstellungen
Ansonsten kannst natürlich auch selbes noch eine Kommunikation aufbauen durch senden und empfangen von Netzwerk nachrichten
-
@oliverio Ich habe es jetzt so gelöst, dass mittels "reuseaddr" alle Instanzen auf derselben Adresse/demselben Port lauschen. Nur eine Instanz bekommt dann die Antworten. Diese prüft, ob die Nachricht von der IP-adresse der in dieser Instanz verwalteten Wallbox kommt.
Andernfalls wird die Instanz ermittelt die sich um diese Wallbox kümmert und die Nachricht in einen State dieser Instanz geschrieben. Über einen Listener reagiert die Instanz dann auf das setzen des States.Bei der Ermittlung des State nutze ich getForeignObjects leider kommen mit "system.adapter.<adapterName>." alle möglichen Daten zu den Instanzen, abern icht das Objekt der Instanz. Daher frage ich nach "system.adapter.<adapterName>..uptime", um aus den Antworten dann die Instanzen zu ermitteln und mittels getForeignObject dann direkt "system.adapter.<adapterName>.<n>" zu lesen. Dort finde ich dann unter native.host die für die Instanz hinterlegte IP-Adresse.
Weißt Du, ob es einen kürzeren Weg gibt, an die Instanz mit native.host = <IP-Adresse> zu kommen? -
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.
