HMCCUDEV: on-for-timer

[zap]

Hallo ZAP,

eine Frage zur Sicherheit: wenn ich den HMIP-BSM in Verbindung mit HMCCU und dem on-for-timer nutze, wird dann die Zeit für die Abschaltung vor dem in Befehl am den Aktor gesendet, so dass dieser nach dem Einschalten keinen Befehl mehr von der CCU zum Abschalten braucht. Der Aktor regelt das ausschalten dann autark? Ist das korrekt?

Vielen Dank

Die on-for-timer Funktion setzt den Datenpunkt ON_TIME im Aktor. Der Aktor schaltet dann autark (unabhängig von CCU und FHEM) ab, wenn die Zeit abgelaufen ist.

[daelch]

Super. Vielen Dank, zap.

[peterk_de]

Kann ich dieses coole non-blocking-sichere on-for-timer eigentlich auch mit HMCCUDEVs nutzen, die mehr als einen Schaltkanal haben? Konkret hab ich hier einen HM-LC-Sw4-Ba-PCB, wo ich on-for-timer für alle 4 Schaltkanäle benötigen würde  - aber das on-for-timer kann ich ja immer nur auf dem einen Kanal nutzen, den ich als Statedatapoint definiert habe, richtig? Oder muss ich dazu 4 HMCCUCHN-Devices anlegen?

(Aktuell mach ich das als Workaround und weil ichs nicht besser weiß ^^über ein Notify und warte 2 Sekunden nach dem Setzen der on-time mit dem Anschalten, um sicherzugehen, dass der Befehl vorher durch ist. Das führt aber eben zu nem unnötigen Delay)

[zap]

Wenn die 4 Schaltkanäle unterschiedliche Ziele schalten, würde ich Dir empfehlen, mehrere HMCCUCHNs anzulegen. Es geht aber auch mit HMCCUDEV. on-for-timer und on-till sind eigentlich nur Abkürzungen. Wenn Du den Befehl set datapoint verwendest, kannst Du das auf beliebige Kanäle anwenden.

Beispiel für die Kanäle 1 und 2:

Code Auswählen Erweitern

set myDev datapoint 1.ON_TIME 30 1.STATE true
set myDev datapoint 2.ON_TIME 30 2.STATE true

Wichtig: Zuerst ON_TIME und dann STATE setzen.

[peterk_de]

zap, ich danke dir! Klappt prima!!

[Dirk070]

Hallo zusammen,

der Thread ist schon älter, mein Problem aber das selbe.
Genutzt wird ein HmIP-BSL

Auch hier funktioniert das Abschalten beim on-for-timer manchmal nicht.
Welche Lösung ist denn die aktuelle? ON_TIME und STATE setzen mit nonBlocking oder ohne?

Danke Euch und schöne Grüße
Dirk

[zap]

Hallo zusammen,

der Thread ist schon älter, mein Problem aber das selbe.
Genutzt wird ein HmIP-BSL

Auch hier funktioniert das Abschalten beim on-for-timer manchmal nicht.
Welche Lösung ist denn die aktuelle? ON_TIME und STATE setzen mit nonBlocking oder ohne?

Danke Euch und schöne Grüße
Dirk

Ich teste das mal mit 4.4

[Dirk070]

Ich teste das mal mit 4.4

Prima, Danke Dir.

Aktuell schalte ich wie folgt, aber auch das scheint nicht immer zuverlässig zu funktionieren, hier eruiere ich aber noch die exakte Fehlerkonstellation:

Code Auswählen Erweitern

$LICHT_CCU .= "CCU_EG_FL_BSL_FLUR.4.ON_TIME=600 CCU_EG_FL_BSL_FLUR.4.STATE=true";
fhem ("set ccu3 datapoint $LICHT_CCU");

[Dirk070]

Ich habe versucht mein Problem weiter einzugrenzen.

Um den on-for-timer zu ersetzen, habe ich das folgende Coding genutzt:

Code Auswählen Erweitern

fhem("set CCU_EG_FL_BSL_FLUR on; sleep 600; set CCU_EG_FL_BSL_FLUR off");
Funktionierte im Test, heute aber dann nicht, sprich die Lampe war nicht an.
So langsam verdächtige ich den BSL.

Dann wollte ich einen Test über rpcparameter machen:

Code Auswählen Erweitern

set CCU_EG_FL_BSL_FLUR rpcparameter 4 VALUES STATE=1"

Hier bekomme ich nur die Fehlermeldung:

Code Auswählen Erweitern

Execution of CCU script or command failed

Sicherheitshalber einen Test mit einer Rollade (Broll):

Code Auswählen Erweitern

set CCU_EG_WZ_Bl1PBU_GAL rpcparameter 4 VALUES LEVEL=90

Selbe Fehlermeldung.

Dazu kommt dann noch, dass ich in einer zentralen Funktion meine 10 Rollade schalte.
Das in einem Rutsch mit "set ccu3 datapoint":

Code Auswählen Erweitern

CCU_EG_KU_Bl1PBU_STR.4.LEVEL=100 CCU_EG_WZ_Bl1PBU_GAL.4.LEVEL=100 CCU_EG_WZ_Bl1PBU_GAR.4.LEVEL=100 CCU_EG_WZ_Bl1PBU_ST.4.LEVEL=100 CCU_OG_BD_Bl1PBU_STR.4.LEVEL=100 CCU_OG_NZ_Bl1PBU_ST.4.LEVEL=100 CCU_OG_NZ_Bl1PBU_STR.4.LEVEL=100 CCU_OG_SZ_Bl1PBU_GAL.4.LEVEL=50 CCU_OG_SZ_Bl1PBU_GAR.4.LEVEL=50 CCU_OG_SZ_Bl1PBU_ST.4.LEVEL=50

Hier werden immer mal wieder einzelne Befehle nicht ausgeführt (Rollade fährt nicht), kein Fehler im Log und in den CCU-Logs finde ich auch nichts. Ein reines Empfangsproblem kann ich zumindest heute ausschliessen, die Rollade ist 2-3 Meter vom HAP entfernt.

zap, wenn ich noch was testen kann, dann gerne.

Viele Grüße und vielen Dank vorab
Dirk

[Dirk070]

Um den on-for-timer zu ersetzen, habe ich das folgende Coding genutzt:

Code Auswählen Erweitern

fhem("set CCU_EG_FL_BSL_FLUR on; sleep 600; set CCU_EG_FL_BSL_FLUR off");
Funktionierte im Test, heute aber dann nicht, sprich die Lampe war nicht an.
So langsam verdächtige ich den BSL.

Dazu kommt dann noch, dass ich in einer zentralen Funktion meine 10 Rollade schalte.
Das in einem Rutsch mit "set ccu3 datapoint":

Code Auswählen Erweitern

CCU_EG_KU_Bl1PBU_STR.4.LEVEL=100 CCU_EG_WZ_Bl1PBU_GAL.4.LEVEL=100 CCU_EG_WZ_Bl1PBU_GAR.4.LEVEL=100 CCU_EG_WZ_Bl1PBU_ST.4.LEVEL=100 CCU_OG_BD_Bl1PBU_STR.4.LEVEL=100 CCU_OG_NZ_Bl1PBU_ST.4.LEVEL=100 CCU_OG_NZ_Bl1PBU_STR.4.LEVEL=100 CCU_OG_SZ_Bl1PBU_GAL.4.LEVEL=50 CCU_OG_SZ_Bl1PBU_GAR.4.LEVEL=50 CCU_OG_SZ_Bl1PBU_ST.4.LEVEL=50

Hier werden immer mal wieder einzelne Befehle nicht ausgeführt (Rollade fährt nicht), kein Fehler im Log und in den CCU-Logs finde ich auch nichts. Ein reines Empfangsproblem kann ich zumindest heute ausschliessen, die Rollade ist 2-3 Meter vom HAP entfernt.

Die beiden oben zitierten Probleme konnte ich lösen.
Neben der CCU3 hängt eine FritzBox, WLAN ist hier abgeschaltet, daher ist das kein Problem.
Wenn man aber im eigenen Netzwerk umbaut und dabei dann die DECT-Basis aktiviert, ist man (ich) selber schuld.

Spannend ist nur, dass dadurch nicht die komplette Kommunikation gestört wird und dadurch dann viel mehr Traffic über den HAP läuft. Es ergibt sich stattdessen ein völlig unprognostizierbares Verhalten.

Lange Rede: die beiden obigen Probleme sind seit der Deaktivierung der DECT-Basis gelöst.
Die Nutzung des rpcparameter habe ich immer noch nicht hinbekommen, jedoch verliert das Thema gerade (s.o.) an Bedeutung.

Das Setzen des ON-FOR-TIMER bleibt für mich dagegen relevant.
Entschuldigt, wenn ich mit meiner DECT-Basis hier für unnötigen Aufwand gesorgt habe