@ingob
Ich hab jetzt nochmal was neues versucht, um den Aufbau ganz trivial einfach zu halten.
Habe eine neue Linux VM installiert, sie hat nur ein Netzwerkinterface, das steckt in einer Fritzbox.
Ein Shelly, ist am Wlan der Fritzbox. Beide sind im selben Subnet 192.168,178,0/24
Die Server IP steht im Shelly unter CoIoT peer.
Der Shelly Adapter bleibt gelb.

@homoran
Bevor ich gefragt habe, habe ich natürlich erstmal die Forensuche bemüht und einen Post gefunden, da wurde vorgeschlagen eine Instanz für MQTT und eine für COAP/HTTP zu verwenden. Für den MQTT-Test hatte ich eine zweite Instanz aufgemacht, da das Ergebnis das selbe war, habe ich sie wieder entfernt, damit wir wieder bei einen simplen Standardinstallation sind.

@homoran
ja, ich habe mein IoT-Netz(192.168.117.0/24), da sind alles Shellys drin. Der ioBroker hat ein Bein in dem Netz, mit der IP 192.168.117.6. Weil da im Debug Modus SO viel Output kam, habe ich den ioBroker in das Hausnetz 192.168.116.0/24 mit der IP 192.168.116.6 und nur einem Shelly 192.168.116.125 übernommen, damit das Debug-Log besser lesbar ist.

Dir ist sicher, wie mir aufgefallen, dass der ioBroker obwohl ich das Netz gewechselt habe trotzdem versuch noch Geräte aus dem IoT Netz abzufragen. Irgendwo hat er also doch gespeichert, dass es diese Geräte gibt, auch wenn sie nicht unter Objekte auftauchen.

@homoran
Das Bild findest Du auch in meinem ersten Post, da habe ich alle Screenshots gepostet.
Entschuldige, ich bin verwirrt, soll ich Text auch in Code-Tags einbetten?

Also zukünftig so texten?

@homoran
doch, im Log steht Kommunikation
https://forum.iobroker.net/assets/uploads/files/1658748176513-shelly-debug01.jpg
ich kann die nur nicht interpretieren, dazu fehlt mir das Fachwissen.

Habe den ioBroker mit nur einem Shelly in ein Testnetz gesteckt, damit er nicht Nachrichten aller 35 Shellys reinlaufen lässt, das wird dann unübersichtlich. Hier das Log mit nur einem Shelly:

shelly.0
	2022-07-25 17:57:55.752	debug	CoAP status package received: {"3332":"SHSW-PM#34945470D521#2","3412":38400,"3420":256,"Uri-Path":"cit/s"} / {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,40.54],[0,3105,104.96],[0,6101,0]]}
shelly.0
	2022-07-25 17:57:55.360	debug	CoAP device description request for SHSW-PM#00E551#2 to 192.168.117.116(0)
shelly.0
	2022-07-25 17:57:55.360	debug	[CoAP] Status update received for SHSW-PM#00E551#2: {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,41.8],[0,3105,107.23],[0,6101,0],[0,3101,26.2],[0,3102,79.2]]}
shelly.0
	2022-07-25 17:57:55.360	debug	CoAP status package received: {"3332":"SHSW-PM#00E551#2","3412":38400,"3420":256,"Uri-Path":"cit/s"} / {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,41.8],[0,3105,107.23],[0,6101,0],[0,3101,26.2],[0,3102,79.2]]}
shelly.0
	2022-07-25 17:57:44.735	debug	CoAP device description request for SHSW-PM#34945470D521#2 to 192.168.116.125(2)
shelly.0
	2022-07-25 17:57:44.369	debug	CoAP device description request for SHSW-PM#00E551#2 to 192.168.117.116(2)
shelly.0
	2022-07-25 17:57:42.734	debug	CoAP device description request for SHSW-PM#34945470D521#2 to 192.168.116.125(1)
shelly.0
	2022-07-25 17:57:42.367	debug	CoAP device description request for SHSW-PM#00E551#2 to 192.168.117.116(1)
shelly.0
	2022-07-25 17:57:40.733	debug	CoAP device description request for SHSW-PM#34945470D521#2 to 192.168.116.125(0)
shelly.0
	2022-07-25 17:57:40.733	debug	[CoAP] Status update received for SHSW-PM#34945470D521#2: {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,40.61],[0,3105,105.1],[0,6101,0]]}
shelly.0
	2022-07-25 17:57:40.733	debug	CoAP status package received: {"3332":"SHSW-PM#34945470D521#2","3412":38400,"3420":256,"Uri-Path":"cit/s"} / {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,40.61],[0,3105,105.1],[0,6101,0]]}
shelly.0
	2022-07-25 17:57:40.365	debug	CoAP device description request for SHSW-PM#00E551#2 to 192.168.117.116(0)
shelly.0
	2022-07-25 17:57:40.365	debug	[CoAP] Status update received for SHSW-PM#00E551#2: {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,41.94],[0,3105,107.5],[0,6101,0],[0,3101,26.2],[0,3102,79.2]]}
shelly.0
	2022-07-25 17:57:40.365	debug	CoAP status package received: {"3332":"SHSW-PM#00E551#2","3412":38400,"3420":256,"Uri-Path":"cit/s"} / {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,4101,0],[0,4103,0],[0,6102,0],[0,6109,0],[0,3104,41.94],[0,3105,107.5],[0,6101,0],[0,3101,26.2],[0,3102,79.2]]}
shelly.0
	2022-07-25 17:57:26.426	silly	States user redis pmessage shelly.0.*/shelly.0.info.connection:{"val":false,"ack":true,"ts":1658764646425,"q":0,"from":"system.adapter.shelly.0","user":"system.user.admin","lc":1658764268889}
shelly.0
	2022-07-25 17:57:26.423	info	[CoAP] Listening for packets in the network
shelly.0
	2022-07-25 17:57:26.407	debug	[CoAP] Starting shelly listener with options: {"multicastInterface":"192.168.116.6"}
shelly.0
	2022-07-25 17:57:26.407	info	Starting in CoAP mode.

@da_woody
dank Dir, okay hab 0/0 also alle IPs eingestellt. Die Shellys habe ich nach der Umstellung neugestartet, habe eben noch einen frischen aus der Verpackung genommen, der hatte noch eine v10 Firmware. Er wurde per multicast nicht gefunden, nach der Aktualisierung habe ich die unicast IP des Servers eingetragen, neustart, auch Shelly Instanz neugestartet, kein Ergebnis und zum Schluss, um sicher zu gehen, den Shelly stromlos gemacht und wieder eingesteck, leider ebenfalls nichts zu sehen.

Aber ist das nicht spannend, dass ich ja wie in dem Screenshot Querys und Responses sehen kann?

@da_woody
hab mich auch gefragt, warum da einer in der Blacklist ist, hab das für ein Beispiel gehalten, das war direkt nach der Installation so, hab das nicht geändert. Einen solchen Shelly habe ich auch nicht. Spannend, wie kommst Du an eine v6? Mein System sagt, mir, ich wäre auf der aktuellsten Version, oder bin ich vielleicht mit der Standardinstallation auf einem Stable-Release Kanal und sehe die nicht?
Hm ja, ich kann bis auf die Version und die bei mir unter MQTT explizit angegebene IP keine Unterschiede sehen.
Achso und ja, die 192.168.117.6 ist der ioBroker

@ingob
exemplarisch einer der Shellys:

@da_woody
Servus, dank Dir für Deine Rückmeldung. Mist, ich dachte wirklich ich hab alles an Infos mitgeliefert.
Ja, stimmt natürlich, Instanz ist in dem Kontext Quatsch. eine Ubuntu VM, auf der die ioBroker Installation läuft. Darauf den Shelly Adapter, mit einer Instanz.

Ich habe den Switch bzw. die APs bereits auf multicast filtering geprüft, aber wie erwartet nichts gefunden, hab zwischenzeitlich auch keine Änderungen am Netzkwerk vorgenommen. Ist ja glaub eh hinfällig, wenn jetzt unicast für die Kommunikation mit den Shellys verwendet wird.

Verwendet habe ich diese Anleitung:
https://www.iobroker.net/#de/documentation/install/linux.md
Also keine manuellen bzw. Betriebssytem Versionen von node / nodejs/ nmp neues, sauberes System, sonst keine Dienste, und ioBroker per Curl aus dem Repository.

Die Instanzen sind siehe Screenshot(s), so wie unter folgendem Link beschrieben eingerichtet:
https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/protocol-coap.md

Hallo zusammen,
ich betreibe schon ein gutes Jahr, eine IO-Broker instanz, hab sie nur selten aktualisiert, lief ja alles. Seit ca. einer Woche hat die Gartenberegnung nicht mehr funktioniert und es wurden auch keine Temperaturen mehr aktualisiert. Hab das System aktualisiert, das lief dann in diverse. Fehler.

Habe daraufhin gestern einen ganz neuen Ubuntu-Server 22 LTS installiert, Iobroker per Script ganz nach Anleitung hier installiert. Der Shelly Adapter findet nicht einen Shelly. Habe einen der Shellys versuchsweise Downgegraded, auf mcast / unicast umgestellt =>nichts. Habe einen zweiten Shelly Adapter mit MQTT installiert=> nichts.

Spannend ist, wenn ich den COAP Adapter auf Debug stelle, sehe ich requests und Antworten, kann sie nicht interpretieren, aber Kommunikation ist wohl da. Ein TCP-Dump zeigt die Kommunikation auch.
Mir gehen langsam die Ideen aus, vielleicht übersehe ich was essentielles. Dank Euch für Input.

VG Ingo

Details:

Ubuntu Linux 22 LTS (gestern installiert) als VM auf Hyper-V Server.
uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs
[sudo] password for administrator:
ln: failed to create symbolic link '/usr/bin/nodejs': File exists
x86_64
/usr/bin/nodejs
/usr/bin/node
/usr/bin/npm
v16.16.0
v16.16.0
8.11.0
administrator
/opt/iobroker/log
OK:1 http://de.archive.ubuntu.com/ubuntu jammy InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu jammy-updates InRelease
OK:3 https://deb.nodesource.com/node_16.x jammy InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu jammy-backports InRelease
OK:5 http://de.archive.ubuntu.com/ubuntu jammy-security InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Alle Pakete sind aktuell.
nodejs:
  Installiert:           16.16.0-deb-1nodesource1
  Installationskandidat: 16.16.0-deb-1nodesource1
  Versionstabelle:
 *** 16.16.0-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_16.x jammy/main amd64 Packages
        100 /var/lib/dpkg/status
     12.22.9~dfsg-1ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages


administrator@destr03-lsv005:/opt/iobroker/log$ iobroker update -i
Used repository: stable
Adapter    "admin"        : 5.3.8    , installed 5.3.8
Adapter    "backitup"     : 2.4.9    , installed 2.4.9
Adapter    "discovery"    : 3.0.5    , installed 3.0.5
Adapter    "hue"          : 3.7.0    , installed 3.7.0
Adapter    "hue-extended" : 2.0.0    , installed 2.0.0
Adapter    "javascript"   : 5.7.0    , installed 5.7.0
Controller "js-controller": 4.0.23   , installed 4.0.23
Adapter    "onkyo"        : 2.1.2    , installed 2.1.2
Adapter    "ping"         : 1.5.3    , installed 1.5.3
Adapter    "shelly"       : 5.3.2    , installed 5.3.2
Adapter    "simple-api"   : 2.7.0    , installed 2.7.0
Adapter    "socketio"     : 4.2.0    , installed 4.2.0
Adapter    "tradfri"      : 3.1.3    , installed 3.1.3
Adapter    "vis"          : 1.4.15   , installed 1.4.15
Adapter    "web"          : 4.3.0    , installed 4.3.0
Adapter    "ws"           : 1.3.0    , installed 1.3.0