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

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

Pull Request auf GitHub

Git ist für mich noch ein rotes Tuch, wo mir die Zeit fehlt, mich reinzuarbeiten (hab relativ wenig Nutzen davon). Könnte mir aber vorstellen, das Example mal etwas aufzubohren...

@unclesam said in socket.io (eigene Visualisierung):

Ja, dann brauchst du eigentlich den gesamten Objektbaum.

...aber nur von den Datenpunkten, die ich brauche. Sosnt sind das auch viel zu viele (komme mit 1000 nicht hin, hab ja schon weit über 100 Shellys).

@unclesam said in socket.io (eigene Visualisierung):

Den kannst du dir holen, indem du objectsRequired im init() auf true setzt
Wo landen die denn dann?

Bin jetzt mit dem Debugger durch:
Er steigt hier in _queueCmdIfRequired() aus (da kommt true zurück) :
https://github.com/ioBroker/ioBroker.socketio/blob/919a467121e673590377a4fd1023f99ee38656b5/example/conn.js#L1259

Werde ich aber gerade nicht schlau raus.

Spontan sieht es so aus, als ob er den Befehl in eine Queue schreibt, diese aber nicht ausführt...

[UncleSam]

@d-ve sagte in socket.io (eigene Visualisierung):

Git ist für mich noch ein rotes Tuch, wo mir die Zeit fehlt, mich reinzuarbeiten (hab relativ wenig Nutzen davon). Könnte mir aber vorstellen, das Example mal etwas aufzubohren...

Der Vorteil von GitHub: du musst gar nichts mit Git machen, du kannst einfach die Dateien anpassen und daraus einen PR erstellen. Alles im Browser. Lohnt sich, das mal anzuschauen.

Wo landen die denn dann?

Da lag ich etwas falsch, es ist eine Object Subscription, du erhälst einfach Objekt-Veränderungen. Du kannst dich darauf mit dem onObjectChange Callback registrieren.

Bin jetzt mit dem Debugger durch:
Er steigt hier in _queueCmdIfRequired() aus (da kommt true zurück) :

Was sagen die lokalen Variablen, wenn du in der Funktion bist? Insbesondere this._authRunning und this._isAuthDone.

Allgemeine Frage: musst du dich authentifizieren? Hast du einen ioBroker Benutzer mit Passwort?

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

Da lag ich etwas falsch, es ist eine Object Subscription, du erhälst einfach Objekt-Veränderungen

Wie werden die getriggert? Bei onUpdate() werden ja alle Änderungen reingespült.

@unclesam said in socket.io (eigene Visualisierung):

Was sagen die lokalen Variablen, wenn du in der Funktion bist? Insbesondere this._authRunning und this._isAuthDone.

beide false

@unclesam said in socket.io (eigene Visualisierung):

Allgemeine Frage: musst du dich authentifizieren? Hast du einen ioBroker Benutzer mit Passwort?
Nein, noch nicht...

[UncleSam]

@d-ve sagte in socket.io (eigene Visualisierung):

Wie werden die getriggert? Bei onUpdate() werden ja alle Änderungen reingespült.

Bei Änderungen am Objekt (nicht am State). Das ist eine eher seltene Angelegenheit.

beide false

Wenn du den Breakpoint hier setzt: https://github.com/ioBroker/ioBroker.socketio/blob/919a467121e673590377a4fd1023f99ee38656b5/example/conn.js#L1270

• wird der angesprungen?
• was ist der Inhalt von version?

Nein, noch nicht...

OK, dann ist das mal kein Problem.

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

wird der angesprungen?

yep

@unclesam said in socket.io (eigene Visualisierung):

was ist der Inhalt von version?

4.1.11

[UncleSam]

@d-ve Dann ist das ja gut. Und ich nehme an, es wird auch nur einmal angesprungen. Danach ist die Verbindung da und alles ist gut. Kannst du mal den Vorschlag von @OliverIO versuchen und/oder schauen, was in Chrome / Edge (oder FF???) in den Entwickler-Tools unter "Netzwerk" steht. Es gibt dort eine langlebige Verbindung (unter "Time" steht bei mir "Pending") (1), dort kannst du drauf klicken und auf den Reiter "Messages" wechseln (2); da solltest du alle ausgetauschten Nachrichten sehen (3):

Was steht da bei dir?

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

da solltest du alle ausgetauschten Nachrichten sehen

Ab da kommen nur noch stateChange Nachrichten

Hab auch nochmal geschaut, die Queue wird wohl irgendwo geleert:

Hat das was zu bedeuten?

Trying to get states again, because emitted getStates still pending

[UncleSam]

@d-ve Ja, es scheint, dass getStates hängt. Du hast gesagt dass du tausende States hast. Vielleicht solltest du wirklich nur die States holen, die du brauchst.

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

@d-ve Ja, es scheint, dass getStates hängt. Du hast gesagt dass du tausende States hast. Vielleicht solltest du wirklich nur die States holen, die du brauchst.

das ist ja genau das, was ich hier von Anfang an versuche... Weiß nur nicht wie...

[UncleSam]

@d-ve sagte in socket.io (eigene Visualisierung):

das ist ja genau das, was ich hier von Anfang an versuche... Weiß nur nicht wie...

Sorry, jetzt haben wir uns wirklich genau einmal in Kreis gedreht. Naja, immerhin habe ich eine Information mehr: es gibt einen Request für ["getStates", "*"]. Im Code von conn.js finde ich dazu nichts. Machst du das in deinem Code?

Im Beispiel-Code wir das hier gemacht: https://github.com/ioBroker/ioBroker.socketio/blob/919a467121e673590377a4fd1023f99ee38656b5/example/index.html#L27

Bei dir würde ich aber wie gesagt nicht empfehlen, alle States zu holen.

Wenn du nicht weisst, woher der Request kommt, dann setze mal hier einen Breakpoint:
https://github.com/ioBroker/ioBroker.socketio/blob/919a467121e673590377a4fd1023f99ee38656b5/example/conn.js#L775
und schau dir dann den Callstack an.

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

Im Beispiel-Code wir das hier gemacht: https://github.com/ioBroker/ioBroker.socketio/blob/919a467121e673590377a4fd1023f99ee38656b5/example/index.html#L27

I know... das hat nur nicht funktioniert... Deswegen habe ich den Request jetzt schon dreihundertiverundachtzigmal umgeschrieben

@unclesam said in socket.io (eigene Visualisierung):

Bei dir würde ich aber wie gesagt nicht empfehlen, alle States zu holen.

Wie gesagt, habe ich auch nicht vor... Ich möchte momentan einfach nur mal IRGENDEINEN State holen, am liebsten ein spezifisches Device.
Momentan funktioniert bei mir nur der onUpdate()-Teil. Aber wenn ich den Status meiner Lampe anzeigen will, kann nicht so lange warten bis die sich mal bequemt, zufällig ein Update zu senden.

lg, Dave

[UncleSam]

@d-ve Jedes Mal, wenn ich deinen Screenshot anschaue, fällt mir wieder etwas auf...

Auf welchen Port verbindest du dich mit dem socket.io Server? Machst du das etwa mit Port 8081? Gleich nach deinem "getStates()" reklamiert nämlich der Admin, dass mit dem Request etwas nicht stimmt. Richtig wäre der Port des socket.io Adapters (normalerweise 8082).

[Homoran]

@unclesam sagte in socket.io (eigene Visualisierung):

Richtig wäre der Port des socket.io Adapters (normalerweise 8082).

8084!

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

Auf welchen Port verbindest du dich mit dem socket.io Server? Machst du das etwa mit Port 8081?

Ja nehme 8081. 8084 aus dem Beispiel hat garnicht funktioniert...

@unclesam said in socket.io (eigene Visualisierung):

der Port des socket.io Adapters (normalerweise 8082).

Hmmm... das könnte die Ursache sein, wobei sich mir dann die Frage stellt, warum der Adapter unter 8081 dann überhaupt antwortet. Kann das nachher mal mit 8082 testen (bin gerade nicht am Platz).

lg, Dave

[Homoran]

@d-ve Bitte sieh bei dir nach auf welchem Port dein socket.io läuft
8082 ist der port für den Web-Adapter, 8081 für den admin, socket.io hat üblicherweise 8084, könnte aber bei dir umkonfiguriert sein.

[UncleSam]

@d-ve sagte in socket.io (eigene Visualisierung):

wobei sich mir dann die Frage stellt, warum der Adapter unter 8081 dann überhaupt antwortet

Ganz einfach: das ist der Port von Admin. Und Admin verwendet auch socket.io, aber teilweise andere Befehle (da Admin mehr können muss als Socket.io).

Und: den socket.io Adapter hast du schon installiert, oder?

[UncleSam]

@homoran sagte in socket.io (eigene Visualisierung):

8082 ist der port für den Web-Adapter, 8081 für den admin, socket.io hat üblicherweise 8084, könnte aber bei dir umkonfiguriert sein.

Richtig, hatte ich verwechselt. Aber gibt es einen Grund, nicht einfach die socket.io Verbindung vom Web-Adapter zu verwenden? Die sollte ja identisch sein mit dem anderen socket.io, oder auch nicht? Ich verwende für meine selbstgeschriebene Vis einfach Port 8082 und habe den socket.io gar nicht installiert. Aber ich verwende auch nicht conn.js sondern habe da selber Code geschrieben (da es eine Angular App ist).

[Homoran]

@unclesam sagte in socket.io (eigene Visualisierung):

die socket.io Verbindung vom Web-Adapter zu verwenden? Die sollte ja identisch sein mit dem anderen socket.io, oder auch nicht?

Da habe ich ehrlich keine Ahnung, habe nur festgestellt, dass es Problem mit dem Web-Adapter gab, die dadurch zu lösen waren nicht den internen socket zu nehmen.

[D.VE]

@unclesam said in socket.io (eigene Visualisierung):

Und: den socket.io Adapter hast du schon installiert, oder?

Öhem... Nö... :grimacing:
Hätte ich sollen?
Braucht man da noch eine zweite Instanz extra für eigene Implementierung?

[UncleSam]

@d-ve sagte in socket.io (eigene Visualisierung):

Braucht man da noch eine zweite Instanz extra für eigene Implementierung?

Bei mir funktioniert es mit Port 8082 und dem (normalen) Web Adapter. Damit brauchst du keine zweite Instanz.

Wenn du es ganz korrekt machen willst, musst du den socket.io Adapter installieren und Port 8084 verwenden.

Port 8081 darfst du niemals verwenden (der hat auch erhöhte Rechte und wird möglicherweise in Zukunft noch besser abgesichert).