
Lars1
Members-
Antal indlæg
3.794 -
Medlem siden
-
Senest besøgt
-
Days Won
111
Indholdstype
Profiler
Forummer
Downloads
Galleri
Alt der er opslået af Lars1
-
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.
-
At du sammenligner en business case på en multi-controller som kan afvikle LK IHC programmer og give adgang til ZigBee, Z-Wave, LK IHC wireless og LK IHC RS485, med en simpel gateway, baseret på eksisterende I/O moduler viser ret tydeligt at du ikke har forstået hvad mit forslag går ud på. Der er en KÆMPE forskel i udviklings omkostningerne ved de 2 løsninger, og en KÆMPE forskel i det potentielle marked. Specielt hvis går med den lille variant med 2 data linier for input og 4 for output.
-
Jeg vil slet ikke have plads i min tavle, hvis jeg skulle erstatte alle mine LK IHC I/O moduler med jeres tavle moduler. Et LK IHC input modul med 16 indgange fylder 2 M36 enheder. Et output modul med 8 udgange det samme. I.flg. databladet på jeres ZIF5028 er det 105mm bredt hvilket er lige under 3 M36 enheder (i skriver 6 i databladet), men i har kun 6 indgange og 6 udgange på den plads. Da jeg har næsten dobbelt så mange indgange som udgange i min installation, vil jeg skulle bruge 2-3 UG18'er mere.
-
Typisk sælger snak. Du glemmer fuldstændig den integration mellem tingene som er kende tegnet ved en LK IHC installation. En gradvis overgang, som du beskriver her, uden gateway, vil medføre at lyset ikke slukker i hele huset når alarmen bliver slået til, at temperaturen ikke sænkes når huset sættes i ude tilstand o.s.v. o.s.v. o.s.v. En gradvis overgang kan altid lade sig gøre hvis man er indstillet på at tingene ikke længere hænger sammen. Hvis de skal hænge sammen under den gradvise overgang, så kræver det en gateway mellem det nye og gamle system. Man har ikke investeret i et LK IHC system for at få svagstrøms styring af sit lys. Man har investeret i det for at få fordelene af sluk alt, ude, hjemme, aften, nat scenarier, integretet alarm, varmestyring og lys styring m.m.
-
Jeg er slet ikke sikker på at det er så store summer der skal investeres for at lave en gateway, baseret på et af jeres eksisterende I/O tavle moduler. Men det kan selvfølgelig være at jeres modul er så tåbeligt designet at det er nærmest umuligt at bruge det til andet. Det har alle dage været LK IHC's store force at grund designet har været extremt flexibelt. Ellers vil det ikke have overlevet stortset uændret i mere end 30 år. Ja det er ret tydeligt at du er sælger. Jeg synes dog det er sørgeligt at i ikke engang vil kigge på om det er muligt at lave en gateway og hvad det vil koste, men bare skyder det ned fra starten. Du skriver at der er 60.000 IHC installationer. Hvis i laver en gateway med 8 dataliner til input moduler og 16 dataliner til output moduler (matcher en LK IHC controller) og prissætter den til 7.000 kr (prisen på Visual 3 controller, da den fortsat kunne købes), så vil i nok ikke sælge mere end et par 1000. Men hvis i laver en gateway med f.eks. 2 datalinier til input moduler og 4 til output moduler og pris sætter den til 1.500 kr. (prisen for jeres tavle I/O moduler), så vil jeg ikke blive overrasket hvis i sælger mindst ligeså mange som af jeres tavle I/O moduler. Nu er LK IHC jo heldigvis uhyggelig stabil. Der køre stadigvæk mange installationer med TermIHC controller fra 80'erne. Det som plejre at stå af er strømforsyningen, og den kan erstattet med en hvilken somhelst 24V størmforsyning som kan levere 72W eller hvad der nu er behov for. Visual 3 controlleren har ry for at være ustabil, men medmindre man har LED dimmer, kan den erstattes af en Visual 2 controller og dertil komme at hvis man har sørget for at få den opgraderet til seneste firmware, så er den faktisk næsten ligeså stabil som en Visual 2 controller. Kortsagt. Der kan gå RIGTIGT mange år før man får problemer med sin LK IHC installation og er tvunget til at skifte.
-
LK IHC alarm er ligesom stortset alt andet LK IHC baseret på digitale ind og udgange. Man tilkobler ganske simpelt en røgmelder med en relæ udgang til en digital indgang på et LK IHC input modul. Det samme gælder for alarm PIR. Sirenen tilkobles et LK IHC output modul. Et batteri backup modul er ikke andet en en UPS på 12 og 24V strømforsyningen. Den kan faktisk også bruges til at sikre strømforsyningen til jeres 12 og 24V moduler. LK IHC er designet tilbage i 80'erne, og har alle dage været bagud kompatibel, således at de I/O moduler du købte sammen med din TermIHC controller (første generation af LK IHC controller), fortsat kan bruges sammen med den sidste generation af LK IHC controller (Visual 3) Input modulerne findes i flere udgaver, men de har alle 16 indgange og kommuniker alle på samme måde med LK IHC controlleren. Forskellen er hvor meget strøm de kan levere på en indgang (er 0V styret ligesom jeres tavle I/O moduler) samt og det er 24V eller 230V indgange. Output modulerne findes også i flere udgaver, men har alle 8 udgange og kommuniker alle på samme måde med LK IHC controlleren. Forskellen er hvor meget strøm de kan levere på en udgang, om det er 24V eller 230V indgange eller om udgangene har fælles forsyning eller er galvanisk adskildte.
-
Hvis det virker og controlleren er stabil, er der ikke nogen speciel grund til at opdater firmware. Du løser ikke nogen af Java og certifikation problemerne med en "ny" firmware, da de alle er så gamle at alt er udløbet i dem. Hvis du vil opdater firmware, så check trådene omkring det. Du kan godt opdater en HW 6.1 controller uden viewer med nyeste Visual 2 firmware, men det skal gøres på en speciel måde.
-
En gateway vil i mine øjne aldrig tjene som andet end en overgangs løsning. Det giver ikke mening at bruge en gateway i en ny installation, men som overgangs løsning giver det RIGTIG meget mening, og jeg tror på at det er et stort marked for sådan en gateway, og at dem som kommer med sådan en gateway, vil være foran på point når resten af installationen skal erstattes med noget andet. Medmindre du bruger LED dimmer, så kan du erstatte din Visual 3 controller med en brugt Visual 2 controller. Jeg er på ingen måde overrasket over at Schneider lader alle deres IHC komponenter udgå efterhånden som de bliver udsolgt. Det har været deres strategi siden Visual 3 controlleren blev frigtivet. Faktisk er jeg mest overrasket over at de overhovedet frigav Visual 3 controlleren.
-
Jeg håber du har hentet projektet med Visual og ikke Sceneview. Det er 2 forskellige projekter. Sceneview er intet værd uden Visual projektet. Via Visual er det også muligt at have flere versioner af projektet liggende på sin PC. Men alt det kan du læse MEGET mere om i den vejledning som er blevet installeret på din PC samme med Visual.
-
Hvis den har USB, har den også netværks stik. Det sidder for neden på controlleren under tavle afdækningen. Både Visual 2 og 3 virker med windos11, incl USB adgang.
-
Tak for linket. Jeg har været ramt af problemerne med den underlige opførsel, men de har nu kørt over 1 år uden problemer. Løsningen er tilsyneladen at firmware opdater alle dimmer samtidig med samme firmware 2-3 gange i træk. Flere gange hvis du har mere end 3 dimmer. Det var i hvertfald sådan at jeg løste mit problem. At dekode RS485 protokollen, vil nok kræve noget mere arbejde end at sætte et oscilloscop på en data forbindelse og se bit mønsteret. Nok derfor ingen endnu har kastet sig over opgaven. Men hvem ved. Måske er der nogen som får blod på tanden, nu hvor der ikke længere er en LK IHC controller på marked.
-
Jeg er ret sikker på at han mener både IOS og Android app's. De kommuniker såvidt jeg ved på samme måde med LK IHC controlleren. Men vær opmærksom på at p.gr.af de udløbede certifikater og forældede krypterings protokoller i LK IHC controllerne (både Visual 2 og 3), så er det ikke sikkert at du kan får app's til at virke da både IOS og Android pr. default ikke understøtter udløbede certifikater og forældede kryopterings protokoller.
-
At noget ikke findes er ikke ensbetydende med at det ikke kommer i fremtiden. Sålænge der var en LK IHC controller på marked, var der ikke rigtigt noget marked for alternative gateways da de det vil kræve MEGET reengineering at få dem til at kommuniker med LK IHC wireless og RS485 bussen. Nu er controlleren væk, så nu er der et hul i marked for en LK IHC gateway som kan kommuniker med LK IHC I/O moduler. Hvis vi tager et af Logic Group's I/O tavle moduler som udgangs punkt, så kan hovedparten genbruges. Det er kun selve ind og udgangs delen som skal redesignes, således at i steddet for en fysisk ind/udgang, så er det en data port med 16 indgange eller 8 udgange pr. port. En sådan gateway vil gøre en konvertering af 90% af alle LK IHC installationer til en økonomisk overkommelig opgave, og muliggøre en gradvis udskiftnign. Der er IMHO et stort marked for den som kommer først. For 10-15 år siden var der faktisk en LK IHC bridge på marked. Den var den del af produktet Elektronic Housekeeper. Produktet havde en kort levetid, da det var baseret på Z-Wave, men mange af hans komponenter var ikke kompatible med andre Z-Wave komponenter og så var det baseret på en abonnements ordning og krævede konstant internet adgang for at virke. Dertil kommer at supporten var ikke eksisterende, som det kan ses i denne tråd. https://www.ihc-user.dk/forum/forums/topic/1680-housekeeper/#comment-11339 Jeg kan ikke huske hvordan han kommunikerede med LK IHC, men jeg er ret sikker på at det ikke var via netværks interfacet. Hvis du søger på housekeeper her på boardet, vil du finde et par tråde om emnet, men ikke nogen reel brugbar information desværre. Jeg kender ikke Schneiders planer, og havde ikke mulighed for at deltage i deres Q&A møder. Men de har i flere år sagt at de arbejder på en gateway mellem LK IHC og Wiser samt KNX. Derudover sagde de allerede da Visual 3 controlleren blev frigivet at det vil være den sidste LK IHC controller. Jeg tror det eneste som er kommet bag på Schneider er hvor hurtigt Visual 3 controlleren blev udsolgt. Deres plader om godkendelser er noget ævl. Det er interne godkendelser som mangler. De eneste eksterne godkendelser de har brug for er til CE mærket. Markeds standarder er også noget ævl. De havde ikke noget problem med at frigive Visual 3 controlleren, selvom den LANGT fra levede op til datiden markeds standarder. At lave en Wiser/KNX gateway som også kan kommuniker med LK iHC wireless og RS485 bus er en større opgave end at finde erstantning for de komponenter som er udgået i den eksisterende controller.
-
Heldigvis har jeg kun brugt wirelesss til dimmer, og nogle enkelte mobile stikkontakter. Ligenu er jeg ret glad for min skeptis overfor wireless. Har du et link? Jeg har forsøgt at finde det, men det er ikke lykkes mig.
-
Jeg kunne teoretisk nøjes med 1 controller, men jeg valgte ret tidligt at bruge 1 controller til alarm og varme styring og 1 til resten.
-
Nu kan LK IHC meget andet end at styre lyset. Jeg har f.eks. både brand og indbruds alarm via LK IHC samt varme styring. Alene mine telestater koster 16 udgange. Dertil kommer 8 udendørs PIR, 12 brand melder m.m. Så nej jeg har ikke behov for 60 Matrixer. Kun ca. halvdelen af mine I/O moduler bruges til lys. Resten er til røgmelder, indbuds pir, temp. sensor, ledelys LED på tryk, telestater m.m. Min installation er uden tvivl en af de større, men langt de fleste LK IHC installationer har mindst 4*16 indgange, 8*8 udgange + tryk, røgsensor, PIR, temp. sensor, wireless m.m. Selv små installationer har ofte hardware for +10.000 kr. når man tæller alle tryk, I/O moduler m.m. med. Det er ret mange penge at smidde i skralde spanden, plus at man skal ud og købe nyt. Jeg kommer næppe selv til at købe en, men hvis i lavede en alternativ version af et af jeres moduler, hvor man kan tilslutte x antal LK IHC I/O moduler, så tror jeg der er mange som vil vælge jeres produkter når de engang skal konverter. Som jeg tidligere skrev er kommunikationen med I/O modulerne en simpel bit strøm, som bør være relativ nem at afkode. Jeg har nogle ideer til hvordan det kan laves. Dem deler jeg gerne med jer hvis i er interesseret, men det er for komplekst at gøre i en tråd som denne. Bl.a. måden LK IHC temp. sensor tilsluttes kan drille, men jeg har en idee til hvordan det løses.
-
Jeg har arbejdet professionelt med IT i over 20 år og set MANGE forskellige løsninger både med kablet systemer og wireless systemer. Der er selv den dag i dag LANGT færre problemer med kablede systemer. Wireless er flexibelt hvis du lige skal flytte en afbryder, men hvis du skal flytte noget som kræver mere strøm end en afbryder, så skal du alligevel til at trække kabler. Derudover vil jeg ikke kalde wireless simpelt. Specielt for kommunikation mellem tavle komponenter giver wireless INGEN mening for mig. Slet ikke når disse er forbundet til tryk rundt i huset via kabler. Man har i såfald valgt det værste af 2 verdener. Men lad nu den diskution ligge. Jeg tvivler på at vi nogensinde bliver enig. Jeg er oprindeligt udlært elektriker tilbage i 1999 og lavede dengang bl.a. installationer med LK IHC. Jeg har selv haft LK IHC i samtlige mine boliger de sidste 25 år. Det er først med LK IHC visual 3 controlleren, at jeg har set controller stå af. Billedet er det samme for stortset alle andre tilsvarende produkter som findes på marked idag. Jeg har tilgengæld set RIGTIGT mange problemer med wireless enheder både LK's og andre. Det er ganske rigtigt ikke hele huset som er mørklagt, men jeg skal hilse og sige at det er pænt irreterende når lyset ikke kan tænde midt om natten fordi der IGEN er problemer med den wireless kommunikation mellem controlleren og wireless enheden. At en controller står er er muligt, men ikke et særligt realistisk scenarie. Det er langt mere realistisk at et eller andet forstyre den wireless kommunikation, hvilket er fuldt ud ligeså irreterende som hvis controlleren giver op. Der er ikke megen protokol over kommunikationen mellem en LK IHC controller og et I/O modul, eller I/O modul og LK IHC/Zigza temp. sensor. Det er en simpel ukrypteret standard bit strøm med start/stop bit og paritet. Den præcise opsætning kan jeg ikke huske, men der var en som afkodede kommunikationen via et osciloskop for nogle år siden. LK IHC SMS modem og LK iHC LED dimmer derimod er en anden sag. Der er der tale om kommunikation via en RS485 bus, så der er der tale om en reel protokol. Hvis i havde en gateway, som kunne forbindes til LK IHC I/O modulerne og f.eks. OpenHab, så kan jeg spare 50-100.000 i nyt udstyr når jeg engang skal erstatte min LK IHC installation. Jeg har pt. 2 LK IHC controller 15 input moduler med hver 16 indgange 20 output moduler med hver 8 udgange 15 temp. sensor 6 LED dimmer 8 wireless dimmer (nødløsning for at kunne % styre lysniveauet) og så det løse som jeg har glemt i farten.
-
Jeg ønsker slet ikke wireless. Wireless er IMHO en nødløsning og en evig problem kilde. Dette gælder ikke bare LK's wireless produkter, men RIGTIG mange andre wireless produkter, incl. wireless ethernet, mobil tlf. etc. Et tryk skal ikke have nogen anden funktion end at reager på et tryk. Resten programmers i en controller. At sætter dimmer m.m. i et tryk gør dem bare dyre, når der ikke er brug for dimmerne. LK's LED dimmer styres desværre via en RS485 bus med LK's proprietær kommunikations protokol. Men hvad med deres I/O moduler. Du skriver til Bjarne at LK IHC temp. sensor funger sammen med jeres system. Eftersom de kommuniker med en simpel bit strøm og LK IHC I/O moduler kommuniker på sammen måde, kan man så også bruge LK IHC I/O modulerne med jeres system?