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
Zeig ein "list" von der Dose bitte
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.
ZitatMittlerweile 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
Zitat von: amenomade am 05 Juli 2019, 23:52:27
Zeig ein "list" von der Dose bitte
Wenn es denn hilft:
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?
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.
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.
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
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.
Zitat von: zap am 07 Juli 2019, 10:10:16
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
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.
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