Beiträge von Harry6276

I had exactely the same problem which seemed to be a firmware problem. After updating to the version mentioned above respectively to the beta version 20221014-091822/v1.12.1-rc1-gd2158aaand after a new calibration the message overtemp disappeard. Unfortunately in both versions there appeared a new problems handling the physical switch1 and unexpected turning on . On, off and dimming doesn't work properly anymore.

I used the older Shelly Dimmer before for the same lights which worked perfect in one button mode.

It burned down for no apparent reason after 14 months so I wanted to change it by a Dimmer 2.

Finally I replaced the Dimmer 2 by a 2.5.

66er .... danke, well life and learn

Zitat von 66er

Was passiert, wenn Du den Befehl in die Adresszeile eines Browsers kopierst und ausführst?

Das war die entscheidende Frage: ERR_CONNECTION_REFUSED

Kaum verwende ich die richtige IP-Adresse der RASPBERRYMATIC, schon antwortet der RPi4 über Port 8181

Ich habe irrtümlich die Shelly-Adresse eingetragen und war absolut betriebsblind! Auch die Idee mit dem Browser ist mir um 4 Uhr Früh nicht gekommen. Danke für den Support.

PS: Ich hoffe es ist OK, wenn ich in meinem Original-Post den überflüssigen Balast, der zum Verständnis nichts beiträgt, wieder entferne.

Liebe Grüße

Harald

Hallo Allseits!

@Stefan: Kompliment! Sensationelles Know-How und super Dokumentationen. Danke, ich hab schon sehr viel nutzen können.

Jetzt allerdings kämpfe ich seit Tagen mit der Einbindung der Shelly dimmer 2 und benötige dringend eure Unterstützung.

Problem: Das Schalten an den realen Tastern bzw. im WEB-UI der Shellys verändert den Status des CUxD (16) Schalters (Kanal 9) nicht. Die Rückmeldungen unter Aktionen "output switched on/off URL" kommen in CUxD einfach nicht an und es wird der Schalterstatus EIN/AUS nicht verändert.

Ich habe im Shelly gemäß Anleitung die Befehle kopiert und angepasst:

http://192.168.127.73:8181/cux.exe?Antwort=dom.GetObject("CUxD.CUX4000001:9.SET_STATE").State(1)

(bzw. in off -> State(0)).

Ich hab auch unzählige andere Varianten des Befehls ausprobiert: einfache statt doppelter Hochkomma, Kanal-Name statt Serien-Nummer, Kanal-Name und ).SET_STATE.State(x), aus Verzweiflung auch 66er.exe oder Harry.exe und statt Antwort= ret= uvm. .... kein Erfolg.

Das Schalten von der RaspberryMatic aus funktioniert tadellos und verändert auch den Schaltzustand und die Dimmerwerte im WEB-Interface der Shellys.

Ich habe auch Shelly 1 und Shelly 2.5 eingebunden. Bei diesen funktioniert die Rückmeldung an CUxD problemlos.

Befehl z.B.: http://192.168.127.129:8181/cux.exe?ret=dom.GetObject('Kino').State(1)

Hat jemand einen Tipp zur Lösung oder eine Idee, wie ich das Problem weiter eingrenzen kann? Welche Infos werden noch benötigt?

Hier einige Facts:

* RaspberryMatic auf RPi3, Version 3.55.10.20210213

* CUxD Version 2.5.1

(Problem ist auch bei RM 3.55.5 und CUxD 2.4.4 aufgetreten).

* Shelly dimmer 2 mit Firmware-Version

20210226-115010/v1.9.6-dimmer2@1873d25e

* Firewall: Ports offen

* Fixe IP-Zuordnung der Shellys im Range .61 bis .74, keine Überschneidungen mit DHCP Range.

* ioBroker auf Synology unter Docker

* CUxD Geräte sind angelegt ((28) Exec, (28) Multi-DIMM-Exec und (40) 16 Kanal Univ-Steuerung für Shelly 1, 2.5 und Dimmer ... alles nach Anweisung ... funktionieren.

Im System-Protokoll gibt es keinen Eintrag, wenn ich am Taster oder via Shelly WEB-Interface schalte und in den Sys-Logs finde ich keine besonderen Hinweise oder Fehlermeldungen.

Danke schon mal im Voraus und

liebe Grüße

Harald