Beiträge von 87insane

ist ne idee aber du hast dir schon gut Mühe gegeben. Schaue ich mir morgen mal am pc an. Habe es hier am Hand nur überflogen.

Da ich nicht weiß, ob das jemals kommt, könnte das sogar ne lange Lösung sein. Die frage ist, wie es in der fhem gemeinde ankommt, das zu vermischen. Mit einer gewissen Struktur, würde das in meinem Augen okay sein. Ich bin aber auf der zuliefer seite vom SVN.

Bedeutet: ich kann sagen das und das ist toll und die andere seite entscheidet ob das wirklich so ist. Die Kollegen haben mehr Übersicht in allen Modulen und kennen alt hergebrachtes. Macht also auch Sinn. Denke aber bei shelly, wird mein Wort schon gut gewichtet.

Zitat

Top Anleitung! Der Teufel liegt im Detail: unter -Server sollte es heißen

"(IP Adresse deines MQTT2 Servers/Fhem Servers:Port deines MQTT2 Servers)"

Wer sich das Bild nicht ansieht kann Probleme bekommen!

Gruß

Danke!

Hab es so übernommen bzw. angepasst. Hatte echt gedacht, ich hab alles drin. Guter Hinweis.

Bei jeder arbeit, die man oft macht, lässt man die Kleinigkeiten aufgrund von "das sollte klar sein" weg. Das trifft natürlich nicht immer auf jeden zu.

Gerne mehr Infos oder Wünsche Danke, danke!

Mein Netz sieht ähnlich aus aufgrund der Ausleuchtung ... Hab nur den vorteil Access Points nutzen zu können und muss nicht ggf sogar über mehrere hops repeaten.

Du hast dir geholfen und das ist schön. Unverständlich ist für mich aber immer noch warum via mqtt bei dir keine direkte Status änderung eintritt. Ggf. Bedarf es noch kleinerer Optimierungen in deinem Netz. Da du aber Ahnung hast, sollte dies kein Problem dar stellen. Wenn noch was ist, wo man ggf helfen kann, immer her mit den infos und fragen

! - RESERVIERT - !

[Anleitung] - Shelly mit FHEM und MQTT2

Vorwort: Es gibt mehrere Wege um Shelly´s in FHEM einzubinden. Hier wird der Weg über den FHEM internen MQTT2 Server genutzt und beschrieben. In dieser Anleitung gehe ich davon aus, dass ein gewisses FHEM Grundwissen vorhanden ist. Hinzu ist diese Anleitung für die originale Firmware von Shelly. Mit Tasmota z.B. wäre der Weg allerdings fast der gleiche.

Übersicht (Praxis Beispiele - LINK)

1. MQTT2 Server anlegen

2. MQTT im Shelly aktivieren und einstellen

3. FHEM - neuen Shelly speichern

4. FHEM - attr wählen

- Infos zu den Templates

1. MQTT2 Server in FHEM einrichten (FHEM MQTT2 Commandref)

Kurz, ohne irgendwelche speziellen Einstellungen:

define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Info: Ich selber würde den MQTT2 Server auf JEDEN FALL mit einem User/Passwort versehen.

2. MQTT im Shelly aktivieren und einstellen

Nachdem ein beliebiger Shelly erfolgreich in dein Netzwerk verbunden wurde (via App oder Webinterface), müssen wir dem Shelly nun den MQTT Server mitteilen. Diese Option findest du im Webinterface (http://IPdesShellys/) unter: Internet & Security -> Advanced – Developer Settings -> Enable action execution via MQTT. Sobald dieses Häckchen gesetzt ist, gibt es neue Optionen im gleichen Menü. Hier müssen eigentlich nur folgende Einstellungen gesetzt werden:

- Username (Benutzer zum authentifizieren am MQTT2 Server von FHEM)

- Password (Passwort zum authentifizieren am MQTT2 Server von FHEM)

- Server (IP-Adresse:PORT deines MQTT2 Servers/Fhem Servers)

Der Rest kann so bleiben wie er ist. Man kann natürlich noch Optionen verändert, dies ist aber nicht notwendig.

Anbei ein paar Bilder:

3. FHEM - neuen Shelly speichern

Nun gehst du in deine FHEM Web Oberfläche. Der Shelly sollte sich nach kurzer Zeit oder einem Neustart, direkt melden. Zu sehen ist dies am „?“ bei „Save config“. Hier nun speichern und die Seite aktualisieren.

4. FHEM - attr wählen

Nun siehst du in FHEM den Punkt „MQTT“ in deiner Raumleiste, auf der linken Seite. Dort befindet sich auch das neue Gerät. Ein Shelly meldet sich immer mit Namen wie: „shelly1pm-B1D951“. Anschließend gehst du einfach in das neue DEVICE hinein und wählst das entsprechende Template. In diesem Beispiel ist das ein Shelly1PM. Dies wäre dann das Template „A_10b_shelly1_w_energy_meassuring“. Nach der Wahl des Templates nur noch auf set und der Shelly ist eingerichtet.

Am Ende kann er kann so oder so ähnlich in FHEM aussehen. Das ist abhängig von der Version des aktuellen Templates. Du kannst das natürlich auch selber noch auf deine Bedürfnisse anpassen.

Wenn du ein paar Geräte gesammelt hast, könnte es so aussehen. In Verbindung mit alexa-fhem ist es auch möglich alle Geräte zu steuern. "Alexa, färbe Wohnzimmer türkis", würde alle meine LED Stripes im Wohnzimmer einschalten und entsprechen einstellen.

INFOS zu den Templates:

-  Es gibt für jeden (mir bekannten) Shelly ein fertiges Template. Man muss diese nicht nutzen. Jeder der sich ein wenig mit FHEM auskennt, kann es natürlich manuell machen. Ich persönlich nutze gerne die Templates, da diese alles einstellen, wie ich das gerne hätte. Der kleine grüne Punkt z.B. neben der Lampe, leitet einen bei einem Klick, direkt auf das jeweilige Webinterface des Shellys. Hinzu würde der Punkt rot sein, wenn der Shelly offline wäre.

- Diese Templates gibt es aktuell:

A_10_shelly1

A_10b_shelly1_w_energy_meassuring

A_10a_shellyplug

A_11b_shelly2_roller

A_11b1a_shelly25_roller_invert_0

A_11b1b_shelly25_roller_invert_1

A_11a_shelly2_split

A_14a_shelly4pro_split

A_14b_shelly4pro_unified

A_15_shellybulb

A_16_shellyht

A_17_shelly2rgbw_color

A_17a_shelly2rgbw_4w_split

Bei Fragen einfach an mich wenden. Ich werde versuchen, diese Anleitung nach und nach weiter aus zu bauen und ein FAQ zu erstellen. Das lebt natürlich von Euren Fragen

Gruß,

Kai

Guten Morgen und ein dickes AU!

Also.... Was ist das und was passiert hier:

open:noArg shellies/shellyswitch25-001AB7/roller/0/command close

"open:" Ist der Befehlsname für FHEM

"noArg" Ist ein Parameter, der besagt das es z.B. kein Slider ist oder so

"shellies/NAME/roller/0/command close" Das ist für dich interessant. Das ist der eigentliche Befehl, den du über das Gerät via set x_mqttcom oder aber deinen MQTT2 Server publishen muss.

Ohne es böse oder abwertend zu meinen. Du hast dich weder in FHEM eingelesen noch in MQTT. Das Button oder so verschwinden, wundert mich weniger.

Hast du mal ganz einfach zum testen, das komplette Template eingesetzt und dann deinen Bedürfnissen angepasst? Dann würdest du vermutlich sehen, wie einfach es in echt ist

Alles was bei setList steht, erzeugt die Befehle an sich. So das man sagen könnte "set GERÄTENAME open" oder sonst was.

Alles was bei cmdIcon steht, erzeugt entsprechende Symbole für die Fahrten. (Symbole neben dem Status Symbol, hinter diesen liegen dann open/close/half usw.).

Alles was bei devStateIcon steht, erzeugt die Icons für den Status des Rollos. Also wenn es auf 40% ist, dass du auch ein Symbol hast, welches 40% anzeigt (reine Schönheit).

stateFormat erzeugt einfach die Übersicht. Hier wird nur gesagt, zeige beim ersten Symbol (status Symbol) nicht nur ein Rollo an sondern bitte auch den online/offline Status und die Bewegung eines Rollos.

Ich hoffe nun kannst du dem Thema folgen - Ansonsten bitte nochmal fragen. Die Templates sollten selbsterklärend sein. Da sie dies wohl nicht immer sind, nehme ich gerne Infos auf und verbessere dies, wenn es Sinn macht

Gruß,

Kai

Hey und guten Morgen,

alsooooooooo... Das hat alles einen Sinn. Diesen kann man nur verstehen, wenn man im FHEM Forum gelesen hat, warum ich das so gemacht hatte, im Template.

1. Settings hast du nicht via MQTT

2. Der announce Befehl geht. Du muss nur "set DEVICENAME x_mqttcom announce" senden und du bekommst diese payload. In dieser sind z.B. IP, MAC usw. Auszug aus meinem EventMonitor:

2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo x_mqttcom: set announce
2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo online: true
2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo fw_ver: 20190711-084118/v1.5.0-hotfix4@3b4f7414
2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo mac: 2462AB007FC8
2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo ip: 192.168.20.34
2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo id: shellyswitch25-007FC8
2019-07-16 07:13:18 MQTT2_DEVICE bz_rollo new_fw: false

3. x_update geht bei allen shellys. Habe bisher immer so geupdatet.

Zitat

Wie lautet das korrekte topic um den command /settings und/oder /status auszuführen?

Nach den MQTT2 template würde er

Code

1. shellies/shelly1-BA21B5/command status
2. shellies/shelly1-BA21B5/command settings

lauten. Leider bekomme ich hierauf keine Antwort in Form eines announce topics.

Du vermischt HTTP-GET mit MQTT. (https://shelly-api-docs.shelly.cloud/#shelly1-1pm-mqtt)

Status ist also bei dir:
shellies/shelly1-BA21B5/command announce

Was genau willst du einstellen? Über settings wirst du auch nichts erreichen. Auch das ist HTTP.

Der setter x_mqttcom, hat den Zweck, sich nicht auf das WEB-IF des Shellys auf zu wählen und aus FHEM heraus einen manuellen Befehl ab zu setzen. Wenn weitere Befehle via MQTT frei geschaltet werden, wie z.B. swap o.ä., kann man diese also direkt senden.

Bin gespannt auf deine Antwort....

Gruß,

Kai

Hast du wirklich nichts angepasst? Sicherlich werden andere ggf. auch mal haben. Da wäre nun deine Erfahrung sehr gut

Danke Dir!

Guten Morgen,

was genau ist das Problem?

Wenn du MQTT nutzt geht das ganz einfach... Dafür gibt es auch bereits fertige Templates in FHEM.

Anbei mal ein Beispiel.. Dies ist original aus dem Template für die Rollosteuerung via MQTT2 aus FHEM heraus.

open:noArg shellies/shellyswitch25-007FC8/roller/0/command close
  close:noArg shellies/shellyswitch25-007FC8/roller/0/command open
  half:noArg shellies/shellyswitch25-007FC8/roller/0/command/pos 50
  stop:noArg shellies/shellyswitch25-007FC8/roller/0/command stop
  pct:slider,0,1,100 shellies/shellyswitch25-007FC8/roller/0/command/pos $EVTPART1
  x_recalibration:noArg shellies/shellyswitch25-007FC8/roller/0/command rc
  x_update:noArg shellies/shellyswitch25-007FC8/command update_fw
  x_mqttcom shellies/shellyswitch25-007FC8/command $EVTPART1

Für dich wäre das pct der Punkt, den du brauchst.

Am besten erklärst du auch noch kurz was genau du dir "verhaust"....?

Gruß,
Kai

ach ja... Das wichtigste vergessen...

announce

Heist der Befehl für mqtt status.

einfach mal aus meinem fhem kopiert. Kannst du dir sicher selber zusammen reimen. Ansonsten kann ich dir dwn fhem svn empfehlen. Dort gibt es eine mqtt 2 template Datei, in der sind auch die shellys.

shellies/shelly1pm-B1D901/relay/0/command $EVTPART1
  off:noArg shellies/shelly1pm-B1D901/relay/0/command off
  on:noArg shellies/shelly1pm-B1D901/relay/0/command on
  update:noArg shellies/shelly1pm-B1D901/command update_fwshellies/shelly1pm-B1D901/relay/0/command $EVTPART1
off:noArg shellies/shelly1pm-B1D901/relay/0/command off
  on:noArg shellies/shelly1pm-B1D901/relay/0/command on
  update:noArg shellies/shelly1pm-B1D901/command update_fwoff:noArg shellies/shelly1pm-B1D901/relay/0/command off
on:noArg shellies/shelly1pm-B1D901/relay/0/command on
update:noArg shellies/shelly1pm-B1D901/command update_fw

Oder um es mal ein zu Grenzen. Was hast du vor? Dann kann man ggf schneller was bieten, was dir hilft.

kurz um - Nein..

Du kannst die mqtt Befehle nutzen wie sie beschrieben sind. Es gibt aber Befehle, die existieren nicht via mqtt. Aber das sind Befehle, die du nur bei der erst Einrichtung brauchen würdest.

ist ein raspi 3 ... Also das geht easy. Was kommt denn groß rein?

Zum einen schaltet man bei Geräten Event-on-Change ein und reglementiert schon mal auf das was man braucht. Zum anderen habe ich nicht für alles direkt ein ganzes Modul am laufen. Immer die waage zwischen sinn und nutzen. Wenn ich zb von ASC nur zwei dinge brauche, dann baue ich die selber bevor ich so rein mächtiges Werkzeug nutze.

Was Genau ist daran quasi so unfassbar?

Einfach auf die IP des shellys gehen, via Browser...

http://123.123.123.123/

BEDENKE! - Auf die IP kommst du NUR wenn du in deinem WLAN/Netz bist. Von außen geht das nur via VPN, Cloud oder Systemen wie FHEM usw. Aber auch diese müsstest du nach außen frei schalten. Ich weiß nicht wie tief du im Thema Netzwerk steckst...

Naja, wenn das der Fall wäre, läuft was nicht richtig. Ich nutze einen Raspi 3 und habe diverse HW aber KEINE Freezes!

Bei sowas immer mal ins LOG gucken und in den EventMonitor. So kann man zumindest sehen wann EVENTs geschehen und was es ggf. sein kann.

Welche Werte genau, werden bei dir nicht schnell genug gezeigt? Geht es um den reinen Status für an/aus oder Verbrauch oder.......?

Hast du mal via MQTT getestet? Ich selber nutze das Modul ungern. MQTT nutzen bei mir viel mehr Geräte und deswegen der Weg. Zudem gibt es ja fertige Templates und man muss fast nichts mehr einstellen.

Zitat von waki

Vielen Dank für Deine ausführliche Erklärung.

Es wäre mir egal, ob die Werte genau angefahren werden oder nicht, aber fhem ist kritisch. Ich verwende das Modul ASC (Automatic Shutter Control) und da ist bei diesem Wetter das shading interessant.

Wenn man jetzt das shading auf pct 10 einstellt und der shelly meldet 8 oder 9 zurück, vermutet das Modul, dass man manuell übersteuert hat und fährt nicht mehr aus der Beschattungsposition heraus.

Ich kann nur hoffen, dass eine neue Firmware für den shelly genauere Anzeigen bringt.

Noch bin ich mir nicht sicher, ob ich die shellies auf Tasmota umflashen will.

cu

Walter

Alles anzeigen

Ahhhhhhhh... Dies Info bezüglich ASC fehlte. Das nutze ich nicht. Ich habe mir die Funktionen, die ich brauche, selber erstellt und deswegen kein Problem. Du könntest mal prüfen ob es ein attr gibt, welches das Übersteuern erlaubt und somit auch aus der Position holt. Ich bin mir sicher das ich das gelesen hatte.

Was die FW 1.5.1. angeht, kann ich das so nicht nachvollziehen. Die Kalibrierung ist an sich schon mal nicht schlecht. Die wird auch nicht Schuld sein... Die Positionierung wird aber sicherlich verbessert.

Hey waki,

ich weiß nicht ob ich dir die Antwort im FHEM Forum schon gab aber es ist bei den Shellys leider so. Die PCT, die FHEM bekommt, bekommt er vom Shelly!

Wenn du also PCT 60 als Beispiel ansteuerst und der Shelly dann 62 oder so daraus macht, kann FHEM nichts dagegen tun. Ich kenne das Phänomen und habe das selber bei den Shellys mit original FW.

Anbei mal ein Bild, was zeigt wie ich das meine und du es auch kennen wirst. Alle Rollos wurden mit dem gleichen Befehl auf Position 81 gestellt. (Bei mir ist 100% = zu).

Ich weiß leider nicht zu 100%, wie die Shellys ihre Position bestimmen. Zum einen gibt es die Spannung. Diese kann natürlich nur am Ende oder Anfang nicht vorhanden sein. Alles was mittig liegt ist dann einfach über die Zeit bestimmt. Bei Tasmota kann man auch manuell die 50% fest legen. Das fehlt bei der Shelly FW auch (wurde aber schon angemerkt und steht [glaube ich] sogar in der Wunschliste). Die 50% von der Shelly FW sind bei mir eher so 75%.

Beobachte mal, um wie viel % sich bei dir der Unterschied ergibt. Bei mir sind es immer 3%-4%. Hier kann man nur warten was die Kollegen nachbessern. Mir ist das z.B. egal ob das nun genau 60% sind oder aber 64%. Der Unterschied ist super minimal.

Die Erklärung dazu sollte sein: Shelly stoppt zu spät. Warum? Kann man nur raten. Leider gibt es dazu kein offizielles Statement, welches mir bekannt wäre.

Wieso ist man mit der Antwort unzufrieden? Es gibt leider keine schönere bisher. :-\

Machen die Kollegen im FHEM Forum / oder sogar ich, ja nicht extra, mit den un zufriedenstellenden Antworten....

EDIT: Das Bild mal angefügt... Zu viel geschrieben und hatte es vergessen...

Zitat von diver77

Hallo 87insane

danke für Deinen link, ja das könnte wirklich der gemeinte Thermostat sein, hoffe nur das er wenn er als "Shelly" kommt ohne Bridge auskommt.

Was ich aber auf deren Seite gesehen habe was die noch im Programm haben ist der Fensterrobi.

Hat den vielleicht schon mal einer getestet?

Würde mich brennend interessieren

Danke und der regen ist jetzt leider auch bei uns angekommen.

Gruß Diver

Alles anzeigen

Den hat mein Management beim durchsuchen der Seite auch direkt gesehen... Würde mich auch interessieren.

Was das Thermostat angeht, denke ich, wird es eine andere Shelly FW geben für das Ding und am Ende kann er ohne Bridge. Aber das ist nur das, was ich in meiner Glaskugel gesehen habe

Kannst du die Frage etwas genauer stellen?

Das flashen an sich geht wie bei allen Fremd-FWs auch. Du brauchst einen USB-TTL Adapter und dann kann es schon fast los gehen. Es gibt eigentlich keinen Unterschied z.B. zu Sonoff HW. Klar, die Pinne sind wo anders, aber der Vorgang an sich ist der gleiche.

Ich frage mich nur warum ESPEasy, wo Tasmota doch viel schöner läuft...

bin deiner meinung.

ABER - wenn die das Produkt 1:1 übernehmen würden, müssten sie nix entwickeln. Also schließe ich den "schlechteren" weg aus.

Das ding wird sicherlich mqtt usw können. Hab zb mal simple 868mhz thermostate ein wenig angepasst. Ein wenig tasmota und alles gut. Im Notfall konnte man bisher flashen. Wenn auch das weg fallen würde, würde das in der Tat semi sein.

Aber ich glaube an deren Produkt treue.