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

[oFbEQnpoLKKl6mbY5e13]

nanoleaf-lightpanels.0	2020-07-05 21:02:37.432	debug	(4042) SSE subscription started, listening...
nanoleaf-lightpanels.0	2020-07-05 21:02:37.320	debug	(4042) nanoleaf Device "Canvas" (NL29) detected!

Funktionuckelt! :+1:

[daniel_2k]

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter nanoleaf-lightpanels v1.0.x GitHub/latest:

Funktionuckelt!

Supi! :-)

[oFbEQnpoLKKl6mbY5e13]

nanoleaf-lightpanels.1	2020-07-05 21:16:38.553	warn	(4088) Connection to '192.168.0.106:16021' lost, Error: No ssdp:alive detected. Try to reconnect...
nanoleaf-lightpanels.0	2020-07-05 21:16:29.108	warn	(4073) Connection to '192.168.0.105:16021' lost, Error: No ssdp:alive detected. Try to reconnect...

:thinking_face:

[daniel_2k]

@oFbEQnpoLKKl6mbY5e13
Ja, sowas habe ich befürchtet, dass das vorkommt. Der nanoleaf-Controller sendet alle 60 Sekunden einen SSDP Broadcast, dass er noch lebt. Und das wertet der Adapter aus. Das kommt bei dir nicht an. Hatte ich bei meinen Tests in einer VM auch, da war die Firewall nicht offen. Du solltest sicherstellen, dass der Node.js-Prozess eingehende Verbindungen zulässt, damit diese Broadcasts nichts blockiert werden.
Wenn du den Adapter noch im Debug hast, solltest du alle 60 Sekunden sowas im Log sehen:

ssdp:alive NOTIFY received: {"host":"239.255.255.250:1900","location":"http://192.168.0.32:16021","usn":"uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","nts":"ssdp:alive","nt":"nanoleaf_aurora:light"}

Schau mal, ob du sowas siehst. Vlt. senden die Canvas einen anderen Notification Type, so dass der Broadcast schlicht nicht erkannt wird. Also gerade das hintere "nt":"nanoleaf_aurora:light" ist interessant. Dann müsste ich das für die Canvas noch anpassen.

[daniel_2k]

@daniel_2k sagte in Test Adapter nanoleaf-lightpanels v1.0.x GitHub/latest:

Schau mal, ob du sowas siehst. Vlt. senden die Canvas einen anderen Notification Type, so dass der Broadcast schlicht nicht erkannt wird. Also gerade das hintere "nt":"nanoleaf_aurora:light" ist interessant. Dann müsste ich das für die Canvas noch anpassen.

Habe gerade noch mal in die nanoleaf API Spez. geschaut. Du wirst im Log nix davon sehen, da nur der NT "nanoleaf_aurora:light" abgehört wird und die Canvas nutzen offebar "nanoleaf:nl29".
Das müsste ich doch anpassen. OK, mach ich morgen.

Könntest du mal die Geräte-Suche ausprobieren? Da werden auch verschiedene Service Types genutzt, wobei ich den für die Canvas drin habe, d.h. die sollten gefunden werden.

[oFbEQnpoLKKl6mbY5e13]

@daniel_2k sagte in Test Adapter nanoleaf-lightpanels v1.0.x GitHub/latest:

Du wirst im Log nix davon sehen

Richtig:

nanoleaf-lightpanels.0	2020-07-05 21:35:01.762	info	(4103) Reconnected to "192.168.0.105:16021
nanoleaf-lightpanels.0	2020-07-05 21:35:01.761	debug	(4103) Connect timer stopped!
nanoleaf-lightpanels.0	2020-07-05 21:34:01.753	debug	(4103) Connect timer started with 60000 ms
nanoleaf-lightpanels.0	2020-07-05 21:34:01.751	debug	(4103) SSE connection closed!
nanoleaf-lightpanels.0	2020-07-05 21:34:01.750	debug	(4103) Command queue cleared!
nanoleaf-lightpanels.0	2020-07-05 21:34:01.749	debug	(4103) Polling timer stopped!
nanoleaf-lightpanels.0	2020-07-05 21:34:01.748	warn	(4103) Connection to '192.168.0.105:16021' lost, Error: No ssdp:alive detected. Try to reconnect...
nanoleaf-lightpanels.0	2020-07-05 21:32:46.762	debug	(4103) SSE subscription started, listening...
nanoleaf-lightpanels.0	2020-07-05 21:32:46.648	debug	(4103) nanoleaf Device "Canvas" (NL29) detected!
nanoleaf-lightpanels.0	2020-07-05 21:32:46.646	info	(4103) Connected to "192.168.0.105:16021
nanoleaf-lightpanels.0	2020-07-05 21:32:46.645	debug	(4103) Connect timer stopped!
nanoleaf-lightpanels.0	2020-07-05 21:32:46.612	info	(4103) Connecting to "192.168.0.105:16021"...
nanoleaf-lightpanels.0	2020-07-05 21:32:46.611	debug	(4103) SSDP events initialized!
nanoleaf-lightpanels.0	2020-07-05 21:32:46.609	info	(4103) Nanoleaf adapter "nanoleaf-lightpanels.0" started.
nanoleaf-lightpanels.0	2020-07-05 21:32:46.581	info	(4103) starting. Version 1.0.1 in /opt/iobroker/node_modules/iobroker.nanoleaf-lightpanels, node: v12.16.3, js-controller: 3.1.6

@daniel_2k sagte in Test Adapter nanoleaf-lightpanels v1.0.x GitHub/latest:

Könntest du mal die Geräte-Suche ausprobieren?

Es wurden keine Geräte gefunden! Versuche die manuelle Eingabe der IP-Adresse oder Hostname.

[daniel_2k]

@oFbEQnpoLKKl6mbY5e13

So. Ich habe jetzt mal eine Entwickler-Version bereitgestellt, die diverse Anpassungen hat. Wenn du die mal testen könntest, wäre das gut.
Bitte aus dem GitBranch hier installieren: https://github.com/daniel-2k/ioBroker.nanoleaf-lightpanels/tarball/dev_1.0.1
Ich habe jetzt das fehlende Handling der SSDP notify Nachrichten für die Canvas ergänzt, so dass die warnings mit den connection losses weg sein sollte.
Des Weiteren habe ich die Geräte-Suche angepasst. Ich vermute, dass die Canvas auf den ST der Lightpanels schlicht nicht reagiert haben. Leider steht dazu nix in der Doku, ob da auch unterschieden wird.
Deshalb bitte mal die Geräte-Suche testen und schauen, ob die SSDP notify Messages jetzt verarbeitet werden und die Warning weg ist.
Daneben habe ich in der Version mal das Logging etwas aufgeweicht. Im Debug werden jetzt alle SSDP-Nachrichten ausgegeben, die der Adapter empfängt (ohne Filter auf Notification Type). Da könnte jetzt durchaus einiges geloggt werden. So wäre interessant (falls es immer noch nicht funktioniert), ob im Log überhaupt SSDP Nachrichten zu sehen sind, und wenn ja, was da für ein ST bzw. NT für die Geräte drin steht.

[oFbEQnpoLKKl6mbY5e13]

Sieht gut aus:

2020-07-06 16:01:38.441 - info: nanoleaf-lightpanels.0 (4374) starting. Version 1.0.1 in /opt/iobroker/node_modules/iobroker.nanoleaf-lightpanels, node: v12.16.3, js-controller: 3.1.6
2020-07-06 16:01:38.471 - info: nanoleaf-lightpanels.0 (4374) Nanoleaf adapter "nanoleaf-lightpanels.0" started.
2020-07-06 16:01:38.474 - debug: nanoleaf-lightpanels.0 (4374) SSDP events initialized!
2020-07-06 16:01:38.475 - info: nanoleaf-lightpanels.0 (4374) Connecting to "192.168.0.105:16021"...
2020-07-06 16:01:38.514 - debug: nanoleaf-lightpanels.0 (4374) Connect timer stopped!
2020-07-06 16:01:38.515 - info: nanoleaf-lightpanels.0 (4374) Connected to "192.168.0.105:16021
2020-07-06 16:01:38.516 - warn: nanoleaf-lightpanels.0 (4374) nanoleaf device "NL29" unknown! Using Canvas device as fallback. Please report this to the developer!
2020-07-06 16:01:38.518 - debug: nanoleaf-lightpanels.0 (4374) nanoleaf Device "Canvas" (NL29) detected!
2020-07-06 16:01:38.636 - debug: nanoleaf-lightpanels.0 (4374) SSE subscription started, listening...
2020-07-06 16:02:27.231 - debug: nanoleaf-lightpanels.0 (4374) TEST: ssdp:alive NOTIFY received: {"host":"239.255.255.250:1900","location":"http://192.168.0.105:16021","usn":"uuid:XXX","nts":"ssdp:alive","nt":"nanoleaf:nl29"}
2020-07-06 16:02:27.231 - debug: nanoleaf-lightpanels.0 (4374) ssdp:alive NOTIFY received: {"host":"239.255.255.250:1900","location":"http://192.168.0.105:16021","usn":"uuid:XXX","nts":"ssdp:alive","nt":"nanoleaf:nl29"}
2020-07-06 16:02:27.232 - debug: nanoleaf-lightpanels.0 (4374) nanoleaf uuid:XXX from device '192.168.0.105' set!

Suche auch:

2020-07-06 16:04:14.689 - debug: nanoleaf-lightpanels.0 (4374) Incoming adapter message: searchDevice
2020-07-06 16:04:14.802 - debug: nanoleaf-lightpanels.0 (4374) TEST: SSDP M-Search found device with USN: uuid:XXX and location: http://192.168.0.105:16021
2020-07-06 16:04:14.802 - debug: nanoleaf-lightpanels.0 (4374) SSDP M-Search found device with USN: uuid:XXX and OpenAPI location: http://192.168.0.105:16021
2020-07-06 16:04:14.803 - debug: nanoleaf-lightpanels.0 (4374) TEST: SSDP M-Search found device with USN: uuid:XXX and location: http://192.168.0.106:16021
2020-07-06 16:04:14.805 - debug: nanoleaf-lightpanels.0 (4374) SSDP M-Search found device with USN: uuid:XXX and OpenAPI location: http://192.168.0.106:16021
2020-07-06 16:04:19.692 - debug: nanoleaf-lightpanels.0 (4374) MSEARCH: 2 devices found!

2 Gerät(e) wurde(n) gefunden und konnen in der Liste oben ausgewählt werden

Welche Liste? :thinking_face:

[daniel_2k]

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter nanoleaf-lightpanels v1.0.x GitHub/latest:

Welche Liste?

Wenn die Suche abgeschlossen ist, ist ja das Feld für Host/IP ja leer. Wenn du mit der Maus über das Feld fährst, sollte rechts ein Klapppfeil zu sehen sein. Dann kannst du die Liste ausklappen und da sollten dann alle gefundenen Geräte (IP) drin stehen.

[oFbEQnpoLKKl6mbY5e13]

Da erscheint kein Pfeil.

Aber wenn ich Doppelklicke, erhalte ich die zwei IP-Adressen.

[daniel_2k]

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter nanoleaf-lightpanels v1.0.x GitHub/latest:

Da erscheint kein Pfeil.

Naja, dass Verhalten dieser Datalist hängt auch etwas vom verwendeten Browser ab. Standardmäßig, wenn man die Adapter-Einstellungen öffnet, ist das ja nur ein stinknormales Inputfeld. Nachdem man die Suche angestoßen hat und was gefunden wurde, ist das eine Datalist. In Chrome sehe ich dann, wenn ich mit der Maus drüberhalte, einen Pfeil. Oder man klickt einfach in das Feld, dann geht die Liste auf.
Bei Firefox, Edge etc. könnte sein, das da kein Pfeil zu sehen ist. Aber die Liste sollte durch reinklicken auf jeden Fall aufgehen. Habs mit Edge, IE, Firefox und Chrome getestet.

[daniel_2k]

Habe jetzt die Fixes in Version 1.0.2 gegossen und auf den GitHub Master sowie ins npm published.
Sollte ab morgen im latest verfügbar sein. Bitte noch mal prüfen, jetzt sollte alles sauber laufen.

[oFbEQnpoLKKl6mbY5e13]

Okayyyyy.

(Mindestens 8 Zeichen... :unamused: )

[oFbEQnpoLKKl6mbY5e13]

2020-07-07 08:23:58.795 - info: nanoleaf-lightpanels.0 (4987) starting. Version 1.0.2 in /opt/iobroker/node_modules/iobroker.nanoleaf-lightpanels, node: v12.16.3, js-controller: 3.1.6
2020-07-07 08:23:58.821 - info: nanoleaf-lightpanels.0 (4987) Nanoleaf adapter "nanoleaf-lightpanels.0" started.
2020-07-07 08:23:58.824 - debug: nanoleaf-lightpanels.0 (4987) SSDP events initialized!
2020-07-07 08:23:58.826 - info: nanoleaf-lightpanels.0 (4987) Connecting to "192.168.0.105:16021"...
2020-07-07 08:23:58.870 - debug: nanoleaf-lightpanels.0 (4987) Connect timer stopped!
2020-07-07 08:23:58.871 - info: nanoleaf-lightpanels.0 (4987) Connected to "192.168.0.105:16021"
2020-07-07 08:23:58.873 - debug: nanoleaf-lightpanels.0 (4987) nanoleaf Device "Canvas" (NL29) detected!
2020-07-07 08:23:59.445 - debug: nanoleaf-lightpanels.0 (4987) SSE subscription started, listening...
2020-07-07 08:24:41.897 - debug: nanoleaf-lightpanels.0 (4987) ssdp:alive NOTIFY received: {"host":"239.255.255.250:1900","location":"http://192.168.0.105:16021","usn":"uuid:XXX","nts":"ssdp:alive","nt":"nanoleaf:nl29"}
2020-07-07 08:24:41.899 - debug: nanoleaf-lightpanels.0 (4987) nanoleaf uuid:XXX from device '192.168.0.105' set!

:+1:

[sentinel]

Hallo Daniel.
Habe heute Morgen das 1.0.2 update eingespielt und es lief alles gut. Jetzt musste ich gerade den server rebooten und der Adapter reconnected sich danach wieder alle zwei Minuten wie vorher :upside_down_face:
Das Panel habe ich heute losgeschickt :wink:

[daniel_2k]

@sentinel
Naja, wenn es erst funktioniert hat und dann nicht mehr, dann kann es eigentlich nur ein Firewall/Netzwerkproblem sein. Sprich, es kommen gar keine SSDP Multicasts in dem Adapter respektive ioBroker Host an. Du wolltest ja ohnehin einiges abdrehen. Vielleicht zu viel abgedreht :-) ?
Jedenfalls im Debug siehst du ja die ssdp:alive Nachrichten. In deinem Log ist davon ja nix zu sehen, also kommt nix an.

[stefande]

@daniel_2k

Ich hab hier ein paar Canvas die auch Probleme machen.
Der ioBroker läuft unter Debian Buster in einer VirtualBox.
Die Suche funktioniert aber das SSE nicht.

2020-07-07 18:21:20.253 - info: host.iobroker-deb "system.adapter.nanoleaf-lightpanels.0" enabled
2020-07-07 18:21:20.276 - info: host.iobroker-deb instance system.adapter.nanoleaf-lightpanels.0 started with pid 20074
2020-07-07 18:21:20.822 - debug: nanoleaf-lightpanels.0 (20074) Redis Objects: Use Redis connection: 127.0.0.1:9001
2020-07-07 18:21:20.857 - debug: nanoleaf-lightpanels.0 (20074) Objects client ready ... initialize now
2020-07-07 18:21:20.860 - debug: nanoleaf-lightpanels.0 (20074) Objects create System PubSub Client
2020-07-07 18:21:20.861 - debug: nanoleaf-lightpanels.0 (20074) Objects create User PubSub Client
2020-07-07 18:21:20.869 - debug: nanoleaf-lightpanels.0 (20074) Objects client initialize lua scripts
2020-07-07 18:21:20.882 - debug: nanoleaf-lightpanels.0 (20074) Objects connected to redis: 127.0.0.1:9001
2020-07-07 18:21:20.887 - debug: nanoleaf-lightpanels.0 (20074) objectDB connected
2020-07-07 18:21:20.889 - debug: nanoleaf-lightpanels.0 (20074) Redis States: Use Redis connection: 127.0.0.1:9000
2020-07-07 18:21:20.895 - debug: nanoleaf-lightpanels.0 (20074) States create User PubSub Client
2020-07-07 18:21:20.897 - debug: nanoleaf-lightpanels.0 (20074) States create System PubSub Client
2020-07-07 18:21:20.906 - debug: nanoleaf-lightpanels.0 (20074) States connected to redis: 127.0.0.1:9000
2020-07-07 18:21:20.907 - debug: nanoleaf-lightpanels.0 (20074) statesDB connected
2020-07-07 18:21:21.587 - info: nanoleaf-lightpanels.0 (20074) starting. Version 1.0.2 in /opt/iobroker/node_modules/iobroker.nanoleaf-lightpanels, node: v12.18.2, js-controller: 3.1.6
2020-07-07 18:21:21.617 - info: javascript.0 (1759) script.js.Adapter_Überwachung: Adapter_Überwachung OK
2020-07-07 18:21:21.601 - info: nanoleaf-lightpanels.0 (20074) Nanoleaf adapter "nanoleaf-lightpanels.0" started.
2020-07-07 18:21:21.603 - debug: nanoleaf-lightpanels.0 (20074) SSDP events initialized!
2020-07-07 18:21:21.604 - info: nanoleaf-lightpanels.0 (20074) Connecting to "192.168.0.151:16021"...
2020-07-07 18:21:21.658 - debug: nanoleaf-lightpanels.0 (20074) Connect timer stopped!
2020-07-07 18:21:21.659 - info: nanoleaf-lightpanels.0 (20074) Connected to "192.168.0.151:16021"
2020-07-07 18:21:21.668 - debug: nanoleaf-lightpanels.0 (20074) nanoleaf Device "Canvas" (NL29) detected!
2020-07-07 18:21:21.777 - debug: nanoleaf-lightpanels.0 (20074) SSE subscription started, listening...
2020-07-07 18:21:21.785 - debug: nanoleaf-lightpanels.0 (20074) Update from OpenAPI: value for state "Canvas.state" changed >>>> set new value: false
2020-07-07 18:21:21.797 - debug: nanoleaf-lightpanels.0 (20074) State change status: id: nanoleaf-lightpanels.0.Canvas.state: {"val":false,"ack":true,"ts":1594138881790,"q":0,"from":"system.adapter.nanoleaf-lightpanels.0","user":"system.user.admin","lc":1594138811247}
2020-07-07 18:21:24.247 - debug: nanoleaf-lightpanels.0 (20074) system.adapter.admin.0: logging true
2020-07-07 18:22:05.531 - info: host.iobroker-deb instance system.adapter.weatherunderground.0 terminated with code 0 (NO_ERROR)
2020-07-07 18:22:36.769 - warn: nanoleaf-lightpanels.0 (20074) Connection to '192.168.0.151:16021' lost, Error: No ssdp:alive detected. Try to reconnect...
2020-07-07 18:22:36.770 - debug: nanoleaf-lightpanels.0 (20074) Polling timer stopped!
2020-07-07 18:22:36.770 - debug: nanoleaf-lightpanels.0 (20074) Command queue cleared!
2020-07-07 18:22:36.771 - debug: nanoleaf-lightpanels.0 (20074) SSE connection closed!
2020-07-07 18:22:36.772 - debug: nanoleaf-lightpanels.0 (20074) Connect timer started with 60000 ms

[daniel_2k]

@stefande
Das SSE läuft schon, das hat mit dem "Keep alive" auch erstmal nix zu tun. Das ist ja nur eine ausgehende HTTP-Verbindung zu den nanoleafs.
Die Suche nutzt auch SSDP Nachrichten. Allerdings antworten die nanoleaf-Geräte auf einen MSEARCH-Request ja direkt dem Absender. Bei den SSDP:alive Notifications, die genutzt werden, um zu erkennen, ob das Gerät noch lebt, sind das allerdings Multicasts die von den nanoleafs gesendet werden. Die scheinen deinen ioBroker/Adapter nicht zu erreichen. Im Log sind die jedenfalls nicht zu sehen. Da ich die Auswertung der Nachrichten (bezüglich Notification Type in der 1.0.2 gefixt habe, dürfte das nicht die Ursache sein).
Kannst du prüfen, ob dein Debian dort firewalltechnisch diese blockiert?

[sentinel]

@daniel_2k
Hab den Fehler bei mir gefunden. IGMP war nicht eingerichtet. Jetzt funzen die alive Signale wieder. Hatte meinen UniFi APs auch ein Update verpasst. Zu viele Updates zugleich sind nicht gut für eine anschließend notwendige Fehlersuche :)

[stefande]

@daniel_2k
Ich bin jetzt nicht wirklich der Debian Spezialist, aber so wie ich das sehe sollte die Firewall nix machen.

iobroker-deb:~# iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination