CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Moderator: Co-Administratoren
- Henke
- Beiträge: 1543
- Registriert: 27.06.2022, 20:51
- System: CCU
- Hat sich bedankt: 144 Mal
- Danksagung erhalten: 315 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
@gnom
Das war das Beispiel, das ich für nicht optimal halte. Der 1PM geht definitiv über command ohne rpc.
@Tenoba
rpc aus, "MQTT Control" ein, speichern, Shelly reboot und bitte nochmal testen.
Ich würde den Pfad noch mit "shellies/" erweitern, damit alle kommmenden Shellys in einer Gruppe sind. "shellies/" ist der Standart bei älteren Geräten.
Das war das Beispiel, das ich für nicht optimal halte. Der 1PM geht definitiv über command ohne rpc.
@Tenoba
rpc aus, "MQTT Control" ein, speichern, Shelly reboot und bitte nochmal testen.
Ich würde den Pfad noch mit "shellies/" erweitern, damit alle kommmenden Shellys in einer Gruppe sind. "shellies/" ist der Standart bei älteren Geräten.
- gnom
- Beiträge: 357
- Registriert: 23.06.2022, 05:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Brühl
- Hat sich bedankt: 28 Mal
- Danksagung erhalten: 60 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Möchte ja gar nicht wiedersprechen
Habe mich auch gewundert, da die anderen Shellys ja so gesteuert werden.
Frage mich auch, was der Grund ist, dass Mathias das bei diesen jetzt so gemacht hat. Kann das aber mangels Gerät mit original FW nicht selber nachvollziehen - lerne ja auch gerne dazu
Gruss, Chris
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Ohne Erfolg.rpc aus, "MQTT Control" ein, speichern, Shelly reboot und bitte nochmal testen.
Inzwischen habe ich auch enorm viele COMMAND_TOPIC, ON_PAYLOAD und OFF_PAYLOAD Varianten ausprobiert; alle negativ.
hier nochmal ein Stand:
"MQTT Control" AN
"Enable RPC over MQTT" AUS
"RPC status notifications over MQTT" AN
"Generic status update over MQTT" AN
COMMAND_TOPIC
shelly1pmminig3-84fce63b7210/switch:0/0/command
ON_PAYLOAD
on
OFF_PAYLOAD
off
Dasselbe Ergebnis mit
"MQTT Control" AUS
"Enable RPC over MQTT" AN
"RPC status notifications over MQTT" AN
"Generic status update over MQTT" AN
oder relay statt switch:0 im Command Topic
oder true / false statt on / off in den Payloads
oder "output":true / false in den Payloads
oder auch ganz abgewandelte Payloads wie z.B. {"src":"shelly1pmminig3-84fce63b7210","dst":"shelly1pmminig3-84fce63b7210/events","method":"Switch.set","params":{"switch:0":{"id":0,"apower":0,"current":0,"on":false}}}
allesamt erfolglos.
- gnom
- Beiträge: 357
- Registriert: 23.06.2022, 05:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Brühl
- Hat sich bedankt: 28 Mal
- Danksagung erhalten: 60 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
wir möchten ja gerne helfen, nur ist das jetzt sehr unübersichtlich und nicht mehr nachvollziehbar, was genau wie gemacht wurde.
Das Dingens sollte sich doch schalten lassen.
Vorschlag:
für eine der beiden Vorgehensweisen (die von Henke oder die im WIKI)
1. SC der MQTT Einstellung im Gerät
2. alle MQTT Topics zu dem Gerät
3. die vollständig lesbaren Einstellungen des Schaltaktors in der CCU,
dann Schritt für Schritt
Das Dingens sollte sich doch schalten lassen.
Vorschlag:
für eine der beiden Vorgehensweisen (die von Henke oder die im WIKI)
1. SC der MQTT Einstellung im Gerät
2. alle MQTT Topics zu dem Gerät
3. die vollständig lesbaren Einstellungen des Schaltaktors in der CCU,
dann Schritt für Schritt
Gruss, Chris
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
- Baxxy
- Beiträge: 11064
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 634 Mal
- Danksagung erhalten: 2293 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Ich würde den Jack erstmal außen vor lassen und direkt mittels MQTT-Explorer (per Publish) versuchen das korrekte Topic/Command zum EIN/AUSschalten zu finden.
Die Frage wäre auch ob sich die Api von Gen 2 zu Gen 3 überhaupt geändert hat.
Zumindest gibt es noch keine "Gen 3 Device API" - Dokumentation.
Anhand der >> Gen 2 Device API << würde ich sagen das Topic/Command müsste etwa so aussehen:
Die Frage wäre auch ob sich die Api von Gen 2 zu Gen 3 überhaupt geändert hat.
Zumindest gibt es noch keine "Gen 3 Device API" - Dokumentation.
Anhand der >> Gen 2 Device API << würde ich sagen das Topic/Command müsste etwa so aussehen:
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- Henke
- Beiträge: 1543
- Registriert: 27.06.2022, 20:51
- System: CCU
- Hat sich bedankt: 144 Mal
- Danksagung erhalten: 315 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Nope
shelly1pmminig3-84fce63b7210/relay/0/command
So kann man das direkt im MQTT-Explorer testen: Achtung: Ich hatte noch deinen falschen Wert im Copy/Past
Bei Topic nimm den Richtigen. switch:0 gibt es definitiv nicht.
switch:0 gibt es.
Der mini ist ein Gen2 Device.
Daher dürfte die Doku passen: https://shelly-api-docs.shelly.cloud/ge ... tt-control
Und damit:
COMMAND_TOPIC: shelly1pmminig3-84fce63b7210/switch:0
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Klasse Baxxy, das hat geklappt!Baxxy hat geschrieben: ↑23.12.2023, 20:15Ich würde den Jack erstmal außen vor lassen und direkt mittels MQTT-Explorer (per Publish) versuchen das korrekte Topic/Command zum EIN/AUSschalten zu finden.
Die Frage wäre auch ob sich die Api von Gen 2 zu Gen 3 überhaupt geändert hat.
Zumindest gibt es noch keine "Gen 3 Device API" - Dokumentation.
Anhand der >> Gen 2 Device API << würde ich sagen das Topic/Command müsste etwa so aussehen:
Shelly_Mqtt.JPG
Ich fasse hier meine Lösung für den 1PM Mini Gen3 zusammen:
Shelly MQTT Konfiguration: CCU Konfiguration: COMMAND_TOPIC shelly1pmminig3-XXXX/command/switch:0
ON_PAYLOAD on
OFF_PAYLOAD off
FEEDBACK_TOPIC shelly1pmminig3-XXXX/status/switch:0
ON_PATTERN "output":true
OFF_PATTERN "output":false
MATCHER CONTAINS
Danke an alle, die mitgetüftelt haben und insbesondere natürlich an Mathias für das Tool und die Anleitung.
Schöne Weihnachten zusammen.
Gruß, Tenoba
- gnom
- Beiträge: 357
- Registriert: 23.06.2022, 05:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Brühl
- Hat sich bedankt: 28 Mal
- Danksagung erhalten: 60 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
na dann, happy switching
PS: die topics shelly1pmminig3-XXXX/command/switch:0 sowie shelly1pmminig3-XXXX/status/switch:0 sollten aber auch im MQTT explorer auftauchen, oder?
PS: die topics shelly1pmminig3-XXXX/command/switch:0 sowie shelly1pmminig3-XXXX/status/switch:0 sollten aber auch im MQTT explorer auftauchen, oder?
Gruss, Chris
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
- Henke
- Beiträge: 1543
- Registriert: 27.06.2022, 20:51
- System: CCU
- Hat sich bedankt: 144 Mal
- Danksagung erhalten: 315 Mal
-
- Beiträge: 64
- Registriert: 03.09.2019, 19:51
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 1 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Guten Morgen zusammen,
Dank eures Threads hier habe ich es hinbekommen mit CCU-Jack einen Shelly 1 Plus zum Ein/Aus Schalten zu bringen
Was ich nicht hinbekomme, das sich der Schalt Zustand Aus/Ein ändert.
Wie hier beschrieben habe ich
gesetzt.
In der HM nach Übernehmen sieht das so aus bei mir Wie gesagt Schalten geht, nur zeigt er mir das in Hm nicht an.
Der Status im MQTT-Explorer ändert sich.
Wäre über jeden Tipp dankbar.
Gruß
Frank
Dank eures Threads hier habe ich es hinbekommen mit CCU-Jack einen Shelly 1 Plus zum Ein/Aus Schalten zu bringen
Was ich nicht hinbekomme, das sich der Schalt Zustand Aus/Ein ändert.
Wie hier beschrieben habe ich
gesetzt.
In der HM nach Übernehmen sieht das so aus bei mir Wie gesagt Schalten geht, nur zeigt er mir das in Hm nicht an.
Der Status im MQTT-Explorer ändert sich.
Wäre über jeden Tipp dankbar.
Gruß
Frank