Lars1

I venstre side har du alle dine produkter, og i højre side har du alle dine funktions blokke. Hvis du opretter en undergruppe som f.eks. cirkulations pumpe, vil den optræde i begge sider, men der behøver ikke føre en funktions blok under cirkulations pumpe for at det virker. Et produkt kan sagtens linkes fra andre undergrupper, som du har gjort med din cirkulations pumpe. Dit program vil ikke virke, da IHC event baseret, til forskel fra en PLC, som er status baseret. Forskellen er at IHC ændre udgange baseret på sidste event, mens en PLC vil have udgangen on hvis bare et af linkne er on. I dit program vil din cirkulations pumpe derfor gå off, når varmen slukker i et af rummene, selvom samtlige andre rum kalder på varme. Du skal samle dine varme kald med en 4.1.02 OR funktions blok. Hvert varme kald skal have sin egen indgang på or blokken. Vedr. at du tidligere skrev at du havde 24-25 grader i rummene, så kan det måske skyldes at dine temp. sensor ikke er kalibreret ordentligt. Hver enkelt temp sensor skal kalibreres individuelt. Det gør du ved at dobbelt klikke på temp. sensorne under lokalitet, og så nederst sætte et offset. Mine temp sensor svinger mellem -2 og +5 grader i offset.

Du skal ikke bruge https, kun http. Start siden med links til administrator etc. køre ukrypteret på port 80, med mindre du har ændret port nr'et. Den vil dog stadigvæk være ukrypteret, så du skal stadigvæk kun bruge http ude s.

Telestater er enten on eller off, så de er enten helt lukkede eller helt åbne. De funger ikke som termostater på radiatorer. LK har forskellige varmestyrings blokke. Du skal hente de nyeste på lk.dk, og vælge den, som passer til dit varme anlæg.

Hvis ikke din egen router har den offentlige IP, skal du også lave port forward i Stofa/SE routeren.

HTTP 403 fejlen opstår før java overhovedet kommer i spil. Hvad skriver du i din browser når du vil tilgå din controller? Det bør være nok at skrive 192.168.1.100 i din browser. Evt. med http:// foran, men det afhænger af din browser. Du kan også prøve at forbinde dig med et USB kable og i administrator viewer verificer at du ikke har fået fjernet adgangen til serviceview etc. under LAN. For at tilgå din controller via USB, skal du bare skrive usb:// i din browser.

Min installation er med 8 input moduler, 16 output moduler, 12 telestater, 6 temp sensor, 6 røgsensor, 6 af de gamle strømslugende 24V udendørs PIR etc. og jeg har "kun" en alm. 72W strømforsyning, og har ikke problemer med belastningen.

Jeg mener dit JAVA sikkerheds problem er rettet i firmware 2.7.220, men ellers er det korrekt at nogle browser er mere pernitten med korrekte certifikater når man til går public IP addresser, end når man tilgår lokale IP addresser.

Spørgsmålet har været oppe mange gange her i foraet. Svaret er nej, men hvis du søger her i foraet, kan du sikkert finde nogle tråde med ideer til hvordan du laver opgraderingen mest lempeligt. Du er som sagt ikke den første som ønsker at opgrader.

En ting jeg savner RIGTIG meget i IHC, er en ordentlig kalender funktion, hvor man kan programmer events etc. Den avancerede udgave indeholder også en mulighed for f.eks. hvert 5 min. at logge en række parameter.

Hvorvidt Elko living og IHC er 100% kompatibelt ved jeg ikke, men der er en RIGTIG godt sandsynlighed for at de er. Den ustabilitet du se, se vi andre også. Erfaringen er at firmware 2.7.199 er den mest stabile. 2.7.220 er lige så ustabil som firmware før 2.7.199, men tilgengæld er der rettet certificat fejl og java fejl i 2.7.220, som ikke er rettet i 2.7.199. Så det er lidt pest eller kolera hvilken version du skal bruge. Det er ikke firmware versionerne du har listet, men visual versionerne. Men bortset fra det, så passer datoerne på Elko versionerne med datoerne på de samme versioner til IHC. At der ikke sker mere på Elko siden skyldes sikkert at Elko for et par år siden droppede samarbejdet med LK. Det medførte en del rygter om at IHC var på vej ud. Om du kan bruge den danske IHC software i din Elko contoller tør jeg ikke garanter, men du kan jo altid prøve at installer IHC visual, og se om du kan indlæse din projekt fil.

Det er ret simpelt at programer. Det er bare et spørgsmål om at lave delay på at du slippe enten max eller min knappen. Det sværeste er at styre om du køre op eller ned i styrke. Til dette kan du bruge en flag, som kipper samtidig med at du køre enten op eller ned i lysstyrke. Er flaget on=at lys styrken vil øges mens du ønsker at slukke, programer du bare en kort puls på udgangen til dimmeren, så den vender lysstyrken. Problemet er bare at erfarings mæssigt kommer dette flag ofte ud af sync med dimmeren, hvorefter lyset går til ful styrke når du vil slukke og omvendt, og eftersom der ikke er nogen tilbage melding fra dimmeren, så er det svært at holde flaget i sync med dimmeren.

Nu handler denne tråd jo om hvorvidt trådstarter med fordel kan købe wireless dimmer som alternativ til at forsøge at kode sig ud af de manglende ind og udgange. I den forbindelse er det værdifuld information at vide om de dimmer som LK sælger idag har fået rettet fejlen med minimums forbrug eller ej. Jeg tør ikke lægge hovedet på blokken for det svar. da jeg kun roder med IHC i min egen installation.

Højst sandsynligt, men du skal have fat i viledningen eller dit elselskab for at finde ud af om den er aktiveret.

Løste den problemet?

Hvis du kan fikse genstart af controller problemet, kan du noget som LK ikke kan (ikke at det vil være nogen nyhed i sig selv) :-) Controller genstart sker også når jeg tilgår den via serviceview eller IHC visual, når den har kørt i 6-7 dage siden sidste genstart. De benytter jo begge samme interface, som du også benytter, så problemet ligger nok mere i controller interfacet end i IHC captain.

Har LK ikke fået rette den fejl i alle deres wireless dimmer endnu? Ø80 lampeudtagne i dimmer udgaven kræver ikke længere nogen minimums belastning såvidt jeg husker. Om det også er tilfældet for afbr. modul dimmerne er jeg ikke 100% sikker på.

Man kunne jo også bare rette sit program, så controlleren husker status på de udgange hvor det er vigtigt, også rette alle de fejl, som får controlleren til at genstarte hyppigt. Jeg har lagt nogle gode råd som har bragt mig fra 3 dage i snit mellem 2 genstart til 7 dage i snit. Men når det er sagt, så er jeg enig i at det er under alt kritik at controlleren genstarter så tidt.

Du skal i programmet bare vælge at udgange skal huske tilstanden fra før genstarten. Det bør du i øvrigt gøre ved alle udgange, hvor du har sikkerheds komponenter siddende.

Ja det gælder også LK's egne FB'er. Min erfaring er dog at det største problem er uoverensstemmelse mellem det der fysisk er monteret, og de produkter man har valgt i sit program, samt hvis man har 2 produkter på den samme data line/udgang eller indgang. LK's IHC controller kan virkelig ikke lide andet end 1-1 relationships.

Du kan gøre meget for at stabiliser din controller selv med FW 2.20, men det kræver at du er meget omhyggelig med din programering. Undgå timer og tæller hvis muligt Sørg for at der et et 200% match mellem hvad der er monteret på dine ind og udgange, og hvilke produkter du har tilføjet i dit program. Check også at alle produkter konfigureret med de rigtige dataliner Lad være med at have flere produkter på samme datalinie. Ved at følge ovenstående har jeg fået min controller til at gå fra genstart hver 3 dag til "kun" at genstarte hver 7 dag. Pt. tester jeg om udskiftning af zigza tempsensor med LK's temp. sensor vil have nogen positiv effekt. Desværre må vi nok vente til næste år før det er muligt at konkluder noget, da jeg først har skiftet sensorne idag.

Fejlen kan ligge både i funktions blokken og i udgangen. Check også om der et af stedderne er sat at status på udgangen skal huskes i forbindelse med genstart. Hvis det er sat på funktions blokken, men ikke på selve udgangen, kan det give nogle sjove resultater sommetider. Jeg sætter det altid på selve udgange, fremfor på udgangen på funktionsblokken.

Du skal jo hente stortset det samme som man henter når man starter serviceview, så sålænge du ikke er længer om at starte end serviceview, så vil jeg mene at du har gjort det godt. :-)

Jeg tvivler på at LK gør ret meget for at forbedre svartider og stabiliteten. Hoved problemet er IHC controlleren. Den genstarter også ofte når du tilgår den med IHC Visual eller service view. De hyppige genstart skylles primært memory leaks i IHC controlleren. Den forrige firmware fra LK var rimelig stabil, men i den seneste release har de genindført noget ustabilitet. Den tid det tager for app'en at connecte til controlleren skyldes også et controller problem. Vi ser det samme når man går på med Visual og serviceview. De tager også en krig om at connecte. Delay fra man beder om at slukke eller tænde lyset kan ligger 2 steddet. Det ene er hvis netforbindelsen mellem app'en og controlleren er langsom eller har høj latency, det andet er hvis controleren generelt er langsom. Jeg ser ofte delays når jeg forsøger at styre ind/udgange via serviceview. Eftersom app'en bruger samme interface til controllerne, vil man også se delays her hvis ens serviceview er langsom. IHC captain vil have samme problem, da den også bruger samme interface. Sidst men ikke mindst. Husk på at selvom du køber en controller, som er produceret igår, så er HW spec og design næste 10 år gammelt på LK's seneste IHC controler, og over 20 år på det netværks interface der benyttes af Visual, Serviceview, app, IHC captain etc. Ingen af delen er blevet synderligt opdateret siden de blev frigivet.

Prøv at tage fat i din lokale elektronik pusher, og se om han ikke har et oneshot relæ eller tilsvarende, som du kan skyde ind mellem din Kamstrup måler og den sløve IHC controller.

Det afhænger af dit netværk. Nogle router/firewalls kan konfigureres således at du kan bruge både LAN og WAN addressen, mens andre kun tillade WAN udefra og LAN indefra.