Guten Abend, kennt jemand den Shelly Button
https://shop.shelly.cloud/shelly-button-wifi-smart-home-automation (https://shop.shelly.cloud/shelly-button-wifi-smart-home-automation)
und weiß, ob und wie man ihn einbinden kann? Es steht auf der Webseite
Compatible with Shelly 1, Shelly 1PM
und eventuell kaufe ich mal einen und probiere den aus? Hier im Forum hatte ich mit der Schnellsuche nichts gefunden.
Das ist nur ein leeres Plastikgehäuse in das du eben einen Shelly1 bzw. Shelly1PM schön einbauen kannst. Dann hast du z.b. an einer Lampe einen smarten Button (in dem eben ein normaler Shelly werkelt).
Gesendet von meinem GM1913 mit Tapatalk
Ah danke, ich dachte das wäre ein batteriebetriebener Taster.
Hallo Zusammen,
jetzt scheint es einen Button zu geben, für die welche es interessiert:
https://shop.shelly.cloud/shelly-button1-wifi-smart-home-automation
Gruß
Tino
hat das Ding schon Jemand im Einsatz?
Mir ist die Funktion nicht ganz klar.
Ist das WLAN ständig on, d.h. die Reaktion im FHEM ist "sofort"?
Oder verbindet der sich nach Tastendruck erst mit dem WLAN und löst dann die Aktion aus, das wäre mit einer großen Verzögerung verbunden (vergleichbar zum Dash-Button)?
Grüße
Andreas
Hallo Andreas,
habe 2 von den Dingern im Einsatz. Im Batterie bzw. Akkumodus dauert es so gefühlte 10 Sekunden, bis alles in FHEM angekommen ist.
Wenn Du die Teile aber über einen MicroUSB-Adapter mit Strom versorgst, senden sie direkt.
Bei mir habe ich das ganze via MQTT und Mosquitto eingebunden.
Gruß Rainer
Zitat von: dora71 am 07 September 2020, 21:36:38
Hallo Andreas,
habe 2 von den Dingern im Einsatz. Im Batterie bzw. Akkumodus dauert es so gefühlte 10 Sekunden, bis alles in FHEM angekommen ist.
[...]
Bei mir habe ich das ganze via MQTT und Mosquitto eingebunden.
Gruß Rainer
Schade die zehn Sekunden sind mir irgendwie zu lange, ich hatte bei Reichelt gelesen, dass es nur 2 Sekunden dauert. Scheinbar dauert die Übermittlung per MQTT so lange ...
Gibt es noch andere Erfahrungsberichte?
Grüße
Andreas
Hallo
ich habe auch einen shellybutton1 im Einsatz. Also 10 Sekunden sind es bei mir definitiv nicht. Ich würde mal eher auf 3-4 Sekunden schätzen, was natürlich trotzdem eine spürbare Verzögerung ist.
Allerdings ist er deutlich schneller, als meine dashbuttons von Amazon, die noch im Einsatz sind.
Ich finde halt fein, dass man 4 verschieden Aktionen damit steuern kann.
Angeschlossen als MQTT2_DEVICE.
Grüße
Saimenberry
Hi simonberry,
Wie lange hält der Akku?
Aus dem Tiefschlaf muss der ESP aufwachen und sich mit dem WLAN verbinden, das wird sehr individuell sein. "Gefühlt" ist zwischen 2 3 4 und 10 sec kein "großer" Unterschied. Der Mensch empfinden > 0,4 sec als spürbare Verzögerung ;)
Gruß Otto
Hallo Otto,
ZitatWie lange hält der Akku?
Dazu kann ich noch nicht viel sagen, da ich Ihn sehr selten benutze. Nach den ersten Gehverusuchen und Spielereien habe ich ihn erstmal wieder aufgeladen.
Jetzt ist er bei 82% und wird bei schönem Wetter ab und zu gedruckt, um die Terrassenbeleuchtung (RGBW Farbverlauf Lampe) zu steuern. (An,Aus, Farbverlauf, Putzlicht-Weiß)
Gruß
Simonberry
Tja, wenn man für solche einfachen Anwendungen auf MQTT setzt, hat man das mit der Verzögerung auch verdient....
Das bedeutet wirklich, mit Kanonen auf Spatzen zu schießen. Viel besser ist, in die Konfiguration des Button (per Webseite des Buttons) als URL, die beim einfachen, zweifachen, dreifachen und langen Tastendruck aufgerufen wird, einen REST-Befehl an FHEM einzubauen. Das wird innerhalb einer halben Sekunde in FHEM empfangen und kann in beliebige Befehle umgesetzt weren.
LG
pah
Wie soll das gehen, wenn der Button per Akku Betrieb im Tiefschlaf sitzt? Was hat das denn mit MQTT zu tun?
Die Verzögerung ist doch der Anmeldung / Verbindung zum Wlan geschuldet!?
Gruß Otto
Frag mich nicht - aber bei mir taucht das Verzögerungsproblem nicht auf.
LG
pah
Ich kann auf der Webseite kein Datenblatt o.Ä. erkennen. Man kann also durch den Tastendruck eine URL aufrufen? Oder wie machst du das genau?
Ja. Schau in die CommandRef des Shelly-Moduls, da steht ein Beispiel drin. Button setzt einfach den Wert eines Dummy auf "single", "double" oder "triple", ein DOIF macht dann das eigentliche Kommando.
LG
pah
Abseits jeder anderen Anwendung die Orignal Referenz https://shelly-api-docs.shelly.cloud/#shelly-family-overview
Konkret https://shelly-api-docs.shelly.cloud/#shelly-button1-settings-input-0
Oder welches Datenblatt meinst Du?
Gruß Otto
danke, genau das hatte ich nicht gefunden
Konkret ist immer besser.
shortpush_url "http://192.168.0.90:8083/fhem?XHR=1&cmd.WZ.SB=set%20WZ.SB%20short"
double_shortpush_url "http://192.168.0.90:8083/fhem?XHR=1&cmd.WZ.SB=set%20WZ.SB%20double"
triple_shortpush_url "http://192.168.0.90:8083/fhem?XHR=1&cmd.WZ.SB=set%20WZ.SB%20triple"
longpush_url "http://192.168.0.90:8083/fhem?XHR=1&cmd.WZ.SB=set%20WZ.SB%20long"
LG
pah
Huhu zusammen,
Ich habe mit einen Shelly Button 1 zur Ergänzung gekauft und fleißig FHEM upgedatet, also auch das Shelly FHEM Modul.
Ich habe das neue Gerät abgelegt, allerdings konnte ich unter dem Punkt ,,Model" den Button 1 nicht auswählen, was mache ich falsch? Mit den ,,Model" ,,generic" klappt es nicht...
Vielleicht hat ja jemand einen Tipp :-)
Vielen Dank Euch!
Natürlich kann man nicht auswählen, was nicht definiert ist. Das Modul 36_Shelly.pm macht überhaupt keinen Sinn für dieses Gerät. Bitte einfach den gesamten Thread lesen.
LG
pah
Hi,
Vielen Dank für die schnelle Rückmeldung!
Ich habe den Button1 nun per MQTT angebunden, klappt wunderbar!
Danke!
Hallo FHEM-Gemeinde,
da ich mir jetzt auch einen Shelly-button1 zugelegt habe möchte ich hier meinen Senf zugeben, evtl. hilft es dem einen oder anderen weiter der ebenfalls mit dem Gedanken spielt sich einen Shelly-button1 anzulegen.
Zitat von: Otto123 am 10 September 2020, 09:01:44
Wie soll das gehen, wenn der Button per Akku Betrieb im Tiefschlaf sitzt? Was hat das denn mit MQTT zu tun?
Die Verzögerung ist doch der Anmeldung / Verbindung zum Wlan geschuldet!?
Gruß Otto
Otto, ich gebe dir vollkommen recht, es geht nicht. Sobald der Button1 nicht an der USB-Versorgung hängt geht er in den Tiefschlaf und es dauert, wahrscheinlich kommt es hier auch etwas auf seine WLAN-Hardware drauf an, einige Zeit, bis sich der Button im WLAN-Netz angemeldet hat. Das ist unabhängig von der Übertragungsart. MQTT und/oder REST waren bei meinen Tests im etwa gleich schnell. Im Akkubetrieb dauert es bei mir ca. 5 Sek. (UNIFI-Netzwerk) mit USB-Versorgung kommt das Signal gefühlt sofort in FHEM an.
Die Nutzung des FHEM-Shelly-Moduls ist in sofern möglich und sinnvoll da es u.a. den Ladezustand anzeigt oder auch "trigger-readings" bereitstellt auf die man reagieren kann (siehe list).
Evtl. kann der Modulautor den Button1 doch noch als Modell hinterlegen und den "Error" im STATE und state mit was anderem beschreiben aber im Grunde kann man das Modul auch so nutzen (ohne Modell).
Internals:
CFGFN
DEF 192.168.12.168
DURATION 0
FUUID 60ccbdfb-f33f-34fb-72bf-439f58ed3e01c887
INTERVAL 60
NAME shelly_button.ma
NR 8582
SHELLYID E8DB84AA1A45
STATE Error
TCPIP 192.168.12.168
TYPE Shelly
READINGS:
2021-06-18 17:38:35 battery 100
2021-06-18 18:35:23 cfgChanged 0
2021-06-18 18:52:34 charger 1
2021-06-18 17:39:35 cloud disabled
2021-06-18 17:39:35 firmware v1.10.3
2021-06-18 18:53:46 inputEventCnt_0 14
2021-06-18 18:53:46 inputEvent_0 S
2021-06-18 18:53:20 network <html>connected to <a href="http://192.168.12.168">192.168.12.168</a></html>
2021-06-18 17:38:35 sensorError 0
2021-06-18 18:52:20 state Error
2021-06-18 18:52:34 wakeupEvent ext_power
Attributes:
shellyuser admin
Also
- wer eine sofortige Reaktion benötigt, der sollte den Shelly-button1 über die USB-Versorgung betreiben. Ob die Übertragung der Daten dann über MQTT, REST-Befehl oder über das Shelly-Modul und Weiterverarbeitung der entsprechenden Trigger über notify oder DOIF....stattfindet spielt dabei nur eine unwesentlich geringe Rolle.
- im Akkubetrieb kann es mehrere Sekunden dauern bis sich der Button1 im Netzwerk zurückgemeldet und das Signal an FHEM übertragen hat. Auch hier spielt die Übertragungsart nur eine kleine Rolle.
Bis dahin
frohes Schaffen
Hast du eine fixe IP BEIM/IM Button vergeben?
(also NICHT "Reservation" im DHCP)
Als ich noch mit ESP "rumgetan" habe war ein deutlicher Unterschied bei der Anmeldung mit fixer IP gegenüber DHCP.
Gruß, Joachim
Hi! Ich hab zwei Buttons angemeldet mit jeweils fixer IP-Adresse (also nicht MQTT)
So wie ich das verstehe, muß dem Button der Befehl über die GUI eingetragen werden, der dann von FHEM ausgeführt wird. Lieg' ich da richtig? Oder gibts eine "better practice"
Was mich aber stört - und ev. hab da jemand eine Idee - ist, dass das log mit Error-Meldungen geflutet wird, wenn der Button idle ist.
greets
Hi,
welches Log wird geflutet?
Zitat von: Prof. Dr. Peter Henning am 28 April 2021, 10:56:57
Natürlich kann man nicht auswählen, was nicht definiert ist. Das Modul 36_Shelly.pm macht überhaupt keinen Sinn für dieses Gerät. Bitte einfach den gesamten Thread lesen.
Gruß Otto
Zitat von: saxandl am 28 Juli 2021, 09:54:00
Was mich aber stört - und ev. hab da jemand eine Idee - ist, dass das log mit Error-Meldungen geflutet wird, wenn der Button idle ist.
Wie wär's denn dann mit den Meldungen? 8)
Und wie wär's mit dem Befehl, den du eingegeben hast (also im Shelly)...
...und evtl. einem list.
Gruß, Joachim
Der shelly-button geht offline, nachdem er ausgelöst hat. Ich dachte, das geht aus dem Fred hervor.
eingerichtet mit
define Button1 Shelly 192.168.15.53
nach 5 Sekunden - das lässt sich im GUI des Button einstellen, geht der Button offline. Das löst die nachstehende Zeile im log aus:
[Shelly_status] has error connect to http://192.168.15.53:80 timed out
und zwar jede Minute
@MadMax-FHEM
das list - wenn es das ist, was du meinst:
Internals:
DEF 192.168.15.53
DURATION 0
FUUID 60ffcb25-f33f-0898-632b-b5855532d04f5b70
INTERVAL 60
NAME Button2
NR 433
STATE Error
TCPIP 192.168.15.53
TYPE Shelly
READINGS:
2021-07-28 10:52:32 network not connected
2021-07-28 10:52:32 state Error
Attributes:
room button
Aber macht es Sinn, sich über ein Verhalten zu wundern, wozu der Autor des Moduls klar sagt: die Verwendung für dieses Device macht keinen Sinn?
Also macht es Sinn mit dem Auto in den See zu fahren und hinterher zu sagen: es schwimmt offenbar doch nicht!?
Zitat von: Otto123 am 28 Juli 2021, 11:03:00
Aber macht es Sinn, sich über ein Verhalten zu wundern, wozu der Autor des Moduls klar sagt: die Verwendung für dieses Device macht keinen Sinn?
Also macht es Sinn mit dem Auto in den See zu fahren und hinterher zu sagen: es schwimmt offenbar doch nicht!?
Da kann ich nur zustimmen :)
Aber irgendwie hast du @saxandl doch auch was in die Shelly-GUI eingetragen ("Button Activity" oder so / I/O url actions [falls es das beim Button gibt, habe keinen])?
Weil du ja wenn du dort drückst etwas in fhem "ausgelöst" haben willst?
Das fehlt noch... ;)
Das ist (soweit ich das "umrissen" habe) der Sinn des Buttons (mit fhem)!?
Ansonsten Anbindung per MQTT, dann sendet der Shelly u.U. beim Drücken "einfach so" was...
...allerdings gibt es auch da eine Art "Client-Überwachung", sofern der Client "sagt", dass er sich hin und wieder/regelmässig meldet...
Gruß, Joachim
@Otto123
ZitatAber macht es Sinn, sich über ein Verhalten zu wundern, wozu der Autor des Moduls klar sagt: die Verwendung für dieses Device macht keinen Sinn?
Woran glaubst du zu erkennen, dass ich das Modul 36_Shelly.pm verwende?
Ich möchte nochmal auf meine ursprüngliche Frage zurückkommen:
Lässt sich - und wenn ja wie - die Ausgabe der Error-Meldung im Logfile unterdrücken?
an deinem List?
ZitatTYPE Shelly
ZitatLässt sich - und wenn ja wie - die Ausgabe der Error-Meldung im Logfile unterdrücken?
eventuell durch verbose 0 am Device bzw. das Modul gar nicht erst verwenden / die definition löschen, weil nutzt Dir ja nichts!?
Wobei in #21 in dem Device mehr zu sehen ist als bei Dir? Aber es wird ja im gesamten Thread eigentlich genau das beschreiben über was wir jetzt diskutieren.
Empfehlung: Button einfach so mit den http Befehlen verwenden - oder per MQTT anbinden und die Auswertung/Steuerung FHEM überlassen.
Zitat von: saxandl am 28 Juli 2021, 11:19:18
@Otto123
Woran glaubst du zu erkennen, dass ich das Modul 36_Shelly.pm verwende?
Naja spätestens seit deinem geposteten list ;)
Zitat
TYPE Shelly
Zitat von: saxandl am 28 Juli 2021, 11:19:18
Ich möchte nochmal auf meine ursprüngliche Frage zurückkommen:
Lässt sich - und wenn ja wie - die Ausgabe der Error-Meldung im Logfile unterdrücken?
u.U. in dem du das Intervall-Attribut auf 0 setzt.
Trotzdem noch mal: warum das Shelly-Modul überhaupt?Gruß, Joachim
@all
Ich denke, ich hab's verstanden: Es ist nicht erforderlich, den Button in FHEM zu definieren oder anzulegen, weil
der Befehl über http vom Button an FHEM ausgelöst wird.
danke ;)
Hatte ich noch editiert:
Empfehlung: Button einfach so mit den http Befehlen verwenden - oder per MQTT anbinden und die Auswertung/Steuerung FHEM überlassen.
Aber bitte csrf-Token beachten!
Und: nicht einfach auf "none" setzen!!
Gruß, Joachim
Guten Abend,
ich bekomme vom Button u.a. diesen String übergeben:
mqttSubscribe state:topic=shellies/shellybutton1-xxxxxxxx/input_event/0
state bekommt dann {"event":"S","event_cnt":30}
Wie komme ich an das S oder ggf L ran um es entsprechend auszuwerten?
Schonmal vielen Dank vorab.
Gruß
Hi,
eventuell mit expandJSON https://fhem.de/commandref.html#expandJSON
Gruß Otto
MGB kann mittel expression auch direkt json2nameValue(). Bsp. siehe commandref zu MGB.
Nachtrag noch:
Zitat von: TheDAG am 27 Oktober 2021, 22:59:12
ich bekomme vom Button u.a. diesen String übergeben:
Mal abgesehen davon, dass man das nur versteht, wenn man weiß, wie es zu lesen ist - warum kommt hier überhaupt MQTT_GENERIC_BRIDGE zum Einsatz und nicht direkt MQTT2_DEVICE? Sollte doch im Ergebnis viel einfacher sein...
Ich nutze MQTT2_Server und soweit ich mich erinnere wurde automatisch ein MQTT2_DEVICE u.a. mit den readings "event" und "event_cnt" erzeugt.
event S 2021-10-27 18:32:46
event_cnt 3 2021-10-27 18:32:46
Diese werden geändert, wenn man den switch drückt.
Evtl. auch attrTemplate shelly1 anschauen.
Vielen lieben Dank für die schnelle Hilfe und Tipps die dann per STRG + C / V zu diesem Ergebnis geführt haben:
state:topic=shellies/shellybutton1-xxxxxxxx/input_event/0 state:expression={json2nameValue($value)}
event L
event_cnt 49
Um die Frage noch zu beantworten:
MQTT_GENERIC_BRIDGE nutze ich, weil damit habe ich irgendwann mal angefangen und bis heute läuft es ohne Probleme :-)
Bin da ein Gewohnheitstier . . .