dann könntest Du in der App die Taster genauso betätigen und das Licht schalten, als wenn Du vor Ort auf den Taster drücke und das Licht wird geschaltet.
ich kann das Licht aber auch direkt am Aktor (Shelly Plus 1) anmachen, geht sogar schneller als ein etwaiger Umweg über den I4. 
Aber ich denke die ganze Diskussion ist sinnfrei, ich halte mich dann ab jetzt raus.
du kannst keinen Shelly Pro (ESP32) mit der Firmware flashen.. mg2tasmota-Shelly1.zip >> die ist für den alten Shelly 1 (1.Generation mit ESP 8266)
Das Kennwort was man im Zertifikat vergibt, muss dem Kennwort der Anmeldung beim mqtt Server entsprechen.
ne, ganz sicher ist das nicht per Default so.. ich hab aus Faulheit admin/admin als Username im Spielserver. Wie oben breits geschrieben war "shelly" mein CA-Certifikats-Passwort.
Neustart vom Shelly hast du gemacht? Zugangsdaten für einen Benutzer eingeben?
Ich habe eins eingestellt und der shelly fragt es bei der Installation nicht ab.
meinst du das für die CA oder für das Server-Zertiffikat?i ich hatte tatsächlich beiden "shelly" als Passwort vergeben, war ja lediglich en Versuchsaufbau.
Stimmt, solange ich die Taster nicht in der App betätigen kann.
in der App bedient man aber keine Taster sondern Relais / LEDs / Dimmer etc, also ausschließlich Ausgabe-Geräte .. Eingabe-Geräte (Sensoren wie H&T, Flood, Motion, DW2 oder eben der I3/I4) zeigen dort lediglich ihre Zustände an und ich denke auch nicht, dass der Hersteller das ändern wird.
Und genau das geht nicht, man kann nicht aus HA die Tasten eines I4 Ansteuern!
wäre m.E. auch komplett sinnfrei, weil er kein Relais hat welches sich schalten lässt.. der Sinn und Zweck eines I4 ist es Schalter/ Taster /Reed-Kontakt usw. Signale abzufangen und diese über Webhook, Cloud, Alexa oder beispielsweise HomeAssistant weiter zu verarbeiten.
Ich nutze den I4 hier in verschiedenen Ausprägenungen (Reed-Kontakt für den Gaszähler, Fernsteuerung von Shelly 2,5, Shelly Bulb, Shelly Dimmer.
ich hätte den Shelly i4 gerne eingesetzt wie ein Shelly 2.5 nur mit eben mit 4 Ausgängen.
und genau das ist hier technisch das "Problem", der hat halt keine schaltbaren Ausgänge sondern nur Eingänge. Ein Ausgang (Relais) wird im HA auch wie ein Ausgang dargestellt (schaltbar). Ein Eingang (SW an einem Shelly) ist dazu gedacht von anderen Schalter/ Taster /Reed-Kontakt das Signal abzugreifen und dann in HA oder wo auch immer weiter zu verarbeiten.
Mit einem Shelly i4 der aus der App steuerbar wäre, könnte ich dann auch über alex 4 geräte schalten.
aber die lassen sich doch auch direkt in der Alexa-App (z.B. über eine Gruppe) steuern? ich verstehe gerade das eigentliche Problem nicht.
guck mal, ob du das verstehst.. ich nutze da eine Einschaltverzögerung (abhängig vom Button-Press)
please check the API docs, there are a lot of examples listed:
In beiden Fällen den FQDN deines Mosquitto-Servers?
genau.
Worauf müsste ich denn bei den BWM achten, damit es mit dem Shelly funktioniert?
so, ich hab das jetzt exemplarisch einmal komplett durchgespielt (von Anfang an)
CA File erzeugen
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 7500 -key ca.key -out ca.crt
Server key erzeugen ( für Mosquitto)
openssl genrsa -out server.key 4096
Zertifikatsanforderung für den Mosquitto Server erzeugen
openssl req -new -out server.csr -key server.key
Anforderung in Zertifikat umwandeln und mit dem CA Zertifikat singnieren
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 4096
im Mosquitto einen passenden Listener anlegen, und die Dateien (ca.crt, server.crt und server.key) entsprechend hinterlegen.
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.keyIm Shelly das ca.crt über das Webformular hochladen.
das sieht nach Upload bei mir so aus:
MQTT auf User-TLS einstellen und auf den passenden Port 8883 konfigurieren.
Shelly restarten, danach hab ich im subscribe auf # folgende Meldungen:
shellyplusi4-083af2010158/online true
shellyplusi4-083af2010158/status/mqtt {"connected":true}
shellyplusi4-083af2010158/status/cloud {"connected":true}
shellyplusi4-083af2010158/status/sys {"mac":"083AF2010158","restart_required":false,"time":"13:59","unixtime":1678625991,"uptime":12,"ram_size":248400,"ram_free":96076,"fs_size":458752,"fs_free":49152,"cfg_rev":64,"kvs_rev":6,"schedule_rev":0,"webhook_rev":0,"available_updates":{"stable":{"version":"0.14.1"},"test":{"version":"0.99.99-dev54754"}}}im mosquitto.log
1678625982: New connection from 192.168.178.84:49371 on port 8883.
1678625986: New client connected from 192.168.178.84:49371 as shellyplusi4-083af2010158 (p2, c1, k60, u'admin').Hoffe das hilft dem ein oder anderen.
ich denke das liegt an der GUI, das hab ich tatsächlich auch nie ausprobiert..
ich hatte es damals bei den Entwicklern angefragt und folgende Anleitung bekommen (da gab es noch keine GUI)
To disable any old certificates you can use:
curl -X POST -d '{"data":null, "append":false, "method":"Shelly.PutUserCA"}' http://${SHELLY}/rpc
For uploading a certificate, you should use this method one time for each line of your certificate:
curl -X POST -d '{"data":<first_line_of_your_certificate>, "append":true, "method":"Shelly.PutUserCA"}' http://${SHELLY}/rpc
curl -X POST -d '{"data":<second_line_of_your_certificate>, "append":true, "method":"Shelly.PusUserCA"}' http://${SHELLY}/rpc
...
curl -X POST -d '{"data":<last_line_of_your_certificate>, "append":false, "method":"Shelly.PutUserCA"}' http://${SHELLY}/rpc
das geht vermutlich genauso auch für die anderen beiden Methoden, Shelly.PutPutTLSClientCert (client.crt hochladen) und Shelly.PutTLSClientKey (key-File hochladen)
Die GUI scheint da noch verbuggt und unvollständig zu sein.
Hab heute leider keine Zeit mehr, werde mir das aber morgen ganauer anschauen.
ich teste es nachher mal und dokumentiere es dann entsprechend, hatte das vor einiger Zeit (> 1 Jahr) mal ausgiebig getestet aber da hat sich anscheinend was geändert.
Use the following RPC methods:
Shelly.PutUserCA RPC method, upload the ca.crt to the device.
Shelly.PutPutTLSClientCert RPC method, upload the client.crt to the device.
Shelly.PutTLSClientKey RPC method, upload the client.key to the device.
das war damals komplett anders 
Diagnostics - Debug rechts oben im Debug-Log das "play" icon drücken.
vorher sollte unter Settings - Debug der Haken bei "Enable Websockets debug" gesetzt werden
Einstellung unter MQTT muss aber User TLS sein, weil du ja dein eigenes CA Zertifikat nutzt.
Alternativ kannst du auch mal mit "TLS no validation" testen
Kann der Shelly EM auf beiden Kanälen nur die gleiche Phase messen?
er kann nur die Phase messen, von der er selbst seine Spannung bezieht.
Wenn ich es also richtig verstehe, dann erstelle ich eine Zertifikatsdatei und signiere diese mit meiner eigenen ca.
nope, nicht ganz.
ich gehe mal davon aus, dass du folgendes irgendwann mal gemacht hast.
- du hast auf deinem MQTT server eine zertifikatsanforderung erstellt
- du hast diese an deine CA übergeben, die hat daraufhin ein Zertifikat ausgestellt.
- das Zertifikat hast du im MQTT-Server eingebunden
dem Shelly reicht das Zertifikat deiner CA (ca.crt), welche das Zertifikat für den MQTT-Server ausgestellt hat. Damit wird die CA vertrauenswürdig, also wird allen Zertifikaten dieser CA vertraut (also auch dem deines MQTT-Servers)
Deinem WebBrowser reicht es ja auch das Zertifikat der Root-CA von "Let's enctypt" zu kennen damit du Webseiten wie diese hier ohne Zertifikatsfehler aufrufen kannst.
in einfacher Sprache gesprochen läuft das etwa so ab:
- Shelly baut auf Port 8883 eine TCP-Verbindung mit dem MQTT-Server auf
- MQTT-Server sagt: Willkommen, auf dem Port nur verschlüsselt, hier ist mein Zertifikat
- Shelly sagt: ah das Zertifikat kommt von der super-CA, die kenne ich und der vertraue ich. Außerdem ist das Zeritifkat gültig, also kann ich dem Server vertrauen und meine Daten per MQTT abgeben.
da er angeblich SSL über MQTT kann.
das kann er auch, hab das auch laufen.
guckst du hier:
https://shelly-api-docs.shelly.cloud/gen2/General/S…oundConnections
Meine MQTT Clients haben ein Client Zertifikat und einen Key (.cer und .key) und kennen auch das ca.crt.
dann machst du zusätzlich zertifikatsbasierte Authentisierung. das sind zwei verschiedene Dinge.
Der Shelly braucht das CA-Zertifikat um eine sichere Verbindung zum MQTT-Server aufzubauen (die auch validiert werden kann) , die Authentisierung erfolgt dann über Username / Password.
but do not have a clue how to install the crt the ca and the key. Is there anyone who can help here?
you'd only need the CA file. this can be uploaded via Webinterface-
Settings - user certificate - upload ca file.
https://shelly-api-docs.shelly.cloud/gen2/General/S…oundConnections
the certificate and private key are both files for the mqtt server side.
Prinzipiell sollte das mit einem Shelly Plus I4 und einem passenden BWM funktionieren. (nicht jeder BWM funktioniert am Shelly SW-Eingang)
Sinnvollerweise würde ich Taster statt Schalter in die Schaltung bauen. Das hat den Vorteil, daß du auch von dort dimmen kannst (Taster halten) und den Doppel-Klick für 100% Helligkeit nutzen kannst.
Alternative zu Shelly Plus I4 + BWM wäre ein Shelly Motion 2, auch der hat einen Dämmerungssensor und kann tageszeitabhängig andere Shellies steuern.
