Moin,
ich betreibe 4 TRV´s jetzt in der 2ten Heizsaison. Shelly Adapter aktuell 6.6.1, TRV´s via MQTT in Shelly Instanz angebunden, FW der TRV 2.1.8
Funktioniert in der Konstellation aus meiner Sicht gut. Selten habe ich "Aufhänger" einzelner TRV´s, nie gleichzeitig bei mehreren. Ein reboot des betroffenen TRV beseitigt dieses Problem...
Ich habe es bisher noch mit keiner Adapterversion >6.0 geschafft, einen TRV via COAP anzubinden. Ursache habe ich nicht ermitteln können. Da via MQTT die Funktionalität des TRV aber zuverlässig da ist, kann ich damit gut leben.
Zu Beginn dieser Heizsaison im Oktober habe ich ein FW Update auf die angebotene Version 2.2.1 durchgeführt. War ein Desaster, nix ging mehr. Also zurück zu 2.1.8 und da bleibe ich baw. Zur aktuellen 2.2.2 kann ich also nichts sagen.
Insofern also nur der Tipp mit der bei mir laufenden Konstellation....
Beste grüße

@SKB
Moin, vielen dank für Deine Arbeit und diesen Adapter. Läuft bei mir stabil unter Rpi4 bullseye lite 32 und 64bit version, jeweils mit den aktuellsten updates, stand 09_15. Der "konfigurierbare" Verbraucher (2tes Auto...) ist ja schon auf deiner Liste, das brauche ich nicht anzumerken.
Mein kleines Balkonkraftwerk habe ich einfach durch eine Addition an die größere Anlage eingebunden, insofern ist die 2te Erzeugungsanlage für den Überblick erstmal realisiert. Könnte ich mir natürlich auch im Rahmen einer "konfigurierbaren" Erzeugung vorstellen. Ansonsten nochmal: großes Lob...

@noidea Moin, ich habe einige shelly´s sowohl per MQTT als auch COAP laufen. Gerade als Neuling ist vielleicht etwas System hilfreich. Vorschläge: Zu Anfang die shelly´s ins Heimnetz bringen und auf feste IP umstellen. Dann den iob Adapter installieren, 1. Instanz auf MQTT konfigurieren, 2. Instanz auf COAP. (Ja, das geht auch anders, hat mir aber geholfen, Ordnung zu halten). Bei MQTT username, PW und port beachten, den MQTT-Adapter benötigst du nicht, beim Port keine Doppelbelegungen verursachen. Bei den Gen1 Geräten schließen sich MQTT und Cloud gegenseitig aus, d.h. wenn Du Cloud haben möchtest, mußt du auf COAP-unicast wechseln. Ansonsten wie schon angemerkt, Doku des Adapters lesen. Die shellys sollten dann erkannt werden. Danach die Firmware checken und ggfs. aktualisieren. Device rebooten hilft auch bei störrischen Geräten meist weiter, wenn die Konfiguration stimmt.
Beste Grüße und nicht abschrecken lassen...

@da_woody Ich fahre ein Test- und ein Prod-System. Die Aufstellung mit den 2 Instanzen hilt mir beim Ordnung-halten. Frohes Schaffen...

@xadox Moin, ich betreibe einen SHMOS01 als Bewegungsmelder im Akkubetrieb, der einen shelly 1 ansteuert. Das funktioniert.
FW des SHMOS ist V20220811-152232/v2.1.8@5afc928c
IOB shelly Adapter aktuell V6.2.4, vorher V6.0.0
In meiner MQTT-Instanz sehe ich das device mit Datenpunkten, im Folder sensor sind ua. die boolean-Werte "motion" und "vibration", die ich ansprechen kann. Funktioniert unter 6.2.4 und 6.0.0
In der COAP-Instanz wird das device nicht bei mir erkannt, weder unter V6.0.0 noch unter V6.2.4. Grund ist mir nicht bekannt. Nach Doku sollte das wohl funktionieren, habe ich aber nicht hingekriegt.
Das ist bei mir die gleiche Situation wie bei den TRV´s: MQTT ist ok, COAP geht nix. Ich kann damit leben, die Funktionalität habe ich ja vollständig.
Beste Grüße

Korrekt, so mache ich das auch...

Korrekt, so mache ich das auch...

Moin,
ich betreibe 4 TRV´s jetzt in der 2ten Heizsaison. Shelly Adapter aktuell 6.6.1, TRV´s via MQTT in Shelly Instanz angebunden, FW der TRV 2.1.8
Funktioniert in der Konstellation aus meiner Sicht gut. Selten habe ich "Aufhänger" einzelner TRV´s, nie gleichzeitig bei mehreren. Ein reboot des betroffenen TRV beseitigt dieses Problem...
Ich habe es bisher noch mit keiner Adapterversion >6.0 geschafft, einen TRV via COAP anzubinden. Ursache habe ich nicht ermitteln können. Da via MQTT die Funktionalität des TRV aber zuverlässig da ist, kann ich damit gut leben.
Zu Beginn dieser Heizsaison im Oktober habe ich ein FW Update auf die angebotene Version 2.2.1 durchgeführt. War ein Desaster, nix ging mehr. Also zurück zu 2.1.8 und da bleibe ich baw. Zur aktuellen 2.2.2 kann ich also nichts sagen.
Insofern also nur der Tipp mit der bei mir laufenden Konstellation....
Beste grüße

@nicb Hallo, wenn ich helfen kann, gerne. Ich bin iobroker-Azubi im 2.Lehrjahr und habe zwei rpi4 Syteme, als Test und Produktiv. Meine Versionen findest Du im vorherigen Post. Im ersten Schritt würde ich empfehlen, den rct-Adapter komplett zu löschen, und das System zu aktualisieren (Haupt-Adapter aus stable repo!). Danach den Fixer laufen lassen. Danach den vis-Adapter aus stable installieren (kostenfreie Lizenz vorher besorgen...) und Backups nicht vergessen.
Wenn das erledigt ist, Adapter anwählen und Expertenmodus einschalten, Katze anwählen und den Link von lauff/rct eintragen. Installieren. Wenn adapter installiert ist, Instanz hinzufügen und konfigurieren mit IP-Adresse und Elements.
Das ganze natürlich ohne Gewähr. Bei mir klappt Installation und Konfiguration ohne Probleme, Datenpunkte werden angelegt und aktualisiert....und dann schaltet die Instanz irgendwann auf ROT.
Beste Grüße und viel Erfolg

@tschippie Hallo, Läuft Dein System mit den Default-Elementen denn stabil? Elemente hinzufügen habe ich hingekriegt, Objekte werde angelegt und aktualisiert. Aber die Stabilität der Instanz ist bei mir auch mit den defaults schon nicht gegeben. Beste Grüsse

@besserso Hallo an alle, meine Anlage ist in Betrieb und läuft. Den rct-Adapter habe ich installiert und er läuft prinzipiell. Die "Elemente" sind zwar etwas "kryptisch", aber mit der doku von @Besserso konnte ich mich da reinarbeiten und auch die gewünschten Ergebnisse erzielen. Das Problem: Die Instanz des Adapters ist nicht stabil. Scheint ein stochastisch auftretendes Kommunikationsproblem zu sein. Mal läuft alles 2 stunden ohne Probleme, mal schaltet der Fehler den Adapter nach 20 Minuten ab.

host.iobrokerkurs
	2023-02-10 10:58:02.961	error	instance system.adapter.rct.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
rct.0
	2023-02-10 10:58:02.279	error	Exception-Code: ECONNRESET: write ECONNRESET
rct.0
	2023-02-10 10:58:02.278	error	Error: write ECONNRESET at afterWriteDispatched (node:internal/stream_base_commons:160:15) at writeGeneric (node:internal/stream_base_commons:151:3) at Socket._writeGeneric (node:net:905:11) at Socket._write (node:net:917:8) at writeOrBuffer (node:internal/streams/writable:391:12) at _write (node:internal/streams/writable:332:10) at Socket.Writable.write (node:internal/streams/writable:336:10) at /opt/iobroker/node_modules/iobroker.rct/rct/rct.js:50:13 at Array.forEach (<anonymous>) at Timeout.requestElements [as _onTimeout] (/opt/iobroker/node_modules/iobroker.rct/rct/rct.js:48:16)
rct.0
	2023-02-10 10:58:02.276	error	uncaught exception: write ECONNRESET

Das ganze passiert sowohl bei V1.0.0 als auch bei V1.0.1. Meine Rpi4-Systeme sind ansonsten auf aktuellem Stand, also NodeJs 16.19.0, admin 6.3.5, npm 8.19.3. Weiß jemand Rat? Danke im voraus...

Moin, ich bin im stable-repo mit aktuellem System unterwegs. Der Adapter mercedesme lief bei mir bis heute in v0.59.0 ohne Probleme.
Seit heute wird im stable-repo v0.1.0 des Adapters angeboten. Ich habe aber die neue Version 0.1.0 gar nicht installiert. Meine v0.59.0 funktioniert nun nicht mehr, das System wird durch eine Vielzahl von Fehlermeldungen geflutet und lahmgelegt. Wie gesagt, obwohl ich gar kein Adapterupdate durchgeführt habe. System ist ruhiggestellt durch Stop der Instanz. Insofern ist dieses Verhalten ganz eindeutig vom Mercedesme verursacht.
Das kann im stable doch nicht Sinn der Sache sein!
Hier läuft m.E. etwas gründlich falsch! Was sagen die Admins dazu...

@xadox Moin, ich betreibe einen SHMOS01 als Bewegungsmelder im Akkubetrieb, der einen shelly 1 ansteuert. Das funktioniert.
FW des SHMOS ist V20220811-152232/v2.1.8@5afc928c
IOB shelly Adapter aktuell V6.2.4, vorher V6.0.0
In meiner MQTT-Instanz sehe ich das device mit Datenpunkten, im Folder sensor sind ua. die boolean-Werte "motion" und "vibration", die ich ansprechen kann. Funktioniert unter 6.2.4 und 6.0.0
In der COAP-Instanz wird das device nicht bei mir erkannt, weder unter V6.0.0 noch unter V6.2.4. Grund ist mir nicht bekannt. Nach Doku sollte das wohl funktionieren, habe ich aber nicht hingekriegt.
Das ist bei mir die gleiche Situation wie bei den TRV´s: MQTT ist ok, COAP geht nix. Ich kann damit leben, die Funktionalität habe ich ja vollständig.
Beste Grüße

@noidea Moin, ich habe einige shelly´s sowohl per MQTT als auch COAP laufen. Gerade als Neuling ist vielleicht etwas System hilfreich. Vorschläge: Zu Anfang die shelly´s ins Heimnetz bringen und auf feste IP umstellen. Dann den iob Adapter installieren, 1. Instanz auf MQTT konfigurieren, 2. Instanz auf COAP. (Ja, das geht auch anders, hat mir aber geholfen, Ordnung zu halten). Bei MQTT username, PW und port beachten, den MQTT-Adapter benötigst du nicht, beim Port keine Doppelbelegungen verursachen. Bei den Gen1 Geräten schließen sich MQTT und Cloud gegenseitig aus, d.h. wenn Du Cloud haben möchtest, mußt du auf COAP-unicast wechseln. Ansonsten wie schon angemerkt, Doku des Adapters lesen. Die shellys sollten dann erkannt werden. Danach die Firmware checken und ggfs. aktualisieren. Device rebooten hilft auch bei störrischen Geräten meist weiter, wenn die Konfiguration stimmt.
Beste Grüße und nicht abschrecken lassen...

@da_woody Ich fahre ein Test- und ein Prod-System. Die Aufstellung mit den 2 Instanzen hilt mir beim Ordnung-halten. Frohes Schaffen...

@da_woody ok, danke für die Info. Meine Gen1 auf MQTT können es nicht, was mich aber nicht stört. Wenn´s die Gen2 können, umso besser.