Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[crunchip]

@phinix laut Doku
https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/protocol-coap.md

[da_Woody]

@crunchip wäre auch eine erklärung...
wobei der port beim speichern automatisch eingetragen wird. IP genügt.

[Phinix]

@DJMarc75 es handelt sich um das ganz normale Shelly1
@da_Woody @crunchip die Shellys liefen ursprünglich direkt mit unicast, IP habe ich eingetragen, der Port wird automatisch ergänzt; dann kommen die Meldungen im Log aus meinem ersten Post.
Ich habe gerade eben noch mcast getestet, funktioniert zwar auch nicht, aber es kommen auch überhaupt keine Meldungen mehr im Log über einen Verbindungsaufbau... somit eventuell doch ein Netzwerkproblem?

[DJMarc75]

@phinix ob Du uns nicht mal die Einstellungen im Adapter und direkt am Shelly (advanced developer settings) per Screenshot zeigen magst ?

[Phinix]

@djmarc75 Klar.

[DJMarc75]

@phinix
dann halt nochmal auf mcast umstellen und das Device natürlich neu starten.

Ebenso das http-passwort im Adapter rausnehmen.

EDIT: da fällt mir grad auf dass der Adapter shelly.1 lautet.
Sind da mehrere Instanzen am laufen ??

[Phinix]

@djmarc75 Ja, ich habe zum Testen gerade eine zweite Instanz installiert. Die Shelly.0 habe ich auf MQTT umgestellt damit die anderen Shellys im Netzwerk funktionieren.
Shelly.1-Instanz läuft auf COaP.

mcast und http-Kennwort habe ich geändert, klappt aber leider noch immer nicht.

shelly.1
2022-08-15 21:04:57.506	debug	CoAP device description request for SHSW-1#E8DB84D253EC#2 to 192.168.1.200(1)

shelly.1
2022-08-15 21:04:55.505	debug	CoAP device description request for SHSW-1#E8DB84D253EC#2 to 192.168.1.200(0)

shelly.1
2022-08-15 21:04:55.505	debug	[CoAP Server] Status update received for SHSW-1#E8DB84D253EC#2: {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0]]}

shelly.1
2022-08-15 21:04:55.504	debug	CoAP status package received: {"3332":"SHSW-1#E8DB84D253EC#2","3412":38400,"3420":256,"Uri-Path":"cit/s"} / {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0]]}

shelly.1
2022-08-15 21:04:49.549	debug	[CoAP Server] Error - handling data: Error: No reply in 247 seconds.

shelly.1
2022-08-15 21:04:47.548	debug	[CoAP Server] Error - handling data: Error: No reply in 247 seconds.

shelly.1
2022-08-15 21:04:45.547	debug	[CoAP Server] Error - handling data: Error: No reply in 247 seconds.

shelly.1
2022-08-15 21:04:44.327	debug	CoAP device description request for SHSW-1#E8DB84D253EC#2 to 192.168.1.200(2)

shelly.1
2022-08-15 21:04:42.326	debug	CoAP device description request for SHSW-1#E8DB84D253EC#2 to 192.168.1.200(1)

shelly.1
2022-08-15 21:04:40.324	debug	CoAP device description request for SHSW-1#E8DB84D253EC#2 to 192.168.1.200(0)

shelly.1
2022-08-15 21:04:40.324	debug	[CoAP Server] Status update received for SHSW-1#E8DB84D253EC#2: {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0]]}

shelly.1
2022-08-15 21:04:40.323	debug	CoAP status package received: {"3332":"SHSW-1#E8DB84D253EC#2","3412":38400,"3420":256,"Uri-Path":"cit/s"} / {"G":[[0,9103,0],[0,1101,0],[0,2101,0],[0,2102,""],[0,2103,0]]}

[DJMarc75]

@phinix
Der zweite Adapter ist sicher auch nicht grün, oder ?
Geht es da eigentlich um ALLE Shellys welche keine Verbindung mehr haben oder nur um einen speziellen ?

[crunchip]

@phinix multicast wird doch gar nicht mehr unterstützt wenn ich mich nicht irre, also bleibt nur unicast oder mqtt

vllt liegt es auch an deiner Netzwerkeinstellung(Router)

[Phinix]

@djmarc75
Nein, der Adapter ist gelb "Verbunden mit Gerät oder Dienst" ist nicht da.
Es geht um alle Shellys.

[DJMarc75]

@phinix sagte in Keine Verbindung zu Shelly:

Es geht um alle Shellys.

Dann wird es u.U. an Deinem Netzwerk liegen.
Router schonmal neu gestartet?

[Phinix]

@djmarc75
das hatte ich befürchtet, nur in welche Richtung könnte ich da schauen?
Ja, die Fritzbox hab ich bereits neu gestartet...

[DJMarc75]

@phinix sagte in Keine Verbindung zu Shelly:

in welche Richtung könnte ich da schauen?

mit Ubuntu und VMs kenn ich mich zu wenig aus aber ich halte es für möglich dass Du da wohl iwo etwas geändert haben könntest - bevor das Problem mit den Shellys aufgetaucht ist ?!

[Phinix]

@djmarc75
Also geändert habe ich die letzten Wochen nichts, dafür war das Wetter zu schön :D Windows Server und Ubuntu Updates waren das einzige was ich gemacht habe...

[DJMarc75]

@phinix sagte in Keine Verbindung zu Shelly:

Windows Server und Ubuntu Updates waren das einzige was ich gemacht habe

Ja das meinte ich mit "geändert" ... ich tippe da auf Windows - da wird ja öfters mal was geändert (durch updates).
Wie gesagt bei Ubuntu bin ich da raus und, naja, Windows Server ist auch nicht ganz so meins.

Muss mal eine Denkpause machen - Kopf qualmt

[Phinix]

@djmarc75
Ich denke ich werde einfach bei MQTT bleiben, den Fehler bei einem Update zu suchen wird recht schwierig.
Danke dir für deine Hilfe!

[Max Meyer]

@phinix Ich hatte auch das Problem das Plötzlich keine Werte in den Objekten aktualisiert wurden obwohl ich nichts geändert habe. Ich hab dann alles upgedated und shelly Adapter 6 installiert. Hab auch in den shellys den Server eingetragen wie es bei Matthias in der Doku steht und npm install xml2js@0.4.19 in den beiden Verzeichnissen installiert. Hat alles nichts geholfen. Dann habe ich eine neue iobroker VM im Windows 10 Hyper-V nur mit dem shelly Adapter installiert, ging auch nicht obwohl ich eingehende udp Pakete von allen shellys sehen konnte. Dan hab ich aus Verzweiflung iobroker auf einem anderen PC installiert und schwupp alle shellys gehen. Auch wenn in den shellys multicast drin ist und nicht die IP des iobrokers. Dann hab ich in die Updates des Windows systems geguckt und dort wurden 2 Updates angezeigt die an dem Tag installiert wurden als die shellys nicht mehr funktionierten. Das deinstallieren der Updates hat aber auch nichts geholfen.
Ich habe dann proxmox auf einem alten NUC installiert und die iobroker VM die auf meinem Hyper-V lief und keine shelly Daten angenommen hat exportiert unf auf dem proxmox zum laufen gebracht. Siehe da die shelly Objekte wurden wieder aktualisiert. Wahrscheinlich hast du im iobroker alles richtig gemacht aber der Hyper-V haut uns dazwischen.
Ich wollte proxmox schon immer mal ausprobieren und das war jetzt die Gelegenheit.
LG Max

[da_Woody]

@max-meyer sagte in Keine Verbindung zu Shelly:

Auch wenn in den shellys multicast drin ist und nicht die IP des iobrokers.

genau das find ich seltsam. mcast dürfte nicht mehr funktionieren.
das ganze wird echt seltsam.

[Phinix]

@max-meyer hm sehr komisch das Hyper-V dazwischen funkt. Ich hätte jetzt eher in Richtung Fritzbox gedacht. Da die shellys aber über MQTT funktionieren, habe ich das mal so belassen.
Eine andere Serverhardware zum Testen habe ich allerdings nicht, bei mir läuft mein Windows Server mit allen VMs in Hyper-V. Da mir Proxmox anzufangen wäre enorm viel Arbeit.
... Wie hast du es denn geschafft eine Hyper-V VM zu exportieren und in Proxmox einzubinden?

[Max Meyer]

@phinix Ich hatte iobroker bestimmt schon mehr als ein Jahr ohne Probleme auf meinem Hyper-V laufen. Backup lief mit Veeam community Edition wunderbar und eigentlich wollte ich nicht umziehen aber ich brauche die cloud Anbindung bei einigen shellys deswegen hilft mir eine Umstellung auf mqtt nicht.
Mein Windows hat am Freitag Updates installiert und abends habe ich einen neuen shelly hinzugefügt und mich gewundert warum der nicht im iobroker auftaucht. Erst dann ist mir aufgefallen, dass sich die Werte der anderen shelly Objekte nicht mehr ändern. Ich habe dann die beiden Updates deinstalliert aber das hat nicht geholfen. Dann habe ich von shelly V5.3 die gut lief auf 6 upgegradet und es war einfach nicht zum laufen zu bringen. Dann mein Test mit der neuen iobroker VM im Hyper-V aber da war das gleiche Problem. Dann iobroker auf einem NUC installiert und es funktioniert.

Die Installation von proxmox ist n klacks und in 10 Minuten erledigt. Zum Umzug der VM musst Du die im Hyper-V exportieren (vorher alle Prüfpunkte konsolidieren) und die vhdx für den proxmox erreichbar machen. Man kann z.B. eine USB Platte nehmen. Ich habe die Datei per Winscp in das Verzeichnis /var/lib/vz/images/ hochgeladen.
Dann legst Du eine neue VM an mit ungefähr der gleichen Konfiguration wie im Hyper-V allerdings ohne Festplatte.
Es war gar nicht so leicht eine Anleitung zu finden da sich diese meist auf kleinere Versionsnummern von proxmox beziehen und die sehr viel geändert haben. Wenn Du was suchst, prüfe ob das auch für proxmox 7 ist.
Vor Version 7 musste man die vhdx noch konvertieren aber in Version 7 kann man die einfach importieren.
Bei der Anlage der VM wird eine Nummer vergeben (bei mir war es 100)
Dann wird die Platte einfach wie folgt importiert:
qm importdisk 999 /tmp/my-image.vhdx local-lvm
Die 999 ist die Nummer der VM dann kommt der Pfad und Name der vhdx und zuletzt der Speicherort. Bei einer Standardinstallation ist local-lvm der Datenträger auf dem die VMs liegen
you can directly import the vhdx files, no need to first convert to raw
and the <target-storage> is the storage id defined in proxmox (e.g. local or local-lvm)

Nach dem Import hast Du an deiner VM eine ungenutzte Festplatte die du noch als bootdevice anbinden musst.
Bei meinem Ubuntu musste nach dem booten noch die Netzwerkkonfig unter /etc/netplan neu gemacht werden.
Seit dem Umzug funktionieren meine shellys wie gewohnt.

Solltest Du rausfinden was beim Hyper-V dazwischen grätscht würde ich mich über eine Info freuen.