Hallo,
ich habe seit zwei Wochen eine Heizungssteuerung per Google für meine HM-CC-RT-DN aktiv.
Das funktioniert auch einwandfrei, die Heizung wird wie gewünscht gesteuert, jedoch habe ich jede Stunde Fehler im Log, die ich mir nicht erklären kann.
Vielleicht könnt Ihr mir ja helfen:
Zum Procedere - ich verwende für jeden Raum einen eigenen Kalender. In diesem Sind die Schaltzeiten als Termin mit den gewünschten Temperaturen im Betreff eingetragen.
Als Besipiel Kalender_Kueche Termin von 19:00 bis 20:30 Uhr - Betreff: "21 17", d.h. um 19 Uhr soll die Küche auf 21 Uhr geheizt werden und um 20:30 Uhr soll auf 17 Grad abgesenkt werden.
Ich verwende dazu zwei Notifys:
define HZ.Kueche_an notify Kalender_Kueche:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } } und
define HZ.Kueche_aus notify Kalender_Kueche:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }.
Im Log findet man dann folgendes:
2013.11.04 20:24:07 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:24:07 3: HZ.Bad_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:24:07 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:24:07 3: HZ.Bad_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: get Kalender_Kueche summary xxx: 21 17
2013.11.04 20:30:00 2: CUL_HM set hz.kueche desired-temp 17
2013.11.04 20:30:00 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: HZ.Bad_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: HZ.Bad_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
Wie man sieht wird die Temperatur wie gewünscht aus dem Kalender ausgelesen und an den Thermostaten übermittelt (das funktioniert auch!)
Trotzdem kommen ein Haufen Fehlermeldungen - sowohl nach einem Schaltvorgang als auch exakt 1x pro Stunde (ich nehme an, immer wenn der Google-Kalender aktualisiert wird).
Wo liegt das Problem? Es funktioniert doch alles?
Falls jemand einen Rat weiß - bitte posten
Viele Grüße
Markus
Entweder liefert get Kalender_Kueche summary $uid nicht zwei Woerter zurueck, oder ist die Temperaturspezifikation nur mit eine Nachkommastelle korrekt, also 21.0 statt 21.
man kann "21" oder "21.0" verwenden- "21." ist nicht zulässig
sollte immer ein "." vorhanden sein kann man einfach eine "0" anhängen. Sprich es geht auch "21.00"
Ich komme mir grade vor wie im Kindergarten.
- Erst wird das Thema im Thread zum RT breitgetreten, obwohl es mit ziemlicher Sicherheit ein Calendar-Problem ist und kein Homematic Problem.
- Dann wird nach endloser Diskussion endlich das Thema im (für Calendar) richtigen Unterforum "Unterstützende Dienste" eröffnet.
- Und dann wird der Mist prompt wieder nach Homematic verschoben.
Der Fehler (von irgendwoher kommt alle Stunde ein "falscher" Befehl an den Thermostaten) kommt garantiert nicht aus Homematic, denn der RT weiss überhaupt nix vom Kalender.
Ich behaupte nach wie vor, dass der Fehler von der Kalenderverarbeitung kommt. Und damit sind wir hier wieder im falschen Bereich.
Ich reich Dir mal ein Sandkasten Schäufele, vielleicht gehts dir dann besser :)
Hallo Hary
Zitat von: fhem-hm-knecht am 05 November 2013, 13:15:42...
... es lohnt nicht ;)
Nur gut, dass unser Beta kein Mod ist, sonst müssten wir hier alle immer erst gerade stehen :o
Gruß
Thomas
Jetzt noch einmal eine Rückmeldung von mir. Ich habe mit dem Verschieben ja nichts zu tun, würde das Thema am liebsten trotzdem wieder ins HM-CC-RT-DN-Unterforum verschieben, auch wenn es Betateilchen nicht gefällt.
Ich habe nämlich den ganzen Abend gegrübelt, warum ich für Wohnzimmer, Bad und Küche dasselbe (an den jeweiligen Raum angepaßte) Notify verwende, der Fehler aber ausschließlich in Bad und Küche auftritt.
Der einzige Unterschied, der mir auffiel ist der, daß ich im Wohnzimmer 4 Thermostate habe, die ich über eine gemeinsame structure wz.heizung ansteuere; in Küche und Bad wird jeweils der Thermostat direkt angesteuert.
Um diese Theorie zu überprüfen habe ich auch für Küche und Bad jeweils eine structure bestehend aus jeweils nur einem Thermostaten definiert und diese statt den HM-CC-RT-DN direkt angesprochen:
define hz.bads structure room hz.bad
das Notify wurde lediglich auf hz.bads geändert:
defi9ne HZ.Bad_an notify Kalender_Bad:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Bad summary $uid")); { fhem("set hz.bads desired-temp $dtemp"); } }
Und was soll ich sagen? Die Fehlermeldungen sind weg!!! (Küche wurde um 18.10 geändert, deshalb davor noch die Meldungen)
2013.11.05 17:05:50 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 17:05:50 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 17:05:50 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 17:30:00 3: get Kalender_Bad summary xxx: 24 17
2013.11.05 17:30:00 2: CUL_HM set hz.bad desired-temp 24
2013.11.05 18:05:50 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 18:05:50 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 18:15:00 3: get Kalender_Kueche summary yyy: 24 20
2013.11.05 18:15:00 2: CUL_HM set hz.kueche desired-temp 24
Damit ist für mich bewiesen, daß die Probleme NICHT von der Kalenderverwaltung herrühren und nicht an einem fehlerhaften Notify liegen, sondern doch direkt etwas mit der Ansprache des HM-CC-RT-DN zu tun haben, auch wenn es Dir nicht paßt und Du bestimmt gleich wieder rummaulst, Betateilchen.
Viele Grüße
Markus
ZitatDamit ist für mich bewiesen, daß die Probleme NICHT von der Kalenderverwaltung herrühren und nicht an einem fehlerhaften Notify liegen, sondern doch direkt etwas mit der Ansprache des HM-CC-RT-DN zu tun haben,
Wenn ich jetzt rummaule, dann nur deshalb, weil Du erst JETZT mit der Tatsache rausrückst, dass Du mit einer structure arbeitest. Also ist es
WEDER ein Problem des
RT,
NOCH der
Kalenderverarbeitung,
sondern eine ganz andere Baustelle:
structure und gehört somit auch nicht hier in den Homematic-Bereich.
Auch wenn diese Möglichkeit Deinen Denkhorizont übersteigen mag.
@ betateilchen
Ich hätte dir auch noch ein Eimerchen passend zum Schäufelchen zu vergeben :)
Zitat von: betateilchen am 05 November 2013, 19:42:52
Wenn ich jetzt rummaule, dann nur deshalb, weil Du erst JETZT mit der Tatsache rausrückst, dass Du mit einer structure arbeitest. Also ist es WEDER ein Problem des RT, NOCH der Kalenderverarbeitung, sondern eine ganz andere Baustelle: structure und gehört somit auch nicht hier in den Homematic-Bereich.
Auch wenn diese Möglichkeit Deinen Denkhorizont übersteigen mag.
ZitatAuch wenn diese Möglichkeit Deinen Denkhorizont übersteigen mag.
Muss das wirlich sein?
Also Betateilchen, vielleicht sollte man sich auch in einem Forum mal einen vernünftigen Umgangston angewöhnen.
Wenn Du, außer zu kritisieren, Dir vielleicht auch ein paar Beiträge VERNÜNFTIG durchlesen würdest, wüßtest Du, daß ich im Wohnzimmer mit structure arbeite, steht nur ein paar Beiträge über dem den Du als nervig bezeichnet hast!.
Und es ist auch keine Baustelle der structure - schließlich funktioniert dort alles! Was nicht ohne Fehlermeldung funktioniert ist das direkte Anprechen des RT (auch wenn die praktische Umsetzung hier wiederum funktioniert)
Es ist doch offensichtlich so, daß die Kommandos, die über das Notify direkt an den RT geschickt werden mit einer Fehlermeldung beantwort (und trotzdem ausgeführt!) werden, dasselbe Kommando über den Umweg einer structure an denselben RT geschickt nicht zu einer Fehlermeldung führt.
Das ist die Frage, die ich mir nicht beantworten kann - und bisher ja auch kein Erfahrener hier im Forum.
Viele Grüße
Markus Jülich
- ich spreche alle meine RT ausschließlich über notify an - und das ohne jegliche Fehlermeldung.
- ich spreche viele meiner RT über Calendar an (also auch wieder über notify) - und das ohne jegliche Fehlermeldung.
2013.11.04 20:24:07 3: set hz.bad desired-temp :
Hier wird ein set desired-temp OHNE Temperaturangabe abgesetzt. Und Du musst herausfinden, warum HZ.Bad_an (ich vermute, das ist ein notify) das tut. Irgendein Event muss dieses notify falsch triggern.
So etwas hätte ich mir auch gedacht, weiß aber beim besten Willen nicht, wo das herkommt. Mein Notify ist doch aber nur eine Modifikation von dem von Dir veröffentlichten. Ich habe jetzt nichts weiter gemacht, als im Notify HZ.Bad_an den RT hz.bad durch die structure hz.bads zu ersetzen - und es kommen keine Fehlermeldungen mehr. Das ergibt doch keinen Sinn. Es sei denn, structure würde falsche Kommandos einfach ohne Fehlermeldung ignorieren.
Viele Grüße
Markus
Du musst einfach rausfinden, WARUM das Notify getriggert wird. Notfalls mal ein bisschen Logging in die Verarbeitung einbauen, um der Ursache auf die Spur zu kommen.
Hallo Betateilchen, im Prinzip könnten wir den Thread ja zumachen - schließlich funktioniert ja alles und das Log ist fehlerfrei. Aber es wurmt mich trotzdem, warum es nur mit dem structure Trick funktioniert.
Wenn es nicht zu sehr nervt, möchte ich deshalb nochmal Deinen Beitrag von September zitieren:
Zitat von: betateilchen am 30 September 2013, 11:29:28
Ein Eintrag im Google-Kalender hat im Titel einfach den Reglername und die Solltemperatur für Beginn und Ende stehen, also z.B. "wz_Thermostat 22 16"
Im Beispiel wird die Temperatur zuerst auf 22 Grad eingestellt und am Ende des Zeitraums auf 16 Grad zurückgeregelt.
Dazu gibt es zwei notify, die entsprechend getriggert werden und die sich nur im split unterscheiden:
Kalender_Heizung:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
Kalender_Heizung:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,undef,$dtemp) = split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
Ich habe das lediglich dahingehend abgeändert, dass ich den Reglernamen weggelassen habe, da ich für jeden Raum einen eigenen Kalender habe.
Dazu die Notifys
define HZ.Kueche_an notify Kalender_Kueche:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }
und
define HZ.Kueche_aus notify Kalender_Kueche:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }
Ich finde da keinen Fehler, vielleicht habe ich was übersehen?
Die Idee eines erweiterten Logs ist sicher gut, an welcher Stelle sollte ich da ansetzen und wie programmiere ich das?
Wie gesagt, es muss niemand antworten, es funktioniert alles. Aber vielleicht besteht ja doch Interesse dem Rätsel gemeinsam auf die Spur zu kommen und so eventuell zukünftige Fehler zu vermeiden.
Eine Anmerkung noch: wenn irgendetwas ungewollt das Notify Tragegurt - müßte es da nicht auch bei einem structure-Device einen Logeintrag geben? Die gewollt ausgelösten Notifys stehen jedenfalls drin.
Viele Grüße
Markus
ich hab ja grundsätzlich schon eine (sehr technische) Idee, warum das so passiert...
Versuch doch einfach mal, den Kalendereintrag so zu verwenden, wie von mir ursprünglich vorgeschlagen (mit Aktorname) und arbeite mit den beiden Original-notify.
Hallo Markus,
um einmal zum Problem zurück zu kommen: das Kommando desired-temp funktioniert. Es wird sich darüber beschwert, dass kein Parameter übergeben wurde - und es ist einer erforderlich. Daher solltest du feststellen, was eigentlich zu diesem Zeitpunkt in $dtemp steht. Schreibe es irgendwo hin, am besten ins log
define HZ.Bad_an notify Kalender_Bad:modeStarted.* { \
my $reading="%EVTPART0";\
my $uid= "%EVTPART1"; \
my ($dtemp,undef)= split(/ /,fhem("get Kalender_Bad summary $uid")); \
{ fhem("set hz.bads desired-temp $dtemp");}\
Log 1,"try to set desired-temp to $dTemp"; }
zum Testen ist es noch besser, gleich alles wegzuschreiben:
define HZ.Bad_an notify Kalender_Bad:modeStarted.* { \
my $reading="%EVTPART0";\
my $uid= "%EVTPART1"; \
my $dAll = fhem("get Kalender_Bad summary $uid"));\
my ($dtemp,undef)=$dAll; \
{ fhem("set hz.bads desired-temp $dtemp");}\
Log 1,"try to set desired-temp to $dTemp from $dAll ##"; }
du nutzt die ersten beiden durch blank getrennten Parameter - schaue dir genau an, was die Funktion liefert. Offensichtlich ist dTemp hier "leer".
Nur wenn der Log korrekt kommt ist es ein Beweis für etwa - bin gespannt
Gruss Martin
Zitat von: martinp876 am 05 November 2013, 22:57:40um einmal zum Problem zurück zu kommen: das Kommando desired-temp funktioniert. Es wird sich darüber beschwert, dass kein Parameter übergeben wurde - und es ist einer erforderlich.
das ist doch ganze Zeit meine Rede und von diesem Punkt habe ich mich - allen Unkenrufen zum Trotz - auch nie wegbewegt - also muss ich zu dem Problem nicht zurückkommen, weil ich die ganze Zeit da bin?!
dann gib ihm halt einen Tip, wie er es herausfinden kann - anstatt zu stänkern
Kleine Rückmeldung:
Ich konnte das Log leider nicht so einfügen wie Du vorgeschlagen hast, Martin. Da kam ein Syntaxfehler. Ich habe es halt hinten angehängt, ich hoffe, es hilft trotzdem:
2013.11.06 22:41:00 3: HZ.Bad_an return value: Global symbol "$dTemp" requires explicit package name at (eval 467) line 1.
Unmatched right curly bracket at (eval 467) line 1, at end of line
syntax error at (eval 467) line 1, near "} }"
2013.11.06 22:42:44 2: CUL_HM set CUL_HM_HM_CC_RT_DN_221812_WindowRec getConfig
2013.11.06 22:43:00 3: HZ.Bad_an return value: Global symbol "$dTemp" requires explicit package name at (eval 471) line 1.
2013.11.06 22:43:00 3: HZ.Bad_an return value: Global symbol "$dTemp" requires explicit package name at (eval 473) line 1.
2013.11.06 22:43:50 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.06 22:43:50 1: try to set desired-temp to
2013.11.06 22:45:00 3: get Kalender_Bad summary xxx: 18 17
2013.11.06 22:45:00 2: CUL_HM set hz.bad desired-temp 18
2013.11.06 22:45:00 1: try to set desired-temp to 18
2013.11.06 22:45:17 2: CUL_HM set hz.kueche getConfig
2013.11.06 22:46:00 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.06 22:46:00 1: try to set desired-temp to
2013.11.06 22:46:00 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.06 22:46:00 1: try to set desired-temp to
2013.11.06 22:47:36 2: CUL_HM set CUL_HM_HM_CC_RT_DN_221812_remote getConfig
2013.11.06 22:48:00 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.06 22:48:00 1: try to set desired-temp to
2013.11.06 22:48:00 3: get Kalender_Bad summary xxx: 18 17
2013.11.06 22:48:00 2: CUL_HM set hz.bad desired-temp 17
2013.11.06 22:48:00 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.06 22:48:00 1: try to set desired-temp to
2013.11.06 22:48:00 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.06 22:48:00 1: try to set desired-temp to
Der entsprechende Kalendereintrag lautete: 22:45 bis 22:48 "18 17"
Es kommt tatsächlich ein Fehler, den ich aber nicht einordnen kann. Ich verwende doch gar nicht "$dTemp" , sondern "$dtemp" .
Wie man sieht funktioniert das Setzen der Temperatur aber trotzdem.
@Betateilchen: Dein Notify war bei mir auch noch aktiv, ich habe mal einen Termin angelegt, jetzt passiert aber leider gar nicht :-( Es hat aber schon mal bei mir funktioniert.
Hatte einen Termin
"hz.kueche 21 17"
Mi, 6. November, 22:59 – 23:02
Notify Kalender_Heizung:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
Viele Grüße
Markus
Hallo Martin, ich habe jetzt doch noch Deinen Code eingeben können - aber das Log ist dabei leer:
Termin:
"18 17"
Mi, 6. November, 23:25 – 23:28
Notify: define HZ.Bad_an notify Kalender_Bad:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Bad summary $uid")); { fhem("set hz.bad desired-temp $dtemp"); } Log 1,"try to set desired-temp to $dtemp from $dAll ##"; }
führt zu folgendem Log:
2013.11.06 23:28:00 3: get Kalender_Bad summary xxx: 18 17
2013.11.06 23:28:00 2: CUL_HM set hz.bad desired-temp 17
Merkwürdig.
Viele Grüße
Markus
Mein Fehler, hatte alles in die DEF kopiert. Bei Deinem Beispiel kommt der Fehler
2013.11.06 23:39:09 3: HZ.Bad_an return value: Unknown command {, try help.
Liebe Grüße
Markus
Jetzt noch mal gelogt:
2013.11.06 23:46:01 1: Setze Temperatur:
2013.11.06 23:47:00 3: get Kalender_Bad summary xxx: 18 17
2013.11.06 23:47:00 2: CUL_HM set hz.bad desired-temp 18
2013.11.06 23:47:00 1: Setze Temperatur: 18
2013.11.06 23:47:00 1: Setze Temperatur:
23:46 Uhr habe ich den Kalender geupdatet - warum wird da das Notify getriggert?
23:47 Uhr Temperatur auf 18 gesetzt
Danach wird augenscheinlich das Notify ein zweitesmal getriggert, ohne Argument - aber warum nur?
Das notify Kalender_Bad:modeStarted.* dürfte doch eigentlich nur beim Beginn eines Termins getriggert werden und als Argument den Betreff des Termins übergeben.
Was ist hier bloß faul?
Hallo Juelich,
damit ist klar, was in CUL_HM passiert - das darfst du so eben nicht senden.
dein Notify triggert immer, wenn ein "Kalender_Bad:modeStarted.*" kommt. schalte einmal "inform on" - dann solltest du alle events sehen, die kommen.
aus HM sicht: setze die temperatur nicht, wenn du sie nicht hast :-)
Gruss Martin
So, Problem gelöst. Vielen Dank an alle, die geholfen haben.
Das Kalendermodulk funktioniert scheinbar andes, als ich es erwartet habe. Ich bin davon ausgegangen, das das Notify genau dann triggert, wenn ein Kalenderereignis eintritt (Beginn und Ende).
Ich habe noch aus dem Jahr 2012 Eine Diskussion in einer Google-Group die Bestätigung gefunden, das dem nicht so aus. Das Notify Kalender_Bad:modeStarted.* triggert bei JEDER Änderung des Kalenders, das soll angeblich auch so gewollt sein (verstehe ich zwar nicht wozu das gut sein sollte, aber muß man so akzeptieren).
Der zweite Fallstrick war das structure-Modul. Scheinbar schluckt dieses den set desired-temp-Befehl ohne Fehlermeldung, auch wenn die Temperatur gar nicht angegeben wird (im Gegensatz zum RT).
Deshalb hatte ich die Fehlermeldungen auch nur in Bad und Küche.
Ich habe jetzt in meinem Notify vor das Setzen der Temperatur eine Abfrage gesetzt, das diese auch wirklich existiert, und jetzt ist das Log fehelerfrei.
Kalender_Bad:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Bad summary $uid")); {if ("$dtemp" ne "") { fhem("set hz.bad desired-temp $dtemp")};}}
Also noch einmal vielen Dank - und jetzt kann der Threat auch in die Abteilung "Unterstützende Dienste" geschoben werden, da er da ja scheinbar wirklich hingehört ;-)
Viele Grüße
Markus