Nach einigem Frust mit meinem "Shelly Pro2" und einem "Shelly i4" sind die jetzt seit November in der Lade gelegen, sollen aber nun doch wieder zum Einsatz kommen, weil es so auch keinen Sinn macht - sollten ja einen Zweck erfüllen.

Hat jemand schon die offiziell angebotene "Version 1.3.3" auf einem oder beiden Shellys? Wichtig ist dabei, dass der ioBroker ohne Probleme damit verwendbar ist, ohne die bekannten Fehlermeldung:

https://forum.iobroker.net/post/1058483

Laut Chancelog https://shelly-api-docs.shelly.cloud/gen2/changelog/#133-2024-06-25 hat sich ja vieles getan, aber ich bin mir unsicher, ob ich es riskieren soll. Eigentlich erwarte ich mir bessere Delay-Time zwischen Input und Action.

Naja und neue Firmware schadet meistens ja nicht...

NACHTRAG:

Beim Shelly Plus i4 dürfte alles problemlos laufen, jetzt mit Version 1.4.4

Beim Shelly Pro2 gibt es massive Probleme, siehe Screenshot.

Nach einiger Recherche ergab das "WLAN Roaming" für mich Sinn, siehe:
https://github.com/iobroker-community-adapters/ioBroker.shelly/issues/931#issuecomment-2439571177

Ich habe bei diesem Geräte leider nur "RSSI: -70dBm (Weak)" laut Webinterface. Somit habe ich "RSSI threshold" auf -90 gesetzt und den Interval auf 0 - also disabled.

Leider hat dies auch nichts gebracht...

Finden wir noch einen Weg, oder muss ich den Shelly Pro2 wirklich raus werfen und gegen ein anderes Gerät ersetzen? Aktuell dient er eigentlich nur als Schalter per Webinterface für zwei Kanäle.

Gefühlte 2 Stunden später:

Kein Connect mehr zwischen dem Shell 2 Pro und dem ioBroker mehr...

Und zu allem Überdruss scheinbar ein Downgrade von 1.4.4 auf 0.14.x nicht möglich. Der Balken läuft ewig und irgendwann ist man wieder bei der 1.4.4 Firmware - NAAAA SUPER.

Ups...

Also anscheinend besteht das Problem auch für das "Shelly i4" ... den hab ich seit Freitag hier zum Testen. Mit der neuesten Firmware (über Webupgrade) nur Fehler. Also zurück auf 0.14.X ... herrje... was macht Shelly nur. Oder ist das Problem der Shelly Adapter von ioBroker? Irgendwie bin ich mir da jetzt nichtmehr sicher...

Also... jetzt gibts was Neues:

Die "Press/Release" werden so kurz getriggert, dass ich es unter den Objekten nicht oder kaum sehe. Da ist die Aktualisierung anscheinend zu träge. Jedoch in einem Blockly kann ich über einen Debug-Baustein das umschalten von "press" und "release_press" sehen.

Allerdings ... das "hold" klappt irgendwie nicht, so wie schon mal irgendwo hier geschrieben wurde.

Ich werde jetzt meinen "Shelly 2.5" zwar raus werfen, aber dafür einen "Shelly i4 (AC)" einbauen.

Grund dafür ist, dass ich die Shelly 2.5 eigentlich als Strommesser im Einsatz hatte, nach rund 16 Monaten waren aber bei beiden Geräten die Kondensatoren defekt. Diese habe ich zwar ausgetauscht und es funktioniert wieder alles, aber es ist unsinnig, wenn ich für die Strommessung immer die Relais angezogen habe. Dies führt zu einem erhöhten Stromverbrauch, zu deutlich mehr Wärme in der UP-Dose und somit zu einem vorschnellen Ausfall der Elkos.

Die Strommessung werde ich jetzt anders machen ... noch ist unklar wie, aber egal derzeit.

Mit dem Shelly i4 fahre ich sicher besser, da dieser keine Relais hat.

@diamand2k22

Danke für die Info...

Ich habe gleich mal getestet und erhalte wie mit der 1.0.3 wieder Fehler im iob-Log:

2023-10-10 23:40:19.816 - info: shelly.1 (29468) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-10-10 23:40:29.790 - info: shelly.1 (29468) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)
2023-10-10 23:40:33.157 - info: shelly.1 (29468) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-10-10 23:40:43.137 - info: shelly.1 (29468) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)
2023-10-10 23:40:47.188 - info: shelly.1 (29468) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-10-10 23:40:57.170 - info: shelly.1 (29468) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)

Und dann noch:

2023-10-10 23:42:54.755 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:54.913 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:54.914 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:54.915 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:55.270 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:55.272 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:55.273 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:55.273 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-10-10 23:42:55.497 - error: shelly.1 (29468) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"

Auch werden die MQTT Daten nicht vollständig und korrekt übertragen:

Ich nutze das aktuelle Shelly Plugin (v6.4.5) von ioBroker. Keine Ahnung, wo das Problem herkommt. Dazu bin ich leider zu wenig tief in der Materie und eher nur Anwender ...

Also doch wieder zurück zur 0.14 ...

(Anmerkung: Downgrade wieder erfolgreich und funktioniert wieder!)

Hier mein (sehr positives) Fazit zum Downgrade:
https://forum.iobroker.net/post/1058091

Ich wollte es hier nicht nochmal posten.

@michaelf

Nunja, das klingt ja alles interessant.

Zurücksetzen möchte ich den Shelly 2 Pro eigentlich nicht so gerne, weil ich wieder alles einrichten müßte.

Aktuell habe ich folgende Firmware (laut Webinterface) drauf:

20230912-082331/1.0.3-g6176478

Downgrade selbst gefunden, hier für andere:

Infos sind zu finden unter:
https://www.shelly-support.eu/forum/thread/21566-firmware-1-0-0-für-geräte-der-2-generation-wird-offiziell-bereitgestellt/?postID=227817#post227817

(Benutzerkonto muss vorhanden sein, soweit ich das noch weiß!)

Hier sind auch die Direktlinks zu diversen Gen2-Geräten zu finden:

PlugUS
Plus1
Plus1PM
Plus2PM
PlusHT
PlusI4
PlusPlugIT
PlusPlugS
PlusPlugUK
PlusSmoke
PlusWallDimmer
Pro1
Pro1PM
Pro2
Pro2PM
Pro3
Pro3EM
Pro4PM

Während ich das Downgrade laufen habe ...

Ich frage mich ja wirklich, wieso es bei Shelly immer wieder Probleme mit der Firmware gibt? Ich hätte schon mit einem einfachen Shelly 1 (UP-Modul) richtige Probleme und mußte dann auf Tasmota wechseln, damit die Hardware für mich nutzbar war. Jetzt und hier ein Versionssprung von 0.14 auf 1.x - alles nicht ganz klar. Eigentlich denkt man bei einem solchen Sprung, dass hier vieles getan wurde, aber eher verschlimmbessert kommt mir vor.

Irgendwie werde ich immer mehr enttäuscht von Shelly Produkten.

Nach dem Downgrade:

Ich habe nur die Instanz im ioBroker neu gestartet und es funktioniert.

Aber wo ist nun der Fehler in der neuen Firmware? Irgendwelche fehlt mir das Wissen, dass ich tiefer in die Materie einsteige und bin eher der Anwender mit einem gewissen technischen Verständnis. Hmm... vielleicht findet ja jemand was raus.

FAZIT: Das Downgrade auf 0.14 funktioniert!

DANKE für diesen goldreichen Tipp, der wahrscheinlich nicht nur mir geholfen hat! TOP TOP TOP!

@bananajoe

Konnte das Problem eigentlich abschließend geklärt worden, denn ich habe das selbe Problemchen...

Auszug aus dem Logfile:

2023-09-23 23:40:38.160 - info: host.niedernpi "system.adapter.shelly.1" enabled
2023-09-23 23:40:39.421 - info: host.niedernpi instance system.adapter.shelly.1 started with pid 3514
2023-09-23 23:40:44.150 - info: shelly.1 (3514) Plugin sentry Sentry Plugin disabled for this process because sending of statistic data is disabled for the system
2023-09-23 23:40:50.497 - info: shelly.1 (3514) starting. Version 6.4.1 in /opt/iobroker/node_modules/iobroker.shelly, node: v18.17.1, js-controller: 5.0.12
2023-09-23 23:40:51.553 - info: shelly.1 (3514) Starting in MQTT mode. Listening on 0.0.0.0:1883 (QoS 0)
2023-09-23 23:41:06.866 - info: shelly.1 (3514) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-09-23 23:41:16.807 - info: shelly.1 (3514) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)
2023-09-23 23:42:04.207 - info: shelly.1 (3514) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-09-23 23:42:14.191 - info: shelly.1 (3514) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)
2023-09-23 23:42:40.762 - error: shelly.1 (3514) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-09-23 23:42:41.043 - error: shelly.1 (3514) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-09-23 23:43:08.894 - info: shelly.1 (3514) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-09-23 23:43:18.885 - info: shelly.1 (3514) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)
2023-09-23 23:43:45.341 - error: shelly.1 (3514) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"
2023-09-23 23:44:13.515 - info: shelly.1 (3514) [MQTT] Device with client id "shellypro2-30c6f78119c0" connected!
2023-09-23 23:44:23.495 - info: shelly.1 (3514) [MQTT] Client Close: (shellypro2 / shellypro2-30c6f78119c0 / shellypro2#30c6f78119c0#1) (false)
2023-09-23 23:44:49.340 - error: shelly.1 (3514) [MQTT] Unable to get mqttprefix of client with id "shellypro2-30c6f78119c0"

Ich habe den Adapter gestoppt, dann den ganzen Baum von shelly.1 gelöscht. Den Shelly 2 Pro neugestartet, dann den Adapter wieder gestartet und es kommt weiterhin zu diesem Fehler. Die Daten bei den Objekten sind nur teilweise vorhanden, meist nur der Zweig/Baum - aber die Daten selbst fehlen...

Vor der Neuinstallation meines ioBrokers hat es funktioniert, jetzt leider nichtmehr...

Wer hat eine Idee oder eine Lösung? seufz

Hallo in die Runde,

ich habe seit heute auch das Modul (https://www.led-trading.de/zigbee-unterputz-modul-fuer-friends-of-hue). Verwendet werden soll es mit deConz, was nach ein paar Schwierigkeiten auch teilweise funktioniert. Die Details:

In deConz neuen Schalter verbinden und "Andere" auswählen. Laut deConz nutze ich Kanal 11 für Zigbee.

Nach der Anleitung unter https://phoscon.de/en/support#pairing-friends-of-hue-switch muss ich für den Kanal 11 also Button 3 für 10 Sekunden drücken. Weiters habe ich gefunden, dass folgende Belegung gilt:

Button 1 = K3
Button 2 = K4
Button 3 = K1
Button 4 = K2

Also es ist nicht Button 1 = K1, Button 2 = K2 ... (ein wenig irreführend finde ich).

Im Phoscon Webinterface wird mir der Schalter auch korrekt angezeigt und ich kann ihn auch zuweisen. Allerdings werden die Schaltfunktionen nie ausführt, also scheint da wo der Wurm drinnen zu sein.

In der deconz-gui zeigt er mir den Schalter gar nicht (!!!) an, was wahrscheinlich schon das Problem darstellt.

Nun stellt sich für mich wirklich die Frage, ob dieses Modul denn überhaupt mit deConz/Phoscon funktioniert? Bisher habe ich meinen Schalter (2-polig) über ein Shelly 2.5 eingebunden, wollte aber unbedingt weg von diesem WLAN-Modul und gleich auf Zigbee setzen.

Gibt's irgendwas was ich übersehen, irgendwelche Erfahrungen mit dem Modul? Ich wäre für jede Hilfe dankbar und bin auch experimentierfreundig, wenn es helfen sollte.

Danke schon mal!

Edit 1:

Im ioBroker werden mir die Datenpunkte angezeigt, aber es scheint nichts zu triggern.

Was mir auch aufgefallen ist: im Phoscon kann ich kein "Tastendruck" und "Gehaltene Taste" konfigurieren, obwohl man in den Datenpunkten sieht, dass diese irgendwie unterschieden werden. Die "Haltezeit" kann natürlich nicht konfiguriert werden, was auch irgendwie schade ist.

Aber irgendwie ist das für mich noch ein durchwachsenes Ergebnis, denn einmal zu lange am Taster und es funktioniert somit nichtmehr wirklich. Phoscon führt die Schaltvorgänge jetzt zwar aus, aber es ist irgendwie ein wenig Glücksache, ob man kurz genug getastet hat.

Und in der deconz-gui sehe ich das Modul noch immer nicht ... :-(((

@homoran said in VIS: Keine gültige Lizenz gefunden:

@soundy sagte in VIS: Keine gültige Lizenz gefunden:

Die Hardware ist aber komplett gleich geblieben

aber nach

@soundy sagte in VIS: Keine gültige Lizenz gefunden:

der Neuinstallation

Hat dein iobroker eine andere UUID. Daran ist die Lizenz gebunden

Die gekaufte Lizenz ist also unbrauchbar und müßte neu gekauft werden, oder wie darf man das verstehen?

@sigi234

Danke, funktioniert wieder.

Nur das die (gekaufte) "iobroker.vis.offline" Lizenz nach der Neuinstallation auf dem selben Gerät nichtmehr gültig ist. Die Hardware ist aber komplett gleich geblieben ... Hmmm, muss ich mich da an "info at iobroker.net" wenden? Direkt einen Support hab ich nicht gefunden.

Edit:
Ich helfe mir vorerst mit der "Free Lizenz", da das Gerät ohnehin online ist....