Test Adapter Shelly v3.3.4 (latest)
-
@Stuebi Welchen Input 1 oder 2 und in welchem Modus oder ist das egal?
-
@CrunkFX , am liebsten beide Kanäle. Mode ist egal. Hattest Du Longpush nur an Kanal 1 getestet?
-
@Stuebi
CoAP:Also Input 1
// Ruhe [0,131,0] // Shortpush wird bei loslassen zu Ruhe [0,131,1] //Longpush Wird bei loslassen zu Ruhe [0,131,2]Input 2
// Ruhe [0,141,0] // Shortpush wird bei loslassen zu Ruhe [0,141,1] //Longpush Wird bei loslassen zu Ruhe [0,141,2]MQTT
Input 1shellies/shellydimmer2-<ID>/longpush/0Rückgabe: 1 bei longpush. Beim Loslassen nichts
shellies/shellydimmer2-<ID>/input/0Rückgabe: 1 bei shortpush ; 0 bei loslassen ; ebenfalls 0 bei loslassen von Longpush
Input 2
shellies/shellydimmer2-<ID>/longpush/1Rückgabe: 1 bei longpush. Beim Loslassen nichts
shellies/shellydimmer2-<ID>/input/1Rückgabe: 1 bei shortpush ; 0 bei loslassen ; ebenfalls 0 bei loslassen von Longpush
-
@Stuebi So zumindest scheint es ein Test mit einem anderen CoAP-Node-Adapter zu bestätigen. Dort werden nur die States 0, 1, 2 ausgegeben. Nach meiner Beobachtung wechselt der State immer bei Falling Edge, also beim freigeben des Signals bzw. Loslassen des Tasters. Insofern dürfte 1 und 2 nicht parallel auftreten (jedenfalls nicht sinnvollerweise).
-
@CrunkFX Krass wie schnell du hier fleißig Testergebnisse geliefert hast. Vielen Dank. Sind noch weitere Infos hilfreich? Habe leider nur den neben RGBW2 und Shelly 1, 2, und 2.5 nur den Dimmer 1 nicht Version 2 aber da hast du ja bereits auch schon alles vorgelegt. Respekt.
-
@CrunkFX sagte in Test Adapter Shelly v3.3.4 (latest):
scheint so, dass es für den Shelly Dimmer 2 anders als für den Dimmer 1 keinen Longpush für MQTT gibt. -
@Stuebi Aber er gibt doch bei Longpush ne 1 aus
-
@CrunkFX , sorry falsch gelesen!! du hast recht
-
@Stuebi Der Dimmer 1 stand in dem Post nicht in deiner Gerätewunschliste, sonst hätte ich natürlich nicht nur den RGBW2 gepostet. Tut mir leid. Hab den Bedarf nicht erkannt.
-
@Stuebi Input und Longpush sind aber im CoAP kombiniert. Ist der input für 1000ms auf high wird 2 gesendet sonst 1 oder 0. Bei MQTT wird zwischen Input und Longpush getrennt Sprich Input high(egal wie lange) sende 1 sonst 0 und falls Input high(>1000ms) sende 1 auf longpush
-
@CrunkFX , okay, damit es bei CoAP und MQTT gleich im Adapter ist, werde ich es wie folgt umsetzten:
Kanal 1:
Beim drücken von Longpush -> longpush = true, input = false
Bei drücken von Shortpush -> longpush = false, input = true
Nichts wird gedrückt / losslassen -> longpush = false, input = falseSo müsste es passen?
-
@Stuebi vergiss aber nicht, dass es beim Dimmer auch den "dual button mode" gibt ... also hast du da 2 Kanäle.
-
@harrym , ja Kanal 2 ist analog zu Kanal 1.
-
@Stuebi Und denk daran, dass bei MQTT Input und Longpush bei Longpush auf 1 gehen.
-
@CrunkFX ,
okay dann nochmals am Beispiel Kanal 1:
Aktion MQTT CoAP DP Input DP Longpush Long push longpush == 1 / input == 1 131 == 2 true true Short push longpush == 0 / input == 1 131 == 1 true false no push longpush == 0 / input == 0 131 == 0 false false So korrekt ?
-
@Stuebi Ja nur das du bei MQTT No Push die 0 bei Longpush nicht anfragen kannst da es die nicht gibt. Du musst also die 0 vom Input abfragen.
-
@CrunkFX , kannst du den Shelly Adapter in der Version 3.1.5 eben von Github laden und testen. habe es für CoAP und MQTT implementiert für den Dimmer 1 und Dimmer 2
-
@Stuebi 3.3.5 meinst du
-
@CrunkFX Wobei longpush=1 logischerweise input=1 implizieren sollte selbst wenn mqtt bei longpush den input nicht als 1 sendet. Das ist wohl einfach der Tatsache geschuldet, dass es hier zwei getrennte Topics gibt für longpush und input. Bei CoAP ist das ja nicht so. Da gibt es den kombinierten State input=1 und longpush=1 nicht. Longpush ist 2 und impliziert input=1.
Davon könnte man also theoretisch auch bei mqtt ausgehen. -
@Stuebi so korrekt
