Hallo,
ich habe mein Shelly i3 in Fhem eingebunden.
"Shelly i3" gibt's aber als model nicht.
Was tun?
Danke in Voraus für die Hilfe.
Gruß
Andi
Wie hast du denn eingebunden?
Shelly Modul? -> da wird es wohl nichts geben (wozu auch wie hier zu lesen https://forum.fhem.de/index.php/topic,93251.msg1090043.html#msg1090043)...
Bzgl. mqtt habe ich leider keine Ahnung bzw. geht es dort meist mittels attrTemplate.
Gruß, Joachim
Hah - da hänge ich mich ja direkt mal dran ...
"Shelly i3" ist sowas hier: <https://www.amazon.de/dp/B089GWDS19/> und das bestelle ich jetzt mal gleich testweise.
Meine Kenntnisse bzgl. Elektroinstallation sind höchst theoretische, was man so in zwei Semestern E-Technik mithörte. Also die Installation wird mein Elektriker machen.
Meine Shelly-Kenntnisse sind auch höchst theoretisch, sie bestehen in der Kenntnis des zuständigen Wiki-Artikels sowie dem Wissen, dass es ein FHEM-Modul für Shelly gibt. Weiterhin glaube ich zu wissen, dass @pah das geschrieben hat. Vielleicht kann er zu dem verlinkten Modul etwas sagen, was nicht auf den Namen MTQ-Dingens hört.
@Andi.Riese
Nun lass mich mal nicht dumm sterben: Welches konkrete Gerät hast Du? Und wie hast Du das ganz konkret in FHEM eingebunden? Ja klar: Code zeigen, bitte.
Naja, wie im Link von mir zu lesen:
der I3 sendet ja bei Drücken http-Requests.
Da ist die Aussage (so ich sie verstanden habe), dass damit ja DIREKT Kommandos in fhem ausgelöst werden können:
http://<fhem-IP>:<fhem-Port>/fhem?cmd=set%20Lampe%20off&XHR=1
Bzgl. shelly gibt (und wird es auch nicht?) ein Modell etc. geben, weil "unnötig", da ja der I3 nicht "steuerbar" ist und auch keinen "Zustand" hat (sofern ich das "verstanden" habe)...
Bzgl. MQTT weiß ich (wie geschrieben) nicht...
...und auch der verlinkte Thread geht ja zum Shelly Modul (weil ja der TE nach "model" gefragt hat und soweit ich das im Kopf habe gibt es "model" eher beim Shelly-Modul als bei MQTT. Bei MQTT gibt es ja eher sowas wie die attrTemplates) dort wird nur erwähnt, dass es wohl mittels MQTT "anders" sein soll...
Gruß, Joachim
Hallo,
also ich habe mein Shelly i3 über MQTT2 eingebunden (es meldet sich selbst als ix3).
Läuft ohne Probleme und sogar ich habe das als Laie hingebracht.
Ich würde da keine Scheu haben mal MQTT2 zu probieren.
lg, Gerhard
Vorbemerkung: Ich habe mir dieses i3 sowie ein V1-Shelly-Dingens einfach mal bestellt. Ziel der Veranstaltung ist, einafch mal zu verstehen, was damit real möglich ist (und ob das für mich sinnvoll ist). Dabei bin ich allerdings tatsächlich auf einen Elektriker angewiesen.
Zitat von: MadMax-FHEM am 27 November 2020, 09:40:24
der I3 sendet ja bei Drücken http-Requests.
Gilt das auch für Schalter mit zwei Schaltzuständen, Gerhard? @gestein
Zitat von: MadMax-FHEM am 27 November 2020, 09:40:24
Da ist die Aussage (so ich sie verstanden habe), dass damit ja DIREKT Kommandos in fhem ausgelöst werden können:
http://<fhem-IP>:<fhem-Port>/fhem?cmd=set%20Lampe%20off&XHR=1
Ok, verstanden. @MadMax-FHEM
Zitat von: MadMax-FHEM am 27 November 2020, 09:40:24
Bzgl. shelly gibt (und wird es auch nicht?) ein Modell etc. geben, weil "unnötig", da ja der I3 nicht "steuerbar" ist und auch keinen "Zustand" hat (sofern ich das "verstanden" habe)...
Aberaberaber es gibt doch 36_Shelly.pm von @paf ... wofür ist das dann gut, wenn es für nix gut ist?
Zitat von: gestein am 27 November 2020, 14:13:09
Ich würde da keine Scheu haben mal MQTT2 zu probieren.
Danke für den Hinweis. Offen gesagt möchte ich das nicht, das werden mir zu viele Protokolle.
Auch die Aktoren (falls du das mit Schalter EDIT: "Shelly V1 Dingens" meinst?) senden bzw. können einen Aufruf bei Betätigung absetzen...
Das ist dann Statusmeldung per "push" oder man schaltet weitere Geräte damit...
EDIT: quasi direktes verbinden von Geräten, die per HTTP (oder mqtt) steuerbar sind. So kann ein I3 auch direkt einen anderen Shelly-Aktor steuern. OHNE fhem. Also der I3 sendet einen "Schalt-Request" in HTTP an den Shelly1 und dieser schaltet ganz ohne fhem ;) So lässt sich aber nat. auch ein dummy (oder was anderes) in fhem steuern. Oder eben auch der Schaltstatus "sofort" übermitteln...
Ansonsten ist shelly.pm (soweit ich verstanden habe) pollend...
Die Anbindung per MQTT ist da eben (generell) anders...
Oder meinst du die "Buttons"?
Die sind wie der I3 nur mit Batterie (soweit ich das mal "überflogen" hab)...
EDIT: vermutlich meintest du mit Shelly V1 Dingens eher einen Shelly1 (Schaltaktor)... ;)
Ja, es gibt das Shelly-Modul.
Dort ging ja mein Link hin.
Dort ist eben von pah selbst persönlich zu lesen, dass er die Integration des I3 als (noch) nicht sinnvoll empfindet.
Da dieser ja NICHT geschalten werden kann und wohl auch KEINEN Status hat.
D.h. der setzt halt auf Betätigung u.a. einen HTTP-Request (oder mqtt oder oder) ab...
D.h. dort (Shelly-Modul) sind (aktuell) nur Aktoren drin. Bzw. Geräte die sich steuern lassen (und einen Status haben).
EDIT: das Shelly V1 Dingens (Shelly1 !?) geht mit dem Shelly-Modul. So habe ich auch einen Shelly1 eingebunden :) Aber: wenn du nichts weiter tust (im Shelly) dann wird der Status "gepollt". Also du schaltest an lokal angeschlossenen Schaltern (am Shelly) und der Status, dass geschalten wurde kommt halt dann beim nächsten "Poll" in fhem an. Wenn du das "schneller" haben willst: mqtt ODER eben einen HTTP-Request VOM Shelly (über dessen Oberfläche konfigurieren) an fhem und dann eben den Status sofort setzen (ist irgendwo entweder im verlinkten Thread zum Shelly-Modul von pah zu lesen oder in der commandref? [habe mir die zu Shelly nie durchgelesen, ich kann mit "Pollingaktualisierung" leben ;) ] oder Wiki [wenn es eines zum Shelly-Modul selbst gibt, das "Shelly-Wiki" zeigt mWn nur die generellen Möglichkeiten der Einbindung auf])...
Selbst einen Shelly HT (humidity/temperature) "wollte" er (pah) nicht integrieren...
(hatte ich gedacht/gehofft als ich mir da mal einen gekauft hatte / "musste" ihn aber dann eben [nach "Ablehnung" ;) ] per mqtt integrieren)
Gruß, Joachim
P.S.: ein paar Shelly hab ich aber ich will nicht zu viel WLAN Zeugs. Finde da manches interessant aber wird wohl nie "groß" bei mir "einziehen"... ;)
Hallo,
Dein ,,Schalter mit zwei Schaltzuständen" benötigt dann 2 Eingänge am i3.
Sollte ohne Probleme gehen.
Zu beachten ist, dass der anscheinend i3 wie ein ,,Durchgangsprüfer" funktioniert.
D.h., Du brauchst potentialfreie Schalter.
Ich wollte einen alten Bewegungsmelder anschließen, der 230V abgibt.
Daher musste ich ein Relais dazwischen schalten.
Aber es klappt ohne Probleme.
Lg, Gerhard
Ergebnis (was ich wissen wollte)
shelly i3 -> fhem
Im shelly kann bei den Inputs unter Zahnrad - Actions für jede Action eine URL eingetragen werden:
http://<ip>:8083/fhem?XHR=1&cmd.<device>=<fhemcommand>
also konkret beispielsweise um eine Lampe lamp in Fhem einzuschalten::
http://raspi:8083/fhem?XHR=1&cmd.lamp=set%20lamp%20on
dabei steht
<fhemcommand> für einen Fhem-Befehl, wobei Zwischenräume durch %20 ersetzt werden müssen
<ip> für die IP-Nummer im Heimnetz oder name, bei mir z.B. "raspi"
XHR=1 keine Ahnung
Device muss sozusagen 2x aufgeführt werden
fhem -> shelly-i3
Umgekehrt gibt es nichts.
Ich habe jedenfalls nichts gefunden.
Umgekehrt fhem-> I3 macht ja auch keinen Sinn, es ist ja nur ein ("Knopfdruck")Sender...
(ist auch der Grund warum wohl pah da nix ins Shelly-Modul einbauen will/wird)
Allerdings fehlt in deinem Aufruf das csrf-Token!
Wenn du es deaktiviert hast: SCHLECHTE IDEE!! (meine Meinung. Lesen wozu das da ist!)
Besser: einen fixen Token wählen...
EDIT: und u.U. auch ein separates FHEM-Web (mit weiteren Einschränkungen, Stichwort: allowed) für den I3 (und "Konsorten")...
Gruß, Joachim
Ja.
Sollte ich wahrscheinlich machen.
Allerdings wüßte ich nicht, wie ich mich in meinen RasberryPi bzw. ins Wlan einhacken könnte.
Noch mal in aller Deutlichkeit: Das Shelly-Modul ist für Aktoren gedacht und kommuniziert mit diesen über http
REQUEST. Die Kommunikation wird also immer vom Modul ausgelöst - auch wenn ich auf regelmäßiges Pollen verzichte und per get device ... abfrage.
Damit kann man ein batteriebetriebenes Gerät sehr schnell leernudeln, es ist also nicht sinnvoll, das z.B. für einen Shelly HT zu machen, der von sich aus in regelmäßigen Abständen die Temperaturwerte sendet. Also sinnvolle Lösung für den HT: MQTT
Es ist auch nicht sinnvoll, einen Tastenzustand zu pollen - nicht einmal bei einem netzbetriebenen I3. Die Funklast wäre immens, und für einen solchen Unsinn bin ich nicht zu haben. Darüber hinaus kann ich durch die Konfiguration des I3 (oder des Shelly Button)
jedes beliebige FHEM Event auslösen - also warum um Himmels Willen sollte man dafür ein extra Modul benötigen? Wer das verlangt, hat FHEM grundlegend nicht verstanden.
Ich habe übrigens auch meinen Shelly Button über MQTT angebunden.
ZitatAberaberaber es gibt doch 36_Shelly.pm von @paf ... wofür ist das dann gut, wenn es für nix gut ist?
Das halte ich doch für eine gewagte Aussage und schlage vor, das noch einmal zu überdenken.
LG
pah
P.S.: Es ist außerdem nicht richtig, dass in einem REST-Aufruf von FHEM das Device "doppelt" aufgeführt werden muss.
@pah
Es gibt keinen Grund für Aufregung: In Beitrag #2 sage ich, dass ich Shelly überhaupt erstmal verstehen möchte - von überdenken sind wir noch weit weit entfernt. Möglicherweise gehören einige Deiner grundsätzlichen Aussagen aus #11 in den zuständigen Wiki-Artikel.
Danke für Deine Erklärung.
Zu meinem Beitrag oben:
ok, stimmt. Tatsächlich ist "cmd.lamp" überflüssig.
Weiß nicht mehr, wo ich das her hab.
http://raspi:8083/fhem?XHR=1&cmd=set%20lamp%20on
oder besser
http://raspi:8083/fhem?XHR=1&cmd=set%20lamp%20on&fwcsrf=<csrftoken>
@curt: Wer "für nix gut ist" schreibt, sollte das umgehend überdenken.
pah
Zitat von: Prof. Dr. Peter Henning am 30 November 2020, 10:32:12
@curt: Wer "für nix gut ist" schreibt, sollte das umgehend überdenken.
Es war eine Replik auf einen vorherigen Beitrag, Bezug war da i3. - Das ist inzwischen dank auch Deiner Erklärung verstanden.
Hallo zusammen,
werden denn per MQTT die diversen Events (kurz-lang, lang kurz, doppel etc.) gemeldet?
Oder geht das dann nur per FHEM-URL-Aufruf aus dem Shelly I3?
Grüße
Thomas
Also, per mqtt lassen sich die doppel oder 3fach Betätigungen nicht auswerten.
Ich habe meinen i3, wie auch alle anderen Shellys, per mqtt angebunden.
Beim i3, und nur bei denen, nutze ich dann unter Action die url....
Wenn Ihr die ix3 über das Template eingebunden habt, ist da sicher noch Raum für Verbesserungen ;)
In der Doku steht als Voraussetzung für diese Events: https://shelly-api-docs.shelly.cloud/#shelly-i3-input-events (https://shelly-api-docs.shelly.cloud/#shelly-i3-input-events)
Input events are only monitored if a button is configured as momentary
Ich bin mir nicht sicher, ob man die Actions am ix3 auf "enabled" setzen muss, damit die Events kommen.
Und ich bin mir auch nicht sicher, ob man eine URL hinterlegen muss damit das funktioniert.
Welche Attribute habt Ihr denn bei Euren Shellys (im Speziellen readingList und setList)?
lg, Gerhard
Als erweitern ist da nicht wirklich möglich....
Internals:
CID shellyix3_A4CF12F4701A
DEF shellyix3_A4CF12F4701A
DEVICETOPIC Schalter_Flur_i3
FUUID 5fee2781-f33f-b900-971c-30d2fb6e313816fb
FVERSION 10_MQTT2_DEVICE.pm:0.233820/2020-12-19
IODev MQTT2Server
LASTInputDev MQTT2Server
MQTT2Server_MSGCNT 6422
MQTT2Server_TIME 2021-01-07 17:45:59
MSGCNT 6422
NAME Schalter_Flur_i3
NR 187
STATE In 1:
0
<br>In 2:
1
<br>In 3:
0
TYPE MQTT2_DEVICE
READINGS:
2021-01-01 11:28:18 attrTemplateVersion 20201110
2021-01-07 17:45:59 event
2021-01-07 17:45:59 event_cnt 0
2021-01-07 08:51:24 fw_ver 20201124-092930/v1.9.0@57ac4ad8
2021-01-07 08:51:24 id shellyix3-A4CF12F4701A
2021-01-07 17:45:59 input_0 0
2021-01-07 17:45:59 input_1 1
2021-01-07 17:45:59 input_2 0
2021-01-07 08:51:24 ip 192.168.111.163
2021-01-07 08:51:24 mac A4CF12F4701A
2021-01-07 08:51:24 model SHIX3-1
2021-01-07 08:51:24 new_fw false
2021-01-07 08:51:24 online true
Attributes:
IODev MQTT2Server
devStateIcon 0:off 1:on
model shelly_ix3
readingList shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input/1:.* input_1
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/1:.* { json2nameValue($EVENT) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input/2:.* input_2
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/2:.* { json2nameValue($EVENT) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input/0:.* input_0
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/0:.* { json2nameValue($EVENT) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/online:.* online
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/announce:.* { json2nameValue($EVENT) }
room Flur
stateFormat In 1:
input_0
<br>In 2:
input_1
<br>In 3:
input_2
Im Reading event bekommt man z.B "SSS" "SS" "S" "L"..... - Keine Auswertung von welchem Eingang
Im Reading input_0 bis input_3 bekommt man "0" oder "1" - bei jeder betätigung ein wechsel, der Startzustand vom jeweiligen Eingang kann "0" oder"1" sein.....
Ich hab es aufgegeben, sobald ich mit mehrfach Betätigung arbeite nehme ich die URL....
Könntest Du mal versuchen in dem Reading "readingList" die Punkte zu ändern:
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/1:.* { json2nameValue($EVENT) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/2:.* { json2nameValue($EVENT) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/0:.* { json2nameValue($EVENT) }
neu:
shellyix3_A4CF12F4701A:shellies/shellyix3_A4CF12F4701A/input_event/0:.* { json2nameValue($EVENT, '0_', $JSONMAP) }
shellyix3_A4CF12F4701A:shellies/shellyix3_A4CF12F4701A/input_event/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
shellyix3_A4CF12F4701A:shellies/shellyix3_A4CF12F4701A/input_event/2:.* { json2nameValue($EVENT, '2_', $JSONMAP) }
Damit solltest Du die Events pro Kanal bekommen.
Ändert das was?
lg, Gerhard
Hi,
damit gibt es den event pro Kanal...
Internals:
CID shellyix3_A4CF12F4701A
DEF shellyix3_A4CF12F4701A
DEVICETOPIC Schalter_Flur_i3
FUUID 5fee2781-f33f-b900-971c-30d2fb6e313816fb
FVERSION 10_MQTT2_DEVICE.pm:0.233820/2020-12-19
IODev MQTT2Server
LASTInputDev MQTT2Server
MQTT2Server_MSGCNT 41
MQTT2Server_TIME 2021-01-08 12:07:55
MSGCNT 41
NAME Schalter_Flur_i3
NR 187
STATE In 1:
0
<br>In 2:
0
<br>In 3:
0
TYPE MQTT2_DEVICE
READINGS:
2021-01-08 12:07:55 0_event S
2021-01-08 12:07:55 0_event_cnt 12
2021-01-08 12:07:55 1_event SS
2021-01-08 12:07:55 1_event_cnt 23
2021-01-08 12:07:55 2_event
2021-01-08 12:07:55 2_event_cnt 8
2021-01-08 12:03:12 attrTemplateVersion 20201110
2021-01-08 12:04:40 event S
2021-01-08 12:04:40 event_cnt 5
2021-01-08 12:05:55 fw_ver 20201124-092930/v1.9.0@57ac4ad8
2021-01-08 12:05:55 id shellyix3-A4CF12F4701A
2021-01-08 12:07:55 input_0 0
2021-01-08 12:07:55 input_1 0
2021-01-08 12:07:55 input_2 0
2021-01-08 12:05:55 ip 192.168.111.163
2021-01-08 12:05:55 mac A4CF12F4701A
2021-01-08 12:05:55 model SHIX3-1
2021-01-08 12:05:55 new_fw false
2021-01-08 12:05:55 online true
Attributes:
IODev MQTT2Server
devStateIcon 0:off 1:on
model shelly_ix3
readingList shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input/0:.* input_0
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input/1:.* input_1
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input/2:.* input_2
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/0:.* { json2nameValue($EVENT, '0_', $JSONMAP) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/input_event/2:.* { json2nameValue($EVENT, '2_', $JSONMAP) }
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/online:.* online
shellyix3_A4CF12F4701A:shellies/shellyix3-A4CF12F4701A/announce:.* { json2nameValue($EVENT) }
room Flur
stateFormat In 1:
input_0
<br>In 2:
input_1
<br>In 3:
input_2
Damit wäre eine Auswerting aus fhem möglich.....
Nur zur Info....
Bisher nutze ich nur kurze Befehle, Bei einem Long Press gibt es keine Event Meldung - bisher gesagt nur eine Rückmeldung ohne Inhalt....
Hi,
super - danke :-)
Da bin ich auch gerade am Thema
Wenn ich statt { json2nameValue($EVENT) } ein { json2nameValue($EVENT, 'X_', $JSONMAP) } schreibe,wie oben beschrieben, kommt es für jeden Schalter einzeln :-)
Wie kann ich mir denn die json Syntax selbst herleiten oder nachlesen / anlernen?
Wie kommt man darauf? Ist das bei MQTT erläutert?
Nun habe ich aber noch ein anderesProblem:
beim loslassen des Schalters wird kein Event dafür gesendet. Das macht der Shelly von sich aus wohl nicht.
Ich möchte erreichen, das die Helligkeit einer Lampe so lange erhöht wird, so lange man den Schalter gedrückt hält.
Problem hierbei ist, das nach loslassen der Count für die Events erst hochgezählt wird, wenn die Max Longpush Zeit rum ist.
Würde also deutlich nachlaufen. Herumexperimentieren mit den Werten für Longpush Duration und multipush duration hat nichts geändert.
Optimal wäre:
1x Kurz gedrückt: Licht Toggle
2x Kurz gedrückt Lichtfarbe ändern
Gedrückt halten: dimmen
Man könnte den shelly in den Tooglemodus setzen. Dann wird eine 1 gesendet so bald der Kontakt geschlossen ist.
Bei loslassen geht das denn direkt wieder auf 0
Da bräuchte man dann eine eigene Logik welche die Zeit zwischen dem Zustandswechsel misst und interpretiert.
Danke und Gruß Andre
ZitatWie kann ich mir denn die json Syntax selbst herleiten oder nachlesen / anlernen?
Wie kommt man darauf? Ist das bei MQTT erläutert?
Das sind 3 Fragen.
1. JSON eingeben bei Google -> GANZ VIELE Tutorials.
2. API-Doku der Shellys lesen https://shelly-api-docs.shelly.cloud/#shelly-family-overview
3. Nein
ZitatDa bräuchte man dann eine eigene Logik welche die Zeit zwischen dem Zustandswechsel misst und interpretiert.
Sequence-Modul.
Allerdings schlage ich vor, als Anfänger von so etwas eher die Finger zu lassen - das führt nur zu Frustration.
LG
pah
Moin,
ich habe jetzt gerade meinen i3 im Zusammenhang mit COAP/CoIoT untersucht. Ich denke, die Implementierung geht dann morgen rein (schreibe ich noch in den ShellyMonitor-Thread), aber out of the box geht es auch schon halbwegs:
Das Folgende gilt jetzt für CoIoT und Shelly-Monitor, aber die Events sind vermutlich für MQTT ähnlich:
Wer wissen will, "ob das Licht an ist", also den Zustand auf der Leitung wissen will, muss (per Hand) in den "Toggle Switch"-Modus wechseln (default ist "Momentary"). Da wird auf dem Reading input_0 / input_1 / input_2 eine 0 oder 1 übertragen. 1 = gemäß Diagram Verbindung zu L.
Im "Momentary"-Modus werden Taster erwartet, und aus der Einschaltfolge "S", "SS", "SSS" oder "L"-Events erzeugt. (1 x kurz, 2 x kurz, 3 x kurz, 1 x lang). Hier ist nun eine Anpassung in ShellyMonitor gefragt, um vernünftig und einfach darauf Events aufsetzen zu können. Wie (sicherlich) auch bei MQTT, wird ja der Event-Kanal alle 30 Sekunden wiederholt. Daher lässt sich das Auftreten des Events erst aus der Kombination mit "inputEventCnt_0/1/2 erhöht" ableiten. Die Logik muss also sein:
if (inputEventCnt_x > inputEventCnt_x(old)) {
setze inputEvent_x als readingUpdate
}
Mod_Shelly arbeitet ja normalerweise immer mit readingsBulkUpdateIfChanged - ein Event wird also nur bei einer Änderung generiert. MQTT hingegen immer (?) mit readingsBulkUpdate. Der "MQTTler" müsste als ein "event-on-change" auf den inputEventCnt_x legen, darauf ein notify etc hängen, um dort inputEvent_x als Art des Ereignisses auszulesen.
Der "Mod_Shellyianer" Stand jetzt genauso, aber ich werde das - gemeinsam für den Button - so implementieren, dass man bei Mod_Shelly sich direkt mit dem Notify auf inputEvent_x "hängen" kann.
Hoffe, damit zur Shelly-Forschung beigetragen zu haben - Vollzug melde ich dann im ShellyMonitor-Thread
Hi,
genau das habe ich auch gemerkt. Der S oder SS kommt öfter und muss mit dem anderen Parameter kombiniert abgefragt werden. Das habe ich bisher nicht hinbekommen.
Daher habe ich direkt im Shelly die Action URLs genutzt.
Wenn Zeit ist versuche ich nochmal MQTT.
Allerdings gibt es leider eine merkbare Verzögerung zwischen Tastenbetätigung und dem Licht.
Da muss ich mal sehen ob das am Shelly an sich, MQTT, der Lampe oder was auch immer liegt.
Gruß André
Du kannst ja auch - ohne das MQTT-Device zu löschen - mal eine 2. Definition mit Mod_Shelly und Mod_ShellyMonitor probieren. Allerdings ist die Verzögerung wohl eher dem Warten auf die Auszeit "Kommt da noch ein Klick?" geschuldet. Logischerweise kann z.B. "SS" erst ausgelöst werden, wenn feststeht, dass es kein "SSS" mehr wird.
Wenn Du auf die multiplen Tastendrücke verzichten kannst und lieber ad hoc dafür hast, dann solltest Du den Mode umstellen. Da wirst Du wohl binnen Millisekunden den Status haben.
Hi,
danke. Guter Hinweis mit dem Warten auf Mehrfachklick.
Habe nun MQTT deaktiviert und den Shelly auf Toogle Mode gestellt.
Jetzt fühlt sich das an wie ein physikalischer Schalter ohne Verzögerung :-)
Gruß André