Beiträge von michsa

Ausgangssituation:

Home Assistant verlangt seit neuestem (2024.1 Update glaube ich) eine aktuelle FW der Shellys.

Aber:

Mein Shelly RGBW2 machte Probleme mit einer seltsamen Firmware 1.87 oder so ähnlich. Keine Ahnung, woher oder wie diese jemals rauf kam.

Die integrierte Updatefunktion zeigte keine(!) Updates an.

OTA Befehle funktionierten nicht, wie man sie hier im Forum im Archiv-Generator erstellen kann.

Bsp: http://192.168.178.111/ota?url=http://archive.shelly-tools.de/version/v1.14.0/SHRGBW2.zip

Andere Anleitungen wie diese hier halfen auch nicht* und sind auch nicht ganz aktuell mehr (bezogen auf die Bilder zu den Versionen).

Weitere Suche zeigte das Python Skript "esptool.py", aber das verlangt eine Python Umgebung. Irgendwie ist das alles sehr umständlich.

Lädt man also per Hand die originale Shelly Firmware (FW) herunter, steht man vor dem Problem, 5 Dateien zu haben.

Was also wie machen?

_{(* Ich wollte keine einzelne Tasmota oder esp Datei flashen. Ich wollte die originale FW flashen, die insgesamt aus 4 bin Dateien besteht.)}

Folgend versuche ich nun für den nicht IT-Profi eine einfache Anleitung zu schreiben. Die Anleitung ist somit etwas länger, dafür ausführlicher. Und wie ich finde auch recht einfach. Es gibt eine Stelle, die etwas komplexer ist, die erkläre ich weiter unten separat.

Das komplizierteste ist eigentlich die elektrische Verbindung zum Shelly. Aber diese ist bei allen Varianten identisch.

Der eigentliche Flashvorgang hat bei mir keine 4 Minuten gedauert.

Wichtig ist zu verstehen, dass ich keine Garantie oder Haftungen für irgendwelche Handlungen übernehmen kann. Jeder ist für sich selbst verantwortlich und muss im Zweifel einen Fachmann die Arbeit überlassen.
Wir hantieren hier nur mit 3,3 V. Alle Bauteile sind in heutigen Tagen sehr Fehlerresistent und -tolerant. Es kann dennoch nicht schaden, vor den Arbeiten einmal an die Heizung oder ähnliches zu fassen, um sich elektrostatisch zu entladen. Das könnte ansonsten den shelly, den USB-Adapter oder sogar Euren PC zerschießen.
Bitte stellt sicher, dass während allen Arbeiten KEINE zusätzliche Spannungsversorgung an den Shelly angelegt wird.

[START Anleitung] Direktes Flashen der 4 FW Dateien mit esptool.exe

In der Tat erscheint mir der folgende Werdegang im Moment am einfachsten, da keine kryptischen und komplizierten Befehle vorhanden sind und alles logisch abgeleitet werden kann. Es muss keine Auswahl aus vielen Downloadmöglichkeiten getroffen werden, wie z. B. bei espeasy. Es ging mir um das Flashen der originalen Shelly-Firmware, einfach mit einem Tool ohne noch was weiteres installieren zu müssen.

Voraussetzungen /Vorarbeiten

1. Download Shelly Original Firmware (FW):

Mit dem Archivgeneratorerhält man auch den Link zur gewünschten FW, hinten dran steht das File zum Herunterladen:

Der hintere Teil ist die Adresse zur Firmware: http://archive.shelly-tools.de/version/v1.14.0/SHRGBW2.zip

Ich nehme in diesem Fall immer die letzte normale Shelly FW-Version. Hier also die 1.14.0.

Diese Adresse einfach im Browser eingeben und die Datei wird herunter geladen.

Per Doppelklick öffne ich die ZIP-Datei. Die enthaltenen 5 Dateien kopiert man z. B. in einen neuen leeren Ordner auf dem Desktop.

2. Download esptool.exe

Um zu vermeiden eine Pythonumgebung sich installieren zu müssen, was wieder für viele in etlichen Fragen endet (welche Version, was , wie, wo,...) gibt es glücklicherweise eine offizielle Stelle zum Download der esptools EXE für Windows:
https://github.com/espressif/esptool/releases

Hier langsam runterscrollen und die oberste Version sich ansehen, in diesem Bsp. ist es die 4.7.0:

Hier nehmen wir die WIN64 version und laden diese herunter. Natürlich wird irgendwann die Versionsnummer eine höhere sein - dann diese einfach nutzen.

ZIP-File doppelklicken. Wir kopieren NUR die esptool.exe in den gleichen Ordner, in dem wir die Firmware abgelegt haben:

In meinem Beispiel war es der Ordner ESP auf dem Desktop:

Jetzt haben wir alle Dateien. Weiter geht es mit zusätzlichen Vorbereitungen.


3. Einen USB2TTL Konverter
Ohne kann es nicht funktionieren. Dieser ist preiswert und kann immer mal in diesem Hobby benötigt werden.
Z. B den hier: DSD TECH USB zu TTL Seriell Adapter Konverter mit FTDI FT232 (kein Affiliate-Link)
Es gibt auch welche für 6 oder 8 €, der genannte ist aber schön stabil und funktioniert auf jeden Fall.

3.1 Für ein einfacheres Arbeiten empfehle ich ein gutes USB3 Verlängerungskabel:
Z. B.: 2 Stück 2M USB Verlängerung Kabel AINOPE USB 3.0 Verlängerungskabel A Stecker auf A Buchse (kein Affiliate-Link)

4. Krokodilklemmen, wenn man den folgend beschriebenen Weg gehen möchte

Ich sagte ja, dass das Anschließen das komplizierteste ist...

10 Stück Krokodilklemmen mit Kabel (kein Affiliate-Link)

5. Etwas schmalen Draht ( ~0.8 mm )

Den habe ich nicht aufgeführt. Irgendwas kleines, was in die kleine Steckbuchse im Shelly passt. Blumendraht, ein Stück von einem Widerstand,...

-- Vorbereitungsende --

Wie geschrieben - das muss bei allen Varianten erfolgen. Wie man nun den Shelly an den PC bekommt, kann jeder selber entscheiden. Meine Skizzierung ist nur ein Vorschlag.

Anschluss des USB zu TTL Adapters:

1. Zu aller erst achten wir darauf, den kleinen Adapter auf 3,3 V einzustellen! Das ist sehr wichtig! Keine weiteren Spannungen an den Shelly anlegen. Achtet darauf KEINE 5 Volt zu verwenden!
Die Spannungsversorgung kommt via PC über den kleinen USB-Adapter auf euren Shelly.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

2. Der Adapter benötigt auch einen Jumper von RTS zu CTS. Diese kleinen Jumper liegen dem Adapter dabei (war bei mir zumindest so).

3. Nun verbinden wir den Shelly mit dem Adapter:

Shelly USB-Adapter

GPIO0 <-> Gnd/Masse/Minus

GND <-> Gnd/Masse/Minus

RXD <-> TXD (!)

TXD <-> RXD (!)

3.3V <-> VCC

Zur Erinnerung: Durch den Jumper auf 3.3V wird bei VCC nur 3.3 V ausgegeben. Nochmal: das ist wichtig!!!

Der Anschluss der Kabel ist kniffelig, da die kleine Steckerbuchse sehr winzig ist. Normale Jumper-Stecker passen da nicht rein, wie sie es überall zu kaufen gibt.

Ich habe mich für eine Draht und Krokodilklemmen-Verbindung entschieden. Nicht schön, aber einfach und schnell.
Hinweis: Man kann die Krokodilüberzieher recht weit nach oben schieben und somit einen Kurzschluss zum Nachbarpin vermeiden.

Die Krokoklemmen sind am Jumperkabel angeschlossen, dazu die Kunststoffkappe abziehen (die kleine Kunststoffnase mit einem kleinen Schraubendreher hochbiegen und dann abziehen - kann danach wieder aufgesteckt werden).

GPIO0 und GND sind an der schwarzen Klemme gemeinsam verbunden.

Flashvorgang und Befehle

Ihr habt die 6 Dateien nach der Vorbereitung in einem Ordner, z. B. auf dem Desktop unter ESP.

1. Öffnet eine CMD (Eingabeaufforderung)

WIN+R drücken, dann cmd eingeben und Enter

2. Wechselt in den Ordner (Befehl cd ), indem ihr alles abgelegt habt.

Wenn euer Loginname z. B. "Tom" ist, dann ist der Pfadwechsel wie im folgenden Bsp. durchzuführen:

cd c:\users\tom\desktop\esp

(hier mit der Annahme, das der Ordner auf dem Desktop mit dem Namen esp liegt)

Da wir nun im Ordner sind, können wir die Firmwaredateien und das esptool.exe direkt ohne Pfadangaben aufrufen.

3. Wir müssen den COM-port des USB zu TTL Adapter herausfinden.

Dazu gehen wir in den Gerätemanager:

WIN+R und dann devmgmt.msc und Enter

Es öffnet sich ein Fenster, wir gehen zu den Anschlüssen ganz oben links.
Um ganz sicher zu sein, welchen Port der Adapter hat, ziehen wir den USB Adapter zuerst einmal am besten ab, falls er bereits am PC eingesteckt ist, und klappen den "Anschlüsse (COM & LPT)" Bereich auf.

In meinem Fall ist ein anderes USB-Gerät bereits eingesteckt - das ist NICHT der USB zu TTL Adapter!

Nun den Adapter einstecken - spätestens jetzt versteht man, warum ein USB-Verlängerungskabel sehr hilfreich ist

Der Adapter wird jetzt angezeigt:

In meinem Fall ist es COM8. Bei euch ist es vermutlich eine andere Zahl. Dieses merken!

Nun sind 4 Dateien auf den Shelly RGBW2 zu flashen.

WICHTIG: Die nächsten Befehle passen wahrscheinlich nur auf den RGBW2 mit der FW Version 1.14.0!!

Im Speziellen geht es um die Zahlen, wie z.B "0x0000 oder 0x8000", die unterschiedlich sein können.

Ich erkläre im Anschluss, wie ich zu diesen Zahlen gekommen bin, um nicht diese Schritte zu sehr auseinander zu reißen.

Flashbefehle

Datei 1 "rboot.bin"

esptool.exe --port COM8 write_flash 0x0000 rboot.bin

(bitte passt euren COM Port an)

Ausgabe:

esptool.py v4.7.0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Flash params set to 0xff30
Compressed 2320 bytes to 1693...
Wrote 2320 bytes (1693 compressed) at 0x00000000 in 0.2 seconds (effective 116.7 kbit/s)...
Hash of data verified.


Leaving...
Hard resetting via RTS pin...

Der Shelly muss rebootet werden. Einfach den USB Stecker aus- und wieder einstecken.

Datei 2 "rgbw2.bin"

esptool.exe --port COM8 write_flash 0x8000 rgbw2.bin

(bitte passt euren COM Port an)

Ausgabe:

esptool.py v4.7.0

Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Compressed 592256 bytes to 408077...
Wrote 592256 bytes (408077 compressed) at 0x00008000 in 35.9 seconds (effective 131.9 kbit/s)...
Hash of data verified.


Leaving...
Hard resetting via RTS pin...

Der Shelly muss wieder rebootet werden. Einfach den USB Stecker aus- und wieder einstecken.

Datei 3: "fs.bin"

esptool.exe --port COM8 write_flash 0xBB000 fs.bin

(bitte passt euren COM Port an)

esptool.py v4.7.0

Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Compressed 262144 bytes to 71528...
Wrote 262144 bytes (71528 compressed) at 0x000bb000 in 6.3 seconds (effective 331.3 kbit/s)...
Hash of data verified.


Leaving...
Hard resetting via RTS pin...

Der Shelly muss rebootet werden. Einfach den USB Stecker aus- und wieder einstecken.

Datei 4: "esp_init_data_default_v08.bin"

esptool.exe --port COM8 write_flash 0x1FC000 esp_init_data_default_v08.bin

(bitte passt euren COM Port an)

Ausgabe:

esptool.py v4.7.0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Compressed 128 bytes to 75...
Wrote 128 bytes (75 compressed) at 0x001fc000 in 0.0 seconds (effective 64.0 kbit/s)...
Hash of data verified.


Leaving...
Hard resetting via RTS pin...
```

Wieder ist ein Reboot notwendig.
Damit ist der Shelly fertig geflashed. Ihr könnt alle Kabel abziehen und normal Anschließen.

Der Shelly ist wie im Auslieferungszustand. Alle Daten sind zurückgesetzt!

Wie entstehen diese Zahlen wie "0x1FC000" im Flashbefehl?

Diese Hexzahlen, so nennt man diese, stehen in der manifest.json Datei, die sich auch bei euch im Ordner befindet.

Hier ist es aber noch eine Dezimalzahl.

Schauen wir uns den Bereich, einen Auszug, in der JSON z. B. für die letzte FW-Datei an:

"sys_params": {
"addr": 2080768,
"cs_sha1": "ff105e66b313201f5b40a2e02b7f00db24022088",
"cs_sha256": "b2218087cf938ce665b26ac049f7d146677c70fe2909205a4d0e6a58aef0e4b3",
"size": 128,
"src": "esp_init_data_default_v08.bin",
"type": "sys_params3"
}

Die "src" zeigt den Dateinamen. die "addr" die Startadresse in Dezimal für den Flashbefehl

Zum "Umwandeln" nutze ich den Windows-Taschenrechner : WIN einmal drücken, dann rechner eingeben und Enter.

Im Taschenrechner schaltet ihr mit dem Hamburger-Menu, die 3 Striche, auf den Programmierer-Modus um.

Leider kann der esptool.exe Befehl nicht mit Dezimalzahlen umgehen, zumindest hat es bei mir nicht funktioniert.

Das habe ich nun für alle 4 Dateien gemacht, so sind diese Startadressen entstanden.

Das war es.

Hey, du drehst mir das Wort im Mund um! Warum machst Du das?

Und dabei unterstellst Du mir hier und da auch noch falsche Sachen.

Wie wäre es einfach mal mit zuzuhören und nicht gleich jedem, der etwas Probleme äußert als unwissend, dumm oder irgendwie ähnlich anders negativ darzustellen?
Es gibt nicht nur deine Welt.

Komme bitte mal runter. Du scheinst irgendwo ein anderes Problem zu haben - ich bin es aber nicht.

Also ersten: ich bin nicht blöd. ich weiß, dass ich mit einem shelly BM arbeite.
Meine Aussage, dass ein Homematic BM und andere das anders machen, bezog sich auf ein Verständnisfehler meinerseits. Bitte verzeihe mir, falls das geht.
Ich habe es so gelesen, dass Du einen HM BM auch nutzt. Aber es steht eindeutig anders da - mea culpa.

Ich habe hier Tage in einer Problemlösung verbracht, bitte versuche einfach mal sich in die Lage anderer Leute und Umstände rein zu denken.

Ich mache Hausautomation schon seit 20 Jahren, habe 200 aktive Aktoren, Sensoren usw. im Einsatz, schon einiges an Skripten und Programme und Umsetzungen an die HM und iobroker Community geliefert und auch einige eigene Sensoren Entwickelt.

Zum Satz

Zitat von 66er

Wie auch von Muetze angemerkt, hat der Timer im http-Request des Shelly für diese Anwendung nichts zu suchen. Nutze "END of Motion" und alles funktioniert reibungslos( auch im Zusammenspiel mit Homematic ).

Eben nämlich nicht.

Hier glaubst Du auch einfach mal, dass Dein Gegenüber im Prinzip erst einmal in irgendeiner Art doof ist.
Sonst würdest Du nämlich ganz anders nachfragen.

Es gibt bei mir die Situation, dass der Ziel-RGBW2 erst nach dem erkennen des BM Strom bekommt. Ja, jetzt sehe ich schon wieder Deine Antwort: "Dann musst Du es anders machen usw. usf..."
Aber vielleicht geht es einfach hier nicht anders. Kann man sich nicht vorstellen, oder?
Das z. B. ein Laube nur WLAN und minimal Stromverteillung hat (Router, Raspi, Kamera), bis man einen Hauptschalter betätigt ist wohl nicht denkbar, oder? Und den möchte ich weiterhin per Hand bedienen, nachdem mir die Hütte einmal halb abgebrannt ist, weil ein Relais klemmte.

So, und nun ist das Problem da. Die Ganze Zeit ist in der Laube Bewegung und KEIN neues http kommt. Mqtt schon.
Und somit muss ich immer erst einmal raus gehen und eine Minute warten. Erst dann kommt nämlich der neue http ON Befehl.
Das das mit nur eine einzige Zeile mehr Code in der Firmware lösbar wäre, wo ich die function zum end_of_motion aufrufe ist mir klar - und Dir auch! Sorry, dass ich soweit dachte. Und sorry, dass ich mir einfach das gewünscht hätte.

Und das ich vielleicht beste Gründe habe, einen HM-BM abzulösen und einen neuen anderen verwenden möchte, der nicht z. B. Zigbee oder hm ist, sondern einfach nur WLAN, scheint auch nicht für Dich in Frage zu kommen, oder?
Die CCU3 soll abgelöst werden, ganz einfach. Und es soll kein zigbee sein, da mir zu unsicher in meinem Fall.

Und nein, ich erwarte NICHT, dass der shelly ein zweiter HM BM ist.
Deine Antwort

Zitat von 66er

Warum erwartet man immer wieder, dass sich Allterco jedem individuellen Userwunsch anzupassen hat?

ist somit einfach mal falsch. Ich erwarte es in keinster Weise, sondern wundere mich, wie es gelöst ist.

Denn

Zitat von 66er

Gerade Homematic ist ein event-getriggertes System. "Bewegung erkannt" triggert "Licht an" . "Keine Bewegung erkannt (END OF MOTION)" triggert "Licht aus".

der shelly erkennt keinen "Keine Bewegung erkannt". Wie soll das auch gehen?

Nach der letzten erkannten Bewegung läuft der interne Timer ab.

Zitat von michsa

Ein Retriggern eines Timers-Call per API darf nicht verwendet werden.
Es darf nur ein AN-Signal gesendet werden.

Der motion2 übernimmt die eigentliche Logik und sendet AN und am Ende ein OFF Befehl (bzw. sollte man es so einstellen).
Das verwirrt etwas - könnte aber z. B. mit iobroker und mqtt auch so gelöst werden, wie man es vielleicht annimmt.

Bei weiterem Nachdenken ist es dennoch ein gutes Feature. Ich wünschte mir, dass man die Funktion einstellen kann.

Die Sleep Time/Pause Funktion klingt eigentlich Logisch und den Sinn könnte man verstehen - wenn er bei mir kontinuierlich wäre. Ein Defekt nehme ich nicht an.

Bleibt ein bisschen die Hoffnung, das es doch noch geändert wird.

Verwendete FW:20220811-152232/v2.1.8@5afc928

Factory reset bereits testweise 2x durchgeführt

Evtl. hilft es anderen.
Evtl. hat noch jemand eine andere Idee oder Zugang zu den Entwicklern und kann das noch einmal durchdenken.

Alles anzeigen

Ich habe gar keine Frage gestellt.

Aber erst einmal muss man ja ein Posting negativ verstehen und auseinander nehmen. Immer schön negativ denken.

Nee, Stefan, hier bist Du einfach über das Ziel hinausgeschossen. Sehe nicht immer alle als so negativ an. Mein Güte.

Und mützes "Antwort" auf gar keine Frage ist somit auch unnötig, da er mich quasi nur selber zitiert.

Zitat

Beim Motion hat ein http -Befehl mit Timer nichts zu suchen

Danke auch für nichts.

Tolles Forum: hier werden Sie geholfen, auch wenn Sie gar keine Hilfe benötigen.

Warte, ich schreibe Deine Antwort an mich:
"Du musst ja dieses Forum nicht benutzen".

Übrigens, schuld sind immer die anderen, selbst wenn alle Argumente gegen mich sprechen.

Mann echt mal, etwas mehr Menschlichkeit. Ich bin Freund - nicht Feind.

Ciao.

Zitat von 66er

Wozu soll ein Gerät (der Motion) einen unveränderten Zustand "Bewegung erkannt" erneut senden?

Jeder Bewegungssensor von Homematic macht das so. Zumindest meine HM-Sen-MDIR-WM55 (3x vorhanden, HM-Sen-MDIR-SM 1x vorhanden und HM-Sen-MDIR-O-2 2x vorhanden)
Der Sensor erkennt eine Bewegung eingestellt z. B. jede Minute.
Du sendest per Homematic dann : Lampe gehe für 90 Sekunden an.

Bewegt sich jemand im Raum, wird nach 60 Sekunden, Bewegung vorausgesetzt, wieder ein gehe 90 Sekunden an gesendet.

Verstehe Deinen Hinweis und Deine Erklärung nicht.

Mag ja sein, dass Du da irgendwas eingestellt hast. Per default ist das so nicht und wird auch nicht so offiziell erklärt.
Selbst jeder Billig Baumarkt Bewegungsmelder arbeitet intern so. Du stellst ein, gehe an für z.B. 1 Minute.
Kommt eine neue Bewegung, wird der interne Timer auf 1 Minute zurückgesetzt.

Wo würdest Du das einstellen, so wie Du das beschrieben hast?:

Wahl des Sendeabstandes

Wenn beim Anlegen direkter Verknüpfungen die "Art der Verweildauer" auf "minimal" gestellt ist (Standardverhalten), dann wirkt sich die Wahl des Sendeabstandes direkt auf die Mindestverweildauer des Verbrauchers (Aktors) aus.

Es gilt dann folgende Beziehung:

Einstellung klassisch:

Diese Einstellung gibt die Funktion eines klassischen Bewegungsmelders wieder. Der Sendeabstand ist fest auf 240 Sekunden (+ 10% Toleranz) vorgegeben. Dies bedeutet: Der Bewegungsmelder meldet die erste erkannte Bewegung sofort, weitere Bewegungen dann erneut wieder nach einer Zeit von ca. 240 Sekunden. Bei direkten Verknüpfungen z. B. mit einem Funk-Schalter (zum Einschalten der Beleuchtung) hat die Beleuchtung damit automatisch eine Einschaltzeit von min. 5 Minuten. D. h., die Beleuchtung schaltet sich frühestens 5 Minuten nach der erkannten Bewegung wieder aus. Bei ständiger Bewegung wird die Einschaltdauer automatisch immer um 5 Minuten verlängert.

Vorteil: Fest vorbestimmte Einschaltdauer des Verbrauchers und batterieschonender Betrieb des Bewegungsmelders.

Nachteil: Keine kürzeren Einschaltzeiten als 5 Minuten möglich.

Einstellung dynamisch:

Der Sendeabstand passt sich automatisch der im Raum vorhandenen Bewegung an. Der Minimalwert kann vorgegeben werden, wobei kleine Werte zu Lasten der Batterielebensdauer gehen. Der Bewegungsmelder meldet die erste erkannte Bewegung sofort, weitere Bewegungen dann zunächst nach der eingegebenen Minimalzeit (z. B. 30 Sekunden). Bei direkten Verknüpfungen z. B. mit einem Funk-Schalter (zum Einschalten einer Beleuchtung) hat die Beleuchtung damit auch eine Mindesteinschaltzeit von 30 Sekunden. Die Beleuchtung schaltet sich nach 30 Sekunden ab. Bei ständiger Bewegung verlängert der Bewegungsmelder selbstständig schrittweise (dynamisch) seinen Sendeabstand und damit auch gleichzeitig die Einschaltdauer eines direkt veknüpften Verbrauchers auf bis zu 10 Minuten.

Vorteil: Bei Umgebungen mit wenig Bewegung kann die Einschaltdauer direkt verknüpfter Verbraucher klein gehalten werden (energiesparend).

Nachteil: Die Einschaltdauer ist nicht vorhersehbar und kann u. U. bis zu 10 Minuten betragen. Verkürzte Batterielebensdauer des Bewegungsmelder.

Aber egal, es geht nicht um Homematic, sondern um shelly.
Und da scheint es so, als ob die Logik gut ist! Aber durchaus anders gesehen werden kann, zumal extra die Retriggerfunktionen ala Treppenhauslicht vorhanden sind. Siehe Timer Funktion und der Möglichkeit den Timer neu zu starten.

Habe das nahezu das gleiche Thema nur anstelle des Dark-Modus halt immer.

Hier scheint der shellymotion2 nach FW Update oder nach Einstellen div. Settings nicht mehr zu senden.

Ich versuche das zu erklären.
Gegeben ist, das ein RGBW2 quasi als Treppenlichtfunktion leuchtet, wenn sich jemand im Raum bewegt.

Check RGBW2 Funktion
http://192.168.1.123/color/0?turn=on&timer=80 wird genutzt zum retriggern des RGBW2. Das geht vom Browser problemlos.
Starte ich den Befehl bei 45 Restsekunden erneut, bleibt der Dimmer wieder 80 Sekunden an - zeigt auch die Weboberfläche.
Ergo RGBW2 und Webcall okay - vom Prinzip her.

Motion2 Settings
"MOTION DETECTED" wurde diese URL des rgbw2 eingetragen.
"Motion Blindtime" auf 1 = 1 Minute.
"Motion Pulse Count" auf 1

Motion2 Verhalten
Kommt eine Bewegung, geht der rgbw2 an. Das zeigt auch diese Weboberfläche, die die Restzeit von 80 sekunden runterzählt.

Bei weiterer Bewegung blinkt motion2 kurz rot.
ABER: Es wird nichts mehr gesendet!
=> Das ist das, was man eigentlich erwarten würde. Denn z. B. der mqtt Wert wird ja auch gesendet, warum wird nicht einfach nicht die Action "motion detected" auch ausgeführt.

Weiterer Test:
"Sleep Time" auf zb. 30 Sekunden
Der Shelly blinkt bei Bewegung nun grün statt rot, wie es die Anleitung auch sagt.
Das erscheint logisch und hier würde ich keine Sendung erwarten.
Aber: Das geht nicht immer. Manchmal taucht die Pause nach der Motionzeit auf. Manchmal gar nicht...

Lösungsansatz
Da alle mir bekannten Systeme hier immer wieder den Befehl zum Retriggern senden, wäre es auch hier zu erwarten.
Bei der Homematic wünschte ich mir das genau, wie sich der shelly motion2 verhält, da hier die DutyCycle geschont werden würde.
Bei WLAN ist es im ersten Moment unlogisch, zumal ja auch mqtt aktualisiert wird und somit WLAN verwendet wird.
Die Pause Funktion verstehe ich nicht wirklich. Das System verhält sich hier ständig anders. Immer wenn ich dachte es herausgefunden zu haben, machte er was anderes.

Ein Retriggern eines Timers-Call per API darf nicht verwendet werden.
Es darf nur ein AN-Signal gesendet werden.

Der motion2 übernimmt die eigentliche Logik und sendet AN und am Ende ein OFF Befehl (bzw. sollte man es so einstellen).
Das verwirrt etwas - könnte aber z. B. mit iobroker und mqtt auch so gelöst werden, wie man es vielleicht annimmt.

Bei weiterem Nachdenken ist es dennoch ein gutes Feature. Ich wünschte mir, dass man die Funktion einstellen kann.

Die Sleep Time/Pause Funktion klingt eigentlich Logisch und den Sinn könnte man verstehen - wenn er bei mir kontinuierlich wäre. Ein Defekt nehme ich nicht an.

Bleibt ein bisschen die Hoffnung, das es doch noch geändert wird.

Verwendete FW:20220811-152232/v2.1.8@5afc928

Factory reset bereits testweise 2x durchgeführt

Evtl. hilft es anderen.
Evtl. hat noch jemand eine andere Idee oder Zugang zu den Entwicklern und kann das noch einmal durchdenken.

Viele Grüße

Mi

Hallo zusammen,

habe nun testweise auch die Beta 0.90 drauf.

Der Wunsch ist wohl recht einfach:
Schalte mit einem i3 einen Shelly 4 PM Pro - der eine Anmeldung benötigt.

Diese Bsp. HTTP-Request Shelly PRO 4PM funktionieren nicht.

Da ja nur noch, möge Shelly wissen warum, ein Passwort verwendet wird, soll dennoch der User per admin verwendet werden.

Wie gesagt, die einfache und übliche Funktion
http://admin:meinpwd@192.168.1.123/rpc/Switch.Set?id=0&on=true
funktioniert nicht.

Achtung an andere Tester: das geht, wenn Du zuvor dich im Browser am shelly angemeldet hast - ist aber ein Trugschluss.

Per curl funktioniert es:
curl --digest -u admin:meinpwd http://192.168.1.123/rpc/Shelly.DetectLocation

Nur der i3 wird das als Webhook wohl kaum verarbeiten.
Frage mich wirklich, was sich shelly dabei dachte und wie die Lösung dazu aussieht?

Hat das also schon jemand hinbekommen?

Michsa

Zitat

Die Idee mit dem Workaround probiere ich nachher einmal aus.

Den Wechsel von Weiß auf color hatte ich schon ausprobiert.

Der Shelly hatte sich dann auch die andere Firmware gezogen, ließ sich jedoch trotzdem nicht in die App integrieren.

Ich werde es nun mal mit dem Downgrade auf Basis der RGB Firmware probieren.

Die Shellys sind alle per DHCP eingebunden.

Die Variante mit dem Adapter würde ich auch ausprobieren. Gibt es hierzu eine Tutorial Video oder enen Thread?

Vielen Dank für die Unterstützung.

Alles anzeigen

Ja - Komma ABER: Hier scheinen die Recovery FWs nicht ganz in Ordnung zu sein - oder ich habe irgendwas übersehen, z. B. eine erweiterte Anleitung dazu.

Denn per Standard, so meine Tests in den letzten Tagen, zeigen ein blödes Problem mit der FW.
Hier habe ich vermutlich dann aber einen Workaround. Zumindest ging es bei mir dann wiederholend.

Ich würde dir dann alles zusammenkopieren oder einen eigenen Thread dazu aufmachen.
I Moment hoffe ich noch auf Hilfe aus diesem Forum, ob evtl. ich nur eine wichtige Anleitung übersehen hatte oder ob es erweiterte Hinweise gibt.

Ich habe mir diesen FTDI Adapter gekauft - bei mir läuft der auf vielen ESPs.

[
Bei den etwas preiswerteren war ich mir nicht sicher.

Ich habe es gerade mit zwei rgbw2 bei mir auch getestet => gleiches Thema. Kein Downgrade via OTA.

Das Umschalten brachte auch keine Besserung. In beiden Modi geht es nicht.

Dafür vermutlich noch einen anderen Fehler oder eine vergessene Funktion in der 1.82 gefunden.

Schade, dass es keine OpenSource ist. Schade das der Weg zur Hilfe so weit ist. Der RGBW2 hat noch viele Probleme.

Tasmota ist mir zu steif.

Zitat

Jemand eine Idee was ich verkehrt mache?

Gar nichts!
Könntest Du Dir vorstellen mittels einem Adapter (6€ bei amzn) und ein paar kleinen Steckkabeln die FW so aufzuspielen?

Aber vielleicht noch vorab ein Workaround:
Stelle doch einfach mal von color auf weiß - oder andersrum.

Dann spielt er normalerweise mit der gegebenen FW, die bei dir drauf ist, eine neue ein.
=> so lange der Shelly auch ins Internet kann.

Dann Versuche das ganze noch einmal. Also per Browserbefehl die FW downzugraden.

=>DHCP oder feste IP eingestellt?

Zitat von 66er

Dann vermute ich mal den direkten Support von Allterco !?

Danke.

Ja, das ganz bestimmt. Das english war auch nicht the yellow from the egg.
Jetzt schreib aber nicht wieder, das sei hart.

Zitat

Ich werde es mit einem Downgrade probieren.

Wenn ich den Anweisungen auf der Seite des Links folge, sagt die Webseite ständig die eingegeben IP wäre falsch. Wie kann das sein, wenn ich die IP aus der Adresszeile kopiert habe?

Nur um sicher zu gehen:
Du hast in das Feld die IP-Adresse deines Shellys, den du downgraden möchtest, eingegeben?

Dann hast Du noch den richtigen Shelly ausgewählt und hast die gesamte Zeile kopiert und im Browser abgeschickt.

Wie sieht denn die Fehlermeldung genau aus? Kommt die vom shelly?
Vielleicht magst Du ja ein Screendump posten?

Der Shelly hat eine statische IP oder eine automatisch zugewiesene? Oder anders: Der Shelly kommt aber in's internet (gateway passt?).

Im Falle das Du eine statische IP im shelly rgbw2 konfiguriert hast: Da scheint immer noch ein satter Fehler zu existieren. Zumindest habe ich das bei zwei RGBW2 Shellys mit Firmware >= 1.80 die letzten beiden Tage festgestellt.

Ansonsten muss ich mal schauen, ob ich meine Erfahrungen hier irgendwo zusammenschreiben darf. Habe nun den ersten Shelly wieder am Laufen, indem ich per esptools eine recovery FW aufgespielt habe. Ist nur leider nichts mit aufspielen geht - sondern noch mit sehr viel Verrenkungen verbunden.

Zitat von 66er

Harte Worte.

Von welchem Support sprichst Du?

Was ist daran hart?
Wenn Du eine Erfahrung machst, z. B.: "die fahren in Italien alle merkwürdig", dann ist es Deine Meinung und Deine Erfahrung, Was ist daran also hart?
Warum reagieren Menschen immer so, wenn jemand von seinen persönlichen Erfahrungen spricht?
Ich habe doch nicht geschrieben, die sind sch... oder sonst was.
Wenn der Support mir aber trotz meines defekten RGBW2 schreibt, "zu 99% liegt es immer am User", dann bin ich schon irritiert. immerhin hat die LED nicht mehr geblinkt, nichts passierte.

Dieses Forum ist voll mit RGBW2 Problemen. Der Playstore zeigt auch eine deutliche Richtung der fehlenden Zufriedenheit. Sagen darf man das aber nicht?

@funkenwerner: schieß los: was findest Du verwirrend, laut deinem Eintrag "Reaktion"? Die vielen Tipps, die ich einem User gab?

Ich sitze schon wieder seit dem Wochenende, satte 20h Arbeitszeit, um meine defekten Shellys wieder zum Laufen zu bekommen. Diese vielleicht wertvollen Tipps, auch wen der eine oder andere sie nicht mag, sind aber möglicherweise zielführend.
Was verwirrt dich also?

Und beim Threadeintrag zuvor von KlickKlack, wo er im OT beschreibt, dass er etwas auch nicht hinbekommen hat, bedankst Du dich als Reaktion? Hier bin ich .

BTW an die, die immer schreiben, man solle keine Updates fahren: Das macht der RGBW2 von alleine, wenn man die Leuchtart color/weiß umschaltet.

Achso, zur Frage welcher Support: Der Support irgendwo, wo sitzen die eigentlich? In Bulgarien? Keine Ahnung. Irgendwas englisches. Da hatte ich auch einige RGBW2 her.

Ich habe von 8 RGBW2 Shellys jetzt schon drei gehabt, die einfach nicht mehr nach einem FW Update funktionieren.
Die restlichen machen große Schwierigkeiten mit der App. Das Problem ist, dass die App die ganze Zeit nach Hause telefoniert - auch wenn die Cloud Disabled hast.

Letztendlich ist die App nichts weiter wie ein Webclient.
Ich hatte auch ein bisschen meinen Pi-Hole in verdacht gehabt - durch den sah ich dann, was da alles so - trotz deaktiviert cloud - raus geht.
Die Bilder und alles lädt er nämlich brav runter - oder eben nicht.
Hast Du schon einfach mal die Webadresse https://my.shelly.cloud/ verwendet?
Mach mal und schaue, was da alles so ist. Evtl. kannst Du mit der alles einstellen.

Tolle Tipps wie "nicht Updaten" brachten mir da auch gar nichts
Der Support ist unterirdísch schlecht.Für die ist der Anwender einfach nur doof.
Die APP Bewertung im Store spricht für sich.

Ich glaube mittlerweile nicht mehr, dass es an einer Deiner Geräte liegt. Bei mir geht es jetzt auch nicht mehr.
Versuch einfach mal auf eine niedrigere Version downzugraden..

Weist Du wie das geht? Am einfachsten via einer URL, die man sich hier sehr gut zusammenbasteln kann:
https://shelly-forum.com/index.php?shelly-firmware-archive/

Viel Glück!

SparkyMaster, MIHO & Guzzi-Charlie

Vielen Dank erst einmal an Euch für euren netten Erklärungen. Gleichzeitig auch mein Respekt, das ist immer viel Arbeit, oft wahrscheinlich undankbare.

Zitat von Admin

Was ich von Dir erwarte sage ich Dir jetzt. Ich erwarte von Mitgliedern das sie sich genau so benehmen wie alle anderen auch.

Hallo Detlef,

keine Ahnung wie das gemeint ist. Keine Ahnung, wie Du was verstanden hast. Werde da nichts hinein interpretieren, klingt aber als Einleitung komisch vor allem im Kontext zu meinem von Dir zitierten Text.
Wenn ich so an meine Kunden denke, ohje, ich hoffe die Leute benehmen sich nicht so!

Gekauft via amazon - ist bereits retour.
Defekt ist defekt, leider.

Meine App zeigte mir nichts von einem Datenbankupgrade an. Weiß auch nicht, was das bedeuten soll, kann mir aber verschiedenes denken.
Ich werde nie im Leben ein IOT Gerät haben wollen, was in irgendeiner Form auf das Internet angewiesen ist. Deshalb ist auch die Cloud Funktion selbstverständlich deaktiviert. In Zeiten von VPN etc. kann ich das einfach nicht verstehen. Egal, anderes Thema.

Deine Frage macht nun skeptisch - und siehe da, ich befürchte, dass meine App tatsächlich alles in das Internet pumpt. Dank Wireshark und Konsorten bin ich recht erschrocken, was da doch vom Handy hoch geht - obwohl ja die Cloud deaktiviert ist.
Und hier könnte ja glatt ein Zusammenhang bestehen zu meinen Problemen, was ich aber grausam fände.

Soeben (20.7.20 20.00h) konnte ich wieder meine Shellys nicht steuern.
Die App ist für mich quasi immer wieder nicht zu gebrauchen. Das ist schlimm und sorgt für Frust.

Das Websystem des Shellys lässt sich wenigstens bedienen - die Dinger sind es nicht (mehr).

Der FAF (Frauen/Familien Akzeptanz Faktor) rutschte in den Minusbereich. Das ist noch schlimmer.

Ich denke nicht, dass es direkt am Handy liegt. Es betrifft ja auch nur die RGBW2 Devices.

Ich baue mir nun meine eigene Oberfläche, denn die API ist mittlerweile positiv ausprobiert und alles funktioniert wie gewünscht.

So bleibt also ein bitterer Beigeschmack.

Soweit aber nochmals Danke für die Antworten.

Zitat von Admin

Solltes du weitere Fragen haben kannst du dich gerne hier https://ticket.shelly.support/open.php ein ticket eröffnen. Vielleicht arbeite ich ja sogar deinen fall ab.

Vielen Dank, aber da hättest Du ja wahrscheinlich mir hier schon eine Antwort gegeben. Da werde ich nun keine unnötigen Redundanzen schaffen.

Servus, Michsa

Zitat von 66er

speziell zur 1.7.3 kann ich mangels EInsatz leider nichts sagen. (Bin kein Fan von Updateorgien , gerade wenn ein Gerät (nicht nur die Shelly) alles tut, was es soll und noch dazu in meinem Netz bleibt (also nur lokaler Betrieb)

Nunja, das erste was man vom Support hört, ist : Haben Sie die letzte Version installiert...
Ich denke das hat nichts mit Updateorgien zu tun, sondern auch mit Sicherheit. Selbst wenn das Gerät gut funktioniert kann es andere Probleme geben.

Zitat von 66er

Zu3. : Beispiele für http-Befehle findest Du auch hier im Forum. SparkyMaster hat vieles im Lexikon veröffentlicht.

Ja, aber nicht die von mir gewünschten. Daher meine Nachfrage.

Zitat von 66er

Viele (aber nicht alle) Probleme haben User, weil unsere Tipps einfach ignoriert werden. 70/30 steht sehr oft am Ende von Theads (Danke für die Ehrlichkeit der User ).

Nun weiß ich nicht, ob und was Du mir direkt damit sagen möchtest? Kann mir nicht vorstellen, dass Du mir Ignoranz unterstellst, oder?
Aber lasse mich bitte einen Hinweis geben. Leute wie Du, die sehr lange in einem Forum aktiv sind, wissen, was es gibt, wonach man suchen muss und vor allem auch wo.

Kommt man als Neuling daher (selbst wenn man Informatiker wie ich bin), findet man hunderte von Einträgen. Viele sehr alt, viele obsolet - aber nicht als solches zu erkennen. Klar, in der Logik des Thread Anpinners und Schreiberlings ist alles klar. nur ist die Logik eines jeden anderen anders.

Deinen "Einsteiger-Tipps" Link sieht man irgendwann sehr schnell. Und dann liest man erst einmal eine Weile. Das tat ich. In einem anderen Thread hast Du ja noch auf meinem Scherz ("leer gelesen" auch mit einem Scherz geantwortet).

In meinem Fall waren tatsächlich die beiden RGBW2 defekt. Ich habe diese aufgemacht und siehe da: Lötbrücken, wo sie nicht hingehören. Ich scheine hier Pech gehabt zu haben. Das Gerät hatte nachher gar nicht mehr funktioniert - nehme thermische Abhängigkeiten an.
2 neue Funktionieren wesentlich besser.

Was ich aber nicht verstehe, ist die schlechte App:
Es gibt hunderte Anleitungen auf Youtube. Ich bin ein optischer Mensch und mag solche Anleitungen wesentlich mehr. Beachtet man hier die Vorgehensweise, stellt man fest: Es gibt hier die unterschiedlichsten Ansätze des Einbindens - und viele sind wegen der Probleme unterschiedlich.
Letztendlich ist die APP mehr als verbesserungswürdig. Egal ob auf Apfel oder Androiden.

BTW:
Sucht man Hilfe, landet man hier im "Offiziellen Shelly Support Forum". Und dann erwartet man hier tatsächlich genau das. Bei einem offiziellen Support bekommt man ein und dieselbe Frage hundert Mal gestellt - und muss diese auch hundert Mal beantworten. So ist es bei unserer Firma und auch sonst wo. Die Supportsoftware hält dazu i. d. R. eine Antwortdatenbank vor, so dass der SupportMA nicht immer und immer wieder das Selbe schreiben muss.
Ich lese aber heraus, dass es hier nicht gewünscht ist. Das ist etwas schade.
Auch finde ich nun ganz unten den Hinweis auf "Wir sind ein privates Support Forum". Dann sollte man vielleicht das "Offiziell" entfernen.

Und so hatte ich dieses Forum bis eben verstanden: Ich melde meine Probleme hier, die ich übrigens mehrfach im Internet nachlesen kann und auch bei anderen erkenne.

In der Quintessenz ist das aber quasi falsch, da man mit einem Ticket bei Allterco Robotics LTD besser aufgehoben ist, richtig?

Viele Grüße
Mic

PS: Man kann ja viel behaupten, daher einige Bilder Im Anhang. Der name der Bilder erklären das Problem. Und genau dieses wollte ich beantwortet haben.
Beim Kurzschlussbild waren zwei Kurzschlüsse. Ein bisschen sieht man links noch die weggekratzen Reste.
Leider gab es einen Schluss durch den Lötstoplack, der ja oft eine Schutzschicht darstellt.
Bei mir gab es einen Niederohmigen Schluss, so dass es sogar funkte beim Anlegen der Spannung. Da ich bisher keine anderen RGBW2 hatte, dachte ich an einen zu groß dimensionierten Elko ohne Ladewiderstand. Du siehst - ich habe mir sehr viele Gedanken gemacht.

Hallo zusammen,

so langsam bringt mich das kleine Dingens an den Rand der Verzweiflung. Wollte mal hören ob ich der einzige bin? Habe 2 von denen.
Noch einige andere Shelly1 und 2.Die laufen ohne sorgen.

Manchmal frage ich mich, ob es an der neuen FW 1.73 liegt?

1.) Die Android App oder das WebInterface: Gut, ich kann die Farben einstellen - aber nur sehr schlecht. klicke ich im Kreis ganz am Rand um z. b. nur ein rot, orange, etc... zu erhalten, ist die Farbe immer noch mit anderen abgemischt. So gesehen kann ich nur die volle Farbe mit den rot, blau, grün Button erhalten. Aber was ist mit orange oder türkis?

2.) Stelle ich mehrfach hintereinander die Farben ein, da es ja solche Schwierigkeiten macht, dann scheint der kleine abzuschmieren und sich neu zu starten. Erst nimmt er keine Befehle mehr entgegen, dann ist er kurz aus und schaltet sich dann auf einer der Farben zuvor.

3.) REST API. Allgemeines Problem (klickmich Das, was da die Entwickler schreiben, ist immer noch mit irgendeinem Geheimwissen anzureichern. Warum kann man nicht mal einfach echte Beispiele bringen pro Setting? Die Antwort JSON stehen ja auch da.
Muss man erst mal auf die Idee kommen zum Einschalten nicht "ison" zu verwenden, sondern "turn". Im Json wird der Wert mit "ison" angezeigt.
Setzen der Farben: nimmt man nun ipadresse/settings/color/0 (soll die Farben persistent setzen- okay, was bedeutet das nun genau?) oder /color/0/settings (war irgendwo ein anderes Beispiel) oder doch nur /color/0 (...controls the output... ).
Wenn ich dann die Werte versuche, dann setzt der kleine die Farben schon so, wie ich es wünsche. Und dann, so nach 1 Minute, schwupps , nimmt er eine Farbe von zuvor. Erst geht er kurz aus, dann kommt die Farbe von 2x davor.
Es gibt keinen Timer, keine andere Steuersoftware und Handy habe ich ausgemacht.

Schicke ich einige Befehle hintereinander, dann verweigert der kleine die Annahme weiterer Befehle (siehe Punkt 2).
Laut WLAN habe ich eine recht gute Verbindung, kann also nicht daran liegen. Da sind die anderen "nicht RGBW2" Shellys deutlich schlechter - dafür sorgenfreier. Und nein, der rgbw2 liegt auch nicht direkt neben dem Accesspoint, so dass ein Übersprechen vorhanden ist.

4.) Mit dem Handy und der APP war kein Einbinden möglich. Irgendwann kam ich auf die Idee mein Tablet mal zu nehmen. Ging sofort.

5.) FW Update: Zeigte mir als neuere Version eine ältere an?! Ein Update ging dann auch nicht. Aber das rote Ausrufezeichen blieb. Irgendwann verschwand es. Sowohl in App als auch in der WebUI.

Tja, wie ist es bei euch so? Bei einigen Threads sehe ich ja ähnliche Probleme. Was kann man da machen?

Gruß Michsa

Hatte exakt das gleiche Problem. Die Lösung ist so simple wie unnötig. Bei mir war es einfach das Handy. In meinem Fall ein Android 10 auf Oneplus 3.

Ich habe das ganze Forum leer gelesen.

Irgendwann zwischen Verzweiflung und Wut kam ich auf die Idee mein Tablet zu nehmen. Da ist ein android 7 oder so drauf. Das lief sofort. Und ich habe Buttons gesehen, die sonst nicht da waren.

Und ja, mein Shelly 1 und 2 haben sich mit dem ersten Handy sorgenfrei einbinden lassen.

Ob es nun das Handy war, irgendeine Zusatzsoftware (ist z. B. ein Norton drauf) oder schlicht nur mit dem Mondstand zusammenhing: keine Ahnung.

Zitat von Herr Heisenberg

Ok, habe die Programme jetzt mal auf "bei Änderung auslösen" geändert. Leider ziehen die RM teilweise trozdem noch hoch. Ich glaube, dass es ein Timer-Problem sein könnte, da der Fehler immer nur Nachmittags (nach 12Uhr) auftritt.

Was hast Du eigentlich für Motoren?
Ich habe den selben Effekt - aber das liegt an meinem KlemmSchutz der Rolladenmotoren.
Der Rolladen fährt ein kleines Stück runter - dann hoch.

Ist nur ein kleiner Hinweis, nicht das Du da sowas wie ich hast?
Und wenn der Tipp nicht passt - dann halt schade..

Hallo Stefan,

erst einmal vielen Dank für Deine Mühe und Erklärung! Topp.
Ich stelle gerade alles nach und komme an eine Problemstelle für mich:

Was ist das Gerät Shelly-Flood KG Waschmaschine?

Das haben wir doch nicht in Deiner Anleitung angelegt, oder?

Oder anders: Im ersten Bild oben (Die Ansicht der Anbindung) hast Du ja das Gerät dargestellt - aber nicht beschrieben, richtig?
Das wäre aber gerade schön zu wissen, wie du diese drei Elemente (Schalter, Temp, Batt) in einem Gerät zusammengefasst hast.

Magst Du das noch erweitern? Oder habe ich da was übersehen?
Ich habe keinen Link weiter oben gefunden, der zeigt, wie Du denn dieses Gerät Shelly-Flood KG Waschmaschine setzt - im Alarmfall. Im Moment bleibt nach dieser Anleitung auch im Alarmfall alles auf AUS - also keine Möglichkeit der Alarmbenachrichtigung.


Gruß
Mi

Zitat von 66er

Aber dieses CUxD-Gerät lässt sich leider nicht auf Status "Gefahr" setzen. Der Zeitstempel wird zwar aktualisiert, aber das Icon wird nicht geschalten!

Dies ist einem anderen Forum zu Folge ein Bug in der Homematic-Welt, der seit mindestens 1 Jahr bekannt ist.

Hi 66er,

erst einmal vielen Dank für Deine vielen Infos, die mir sehr helfen!

Kannst Du mir bitte einmal sagen, was genau der Fehler wo ist? Also ist es ein Problem innerhalb der CCU direkt oder eher von CuxD? Oder ganz was anderes.
Ich frage nur, da ich bereits andere Teile mit CuxD als Gefahrenmelder problemlos umgesetzt habe.
Und entweder habe ich hier ein Problem, von dem ich noch gar nichts weiß oder bei mir funktioniert es aus welchem Grund auch immer.

Wäre also Nett, wenn Du Dir die 5 Minuten nehmen könntest. Danke schon mal im Voraus.

MI