Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Sneak-L8]

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

@sneak-l8
Ja sorry link vergessen
https://github.com/oweitman/ioBroker.squeezeboxrpc/blob/54a78e0c428dec47e96ade29fd4aa530cf0eab4e/lib/iosbserver.js#L271

[Sneak-L8]

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

[OliverIO]

@sneak-l8
Ich denke nicht

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

[Sneak-L8]

@oliverio Genau den Satz hatte ich dort auch gelesen und genau daher gefragt (nicht , dass ich ihn falsch verstanden hatte) :)

[Sneak-L8]

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

[Sneak-L8]

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

[OliverIO]

@Sneak-L8

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

[Sneak-L8]

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

[OliverIO]

@sneak-l8

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.

https://github.com/ioBroker/ioBroker.js-controller/blob/5d9bc81716937c16ae2e89717eca3c9a1faee5d3/packages/controller/doc/adapter.js.html#L3519

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
usw

mü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.

[Sneak-L8]

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

[OliverIO]

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

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

[Sneak-L8]

@oliverio

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.

[OliverIO]

@sneak-l8

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?

[Sneak-L8]

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

[OliverIO]

@sneak-l8

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.

[Sneak-L8]

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

[OliverIO]

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

informationen 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

[Sneak-L8]

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