Fibaro Wall Plug - Zustand wird nicht erkannt

Begonnen von dantist, 22 August 2017, 21:56:34

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Zitatein eindeutiges "on" bzw. "off" bei Z-Wave, obwohl die Steckdose dies nicht bestätigt hat, halte ich für falsch
Das leuchtet mir ein, und ich finde wir sollten state beim generieren von NO_ACK setzen. Ich bin nur unsicher, auf was.

dantist

Zitat von: rudolfkoenig am 25 August 2017, 16:43:04
Das leuchtet mir ein, und ich finde wir sollten state beim generieren von NO_ACK setzen. Ich bin nur unsicher, auf was.

Hier würde ich die Logik von Homematic vorschlagen. Wenn beim Anschalten keine Antwort kommt, wird der state auf set_on gesetzt, beim Ausschalten auf set_off.

Ich habe für die Z-Wave Dose erstmal einen Workaround mit stateFormat gebaut:

{ ReadingsVal("$name","transmit", undef) eq "OK" ? ReadingsVal("$name","state", undef) : ReadingsVal("$name","state", undef) eq "on" ? "set_on" : "set_off" }

rudolfkoenig

ZitatHier würde ich die Logik von Homematic vorschlagen. Wenn beim Anschalten keine Antwort kommt, wird der state auf set_on gesetzt, beim Ausschalten auf set_off.

Soweit ich weiss, ist die Logik von HomeMatic genau andersrum (und das passt mir nicht): erst wird state auf set_on gesetzt, und wenn bestaetigt, dann auf on. Deswegen blitzt kurz ein Ausrufezeichen beim Schalten auf, und ich musste etliche Klimmzuege in FHEMWEB implementieren, damit es nicht beim Ausrufezeichen bleibt.

dantist

Zitat von: rudolfkoenig am 25 August 2017, 17:34:49
Soweit ich weiss, ist die Logik von HomeMatic genau andersrum (und das passt mir nicht): erst wird state auf set_on gesetzt, und wenn bestaetigt, dann auf on. Deswegen blitzt kurz ein Ausrufezeichen beim Schalten auf, und ich musste etliche Klimmzuege in FHEMWEB implementieren, damit es nicht beim Ausrufezeichen bleibt.

Das ist nachvollziehbar, dass es umständlich im Interface zu implementieren ist. Aber logisch gesehen ist es eigentlich die richtige Reihenfolge. Auch wenn im Fehlerfall ein "on" nur kurz gesetzt wäre, bevor es auf "set_on" springt, würde z.B. ein notify darauf reagieren, oder?

Und da das Interface bereits mit HomeMatic umgehen kann, wäre es doch kein Mehraufwand, die gleiche Logik bei Z-Wave zu verwenden?

rudolfkoenig

ZitatAber logisch gesehen ist es eigentlich die richtige Reihenfolge.
Mag sein, aber im Normalfall moechte ich (als Benutzer) die Vorgaenge nicht bis ins letzte Detail dargestellt bekommen.

krikan

Zitat von: rudolfkoenig am 25 August 2017, 16:43:04
sollten state beim generieren von NO_ACK setzen.
Das bedeutet doch nur, dass kein ACK vom Gerät angekommen ist. Warum auch immer. Trotzdem kann der Schaltvorgang erfolgreich gewesen sein. Evtl. wird das sogar von irgendeiner anderen Command Class richtigerweise reported oder gar von SWITCH_MULTILEVEL mit dim %. Kann man das dann im state erkennen? Oder steht state dann fälschlicherweise nicht auf on, sondern auf NO_ACK. Eigentlich müsste man doch direkt den korrespondierenden get-Befehl zur Kontrolle nach dem set-Befehl schicken!?

Für welche CC soll das gelten? Für alle? Oder nur für on/off, was aber diverse Bedeutungen haben kann und x verschiedene automatische Antworten nach sich ziehen kann.

Sorry, liest sich sehr negativ, aber ich verstehe nicht, wie man das vernünftig und ohne unnützen Overhead umsetzen kann. Gehen wir hier nicht von einem sehr speziellen Anwendungsszenario aus und es wird der Spezialfall zum Normalfall gemacht? Die gewünschte Info kann man sich jetzt schon per stateFormat selbst zusammenbauen, wobei der Aussagegehalt immer noch nicht vorhanden ist.

Lasse mich aber gerne überzeugen.  :)

rudolfkoenig

Keine Panik, das ist hier erstmal als Diskussion gedacht.

Ich verstehe den Standpunkt von dantist, dass er nach einem set nicht erst auf der Detailseite rausfinden muss, dass FHEM weiss, dass was schiefgegagenen ist. Ich habe aber noch keine fertige Loesung, und ich will auch nicht unmotivierte Supportfragen fuer uns generieren.

Moeglichkeiten, die mir z.Zt. durch den Kopf gehen (alle nur mit explizites Setzen eines Attributes aktivierbar):
1. falls der letzte set (z.Bsp. on) ein NO_ACK generiert, und seitdem keine anderen Nachrichten vom Geraet eingetroffen sind, dann wird state auf on_NO_ACK gesetzt. Fuer die set_XX icons erstelle ich ein Alias fuer XX_NO_ACK.
2. Verhalten wie bei HomeMatic. (erst set_on und nach ACK on)

justme1968

auch wenn ich kein zwave anwender bin: 2. ist besser. weil konsistent mit anderen modulen und es ist auch einfacher zu implementieren da es keine logik und keine history fur die zustandsübergänge braucht und auch keine anderen kommandos/ nachrichten berücksichtig werden müssen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

krikan

Zitat von: rudolfkoenig am 25 August 2017, 20:05:45
Ich verstehe den Standpunkt von dantist, dass er nach einem set nicht erst auf der Detailseite rausfinden muss, dass FHEM weiss, dass was schiefgegagenen ist.
Vom grundsaetzlichen Gedankengang verstehe ich es irgendwie. Jedoch wird mMn die Info "Absetzen des set-Befehl wurde mit ACK bestaetigt" unzulaessig mit einer (angenommenen) Info über den tatsaechlichen Aktorzustand vermischt. Denn eigentlich interessiert ihn doch Letzteres. Die Info kommt im reportedState. Man kann 100x set-off absetzen, wenn der Aktor nicht erreicht wird, bleibt reportedState on. Das setzt natürlich eine korrekte Assoziation/Einrichtung voraus. Total unnütz wird die Info "Absetzen des set-Befehl wurde mit ACK bestaetigt", wenn jemand beispielsweise mit CC PROTECTION herumspielt und alle Schaltvorgaenge unterbindet. Dann geht er von einem erfolgreichen set-off wegen ACK aus, obwohl der Aktor tatsaechlich weiter an ist.
Höchste Sicherheit, die unabhaengig von korrekter Assoziation oder sonstigen Einflüssen ist, gibt es mMn nur durch eine aktive get-Abfrage und Auswertung des Ergebnisses. Wenn die get-Abfrage den nicht gewünschten Zustand oder NO_ACK liefert ist "Alarm" angesagt.

Die befehlsspezifische Info zu Kommunikationsstörungen sollte man  mMn, wenn so etwas kommt, nicht auf einzelne set-Befehle eines Nodes beschraenken. Konsequenterweise und um Verwirrung zu vermeiden, sollte es dann bei jeder fehlgeschlagenen Kommunikation von set- und get-Befehlen einen Hinweis geben. Wie begründet man sonst bspw., dass bei fehlgeschlagenen get-swbStatus/swmStatus-Abfragen im state off ohne Warnungs-Ergaenzung steht, obwohl der Stecker in Realitaet "on" ist?

Das Ganze geht dann in Richtung einer FHEM-geführten Failed Node-List. Sinnvoll könnte so etwas sein, um unnötige Belastungen des ZWave-Netzes mit FHEM-Kommunikationsversuchen mit toten Nodes zu verhindern. Aber selbst hier bin ich hin- und hergerissen.

Btw: Keine Panik, sondern meine Versuche es zu verstehen.  :)

rudolfkoenig

Zitatauch wenn ich kein zwave anwender bin: 2. ist besser
Ich habe jetzt ein showSetInState Attribut in 00_ZWDongle.pm(!) eingefuehrt. Falls gesetzt, dann wird erst set_XX als state gesetzt, und das wird auf XX gesetzt, wenn ein ACK eintrifft. Es betrifft nur set, und in diesem Fall gibt es ein Event zusaetzlich.

Dabei ist mir aufgefallen, dass bei longpoll=websocket die oben erwaehnten "Klimmzuege" nicht funktioniert haben (habs gefixt). Das faellt inzwischen nur noch auf, wenn man set von der Detailseite ausloest, da auf Raum-Ebene die Seite nicht mehr neu geladen wird. Trotzdem komisch, dass bisher das niemand gemeldet hat, offensichtlich wird longpoll=websocket kaum von den CUL_HM Benutzer verwendet.

justme1968

 was hm angeht: es gibt/gab im forum einige berichte das in der detail seite der zweite wechsel von set_X auf das ensgültige X in fhemweb manchmal nicht funktioniert. unabhängig von websocket. ich wollte mir das schon länger mal anschauen bin aber nie dazu gekommen. meinst du das mit nicht funktioniert?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig


krikan

#27
Zitat von: rudolfkoenig am 12 September 2017, 17:48:27
Falls gesetzt, dann wird erst set_XX als state gesetzt, und das wird auf XX gesetzt, wenn ein ACK eintrifft.
Bei neighborUpdate der Nodes bleibt "set_neighborUpdate" stehen, obwohl die Funktion erfolgreich mit "done" abgeschlossen wird. Ist bei den anderen Controllerfunktionen der Geräte-Devices genauso.

Auch bei Geräten, die bsher schon das Reading state bei bestimmten Befehlen setzten, wird dieser jetzt durch jeden set-Befehl beeinflusst. Man hat dann bspw. "configSwitchType MomentarySwitch" in der Raumansicht, statt vorher ausschließlich Lampensymbol. Ist im ersten Moment irritierend, aber arbeitet wohl wie gewünscht. Lässt sich durch Setzen von stateFormat beheben.

edit: Formulierung letzter Absatz geaendert.

rudolfkoenig

ZitatBei neighborUpdate der Nodes bleibt "set_neighborUpdate" stehen, obwohl die Funktion erfolgreich mit "done" abgeschlossen wird.
Danke fuer den Hinweis, "set_*" habe ich fuer Controllerfunktionen, die ueber eine ZWave-Instanz gestartet werden, deaktiviert.

ZitatMan hat dann bspw. "configSwitchType MomentarySwitch" in der Raumansicht, statt vorher ausschließlich Lampensymbol.
Das verstehe ich noch nicht. Das Attribut bewirkt, dass beim set zusaetzlich set_ im Status gesetzt wird, und nach dem Ack das set_ entfernt wird. Kannst du bitte davon irgendein Log machen, oder es mir anders erklaeren?

FunkOdyssey

Ich habe ein Fibaro FGS-222 (2-fach Relais), in welchem nun bei den Kanälen der falsche Status angezeigt wird:

Internals:
   DEF        f6befb31 2818
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     1
   NAME       zw_garten_02
   NR         336
   STATE      set_off
   TYPE       ZWave
   ZWDongle_0_MSGCNT 1
   ZWDongle_0_RAWMSG 0004000b07600d0200250300
   ZWDongle_0_TIME 2017-09-13 22:45:21
   ZWaveSubDevice yes
   endpointParent zw_garten
   homeId     f6befb31
   isWakeUp
   nodeIdHex  0b02
   READINGS:
     2017-09-13 22:45:21   reportedState   off
     2017-09-14 07:04:03   state           set_off
Attributes:
   IODev      ZWDongle_0
   classes    SWITCH_BINARY
   devStateIcon on:on@Crimson off:off






Zitat von: krikan am 13 September 2017, 19:00:48
Auch bei Geräten, die bsher schon das Reading state bei bestimmten Befehlen setzten, wird dieser jetzt durch jeden set-Befehl beeinflusst. Man hat dann bspw. "configSwitchType MomentarySwitch" in der Raumansicht, statt vorher ausschließlich Lampensymbol. Ist im ersten Moment irritierend, aber arbeitet wohl wie gewünscht. Lässt sich durch Setzen von stateFormat beheben.

Zitat von: rudolfkoenig am 14 September 2017, 10:18:41
Das verstehe ich noch nicht. Das Attribut bewirkt, dass beim set zusaetzlich set_ im Status gesetzt wird, und nach dem Ack das set_ entfernt wird. Kannst du bitte davon irgendein Log machen, oder es mir anders erklaeren?

Soweit ich weiß hat das nichts mit dieser Änderung zu tun. Ich habe im STATE (Raumansicht) immer die letzte Aktion stehen, die ich ausgeführt habe (z.B.: "neighborUpdate" oder "configxyz"). Das finde ich btw übrigens extremst störend, da man nun nicht mehr erkennen kann, ob die Aktoren ein- oder ausgeschaltet sind. Ist vielleicht nicht Thema des Threads - obwohl nah verwandt. :-)