Lars1

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.

Dybden er der desværre ikke så meget at gøre ved når det skal være CAT6a eller CAT7. Jeg arbejder ikke længere med data netværk til dagligt, men jeg kan ikke mindes at have set CAT6A eller CAT7 connector hvor kablet ikke kommer ind bagfra. Det er længe siden jeg købte udtagne, men jeg mener at denne model passer sammen med IHC net connectorne. http://www1.lk.dk/servlet/context?n1=16&n2=2415&n3=2782&n4=2880

Hvis du bruger standard IHC FB's til varme styring, så kan puls tiderne sættes under indstillinger i de enkelte FB's via service view'et.

De 3 min. kan du ikke ændre på. Det er den tid det tager for en telestat at åbne og lukke. Det skyldes den måde som en telestat er konstrueret på. Men telestater på en radiator er generelt en dårlig løsning. Specielt hvis der ikke er retur termostater på dem.

De fleste telestater har et strømforbrug på 1-2W, så med en 72W strømforsyning skal du have rimeligt mange før du kommer i nærheden af grænsen for strømforsyningen. En normal installation med 1 controler og fuldt bestykket med I/O moduler, PIR sensor, røgmelder etc. vil normalt ligge på 20-40W, så der burde være plads til 10 telestater. Men Lars Jacobsen har tidligere uploadet et regneark, som kan hjælpe med at beregne dit forventede strømforbrug.

Der er stort set ingen udvikling sket på IHC de sidste 10-15 år, men bortset fra det, så er problemet at radiator ikke er beregnet til on/off styring, og IHC har ikke nogen 4-20mA udgange, som typisk bruges til motorventiler. Det er derfor rimeligt svært at kode en varmestyring til radiator baseret varme. Hvis jeg satte telestater på en radiator, vil jeg altid sætte en retur ventil på også, for at undgå de store temp. udsving i radiatoren. Retur ventilen lukker gradvist op og ned på samme måde som fremløbs ventilen. Eneste forskel er bare at den måler på vand temperaturen, mens fremløbs termostaten måler på rum temperaturen. Men jeg har kigget lidt på dine billeder. Det ligner lidt pex slager, som kommer ud af væggen. Hvis det er tilfældet, har du sandsynligvis en fordeler manifold i dit bryggers, og så vil du sandsynligvis kunne sætte telestaterne her, og fortsat benytte termostaterne på radiatorne til at undgå de voldsomme temp. udsving. Du skal bare sørge for at termostaterne altid står på f.eks. 4 eller 5 hvis de idag står på 3. Moderne termostater kan låses, så børn og andre pilfinger ikke ændre dem.

Som trikker lærling, bør du have nogle svende eller mester omkring dig, som du kan spørge til råds. Det er bl.a. deres job at lære dig det du ikke ved, og du vil få meget mere ud af at diskuter problemet direkte med dem, end at vi skal forsøge at forklare det på skrift. Vi kan ikke gøre det meget bedre på skrift end vildledningerne du allerede har.

Hvis du ikke er sikker på hvordan den monteres jvf. vildledningen, så bør du få din lokale elektriker til at monter den for dig. Strøm er ikke nogen man bare leger med, og slet ikke i en el-tavle.

Du kan bruge enhver magnet ventil som er godkendt til drikkevands anlæg. Desværre gør den godkendelse dem relativt dyre.

Som jeg har skrevet oven over, så virker admin og service view etc. ikke med den nyeste Java. Ældre Java versioner kan hentes her. http://www.oracle.com/technetwork/java/archive-139210.html Efter en downgrade virker alt igen.

Jeg har opdateret nedenstående tråd, og vil fremover forsøge at holde den opdateret. Vil det ikke være muligt at lave den sticky eller på anden måde få den fremhævet, da den indeholder løsningerne på mange af de Java problemer der ofte bliver efterlyst løsninger til. Når jeg får tid har jeg planer om at lave en tråd om hvad man kan gøre for at forbedre stabiliteten i ens controller. Det vil være dejligt hvis den også kunne gøres til en FAQ Andre kan sikkert lave FAQ'er om LED's, dimmer etc. Der har jeg ikke så meget erfaring.

Jeg håber du får svar fra en af de andre kode hajer, for jeg har desværre begænset tid til at hjælpe pt.

Nu er det ikke mig som har problem med at få det til at virke, men bortset fra det, er det kun wireless dæmper som ikke fungere i simuleringen. Fortråede dæmper funger fint i simuleringen, bort set fra at man ikke får nogen tilbage melding, så man har rent faktisk ingen idee om hvilken lysstyrke de står til.

Hvad gør du med strømforsyning af PI'en?