Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[harrym]

@Stuebi vergiss aber nicht, dass es beim Dimmer auch den "dual button mode" gibt ... also hast du da 2 Kanäle.

[Stuebi]

@harrym , ja Kanal 2 ist analog zu Kanal 1.

[CrunkFX]

@Stuebi Und denk daran, dass bei MQTT Input und Longpush bei Longpush auf 1 gehen.

[Stuebi]

@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 ?

[CrunkFX]

@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.

[Stuebi]

@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

http://www.stueben.de/iobroker-adapter-per-github-laden/

[CrunkFX]

@Stuebi 3.3.5 meinst du :blush:

[Domingo]

@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.

[Domingo]

@Stuebi so korrekt 👍

[CrunkFX]

@Stuebi CoAP funktioniert einwandfrei, MQTT nicht. Longpush bleibt auf true hängen.

[Domingo]

@Stuebi Kann bestätigen Protokoll CoAP Dimmer 1 läuft perfekt.

[Stuebi]

@CrunkFX , schaue ich mir in 10 Minuten an

[CrunkFX]

@Stuebi Jojo kein Stress. Bin für ne Stunde nicht hier, danach könnte ich wieder Testen.

[Stuebi]

@CrunkFX , alles klar. Erklären kann ich es mir nicht bei MQTT . Was passiert dann beim short press? Ändert sich dann Longpush MQTT?

[CrunkFX]

@CrunkFX
Er scheint Longpress nach dem drücken nicht mehr abzufragen.

[Stuebi]

@CrunkFX sagte in Test Adapter Shelly v3.3.4 (latest):

@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 1

shellies/shellydimmer2-<ID>/longpush/0

Rückgabe: 1 bei longpush. Beim Loslassen nichts

shellies/shellydimmer2-<ID>/input/0

Rückgabe: 1 bei shortpush ; 0 bei loslassen ; ebenfalls 0 bei loslassen von Longpush

Input 2

shellies/shellydimmer2-<ID>/longpush/1

Rückgabe: 1 bei longpush. Beim Loslassen nichts

shellies/shellydimmer2-<ID>/input/1

Rückgabe: 1 bei shortpush ; 0 bei loslassen ; ebenfalls 0 bei loslassen von Longpush

Was meinst du mit nichts bei longpush?

[CrunkFX]

@Stuebi Beim loslassen vom Input wird im Channel /longpush nichts gesendet also keine 0 oder ähnliches. Nur beim Input high >1000ms

[Stuebi]

@CrunkFX , d.h der longpushWert bleibt dann bei MQTT auf 1 und geht nie wiede rzurück auf 0?

Edit
Verhalten ist auch beim MQTT Adapter so?

[CrunkFX]

@Stuebi Ja und Ja

[e-s]

@Stuebi
Wenn ihr schon dabei seid, longpush ging früher über mqtt (coap nicht getestet) auch nie richtig. Hatte deswegen schon mehrere threads geschrieben und war mit shelly in Kontakt. Meines Erachtens liefern die schon falsch.
Longpush blieb früher immer auf true bis das nächste mal der taster losgelassen wurde.
Wenn 2 mal in Folge lange gedrückt wurde, dann hat sich longpush nie verändert und konnte somit auch nie als trigger alleine genutzt werden.
Nur wenn man anschließend kurz drückt, wird longpush auf false gesetzt.