Lars1

Jeg talte med LK idag, vedr. problemet med den nyeste Java version. Deres kunde support påstår at de er klar over det seneste problem med Java, og at de ikke har nogen workaround, samt at de er bekendt med dårlig stabiliteten i den seneste firmware. Kundesupporten påstår de arbejder på at release en ny firmware og Visual version som bl.a. skulle addresse nedenstående punkter. Udløbne certifikater Stabilitet Forældede krypterings metoder på web scene services etc. Manglende mulighed for at editer noter m.m. under produkt konfiguration i Visual Men jeg tror vi alle har hørt den historie før, så jeg vil se de nye versioner, før jeg tror på dem.

Serie forbundet?. Jeg håber du mener parallelt forbundet. Hvis de er parallelt forbundet, så har jeg ikke flere ideer til hvad der kan være galt, ud over at dimmeren er død, som du selv er inde på.

Når du har testet, har du så sikret dig at der ikke er nogen belastning tilsluttet på bagsiden eller forsiden af dimmeren, samt at 230V er stabil på forsynings siden af dimmeren?

LK's IHC - Nilan implementering er noget være klamp. Den kræver en ekstra PLC til +5.000 kr. og den passer ikke i en alm. gruppe tavle, som IHC komponenterne ellers gør. Det eneste du reelt kan styre er driftniveauet. Hvis du vil have en ordentlig integration, er du nød til at anskaffe et visility board til +10.000.

Din controller er ca. ligeså gammel som min, og jeg kan se at du har samme problem med RF upgrade som jeg har. Har du prøvet at have FW 2.7.199 i den? Den skulle efter sigende kunne opgrader RF versionen, hvilket 2.7.220 ikke kan hvis man går direkte til den fra en ældre version. Det lykkes dog ikke på min controller. Men tilbage til dit problem. Jeg tvivler på at det har noget med vintertid at gøre. Min controller har gjort noget tilsvarende for et par år siden, men der var det nok at tage strømmen til den i 10 sek. Så medmindre du har noget som ikke virker, så vil jeg bare parker hændelsen under endnu en af underlighederne ved LK's IHC.

Der er ikke den store pris forskel på om du bygger dit house controll system med 1 fabrikat, eller med flere forskellige som du bringer til at tale sammen via et trejdeparts produkt. Faktisk vil den sidste løsning ofte være den billigste da der er langt større konkurrence på små systemer med 1 specifik funktions område, end på store komplekse systemer som kan det hele, da disse er få og ofte konkurrer med KNX, EIB og tilsvarende. Det er rigtigt at du har flere fejl kilder ved at benytte flere systemer, men du får på den anden side også et setup, hvor hvis et system fejler, så påvirker det ikke resten. De trindløse telestater jeg har set køre alle på 0-10V eller 4-20mA. Dette er den normale standard inden for elektronisk regulering af trinløse ventiler.

Hvilken af dimmerne sad den blinkende lampe på?

Inden du dødsdømmer dimmeren, vil jeg prøve med en alm. pære eller en halogen pære. Ø80 wireless dimmer i HW 1 udgaven har problemer med LED's, og det som du beskriver her passer meget godt med de problemer.

Prøv at sætte en alm. pære på dimmeren. Hvis det er en HW1 udgave har de problemer med lave belastninger. Det resulter f.eks. i at hvis en pære springer mens den er tændt, og der kun er 1 pære på dimmeren, så kan du ikke slukke for dimmeren. Med andre ord er du nød til at skifte pæren mens der er spænding på, medmindre du slukker ved sikringen.

6.3.01 og 6.3.04 er ikke 2 versioner af den samme blok. Det er 2 forskellige blokke med forskellige formål. Det efterfølgende a og b angiver versionerne af de enkelte blokke. LK ændrede ret meget i deres alarm blokke for ca. 1 år siden. De blev en hel del mere enkle, og i den forbindelse røg nogle af de komplekse blokke, som kun fungerede hvis man linkede dem med andre blokke. Det er sandsynligvis derfor 6.3.04 er røget ud.

LK's IHC wireless lampeudtag er mig bekendt ikke designet til eurodåserne. I DK bruger vi Ø80 dåser til lampe udtag.

Jeg har fuldt respekt for dit ønske, om 1 system til alt, men desværre er house control blevet et meget komplext område, hvor der ikke findes et system som kan det hele. Løsningen er flere forskellige systemer, som man så bringer til at tale sammen via produkter som Domoticz, IHC captain etc. Desværre gør LK alt hvad de kan for at undgå at nogen kan tale med deres IHC system, og de gør INTET for at videre udvikle deres IHC system. Dit ønske om et rent fortråedet system kan jeg kun støtte op om. For mig er wireless en nødløsning, som ofte medføre at man skal skifte batterier etc. i en uendelighed. Det er jo ikke kun Danfoss, som laver telestater, og stort set ingen af deres konkurenter har lavet andet end on/off telestater. Der findes kun meget få trindløse telestater på marked, som kan styres med 4-20mA eller 0-10V styre signaler, og de fleste er kommet på marked indefor de sidste 5 år. Men når det er sagt, så vil jeg heller skifte min IHC installation ud med en PLC installation, Smart-house eller tilsvarende, før jeg begynder at invester i LK's 0-10V moduler. Det gamle fortråede giver ingen mulighed for at sætte f.eks. 2V. Du kan kun reguler op/ned eller tænde/slukke. Du kan ikke sætte et niveau, som på de trådløse dimmer. De nye kræver en trådløs dimmer, som ikke kan placeres i din tavle, og 0-10V modulet er et tavle modul. Jeg ved ikke hvem der har fået den tossede ide hos LK.

Online manualen skulle meget gerne fortælle hvilken udgang din stikkontakt sidder på, have kabel nr. og andre former for identifikation af din stikkontakt. Men ofte er online manualen ikke udfyldt med ret mange detaljer. Jeg kender ikke Safari browseren, og hvis jeg husker ret, supporter LK kun USB på windows. Men prøv med "ping usb" fra en command promt. Du skulle gerne få en IP adr. Du kan prøve at skrive denne IP adr. i URL'en på din browser isteddet for USB.

Indtil root cause af et problem er fundet, vil jeg være meget forsigtig med at kalde Morten's problem for et kendt problem. Det sommertids problem, som Clemen henviser til er løst for flere år siden. Men det kan selvfølgelig være genintroduseret. Et andet problem kan være at LK for et par år siden ENDELIGT skiftede fra NIST til NTP som tidsprotokol. Man skal selv skifte til en NTP server efter opgradering til en firmware som understøtter NTP. Men derudover tror jeg ikke det er et spørgsmål om evner. Det er alene et spørgsmål om prioritet, og det ser desværre ikke ud til at LK satser på deres IHC system længere.

Sommertids problemet er rettet for længe siden. Det eksister ikke i FW 2.7.220. Hvilket NTP server har du sat op i din IHC controller, og hvilken HW version er controlleren?

Jeg kan ikke helt gennemskue hvordan vi kom så langt fra det oprindelige spørgsmål, men nu er vi her. Jeg tror heller ikke vi er så uenige, og jeg siger ikke at balancen i de enkelt par har noget at sige. Jeg har bare svært ved at se hvordan den skulle være så meget anderledes afhængig af om et kabel kommer ind bagfra eller fra neden. Omkring den attachede vejledning, så er jeg ikke sikker på at jeg tolker den som at der kan være flere meters forskel på de enkelte par. Der står godt nok på side 9 at et eller flere par kan være significant shorter, men det er angivet som en fejl kilde og fejl mulighederne er angivet som damaged kable eller dårlig forbindelse. Det er ikke fejl kilder som IMHO godtgør at der kan være flere meters forskel på længden af parne. Tværtimod antyder de at der ikke må være ret stor forskel på længden af parne. Men der står på den anden side heller intet om at parne skal være lige lange, eller tæt på at være lige lange. Omkring udtagne, så er det stort set kun LK udtag, som er plane med væggen. Langt de fleste andre udtag jeg har set for CAT6 og 7 er skråtstillede, så de ikke kræver så dybe dåser. Personligt vil jeg dog til enhver tid fortrække en dyb dåse og et plant vægudtag.

Jeg troede også en gang at problemet næsten kunne fjernes hvis man fjernede alle fejl i ens program, men jeg må erkende at dette ikke er tilfældet. Grunden til denne er kendelse, er at efter at min controller har kørt med genstart ca. hver 7 dag i et par mdr. skiftede jeg en rum/gulv sensor ud med en rum/fugt sensor. Eneste ændring var en udskiftning af produktet i programmet, men siden denne ændring har min controller genstartet ca. hver 3 dag. At rydde op i sit program og sikre sig at alt er linket korrekt, og at der ikke er flere produkter som har fået samme input/output kan dog i nogle tilfælde hjælpe, men jeg har været mit program igennem flere gange, og jeg kan ikke komme under de 3 dage.

Har dit wireless lampeudtag fast fase, eller er det forbundet til en IHC udgang, som du slukker samtidig med wireless? Et andet problem kan være for lav grund belastning. De gamle lampeudtag skal minimum belasted med 5W for at fungere ordentligt.

Prøv at ændre IP på din IHC Captain til statisk uden DHCP reservation. DHCP tildelingen sker meget senere i startup sekvensen end en statisk IP som er sat på netværks interfacet. Det er ikke utænkeligt at IHC Captain forsøger at forbinde sig til Sonos enhederne før netværks interfacet har fået en IP når du køre med DHCP tildeling.

Det er bl.a nedenstående 2 ting du skal være opmærksomme på. Du skal muligvis sætte udgangen for strikkontakterne til at huske tilstanden ved strømafbrydelse. Jeg er ikke 100% sikker på om dette er nødvendigt. Du skal downloade dit program, rette det og uploade igen. Derved husker IHC controlleren alle tilstande, og ændre dem kun hvis power up eventet forskriver en ændring. Hvis du load en ældre version af programmet fra en backup, retter i denne og uploader, så kan IHC controlleren ofte ikke genkende tilstande, og derfor sættes stikkontakter etc. ofte til off. Du kan sagtens downloade programmet, rette, uploade, rette, uploade etc. Du skal bare starte med at downloade for at IHC controlleren vil huske tilstande når du uploader en ny version.

Jeg må desværre sige at jeg tror LK er nået til et punkt, hvor de kun laver rettelser, når der er problemer som ikke længere kan løses med en workaround. JAVA 8 update 77 ser ud til at være et af disse tilfælde.

Jeg har også godt hørt at LK mener at FW 2.20 køre stabilt, men jeg har også hørt fra andre at LK har anbefalet dem at nedgrader til 1.99 for at få bedre stabilitet. Min egen observation er at min controller gik fra at genstarte ca. hver 7 dag, til at genstarte ca. hver 3 dag da jeg udskiftede en rum/gulv temp. sensor med en fugt/temp. sensor, og det uden at der er lavet nogen ændringer ud over udskiftningen af sensor produktet i IHC programmet.

Jeg tror at 2 og 3 hænger sammen. Den nyeste Java virker ikke p.gr.af af de udløbne certifikater. Du kan så også tilføje at web scene view ikke virker i de nyeste browser, grundet forældet krypterings teknik. Det til kan jeg så kun opfordre så mange som muligt til at klage deres nød til LK.

Som jeg skrev tidligere, er det noget siden jeg stoppede med at lave data netværk, så jeg er ikke uptodate på de CAT6 og op. De kom til efter jeg stoppede. Men bøjnings radius argumentet giver ikke rigtig mening som forklaring på hvorfor kablet ikke kan komme ind fra bunden af en connector i steddet for bagsiden. Ofte vil kablet skulle ud gennem bunden eller toppen af dåsen bag, og så vil det give mere mening at kablet kommer ud af en connector som i CAT5 standarden hvis det er bøjnings radius'en som er problemet. Det er korrekt at parne er snoet forskelligt i et kabel, men såvidt jeg husker er denne snoening lavet således at over 10M er alle par igen lige lange. Hvis du måler over 5M er der måske en forskel, men jeg har ikke noget test instrument, så jeg kan ikke efterprøve om dette er korrekt. Balancen i de enkelte par skal være i orden for at de er støj imume, men den har ingen indflydelse på parallel datastrømme. Her er det længden på parne, som er vigtigt. Især ved høje hastigheder. Seriel data strøm i 1 par er relativ simpel. Her har man en start bit, en række data bit's og en stop bit. Man skal kun bekymre sig om timingen i 1 data strøm. Parallel datastrøme som i Gigabit ethernet over kobber er straks mere kompliseret. Her benytter man 3 par samtidig, og nu skal man pludseligt til at holde øje med at data komme i den rigtige rækkefølge på alle 3 par. Det gør man med data buffers i netværks chippen, men det er begræset hvor store buffer man kan have her, og hvis 1 par konsekvent er længere om at sende data igennem end de andre par, vil man for ofte skulle holde en pause for at komme i sync igen. Problemet med at styre parallel datastrømme opdagede man allerede da man kom over 100MHz i processor hastigheder. Print banerne på et motherboard mellem CPU'en og RAM kredsene måtte nu ikke længere afvige mere end få mm. i længde, før bit sekvensen kom ud af sync. Det er også derfor harddisk interfaces m.m. idag alle er serielle.

Den forklaring jeg har fået, er at alle parne skal være lige lange, da de alle bruges parallelt ved gigabit speed. Der er stor risiko for at dette ikke er tilfældet, hvis man bruger samme afslutnings metode, som på CAT5E connectorne. Det er kun 5-10mm i hver ende vi taler om, men det er meget når man snakker hastigheder på over 200MHz.