Lars1

Du bør kunne linke hver enkelt knap på fjernbetjeningen til forskellige FB'er. Knapperne har ikke nogen funktion i sig selv. Alt funktionalitet ligger i den/de FB'er du linker dem til.

Jeg vil fremover forsøge at holde denne tråd opdateret med de forskellige problemer der findes for de forskellige Java og IHC firmware versioner. Skriv endeligt kommentar i denne tråd. Jeg vil efter bedste evne forsøge at holde dette indlæg opdateret. Seneste nyt: 28/07-2021: Oracle har fornylig releaset Java 8 update 311. I den er TLS 1.0 og 1.1 disablet på en ny måde. For at enable de 2 skal de fjernes fra jdk.tls.disabledAlgorithms=. Se flere detaljer længere nede. Seneste nyt: 22/07-2021: Oracle har fornylig releaset Java 8 update 291. I den er TLS 1.0 og 1.1 disablet. For at enable de 2 skal de tilføjes i på samme måde som MD5. Se flere detaljer længere nede. Seneste nyt: 19/10-2017: Oracle har fornylig releaset Java 8 update 151. Ingen problemer med firmware 2.8.4. Tidligere firmware har problemer med manglende MD5 understøttelse. Seneste nyt: 29/7-2017: Oracle har fornylig releaset Java 8 update 141. Samme udfordring med MD5 som med Java 8 update 131. Problemet er imidlertid løst med firwmare 2.8.4 som er blevet released af LK inden for den sidste mdr. Seneste nyt: 21/4-2017: Oracle har releaset Java 8 update 131. LK IHC Serviceview etc. virker ikke med denne Java medmindre man enabler MD5 certifikater igen. Se workaround under Java 8 update 131. Seneste nyt: 1/10-2016: LK har langt om længe releaset firmware 2.8.1, men det bør kun installeres på HW6.2 controller jvf. LK. Den nye firmware løser såvidt jeg kan se alle kendte JAVA problemer. Jeg har ikke fået checket om de også har fået opdateret krypterings algorithmerne som bruges i forbindelse med HTTPS trafik. Eftersom der ikke er kommet en ny firmware til HW6.1 controller, lader jeg nedenstående stå. Seneste nyt: 22/7-2016: Oracle har releaset Java 8 update 101 og den ser ud til igen at virke med LK's firmware 2.7.199 og 2.7.220, sålænge man bruger de workarounds som er beskrevet for Java 8 update 71 længere nede. Hvis i allerede har implementeret workaroundsne, kan i opgrader til Java 8 update 101 direkte uden at ændre noget. Firmware 2.8.4: Problemer: Fungere i.flg LK's support site ikke på HW6.1 controller. Løst: MD5 certifikater bruges ikke længere af serviceview etc. Det ser umiddelbart ud til at Visual's problemer med at forbinde til controlleren samtidig med at f.eks. IHC Captain køre er blevet løst Firmware 2.8.3: Problemer: Fungere i.flg LK's support site ikke på HW6.1 controller. Enkelte rapporter om at Visual har problemer med at connecte til controlleren hvis Serviceview eller f.eks. IHC Captain køre Løst: Sandsynligvis fornyede certifikater Firmware 2.8.1: Problemer: PT ingen kendte problemer udover at den i.flg LK's support site ikke fungere på HW6.1 controller. Løst: Fornyede certifikater Firmware 2.7.220: Problemer: Udløbne JAVA og SSL certifikater, som giver problemer med Java applikationer som service view etc. Forældet krypterings algorithm'er som giver problemer for web scene view i nyer browser, samt SOAP API'et Generelt set som en ustabil firmware Løst: Understøttelse at TLS 1.1 og 1.2 kryptering Support for lux/temp og fugt/temp sensor Firmware 2.7.199: Problemer: Udløbne JAVA og SSL certifikater, som giver problemer med Java applikationer som serviceview etc. Forældet krypterings algorithm'er som giver problemer for web sceneview i nyer browser. Kun understøttelse af TLS 1.0, hvilket giver problemer for Java applikationer som service view etc. Ingen understøttelse af lux/temp og fugt/temp sensor Løst: Generelt set som en stabil firmware Java 8 update 311: TLSv1, TLSv1.1 skal nu også fjernes fra jdk.tls.disabledAlgorithms= i <JAVA_HOME>/lib/security/java.security. Hvis man ikke fjerne dem der, får man unable to login. Java 8 update 291: Ældre TLS protokoller er blevet disablet. Disablingen forhindre IHC Java applikationerne i at blive loadet. Find filen <JAVA_HOME>/lib/security/java.security og tilføj "TLSv1, TLSv1.1" til jdk.tls.legacyAlgorithms Java 8 update 131, 141 og 151: Problemet er løst med firmware 2.8.4 Jeg får nedenstående fejl når jeg forsøger at starte Serviceview. Workarounden er at fjerne MD5 fra jdk.jar.disabledAlgorithms= som findes i konfig. filen java.security i <JAVA_HOME>/lib/security/java.security. En nærmere beskrivelse af baggrunden for ændringen i Java findes her https://blogs.oracle.com/java-platform-group/entry/strengthening_signatures og her https://blogs.oracle.com/java-platform-group/entry/strengthening_signatures_part_2 Java 8 update 101: Java 8 update 101 blev released omkring 22/7-2016. Den ser ud til at virke med samme workarounds som for Java 8 update 71 Java 8 update 77: Java 8 update 77 blev released 23/3-2016. PT. er det ikke lykkes mig at få service view til at starte med JAVA 8 build 77 installeret, heller ikke selvom den er disablet i java control panel. Jeg får nedenstående fejl og ingen af løsningerne fra de tidligere Java versioner virker. Løsningen er pt. at downgrade til en ændre Java version. De ændre versioner kan hentes her http://www.oracle.com/technetwork/java/archive-139210.html men vær opmærksom på at den nyeste version skal afinstalleres for at admin, service view etc. vil virke. Jeg håber jeg kan få fat på LK efter påske og få dem til at release en ny FW med opdaterede certifikater og krypterings protokoller, da det synes at være det som er problemet. Edit 1/4-2016: Problemet ser ud til at være opstået allerede i Java 8 update 72. Java 8 update 71 ser dermed ud til at være den sidste Java version, som kan bringes til at afvikle LK's IHC's Java applikationer. Jvf. LK's support site er seneste supporterede Java version for HW6.1 controller Java 8 update 66. Java 8 update 71 eller tidligere (Gælder også for Java 8 update 101): Efter opgradering til Java 8 update 71 vil service view ikke længere starte. Den kommer med nedenstående fejl, og der kommer ikke nogen boks hvor man kan aksepter expired certifikater. Løsningen findes her. http://java.com/en/download/help/jcp_security.xml Tilføj det som står uden for location i ovenstående billed, under edit site list på security tab'en i Java control panel. Java vil brokke sig over at i kun skriver http: og ikke https:, men det skal i bare aksepter. Der skal står HTTP:, da JAVA applikationen downloades via HTTP, mens data og login sendes og modtages over https: Når i starter service view første gang efter ovenstående rettelse, vil få en boks hvor i kan aksepter udløbne certifikater. Forkert bruger ID/Password: Denne fejl ses ind imellem hvis man køre med en Java 8 update 71 eller nyer, samt Firmware 2.7.199 eller ældre. Workarounden er at disable TLS 1.1 og 1.2 og enable TLS 1.0 i Java. Browser support for forældet kryptering: I firefox skriver i about:config i url linien. aksepter den advarsel som kommer op, og søger efter security.tls.insecure_fallback_hosts. Dobbelt klik på entriet, og indtast ip addressen på jeres IHC controller. Herefter vil web scene viewer igen virke, ligesom SOAP login fra en browser etc.

Jeg forstår ikke lige dette spørgsmål.

Dit program ser rigtigt nok ud, og du har de samme setpunkt værdier, så mit bedste gæt er at det er indreguleringen af dit gulvvarme den er gal med. Jeg gætter på at når du siger at stuen er kold, så er det gulvet, som føles kolder end i køkkenet. Eftersom du køre med pulsvarme, vil du sikkert godt kunne opleve dette hvis ikke de 2 varme kredse er lige lange. Du bør kunne kompenser for dette ved at ændre på puls varme parameterne i indstillinger i FB'en. Men det kan også være dit gulvvarme som ikke er indreguleret korrekt. Hvis alt ellers er ens i stuen og køkkenet, kunne du også vælge bare at køre med en varme FB og trække udgangen over på de 2 telestater. Lidt ligesom du har gjort med temp. indgangen. Men hvis du gør dette får du ikke mulighed for at køre med forskellige værdier for de 2 varme kredse.

Hvis der er krav om at i skal have ABDL anlæg i jeres bygninger, kan IHC ikke bruges, da det ikke er godkendt som ABDL anlæg. Generelt er IHC slet ikke godkendt til nogen former for sikkerheds systemer. Hverken brand eller tyveri. Det er ok at bruge det i private hjem, hvor der ikke er noget lovkrav om godkendte sikrings anlæg, men hvor der er lovkrav om godkendte sikrings anlæg kan IHC ikke bruges. Man kan løse meget med en ekstern strømforsyning og et par overdragelses relæer. Men før du har afklaret om der er krav om godkendt ABDL anlæg, vil jeg ikke bruge mere tid på dit problem.

Ikke helt. Der er ikke noget i vejen for at have produkter eller dele af et produkt, som ikke er forbundet til en FB, sålænge at produktet rent fysisk er tilsluttet IHC installationen på den port som er registreret i programmet. Men hvis man ikke bruger et produkt, og ikke forventer at komme til at bruge det, bør man fjerne det fra programmet og installationen. Om du monter de 3 udendørs lamper på samme udgang, eller 3 forskellige er ligegyldigt fra et stabilitets syspunkt. Hvis de alle 3 er monteret på den samme udgang, skal du bare kun have 1 lampe udtags produkt i dit program (reglen om aldrig at bruge samme udgang 2 gange i dit program), mens hvis de er monteret på hver sin udgang, skal du have 3 lampe udtags produkter som bruger hver deres udgang. Du må ikke have 3 lampeudtags produkter i dit program, som bruger samme udgang. Dine 3 udendørs sensor bør have hver sin indgang, men det skyldes at IHC er event styret, og ikke status styret som en PLC. Hvis de 3 udendørs sensor skal bruges på samme indgang i en FB, skal deres event sendes gennem en OR FB som f.eks. 4.1.02 først, ellers vil din indgang i FB'en går off, når en af sensorne går off, selvom de 2 andre fortsat er on. Afhængig af hvad det er for nogle udendørs sensor, kan de godt monteres på samme port, og så gælder samme regl som ved lampe udtagne. Kun et sensor produkt i dit program.

Hvis du har f.eks. en temp. sensor i din stue, og den er monteret på indgang 1.01, så skal der også være et temp. sensor produkt i dit program, som er konfigureret til at sidde på indgang 1.01. Omvendt. Hvis du ikke har en temp. sensor fysisk monteret på indgang 1.01, så må der heller ikke være et temp. sensor produkt i dit program, som er konfigureret til at sidde på indgang 1.01. Du må ikke have f.eks. 2 temp. sensor som er i dit program er konfigureret til at bruge den samme fysiske indgang. Tryk, lampe stedder etc. er ikke så kritiske, men du bør heller ikke have flere tryk, lampestedder etc. som er konfigureret til at bruge de samme ind og udgange.

Da IHC er event styret, skal du sende dem gennem en OR blok som f.eks. 4.1.02 før indgangen på FB'en, så er der ikke noget problem i at have flere PIR på samme FB.

Hvad er det for 3 wireless enheder som du har problemer med. Kunne være interessant at kigge lidt nærmere på FB'en for de 3.

Prøv at sætte en alm. lampe med en alm. pære på lampeudtaget, så kan du hurtigt se om det er lampe udtaget som er blevet defekt eller ej. Jeg har selv en elektronisk trafo med 6*10W halogen spot på et HW1 lampeudtag. Bortset fra at de aldrig slukker helt, medmindre jeg tager strømmen til lampeudtaget, så virker det fint på 5 år.

Det lyder som om et eller andet forstyre din IHC controller. Prøv evt. at lukke for internet adgangen til den, for at udelukker at nogen/noget udefra forsøger sig med et DDOS eller tilsvarende. Der findes en del robotter på internettet, som løbende scanner nettet, og finder de et eller andet som gider svare dem, kan de godt finde på at hænge fast på den IP et godt stykke tid.

Den fejl du beskriver er meget normal hvis du bruger lavenergi eller LED pære. De gamle wireless lampeudtage og stikkontakter etc. har en minimums belastning på 5W. Kommer man under det kan enheden opføre sig som du beskriver. Det skøre ved fejlen er at det kan virke fint i en periode, hvorefter man så har problemer i en periode, hvorefter det så virker fint igen. Fejlen er rettet i lampeudtag af HW2 modellen. Desværre har den samme produkt nr. som HW1 modellen, så den eneste måde at kende forskel er på et lille klistermærke på bagsiden.

Man kan starte LK IHC's JAVA applikationer af 2 veje. Enten fra et link i et browser vindue, eller et link fra IHC gruppen i start menuen. Hvis man starter via et link i et browser vindue, skal man i nogle browser sætte JAVA rettigheder, eller sænke browserens sikkerheds niveau til lav. Det er ikke JAVA, som styre disse settings. Hvis man starter via et link fra f.eks. start menuen, så skal man ikke først slåsse med browser sikkerheden. Så er det kun JAVA man skal slåsse med. Hvis vi skal hjælpe dig, bliver du nød til at fortælle hvordan du starter JAVA, og hvornår fejlen kommer, om JAVA overhovedet når at starte etc.

Det lader til at din elektriker har været forudseende. Det er ikke normalt man ser en afbryder kun til at afbryde de 24V til controlleren. :-) Held og lykke med forsøget i morgen.

Jeg tror det mest skyldes at patentet/mønster beskyttelsen på placeringen af kloer, størrelsen på rammer etc. er udløbet. Det som LK opdater pt. er indmaden, men det er ikke nok til at de kan forlænge beskyttelsen af selve FUGA designet. Jeg mindes ikke at have set alternative produkter, som passer til OPUS serien endnu.

Jeg har et par gange oplevet et tilsvarende problem efter at controlleren er genstartet af sig selv. Jeg har hidtil kunnet løse problemet ved at tage strømmen til controlleren, incl. batteri backup, i 10 sek. Når controlleren efterfølgende er kommet op, har alt virket som før den genstartede sig selv.

Det problem du har, har jeg også set for et par år siden, men det forsvandt af sig selv når jeg genstartede controlleren manuelt. Andre har løst problemet ved at unlink og linke de wireless enheder, som der er problemer med. Husk at uploade dit program mellem unlink og link. LK's IHC er pænt pernitten med at der er 1-1 overensstemmelse mellem hvad der fysisk er monteret, og hvad der er programeret. Alle fejl kan have indvirkning på stabiliteten. Nogle fejl, som en temp. sensor på en indgang, som ikke er programeret, eller en programeret temp. sensor, som ikke findes er værre end f.eks. et tryk, som ikke er programeret. Du kan rimeligt nemt i bunden af LK IHC dokumentations rapporterne se om du skulle have brugt en ind eller udgang 2 gange. Ellers har Mikkel lavet et ganske godt dokumentations program, som såvidt jeg husker highlighter fejl som ind/udgange der er brugt 2 gange. Det er beskrevet i flere detaler i flere tråde her på boardet.

Det kan du være 100% sikker på. Ellers vil LK ikke kunne komme efter dem som kopier deres produkt og teknologi. De har også patenter på deres FUGA og OPUS serie. Det er derfor de pt. er igang med en større opdatering. Det oprindelige patent er ved at løbe ud, og ved at opdater serierne, kan de forny patentet, og dermed sikre deres produkter igen.

Hvis du ikke har styr på hvad der er fase, nul og mellemledning, bør du få en elektriker til at skifte afbryderen for dig.

Nej. Ø80 lampeudtag, som normalt sidder i loftet.

Standalone wireless komponenterne er blevet solgt i flere lande under forskellige schneider brands gennem flere år. Men de fortråede komponenterne og controlleren har jeg kun set i DK og Norge desværre. I Norge bliver den ikke længere markedsført, eller supporteret med firmware upgrades etc. I Norge havde de nogle fortråede temp. sensor med display. De kostede det dobbelte af de temp sensor som LK sælger herhjemme, og jeg har INGEN idee om hvordan displayet fungerede. Men jeg kunne RIGTIG godt tænke mig et display men aktuel temperatur og gerne også setpunkt i mine temp. sensor. Edit: Har lige set linket fra Anders. Lidt interessant at fuld IHC bliver markedsført i Tyskland, og med ny firmware så sent som i september mdr. sidste år, når der ikke kommer ny firmware til Norge længere. Men de er ikke kommet længere end til Visual 2.7.2 i Tyskland, og den er fra 2012, så det tyder ikke rigtig på en seriøs satsning, men mere et lævn fra et halvhjertet forsøg for nogle år siden.

Nu ved jeg ikke om du nogensinde har brugt det stik til data i forvejen, får det bør ikke virke hvis de 2 ender ikke er monteret efter den samme type. Det skal dog siges at jeg har set en switch, som kunne køre half duplex på et kabel, hvor det var byttet om på par'ne i den ene ende. Normalt vil det dog ikke virke.

Hvorvidt i kan køre uden shunt eller ej afhænger ikke af jeres styring, men hvordan jeres varme installation er lavet. Har i radiator og træ gulve med gulvvarme, bør i IKKE køre uden shuntpumpe. Radiator bør have en fremløbs temperatur på 50-60 grader, mens gulvarme i træ gulve ikke bør være over 30-40 grader. Generelt får man en laver varme regning ved ikke at have en fremløbs temperatur i gulvarme på mere end 30-40 grader, og det gælder alle slags gulvvarme. Pumpeshunten bruges i blandesløjfen hvor man blander koldt returvand i det varme fremløb, således at radiatorne fortsat kan få 50-60 grader fremløb, mens gulvvarmen kun får 30-40 grader.

Man har lov at håbe, men LK er en kommerciel virksomhed. Efter de er blevet en integreret del af Schneider, tænker de i store baner. Hvis de kan undgå at lave noget kun til det danske marked, så gør de det. Bare se hvad der er sket på kontaktor og gruppe afbryder til tavler. Alt hvad der stod LK på er erstattet med tilsvarende Schneider produkter. Jeg er ikke sikker på om den danske el-lovgivning er blevet rettet ind, så det nu er lovligt at installer schuko udtage. Hvis den er, er det bare et spørgsmål om tid, før FUGA og OPUS serien vil blive erstattet med Schuko produkter. Personligt ser jeg helst Schuko forbudt ved lov, da man ikke kan se om man vender et stik korrekt når man sætter det i schuko udtaget. Heller ikke når der er jord forbindelse i stikket og udtaget. Jeg har efterhånden mere end 1 gang løst IT problemer ved at vende stikket i en schuko stikkontakt, og det selvom der er en fuldt funktionsdygtig jordforbindelse i både computer kablet, stikket og stikkontakten. Jeg tror ikke du skal sætte næsen op efter at LK IHC bliver open source. Det vil være en konkurrent til Schneiders andre home automation produkter. Heller skrotte det og grave det dybt ned, en risiker at nogen arbejder videre med det. Men de fleste af deres patenter må snart være løbet ud, så dem der gider må snart lovligt kunne lave reverse engineering, og arbejde videre derfra.

Jeg vil da håbe at din VVS'er ved hvad han taler om. Man bruger normalt pumpeshunten til at blande koldt returvand med det varme fremløb, for at få 30-40 grader på fremløbet til gulvvarmen, så man ikke ødelægger et træ gulv. Normal fremløb for en radiator er 50-60 grader, og til opvarming af brugsvand køre nogen helt op til 90 grader. Men hvis du ikke har radiator, og dit gasfyr kan levere et fremløb på 30-40 grader, så kan du helt undvære blandesløjfen til din gulvvarme installation.