Lars1

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.

Hvad er problemet med den linie?

Hvad sker der hvis du forsøger at downloade projektet fra controlleren, rette i det og uploade det igen?

Jeg havde præcis samme udfordring med min (u)smartread måler. Den optiske sensor talte lystigt når jeg holdte den nærheden af dioden på IHC controlleren, men på (u)smartread måleren skulle den placeres ret præcist for at ville fange noget.

Åben IHC Visual Vælg Hjælpe Emner under Hjælp Søg på link wirelessDu har nu flere punkter, med en ganske god step by step guide til hvordan du linker dine wireless enheder til controlleren. Husk dog at download dit program til Visual inden du begynder at linke dine wireless enheder. Basal hjælp til programering af din controller finder du i samme hjælpe menu. Hvor i landet gemmer du dig iøvrigt?

Jeg ved ikke hvordan du har monteret den optiske sensor, men jeg havde lidt problemer med min på min (u)smartread måler i starten. Det virkede først godt da jeg tapede sensoren fast med noget mørkt tape, så der ikke kom noget falsk lys ind. Sensoren skulle også sidde meget præcist over dioden for at virke. Jeg har før set s0 bussen benævnt som en s0-indgang, også selvom den blev brug til at sende puls signaler til externe tæller. 230V relæerne er jeg 99,999% sikre på vil være for langsomme til 10.000 impl/KWh.