Test Adapter nanoleaf-lightpanels v1.3.x GitHub/latest
-
@ofbeqnpolkkl6mby5e13
Also EHOSTUNREACH heißt, dass dein Gerät netzwerktechnisch schlicht nicht erreichbar ist. Wenn es unter der IP erreichbar ist, aber der Service nicht läuft, dann gibts normalerweise ein ECONNREFUSED, also die Verbindung wird abgelehnt, aber der Host ist erreichbar.
Prüfe mal bitte, ob deine Canvas unter der IP, die du angegeben hast, auch erreichbar ist. Die sollten via Ping erreichbar sein.Ich update meine Test-Canvas jetzt auch mal auf die neuste Version (ich habe sonst nur Light Panels im Einsatz) und schaue, ob es nach dem Update bei mir auch Probleme gibt,
-
@daniel_2k
Anpingen lassen sie sich tatsächlich nicht. Allerdings funktioniert die Steuerung über die App. -
Vermutlich haben die jetzt mit neuer Firmware eine andere IP zugewiesen bekommen. Schau im Router unter welcher Hausnummer die jetzt erreichbar sind.
-
@ofbeqnpolkkl6mby5e13
Mal power reset gemacht? Also wenn du sie nicht anpingen kannst, ist kein Wunder.
Haben die evlt. ne anderer IP nach dem Update bekommen?
Die App verbindet sich ja nicht via manuell eingegebener IP, sondern die detected die Geräte ja via SSDP. -
@thomas-braun
So ist es. Ich habe allerdings schon dutzende Firmware-Updates bei den Canvas gemacht und noch nie ist das die Folge gewesen. -
@ofbeqnpolkkl6mby5e13
Also mein Update ist jetzt durch (hat ewig gedauert).
Bei mir haben die tatächlich eine neue IP bekommen, stehen in der FritzBox jetzt als OpenWRT.
Interessant.
Also schau mal im Router und hinterlege die neue IP, besser noch vergebe ein DNS und trage den Namen ein, dann hast du solche Probleme nicht.
Du kannst auch via Geräte erkennen im Adapter das Gerät suchen. -
@ofbeqnpolkkl6mby5e13 sagte in Test Adapter nanoleaf-lightpanels v1.2.x GitHub/latest:
Ich habe allerdings schon dutzende Firmware-Updates bei den Canvas gemacht und noch nie ist das die Folge gewesen.
Dann hat sich jetzt mal die MAC-Adresse geändert. Oder woraufhin dein Router IPs basiert vergibt.
Kommt schon mal vor. -
@daniel_2k
Das hatte ich auch beobachtet, dass die jetzt unter OpenWRT gemeldet werden. Da scheint es einen größeren Umbau bei der Firmware gegeben zu haben. -
@daniel_2k sagte in Test Adapter nanoleaf-lightpanels v1.2.x GitHub/latest:
Du kannst auch via Geräte erkennen im Adapter das Gerät suchen.
Das hat bei mir nicht funktioniert.
-
@ofbeqnpolkkl6mby5e13
Ja, bei mir findet er die jetzt nach dem Update auch net mehr und der Adapter verliert auch die Verbindung, weil kein ssdp:alive mehr ankommt.
Muss ich mal debuggen und schauen, ob die sich jetzt etwas anders melden. -
@daniel_2k
6.2.1 (2021-10-08)Added support for Nanoleaf Canvas Control Squares to becomes Cloud Gateways for Nanoleaf Essentialshttps://helpdesk.nanoleaf.me/hc/en-us/articles/360014639693-Canvas-Firmware-Release-Notes
-
@daniel_2k sagte in Test Adapter nanoleaf-lightpanels v1.2.x GitHub/latest:
Ja, bei mir findet er die jetzt nach dem Update auch net mehr und der Adapter verliert auch die Verbindung, weil kein ssdp:alive mehr ankommt.
Kann ich bestätigen.
-
@ofbeqnpolkkl6mby5e13
Also das mit dem keep alive über SSDP ist offenbar ein Bug in der Firmware.
Das Problem ist, dass die Location, die im ssdp:alive vom Gerät gesendet wird, leer ist:2021-11-13 15:05:05.719 - debug: nanoleaf-lightpanels.2 (8320) ssdp:alive NOTIFY received { "host": "239.255.255.250:1900", "nt": "nanoleaf:nl29", "nts": "ssdp:alive", "usn": "uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "location": "http://:16021", "cache-control": "max-age = 60", "nl-deviceid": "XX:XX:XX:XX:XX:XX", "nl-devicename": "Canvas 22D6" } 2021-11-13 15:05:05.720 - debug: nanoleaf-lightpanels.2 (8320) Invalid location 'http://:16021' received from device.Da fehlt die Adresse bei location.
Kann das jemand mal bei sich nachschauen, ob da auch die IP fehlt?
Einfach den Adapter auf debug stellen, dann sieht man die ssdp-Infos im Protokoll inkl. Fehlermeldung. -
@ofbeqnpolkkl6mby5e13
Beim M-SEARCH zum Suchen der Geräte ist die Location ebenfalls falsch, daher werden die auch nicht gefunden.
Ich reporte das mal bei nanoleaf.Edit:
Das Problem ist bekannt und tritt auch bei den Shapes auf. Da kann ich erstmal nix machen, da muss eine neue FW released werden.
Also bis auf weiteres im Adapter "Polling anstatt SSDP Notify Messages für Keep-Alive verwenden" aktivieren. -
@daniel_2k sagte in Test Adapter nanoleaf-lightpanels v1.2.x GitHub/latest:
Kann das jemand mal bei sich nachschauen, ob da auch die IP fehlt?
nanoleaf-lightpanels.0 2021-11-13 15:16:32.571 debug Invalid location 'http://:16021' received from device. nanoleaf-lightpanels.0 2021-11-13 15:16:32.569 debug ssdp:alive NOTIFY received: {"host":"239.255.255.250:1900","nt":"nanoleaf:nl29","nts":"ssdp:alive","usn":"uuid:***","location":"http://:16021","cache-control":"max-age = 60","nl-deviceid":"***","nl-devicename":"Canvas ***"} -
@ofbeqnpolkkl6mby5e13
OK Danke, passt. Betätigt das und passt mit dem was im nanoleaf-Forum für die Shapes gemeldet ist. -
@daniel_2k
Danke für deine Arbeit!
-
@daniel_2k
Ich glaube davon, dass du jemals das Polling aus dem Adapter entfernen kannst, kannst du dich endgültig verabschieden...
-
@daniel_2k
Hi! Könnte man diese fehlerhafte (Location-) Meldung nicht abfangen und bevor sie im Adapter weiterverarbeitet wird die IP einsetzen, die im Adapter hinterlegt ist? -
@badsnoopy667
Nein, geht leider nicht, weil ich ja wissen muss, von welchem Gerät das ssdp:alive kommt, falls man mehrere hat. Und die UUID habe ich zu der Zeit noch nicht. Die wird erst beim ersten Paket gemerkt und alle künftigen Pakete werden dann nur gegen die UUID geprüft.
Ich bekomme ja die reinen Nutzdaten der SSDP-Pakete von der Library. Den Absender sehe ich da nur in der Location. Zumindest war mir so, müsste ich noch mal reinschauen, ob da neben der Location noch ein IP-Feld im Objekt ist. Aber wenn nicht, keine Chance.
