Beiträge von supernova1963

Zitat

sorry, das war mir entfleucht...

Kein Problem, geht ja auch mit tasmota ganz gut

Zitat

warum mqtt?

Mit der Original FW hätte ich mich wahrscheinlich für die Common HTTP API entschieden (weniger wegen der Cloud, als dem größeren Funktionsumfang im Vergleich zu Cloud API, CoIoT und MQTT) .

Aber, wie du weißt, bekomme ich auf 2 meiner 4 RGBW2 Shellies die Original FW nicht mehr ans fliegen.

Mit Tasmota ist die MQTT Schnittstelle einfach besser, vollständiger und bietet Funktionen, die ich bei der Original FW noch nicht gefunden habe.

Also, sobald sichergestellt ist, dass ich 3 meiner RGBW2 Shellies mit der original Firmware nutzen kann, würde ich wahrscheinlich wegen original,- nicht wegen der Cloud Anbindung -, erneut hinsetzen und die Shellies so oder so ähnlich über die Common HTTP API in FHEM einbinden.

lg

Gernot

Funktionen:

• Text wird im defStateFormat wird aus Alias und Schaltzuständen generiert.

• Im leeren Feld dahinter soll auf ein mögliches FW Update hingewiesen werden und bei Klick durchgeführt werden (z.Zt. Noch statisch, ich muss noch die aktuelle FW Version irgendwie abfragen. Das geht mit original FW leichter)

• Klick auf den „gelblichen Stripe“ schaltet warmweiss an bzw. Aus
• Klick auf den „bläulichen Stripe“ schaltet kaltweiss an bzw. Aus
• Klick auf die Birne schaltet warm- und kaltweiss gleichzeitig an bzw. Aus
• Grüner Punkt zeigt den online Status an und ist verlinkt auf HTTP der RGBW2 IP
• Gelblicher Slider setzt den warmweiss Prozentwert
• Gräulicher Slider setzt den kaltweiss Prozentwert
• Set command „Fade“ schaltet das Dimmen bei ein-/ausschalten ein oder aus
• Set command „Speed“ setzt die Dauer des Ein-/Ausschaltdimmens
• Set command „Status“ fragt den Status ab (0, ... 11 = welcher Status gem. Tasmota)
• Set command „Upgrade“ führt das OTA Upgrade aus
• Set command „Restart“ bootet den RGBW2

@da_Woody Ich habe das Einblenden (Fade) und das gleichzeitige schalten von 2 Kanälen in der originalen FW per MQTT noch nicht gefunden.

Ergebnis vorab:

E12781E2-E73D-4AA7-B58B-9AD400F067E1_autoscaled.jpg

1. Schritt: tasmota konfigurieren

a) Generic (18)

99E115FC-BFE2-4333-BC94-527EE123F618_autoscaled.jpg

b) Setoption 68 1

pasted-from-clipboard.png

c) FHEM: Am angelegten MQTT2_DEVICE attrTemplate tasmota_2channel_split

d) FHEM: RAW Definition LEDStripe_A und LEDStripe_B im Anhang RAWDEFS.TXT

Ich nehme gerne Anregungen für Verbesserungen oder Korrekturen an.

lg

Gernot

Aktueller Zwischenstand:

• FW von FB geladen und geflasht.
• AP vorhanden und wird verbunden
• Aufruf von 192.168.33.1:
  pasted-from-clipboard.png

Ich habe die Frage auch in FB gepostet, sollte es dort eine Antwort geben, melde ich mich und umgekehrt natürlich auch!

Also, vielleicht nächste Woche nochmal

lg

Gernot

MIHO: Angehangen FW funktioniert bei mir auch nicht ...

Vielleicht deswegen:

pasted-from-clipboard.png

Hey Michael,

danke für die Informationen, es hilft insofern, dass die Problemsuche sich erheblich erweitert.

Nein, ich bin nicht bei f***book.

Danke,

Gernot

So, nun habe ich lange genug "probiert".

Ausser einem wilden Blinken der Status LED kann ich der Original FW (weder: Backup, noch SHELLY RGBW2 FW 1.5.2 oder SHELL RGBW2- RECOVERY FW V1.5.0-HOTFIX2) und Resets in allen Varianten kann ich den RGBW2's nichts mehr entlocken. Ein AP wird nicht mehr angeboten. Sicherheitshalber, um auszuschliessen, dass der Shelly, trotz vollem Funktionsumfang mit tasmota, eine Macke hat, habe ich einen weiteren RGBW2 auf tasmota "umgeflasht". Das Ergebnis ist 1:1 nachstellbar, das "Zurückflashen" auf die Original FW funktioniert bei mir nicht.

Ist auch nicht tragisch, da tasmota ja vollständig, und in Teilen sogar mit mehr Einstellungsmöglichkeiten, funktioniert ...

lg

Gernot

Vielen Dank für Dein Angebot, Kai,

und, das flashen funktioniert ja auch (über Arduino, da keine dubiosen Treiber für OS X notwendig). Ich habe jetzt bis zum Wochenende erstmal wieder tasmota „geflasht“.

Dann kann ich voraussichtlich etwas ausgiebiger probieren.

lg

Gernot

Vielen Dank für die Unterstützung,

leider blieben bisher alle Versuche mit der FW aus der Filebase erfolglos.

Ich will es noch mit einem Backup von einem anderen RGBW2 versuchen.

Ich werde den Verdacht nicht los, dass es mit der zip Datei zusammenhängt, da Tasmota „Flashen“ funktionierte wiederholt einwandfrei.

Gernot

Den Beitrag „Shelly bei Inbetriebnahme noch im "factory test mode"“ hab‘ ich gefunden, aber dafür muss der Access Point zur Verfügung stehen.

Ich nehme gerne weitere Hinweise entgegen ...

Danke, #da_Woody,

Gernot

Hallo zusammen,

ich habe einen RGBW2, den ich mit Tasmota "geflashed" habe. Hat auch funktioniert ...,

... aber jetzt würde ich gerne die Original FW wieder nutzen. Dazu habe ich die zip Datei aus dem Lexikon wieder auf den RGBW2 übertragen:

Command: esptool.py —port /dev/cu.usbmodem14301 —baud 115200 —after no_reset write_flash —flash_mode dout 0x00000 /Users/gernot/Downloads/SHRGBW2_build.zip —erase-all

esptool.py v2.6
Serial port /dev/cu.usbmodem14301
Connecting…
Detecting chip type… ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:6e:ab:2b
Uploading stub…
Running stub…
Stub running…
Configuring flash size…
Auto-detected Flash size: 2MB
Erasing flash (this may take a while)…
Chip erase completed successfully in 3.0s
Compressed 953828 bytes to 527818…
Wrote 953828 bytes (527818 compressed) at 0x00000000 in 45.6 seconds (effective 167.3 kbit/s)…
Hash of data verified.

Leaving…
Staying in bootloader.

Firmware successfully flashed. Unplug/replug or reset device 
to switch back to normal boot mode.

Für mich sieht es so aus, als hätte das "flashen" funktioniert.

Leider bekomme ich keinen Standard Access Point für diesen Shelly.

Worauf muss ich achten?

Was mache ich nicht richtig?

Muss ich zurück nach Tasmota?

Vielen Dank,

Gernot

Ich bin auch weder Webdesigner noch Shelly Experte!

Aber da fallen mir gleich mehrere mehrere Möglichkeiten ein, es kommt halt auf die konkrete Realisierung des Homepage Servers an.

• Z.B. über einen MQTT Broker, wenn der Homepage (HP) Server und Shelly darauf zugreifen kann, und, man Rechte für den Client/User vergeben kann (mosquitto)
• Z.B. Über die Shelly Cloud API

lg

Gernot

Also 'mal ohne Gewähr:

es gibt in der REST API unter settings/

Das hört sich für mich danach an, dass man damit das MQTT publish des Shelly beeinflussen kann.

Schon probiert?

lg

Gernot

Hallo,

hier einige Beispiele:

1. Einliegerwohnung bzw. Mehrfamilienhaus, oder mehrere Generationenhaus

2. Gästezimmer, -bad und Flur

3. Raumpflegerin

4. ...

Derzeit löse ich 2. und 3. mit mehreren Instanzen von fhem und Sub Netzen. Aber bei 1. wäre mir definitiv wohler, wenn man Rechte von User (Mitbewohnern) und ID's (Steuereinheiten) auch in MQTT steuern kann.

lg

Gernot

Zitat

... Die frage habe ich aber nicht verstanden. Kannst du diese umformulieren? ...

Ok, ich möchte verschiedenen MQTT Clients unterschiedliche Rechte für das abonnieren (Topic subscribe) und das senden (topic publish) einräumen (das wird oft "topic restriction" genannt). In mosquitto kann man in der mosquitto.conf den Parameter "acl_file file path" festlegen. In diesem acl_file kann man dann den Zugriff für topics steuern (s. z.B. hier oder hier, unter General Options).

Hierauf bezieht sich meine Frage:

Eine adäquate Steuerung der Zugriffsrechte habe ich in MQTT2_SERVER nicht gefunden, weißt Du da mehr?

Danke,

Gernot

P.S.: Diese Möglichkeit zur Zugriffssteuerung ist insbesondere bei der Verwendung der ADVANCED - DEVELOPER SETTINGS bei den Shellies nicht ganz trivial, da man mit dem Zugriff auf den Shelly auch den user und das password für den MQTT Broker in Klartext (json Rückgabe z.B. von http://<http user>:<http password>@<IP des Shelly>/settings) erhält.

Zitat

ot: ja..außer das auch mqtt 2 das kann. Nur eben die shelly nicht.

Das gilt nach meinem Kenntnisstand für TLS, zur Verschlüsselung von Daten.

Da teile ich Deine Ansicht, dass für den "Cloud-Free" Fall = "Developer-Mode des Shelly" und einem geöffneten Zugriff auf das WPA2 verschlüsselte und gesicherte WLAN eine verschlüsselte Datenübertragung enorm wichtig ist. Dann bitte aber unbedingt auch eine Verschlüsselung des http Protokolls (z.B. HTTPS) und der anderen nicht deaktivierbaren API's!

Für mich ist derzeit der "VPN - Zugriff" der geeignete Kompromiss bei der Sicherheit einer "fernen Steuerung".

Innerhalb meines WPA2 gesicherten und verschlüsselten WLAN priorisiere ich die erneute Verschlüsselung, - quasi gegen den Missbrauch von innen -, nicht ganz so hoch. Hier versuche ich durch geeignete (Sub-) Netzstrukturen den Zugriff zu steuern.

Leider ist das für zentrale Komponenten, wie z.B. einen MQTT Broker nur bedingt hilfreich. Hier wäre eine Rechtesteuerung durch den Broker wünschenswert. Das ist u.A. auch der Grund, für meinen Wunschgedanken zur anpassbaren topic Struktur. Dann muss man die freigegebenen oder gesperrten Shellies nicht alle einzeln angeben.

Unsicher bin ich mir ob diese Rechtesteuerung (Autorisierung von Clients für bestimmte "Pfade" zu abonnieren / zu senden) mit MQTT2_SERVER (Broker) umsetzbar ist (Der mosquitto broker z.B. ermöglicht diese Steuerung).

Weißt Du da mehr, und, wenn ja, welche Einstellungen muss ich am MQTT2_SERVER bzw. dem zugehörigen "allowed" vornehmen?

Danke,

Gernot

PS: An für sich find ich die Shelly Original Firmware gut und einfach, und, ich nutze diese für alle Shellies. Wir sind hier jedoch im MQTT & REST-API Board. Da kann man schon etwas "in die Tiefe" gehen, oder?

OT: Die shellies sind doch "nur“ clients, die vom Broker für topics "autorisiert werden“?

lg

Gernot