NEWS
Test Adapter shelly - ALPHA Versionen
-
@fuzzy1955 Ne, wozu? Der Adapter arbeitet nur per RPC
-
@mcm1957 das kam jetzt durch die ganzen Tests. Aktuell sind diese auf Port 1888. Aber ich habe den Übeltäter gefunden. Es ist der MQTT Adapter. Dieser läuft aber auf einen anderen Port. Ich werde das einmal weiter einkreisen. Ich habe meine Einbindung des EVCC Server in Verdacht. Das ist das letzte, was ich in letzter Zeit in MQTT eingebunden habe. So zeitlich könnte das hinhauen
-
@gelberlemmy sagte in Test Adapter shelly - ALPHA Versionen:
@mcm1957 das kam jetzt durch die ganzen Tests. Aktuell sind diese auf Port 1888. Aber ich habe den Übeltäter gefunden. Es ist der MQTT Adapter. Dieser läuft aber auf einen anderen Port. Ich werde das einmal weiter einkreisen. Ich habe meine Einbindung des EVCC Server in Verdacht. Das ist das letzte, was ich in letzter Zeit in MQTT eingebunden habe. So zeitlich könnte das hinhauen
So ist der EVCC-Server über den MQTT Adapter. Was auch immer dieser macht. Dieser muss ja über die Ports hinweg irgend etwas zu streuen….. Werde dies einmal bei EVCC als Bug melden. Habe diesen jetzt abgeschaltet und den MQTT Adapter wieder gestartet mit den restlichen Geräten. Läuft alles wieder. Danke für Euren Support
-
Da du EVCC offenbar kennst (siehe YouTube Video
) hast du eine Idee was da ev. an der EVCC EInstellung faksch sein kann sodass der Shelly Adapter Probleme bekommt?
-
@mcm1957 ich habe ein wenig geschaut. Ich habe einen direkten EVCC Adapter von Github installiert. Und jetzt läuft wieder alles. Also nicht den Umweg über MQTT
-
@gelberlemmy Der arbeitet doch sogar per HTTP und nicht per MQTT, oder? Sehe da keinen Zusammenhang. Zufall
-
@haus-automatisierung ja genau. Der Bezug war ja, dass ich EVCC über den MQTT Adapter abgefragt habe. Dies brauche ich ja jetzt nicht mehr mit dem passenden EVCC Adapter. Somit ist das Problem mit dem Shelly Adapter ja für mich gelöst. Wobei das schon merkwürdig war, das der Shelly Adapter da wirklich Probleme gemacht hat, als ich die Daten von EVCC per MQTT Adapter abgefragt habe. Und das noch auf einen ganz anderen Port.
-
@gelberlemmy sagte in Test Adapter shelly - ALPHA Versionen:
Der Bezug war ja, dass ich EVCC über den MQTT Adapter abgefragt habe.
Aber auch der läuft ja dann auf einem ganz anderen Port als der Shelly-Adapter. Die beiden wissen gar nichts voneinander.
-
@haus-automatisierung das ist ja das verwirrende. Ich habe noch mehr Geräte über MQTT…. Alles kein Problem. Aber wenn ich in EVCC die MQTT Daten eintrage fängt der Shelly Adapter an zu spinnen. Warum auch immer.
️
-
@haus-automatisierung sagte in Test Adapter shelly - ALPHA Versionen:
Ne, wozu? Der Adapter arbeitet nur per RPC
Das begreife ich nicht. Bei mir wirft der Shelly-Adapter sofort Fehler und geht offline, wenn ich die Option Enable 'MQTT Control' weglasse. Was steckt da dahinter?
shelly.0 2025-06-05 21:29:41.557 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:31.556 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:21.516 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:14.637 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:12.973 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:11.585 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:11.516 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:09.781 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:07.797 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:05.941 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:04.695 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:02.598 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:29:01.513 warn [mqtt controlFunction] Unable to perform request - device (undefined / undefined / undefined) is offline shelly.0 2025-06-05 21:28:52.386 info [MQTT] Client Close: (shellyplusplugs / shellyplusplugs-e465b8b35bdc / shellyplusplugs#e465b8b35bdc#1) (false) shelly.0 2025-06-05 21:28:52.367 error [MQTT] Wrong MQTT authentification of client "shellyplusplugs-e465b8b35bdc"
-
@mcm1957 said in Test Adapter shelly - ALPHA Versionen:
@peter-v
ein mqtt user und passwort wird IMMER benötigt.Ich meinte ja auch für Authentifizierung, sprich Shelly-Passwort.
Hab mich vielleicht nicht klar genug ausgedrückt -
@fuzzy1955 sagte in Test Adapter shelly - ALPHA Versionen:
Das begreife ich nicht. Bei mir wirft der Shelly-Adapter sofort Fehler und geht offline, wenn ich die Option Enable 'MQTT Control' weglasse. Was steckt da dahinter?
Die Option wurde mal eingeführt, um die neueren Geräte mit den gleichen Topics ansteuern zu können wie die Generation 1 Geräte. Das macht der Adapter aber wie gesagt gar nicht und die Option spielt keine Rolle für die Zusammenarbeit mit ioBroker. Siehe Doku
-
@mcm1957
kannst du dir das bitte noch anschauen
Geht um das Ogemray Relais@stenmic sagte in Test Adapter shelly - ALPHA Versionen:
@mcm1957
ich hab es mal gefilmt...
https://www.dropbox.com/scl/fi/0nivazrw1yoztq74dbj2t/Ogemray.mp4?rlkey=dlh6iy8wdgu7hngofgtrk695q&st=7wna1c2m&dl=0Shelly.GetStatus AN
{ "ble": {}, "bthome": { "errors": [ "bluetooth_disabled" ] }, "cloud": { "connected": false }, "input:0": { "id": 0, "state": false }, "knx": {}, "mqtt": { "connected": true }, "switch:0": { "id": 0, "source": "WS_in", "output": true, "apower": 0.0, "voltage": 237.9, "freq": 50.0, "current": 0.0, "aenergy": { "total": 0.0, "by_minute": [ 0.0, 0.0, 0.0 ], "minute_ts": 1748490540 }, "temperature": { "tC": 33.4, "tF": 92.2 } }, "sys": { "mac": "B08184E1xxx", "restart_required": false, "time": "05:49", "unixtime": 1748490572, "last_sync_ts": 1748490152, "uptime": 423, "ram_size": 252528, "ram_free": 126080, "ram_min_free": 112252, "fs_size": 1048576, "fs_free": 593920, "cfg_rev": 14, "kvs_rev": 0, "schedule_rev": 0, "webhook_rev": 0, "btrelay_rev": 0, "available_updates": {}, "reset_reason": 1, "utc_offset": 7200 }, "wifi": { "sta_ip": "xxxx", "status": "got ip", "ssid": "xxxx", "rssi": -50, "sta_ip6": [ "fe80::b281:84ff:fee1:deb4", "2003:d5:a73e:7800:b281:84ff:fee1:deb4", "fdf9:2cf3:d0b7:0:b281:84ff:fee1:deb4" ] }, "ws": { "connected": false } }
Shelly.GetStatus AUS
{ "ble": {}, "bthome": { "errors": [ "bluetooth_disabled" ] }, "cloud": { "connected": false }, "input:0": { "id": 0, "state": false }, "knx": {}, "mqtt": { "connected": true }, "switch:0": { "id": 0, "source": "MQTT", "output": false, "apower": 0.0, "voltage": 237.9, "freq": 50.0, "current": 0.0, "aenergy": { "total": 0.0, "by_minute": [ 0.0, 0.0, 0.0 ], "minute_ts": 1748490480 }, "temperature": { "tC": 32.9, "tF": 91.2 } }, "sys": { "mac": "B08184E1xxx", "restart_required": false, "time": "05:48", "unixtime": 1748490518, "last_sync_ts": 1748490152, "uptime": 369, "ram_size": 252540, "ram_free": 125912, "ram_min_free": 112252, "fs_size": 1048576, "fs_free": 593920, "cfg_rev": 14, "kvs_rev": 0, "schedule_rev": 0, "webhook_rev": 0, "btrelay_rev": 0, "available_updates": {}, "reset_reason": 1, "utc_offset": 7200 }, "wifi": { "sta_ip": "xxx", "status": "got ip", "ssid": "xxx", "rssi": -51, "sta_ip6": [ "fe80::b281:84ff:fee1:deb4", "2003:d5:a73e:7800:b281:84ff:fee1:deb4", "fdf9:2cf3:d0b7:0:b281:84ff:fee1:deb4" ] }, "ws": { "connected": false } }
Meine anderen Shellys laufen ohne Probleme.
-
@stenmic
Leg bitte ein Issue dazu an
Un dleg dort auch den DEBUG Log ab.Leider komm ich (urlaubsbedingt) die nächsten Wochen kaum dazu da was zu suchen.
-
@mcm1957
schade, ich bin auf github nicht wirklich unterwegs.
Ich werde das wohl ohne den Adapter mit mqtt lösen.
Aber kein Problem. -
@stenmic
OK - wenn du nicht auf GH unterwegs bist solls daran nicht scheitern. Ich erstell das Issue dann mal selbst.Aber BITTE erstell ein log mit Level DEBUG und legs hier ab. Wir müssen wissen, was da wann reinkommt. Sollte das Ogemray die Änderungen slebst stark verzögert schicken (was derzeit nicht geklärt ist) dann kann das der Adapter nicht 'aufholen'.
Es wär also schön den Ablauf zu sehen:
- Adapter schaltet auf ein
- Ogemray bestätigt / meldet Status ein
usw ...
-
Ich hab mir heute dein Video nochmal angesehen. Das sieht eigentlich fast so aus als würde das SIgnal genau invertiert kommen. Kannst du mal bestätigen, dass die Anzige in der Shelly App und das physikalische Relais übereinstimmen? Sprich bleuer Krei ind er App == Relais geschlossen?
Und wenn ich hier nichts übersehen habe hast du bisher kein DEBUG log gepostet. Ev. kannsgt du noch ein Video machen wo man auch das Log gleichzeitig sieht? Und bitte anschließend das Log posten.
Wenn du auch bzw. mit dem MQTT Adapter arbeitest kannst du dort mal schaun was da in den Topics daher kommt wenn du ein / ausschaltest?
Aus dem Bauch heraus tippe ich auf einen Fehler in der Relais-SW. ABER ohne genauere Eingrenzung will ich einen Fehler nicht abschieben...
-
@mcm1957 sagte in Test Adapter shelly - ALPHA Versionen:
Das sieht eigentlich fast so aus als würde das SIgnal genau invertiert kommen.
Hoffe mal, dass am Ende nicht einfach nur der Ausgang in der Shelly-Konfiguration invertiert wurde?!
-
Hoffe mal, dass am Ende nicht einfach nur der Ausgang in der Shelly-Konfiguration invertiert wurde?!
Wo wäre das einzustellen?
Und würde das nicht "nur" das Relais inverteieren - spich Relais offn wenn in der Shelly App der blaue Ring 'on' signalisiert?Das Video scheint eine invertierung ziwschen ioBroker und Shelly anzuzeigen:
https://www.dropbox.com/scl/fi/0nivazrw1yoztq74dbj2t/Ogemray.mp4?rlkey=dlh6iy8wdgu7hngofgtrk695q&st=7wna1c2m&dl=0Der Switch in ioBroker springt praktisch sofort - aber auf die falsche Position...
Allerdings schreibt @@stenmic auch:
Jetzt nochmal gewartet.
Also der "Switch" im Adapter wird aktualisiert, jedoch extrem Zeitverzögert.Da hab ich keine Info bekommen (oder sie übersehen) was das nun GENAU heißt.
siehe auch:
https://forum.iobroker.net/topic/80649/test-adapter-shelly-alpha-versionen/63
https://forum.iobroker.net/topic/80649/test-adapter-shelly-alpha-versionen/65Ich denke ohne synchronisiertes DEBUG Log wird es da schwer was zu klären.
-
@haus-automatisierung sagte in Test Adapter shelly - ALPHA Versionen:
@mcm1957 sagte in Test Adapter shelly - ALPHA Versionen:
Das sieht eigentlich fast so aus als würde das SIgnal genau invertiert kommen.
Hoffe mal, dass am Ende nicht einfach nur der Ausgang in der Shelly-Konfiguration invertiert wurde?!
Da is nix invertiert.
Der Zustand im ioBroker wird ja korrekt aktualisiert, jedoch mit Verzögerung.Hier gut zu sehen:
https://www.dropbox.com/scl/fi/s10co960ltaybh3q0xhjh/verz-gerung.mp4?rlkey=hjvw59ks6ary6hwx9wtc023lw&st=v3mep9ve&dl=0Debug kommt noch