HM-CC-RT-DN

[martinp876]

ein device das conditional burst (also burst einschaltbar ) unterstützt wird, wenn vom User ein burst-transmitt gefordert wird, getestet, ob burst aktuell verfügbar ist oder nicht. FHEM versucht genau einmal nach User-request - ob burst funktioniert und schreibt das Ergebniss in diesen Parameter.

[CQuadrat]

Danke für die Antwort.

Und dass bei den RTs, die mit Fensterkontakten gepeert sind, sehr häufig burst nicht funktioniert ist wohl Zufall. Oder?

[martinp876]

verstehe ich nicht.
ein SC  der mit einem RT gepeert ist sollte tunlichst burst senden
beim RT sollte tunlichst burst enabled sein.

zufall sollte das nicht sein - das sollte man korrekt konfigurieren. FHEM sollte hier entsprechend burst einschalten, auf beiden Seiten.

Gruss Martin

[CQuadrat]

verstehe ich nicht.
ein SC  der mit einem RT gepeert ist sollte tunlichst burst senden
beim RT sollte tunlichst burst enabled sein.

zufall sollte das nicht sein - das sollte man korrekt konfigurieren. FHEM sollte hier entsprechend burst einschalten, auf beiden Seiten.

Gruss Martin

Kann es sein, dass ein RT nur von einem Device aufgeweckt werden kann? Hier dann der gepeerte SC. Befehle von der Zentrale benötigen - zumindest bei mir - bei den SC-gepeerten RTs immer eine gewisse Zeit. Bei den ungepeerten RTs kommen alle Befehle (fast) sofort am RT an.


Viele Grüße

Christoph

[Mr. P]

Kann es sein, dass ein RT nur von einem Device aufgeweckt werden kann? Hier dann der gepeerte SC. Befehle von der Zentrale benötigen - zumindest bei mir - bei den SC-gepeerten RTs immer eine gewisse Zeit. Bei den ungepeerten RTs kommen alle Befehle (fast) sofort am RT an.

Hej Christoph,

nein - ist definitiv nicht so. Ich arbeite mich auch gerade in die RT/SC-Thematik ein und es funktioniert alles (mehr oder weniger) problemlos. Also zumindest das Aufwecken tut, wie es soll (sowohl von der Zentrale als auch vom SC). Das melden an die Zentrale + an vier Peers erfolgt (noch) nicht sooo ganz zuverlässig, wie ich es gerne hätte. Da bleibt hier und da schon mal ein RT auf der Strecke.

[martinp876]

also noch einmal eine Langform:
ein burst weckt alle devices auf, die burst können. dann folgt die message mit sender-ID. jetzt sehen alle aufgewachten nach, ob die etwas mit dieser senderID zu schaffen haben (gepairt oder gepeert sind). wenn dass der Fall ist schauen sie in die Message hinein, ob sie diese verstehen....

Es ist, wie Mr. P gesagt hat - den RT von mehreren devices zu erwecken.
wenn diese aber nicht gepeert sind, schläft er wieder ein.

[noonscoomo]

Naben zusammen.
Darf ich mich hier kurz mit meinem Problemchen an euch wenden?
Ich habe vier HM-CC-RT-DN und zwei Fensterkontakte gekauft. Das Konfigurieren des Wochenprogramms der HM-CC-RT-DN und das Koppeln mit den Fensterkontakten hat einwandfrei geklappt.
Jetzt wollte ich die Dinger mit meinem CUL_v3 und FHEM bedienen, habe das pairing im FHEM eingeschaltet und bekomme auch einen einigermassen vernünftigen Eintrag in der fhem.cfg.

define CUL_HM_HM_CC_RT_DN_21DDFB CUL_HM 21DDFB
attr CUL_HM_HM_CC_RT_DN_21DDFB .devInfo 00FFFF
attr CUL_HM_HM_CC_RT_DN_21DDFB .stc 59
attr CUL_HM_HM_CC_RT_DN_21DDFB actCycle 000:10
attr CUL_HM_HM_CC_RT_DN_21DDFB actStatus
attr CUL_HM_HM_CC_RT_DN_21DDFB firmware 1.0
attr CUL_HM_HM_CC_RT_DN_21DDFB model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB peerIDs
attr CUL_HM_HM_CC_RT_DN_21DDFB room CUL_HM
attr CUL_HM_HM_CC_RT_DN_21DDFB serialNr KEQ0573577
attr CUL_HM_HM_CC_RT_DN_21DDFB subType thermostat
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_Weather CUL_HM 21DDFB01
attr CUL_HM_HM_CC_RT_DN_21DDFB_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_Weather peerIDs
attr CUL_HM_HM_CC_RT_DN_21DDFB_Weather room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Weather FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_Weather-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_Weather
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Weather logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Weather room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_Climate CUL_HM 21DDFB02
attr CUL_HM_HM_CC_RT_DN_21DDFB_Climate model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_Climate room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Climate FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_Climate-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_Climate
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Climate logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Climate room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec CUL_HM 21DDFB03
attr CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr CUL_HM 21DDFB04
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam CUL_HM 21DDFB05
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_remote CUL_HM 21DDFB06
attr CUL_HM_HM_CC_RT_DN_21DDFB_remote model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_remote room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_remote FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_remote-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_remote
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_remote logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_remote room CUL_HM
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector room CUL_HM
define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log ActionDetector
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room CUL_HM

Wenn ich mir dann den room CUL_HM anschaue bekomme ich
"ActionDetector alive:0 dead:0 unkn:1 off:0"
und hinter allen Einträgen unter CUL_HM stehen drei Fragezeichen, ebenso hinter dem Thermostat Eintrag

Wenn ich die "desired-temp" auf einen anderen Wert setze als 20 fängt es im Logfile ordentlich an zu rappeln:

2013.11.12 01:43:51 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 432
2013.11.12 01:43:55 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:43:55 5: SW: As0901B112F1123421DDFB
2013.11.12 01:43:55 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 433
2013.11.12 01:44:01 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:44:01 5: SW: As0901B112F1123421DDFB
2013.11.12 01:44:01 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 434
2013.11.12 01:44:06 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:44:06 5: SW: As0901B112F1123421DDFB
2013.11.12 01:44:06 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 435
2013.11.12 01:44:11 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:44:11 5: SW: As0901B112F1123421DDFB
2013.11.12 01:44:11 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 436

und es passiert genau nix am  HM-CC-RT-DN

Wenn ich den Fensterkontakt Paire seh ich den und bekomme auch ordentlich "open" bzw. "close" angezeigt.
Ich hab mir das Funksignal mal mit einem SDR angeschaut, da kommt erst ein ordentlicher Piep-Ton und dann ein paar Daten
Interessant ist, dass der Fensterkontakt diesen Piep-Ton nicht schickt, dafür klappte dann am HM-CC-RT-DN sofort.

Hab das alles auch mit einem anderen HM-CC-RT-DN ausprobiert, gleiches Ergebnis. Ein fhem update habe ich gemacht und ich hab die aktuellste CUL Firmware drauf, ausserdem hab ich den HM-CC-RT-DN komplett auf Werkseinstellungen redetet und noch mal gepaired.  Als Antenne hab ich ne Lambda/2, das machte aber wenig Pegel auf meinem SDR komischerweise, hab deshalb ein Kabel vernünftiger Länge genommen, viel besser der Pegel jetzt, trotzdem kann ich mit den Dingern nicht reden. Was mach ich falsch?

[noonscoomo]

Hat sich erledigt, hab's selbst rausgefunden...
Die Antwort ist, wenn man das Set CUL1 hmPairForSec 600 in der fhem.cfg einträgt geht das nicht. Man muss das Kommando in der Kommandozeile eingeben, dann sagen die Thermostate auch sofort AC wenn man in den Pairing mode geht und alles ist gut.

[Phil__]

Hallo,

zum Thema peeren von HM-CC-RT-DN mit einem HM-Sec-RHS Fensterkontakt wurde ja hier auf den letzten 37 Seiten einiges geschrieben.
Der Befehl allein bewirkt nicht wirklich viel.

Code Auswählen Erweitern

set <fenster-sensor> peerChan 0 <rt_WindowRec> single

Vielleicht kennt ja jemand hier eine zuverlässige Anleitung wie das peeren funktioniert und möchte das nocheinmal kundtun?!

Folgendes findet man zB auf den vorherigen 37 Seiten, was aber ziemlich verwirrend ist:

1) set <rt> clear msgEvents | bei dir ist die queue verstopft (siehe die noch 32 ausstehenden cmd's)
2) Prüfen, ob die queue leer ist => Reading "protcmdsPend" müsste was von CMDs_cleared oder 0 stehen => weiß es aber nicht mehr so genau?
2) set <hmlan> hmPairSerial KEQ0579448 (bitte die Seriennummer prüfen)
3) dann die Anlerntaste auf dem RT drücken -> dann ein wenig warten -> bis die CMDs abgearbeitet sind.

Kannst es ja mal versuchen - bei mir hat das so funktioniert.


Dann in FHEM neu paaren und ab gehts:
set HMLAN hmPairForSec 100
--Paarungstaste am Fensterkontakt drücken, dann blinkt er kurz gelb-grün--
set bad.klein.fenster peerChan 0 bad.klein.thermostat_WindowRec single
-- nun mal nochmal kurz die Paarungstaste drücken--

was du alles sehen solltest:
- fenster ist gepeert, RT_windowRec ist gepeert
- fenster hat "peerneedsburst" gesetzt (sonst wacht der RT nicht auf)
- fenster sendet beim öffnen einen trigger an den RT - notify und readings sind in FHEM zu sehen.


Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.

Danach geht's eigentlich generell...

Eine Schritt für Schritt Anleitung die man dann auch im Wiki platzieren kann wäre doch ganz gut!?
Geräte pairen, peeren und sonstige Einstellungen die notwendig sind wie zB set <RT> regSet burstRx on usw.

Danke und einen schönen Abend
Gruss Philipp

[snoop]

Hallo Philipp,

hmm ja das mit dem Wiki ist so eine Sache ... Zeit un Pflege...
Wie du festgestellt hast fehlt eine genaue Beschreibung.....

Es gibt eigentlich zwei Möglichkeiten (Beschreibung in Wiki folgt):

Variante 1: Peeren ausserhalb von FHEM (Das ganze muss ich aber noch verifizieren *das ganze nur aus dem Gedächtnis)

1) Anlernmodus auf dem RT aktivieren -> langer Tastendruck auf die "boost Taste (Taste in der Mitte)"
2) Anlernmodus auf dem RHS aktivieren -> drucke auf die Anlerntaste auf dem RHS (siehe Beschreibung/Bediensungsanleitung) -> (Meine Anleitung: Batterie-Deckel ab, hier befindet sich der Anlerntaste (liegt etwas tief) die gedrückt werden muss)
?) Bilder/Status fehlen - Wenn du jetzt Fester "auf/kippen lässt - müsste auf dem RT ein Fenter aufgehen bzw. sichbar sein.
Falls nicht, Vorgang wiederholen.
3) Falls alls ein Fenster zu sehen ist dann beginnt die FHEM pair Phase.
4) FHEM pair Prozess überspringe ich mal... Falls unklar einfach melden....
5) Danach sollte alles funktionieren.

Variante 2: Sensor (RHS) / Aktor RT mit FHEM pairen - anschliessend alles via peerChan über FHEM erledigen.

Anmerkung: Diese Variante habe ich bisher nicht erfolgreich getestet "sollte/müsste aber funktionieren" (Ich kämpfe aktuell mit Martin mit dem SC -> RHS folgt).
1) RHS mit FHEM pairen (FHEM pairing klar?)
2) RT mit FHEM pairen (FHEM pairing klar?)
3) set <fenster-sensor-SC/RHS> peerChan 0 <rt_WindowRec> single
4) Anlerntaste SC/RHS drücken "CMDs" prüfen...
5) set <RT>/<SC/RHS> getConfig ausführen -> bei SC/RHS Anlerntaste drücken
6) Channel: DG_HR_Gaestezimmer_WindowRec und Sensor <fenster-sensor> auf peer prüfen.

Sorry muss jetzt leider abbrechen - und stelle das mal zur Schau/Diskussion.

Viele Grüße
Arthur

[Phil__]

Variante 2: Sensor (RHS) / Aktor RT mit FHEM pairen - anschliessend alles via peerChan über FHEM erledigen.

Anmerkung: Diese Variante habe ich bisher nicht erfolgreich getestet "sollte/müsste aber funktionieren" (Ich kämpfe aktuell mit Martin mit dem SC -> RHS folgt).
1) RHS mit FHEM pairen (FHEM pairing klar?)
2) RT mit FHEM pairen (FHEM pairing klar?)
3) set <fenster-sensor-SC/RHS> peerChan 0 <rt_WindowRec> single
4) Anlerntaste SC/RHS drücken "CMDs" prüfen...
5) set <RT>/<SC/RHS> getConfig ausführen -> bei SC/RHS Anlerntaste drücken
6) Channel: DG_HR_Gaestezimmer_WindowRec und Sensor <fenster-sensor> auf peer prüfen.

Punkt 1 bis 3 sind klar und kann ich so beim RHS bestätigen.

Nach Punkt 3 stehen bei mir RT und RHS auf CMD_pending. Bei RT Boost-Taste/Anlerntaste ergibt ein CMD-done, beim RHS die Anlerntaste drücken wirft ein CMD_error aus.
Jetzt steht beim RT die peerID drinnen und beim RHS nicht. Soll das bzw. wie soll das sein?
Auch ein getConfig + anschließend Anlerntatse bringt keine Änderung.
Ich bleibe aber drann und werde morgen wieder ausgiebig Testen.

Gibt es evtl. noch andere Parameter die gesetz werden müssen oder gesetz sein sollten?
Wie zB. burstRx on oder peerNeedsBurst=on??

Gruss Philipp

[snoop]

Hallo Philipp,

mMn hast du bisher nichts falsch gemacht -> da muss jetzt Martin dran - vielleicht gibt es auch einen Zusammenhang mit dem SC (SC und StatusRequest Thema das vielleicht? ein peering blockiert).
@Martin: Die ganzen "vielleicht's" - hast du eine Idee - Logs könnte auch ich liefern ein RHS und einen RT habe ich auch noch hier liegen.
@Philipp: Falls du sofort loslegen möchtest dann nimm V1 - hat bei mir auf Anhieb funktioniert.

Viele Grüße
Arthur

[ext23]

Nabend,

wurde hier schon wieder was geändert, ich bekomme mal wieder kein Temp Liste gesetzt.

Der bleibt bei:
tempListWed set_ 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0 2013-11-12 21:26:38
tempList_State set 2013-11-12 21:26:38
stehen. Ein get config läd dann wieder die alten Listen raus.

2013.11.12 21:26:38 2: CUL_HM set bz_Heizung_ClimRT_tr tempListWed 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0
2013.11.12 21:26:42 3: HMLAN_Send:  HMLAN1 I:K
2013.11.12 21:26:42 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:0CD443C1 IDcnt:000B
2013.11.12 21:26:44 3: HMLAN_Parse: HMLAN1 R:E1D2544   stat:0000 t:0CD44AD2 d:FF r:FFC0     m:1B 8670 1D2544 000000 00D33D
2013.11.12 21:27:04 3: HMLAN_Parse: HMLAN1 R:E1D2544   stat:0000 t:0CD498F4 d:FF r:FFC0     m:1B A258 1D2544 1D219B 000C
2013.11.12 21:27:04 3: HMLAN_Parse: HMLAN1 R:E1D219B   stat:0000 t:0CD49978 d:FF r:FFBB     m:1B 8202 1D219B 1D2544 010108003B
2013.11.12 21:27:07 3: HMLAN_Send:  HMLAN1 I:K
2013.11.12 21:27:08 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:0CD4A7DA IDcnt:000B
2013.11.12 21:27:15 3: HMLAN_Parse: HMLAN1 R:E1D259A   stat:0000 t:0CD4C6B3 d:FF r:FFBA     m:16 8670 1D259A 000000 00C83C
2013.11.12 21:27:32 3: HMLAN_Send:  HMLAN1 I:K
2013.11.12 21:27:33 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:0CD50987 IDcnt:000B

Viele Grüße
Daniel

[Mr. P]

Punkt 1 bis 3 sind klar und kann ich so beim RHS bestätigen.

Nach Punkt 3 stehen bei mir RT und RHS auf CMD_pending. Bei RT Boost-Taste/Anlerntaste ergibt ein CMD-done, beim RHS die Anlerntaste drücken wirft ein CMD_error aus.
Jetzt steht beim RT die peerID drinnen und beim RHS nicht. Soll das bzw. wie soll das sein?
Auch ein getConfig + anschließend Anlerntatse bringt keine Änderung.
Ich bleibe aber drann und werde morgen wieder ausgiebig Testen.

Gibt es evtl. noch andere Parameter die gesetz werden müssen oder gesetz sein sollten?
Wie zB. burstRx on oder peerNeedsBurst=on??

Gruss Philipp

Hej Philipp,

hast du auch wirklich die aktuellste FHEM-Version?
Ich frage deshalb, weil Martin erst gestern etwas im Code geändert hat, weil es noch Probleme mit dem automatischen Setzen vom Burst gab.
Damit der Fensterkontakt funktioniert, muss am RT 'burstRx' und am SC/RHS 'peerNeedsBurst' auf 'on' sein. Soweit ich Martin aber verstanden habe, sollte das jetzt von selbst während des peer-Vorganges passieren.
Versuche zur Sicherheit einmal, das Peering vom RT nochmal zu löschen, dann bereits im Vorfeld 'burstRx' am RT aktivieren und dann nochmal die Liste zum Peeren durcharbeiten. Wenn das Peeren nicht gleich beim ersten Mal klappt (du wieder deine Fehlermeldung nach dem 'getConfig' vom RHS bekommst), versuche es gleich nochmal. Wenn es dann geklappt hat, muss in den Registern vom RHS dann der 'peerNeedsBurst'-Eintrag für deinen RT auf 'on' sein. Wenn nicht, dann diesen bitte auch noch händisch umsetzen (set <RHS> regSet peerNeedsBurst on <RT>) und mittels Anlerntaste übertragen. Sobald das geschafft ist, müsste eigentlich alles so klappen, wie du es möchtest.

Probier es nochmal aus, aber aktiviere während des ganzen Vorganges doch bitte einmal das Logging (set global verbose 1;;set global msec 1;;set <HM> verbose 1) in FHEM und lass uns das Ergebnis zukommen, sollte es immer noch nicht geklappt haben.

[JoeALLb]

ist nicht dies die korrekte Schreibweise?

Code Auswählen Erweitern

set global msec 1