UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[SKB]

@apollon77 Nein, ich verwende die von ioBroker. Sie wird im head der Konfigurationsseite direkt vom Server (ioBroker Web-Adapter) abgerufen.

<script src="../../socket.io/socket.io.js"></script>

Hier habe ich, wie gesagt, festgestellt, das die transports default-mäßig auf polling stehen und dann auf websocket upgraden.

Wenn aber kein polling da ist (weil Web-Adapter auf irgendwas mit Websockets steht), kommt keine Verbindung zustande. Tauscht man sie in der Reihenfolge bzw. gibt sie an, dann wird erst ein Versuch zu websocket unternommen und dann ggf. polling versucht. Andersherum funktioniert es (leider) nicht.

// Global Socket Variable

const socket = io.connect(appProperties.socketURL, {
    path: appProperties.socketPath,
    reconnectionDelay: 500,
    reconnectionAttempts: Infinity,
    upgrade: true,
    transports: ['websocket', 'polling']

});

Also, erst polling und dann websocket. Ich denke, das ist von der socket.io Funktion so vorgegeben, das erst das "Schlechteste" versucht wird und dann eben "upgrade" erfolgt und nicht erst "Sehr gut" und wenn das nicht geht, fallback auf polling.

Durch einige Versuche hat mir das mit den transports eigentlich den gewünschten Erfolg gebracht ;)

[apollon77]

@skb Und du bist sicher das beim rumwechseln der Browser nicht was gecachtes genutzt hat?

Wenn das aber so ist wie Du sagt so kommt es mir so vor als ob das "io.connect" gar nicht das ist was vom server geladen wurde sondern ein anderes. Aber da kann ich jetzt nur raten.

[SKB]

@apollon77 Also, ich binde nur die socket.io.js bei mir ein und erstelle dann das Socket Objekt.

Und wie gesagt, wenn man die Transports nicht in der Reihenfolge anpasst, kommt keine Verbindung zustande.

[apollon77]

Hast Du mal den Link zum Adapter-Code?

Und schau mal ob das "io" Objekt wirklich von unserem JS File kommt.

Auch iunteressant wäre mal die genaue Request Reihenfolge aus den Netzwerk-Tab bei Websockets only ... um zu sehen was genau passiert. Scheinbar kommt ja der HTTP-Upgrade nicht durch?

[SKB]

@apollon77 ja, Io kommt von dem File.

So steht es auch bei socket.io beschrieben.

Mit dem Adapter Code wird man nicht weiterkommen, da der Adapter seine eigene (ausgelagerte) Konfigurationsseite hat und nur Basics über die interne ioBroker Seite einstellt. Es geht um den Adapter in meiner Signatur.

Wie gesagt, das Problem ist eigentlich "behoben", jedoch dachte ich, es gäbe da ein "automatisches Verbinden" bzw. automatische Erkennung.

[apollon77]

@skb Naja, Du nutzt einen Workaround der eigentlich nicht nötig sein sollte bzw semantisch nicht sein dürfte!

Wenn die "io" Klasse immer vom web-serve rgeladen wird und Wenn im Web-Server "Websockets nutzen" gewählt ist dann bekommst Du eine socket.io.js die sowas wie polling gar nicht kennt weil es eine "API-Kompatible ioBroker eigene lib" ist. Damit ist am Ende auch egal was bei socket.io generell beschrieben ist weil es ja kein "echtes" socket.io ist, sondern etwas was nur nach aussen so aussieht.

Deshalb meine obigen Fragen ... weil es. sollte das alles gar nicht passieren!

Von daher wäre interessant:

• Was genau wird da runtergeladen bei einer "Websocket only" konfiguration? mal Netzwerk-Tab den content schauen und ggf posten. Wenn iobroker.ws genutzt wird dann sollte das file sowas sein https://github.com/ioBroker/ioBroker.ws/blob/main/lib/socket.io.js und nicht das offizielle socketio

Und die Fragen oben

[SKB]

@apollon77 Nochmal von Anfag:

Ich habe einen Adapter in ioBroker, der läuft und tut was er soll.
Da die Konfiguration aber über eine andere Webseite stattfindet, die nicht über die Adminoberfläche aufgerufen wird, benötige ich ja Zugriff auf die States, um die Konfig abzuspeichern oder auch Dinge abzufragen.

Also habe ich im WWW Verzeichnis meines Adapter eine "configuration.html" Datei, die das o.g. File direkt über den Web-Adapter lädt. (ist ja vorhanden: https://github.com/ioBroker/ioBroker.web/blob/master/www/lib/js/socket.io.js)

Ich habe keine socket.io Datei irgendwo heruntergeladen, sondern die von ioBroker genutzt. Die eben beim Web-Adapter dabei ist.

Wenn man diese Datei einbindet, bekommt man das io Object aus der Datei, wo man dann die Konfiguration einbinden kann.

Was Anderes macht der iQontrol-Adapter auch nicht: https://github.com/sbormann/ioBroker.iqontrol/blob/03f622565194e7e3909fab85911f6d3624eb5b7e/www/index.html#L57

Mit dem Funktionsaufruf:
https://github.com/sbormann/ioBroker.iqontrol/blob/03f622565194e7e3909fab85911f6d3624eb5b7e/www/index.js#L14258

Bei ihm steht auch, das der Web-Adapter eben entsprechend eingestellt sein muss:
https://github.com/sbormann/ioBroker.iqontrol/tree/master?tab=readme-ov-file#you-need

So, da ich aber nun für beide Fälle (egal, was im Web-Adapter angehakt oder weggeklickt ist) eine Verbindung habe, stellt sich mir immer noch die Anfangsfrage:

Wieso hat diese socket.io keiner "Art" Auto-Negotiation -> Ermittel, ist der Server da, wenn ja, verbinde mit dem Möglichen und nicht, wenn "polling" nicht geht - verweigere die socket-Vebindung.

[apollon77]

Wir drehen uns im Kreis :-)

Also habe ich im WWW Verzeichnis meines Adapter eine "configuration.html" Datei, die das o.g. File direkt über den Web-Adapter lädt. (ist ja vorhanden: https://github.com/ioBroker/ioBroker.web/blob/master/www/lib/js/socket.io.js)

Ja da liegt eine aber ob Du diese oder eine andere beim Abfragen über den Web-Server geliefert bekommst steht auf einem anderen Blatt, weil es von der Konfiguration der Web Instanz abhängt. Siehe https://github.com/ioBroker/ioBroker.web/blob/master/main.js#L996

Womit ich wieder bei der Frage bin ob denn im richtigen Fall (also mit nur Websockets und so) auch das richtige (ANDERES als das Standard file!) zurückgegeben wird. Weil wenn nicht ist das ein Bug und muss gefixt werden.

Wieso hat diese socket.io keiner "Art" Auto-Negotiation -> Ermittel, ist der Server da, wenn ja, verbinde mit dem Möglichen und nicht, wenn "polling" nicht geht - verweigere die socket-Vebindung.

Wenn das richtige File ausgegeben wird - siehe Link oben, das vom ws Adapter - dann ist da keinerlei polling logik drin. Dann braucht er auch keine Auto Negotiation weil entweder websocket geht oder halt nicht.

[SKB]

@apollon77 So, also ich habe es jetzt mal so getestet:

Web-Adapter steht auf integriert und sonst alles aus:

Web-Adapter auf "Web-Sockets erzwingen":

Web-Adapter "Reine Web-Sockets":

Erst hier wird die WS-Datei von ioBroker geladen.

Aber, nochmals dazu gesagt: Die Library von socket.io geht andersherum vor, als es ioBroker tut bzw. vielleicht gedacht ist.
Zuerst wird geprüft, ob der Server da ist, wenn ja, wird versucht, über polling zu verbinden. Wenn das erfolgreich ist, wird auf sockets gewechselt.

Da aber wohl der Web-Adapter quasi gänzlich das polling abschaltet, wenn der Web-Adapter eines der Sockets verwenden soll, läuft das Scoekt Ding ins Leere, weil es "andersherum" läuft.

Daher meine Aussage mit den "transports" - wenn diese gedreht sind, gehts ;)

[apollon77]

@skb ich denke das zweite ist falsch ... kannste mit den screenshots bitte mal issue anlegen? muss sich Denis anschauen

[SKB]

@apollon77 Klar, mache ich. Danke!

[apollon77]

@skb sagte in Web-Adapter mit/ohne Websockets ansprechen:

Web-Adapter auf "Web-Sockets erzwingen":

Okk ... Geheimnis gelüftet.

Diese EInstellung zwingt socket.io dazu nur Websocket zu nutzen. Also ist das ausgelieferte File korrekt und ja wer diese EInstellung braucht MUSS auch im socket.io client das polling ausschalten (oder in der liste nach hinten machen, am besten ganz weg).

Also am besten nicht nutzen :-)

Also entweder "integriert" oder "Reine Web-Sockets"