Shelly2 IP Schaltaktor

Begonnen von Prof. Dr. Peter Henning, 08 September 2018, 16:31:30

Vorheriges Thema - Nächstes Thema

Torsten_MG

Zitat... Für die Nutzung ist noch eine hybride Version denkbar: Alle Set-Befehle erfolgen über 36_Shelly.pm (und auch Konfigurationsänderungen). Aber statt in festen Abständen den Status zu pollen, wird eine minimales MQTT-Device definiert, sowie ein notify, das dann beim Eintreffen einer MQTT-Nachricht vom Shelly die Readings in dem anderen Device updatet.


LG

pah

Ich bin hier die ganze Zeit am mitlesen, da ich noch auf meine 2 Shelly1 warte und ich bin da noch ein Anfänger in diesem Thema, aber kann man sich mit mqtt_Generic_Bridge sich nicht ein zusätzliches Device sparen da man über die Attribute dann auf mqtt reagieren kann? Kann jetzt nicht den genauen Parameter nennen, sitze hier auf der Arbeit :)

Kann mich jetzt auch irren, darum bitte keinen shitstorm!

Gesendet von meinem SM-J730F mit Tapatalk

Prof. Dr. Peter Henning

ich benutze MQTT2_SERVER und MQTT2_DEVICE, weil diese ohne zusätzliche Software auskommen.

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 05 Oktober 2018, 18:48:47
Bei Punkt 3 bin ich mir nicht sicher, ob es nicht doch noch einen Workaround gibt.
Man kann das schon hinfrickeln über eventMap, webCmd und ggf. widgetOverride und dann $EVTPARTx in setList nutzen.
Beispiel (wenn auch wg. der unnötigen Verwendung von toJSON nicht perfekt):https://forum.fhem.de/index.php/topic,86932.msg832336.html#msg832336
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Cluni

Ich sehe schon, bis meine Shellys endlich da sind, läuft das Modul perfekt... [emoji2][emoji1376][emoji1360]


Gesendet von iPhone mit Tapatalk

Prof. Dr. Peter Henning

#214
ZitatMan kann das schon hinfrickeln
Eben. Das sollte es nicht sein - vielleicht kann ich Rudi zu einem Patch überreden. Denn es funktioniert schon

attr <device> relay_0:on,off shellies/shelly4pro-061D51/relay/0/command

für das FHEMWEB-Interface - aber nicht bei der Ausführung.

Jedenfalls erschließt sich mir mit der funktionierenden MQTT-Anbindung off-the-shelf und dem 36_Shelly.pm eines nicht: Warum sollte man dann überhaupt irgendeine andere Firmware aufspielen ?

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 06 Oktober 2018, 20:32:25
Jedenfalls erschließt sich mir mit der funktionierenden MQTT-Anbindung off-the-shelf und dem 36_Shelly.pm eines nicht: Warum sollte man dann überhaupt irgendeine andere Firmware aufspielen ?
Vorbehalte gegen die Verwendung irgendeiner Hersteller-Firmware: Seit du das berichtet hast, dass das Teil seine Geodaten kannte (auch noch trotz Inet-Verbot für neue Geräte im Router), ist das m.E. für Shelly's ein "must".

Dennoch finde ich den Gedanken nicht schlecht, die "vermutlich richtigen" Attribute zu setzen (wenn ich den Vorschlag richtig verstanden habe?), wenn man den Device-Typ erkennen kann.

Das "attr <device> relay_0:on,off shellies/shelly4pro-061D51/relay/0/command" verstehe ich aber nicht so recht, m.E. müßte man das für MQTT2 auf mehrere attr verteilen (setList, webCmd widgetOverride).

Und wenn man mal ein Beispiel hat, wie das zu funktionieren hat, braucht es m.E. keinen Patch, dass sollte dann jeder User selber hinbekommen (Motto: Attribute gehören dem User); notfalls kann man ja auch templates generieren und zentral zur Verfügung stellen (finde ich für diesen Anwendungsfall (sowohl Shelly wie Tasmota) eine gute Sache, ohne das näher geprüft zu haben).

Just my2ct.

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

ZitatVorbehalte gegen die Verwendung irgendeiner Hersteller-Firmware
Teilweise gebe ich dir Recht - aber das lässt sich durch Einstellungen beheben. Beim Flashen scheue ich einfach den zusätzlichen Aufwand, außerdem treten dann wieder (möglicherweise) versicherungsrechtliche Probleme auf, die CE-Sicherheitszertifizierung erlischt.

Zitatmüßte man das für MQTT2 auf mehrere attr verteilen (setList, webCmd widgetOverride)
Äh - nö. Wenn FHEMWEB das schon richtig anzeigt, mit 2 Drow-Down-Listen, sollte das bei der  Ausführung nicht aussteigen. Rudi sieht es zumindest als Bug an, ist jetzt hier gepostet für einen Fix: https://forum.fhem.de/index.php/topic,90145.msg843282.html#msg843282.

LG

pah

andies

Zitat von: Prof. Dr. Peter Henning am 07 Oktober 2018, 09:21:54
außerdem treten dann wieder (möglicherweise) versicherungsrechtliche Probleme auf, die CE-Sicherheitszertifizierung erlischt.
CE ist ja eine Eigendeklaration, kein Prüfsiegel durch Dritte. Bei den Bulgaren wird es wahrscheinlich so sein, dass die sich eine Falschdeklaration langfristig nicht leisten können. Die Chinesen (Sonoff) sind da sicher gedankenloser.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Prof. Dr. Peter Henning

#218
Eben - und die werden sich hüten, Dritten gegenüber die Konformität zu erklären, wenn die Software von irgendwoher stammt.


Betreffend das Modul 10_MQTT2_DEVICE: Rudi hat es gerade gefixt und eingecheckt.

LG

pah

Papaloewe

#219
Kurzes Feedback zum Einsatz eines Shelly 4pro mit original, aktueller Firmware des Herstellers.
(Ein Update auf Tasmota, o. ä. steht bei dem Shelly4 gar nicht zur Debatte, weil kein ESP8266-Chip verbaut wurde)

Ich kann alle Werte über MQTT empfangen und auch die vier Relais getrennt schalten.
Eine ausführliche Doku der MQTT-Topics habe ich hier gefunden:
http://shelly-api-docs.shelly.cloud/#4pro-mqtt
Es können laut Doku auch die verschiedenen Settings gepublished werden.
Das habe ich aber noch nicht ausprobiert.
Falls Interesse besteht kann ich auch gerne ein List meines FHEM-Devices hier posten.

Ich werden den Shelly 4  als modernen Treppenlichtautomaten einsetzen.

Gruß
Thomas

Prof. Dr. Peter Henning

Ich lese die Dokumentation anders: MQTT erlaubt eben nicht, die Settings zu lesen oder gar zu verändern. Das geht nur über die REST-Schnittstelle im JSON-Format.
Die einzig nichttrivialen Werte für Attribute des MQTT2-Devices werden für readingsList und setList benötigt, stehen oben bereits zur Verfügung.

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 07 Oktober 2018, 09:21:54
...außerdem treten dann wieder (möglicherweise) versicherungsrechtliche Probleme auf, die CE-Sicherheitszertifizierung erlischt.
Gutes Argument; vielleicht läßt der Hersteller sich dazu überreden, dass man das "Reden mit der cloud" aktiv freischalten muß (im Einbindeverfahren in das eigene WLAN), denn schließlich dürfte der "normale MQTT-User" das nicht benötigen bzw. wollen?

Danke für das Anschubsen der erweiterten Optionen bei setList!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dkreutz

Zitat von: Beta-User am 08 Oktober 2018, 07:57:27
vielleicht läßt der Hersteller sich dazu überreden, dass man das "Reden mit der cloud" aktiv freischalten muß
Das muss man nicht, da der Cloud-Modus im Auslieferungszustand ausgeschaltet ist und auch nur benötigt wird, wenn man "unterwegs" über die Shelly-App die Geräte steuern möchte - wird der geneigte FHEM-User wohl eher nicht tun. Der Cloud-Modus und MQTT schließen sich auch gegenseitig aus (wird explizit in der Konfiguration drauf hingewiesen).

Was die Shelly-Devices hingegen "ab Werk" machen, ist den (ungefähren) Standort zu ermitteln - vermutlich über GPS-Daten des Internetproviders. Diese Informationen werden für die Ein/Ausschaltautomatik bei Sonnenauf/untergang verwendet. Die Standortabfrage kann man auch abschalten, ist aber - wie zuvor geschrieben - im Auslieferungszustand aktiv. Wenn man also verhindern möchte, dass das Shelly-Device die Standortdaten ins Internet "funkt" kann bei erstmaligen verbinden im WLAN ja den externen Datenverkehr blocken.

Außerdem fragen die Shellies wohl regelmäßig ab, ob es einen neue Firmware gibt. Hier ist mir noch nicht klar wie man das deaktivieren kann, außer evtl. eine statische IP zu vergeben und die Einträge für Router und DNS leer zu lassen (habe ich noch nicht ausprobiert)?
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

eki

Wenn Du die Cloud abschaltest, dann wird nach meiner Erfahrung auch keine Firmware Abfrage gemacht. Außerdem habe ich für die Shelly Devices, wie von Dir ja auch vorgeschlagen, die Verbindung ins Internet im Router deaktiviert, dann passiert da gar nichts Richtung Cloud. Den Standort hatten meine erst, als ich erstmals die Cloud aktiviert hatte und temporär den Zugang zum Interet geöffnet habe, um mal nach neuer Firmware zu schauen.
Firmware Updates machen und trotzdem verhindern, dass das Gerät nach Hause telefoniert, schließt sich natürlich aus und wenn man die updates macht, dann kann natürlich auch alles mögliche zusätzliche übermittelt werden.

Prof. Dr. Peter Henning

ZitatWenn Du die Cloud abschaltest, dann wird nach meiner Erfahrung auch keine Firmware Abfrage gemacht
Leider falsch - die Cloud ist bei mir überall aus, und trotzdem wird das Vorhandensein einer neuen Firmware gemeldet. Damit kennt der Hersteller auch die IP-Adresse, und die stammt nun mal aus einem grob lokalisierbaren Pool des Internet-Providers.

Der erste Weg, das zu verhindern, ist die komplette Bockade im Router. Der zweite wäre die Umleitung über einen entfernten Proxy - so wie man das auch machen kann, wenn man nicht für Europa bestimmte Videostreams sehen möchte.

LG

pah