Lars1

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.

Med de fejl du beskriver, er jeg ret sikker på at du ikke køre med den nyeste firmware i din IHC controller. Uden den vil du have problemer med JAVA og TLS kryptering. Præcis hvad det er der skal slåes fra, for at få JAVA 8 til at virke kan jeg ikke længere huske. Men der ligger flere indlæg her på boardet om emnet, og nogle af dem har også et link til den nyhed på LK.dk, som indeholder de rette oplysninger.

Jeg tvivler stærkt på at der er nogen som har P100 moduler liggende. De har været udgået temmeligt længe. Hvis de 3 P100 moduler skal sidde på samme din skinne i en IHC net tavle, kan du uden problemer bruge et P112 patch panel i steddet.

Når du aligevel er logget på admin interfacet, så give os også lige produktions datoen

Som Brian skriver, så check serviceview. Mit bedste gæt er at du har en monterings fejl i din installation. I service viewet kan se status på dine ind og udgange, og du kan manuelt aktiver dem, så du hurtigt kan se om du skulle have en monterings fejl.

LK's IHC er fuldt af memory leaks. Min egen erfaring er at det er meget vigtigt at du ikke tilføjer komponenter i programmet, som ikke rent fysisk er monteret på de dataliner du angiver. Den anden vej rundt, hvor du har komponenter fysisk monteret men ikke tilføjet i dit program er ligeså slemt. Du behøver ikke have komponenterne linket til nogen funktions blok, men der skal være en 100% 1-1 overenstemmelse mellem komponenter og hvad der fysisk er monteret på dine I/O moduler. Komponenter uden dataliner konfigureret kan LK's IHC heller ikke lide.

Hvor i landet holder du til? Er det HW version 6.1 eller 6.2?

Hvad med at kode en funktion, som kan tænde sprinkleren når hun nærmer sig.

Jeg har kun 3 gæt, som du selvfølgelig har prøvet. Sørget for at der er en pære i lampeudtaget og spænding på mens du linker. Dette er et kendt problem som skulle være løst i de nyer lampeudtag, men det er MEGET svært at se forskel på de nye og gamle lampeudtag, da de har samme el-nr. Prøvet at skifte batteri i trykket. At det er trykket som er defekt og ikke lampe udtaget.