Test Adapter Shelly v3.3.4 (latest)

[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

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

[Stuebi]

@e-s , okay dann passt es ja , wie ich es umgesetzt habe. Schade, das Shelly den Longpush nicht wie bei CoAP zurücksetzt

[e-s]

@Stuebi
Ich habe es irgendwann aufgegeben und nutze jetzt immer ein script was mit dem Tasten startet und beim loslassen endet. Mit dem kann man somit auch mehrere Funktionen starten lassen und nicht nur eine.

[Domingo]

@e-s Also bei der Kommunikation per CoIoT scheint das mit longpush seitens des Shelly recht verlässlich kommuniziert zu werden. Im Zusammenspiel mit ioBroker sollte es beim umschalten von mqtt zu CoAP im Prinzip dann ja transparent weiterlaufen ohne Skritpzwang.
Oder nutzt du irgendwas spezielleres, was nur bei mqtt unterstützt wird und nicht bei CoAP?

[CrunkFX]

@Stuebi Ich würde den Longpush via /input wert 0 zurücksetzen lassen, damit es hier keine verwirrung gibt. Immer wenn longpush losgelassen wird wird auch input losgelassen, somit wäre das doch ein guter Ersatz oder? Das Problem ist nämlich bei der jetzigen Umsetzung, dass in IOB ja der Wert longpress nur getriggert wird, falls jemand ne komlexe Steuerung mit der Input high zeit bauen will funktioniert das so nicht.