HM-ES-PMSw1-Pl an CCU2 mit HMCCUDEV und on-for-timer

[ext23]

Ich habe das Problem jetzt schon bei der dritten Dose, dass das on-for-timer nicht funktioniert und die Dose dauer an bleibt. Das kann doch nicht sein, dass das nur bei mir so ist? Ich nutze die für meine Gießanlage und da ist es natürlich blöd wenn die Pumpe trocken läuft weil die Dose nicht aus geht.

Kann man das nicht irgendwo im HMCCU Modul abfangen? Das Problem tritt ja nur sporadisch auf. Das muss ja entweder ein Bug in der CCU Software sein oder in der API für HMCCU.

HM-ES-PMSw1-Pl FW 2.5
CCU2 2.45.7
HMCCU 4.3.015

/Daniel

[amenomade]

Zeig ein "list" von der Dose bitte

[zap]

Es scheint ja ab und zu zu funktionieren. In früheren Versionen von HMCCU waren ON_TIME und STATE unabhängige Requests. Da konnte es schon vorkommen, dass nur STATE durchkam. Mittlerweile werden beide Datenpunkte aber in einem Request geschickt.

Wichtig ist: wenn einmal ein on-for-timer geschickt wurde, darf danach bis zum Ablauf des Timers nicht nochmal ein separates STATE = true geschickt werden. Das würde vermutlich den Timer löschen und die Dose würde immer an bleiben.

[amenomade]

Mittlerweile werden beide Datenpunkte aber in einem Request geschickt.

@zap: gibt es noch dieses Problem mit nonBlocking und Reihenfolge von den Befehle (deswegen wollte ich ein "list" sehen) oder wurde es damit behoben

[ext23]

Zeig ein "list" von der Dose bitte

Wenn es denn hilft:

Code Auswählen Erweitern

Internals:
   DEF        HM-PMSW-01 defaults
   FUUID      5c4aea31-f33f-2323-9c31-ff3216c7639ba43b
   IODev      CCU2_01
   NAME       HM_PMSW_01
   NR         2336
   STATE      off
   TYPE       HMCCUDEV
   ccuaddr    KEQ0971925
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    HM-PMSW-01
   ccutype    HM-ES-PMSw1-Pl
   channels   7
   firmware   2.5
   statevals  devstate|on|off
   READINGS:
     2019-06-15 11:41:33   0.RSSI_DEVICE   1
     2019-07-05 11:53:08   1.STATE         off
     2019-07-06 12:35:49   2.CURRENT       0.0
     2019-07-06 12:35:49   2.ENERGY_COUNTER 192.2
     2019-07-06 12:35:49   2.FREQUENCY     50.0
     2019-07-06 12:35:49   2.POWER         0.0
     2019-07-06 12:35:49   2.VOLTAGE       230.7
     2019-07-06 00:07:07   Activity        alive
     2019-07-05 11:53:08   control         off
     2019-07-06 12:35:49   hmstate         off
     2019-06-15 11:41:33   sign            off
     2019-07-05 11:53:08   state           off
   hmccu:
     devspec    HM-PMSW-01
     dp:
       0.AES_KEY:
         OSVAL      off
         OVAL       0
         SVAL       off
         VAL        0
       0.CONFIG_PENDING:
         OVAL       false
         VAL        false
       0.DEVICE_IN_BOOTLOADER:
         OVAL       false
         VAL        false
       0.DUTYCYCLE:
         OVAL       false
         VAL        false
       0.RSSI_DEVICE:
         OSVAL      1
         OVAL       1
         SVAL       1
         VAL        1
       0.RSSI_PEER:
         OVAL       186
         VAL        186
       0.STICKY_UNREACH:
         OVAL       1
         VAL        1
       0.UNREACH:
         OSVAL      dead
         OVAL       1
         SVAL       alive
         VAL        0
       0.UPDATE_PENDING:
         OVAL       false
         VAL        false
       1.INHIBIT:
         OVAL       false
         VAL        false
       1.STATE:
         OSVAL      on
         OVAL       1
         SVAL       off
         VAL        0
       1.WORKING:
         OVAL       0
         VAL        0
       2.BOOT:
         OVAL       1
         VAL        1
       2.CURRENT:
         OSVAL      0.0
         OVAL       0.000000
         SVAL       0.0
         VAL        0.000000
       2.ENERGY_COUNTER:
         OSVAL      192.2
         OVAL       192.200000
         SVAL       192.2
         VAL        192.200000
       2.FREQUENCY:
         OSVAL      50.0
         OVAL       49.970000
         SVAL       50.0
         VAL        49.980000
       2.POWER:
         OSVAL      0.0
         OVAL       0.000000
         SVAL       0.0
         VAL        0.000000
       2.VOLTAGE:
         OSVAL      231.1
         OVAL       231.100000
         SVAL       230.7
         VAL        230.700000
       3.DECISION_VALUE:
         OVAL       0
         VAL        0
       4.DECISION_VALUE:
         OVAL       0
         VAL        0
       5.DECISION_VALUE:
         OVAL       0
         VAL        0
       6.DECISION_VALUE:
         OVAL       0
         VAL        0
Attributes:
   IODev      CCU2_01
   alias      Gießanlage Blumen
   ccureadingfilter (STATE|CURRENT|ENERGY_COUNTER|POWER|VOLTAGE|FREQUENCY)
   controldatapoint 1.STATE
   room       Balkon
   statedatapoint 1.STATE
   statevals  on:1,off:0
   stripnumber 1
   substitute STATE!(1|true):on,(0|false):off
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
   webCmd     control
   widgetOverride control:uzsuToggle,off,on

@zap:
Ich bin mir ziemlich sicher, das tritt nur auf, wenn die Dose schlechten Empfang hat. Ich sehe auch ab und an mal Meldungen in der CCU2, dass die Kommunikation gestört war. Nichts desto trotz darf das aber nicht passieren. Das ist bestimmt ein Bug in dem Protokoll der CCU2.

Ich setze jetzt zusätzlich immer noch ein AT der nach Ablauf der on-for-timer zeit mir eine Push Message schickt wenn die Dose noch an ist, aber ist eben auch nur ne Krücke.

Sind denn die Entwickler da erreichbar von eq3? Kann man da ein case öffnen oder gibt es solche Möglichkeiten nicht?

[frank]

wenn die ccu wie cul_hm funktioniert, dann besteht ein on-for-timer befehl aus einer einzigen message an das device. wenn der aktor an geht, muss er auch wieder aus gehen. ausser er ist defekt oder hat zufällig eine gestörte message empfangen, die zufällig eine längere einschaltzeit enthält.

ansonnsten kann nur ein zusätzlicher on befehl das ausschalten verhindern.

du könntest den aktor ja mal auf cul_hm umbauen.
zumindestens von cul_hm aus sniffen.

schlechter empfang kann das ausschalten eigentlich nicht verhindern. den kann auch eq3 nicht verbessern.

[zap]

Nicht die  CcU steuert den Timer sondern das Device selbst. Wenn das Device den ON_TIME erhalten hat und angeht, muss es auch wieder ausgehen. Es sei denn, die Firmware hat einen Bug.
Wenn es an geht, hat zwischen HMCCU- CCU und Device erdt mal alles richtig funktioniert.

Warum lässt du dir mit at eine Notification schicken? Schicke dem Device doch gleich ein OFF.

[ext23]

Also die LED ist an, sprich sie bekommt anstelle von on-for-timer ein on. Sonst würde die LED ja blinken. Sprich defekt (da bei 3 Dosen) und falsche Zeit (weil leuchtet) kann es nicht sein.

Wenn das nur ein Kommando ist, dann muss da trotzdem irgend was nicht stimmen mit dem Protokoll.

Mit CULHM und HMLAN haben die Dosen immer funktioniert.

Warum lässt du dir mit at eine Notification schicken? Schicke dem Device doch gleich ein OFF.
>Mache ich auch, die Message ist nur, dass ich es auch mitbekomme wann es passiert. Aber ich finde das nicht als saubere Lösung weil dann kann ich gleich den on-for-timer von FHEM benutzen und das möchte ich ja gerade nicht aus Sicherheitsgründen. Fällt FHEM aus, habe ich ja dasselbe Problem. Ich minimiere zwar den Fall dass es passiert aber sicher ist es dennoch nicht.

Auch wenn ich es als Programm mit der CCU2 erstelle sind es aber 2 Kommandos, erst den Timer setzen und dann die Dose ganz normal anschalten. Da geht doch bestimmt der erste Befehl flöten ab und an. Kann ich eigentlich irgendwie abfragen ob die Dose im "on" oder "on-for-timer" ist? Auf der CCU2 Seite sieht man ja dann so ein Zahnrad wenn ich mich recht entsinne.

/Daniel

[zap]

Im Prinzip ist ein on-for-timer bei HMCCU nur die Abkürzung für

set xy datapoint ON_TIME Zeit STATE true

Beide Datenpunkte werden in einem Request an die CCU geschickt. Die CCU schickt die Settings dann an das Gerät.
Früher waren das 2 Requests. Da war die Wahrscheinlichkeit durchaus da, dass zB ON_TIME verloren ging.

[ext23]

Im Prinzip ist ein on-for-timer bei HMCCU nur die Abkürzung für

set xy datapoint ON_TIME Zeit STATE true

Beide Datenpunkte werden in einem Request an die CCU geschickt. Die CCU schickt die Settings dann an das Gerät.
Früher waren das 2 Requests. Da war die Wahrscheinlichkeit durchaus da, dass zB ON_TIME verloren ging.

Du meinst zwischen HMCCU und CCU2 ja? Aber wie sieht es auf dem Funk aus? Aber mhh naja egal, ich ruf da mal bei EQ3 an und frag nach was das sein kann.

Ich habe jetzt ein Programm auf der CCU2 was genau das macht und das trigger ich durch einen der Virtuellen Buttons. Wenn es dort auch passiert ist es definitiv die CCU2. Den Button an der Dose kann ich nicht aktivieren über FHEM oder? Weil dort kann man ja in der HW hinterlegen das die Dose nur eine Zeit x angeht, da würde das Problem dann vielleicht auch nicht auftreten.

/Daniel

[zap]

Du kannst mit "set config" alles einstellen, was sich auch über die Geräteeinstellungen in der CCU ändern lässt. Leider sind die Namen der Parameter nicht dokumentiert. Man kann die aktuellen Einstellungen aber mit

get configlist

oder

get configlist Kanalnummer

Für das Gerät bzw. einen einzelnen Kanal abfragen. Aus den angezeigten Daten lässt sich meistens der Parametername ableiten.

[ext23]

Naja da ist nichts bei ja, aber die CCU2 zeigt es dennoch an, also die kann vermutlich etwas mehr als man über die API bekommt.

/Daniel