Lars1

Jeg oplever fra tid til anden at min IHC Captain installation ikke kan hente programmet på min IHC controller før end jeg har genstartet controlleren. Jeg tænker derfor på om det kan være kommunikationen mellem IHC Captain og IHC controlleren, som svigter hos dig.

Sporadisk genstart er desværre et kendt problem med LK IHC. Nogle firmware versioner er værre end andre, men problemet eksister på samtlige controller versioner hvad enten det er TermIHC, Visual 1, 2 eller 3. En sporadisk genstart slå dog ikke alarmen fra hvis programmet er lavet rigtigt.

1) Korrekt. Såfremt at IHC app og home assist er på det samme logiske netværk, bør du kunne bruge netværks informationerne fra din IHC app, til at tilgå IHC controlleren fra home assist. 2) Hvis Java er blevet opdateret på din PC siden du brugte den sidst kan det meget vel være årsag til at det ikke længere virker. Hvergang Java bliver opdateret overskriver den alle konfigurations ændringer du måtte have lavet.

Hvis du fjerner linket før du fysisk fjerner sabotage kredsen, så bør indgangen i FB'en forblive ON, også efter genstart og uden at du gør noget. Hvis FB'en er lavet korrekt, vil default på FB indgangen allerede være ON, men det er værd at checke via ServiceView om default kan ændres eller ej og hvis den kan, sæt den til ON bare for at være sikker. Hvis FB indgangen af en eller anden grund går OFF, så bør alarmen gå i igang, men hvis default er ON, og indgangen er ON når du sletter linket, bør dette ikke kunne ske.

Hvis jeg forstår dig ret, så vil du ændre i FB'en. Det bør ikke være nødvendigt. Det bør være nok at slette linket mellem sabotage indgangen i FB'en og den fysiske sabotage indgang. Alt efter hvordan FB'en er bygget op, kan det være nødvendigt manuelt at sætte FB indgang ON første gang controlleren genstartes efter at linket er slettet.

Det grundlæggende problem er sandsynligvis de gamle udløbne certifikater som LK bruger i deres software. De giver så forskellige fejl alt efter hvordan du forsøger at tilgå controlleren. Hvis du kan forbinde med IHC app, så er der netværks forbindelse til din IHC controller, og du skal lede efter den manglende forbindelse mellem din home assist installation og IHC controlleren. Jeg har ikke selv home assist, men andre har fået det til at virke ved at bruge HTTP i steddet for HTTPS i home assist konfiguration. Dermed omgår man de udløbne certifikater. Alt efter hvordan dit lokal net er strikket samme, kan det også være et netværks problem mellem din IHC controller og home assist installation. Prøv evt. at bruge WAN addresse både med og uden WAN port nr'et. Husk også her at bruge HTTP i steddet for HTTPS. Din problem med IHC administrator kan dels skyldes at du har en controller uden viewer. HW 6.1 fandtes i 2 udgaver. En med viewer og en uden. Man kan kende forskel da der på den med viewer står IHC Visual controller / Viewer, mens der på den uden kun står IHC Visual controller. Hvis den er med viewer, så er det sandsynligvis et java krypterings problem. Hvordan du løser det kan du læse mere om i tråden "Login mislykkes (Java problemer)" i FAQ fora'et. Admin view og service view er ikke noget man installer på sin computer. Det er Java programmer som downloades hvergang og afvikles direkte uden at blive installeret. Det er imidlertid de færreste browser som idag understøtter afviklingen af Java direkte. Man er derfor nød til at gemme Java programmet og starte det manuelt bagefter. Her kommer java starter til hjælp da man så ikke skal bruge en browser for at download og starte Java programmerne. Men der står også mere om Java starter i den tråd jeg henviste til tidligere.

Jeg må indrømmer at jeg har svært ved at gennemskue hvordan den funktions blok skal virke. Umiddelbart vil jeg sige at det kun er muligt at reguler mellem 100% og 35%. Det er ikke muligt at slukke med de forbindelser der er lavet. Men det er meget tænkeligt at jeg ikke forstår LK's tankegang eller at du mangler at forbinde lysdæmper tændt udgangen. Prøv at trykke på F1 når du har funktionsblokken markeret. Så skulle du få LK's villedning til hvordan FB'en skal forbindes. Det plejre at være med fine tegninger af hvad der skal forbindes til hvad.

Det er et kendt problem med HW version 1 wireless stikkontakter og lav belastning. Dog plejer mine dog rent faktisk at tænde igen. HW ver. 1 wireless stikkontakter har et minimums belastnings krav på 20W såvidt jeg husker. Det er relativt simpelt at teste om det er den lave belastning som er problemet. Prøv at sætte en støvsuger, el radiator, glødepære lampe eller tilsvarende med høj belastning til i steddet for din nuværende belastning. Forsvinder problemet skyldes det den lave belastning og løsninger er at skifte til HW ver. 2 wireless stikkontakter som ikke har noget miminums belastnings krav, eller sætte noget mere belastning på stikkontakterne.

En PIR registrer ændringer i varme. De LK IHC udendørs PIR jeg har siddende registrer normalt min bil når jeg nærmere mig min parkerings plads, men ikke altid. Specielt i sommerhalvåret sker det ofte at de ikke registre min bil eller mig når jeg stiger ud. Man kan dog ændre følsomheden på dem, men skruer jeg dem meget længere ned, registrer de også naboen kat om vinteren uden at de samtidig bliver bedre til at registre min bil om sommeren. Alt kan bruges som input til LK IHC, men sommetider skal man have en galvanisk adskildelse eller overdragelses relæ imellem. Mange garage port systemer har et potentialt frit relæ som kan bruges til at tænde lys med m.m. når porten åbner. Prøv at checke om din garage port ikke har sådan en udgang. Alternativt kan du monter et overdragelses relæ parallet med garage port motoren.

Det er højst sandsynligt et Java problem, eller retter disablet Java understøttelse af de forældede krypterings protokoller som LK fortsat bruger. Du er ikke den første som får login fejl og løser problemet ved at følge en af mulighederne i tråden i FAQ'en. Hvis du kan logge på med Visual, men ikke med Serviceview eller adminview, er det 99,99% sikkert et Java krypterings problem. Hvis du bruger IHC/Java starter, så brug Mikkels. LK's har et problem med de seneste Java opdateringer. Hvis du vil prøve med reset firmwaren, så kan du risiker at skulle bruge en ældre firmware loader, da de nyer har versions kontrol som bloker for upload af reset firmwaren.

Reset firmwaren løser ikke problemet hvis det er et Java problem, hvilket det højst sandsynligt er.

Røgsensor lever ikke evigt, så man bør ikke genbruge røgsensor som er mere end 5 år gamle. Enhver røgsensor som kan afbryde en forbindelse ved alarm kan bruges i LK IHC alarm. Det behøver ikke være LK IHC røgsensor.

Jeg kan ikke lige gennemskue Mikkel's rapport, så jeg tror det er bedre han svare på om der er flere lampeudtag på samme udgang. Det er noget nemmer at gennemskue via LK's standard rapporter, men de er noget besværlige at generer medmindre man har en god gammel windos xp PC. Men det er korrekt at du jvf. Mikkel's rapport kun har et wireless lampe udtag.

Har du prøvet standard løsningerne med at genstarte controlleren o.s.v.? Er lampe udtagne wireless eller forbundet til et output modul? Hvis det er wireless udtag fra 2008 og du har skiftet til LED pære kan du opleve det som du beskriver. LED er kun understøttet med HW ver 2. wireless lampeudtag og de kom først på marked noget senere end 2008.

Det er højst sandsynligt et Java problem. Check tråden i FAQ fora'et. Den beskriver indtil flere løsninger.

Jeg kender ikke hue, men jeg kan ikke rigtigt forstille mig at den eneste måde at tænde/slukke lyset, hvis man går hue vejen, er via en app. Så da et 230V output modul jo har samme funktionel funktion som en alm. on/off kontakt, man kan vel erstatte dimmerne med et 230V output modul isteddet for at gøre installationen mere kompleks med HA/IHCCaptain. Bortset fra det ser det ud til at den nuværende IHC controller er en Visual 2 HW 6.1 uden viewer, hvilket vil sige at IHC app m.m. ikke vil virke på den. Opgrader til en controller med viewer (Visual 2 HW 6.1 med viewer, Visual 2 HW 6.2 eller Visual 3 HW 7) og lyset kan styres med f.eks. IHC app uden anden ændring end udskiftning af selve controlleren. Alt andet kan genbruges. Sidst men ikke mindst ser det ud til at der er et wireless tryk et eller andet sted som trænger til et nyt batteri

Magnet kontakter hjælper ikke meget når en tyv skære hul i ruden eller helt fjerne den. Ud over det har jeg aldrig været fan af at have magnet kontakter og sabotage keds på samme kreds. Det gør fejlsøgning besværlig forhindre at man kan bruge sabotage kredsen til at holde øje med kabel fejl.

Formålet med en sabotage kreds er at opdage kabel fejl og sikre mod at nogen kan åbne alarm sensorer og kortslutte dem så de ikke generer alarmer. Den er selvfølgelig mest relevant på alarm enheder som sidder uden for, men det er de færreste huse som er fuldt dækket med PIR og dertil kommer at en PIR reager på varme. Det betyder at hvis en tyv har alm. tøj på og dækker sine hænder og ansigt, så vil en PIR ikke registrer at han går gennem rummet. En sådan tyv vil sandsynligvis tildække en PIR, men nogle er ikke så kloge, så de forsøger at ødelægge PIR'en, hvilket vil udløse en alarm hvis sabotagekredsen er i brug. Jeg kender ikke dit program, men det er sandsynligvis den afbrudte sabotage kreds som har udløst alarmen, men det kan også være noget andet. Jeg havde f.eks. et problem med at min brand alarm fra tid til anden gik igang uden at der var brand eller røg. Det var altid den samme brandmelder som var årsagen og selvom jeg udskiftede den, relæ soklen, kablet og I/O modulet, forsvandt problemet ikke. En dag opdager jeg så tilfældigvis at afløbet fra overtryks ventilen på varmtvands beholderen på etagen oven over har skubbet sig så det dryppede ned på gulvet når den varmede op. Den brandmelder som gav problemer sad lige nedenunder. Efter at afløbet var sat tilbage på plads og sikret, var problemet væk.

Det kan godt hænge samme. Sabotage kredsen er normalt en sløjfet forbindelse som går fra den ene PIR til den næste o.s.v. Alle samlinger sker dog normalt i tavlen. PIR alarm er derimod en direkte forbindelse. Det specielle ved sabotage kredsen og PIR alarm er at de generer events når forbindelsen bliver afbrudt, mens et normalt tryk generer events når forbindelsen bliver sluttet. Hvis du har fejl på kablet til din PIR kan du derfor opleve at sabotage kredsen og PIR'en går i alarm samtidig. Din elektriker kan dog også have monteret det anderledes da installationen fysisk kan laves på MANGE måder, og det er mest religion om man mener den ene er bedre end den anden. Der er ikke nogle faste regler på området. Bare en LANG række best practices.

Jeg har flyttet tråden fra FAQ til teknik, således at indlæg ikke længere skal godkendes.

Jeg har også 2 IHC controller. Den ene har hvert år et problem med tilfældig forsinkelse efter der er skiftet mellem sommer/vintertid. Jeg løser problemet ved at genstarte controlleren via adminview. Herefter er problemet væk til vi igen skifter mellem sommer/vintertid. Hvorfor problemet kun rammer den ene controller ved jeg ikke, men det har været ret konstant de sidste 3 år, og det er altid den samme controller som bliver ramt.

Nej. Der kommunikers kun med de enheder som indgår i det aktuelle scenarie/program sekvens. Du kan godt have kommunikations problemer med wireless enheder selvom der er god RSSI værdi. Årsagen til problemerne med min wireless dimmer var at jeg havde for lav belastning på den (ver. 1 wireless dimmer). Med en alm. 25W gløde pære virkede den perfekt.

Hvis du bare skal bruge det som alm. netværk, kan ethvert Cat5e kabel eller bedre bruges. Skal det også kunne klare TV signaler skal du gå efter Cat6 kabler med individuel par skærmning og 1000Mhz certificering. Normale 1Gbit netværks kabler er kun certificeret til 200Mhz. Desværre kan man ikke linke direkte til udgåede produkter på lk.dk, men du kan se spec'sne på det originale IHC Net netværks kabel ved at søge efter "IHC net kabel" i produkt oversigten på lk.dk. Husk at vælge medtag udgåede produkter.

IHC wireless kommunikation er serielt forstået på den måde at kommunikationen med en wireless enhed skal være afsluttet med OK retur inden kommunikationen med næste enhed starter. Det betyder at hvis du har en enhed hvor kommunikationen giver problemer kan det bloker for kommunikationen med de andre enheder. Såvidt jeg husker forsøges kommunikationen i op til 1 min. før der give op og fortsættes til næste enhed. Jeg har selv været ramt af det problem og fandt synderen ved at lave en test funktions blok, hvor jeg tændte/sat alle lamper på 100% samtidig og efterfølgende slukkede dem alle på sammetid. Eftersom der kommunikers med lamperne i den rækkefølge de er linket til funktions blokken var det rimeligt nemt at finde synderen, også selvom den umiddelbart så ud til at reager som den skulle. Den tændte eller slukkede ikke langsommer end de andre enheder, men den havde sandsynligvis problemer med at sende OK retur til controlleren og dermed blokerede den for kommunikationen med den næste enhed. Hvis du ikke finder synderen i første forsøg, så prøv at ændre rækkefølgen så dem som er sidst bliver først. Det kan også være du har flere synder og dermed bliver nød til at gentage processen et par gange.

Jeg har både Visual 2 og Visual 3 installeret samtidig. Begge virker som de skal. De er begge installeret for mere end 2 år siden og jeg har lavet egne shortcut's til at starte dem. Jeg kan ikke huske om jeg måtte lave nogle krumspring dengang for at få dem begge til at virke samtidig, men jeg mindes at have læst en readme.txt fil med nogle noter om hvad man skulle gøre for at få begge versioner til at virke samtidig. Det kan også ske at det var på lk.dk eller "mit lk" jeg så det.