UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[da_Woody]

@foxthefox was erwartest du? In der App geht's nicht, aber im Adapter soll's klappen?
Shelly ist nicht mehr Shelly grundsätzlich.
Da wird viel entwickelt, das mit dem Adapter und der App nichts zu tun hat.

[mcm1957]

@foxthefox

Um welches Shelly Device geht es jetzt genau:

Shelly Pro 3 EM (shellypro3em) ist ein Gen2 Gerät. Das müsste bei einsprechender Konfiguration immer in der Shelly App sichtbar sein und auch via http ansprechbar und konfigurierbar sein.

Hier https://github.com/foxthefox/ioBroker.ecoflow-mqtt/issues/297#issuecomment-3196611996 wird ein mqtt trace gezeigt. Bei dem dort gezeigten Gerät wurde die originale id verändert. Daher kann der Shelly Adapter diesen Pro 3EM nicht erkennen auch wenn bei diesem die mqtt Daten für den ioBroker eingetragen sind. Um das Gerät mit dem Shelly Adapter zu verwenden wäre ein Rücksetzen auf Werkseinstellungen und nachfolgende Konfiguration lt. Anleitung im Shelly Adapetr Repo wohl am sinnvollsten. Wichtig ist, dass die Geräte Id NICHT verändert werden darf da sie der Shelly Adpater zur Identifikation des Gerätetyps verwendet.

Der Shelly Pro 3EM kann als Gen 2 Gerät mit genau einem mqtt Broker reden. Wenn ecoflow verlangt, dass der Shelly Daten via mqtt an Ecoflow sendet dann kann er nicht parallel Daten an den Shelly Adapter senden. Der Zugriff via App / Cloud von Shelly ist davon unabhängig. Ein Zugriff auf das Gerät via App sollte immer möglich sein sofern das Netzwerk hier nichts blockt. Nur Gen 1 Geräte können nicht gleichzeitig mit der Cloud und mit einem mqtt Broker kommunizieren.

Und falls die Frage in die Richtung geht den Shelly Adapter komplett von mqtt auf http Polling umzustellen - nein, das ist nicht geplant.

[Whity]

Danke @foxthefox das war das was ich fragen wollte. Ich sollte nächstes Mal nicht aus'm Urlaub vom Handy ausschreiben. @da_Woody was hat das an sich mit der Shelly App zu tun? Erstmal gar nichts.
Es ist vom Haus aus erstmal ein Shelly mit einer angepassten FW für Ecoflow. Der MQTT part im Shelly ist durch ecoflow belegt, deswegen auch erst der Versuch über den ecoflow Adapter. Die Frage wäre, wo ist es sinnvollerweise eher richtig aufgehoben und ob es überhaupt sinnvoll wäre, wenn ihr auch nein sagt, dann ist es ein Shelly bei mir der nicht im IOB ist. Dann kann ich es auch nicht ändern.

Danke
Matze

[Whity]

@mcm1957 gut dann hat sich mein letzter Post auch erledigt zu der Anfrage.

Trotzdem danke fürs rüberschauen

[mcm1957]

@whity said in Shelly Adapter - genereller Support:

Danke @foxthefox das war das was ich fragen wollte. Ich sollte nächstes Mal nicht aus'm Urlaub vom Handy ausschreiben. @da_Woody was hat das an sich mit der Shelly App zu tun? Erstmal gar nichts.
Es ist vom Haus aus erstmal ein Shelly mit einer angepassten FW für Ecoflow. Der MQTT part im Shelly ist durch ecoflow belegt, deswegen auch erst der Versuch über den ecoflow Adapter. Die Frage wäre, wo ist es sinnvollerweise eher richtig aufgehoben und ob es überhaupt sinnvoll wäre, wenn ihr auch nein sagt, dann ist es ein Shelly bei mir der nicht im IOB ist. Dann kann ich es auch nicht ändern.

Danke
Matze

Also läuft dort eine spezielle Firmware. Dann ist es nur mehr ein Gerät das von Shelly Produziert wird und (in meinen Augen) KEIN Shelly Pro 3EM.
Was zeigt das Ding an wenn man das Webinterface öffnet?
Was steht am Typenschild?
,"model":"EFPEM-003CEBEU120" im mqtt Paket sagt eigentlich deiutlich, dass es KEIN Shelly Pro 3EM ist.

[Whity]

@mcm1957 shellyPro3EMEF , auf den Shelly kann ich gerade nicht direkt schauen, da ich in Ägypten bin. Das WebUI ist auch das gleiche wie von einem Standard Pro3EM. Sage ja er ist entstanden aus einer Zusammenarbeit von Shelly und Ecoflow

[mcm1957]

@whity
schönen Urlaub

Spezielle Shellies kann man natürlich auch versuchen in den Shelly Adapter aufzunehmen. Nur so wie ich es seh muss dieser Shelly zwingend via mqtt mit Ecoflow reden. Damit kann er nicht gleichzeitig mit dem Shelly Adapter reden.

[migesch]

Liebe Leut,

als Anfänger habe ich erfolgreich auf meinem Raspberry Pi 5 iobroker installiert und den Fronius Wechselrichter meiner PV-Anlage auf meinem Raspberry Pi 5 eingebunden. Aber beim Shelly Plug S Gen3 bin ich nach mehreren Tagen und verschiedenen Versuchen gescheitert.

Dem Plug S Gen3 kann ich über die App und meinen Firefox-Browser ansprechen.

Die MQTT-Settingings lauten wie folgt

Im Shelly Adapter (v10.2.0)

habe ich den Username, das Passwort und den Port 1882 übernommen.

Das Protokoll zeigt immer an, dass der Shelly Plug S Gen3 irgendwas beendet

Wenn mir bitte ein Spezialist auf die Sprünge helfen würde müsste ich mich nicht länger ärgern und wäre ihm ewig zur Dankbarkeit verpflichtet.

[wendy2702]

Lösche mal das „http://„ vor der IP:Port im Shelly

[mcm1957]

@migesch
Hier das Beipiel aus der SHelly Dokumentation:

Der Shelly Plug beendet keinen Adapter. Ziemlich sicher hast du die ioBroker Einstellungen angegriffen und gespeichert. Dies Aktion restartet den Adapter. Das ist normal.

[migesch]

@wendy2702

Vielen Dank wendy2702. Nachdem ich "http://" entfernt habe ist alles grün und mein Shelly Plug S Gen3 ist bei den Instanzen da.
Vielen Dank nochmals für deine Hilfe.

[SabineT]

Warum verwendet der Shelly Adapter eigentlich überhaupt einen eigenen MQTT-Broker und isoliert die Geräte damit von der übrigen MQTT-Welt?

[da_Woody]

@sabinet wieso isoliert? Du kannst doch deinen mqtt verwenden.

[Samson71]

Komische Frage. Warum sind die "isoliert"? Ohne

@sabinet sagte in Shelly Adapter - genereller Support:

eigenen MQTT-Broker

braucht man doch den ganzen Adapter nicht.

Es steht Dir selbstverständlich frei einen Shelly über einen anderen (bereits vorhandenen) MQTT-Broker einzubinden. Dann brauchst Du den Adapter überhaupt nicht, musst dann aber die Datenpunkte selber aufbereiten. Im Standard kommt da nämlich ein JSON, was Du dann zerlegen musst. Der Adapter macht das alles out-of-the-box für den User und liefert dazu zusätzliche Features wie z.B. Summenbildung beim Shelly 3EM. Die fehlen beim normalen MQTT. Kann man aber natürlich auch alles selber mit standardisiertem MQTT machen. Das kann aber auch nicht jeder.

Außerdem können nicht alle Shelly-Generationen MQTT und Cloud parallel. Deswegen bietet der Adapter ja auch nicht nur MQTT als Anbindung.

[SabineT]

@samson71 @da_Woody so mach ich es ja auch (mit node-red).
Ich frag mich halt nur, welchen Vorteil der eigene Broker bringen soll.

[Homoran]

@sabinet sagte in Shelly Adapter - genereller Support:

welchen Vorteil der eigene Broker bringen soll.

damit nicht

@sabinet sagte in Shelly Adapter - genereller Support:

isoliert die Geräte damit von der übrigen MQTT-Welt?

[SabineT]

@homoran mit "eigenen Broker" meinte ich den vom Shelly Adapter!

[Samson71]

@sabinet sagte in Shelly Adapter - genereller Support:

Ich frag mich halt nur, welchen Vorteil der eigene Broker bringen soll.

Du antwortest mir zwar, also muss ich annehmen dass Du auch gelesen hast. Nur mit dem Verstehen scheint es zu hapern. Anders ist diese (nochmalige) "Nachfrage" jedenfalls nicht zu erklären.

[Homoran]

@samson71 nee, so einfach ist das anscheinend nicht.

mit der Zusatzinfo

@sabinet sagte in Shelly Adapter - genereller Support:

@homoran mit "eigenen Broker" meinte ich den vom Shelly Adapter!

und der vorangegangenen Frage(n) gibt es noch eine weitere, wahrscheinlich aber sehr komlizierte, Möglichkeit, die @sabinet möglherweise meinen könnte:

Der MQTT Broker liest auch die Shelly-topics aus, der Shelly Adapter zerlegt diese in Bestandteile.

Wenn das so einfach lösbar sein könnte, setzt das aber mindestens einen MQTT-Client im shelly-Adapter voraus.

und da stellt sich mir die Frage: Warum dann über den MQTT Broker, wenn die Restauswertung woanders stattfindet und das restliche MQTT Universum nichts davon hat.

[mcm1957]

@sabinet said in Shelly Adapter - genereller Support:

@samson71 @da_Woody so mach ich es ja auch (mit node-red).
Ich frag mich halt nur, welchen Vorteil der eigene Broker bringen soll.

Du willst wissen warum der Shelly Adapter einen eigenen mqtt-broker eingebaut hat?

Kurze (und ein wenig provokante) Antwort:
Weil das bei der Entwicklung so entschieden und umgesetzt wurde.

Längere Antwort:
Der integrierte mqtt Broker

• erleichtert die Implementierung
• erleichter die Installation (nur ein Adapter und die Shellies können verbunden werden)
• User brauchen kein Wissen über mqtt, keine extra Installation eines weiteren Adapters oder einer externen Software
• User brauchen keine Kenntnis von json und / oder node-red um dedizieret States zu erhalten

Niemand zwingt jemand den Adapter zu verwenden. Wenn es jemand will und kann, dann kann er gernee einen externen Broker verwenden und die Daten selbt mit jeder geeigneten Software bearbeiten.

Falls es ein konkretes Problem gibt, dass ggF im Adapter behoben oder verbessert werden soll, dann gerne ein Issue im Repo anlegen. Die rein philosophische Diskussion warum etwas so und nicht anders umgesetzt wurde wenn möglich bitte zurückfahren oder in einnderes Topic verlagern. Supportbedarf sehe ich mit den vorhandenen Infos derzeit nicht. Sollte doch welcher gegeben sein, bitte klarer rausarbeiten.

Hab Homorans Antwort erst später gesehen:
Natürlich gibt es viele Wege zum Ziel. Der Shelly Adapetr könnte sich natürlich als Client an einen Broker hängen. Nur das erfordert mehr Aufwand und Kenntnis beim User (er muss einen Broker irgendwie aufsetzen) und im Shelly Adapter. Als Broker teilt ihm der Shelly aktiv mit was er zu sagen hat. Als Client muss der Adapter "auf Verdacht" subscriben da er nicht weiß was der Shelly denn zu sagen hat. Außerdem muss der Adapter die IP des Shellies dann anderweitig ermitteln da der Broker im Normalfall ja nur die mqtt Daten weiterleitet. Und der Adapter benötigt die IP des Shellies weil nicht die gesammte Kommunikation via mqtt erfolgt.

Das nur als ein paar Beispiele. Und ja - es würde gehen. Wie geschrieben gibts meist mehrere Wege die zum Ziel führen. An eine Umstellung des Adapters ist derzeit aber definitiv nicht gedacht.