Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten
-
@mehrwiedu sagte in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Steht denn da drin, wie ich einen Datenpunkt wie den RPC mittels ioBroker eigenen Mitteln beschicken kann?
Keine Ahnung, ich weiß nicht warum du nicht den Shelly Adapter nimmst, da hast du doch alles fertig an Datenpunkten vorliegen und er holt die Daten ja auch zuverlässig mit Mqtt.
-
Ok, ich habe nun herausgefunden, warum der Dimmer Gen 3 nicht im Shelly Adapter aufgetaucht ist.
Die Instanz vom Shelly Adapter hat von jeher als Protokoll MQTT und HTTP in den allgemeinen Einstellungen gehabt.
Offensichtlich funktionieren beide Instanzen nicht parallel zueinander, wenn "Shelly" auch das MQTT Protokoll nutzt um mit den Shellys zu kommunizieren. Ist mir bei den Gen 1 Geräten nie wirklich aufgefallen. Ich habe die Objekte der Shelly Instanz wenig genutzt und alles mit dem MQTT Instanz Objekten geregelt.
Da beide Instanzen (Shelly und MQTT als Broker) Benutzer und Passwort, sowie identische Ports auf der IP vom ioBroker haben, gibt es offensichtlich Konflikte, die dazu führen, dass der Dimmer Gen 3 nun als einziges Gerät in der Shelly Instanz nicht aufgetaucht ist.
Das geht dann wohl eher in das tiefere Wissen über das MQTT Protokoll, was ich nicht habe.
Stand aktuell ist also, dass der Dimmer Gen 3 sehr wohl in der Shelly Instanz gefunden wird und auch alle Datenpunkte liefert, aber nicht gleichzeitig im MQTT Adapter auftauchen darf. Ist das tatsächlich nicht möglich? Ich dachte ein Client dürfe von jeglichem Broker empfangen und wahlweise bedient werden. Hab ich zumindest in der Vergangenheit mit den Shelly Gen 1 ja so gehabt.
Nun aber nochmal zum Kern meiner Frage.
Ich habe nie wirklich mit dem Shelly Adapter gearbeitet, sondern alles über den MQTT Adapter gemacht.
Dort taucht aber wie oben beschrieben dieser RPC Datenpunkt auf. Ich bin auch mit JSON nicht vertraut und weiß nicht, wie ich das nun schalten sollte. So nen Toggle Switch gibts da ja nicht.Und eigentlich wollte ich auf eine native Installation in einem LXC von Proxmox auch Mosquitto zukünftig verwenden, damit ich ein wenig unabhängiger werde. Dafür würde ich eventuell auch von deConz auf ZigbeeIIMQTT wechseln wollen.
Ich bin aber ehrlich: Wenn das nicht in meinen Schädel passt und ich tatsächlich wie gerade eben wie der Ochs vorm Berg stehe und die Zusammenhänge nur so zäh begreife und es am Ende immer noch nicht erklären kann, dann lass ich das auch lieber und stricke alles um zum Shelly Adapter. MQTT habe ich aktuell nur für die Shelly Geräte. Die Tasmota sind im Sonoff Adapter. Und mehr gibts bei mir nicht. -
@mehrwiedu hättest du mal die Doku. gelesen die ich oben verlinkt habe.
Bei Json bin raus hier. Weiterhin viel Erfolg
Grüße
Fabio -
@fabio sagte in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
@mehrwie hättest du Doko gelesen dir ich verlinkt habe.
Ok, vielleicht ist das jetzt frech von mir, aber ich kann die Doku noch 10x lesen und habe sie dann insgesamt 20x gelesen. Ich bin zu doof den Zusammenhang zu verstehen.
Ich weiß nicht, auch aufgrund der fachlichen Sprache in dieser Doku, wo übersetzt steht: Mach nur Shelly Adapter an, denn mit MQTT Adapter gleichzeitig gibt das Probleme. Ich bitte hier um Unterstützung in meinem Verständnis zu den sehr technischen Zusammenhängen. Und nochmal...mir fällt das nicht wirklich leicht.
Warum genau ein Client wie der Shelly Dimmer Gen 3 jetzt nur Daten an einen Broker liefert, der ja im Grunde nur zuhört und nichts weiter tut, verstehe ich halt rein technisch nicht. Wo ist da die Reglementierung. Ich habe die Einstellung MQTT und HTTP in dem Shelly Adapter seit Jahren so stehen und die Einstellungen im MQTT Adapter sind ebenfalls seit Anfang an so eingestellt und nie geändert worden. Die Datenpunkte im Shelly Adapter und im MQTT Adapter sind bei jedem Shelly der dazu gekommen ist, neu erstellt worden.
Dann war, wenn das grundsätzlich nicht so vorgesehen ist vom MQTT Protokoll bei mir ja seit 6 Jahren schon was schief.
Und das möchte ich nun einfach verstehen. Ich bin niemand, der jeden Tag vor dem ioBroker sitzt. Ich habe da bis auf Aktualisierungen auch mal Jahre dazwischen, wo ich dafür keinen Finger rühre. Ich bin ausschließlich Anwender. Sorry dafür. -
@fabio sagte in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Keine Ahnung, ich weiß nicht warum du nicht den Shelly Adapter nimmst, da hast du doch alles fertig an Datenpunkten vorliegen und er holt die Daten ja auch zuverlässig mit Mqtt.
Weil ich meine Zigbee Geräte zukünftig auch gerne an Mqtt übergeben würde.
-
@mehrwiedu said in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Ok, ich habe nun herausgefunden, warum der Dimmer Gen 3 nicht im Shelly Adapter aufgetaucht ist.
Die Instanz vom Shelly Adapter hat von jeher als Protokoll MQTT und HTTP in den allgemeinen Einstellungen gehabt.
Das ist normal
Offensichtlich funktionieren beide Instanzen nicht parallel zueinander, wenn "Shelly" auch das MQTT Protokoll nutzt um mit den Shellys zu kommunizieren. Ist mir bei den Gen 1 Geräten nie wirklich aufgefallen. Ich habe die Objekte der Shelly Instanz wenig genutzt und alles mit dem MQTT Instanz Objekten geregelt.
Die Aussage ist falsch. Natürlich funktioniert der MQTT Adapter einwandfrei neben dem Shelly Adapter sowohl mit einer Instanz der Shelly Adapters die MQTT spricht als auch einer Shelly Instanz die COAP spricht.
Da beide Instanzen (Shelly und MQTT als Broker) Benutzer und Passwort, sowie identische Ports auf der IP vom ioBroker haben, gibt es offensichtlich Konflikte, die dazu führen, dass der Dimmer Gen 3 nun als einziges Gerät in der Shelly Instanz nicht aufgetaucht ist.
Der Shelly Adpater hat per default einen ANDEREN Port. Wenn du den natürlcih ident zum mqtt Adapter einstellst hast du selbst ein Problem geschaffen dass per Default gar nicht existister
Das geht dann wohl eher in das tiefere Wissen über das MQTT Protokoll, was ich nicht habe.
Nö - das Ports haben was mit dem Netzwerk zu tun und nicht mit mqtt.
Stand aktuell ist also, dass der Dimmer Gen 3 sehr wohl in der Shelly Instanz gefunden wird und auch alle Datenpunkte liefert, aber nicht gleichzeitig im MQTT Adapter auftauchen darf. Ist das tatsächlich nicht möglich? Ich dachte ein Client dürfe von jeglichem Broker empfangen und wahlweise bedient werden. Hab ich zumindest in der Vergangenheit mit den Shelly Gen 1 ja so gehabt.
Nein - ein Shelly kann nur mit EINEM mqtt Broker sprechen da die Shellies nicht mehrerer mqtt Verbindungen unterstützen. Also entweder konfigurierst du den Port des Shelly Adapters ODER den Port deines mqtt Brokers. Wie oben geschrieben und auch per Default eingestell sind die Ports per default unterschiedlich. Eine ausführliche Beschreibung gibts in der shelly Adapter Dokumentation.
Nun aber nochmal zum Kern meiner Frage.
Ich habe nie wirklich mit dem Shelly Adapter gearbeitet, sondern alles über den MQTT Adapter gemacht.
Dort taucht aber wie oben beschrieben dieser RPC Datenpunkt auf. Ich bin auch mit JSON nicht vertraut und weiß nicht, wie ich das nun schalten sollte. So nen Toggle Switch gibts da ja nicht.Wenn du den Shelly zu Fuß bedienen willst musst du dich in die Shelly API Dokumentation (https://shelly-api-docs.shelly.cloud/) einlesen und auch ein wenig Wissen zu mqtt kann da nicht schaden. Der Shelly Adapter kommuniziert in Richtung ZUM Shelly tw. via mqtt und tew. via HTTP.
Und eigentlich wollte ich auf eine native Installation in einem LXC von Proxmox auch Mosquitto zukünftig verwenden, damit ich ein wenig unabhängiger werde. Dafür würde ich eventuell auch von deConz auf ZigbeeIIMQTT wechseln wollen.
Da bin ich außen vor und kann nichts konstruktiv dazu sagen.
Ich bin aber ehrlich: Wenn das nicht in meinen Schädel passt und ich tatsächlich wie gerade eben wie der Ochs vorm Berg stehe und die Zusammenhänge nur so zäh begreife und es am Ende immer noch nicht erklären kann, dann lass ich das auch lieber und stricke alles um zum Shelly Adapter. MQTT habe ich aktuell nur für die Shelly Geräte. Die Tasmota sind im Sonoff Adapter. Und mehr gibts bei mir nicht.
-
@mehrwiedu said in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Ich weiß nicht, auch aufgrund der fachlichen Sprache in dieser Doku, wo übersetzt steht: Mach nur Shelly Adapter an, denn mit MQTT Adapter gleichzeitig gibt das Probleme. Ich bitte hier um Unterstützung in meinem Verständnis zu den sehr technischen Zusammenhängen. Und nochmal...mir fällt das nicht wirklich leicht.
Was meinst du mit übsersetzt steht ..
Die Doku des Shelly Adapters ist auch auf DEUTSCH verfügbar:
https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/README.mdWenn da wo so was krummes steht mach bite ein Issue auf.
Warum genau ein Client wie der Shelly Dimmer Gen 3 jetzt nur Daten an einen Broker liefert, der ja im Grunde nur zuhört und nichts weiter tut, verstehe ich halt rein technisch nicht. Wo ist da die Reglementierung. Ich habe die Einstellung MQTT und HTTP in dem Shelly Adapter seit Jahren so stehen und die Einstellungen im MQTT Adapter sind ebenfalls seit Anfang an so eingestellt und nie geändert worden. Die Datenpunkte im Shelly Adapter und im MQTT Adapter sind bei jedem Shelly der dazu gekommen ist, neu erstellt worden.
KEIN Shelly kann mehr als eine mqtt Verbindung aufbauen - auch kein Shelly GEN1. Der einzige Untersschied ist, dass Shelly GEN 1 da Protokoll COAP unterstützen und der Shelly Adapter GEN1 Devices via COAP anspricht und gar kein mqtt benutzt.
Dann war, wenn das grundsätzlich nicht so vorgesehen ist vom MQTT Protokoll bei mir ja seit 6 Jahren schon was schief.
Und das möchte ich nun einfach verstehen. Ich bin niemand, der jeden Tag vor dem ioBroker sitzt. Ich habe da bis auf Aktualisierungen auch mal Jahre dazwischen, wo ich dafür keinen Finger rühre. Ich bin ausschließlich Anwender. Sorry dafür.Da gibts nichts was ein sorry auslösen sollte.
Wenn gewunschen kann ich das gener nochmal zusammenfassen:
Shelly GEN1 sprechen COAP und MQTT. Der Shelly Adapter benutzt für GEN 1 Geräte COAP oder MQTT je nachdem was du in der Instanz eingestellt hast. Empfohlen ist COAP.
Shelly GEN2++ spechen nur mehr MQTT und der Shelly Adapter benutzt nur MQTT für GEN2++ Geräte
Ein Shelly kann via MQTT nur mit einem Broker verbiunden sein, also entweder mit einem mqtt Broker (z.B. mqtt Adpater) ODER dem Shelly Adapter.
2 Instanzen (egal ob von einem Adapter oder mehreren) können NIEMALS Daten auf demselben Port empfangen. Der mqtt Adapetr und der Shelly Adapter im mqtt Modus müssen daher auf unterschiedliche Ports konfiguriert sein. Das sind sie auch per Default. Sollten sie versuchen denselben Port zu benutzen wird der erste gewinnen - beim zweiten Adapter wird eine Fehlermeldung im Log stehen.
-
@mehrwiedu said in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Weil ich meine Zigbee Geräte zukünftig auch gerne an Mqtt übergeben würde.
Das ist im Prinzip erst mal unabhängig. Du kannst natürlich einen mqtt Broker parallel zum Shelly Adapter (auf getrennten Ports) betreiben.
Und es ist auch nicht verboten Shellies an den mqtt Adapter zu binden. Du musst dann halt nur die Kommunikation selbst aufbauen und in der Shelly Doku nachlesen was du wie zu senden hast. Ich kann nur beim Shelly Adapter Hilfe anbieten. Ich rate aber explizit nicht vom mqtt Adapter ab wenn jemand lieber selbst mit mqtt arbeitet.
-
Vielen Dank erstmal für Deine ausführlichen Antworten.
Jetzt, da ich ein paar Tage Zeit hatte mein Setup noch einmal durchzuschauen und auch zu verstehen, was ich damals gemacht habe, wirkt meine Frage oben ziemlich durcheinander und überhaupt nicht fachlich ausreichend von mir im Vorfeld recherchiert.Darüber hinaus hatte ich zu diesem Zeitpunkt ein wenig zu viele Einflüsse parallel, die rückblickend betrachtet nicht förderlich waren um die Quereinflüsse zu verstehen.
Nun bin ich schrittweise vorgegangen und habe zunächst erstmal für mich verstanden, was ich damals überhaupt gemacht hatte. Und da war sicher auch einiges dabei, was damals aus einem try and error entstand. So hatte ich bis dato alle Shellys der Gen 1 an den MQTT Adapter gebunden und den Shelly Adapter aus mir nicht mehr bekannten Gründen gar nicht genutzt.
Der Dimmer Gen 3 sprach aber nun mit dem MQTT Adapter in einer Sprache, die ich nicht verstanden habe. Nicht wie mit den Gen 1 Geräten. Warum das so ist, ist mir nun klar. Und der Shelly Adapter hatte bei meinen ersten Versuchen eine falsche Einstellung für den Gen 3 Dimmer, da er auf CoAP (und HTTP) eingestellt war. Nach der Umstellung auf MQTT (und HTTP) funktioniert nun alles wie es sollte.
@mcm1957 sagte in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Shelly GEN1 sprechen COAP und MQTT. Der Shelly Adapter benutzt für GEN 1 Geräte COAP oder MQTT je nachdem was du in der Instanz eingestellt hast. Empfohlen ist COAP.
An dieser Stelle wirft sich mir die Frage auf, ob ich dann für die momentane "Mehrzahl" an Shelly Gen 1 Geräten die Einstellung im Shelly Adapter wieder auf CoAP (und HTTP) umstellen soll und für den Gen 3 Dimmer und eventuell weiter folgende Gen 2+ Geräte eine zweite Instanz des Shelly Adapters nutzen sollte, die dann auf MQTT (und HTTP) eingestellt ist?
Aktuell machen die Gen 1 Geräte keine Zicken über MQTT am Shelly Adapter. Gibt es einen Nachteil sie so zu lassen? Bezogen auf mein vor k. A. 6 Jahren eingerichtetes Setup haben sie die gesamte Zeit mit dem MQTT Adapter als Broker kommuniziert. Da hatte CoAP doch sicher keine Relevanz, oder?
Im Grunde nutze ich die Shelly Relais nur, damit meine Tradfri Bulbs in den Fassungen unter Strom stehen und damit ich diese über die Wandschalter weiterhin bedienen kann, und umgekehrt die nicht smarte Beleuchtung über den Wandschalter toggle, jedoch zusätzlich noch eine Sprachoption dafür habe.
Mit dem MQTT Adapter oder allgemein mit MQTT habe ich nichts weiter gemacht, als den Switch der Shellys in meinen Skripten abgegriffen und geschaltet. Ich bin glaube ich auch ein wenig von Mosquitto und Zigbee2Mqtt weg. Mir erschließt sich momentan kein Vorteil.
Die deConz Gruppen werden im Gegensatz zu den Zigbee2Mqtt Gruppen im Matter Adapter als HUE Lichter erkannt und meine Skripte benötige ich eh weiterhin um Zigbee Lampen/Gruppen zusammen mit Shelly Relais als Sprachbefehl gleichzeitig ein- oder auszuschalten. Außer ich bilde die Gruppe erst in Alexa, aber das möchte ich eigentlich nicht.
Ich glaube, ich wäre ohne die Obsoleszenz des alten IoT Skills gar nicht so tief wieder in meine Konfiguration abgetaucht. Mein ursprüngliches Ziel war eigentlich nur meine "virtuellen" Schalter auf ein Aqara Panel Hub S1 zu bekommen. Das habe ich nun mit dem Matter Adapter geschafft. Der nimmt alles, was ich ehemals dem IoTAdapter als Alexa Gerät übergeben habe in seine Bridge und gibt das zunächst an Aqara als Hub ab und den habe ich wiederum als Matter Gerät an Alexa weitergegeben. Das funktioniert aktuell prima. Somit habe ich in der ersten Stufe die Schalter alle in Aqara auf dem Panel Hub S1 zur Verfügung und in der zweiten Stufe kann ich alle Geräte aus dem Hub auch über Alexa Sprachbefehle steuern.
Ich war mir bisher nur nicht sicher, ob ich auch auf meine Skripte verzichten kann. Aber das wird weder mit IoT Skill, noch mit Matter Bridge gehen. Eine Gruppe aus Shelly Relais und Zigbee Lampe kriege ich wahrscheinlich vor der Übergabe an Alexa oder Matter in ioBroker nur über ein Skript gesteuert.
-
@mehrwiedu said in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
@mcm1957 sagte in Shelly Dimmer Gen 3 mqtt Verbindung Datenpunkte schalten:
Shelly GEN1 sprechen COAP und MQTT. Der Shelly Adapter benutzt für GEN 1 Geräte COAP oder MQTT je nachdem was du in der Instanz eingestellt hast. Empfohlen ist COAP.
An dieser Stelle wirft sich mir die Frage auf, ob ich dann für die momentane "Mehrzahl" an Shelly Gen 1 Geräten die Einstellung im Shelly Adapter wieder auf CoAP (und HTTP) umstellen soll und für den Gen 3 Dimmer und eventuell weiter folgende Gen 2+ Geräte eine zweite Instanz des Shelly Adapters nutzen sollte, die dann auf MQTT (und HTTP) eingestellt ist?
Aktuell machen die Gen 1 Geräte keine Zicken über MQTT am Shelly Adapter. Gibt es einen Nachteil sie so zu lassen? Bezogen auf mein vor k. A. 6 Jahren eingerichtetes Setup haben sie die gesamte Zeit mit dem MQTT Adapter als Broker kommuniziert. Da hatte CoAP doch sicher keine Relevanz, oder?
Shelly Gen 1 kannst du wie geschreiben entweder über mqtt oder über coap einbinden. Aus Sicht des Shelly Adapters ist beides zulässig und es gibt einen einzigen Nachteil: Wenn die Shellies der Gen 1 mit einem mqtt Broker verbunden sind - egal ob Shelly Adapter oder ein anderer Broker - dann können sie nicht gleichzeitig mit der Shelly Cloud verbunden sein. Ob das für dich eien Einschränkung bedeutet kann ich nicht sagen. Da aber deine Shelly Gen 1 derzeit via mqtt mit dem Shelly Adapter funktionieren spricht nichts dagegen das so zu lassen.
Und ja - wenn du COAP (für Gen 1) und MQTT (für Gen 2+) verwenden willst, brauchts du 2 Instanzen. Theoretisch könnte es bisher so gewesen sein, dass die Gen 1 via mqtt mit dem mqtt Adapter gesprochen haben udn gleichzeitig via coap mit dem Shelly Adapter. Ist aber reine Glaskugelbetrachtung und - wenn jetzt alles läuft wie du es willst - eher nebensächlich.
Hoffe ich konnte deine Fragen was Shelly betriff beantworten. Bezüglich Zigbee in allen Varianten sag ich nichts - da gibts kompetentere User / Devs.
-
Danke erneut für Deine hilfreiche Unterstützung.
Da ich den Shelly Adapter erst vor ein paar Tagen in Betrieb genommen habe, ist es eher unwahrscheinlich, dass die CoAP Einstellung der Shellys irgendwo im ioBroker von Nutzen war. Ich habe es jetzt auch so gelassen, da es nicht weh tut und in der Vergangenheit nicht weh getan hat. Ich sehe jetzt im Shelly Adapter an den Objekten, dass die Gen 1 Shellys mit dem Adapter per MQTT Protokoll sprechen.Die Einschränkung der Cloud war mir bekannt und war auch explizit damals gewünscht. Die damalige Motivation vor etlichen Jahren den ioBroker einzurichten, entsprang dem Wunsch von den Hersteller Gateways wegzukommen. Als ich den Controller in Form von ioBroker noch nicht hatte, waren hier für die Tradfri Geräte das alte IKEA Tradfri Gateway und für die Sensoren der Xiaomi Mii Hub im Einsatz, wo auch die ersten Roborock Staubsaugroboter angebunden waren. Und für die noch nicht mit Tasmota geflashten Tuya Geräte gabs wieder ne separate App.
Da ich erstens Cloud unabhängig sein wollte und zweitens die Geräte steuerungstechnisch auch herstellerübergreifend kombinieren wollte, kam der ioBroker und auch deConz mit dem Conbee II zum Einsatz. Und ich glaube im Bereich Zigbee ist an deConz auch nichts weiter auszusetzen. Ein Wechsel auf Sonoff Stick und Zigbee2Mqtt war zwar angedacht, aber wenn es keinen wirklichen Mehrwert bringt, dann kann mein Setup auch so bleiben wie es ist.
Das lief bis vor Kurzem auch relativ klaglos. Erst mit der Matter Fähigkeit von den neuen Geräten wie der Türklingel und dem Türschloss, ist die Notwendigkeit von Hersteller Hubs und Boarder Routern notwendig geworden. Und die unglückliche Entwicklung mit dem ioBroker Skill hat dann nochmal andere Voraussetzungen geschaffen. Aber das eröffnet neue Möglichkeiten und hat mich mal wieder tiefer in die SmartHome Automation eintauchen lassen. Auch, wenn ich Anfangs eher planlos unterwegs war und meine Kenntnisse mit eher "komischen" Fragen wieder in die Bahnen lenken musste.
Danke nochmal für die Geduld mit mir. Das weiß ich sehr zu schätzen.
