Lars1

Det er ganske rigtigt et problem, som har været diskuteret meget. En del af problemet er at der kan være flere fejl kilder. F.eks. hvis dine dimmer ikke er HW ver 2.0 skal du være 100% sikker på at du har belastning nok på alle dimmer, ellers kan det give kommunikations problemer. Hvis du har sluk alt, eller anden FB som styre flere dimmer, har det også betydning i hvilken rækkefølge dine dimmer er linket til sluk alt FB'en. Årsagen til dette er at kommunikationen sker med 1 dimmer af gangen i den rækkefølge de er linket. Er der problemer med 1 dimmer, bloker den for kommunikationen med de andre indtil den timer ud, som vist nok er over 1 min. Når den endelig timer ud, er tiden også udløbet for de andre dimmer, så de når aldrig at få sluk alt signalet. En trejde ting er hvis dine dimmer sidder for tæt. Jeg fik på et tidspunkt at vide at der skulle være 1M mellem dem. Om det holder vand ved jeg ikke, men det er et kendt problem at radio signaler kan forstyres hvis flere sender sidder for tæt sammen. Og dimmerne sender jo et handling udført signal tilbage, når de har udført den ønskede handling. Controlleren fortsætter ikke med den næste dimmer, før den har fået dette ok signal tilbage.

Fugt/temp. og temp/temp sensorne kan fortsat købes i alm. handel. LED dimmer og lux/temp. sensor er desværre udgået og tilsyneladen udsolgt.

27VDC er lidt højt, så man får en elektriker til at verificer at controlleren rent faktisk får 24V og er død. Er det en Visual 3 controller kan den ombyttes. Om det også kan lade sig gøre med en ældre controller, nu hvor LK er meget tæt på at frigive deres nye KNX controller til LK IHC installationer ved jeg ikke, men det kan jeres elektriker også undersøge. Ellers er alternativerne at se om man kan finde en brugt LK IHC controller, eller at prøve at kontakte teamet bag Revo controlleren, og høre dem om det er mulig at komme med i deres test program. De har et par tråde her på boardet.

Hvis i laver en søgning her på boardet, er jeg ret sikker på at der vil dukke et par Visual 1 program filer op. Det sker fra tid til anden at nogen har uploadet et program, for at få hjælp til et problem. I vil nok finde flest Visual 2 filer, men jeg er ret sikker på at der også er Visual 1 filer imellem. I skal dog nok nogle år tilbage for at finde nogen.

Hvis du har ledige 230V udgange, kan du jo bare styre Shelly dimmeren på samme måde som du nu styre dine Uni400 dimmer via 24V udgange.

Jeg er ikke helt med på hvad du leder efter. Du skriver at dimmeren skal være svagstrøms styret, men samtidig skriver du at den skal være Zigbee kompatibel hvis muligt. Når du skriver svagstrøms styret, går jeg udfra at du mener kablet med 24V signaler til at styre dæmpning. ZigBee er ren wireless. Jeg vil ikke afvise at der findes en dimmer som understøtter begge muligheder, men jeg tvivler. De produkter som findes til ZigBee eller ZWave er typisk rene wireless produkter, medmindre du går efter et brand, som også har en controller i deres sortiment.

I dit screenshot, kan vi ikke se hvad du har linket til de forskellige indgang i dit program. Fejlen kan ligge der. Jeg ved ikke hvad du mener med at det ser helt forkert ud når du måler med et multimeter. Men det er ikke unormalt at måle spænding på et langt kabel i slukket tilstand. Det skyldes induktion fra andre kabler m.m. Om tingene er monteret korrekt i brønden, bør du får en elektriker til at checke. Det er simpel elektriker arbejde, som enhver elektriker bør kunne gennemskue.

Den kunde gruppe som ønsker MQTT/Modbus og den kunde gruppe som bare ønsker status quo, er 2 MEGET forskellige kunde grupper, med 2 MEGET forskellige ønsker. Dem som gerne vil have MQTT/Modbus integration, vil også forvente at de kan lave alt kritisk kodning i REVO controlleren, uden fortsat at skulle have Visual (som iøvrigt ikke længere er supporteret) installeret. Jeg tror desværre ikke at i kommer uden om en eller anden form for programmerings værktøj hvis i vil have held med denne mål gruppe. Det er måske meget fint at skulle bruge Visual under udviklings fasen, men når man går fra udvikling og til drift, så tror jeg i vil blive mødt med et krav om et programmerings værktøj som ikke er Visual. Den anden kundegruppe (dem som ønsker status quo) er jeg mere tvivlende overfor. Hvorfor overhovedet skifte LK IHC controlleren ud, hvis den køre stabilt, og man ikke har lavet ændringer i 10 år? Når denne gruppe endeligt vil lave ændringer i deres LK IHC installation, vil de højst sandsynligt tage fat i en elektriker, og de vil enten forslå en total udskiftning med noget ZWave eller Zigbee, eller Schneiders LK IHC/KNX controller. Jeg tviler stærkt på at i får mange elektriker til at hoppe på jeres REVO controller. De vil have standard vare fra en producent med en stærk support organisation. Desværre. Jeg forventer ikke et fuldgyldigt grafisk redigeringsprogram. Faktisk er en af de ting der irriter mig ved Visual, at alt er grafisk, og man er nød til konstant at bruge drag and drop. Noget mere simpelt ala .item, .things samt script filer i OpenHAB kan også gøre det. Disse kunne så compiles til en JSON fil. LK IHC .vis filen er XML formateret, og er også et spildelvæv af pointere, resourcer, script stumper m.m. Så på det punkt er den eneste forskel på jeres controller og en LK IHC controller, formatet på program filen. Produkt definitions filerne i LK IHC er ligeledes xml formateret. Det er ikke normalt, men fra tid til anden har jeg faktisk lavet program rettelser direkte i .vis filen, eller lavet nye produkt filer, som f.eks. en gulvarme fordeler unit med 8 telestater. Ikke særligt svært når man har brugt lidt tid på at sætte sig ind i hvordan filerne er bygget op. Der findes 2 typer alarm tastatur. Igen er der bare tale om enheder som kommuniker med controlleren via I/O modulerne. De kommuniker ikke via en bitstrøm som temp/fugt/lux sensorne, men simpel status ON/OFF. Så hvis i kan konverter LK IHC programmet, så bør alarm tastaturne også virke uden yderlig understøttelse. Det gamle tastatur havde såvidt jeg husker kun nr'erne 1-8 på tastaturet, og brugte 3 input indgange til koden. Disse 3 indgange blev sat binært når man trykkede på tallene på kode tastaturet. Koderne havde man så i LK IHC programmet. Det "nye" tastatur havde alle tallene 0-9 på tastaturet, og her lå koderne i tastaturet. Der er plads til 6 koder i tastaturet. Det bruger fortsat 3 indgange på et input modul, men nu bliver de sat binært alt efter hvilke kode man har trykket på alarm tastaturet. For at ændre kode i tastaturet, behøver der kun være strøm på det. Det behøver ikke være tilsluttet en LK IHC controller. Udover indgangene til koderne, så brugte alarm tastaturene nogle ind og udgange til sabotage kreds, status m.m. Igen simpel status ON/OFF. Husk på at LK IHC blev udviklet i start 80'erne, med de teknologier, som var tilrådighed dengang. Bortset fra nye controller hvert 8-10 år, temp/fugt/lux sensor, wireless og LED dimmer er LK IHC ikke ændret siden TermIHC blev lanceret. De I/O moduler som man brugte sammen med sin TermIHC controller i slut 80'erne, er de samme som man brugte sammen med en Visual 3 controller indtil den udgik i 2023.

En automatisk konvertering af LK IHC programmet til REVO formatet, vil uden tvivl være perfekt, men at skulle vedligeholde det den vej også, lyder for mig, som at gå over åen efter vand for at være ærlig. Jeg kender ikke mange som kan lave den rigtige rettelse i første hug, så man kommer til at skulle konverter mange gange før man er i mål med en rettelse. Også virker det til at være temmeligt besværligt. Man skal fortsat have Visual installeret for at kunne lave rettelser. Derefter skal man gemme sine rettelser, før man kan konverter dem og uploade dem i REVO controlleren. Lyder temmeligt omstændigt. Det er lige før det vil være nemmer at skrive Json filen i hånden. PS. LK IHC alarm har ikke noget specielt modul. Det er bare røg og bevægelses sensor, som er koblet til alm. indgange på et input modul. Program mæssigt ligner de alle andre digitale indgange, bortset fra at det er OFF når de er aktiveret. Der er en ENORM forskel på hvad man kan programmer i Home Assistant/OpenHAB og LK IHC. Jeg forventer på ingen måde at i laver et Home Assistant/OpenHAB programmerings interface, men et begrænset programmerings interface ala Visual, vil jeg dog forvente, eller som minimum en ordentlig dokumentation, så man kan skrive Json filen i hånden. Bortset fra det, så kender jeg flere som er blevet overrasket over hvor lidt som fungere når deres Home Assistant/OpenHAB løsning går ned, og de går ned fra tid til anden. Ofte i forbindelse med en software opdatering, som det tager en krig at recover fra. Det er ikke helt nok at kunne tænde/slukke lyset manuelt, hvis avancerede ting som udelys styring (ala den jeg beskrev i et tidligere indlæg), ligger i Home Assistant/OpenHAB og det stopper med at fungere dagen før man skal på vinter ferie. Sådan en styring bør ligger i REVO controlleren. Ikke i et ustabilt trejdeparts produkt som Home Assistant/OpenHAB. Man kan ikke rigtigt sammenligne en PLC med Home Assistant/OpenHAB. Det er 2 forskellige teknologier, som udvikles og opdateres på MEGET forskellige måder, med MEGET forskellige mål grupper. REVO controlleren og en PLC skulle helst være ca. lige stabile. Men jeg synes fortsat at jeres projekt er meget interessant. Jeg er bare ikke helt sikker på at i har styr på jeres mål gruppe. Her og fru Danmark, vil aldrig selv påtage sig at erstatte en LK IHC controller med en REVO controller, og de har næppe selv lavet deres LK IHC program. Den mere professionelle vil ikke være bleg for at kaste sig over integration med Home Assistant/OpenHAB, men vil forvente at man kan lave alt kritisk i REVO controlleren. Derudover er jeg bange for at i er kommet forsent igang. LK har jo annonceret deres LK IHC/KNX controller, som vil blive præsenteret om knap 3 mdr. og være til salg om ca. 6 mdr. Vi ved ikke hvad den reelt kan, men umiddelbart ser det ud til at den vil kunne alt hvad jeres controller kan, og mere til. Når det er sagt, så vil jeg ikke afvise at jeg ender med at købe en af jeres controller. Om ikke andet, så for at se hvad den reelt kan. Det er meget nemmer at diskuter et produkt når man har det i hænderne.

Godt nok kan man lave mange avancerede ting med en LK IHC controller, men script sproget i controlleren, er faktisk meget begrænset i funktionalitet. Det er grundlæggende kun Event trigger, IF-THEN-ELSE, CASE-WHEN, timer, regne operationer (+-*/) samt tæller. Det bør derfor ikke være noget stort problem at lave et tilsvarende script sprog i en ny microcontroller. Faktisk vil jeg tro det vil være nemmer, end at skulle lave erstatninger for LK's standard funktions blokke, da disse ændrede sig gennem årene, og ind i mellem genbrugte LK funktions blok navne og nr. selvom funktionaliteten var væsentlig anderledes.

Jeg vil nok ikke bruge for meget tid på automatisk .vis konvertering. LK IHC har mindst 2 formater som i vil skulle supporter. Der er TermIHC, Visual 1 (er vist nok det samme som TermIHC), samt Visual 2/3 som er det samme. Der findes en del installationer, som fortsat har TermIHC og Visual 1 controller kørende, og de programmer som ligger deri er sjældent voldsomt avanceret, da der ikke var mange af de funktioner, som findes i Visual 2/3. Hvis i laver en konvertering, bør i kunne konverter stortset hele programmet. Det vil være MEGET svært at gå efter standard LK funktions blokke, da disse har ændret sig gennem årene, og sommetider genbrugte LK funktions blok navne og nr. selvom de nye blokke reelt fungerede væsentlig anderledes. Hvis i ikke kan lave en fuld konvertering, kan det være lidt lige meget. Så skal man alligevel til at leve en masse arbejde selv. En smarthouse installation, som kun indeholder nogle kip funktioner er IMHO spild af tid og penge. Selv TermIHC kunne mere end det. Til min svendeprøve tilbage i start 90'erne, lavede jeg f.eks. en udelys funktion, som tændte lyset på 25% når skumring indtraf. Blev en bevægelses sensor påvirket, gik lyset på 100% i et forud defineret tidsrum, hvorefter det gik tilbage på 25%. Om morgen slukkede lyst igen automatisk når det blev lyst. En sådan funktion, skal jeres enhed kunne klare, for at være relevant. Omkring at have mere kompleks styring i Home Assistant eller tilsvarende, synes jeg det er en dårlig ide. Home Assistant vil aldrig blive ligeså stabil som et program i en microcontroller. Jeg bruger selv OpenHAB, men køre fortsat på ver. 3, da jeg ikke orker at skulle opgrader til ver. 4, grundet de ændringer, som jeg vil skulle lave for at få alt til at køre igen. Jeg bruger dog kun OpenHAB til data opsamling, samt oversigts billeder, så hvis det holder op med at virke er skaden ikke så stor, som hvis jeg var afhængig af at det virkede for at mit lys eller alarm ville fungere. Jeg har med vilje lavet min installation, således at alt hvad der er must have ligger i LK IHC controlleren, mens alt hvad der er nice to have primært også ligger i LK IHC controlleren, og kun hvis det ikke kan laves der, ligger det i OpenHAB.

Jeg vil ikke anbefale firmware 2.7.220. Brug isteddet 2.7.199, eller bedre som du skriver 2.8.4, også selvom at den officielt ikke virker på en HW 6.1 controller. 2.7.220 er temmelig ustabil, og bevirker ofte ikke planlagt genstart af controlleren. 2.7.199 er mere stabil, men 2.8.4 er absolut den mest stabile af de 3.

Derfor kan de godt blive påvirket af sollys alligevel. En PIR, hvad enten det er til lys styring eller alarm, reager på ændringer i det infrarøde lys som varme udsender. En PIR kan derfor blive påvirket af direkte sol lys, sol lys som bliver reflekteret, men også hvis solen eller noget andet opvarmer en genstand i PIR'en dektektions felt. Omkring de 24V til din PIR. Har du prøvet at sætte log på den PIR hvor der ikke er +24V monteret? LK havde på et tidspunkt nogle udendørs PIR, som blev forsynet fra en indgang på et input modul, men disse er udgået for snart 10 år siden. Disse PIR krævede kun 2 ledninger. En indgang, og 0V. Alle senere PIR kræver mig bekendt seperat 24V forsyning udover forbindelsen til 0V og en indgang. Den gamle udendørs PIR er iøvrigt et RIGTIGT dårligt valg som alarm PIR, da den ikke har et stående signal, men derimod pulser når den bliver aktiveret. Du bør kunne se produkt nr'et på PIR'en og herefter slå det op på lk.dk, hvor du så kan finde monterings vejledningen. Derudover vil jeg anbefale dig at læse den PDF som blev installeret sammen med Visual softwaren til din IHC controller. Den giver en ganske grunding indføring i hvordan LK IHC fungerer, programeres o.s.v.

Om det er hurtigere/nemmer at opsætte nogle matter/zigbee alarm pir kan kun du afgøre, da det afhænger af hvordan installationen er lavet. Svaret er det samme vedr. udskiftning af de installerede PIR til LK IHC 12V alarm PIR. Dog bliver det svært at skaffe disse, da de alle er udgået, og der ikke er kommet nogen erstatning. Eftersom PIR'ne køre med 24V, går jeg udfra at det ikke er Alarm PIR's som er installeret. Tag evt. et billed af en af dem, så kan vi hurtigt se om der er en alarm PIR eller en alm. PIR. Men selvom det er en alm. PIR, bør den ikke give signal, når der ikke er nogen i huset, med mindre den er monteret, så den bliver ramt af sollys eller kan se anden varmekilde som ændre sig.

Jeg tvivler stærkt på at kablerne har noget at gøre med din LK IHC installation. Få en elektriker til at pille låget af dine tavler, og se om i kan se hvad kablet er forbundet til. Det bør ikke koste mere end 1/2-1 times faktureret arbejde. Det behøver ikke være en IHC eller netværks kyndig elektriker. Hvis elektrikeren ikke kan gennemskue hvad kablet er forbundet til, så tag et billed, så kan vi måske hjælpe.