Astronaut

Løs forbindelse er også en mulighed. Det behøver ikke være PIR'en der er defekt. Hvis der er fejl på 0 eller 24V så ryger den i powerup mode hver gang strømme ryger.

Har du prøvet at sætte trace på den i IHC Service View?

Der er kun to dimmere der virker ordentligt med LED: Ø80 V2 og 2 kanal DIN dimmer. Alt andet giver blot problemer. Der er ingen UNI Dimmer v2.

For at sige det endnu mere skarpt: hold dig væk fra kombi lysdæmperne. Det kan være du i dag kan finde LED pærer der virker med dem, men du kan ikke regne med at det er tilfældet om 5 år. Jeg har 12 stk. kombi dæmpere liggende fordi jeg tilsidst opgav at finde LED pærer der er kompatible.

Problemet er selvfølgeligt hvis det er lige så lukket som IHC. For det er ganske enkelt svært at forestille sig at Schneider har ressourcerne og viljen til at følge med udviklingen. Lige nu tror jeg ville vælge en af de 3. parts løsninger der kører zigbee men kan bruge Fuga IHC tangenter. Eller IHC igen.

Grundlæggende er der intet personligt ved det der ligger på en Visual 1 controller. Den er klippestabil men kan ikke sættes på internettet. Den eneste måde at betjene systemet er således vha. de tangenter og følere der måtte være sat op i huset.

Der blev jeg klogere. Jeg havde aldrig tænkt at et HPFI relæ kunne have problemer med hurtige skift i belastningen. Jeg tænker at det kunne give mening at skifte sikringerne til mine dæmpere til nogen der har indbygget HPFI og på den måde køre uden om det HPFI relæ som bruges til bl.a. komfuret.

Det billede du har lagt her, er det alt det IHC du har? Har du nogen IHC komponenter i din el-tavle? For hvis det du har vist er alt hvad du har, så har du IHC varianten uden controller. Og i så fald er det vist relativt nemt at rode med men også ret begrænset hvad du kan få det til. Der ligger vejledninger på LK's website for de enkelte komponenter der viser hvordan man gør. Jeg har aldrig selv prøvet det.

Det du har er en TermIHC controller. Jeg har aldrig rodet med sådan en, men jeg ved at der intet grafisk miljø findes til den. Det hele foregår gennem et terminal program. Sandsynligvis kan du slippe afsted med den rigtige USB-RS232 adapter til at få fat i controlleren. På den måde kan du udlæse programmet (spørg mig ikke hvordan) og du kan også udlæse dokumentationen for din installation (vigtigt, men spørg mig ikke hvordan). Dokumentationen for din installation er vigtig for at planlægge hvordan en ny installation skal hænge sammen. Hvis du kigger i din el tavle så vil du se en række input og output enheder. De er ret dumme komponenter og genbruges hvis du køber en ny controller. Den nye controller programmeres i et grafisk miljø med mus etc. Controlleren er sandsynligvis forbundet med ca. 10-40 ledninger alt efter hvor mange input og output moduler du har. Ret fysisk passer den nye controller ind hvor den gamle sad (den er lidt smallere). Ledningerne skal også tilsluttes stort set samme sted på den nye controller, men det er vigtigt at man er omhyggelig - ellers virker ingenting. Når controlleren så er monteret skal den programmeres. Alt efter hvor mange ting input/output moduler du har kan det være en opgave af varierende størrelse. Jeg programmerede min egen controller med et meget basalt program på et par timer. Sidenhen er det vokset betragteligt. At skrive programmer til IHC ligner ikke noget man lærer andre steder. Grundlæggende er der nogle ganske få koncepter man skal forstå, men sådan et program bliver hurtigt stort og svært at overskue. I mine øjne er det dog vigtigt at du investerer nogle timer i det basale, sådan at du kan forstå hvad elektrikeren laver til dig. Det er også rart at kunne lave den slags ændringer du beskriver ovenfor selv uden at skulle ringe til en elektriker. Det er ikke alle elektrikere der ved noget om IHC eller forstår det. Det er således vigtigt at du finder en elektriker der ved hvad han laver. Sidst skal du vide at IHC er en teknologi der er tæt ved vejs ende. Jeg tror ikke du skal forvente at der sker enormt meget rent teknologisk på den front i fremtiden. Heldigvis er det et ganske lille problem fordi flere andre har formået at bygge "tilbygninger" til IHC (fx. IHC Captain, Home Assistant, OpenHAB). Disse opdateres i rivende fart. Skulle du vælge i stedet at rive IHC ud af dit hus, så er det værd at overveje hvor lang tid du forventer at andre produkter lever og hvad stabiliteten er. Grundlæggende funktioner som tænd og sluk af lys skal bare virke. Tilgang til skidtet fra internettet er for de fleste "nice to have". Når man vælger en "smart" el installation så er det vigtigste at de basale komponenter er stabile og at du kan forvente at de vil virke i de næste mange år frem i tiden. Sådan har IHC været indtil nu. Jeg håber det fortsætter. Under alle omstændigheder har jeg meget lille tillid til andre løsninger på det punkt. Derfor valgte jeg selv IHC igen da vi flyttede for et par år siden.

Dobbeltklik virker ikke specielt godt på wireless. Der skal være en del tid imellem kliks før det virker stabilt. En stor fejl i mine øjne. Man han kan bare købe et 6 tryk (3 tangenter). Så er der knapper nok.

Kombi dimmeren virker kun når der er belastning på den. Den trækker strøm gennem belastningen selvom der er slukket.

Nej ... jeg vil have en proxy der udstiller controllerens API. Sådan at Home Assistant, OpenHAB, Kaptajnen, LK's IHC App, måske endda IHC Visual opfatter proxyen som en IHC Controller. Kun vi ved at den sender alting videre til en rigtig controller bagved og får den rigtige controller til at lave arbejdet. Proxyens primære opgave er at være opdateret på Java fronten sådan at vi ikke sætter outdatet software på eget net (eller internettet). En sekundær opgave en proxy ville løse ville være at beskytte IHC Controlleren mod for mange connections. Jeg har set min egen Visual 3 controller stejle da jeg på et tidspunkt kørte med alle ovenstående connections + en ekstra HA connection. Til sidst måtte jeg genstarte controlleren.

Problemet vil kun blive værre med tiden. På et tidspunkt vil LK holde op med at lave nye versioner af IHC controlleren og holde op med at lave software opdateringer. Til den tid vil IHC controlleren progressivt blive mere og mere usikker. Jeg har et ønske om at min IHC controller kører de næste 15 år. Jeg har også et ønske om en begrænset integration mellem min IHC verden og resten af verden. Det hænger ikke sammen med en situation hvor LK ikke opdaterer softwaren i controlleren længere. Allerede i dag gyser jeg ved tanken om at folk sætter IHC controlleren direkte på internettet. Mine tanker går på om man kunne bygge en IHC Proxy. Dvs. en stump kode der fx. kunne køre på en Raspberry Pi og som for omverden lignede en IHC Controller men sendte alle requests videre til en bagvedliggende IHC controller. På den måde ville controlleren sidde på et netværk hvor den kun kunne snakke med proxyen og hvor proxyen var den eneste der kunne snakke med controlleren.

Og i dag kan de passende udskiftes med en tavle-dimmer (ville du sikkert have skrevet ).

Det burde ikke kunne give problemer, men er det ikke solid state relæer/optocouplers? Der er ingen spoler i den slags. Blot så jeg forstår det, du har en 12V strømforsyning der leverer strøm til PIR og problem-dimmeren? Og så har du en overdragelse fra 12V domænet til 24V IHC domænet vha. nogle 12/24 relæer. Det hele på en eller flere 230V faser men givetvis samme nul leder. Du har problemer på både 12V nettet og 24V nettet og går ud fra at der er kun et problem (hvilket lyder ganske fornuftigt). Bruges din 12V både til forsyning til din LED dimmer og til power til din PIR? Ved du om det bare er en PWM dimmer (jeg har rodet med LED dimming på en Arduino og der bruger man PWM)? For det vil generere nogle kraftige transienter med mindre der sidder fine kondensatorer indeni. Når man switcher DC on/off ved høj frekvens så vil det støje. Hvis det er muligt så ville jeg bruge en anden strømforsyning til LED+LED dimmers end til spænding Dine 12/24V relæer er måske også værd at kigge på. De er fælles på de to domæner. Men ellers ja, en transient beskytter foran begge dine strømforsyninger kunne give mening. Hvis den slags transienter kan passere gennem strømforsyningen. Jeg gætter nu på at transientbeskytteren mere beskytter strømforsyningen end din DC load. Det vil i øvrigt heller ikke skade noget at sætte en stor kondensator på DC siden af strømforsyningen (selvom der allerede sidder en inden i strømforsyningen).

Det lyder som det ingen skade gør og det må være første krav. Din 250 volt varistor kan du med fordel udskifte med en transientbeskytter - jeg tror også de indeholder et lavpasfilter. Du kan købe en færdig dims der kan sidde på en DIN skinne. Hvis du bruger en varistor så husk at kigge på karakteristikken på databladet sådan at du ved den reagerer hurtigt nok. Amerikanere putter transientbeskyttere alle steder - både af "cargo cult" grunde men også fordi deres el-net i visser områder er håbløst. Men jeg har aldrig hørt om nogen der havde behov for den slags i Danmark. Under alle omstændigheder er det lidt svært at vurdere om det vil løse problemet når man ikke ved præcist hvad der er galt. Jeg kan godt forstå du regner med at det er transienter på 230V forsyningen for det er det eneste der umiddelbart er fælles for de to strømforsyninger. Det lyder bare underligt, med mindre du har en stor strømslugende maskine i kælderen og/eller er nabo til en industrivirksomhed. Sidder der noget meget strømslugende på den nye dimmer? Er der nogen forbindelse mellem de to kredsløb? Fx. sidder din 3. parts PIR på IHC controlleren? For så kan den ene strømforsyning i princippet godt påvirke begge kredsløb (alt efter konstruktionen af din 3. parts PIR). Umiddelbart ville jeg tro det var mere sandsynligt at en af de to strømforsyninger havde det skidt. Den slags sker. Sidst vil jeg gøre opmærksom på at jeg godt nok er elektroingeniør og har lært om alt det her i en fjern fjern fortid. Men mit speciale er software og i mindre grad digitale kredsløb. Jeg er på ingen måde expert på det her område.

Ja. Men nu kommer det an på hvad root cause er. Kondensatoren vil gøre at det tager længere tid for spændingen at stige og med lidt held så vil transienten være overstået inden spændingen er steget. Hvor stor kondensatoren skal være afhænger helt af hvad der er af modstand inden i strømforsyningen og hvor lang transienten er. Men når det handler om DC spænding så er reglen: jo større jo bedre når man bruger en kondensator til at håndtere transienter. Det er normalt bedst at placere kondensatoren så tæt på det sted strømmen "forbruges" som muligt. Det er fordi ledningerne i kredsløbet også har en (lille) modstand som er med til at begrænse hvor hurtigt kondensatoren lades/aflades. I princippet kan man bruge en 1F superkondensator - så har man en (lille) UPS om end man kun kan bruge en lille del af kapaciteten fordi spændingen hurtigt vil falde når man skal bruge strøm. Man skal også være opmærksom på at der kan være strøm i kredsløbet efter man har slukket. Det vil nok være en ide at sætte et oscilloscop på og så se hvordan strømforsyningen holder spændingen. Det vil være kedeligt at gå i gang med en masse ændringer før du er sikker på hvad problemet er. Men AC dimmere giver nogle spændende påvirkninger af elnettet. Hvordan det påvirker en switchmode strømforsyning (som IHC strømforsyningen) ved jeg ikke. Men umiddelbart ville jeg mene at en ordentlig switchmode strømforsyning ikke bøt propagere almindeligt forekommende transienter ud på DC siden.

Hvis det blot er kortvarigt så burde en kæmpe kondensator løse problemet. Og hvis det ikke er kortvarigt så er der vist andre problemer ...

Der var ingenting i loggen. Det ville også være en mystisk måde at reagere på. Jeg tror nærmere det er en software fejl fra LK's side. Lige nu er der intet spor af problemet. Hvis det sker igen ...

Jeg har 4 stk. 2 kanal DIN dimmers i min installation. De har fungeret fint lige siden jeg satte dem op (den sidste er termineret etc.). I lørdags begyndte en af dem at opføre sig underligt - men kun den ene kanal på den sidste dimmer i kæden. Den ville ikke tænde, slukke, gjorde det på underlige tidspunkter, etc. Det var 10 dage siden jeg sidst havde lavet ændringer i min IHC installation og ændringen var blot at tilføje endnu et wireless tryk. Ikke noget der burde kunne give problemer. Jeg rebootede controlleren. Det fiksede ikke problemet. Jeg tjekkede programmet (de fleste blokke er hjemmelavede så jeg tænkte at det kunne være en fejl 40). Intet problem der. I nogen situationen tænder dimmeren ved at blokken aktiverer et scenarie som også tænder et wireless relæ. Relæet virkede altid perfekt, så jeg er sikker på at der ikke var fejl på programmeringen. Jeg uploadede programmet igen. Det fiksede heller ikke problemet. Sidst rebootede jeg dimmeren ved at tage strømmen til den. Det fiksede problemet. Andre der er rendt ind i samme problem?

Spændende. Jeg har dog ikke tid og er måske lidt bekymret for ustabilitet i min installation. Jeg oplever at hvis jeg kobler for mange ting på SOAP på min HW 7.1 controller så bliver controlleren ustabil. Jeg kørte på et tidspunkt med kaptajnen, 2 versioner af Home Assistant og OpenHAB og fandt ud af SOAP delen af controlleren crashede. Jeg har således tænkt på om man kunne bygge en form for proxy til controlleren ... har du kigget på noget i den retning? Det kunne også give mening for ældre controllere hvor LK er holdt op med at lave sikkerhedsopdateringer.

Det er ikke nok at den har en fast IP adresse. IP adressen skal også ligge på samme "subnet" som din router og den PC/Telefon/Tablet du bruger når du tilgår controlleren. Eksempel: Hvis din controller har fast IP adresse 192.168.1.3 og din PC har adresse 192.168.0.17 så kan du ikke tilgå controlleren. De kan ganske enkelt ikke se hinanden uanset at de er plugget ind i samme router. Det er en ofte overset ting når der bruges faste IP adresser og håbløst at LK ikke tillader dynamiske IP adresser. Subnet er (i praksis) det samme som de første 3 tal i IP adressen.

Jeg har en Visual 3 controller med 22 wireless stikkontakter og 19 batteritryk. Det kører fint. Den genstarter aldrig. Men mon ikke dine problemer skyldes at der er noget galt med dit program. Hvad det skulle være ved jeg ikke. Men du kunne forsøge at uploade et tomt program til controlleren. Derefter kunne du lave en version af dit normale program der blot indeholder det mest vigtige og køre med det i en periode og se om controlleren stadigvæk genstarter.

Blot for en ordens skyld så er det ikke noget godt argument. Der er intet teknisk til hinder for at lave gode trådløse setups. Det bliver en smule sværere p.g.a. RF delen. Og når det bliver batteridrevet, så bliver det lidt sværere p.g.a. begrænsninger i strømforbruget. Men både bluetooth og mobiltelefoni er gode eksempler på at batteridrevet wireless teknologi kan fungere pålideligt og effektivt så længe man holder sig indenfor de begrænsninger teknologien lægger. Det største problem ved SOHO wireless er at wireless er et delt domæne hvor man deler frekvensen med alle mulige andre. Det er dog i praksis kun et problem når man flytte store mængder data (fx. wifi, mobildata) og der kan kablede løsninger også få problemer (som så løses med TP, shielding, etc.). Ud fra hvad jeg kender til Zigbee teknologien så er der intet til hinder for at det kan fungere effektivt og pålideligt. Det ændrer selvfølgeligt ikke på at man kan købe Zigbee produkter der ikke fungerer ordentligt.

Når folk vil have et trådløst setup, så er det fordi det er mere fleksibelt. Det er de færreste der har adgang til at trække nye kabler fordi de har brug for en ekstra PIR eller en ny betjeningsknap. Wireless kan virke rigtigt stabilt hvis man håndterer problemer omkring range og stabilitet. Zigbee løser det problem ved at man for billige penge kan få en zigbee router i hvert rum. Det er i mine øjne en rigtigt fornuftig løsning. Trådløst setup behøver ikke være uden logik. IHC Wireless er et godt eksempel på at man fint kan integrere custom logik ind i et wireless setup. Og det kan man også med Zigbee. Der er bare ikke nogen der har et kommercielt produkt der kan gøre det nu. Som jeg ser det behøver man ikke bruge Schneiders Wiser/Zigbee FUGA enheder sammen med en Wiser gateway. Hvis det er Zigbee devices så kan de kobles sammen med lige præcist den "controller" man har lyst til. Med alt den logic controlleren giver mulighed for. Min oplevelse er at LK har haft 3 store investeringer i IHC: TermIHC: Design af tryk, controller, databus produkter Visual 1: Nyt programmeringsmiljø, ny controller hardware platform Visual 2: Wireless, ny controller hardware platform, rewrite af programmeringsmiljø (i Indien?) Visual 3 er blot et port af controlleren til ny hardware med minimale ændringer af softwaren. Jeg har svært ved at se LK smide penge i større udvidelser af softwaren. Det er simpelthen for dyrt i forhold til hvor få controllere der er solgt. Som det er nu kan de lave nye controllere baseret på næste Linux version + næste java version + ny ARM platform hver 3-4 år. Største udgift er nok at holde wavenis stakken i live. Samlet kan det nok beskæftige en/to mand og det er nok hvad der er penge til. At integrere andre produkter ind i controlleren ville kræve store investeringer både på hardware og software siden. Hvis IHC controlleren skulle være levedygtig på langt sigt så skal hele programmerings oplevelsen forbedres: Bedre editor, bedre debugging, modularisering, mere kodegenbrug, flere datatyper, netværksadgang, etc. Før man ved af det står man med et fuldt "programmeringssprog" med tilhørende IDE. Hvis man kunne sælge sådan en controller til resten af europa så ville der være penge i det ... ellers ikke.