Fibaro Wall Plug - Zustand wird nicht erkannt

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

Vorheriges Thema - Nächstes Thema

dantist

Hallo zusammen,

ich bin die Tage mit dem Aeotec AEOEZW090-C Dongle und einem Fibaro Wall Plug in die Z-Wave Welt eingestiegen, was super einfach und schnell funktioniert hat.

Allerdings ist mir aufgefallen, dass FHEM nicht erkennt, wenn der Stecker ausgesteckt wird. Er bleibt einfach auf dem letzten Zustand stehen und lässt sich sogar toggeln, es findet also keine Prüfung des tatsächlichen Zustandes statt.

Anbei ein Screenshot der Readings - ist da irgendwas falsch?

Gruß
Dan

rudolfkoenig

FHEM kann nicht wissen, ob der Schalter noch angesteckt ist oder nicht. Es weiss nur, dass nach dem "on" Befehl kein ACK vom Schalter gekommen ist, ind das steht auch unten in deinem Screenshot.

dantist

D.h. Z-Wave Geräte kommunizieren nicht regelmäßig mit der Zentrale, wie es bei Homematic der Fall ist? Wenn ich eine Homematic-Steckdose vom Strom nehme, ändert sich der Zustand nach kurzer Zeit auf "unreachable".

dantist

Hat niemand eine Idee? Man muss sich doch bei Z-Wave auf den Zustand verlassen können. An der Steckdose soll zukünftig ein Bügeleisen hängen, daher ist es *sehr* wichtig zu wissen, ob sie tatsächlich an oder aus ist ;) Es kann doch nicht sein, dass man dazu extra das Reading "transmit" auf NO_ACK prüfen muss.

darkness

Zitat von: dantist am 24 August 2017, 08:33:04
An der Steckdose soll zukünftig ein Bügeleisen hängen, daher ist es *sehr* wichtig zu wissen, ob sie tatsächlich an oder aus ist ;)

Was genau soll den der Zwischenstecker deiner Meinung nach machen.

Wenn der Stecker nicht gesteckt ist und du schaltest, passiert auch nichts. Im Zweifel schaltest du den Stecker aus. Steckt er, wird er aus geschaltet. Steckt er nicht, ist alles gut.
Aber irgendwie finde ich dein vorhaben "gruselig".

Beachte aber auch die max. Leistung des Zwischensteckers. Und nachdem die Stecker in der Vergangenheit (in einer früheren Version) mal Probleme gemacht haben, würde ich den keine großen Lasten "anvertrauen"

Nur meine Meinung :)

Gruß

Fixel2012

Zitat von: dantist am 24 August 2017, 08:33:04
Hat niemand eine Idee? Man muss sich doch bei Z-Wave auf den Zustand verlassen können. An der Steckdose soll zukünftig ein Bügeleisen hängen, daher ist es *sehr* wichtig zu wissen, ob sie tatsächlich an oder aus ist ;) Es kann doch nicht sein, dass man dazu extra das Reading "transmit" auf NO_ACK prüfen muss.

Verstehe ehrlich gesagt nicht, was dein Problem ist.

Wenn Fhem ein Befehl sendet wartet Fhem auf einen Rückmeldung des ZWave Aktors. Wenn diese kommt trägt Fhem sie in in das Device ein und kann sicher gehen, dass es geschaltet hat.

Wenn die Rückmeldung nicht nach einer gewissen Zeit kommt, meldet Fhem NoAck (keine Rückmeldung) des Device.

Also im prinzip so wie HM...

Das einzige, was es nicht gibt, ist ein activity Reading, was nach einer gewissen zeit auf inactiv gesetzt wird, wenn der Aktor nicht erreichbar ist.

Somit kannst du dir immer gewisse sein, wann die Steckdose an oder aus ist (da sie wie gesagt ihren eigenen Status immer bei Status wechseln sendet).

Es sei denn du hast schlechten Empfang zum Aktor und das Funk Telegramm kommt nicht durch. Dann kriegst du ein NoAck zurück obwohl du eigentlich auf on geschaltet hast. Aber sowas kannst du ja vermeiden in dem du:

  • mehrere Aktoren kaufst, um ein gescheites meshed Network auf zu bauen.
  • Vorher sicherstellst, dass der Aktor nah genug am Sender sitzt (Fhem)

Ansonsten wirst du imme NoAck bekommen wenn die Zwishensteckdose nicht in der Steckdose steckt. ;)


Sonst lies dir mal ein bisschen was zu ZWave durch.

Gruß,

Fixel

Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

rudolfkoenig

Um ein activity-Flag zu realisieren muss man Geraete regelmaessig pollen, bei Batteriebetriebenen den wakeupInterval auf einen relativ kleinen Wert setzen. Ich finde sowas fuer alle einzufuehren (noch?) eine schlechte Idee. Wer das unbedingt will, kann sowas mit einem at basteln, und seine Erfahrungen hier mitteilen.

Eine Alternative ist solche Probleme organisatorisch zu loesen, indem man das Entfernen wichtiger Steckdosen unter androhung von Strafe verbietet.

Fixel2012

#7
Zitat von: rudolfkoenig am 24 August 2017, 09:48:52
Um ein activity-Flag zu realisieren muss man Geraete regelmaessig pollen, bei Batteriebetriebenen den wakeupInterval auf einen relativ kleinen Wert setzen. Ich finde sowas fuer alle einzufuehren (noch?) eine schlechte Idee. Wer das unbedingt will, kann sowas mit einem at basteln, und seine Erfahrungen hier mitteilen.

nötig finde ich das nicht, auch bei HM finde ich dafür keinen Gebrauch.

Da müsste es schon entsprechende Gründe geben.  :)
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

dantist

Zitat von: Fixel2012 am 24 August 2017, 10:25:58
nötig finde ich das nicht, auch bei HM finde ich dafür keinen Gebrauch.

Da müsste es schon entsprechende Gründe geben.  :)

Wenn ich unterwegs bin und eine Steckdose prüfen will, sehe ich bei Homematic sofort, wenn etwas nicht stimmt -> unreachable. Wenn die Z-Wave Dose warum auch immer die Verbindung verliert, zeigt FHEM weiterhin den letzten Status an, und schlimmer noch, ändert den Status scheinbar erfolgreich, wenn man sie per Interface an oder ausschaltet.

Wegen solcher Unsicherheiten bin ich von normalen Funksteckdosen weg zu "smarten" Lösungen. Natürlich lässt sich mit dem "NO_ACK"-Hinweis ein Workaround bauen, aber eine out of the box-Lösung wie bei Homematic wäre meiner Meinung nach auch bei Z-Wave sinnvoll.

Fixel2012

Zitat von: dantist am 24 August 2017, 14:43:16
Wenn ich unterwegs bin und eine Steckdose prüfen will, sehe ich bei Homematic sofort, wenn etwas nicht stimmt -> unreachable. Wenn die Z-Wave Dose warum auch immer die Verbindung verliert, zeigt FHEM weiterhin den letzten Status an, und schlimmer noch, ändert den Status scheinbar erfolgreich, wenn man sie per Interface an oder ausschaltet.

Wegen solcher Unsicherheiten bin ich von normalen Funksteckdosen weg zu "smarten" Lösungen. Natürlich lässt sich mit dem "NO_ACK"-Hinweis ein Workaround bauen, aber eine out of the box-Lösung wie bei Homematic wäre meiner Meinung nach auch bei Z-Wave sinnvoll.

Naja, ich hatte bei HM schon den Fall, dass ich erst nach mehreren Stunden die Rückmeldung bekommen habe, dass das Gerät nicht erreichbar ist.

Da bringt dir das auch nicht viel.
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

rudolfkoenig

unreachable ist ja auch nicht ganz korrekt, FHEM empfaengt nur keine Daten. Ob das Geraet die FHEM-Befehle empfangen und ausgefuehrt hat, weiss man nicht. Laeuft auf die Diskussion hinaus, ob eine Steckdose mit ACK besser ist, als eine ohne (HomeMatic/ZWave vs. FS20): ich meine das ist egal, da ich nicht so recht weiss, was ich machen soll, wenn ich "NO_ACK" habe.

krikan

#11
Welche Information kann man denn in dem hier beschrieben Anwendungsfall aus "unreachable" oder "NO_ACK" ableiten? Das kann doch alles bedeuten:
- Zwischenstecker ist ausgezogen.
- Temporäre Funkstörungen
- Zwischenstecker ist defekt
- Zwischenstecker schmorrt
- Zwischenstecker steht mit Zimmer in Flammen
Was also ist bei NO_ACK zu unternehmen? NO_ACK ist mMn zu vieldeutig, um daraus Schlüsse zu ziehen.

Hier https://forum.fhem.de/index.php/topic,57781.0.html findet man die Begründung, warum NO_ACK nicht im state landet.

Das Gewünschte kann man mit einem stateFormat selbst erreichen.
Wenn der Zeitstempel von state deutlich jünger als reportedstate ist und in transmit ein NO_ACK steht, dann war der letzte Schaltvorgang nicht erfolgreich und man könnte ein NO_ACK oder "unreachable" ausweisen.




dantist

#12
Ich habe es grade noch einmal mit Homematic getestet: Wenn ich dort die Steckdose vom Strom nehme und im Interface an oder ausschalte, wird der State auf set_on bzw. set_off gesetzt und der unklare Status mit einem entsprechenden Icon (graue Lampe mit Ausrufezeichen) angezeigt.

Man kann natürlich darüber streiten, ob sowas in den State oder ein Reading gehört, aber ein eindeutiges "on" bzw. "off" bei Z-Wave, obwohl die Steckdose dies nicht bestätigt hat, halte ich für falsch. Das Interface zeigt einen Zustand an, von dem nicht klar ist, ob er korrekt ist. Der fehlende Warnhinweis im Interface wiegt den Nutzer in falscher Sicherheit.

tomspatz

Glaube nicht das das ein fhem "Problem" ist.
Wie sieht soetwas wohl bei dem Fibaro HC aus?

Wobei dieses Szenario mE schon schräg ist.

LG
Tom

krikan

Zitat von: dantist am 24 August 2017, 20:49:49
Man kann natürlich darüber streiten, ob sowas in den State oder ein Reading gehört, aber ein eindeutiges "on" bzw. "off" bei Z-Wave, obwohl die Steckdose dies nicht bestätigt hat, halte ich für falsch. Das Interface zeigt einen Zustand an, von dem nicht klar ist, ob er korrekt ist. Der fehlende Warnhinweis im Interface wiegt den Nutzer in falscher Sicherheit.
Vielleicht hilft Dir das:
Das Reading "reportedState" enthält den letzten vom Aktor gemeldeten Schaltzustand.

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. :-)

krikan

Zitat von: FunkOdyssey am 14 September 2017, 14:00:52
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. :-)
Ja, Du hast Recht habe ich bewußt nur noch nie wahrgenommen; arbeite wohl zuviel mit stateFormat.

@Rudi: vergiß bitte den nicht verstandenen 2. Absatz; das war Blödsinn.

rudolfkoenig

ZitatIch habe ein Fibaro FGS-222 (2-fach Relais), in welchem nun bei den Kanälen der falsche Status angezeigt wird:
Danke fuer die Meldung, habs gefixt, kurz getestet und eingecheckt.

FunkOdyssey


FunkOdyssey

Ähm. Irgendwie klappt das wohl doch nicht.
Schalte ich manuell, so klappt es.
Aber wenn über DOIFs & Co. geschaltet wird, so verbleibt die Anzeige bei ,,set_on".
Das Log ist recht umspannend.

krikan

Konnte hier gestern keinerlei Fehlfunktion feststellen bei diversen notify iVm FGS213 und FGS223.

FunkOdyssey

#35
Bei meinem FGS-222 bleibt der Kanal 01 auf "set_off" stehen. Ich schalte bewusst die Kanäle 01 und 02 und nicht das Master-Device. Ich schalte die Kanäle immer zeitgleich. Im Log zum Kanal 01 gibt es ein paar mehr Ausschaltversuche, da ich diese dann noch einmal manuell über die GUI ausschalte.

Kanal 01:
2017-09-15_20:31:11 zw_garten_01 set_on
2017-09-16_00:12:50 zw_garten_01 set_off
2017-09-16_00:13:51 zw_garten_01 set_off
2017-09-16_01:22:00 zw_garten_01 set_off
2017-09-16_01:23:00 zw_garten_01 set_off
2017-09-16_01:24:49 zw_garten_01 set_off
2017-09-16_01:25:49 zw_garten_01 set_off
2017-09-16_08:33:03 zw_garten_01 set_off
2017-09-16_08:34:03 zw_garten_01 set_off
2017-09-16_20:26:13 zw_garten_01 set_on
2017-09-17_00:22:44 zw_garten_01 set_off
2017-09-17_00:23:45 zw_garten_01 set_off
2017-09-17_01:22:05 zw_garten_01 set_off
2017-09-17_01:22:17 zw_garten_01 set_off
2017-09-17_01:23:05 zw_garten_01 set_off
2017-09-17_01:24:40 zw_garten_01 set_off
2017-09-17_01:25:40 zw_garten_01 set_off
2017-09-17_20:26:13 zw_garten_01 set_on
2017-09-17_21:30:25 zw_garten_01 set_on
2017-09-17_21:30:25 zw_garten_01 on
2017-09-17_23:11:44 zw_garten_01 set_off
2017-09-17_23:12:44 zw_garten_01 set_off
2017-09-18_01:23:20 zw_garten_01 set_off
2017-09-18_01:24:20 zw_garten_01 set_off
2017-09-18_07:03:03 zw_garten_01 set_off
2017-09-18_07:04:03 zw_garten_01 set_off
2017-09-18_10:40:47 zw_garten_01 set_off
2017-09-18_10:40:47 zw_garten_01 off


Kanal 02:
2017-09-15_20:31:11 zw_garten_02 set_on
2017-09-15_20:31:12 zw_garten_02 on
2017-09-16_00:12:50 zw_garten_02 set_off
2017-09-16_00:12:51 zw_garten_02 off
2017-09-16_00:13:51 zw_garten_02 set_off
2017-09-16_00:13:51 zw_garten_02 off
2017-09-16_01:22:00 zw_garten_02 set_off
2017-09-16_01:22:00 zw_garten_02 off
2017-09-16_01:23:00 zw_garten_02 set_off
2017-09-16_01:23:00 zw_garten_02 off
2017-09-16_01:24:49 zw_garten_02 set_off
2017-09-16_01:24:49 zw_garten_02 off
2017-09-16_01:25:49 zw_garten_02 set_off
2017-09-16_01:25:49 zw_garten_02 off
2017-09-16_08:33:03 zw_garten_02 set_off
2017-09-16_08:33:03 zw_garten_02 off
2017-09-16_08:34:03 zw_garten_02 set_off
2017-09-16_08:34:03 zw_garten_02 off
2017-09-16_20:26:13 zw_garten_02 set_on
2017-09-16_20:26:13 zw_garten_02 on
2017-09-17_00:22:44 zw_garten_02 set_off
2017-09-17_00:22:45 zw_garten_02 off
2017-09-17_00:23:45 zw_garten_02 set_off
2017-09-17_00:23:45 zw_garten_02 off
2017-09-17_01:22:05 zw_garten_02 set_off
2017-09-17_01:22:05 zw_garten_02 off
2017-09-17_01:22:17 zw_garten_02 set_off
2017-09-17_01:22:17 zw_garten_02 off
2017-09-17_01:23:05 zw_garten_02 set_off
2017-09-17_01:23:05 zw_garten_02 off
2017-09-17_01:24:40 zw_garten_02 set_off
2017-09-17_01:24:40 zw_garten_02 off
2017-09-17_01:25:40 zw_garten_02 set_off
2017-09-17_01:25:40 zw_garten_02 off
2017-09-17_20:26:13 zw_garten_02 set_on
2017-09-17_20:26:13 zw_garten_02 on
2017-09-17_23:11:44 zw_garten_02 set_off
2017-09-17_23:11:44 zw_garten_02 off
2017-09-17_23:12:44 zw_garten_02 set_off
2017-09-17_23:12:44 zw_garten_02 off
2017-09-18_01:23:20 zw_garten_02 set_off
2017-09-18_01:23:20 zw_garten_02 off
2017-09-18_01:24:20 zw_garten_02 set_off
2017-09-18_01:24:20 zw_garten_02 off
2017-09-18_07:03:03 zw_garten_02 set_off
2017-09-18_07:03:04 zw_garten_02 off
2017-09-18_07:04:04 zw_garten_02 set_off
2017-09-18_07:04:04 zw_garten_02 off

krikan

Beim FGS222 ist es meiner Erinnerung nach so -zumindest habe ich das im Wiki festgehalten- ,dass der Status von Kanal 1 nur an das Hauptdevice gemeldet wird und nicht an das Endpoint-Device 1. Warum das beim manuellen Schalten von FHEM erkannt wird und nicht beim notify kann ich in Trockenübung ohne verbose 5 Log nicht nachvollziehen.

Ansatzpunkt bei der Assoziation und außerhalb von FHEM: Du könntest auch einmal mit einer mcaAdd wie beim FGS2223 statt einer normalen Assoziation probieren.

FunkOdyssey

Ich habe bereits überall das verbose auf höchster Stufe. Aber das bringt nichts. Es steht nicht mehr im Log.
Dies spielt aber keine große Rolle, weil das Problem wahrscheinlich wirklich woanders liegt.
Ich habe die Ein- und Ausschaltreihenfolge in den DOIFs mal geändert und prompt bleibt der andere Kanal in "set_on/set_off" stehen. Und dies obwohl die Relais aber wirklich ausgeschaltet wurden. Keine Ahnung, ob beim Wechsel von "set_off" auf "off" auf ein weitere ACK gewartet wird.
Die Probleme habe ich beim manuelle Umschalten nicht, da dies halt nicht so schnell gemacht wird, wie ein DOIF & Co.

Am Rande: Die Probleme bei mir sind eher etwas für andere Threads und brauchen wir hiermit nicht weiter verfolgen. Tatsache ist jedoch, dass sich irgendetwas vor kurzem geändert haben muss, da ich eine extreme Häufung an NO_ACKs habe. Ich kann keine zwei Geräte gleichzeitig (bzw. sequentiell) mehr einschalten. Und ich habe schon ne Menge "async_delay", wait und sleeps gesetzt. Komisch komisch.

krikan

Zitat von: FunkOdyssey am 19 September 2017, 15:00:56
Ich habe bereits überall das verbose auf höchster Stufe. Aber das bringt nichts. Es steht nicht mehr im Log.
Im Logfile steht bei verbose 5 am ZWDongle-Device bestimmt mehr drin; das meinte ich.

ZitatDie Probleme bei mir sind eher etwas für andere Threads und brauchen wir hiermit nicht weiter verfolgen. Tatsache ist jedoch, dass sich irgendetwas vor kurzem geändert haben muss, da ich eine extreme Häufung an NO_ACKs habe.
Kann ich nicht beurteilen.
Wenn die Bestätigung für den off-Befehl ausbleibt und "set_off" stehen bleibt, dann arbeitet "showSetInState" doch wie gewünscht.