Lars1

Jeg tror ikke det specifikt er z-wave som der er berørings angst for. Vi er bare nogle som har en del erfaring med wireless kommunikation. Wireless kommunikation er bare ikke så stabilt som kablet kommunikation, ligegyldigt hvilket produkt du vælger. Problemerne bliver særligt tydeligt jo større din installation bliver.

@Bill CHvad der sker hvis en IHC controller dør, afhænger lidt af hvordan den dør. I de fleste tilfælde vil der ske det at det som er tændt da den dør fortsat vil være tændt og det som er slukket fortsat vil være slukket, men der kan også sket andre ting. Specielt hvis den dør i forbindelse med en strøm afbrydelse. Så vil du ofte opleve at alt er slukket. Men som Bjarne skriver. LK IHC er et MEGET stabilt produkt. De installationer som blev lavet for snart 30 år siden, køre ofte fortsat med de komponenter som blev installeret dengang. Også selvom de måtte være blevet opgraderet med nye controller undervejs. Det vil ofte være de samme I/O moduler som blev installeret oprindeligt. Schneider har flere gange sagt at der ikke kommer nogen ny LK IHC controller. Så hvis du ikke kan få fat i en brugt hvis en af dine controller skulle dø, er det hele din IHC installation som skal udskiftes. Dine I/O moduler m.m. kan ikke genbruges. Jeg har listet nogle forskellige alternativer i FAQ tråden om LK IHC EOL. Kip relæ løsningen er helt klart den billigste og kan sikkert laves for under 10.000 kr. En løsning som giver dig samme funktionalitet som idag vil med 2 LK IHC controller nemt løbe op i 50-100.000 kr.

Jeg kender ikke detaljerne i hvordan det er lavet, men i princippet burde der ikke være noget i vejen for at gøre begge dele, bare ikke samtidig. Det er bare et spørgsmål om at rette koden til. Jeg kan dog ikke helt gennemskue om det kræver et Arduino board pr. I/O modul eller om flere moduler kan tilsluttet samme board. Et er dog sikkert. Hvert I/O modul kræver sin egen fysiske ind/udgang på Arduino boardet da kommunikationen er simpel bit strøm. Korrekt, men efterhånden som LK IHC installationerne udskiftes, må man forvente at brugt marked bliver oversvømmmet med brugte I/O moduler, og disse holder nemt 30 år.

Bruger du ikke de 2 LED's i programmet, kan du undlade at konfigurer dem, men for overblik og dokumentation bør de konfigureres hvis de er tilsluttet en udgang.

Der ligger links til kommunikationen mellem LK IHC controlleren og I/O modulerne i bunden af FAQ tråden om IHC EOL. Det bliver svært at få en PLC til at tale direkte med LK IHC I/O modulerne. Du bliver nok nød til at have Arduino eller tilsvarende imellem, men det kræver så en PLC med netværks interface, og disse er IKKE billige.

Jeg har ingen erfaring med Arduino, men efter at have kigget lidt på deres website samt i den gamle Arduino tråd, kan jeg se at nogen har lavet integration mellem LK IHC og Arduino. Linket til hans kode virker dog desværre ikke længere. På OpenHab's website er der derudover links til hvordan man kan kommuniker mellem OpenHab og Arduino. Der er også lidt det samme på HA's website. Så teoretisk burde det være muligt, men ligesom Astronaut stoler jeg ikke nok på hverken OpenHab eller HA til at lægge min lys styring m.m. i hænderne på dem. Jeg bruger alene OpenHab til data opsamling og web/app bruger interface. Den kommer ALDRIG til at overtage det program som ligger i min LK IHC controller. Det er dog også muligt at lave noget kode direkte i Arduino, men jeg kan ikke gennemskue hvor mange LK IHC I/O moduler man kan tilslutte pr. Arduino board, samt om man kan kode på tværs af dem. Hvis du laver koden i Arduino vil du have noget som ligner programmet i LK IHC controlleren, og sandsynligvis have nogenlunde samme stabilitet.

Jeg ønsker ikke at dette skal føre til en længere diskution, men som jeg skrev i mit indlæg, var der flere ting i dialogen som gør at jeg mistænker at der er tale om varme vare. Men eftersom jeg ikke offentliggør private samtaler, kan jeg ikke dele hvad det specifikt er som gør mig mistænksom. Bortset fra det er jeg selv ofte i Wien, så at du bor der er faktisk ikke noget problem i forhold til personlig afhentning. Men alt dette er lidt ligegyldigt da jeg som skrevet er i tvivl om hvorvidt der er tale om varme vare eller ej.

LK har nu lavet et nyhedsbrev man kan tilmelde sig. Man skulle så få nyheder vedr. alternativerne til LK IHC og hvad der ellers ske på LK IHC området. https://forms.office.com/Pages/ResponsePage.aspx?id=reFRbkvFOUu1mA_-muaP75nTbeFzOPNPpOLWZfeYF3tUNFdKNEtKTVBVUlhOMVY2VlkzVEROS1VaMS4u&mkt_tok=MTc4LUdZRC02NjgAAAGOkuMlS4LEdDBxipFvsq4r_0rbUxcWxNbLkGuA-o_mPxlFh1m9P0yqsmqZ8bBQ5tdbCEGF8tsgcebcyQ1iamdBXT9A_-ocleH--fYRcOgLNn8BmqWAm0rG

Såvidt jeg husker er der ikke noget viewer modul til Visual 1. Visual 2 kom i 2 udgaver. En med indbygget viewer og en uden. Til den uden kunne må få et viewer modul så den kunne opgraderes uden at skulle skifte hele controlleren.

Tror bare at folk er optaget af et par andre tråde. Til LK IHC kan du bruge en hvilken somhelst PIR som har en galvanisk adskildt udgang. Uden galvanisk adskildt udgang kan du bruge en hvilken somhelst PIR som kan tilsluttes samme 24V eller 230V forsyning som LK IHC installationen og som har en udgang som i ON tilstand er forbundet til 0V. Er den forbundet til 24V eller 230V skal der et overdragelses relæ i mellem.

En hurtig søgning på pricerunner vise at flere webshops fortsat har LK IHC lyssensor på lager. Men inden du helt dødsdømmer din nuværende sensor, så check lige at den er monteret korrekt i soklen. Såvidt jeg husker skal den vippes ind for oven først for at få ordentlig kontakt. Jeg har været tæt på at dødsdømme 4 PIR indtil det gik op for mig at de ikke sad ordentligt i soklen. Hvis den fortsat ikke virker bør du prøve at pille den ned og tilslutte den direkte med max 1M kabel til en anden indgang. 9 ud af 10 gange er det dårlig forbindelse eller kabel fejl, som gør at sensoren ser død ud. Ender du med at skulle skifte solsensoren, så har du et par alternativer. Den Niko sensor som du nævner her kan ikke erstatte LK IHC solsensoren 1-1 da Niko sensoren sender et 0-10V signal, mens LK IHC solsensoren sender lux værdien som en digital værdi via en kommunikations protokol. Om du kan tilslutte Niko sensoren til 0-10V output modulet ved jeg ikke. Du bliver nød til at undersøge nærmere om 0-10V modulet forventer en digital værdi, et 0-10V signal eller et on/off signal. Det billigste alternativ er imidlertid nok at anskaffe en alm. solsensor som har et galvanisk adskildt udgangs relæ. Denne udgang kan du forbinde til en indgang på et LK IHC input modul og får nu et on/off signal alt efter om solen er oppe eller ej. Det vil så kræve lidt LK IHC programering, men det gør din forslåede løsning nok også.

Der er mange som nævner faren ved at binde sig til et proprietært produkt som kun ejes og produceres af 1 producent. I den forbindelse skal man lige huske på at LK IHC har været på marked i mere end 30 år og at de I/O moduler m.m. man købte da produktet blev lanceret for +30 år siden kunne bruges sammen med samtlige controller som er kommet på marked i de +30 år. I den anden grøft er systemer baseret på åbne protokoller som KNX, Z-Wave, Zigbee m.fl. Her er problemet ikke så stort hvis en producent trækker sig fra marked, men tilgengæld har man udfordringer med at man sommetider løber ind i at produkter fra forskellige producenter ikke kan tale sammen, eller at produkter som er +10 år gamle ikke altid kan tale med nye produkter. Specielt Z-Wave har for år tilbage været hårdt ramt af dette.

Det er jeg ikke enig i. Der er 2 metoder beskrevet i min FAQ om LK IHC EOL. Den ene er at erstatte hele IHC installationen med kip relæer. Den anden er at koble LK IHC I/O modulerne sammen direkte par vis. Så vil de såvidt jeg ved funger som kiprelæer.

Mig bekendt er Wiser, Schneiders globale satsning på home automation marked. Det giver ganske simpelt ikke menning hvis de har udviklet Wiser kun for det danske marked når de allerede havde LK IHC. Når det er sagt, er jeg enig i at det er lukket system og at der er lang vej før de har samme produkt bredde som LK IHC eller deres konkurrenter.

Ikke helt. Z-Wave kan best sammenlignes med LK IHC wireless standalone. Her pare du også de enkelte enheder uden controller. Ved ren LK IHC wireless, giver LK IHC controlleren dig bare mulighed for at lave komplekse ting som i Z-Wave også kræver en HC3 controller eller tilsvarende. Hvis en controller understøtter både Z-Wave og ZigBee, så er det vel muligt via af den at lave noget som ligner en parring mellem enheder på de 2 protokoller?

Sendt dig en PM.

Pointen er at typehus firmaer m.m. traditionelt har gjort meget ud af at bringe omkostningerne ned, og har derfor ofte sparet afbryder dåsen væk, når de har lavet et hus med LK IHC. Det vil give problemer hvis man skal skifte til Matrix afbryder fra Logic Group. Om det er smart eller ej er en anden diskution. Hos mig er alt lavet med rør og dåser, således at jeg kan skifte kabler og afbryder/udtag uden at skulle have hammer og mejsel eller sav frem.

Jeg tror slet ikke du har læst hvad jeg og andre har skrevet. Vi er ikke ude efter en ny LK IHC controller, eller at i skal lave løsninger baseret på Lk IHC. Vi er ude efter en gateway, så overgangen fra LK IHC til noget andet kan gøres gradvist over 5-10 år. Det er de færreste af os som har 50-100.000 som vi lige kan smidde efter en one shot udskiftning. Gatewayen skal ses som en dør åbner for at i kan komme ind i en LANG rækker transitions projekter, som ellers vil være lukket land da de simpelthen er for dyre i forhold til at erstatte LK IHC installationen med en stak kip relæer, hvilket er hvad der vil ske med RIGTIGT mange LK IHC installationer efterhånden som de går i stykker. Gatewayen handler netop om at giver Z-Wave adgang til eksisterende LK IHC I/O moduler så man gradvist kan skifte til noget andet. Den handler ikke om at give Z-Wave adgang til LK IHC controlleren, andet LK IHC udstyr eller være en ny LK IHC controller. Udover det, så kommer nye LK IHC lnstallationer ikke på tale, da Schneider allerede har sagt offentligt at når det eksisterende lager af LK IHC komponenter er udsolgt (både wired og wireless), så udgår de af Schneider's produkt katalog. Sålænge du ikke har hørt hvad min idee til en gateway går ud på, så kan du ærligt talt ikke udtale dig om hvorvidt der er en god business case eller ej. Med min idee til en gateway, vil i have grundlaget for en billig udvikling af tavle moduler fremad rettet, og sandsynligvis kunne spare en del i licenser og udgifter til z-wave chips m.m. samt forenkle jeres produkt portefølje. Alt sammen uden at skulle lave en controller, eller gå på kompromis med jeres fokus på Z-Wave. I vil sågar få en løsning, hvor i også vil kunne angribe Carlo Gavazzi installationer. Men som jeg tidligere skrev er det for komplext af forklare i en tråd som denne. Sidst men ikke mindst. Jeg er ikke fustreret over at Schneider dropper LK IHC. Det har været offentligt kendt at det gik den vej siden de trak LK IHC fra alle markeder uden for Danmarks grænser. Derfor har mine investeringer i LK IHC også været meget begrænset de sidste mange år, og primært været fokuseret på selv at have et reservedels lager. Skulle jeg nå i den situation at alle mine controller dør, så vil jeg i første omgang lave IHC standalone ved at koble LK IHC I/O modulerne direkte sammen, og i næste ombæring erstatte dem med kip relæer. Med en gateway kunne jeg meget vel overvejer at kigge på Z-Wave, selvom jeg vil gå langt for at undgå wireless. Uden gateway kommer det IKKE til at ske. Sådan tror jeg der er mange andre som også tænker.

Mere og mere tyder efterhånden på at hvis ikke Allan selv har fået idee'en, så er det ikke noget som kan lade sig gøre og ikke noget som er værd at bruge tid på. Med en sådan holdning er det et spørgsmål om tid før hans firma lider samme skæbne som LK IHC, eletronic housekeeper etc.

Når du har sparet trækrørne væk, har du så også sparet dåserne bag svagstrøms trykkene væk, som mange typehus firmaer har gjort når de har lavet huse med LK IHC. Uden dåsen bliver det svært at få plads til en Matrix.

Prøv at kontaktet @Henning PedersenHan lever af at programmer bl.a. IHC såvidt jeg ved.

Jeg har lidt svært ved at se hvad begrænsnigner i brugen af FUGA designet, har at gøre med at grund designet i LK IHC er så stærkt at det har holdt i mere end 30 år og at alle 4-5 generationer af LK IHC controlleren har været bagudkompatibel og kunnet supporter samtlige komponenter fra tidligere generationer af LK IHC. Og selvom at FUGA desigenet har været beskyttet frem til 2012, så er det alligevel mere end 10 år at LK IHC har overlevet trods konkurrenternes adgang til FUGA.

Hvis jeres nuværende processor ikke kan klare bit strømmen fra en LK IHC/Zigza temp. sensor eller et LK IHC I/O modul, så har i et seriøst problem. Som vi har skrevet flere gange er der tale om en simpel bit strøm som kan afkodes via et oscilloscop. Der er ingen kryptering eller andet andet kompleksitet. Faktisk snakker vi kommunikation på lag 2 i OSI modellen. Det er fair nok at i ikke vil bruge tid på en gateway, men så værd ærlig og sig at i ikke vil bruge tid på det, fremfor at komme med søgte argumenter om dårlig business case m.m. Enhver med bare lidt indsigt i produkt udvikling kan hurtigt gennemskue at det er en sælger som har afvist gateway'en uden at spørgsmålet nogensiden har været forbi produkt udviklings afdelingen. Jeg kan virkelig ikke forstå hvorfor i ikke vil lade jeres tekniker bruge 1/2-1 time sammen med en af os nørder som kender LK IHC og har nogle ideer til hvordan en gateway kan strikkes sammen og markedsføres.

Jeg er udemærket klar over at der produktions mæssigt ikke er den store forskel på om der er 2 eller 8 indgang på en gateway. Men som sælger burde du vide at der salgsmæssigt en STOR forskel på om der er 2 eller 8 indgange. Det er meget nemmer at sælger 4 gateways med 2 indgange til 1.500 kr. end 1 gateway med 8 indgange til 6.000 kr. Dermed vil det være meget nemmer at få en business case til at hænge sammen hvis man laver en lile gateway med 2 indgange frem for en stor med 8. Min ide til hvordan en gateway skal strikkes sammen, bygger langt af vejen på genbrug af designet på jeres eksisterende I/O tavle moduler. Så i skal netop IKKE skal ud og invester i nye støbe væktøjer m.m. Der er alene tale om at printet og softwaren er anderledes end i de I/O tavle moduler i idag har til salg.

WIFE faktoren på jeres Matrix tryk er for lille til at de nogensinde vil blive aksepteret i mit hus.