Hallo zusammen,
ich habe mir einen Shelly Door/Window 2 gekauft.
Ihn nun in erfolgreich in Fhem eingebunden. Hierzu ein kleines ToDo.
Shelly Door/Window 2
- Als erstes wird der Shelly OHNE Batterien ausgeliefert. Er benötigt 2 Batterien TYP CR123A (Also nicht Handelsübliche Größe :) )
- Konfiguriert habe ich ihn wie gewohnt über WLAN, das der Shelly nach dem Start selbst anbietet (AP Mode), erreichbar dann über IP 192.168.33.1
- Hier dann WLAN SSID und WLAN PW eingegeben. IP Adresse des Shelly im Router suchen und am besten dort angeben, dass dieses Gerät immer die selbe IP erhalten soll.
- Jetzt ist die Weboberfläche im Heimnetz erreichbar
Hinweis: Geht der Sensor in den "SleepModus" muss er aufgeweckt werden, sonst ist die Oberfläche NICHT erreichbar. Aufwecken kann man ihn mit einem Druck auf den "Button" der mit Hilfe einer Büroklammer oder einer SIM nadel von Handy betätigt werden kann. Unter dem kleinen Loch überhalb der LED ist dieser Button. Dort eben mit Hilfe eines dünnen Gegenstandes reindrücken ;-)
- In der Oberfläche unter Internet&Security-->Advanced-Devplorer Settings MQTT auf Enable setzen und die IP des Mqtt Servers und richtigen Port eintragen. Alle anderen Einstellungen so belassen. Mit Save bestätigen
In Fhem:
Vorraussetzung: Mqtt server in Fhem aktiv und installiert
- Mqtt device anlegen define DW2_1 mqtt_device
- folgende Attribute anlegen:
defmod DW2_1 MQTT_DEVICE
attr DW2_1 IODev mqtt
attr DW2_1 devStateIcon open:fts_window_1w_open@red close:fts_window_1w@black
attr DW2_1 event-on-change-reading .*
attr DW2_1 genericDeviceType contact
attr DW2_1 subscribeReading_battery shellies/shellydw2-483FDA824562/sensor/battery
attr DW2_1 subscribeReading_illumination shellies/shellydw2-483FDA824562/sensor/illumination
attr DW2_1 subscribeReading_lux shellies/shellydw2-483FDA824562/sensor/lux
attr DW2_1 subscribeReading_state shellies/shellydw2-483FDA824562/sensor/state
attr DW2_1 subscribeReading_temperature shellies/shellydw2-483FDA824562/sensor/temperature
attr DW2_1 subscribeReading_tilt shellies/shellydw2-483FDA824562/sensor/tilt
attr DW2_1 subscribeReading_vibration shellies/shellydw2-483FDA824562/sensor/vibration
Die Shelly Adresse shellydw2-xxxxxxxxxxxx ist bei jedem Shelly anders und die ID Nummer bekommt man aus der Oberfäche des Shelly unter Settings-->Device Info oder auch im Wlan wird das Gerät so angezeigt (im Router)
Funktionsweise des Shelly. Ändert sich ein Status wacht er auf und sendet kurz VIA mqtt alle Status raus, danach geht er sofort wieder schlafen. Deshalb ist das Gerät auch nie dauerhat über die IP erreichbar bzw Online. Will ich das er Online ist für eine gewisse Zeit, müsst ich ihn über den Button aktivieren. Dann komme ich auf die Oberfläche
Soweit nun passt alles in meiner Fhem Weboberfläche habe ich nun ein Fenster Icon das sich ändert, Schwarz geschloßen = close und Rot offen = open
Jetzt meine Frage
Wie kann ich im State eben mehr anzeigen lassen wie nur das Fenster, Also batterie, temperatur, illumination, lux
In den Readings sind die States ja da
Vielen dank wenn mir da noch jemand nen Tipp hat....
Gruß Albi
Vermute, du suchst das Attribut "stateFormat"?
Wer es mit MQTT2_DEVICE machen will, nimmt einfach das attrTemplate "shellydw", da wird dann auch der "state" direkt zu "tilted" usw.. Startpunkt im Wiki wäre https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele, dort speziell der "Shelly"-Abschnitt.
Ja,
stateFormat ist mir schon ein Begriff. Nur da habe ich noch nie mehr als "state" angelegt bei meinen Geräten wie schalter oder Steckdosen...
Ist völliges Neuland für mich, wie ich dort mehrere Readings anlege.
Werde das Mqtt2 Thema auch mal testen ;-)
Danke
Mit "stateFormat" kann man schon einiges nützliches anfangen, auch was Visualisierung usw. angeht (mehrzeiliges stateFormat+passendes devStateIcon, siehe z.B. zigbee2mqtt_human_body_movement_illuminance (derzeit ab Zeile 538 in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template). In der file sind auch ganz viele andere Beispiele drin (auch für devStateIcon), ist nur ggf. etwas schwer zu lesen, wenn man die Devices "anders" hat.
(Man kann es auch übertreiben, aber das ist ein anderes Thema).
(Prinzipiell würde übrigens auch MQTT_DEVICE AttrTemplate unterstützen, das würde aber dann ein eigenes attrTemplate-file benötigen, weil die Attribute ganz anders sind...)
Okay,
habe es jetzt über mqtt2 gelöst.
habe einfach einen mqtt2 Client angelegt und dann das mqtt2 Device mit entsprechendem Template.
Zumindest zeigt es mir nun das Fenster open/close und gekippt an
Und deutlich mehr Readings sind da, wie zb die IP des Shellys
Danke erst mal
Bitte aber trotz des schnellen Erfolges noch zwei Dinge zu beachten:
- Bei MQTT2_CLIENT sollte man sinnigerweise noch ein "Sortierdevice" dazwischenschalten, siehe Artikel MQTT2_CLIENT im Wiki.
- Shelly sind "gesprächig". Auch dazu steht ein kurzer Hinweis ganz zu Beginn des Abschnitts zu "Shelly" in den "Praxisbeispielen". MAn. sollte man die Dinger unbedingt "bändigen", sonst hat man viel zu viele unnötige Events, die das System an der falschen Stelle beschäftigen...
Danke das war ein guter Tipp ;-)
http://<ip-shelly>/settings?mqtt_update_period=0,
Danke!
Danke für die Rückmeldung!
Setzt du den Thread bitte noch "ordnungsgemäß" auf [gelöst] oder ist noch was an Wünschen offen ;) ?
Hallo,
interessanter Tipp, die Gesprächigkeit der Shellys mit "http://<ip-shelly>/settings?mqtt_update_period=0" zu bändigen.
Welche Auswirkungen auf fhem hat denn der Wert "0"?
Dann kommt doch gar kein Update mehr. Oder?
lg, Gerhard
Es sollten keine "regelmäßigen" Updates mehr geben, was auch immer das im Einzelfall und bezogen auf das jeweilige Gerät (bzw. die jeweilige firmware-Version) auch heißen mag.
Ich hatte zugegebenermaßen bei meinen letzten Posts zum Thema "Geschwätzigkeit" auch nicht mehr im Auge, dass das mit der mqtt_update_period im Zusammenhang mit den Shelly schon (mutmaßlich sehr lange) im Wiki stand (aber zum Glück meistens dazugeschrieben, dass man als erstes nach Konfigurationsmöglichkeiten an der firmware suchen sollte...).
Irgendwie hatte ich jetzt noch im Ohr, dass das
1. z.B. nicht updates zu Verbrauchsdaten u.ä. unterbindet, und
2. sich nicht über den MQTT-Weg setzen läßt.
Vermutlich ist das Thema unter "Shelly DW2" nicht wirklich gut aufgehoben.
Meine Bitte ist nach wie vor: Wir sollten das (ggf. eben dann als "gute" Vorgabe pro Device-Typ irgendwie "besser" an "den Mann" bringen. Gut vorstellen könnte ich mir, das jeweils im zugehörigen attrTemplate in comment (=> Attribut) und farewell (=> Das bekommt der User nach Anwenden des attrTemplate angezeigt) aufzunehmen.
Das geht aber nur, wenn ich "Futter" bekomme ;) . Und: jeder Weg beginnt mit dem ersten Schritt...
Hallo,
ich habe bei mir den über MQTT eingebunden und sehe:
shellies/shellydw-xxxxxx/sensor/state open
shellies/shellydw-xxxxxx/sensor/tilt -1
shellies/shellydw-xxxxxx/sensor/vibration 0
shellies/shellydw-xxxxxx/sensor/lux 17
shellies/shellydw-xxxxxx/sensor/illumination dark
shellies/shellydw-xxxxxx/sensor/battery 100
shellies/shellydw-xxxxxx/sensor/error 0
shellies/shellydw-xxxxxx/sensor/act_reasons ["sensor"]
D.h. das könnte man alles Abfragen.
Da mich das letzte Öffnen interessiert, dann noch das:
attr Reed.Shelly userReadings Zeitstempel \
{\
ReadingsTimestamp("Reed.Shelly","Zustand",0) =~ /^(\d+)-(\d+)-(\d+)\s(\d+:\d+):(\d+)$/;;\
return "Datum: $3.$2.$1, Uhrzeit: $4";;\
}
Grüße Peter
Mal abgesehen davon, dass mir nicht klar ist, für was man so ein weiteres Reading braucht, und was mt "abfragen" gemeint sein soll (das Ding pusht doch, oder?): trigger fehlt => unsaubere Lösung
Hallo,
wenn man was davon brauchen kann, dann kann man das Abfragen. Also simple, was ist an Info verfügbar.
Ich liebe Killerphrasen wie >> unsaubere Lösung << ;-) Fakt ist, es zeigt bei mir den letzten Timestamp des Öffnens. Evtl. läuft ja eine andere Einstellung, da das dann refreshed.
Falls man was verbessern kann, dann immer raus damit. Das Forum sollte zeigen was machbar ist, oder helfen bessere Lösungen zu nutzen und das hier ist ein Vorschlag. Wenn es eine bessere oder saubere Lösung gibt, dann würde ich mich über diese freuen.
Peter
Im Gegenzug liebe ich "unsaubere postings" wie deines:
- keine Code-Tags
- Unsauberes wording: "Abfragen" verbinde ich mit "pollen". Diese Werte werden aber ungefragt an FHEM übermittelt, also gepusht, so jedenfalls bei Topics als Bezugspunkt!
- Dass man innerhalb FHEM den letzten übermittelten Wert "abfragen" kann, ist klar, darauf bezog sich aber dein Code-Auszug nicht.
- Und ein userReading, das Infos einfach nur umpackt, ist m.E. schlicht sinnlos.
- Dass das als userReading-Eintrag "unsauber" ist, weil kein trigger verwendet wurde, kann man als "Killerphrase" abtun oder einfach zum Anlass nehmen, mal in die commandref (oder das Wiki) zu userReadings zu sehen.
Falls man dann was nicht verstanden hat, bekommt man auf höfliche Fragen vielleicht auch eine höfliche Rückmeldung, aber Unsinn (s.o.) auch noch zu korrigieren, sehe ich gar nicht ein :P .
ZitatDa mich das letzte Öffnen interessiert, dann noch das:
attr Reed.Shelly userReadings Zeitstempel \
{\
ReadingsTimestamp("Reed.Shelly","Zustand",0) =~ /^(\d+)-(\d+)-(\d+)\s(\d+:\d+):(\d+)$/;;\
return "Datum: $3.$2.$1, Uhrzeit: $4";;\
}
Das liefert meiner Meinung nach nicht "das letzte Öffnen", sondern die Uhrzeit der letzten Aktualisierung des Readings "Zustand" (könnte auch "closed" sein)
Hallo,
leider stimmt das :( Hatte das 0 als Zustand interpretiert, dem ist aber nicht so.
Danke für den Hinweis, da muss ich wohl noch etwa an der Logik feilen.
Grüße Peter
Könntet ihr für dieses Thema einen neuen Thread aufmachen?
Das Problem des TE ist gelöst, und das Umformatieren des Zeitstempels ist und bleibt Unsinn, insbesondere, wenn ggf. dann auch noch der Zustand regelmäßig aktualisiert wird, auch ohne Änderung und ohne Berücksichtigung, ob jetzt geöffnet oder geschlossen war... :P
(Falls jemand sinnvolle (!) Verbesserungswünsche zum attrTemplate hat: her damit; ich weiß nämlich nicht, wann welche Infos übermittelt wurden und kann daher auch keine Ideen zu timestamp-on-change-reading entwickeln (falls man das hier benötigt)...)