Lars1

Touch problemet findes kun på wireless dimmer og kun hvis du går fra en gammel version af Visual 2 til Visual 3. Jeg tror faktisk ikke at det kan lade sig gøre at upload et Visual 2 program med touch dimmer produkter til en Visual 3 controller. Du vil få en fejl med henvisning til de produkter i dit program som ikke er understøttet af Visual 3. Problemet er at der for flere år siden var 2 wireless dimmer produkter i Visual. Et med 1 tast betjening (touch) og et med 2 tast betjening. Et Ø80 wireless dimmer lampeudtag understøttede begge produkter, og du valgt betjenings metoden når du linkede din wireless dimmer til controlleren. De sidste mange år har man ikke kunnet vælge touch produktet når man linkede wireless enheder, men det har fortsat været understøttet i firmwaren. Denne understøttelse er fjernet i Visual 3. Selvom du valgte 2 tast produktet under linkning, er det fortsat muligt at betjene dimmeren via 1 tryk. Det er bare et spørgsmål om hvordan din FB er kodet. Skulle du have wireless dimmer som er linket med touch produktet er problemet ikke større end når du linker dem til din Visual 3 controller, så skal du bruge et 2 tast produkt, og alt efter din FB, skal denne måske omkodes eller udskiftes med en ny. Jeg kan dog ikke huske om LK's dimmer FB's understøtter 1 tryk betjening

Hvis du har lukket brusekabine så vil jeg give dig ret i at ventilatoren hurtigt får klaret fugt problemet, men hvis du har en åben, så breder fugten sig hurtigt i hele badeværelse, og så tager det nemt et par timer eller mere at komme ned på normalt fugt niveau igen. Det er dog ikke et problem som er så stort at jeg personligt vil smide mange penge efter en fugt styret ventilator.

Folk læser dokumentation forskelligt, og nogle ting er svære at beskrive end andre. Udfra overenstående virker det ikke til at du har forstået det grundlæggende princip i scenarier eller LK IHC i det hele taget. Der findes 5 operationer med scenarier. Fremkald Scenarie - Sætter de linkede udgange/dimmer til den værdi, som du angav da du linkede dem til scenarierne. Hvis du linker f.eks. et lampeudtag med værdien ON, så bliver lyset tændt, når du fremkalder det pågældende scenarie Gem Scenarie - Overskriver den værdi du angav da du linkede lampeudtaget eller dimmeren til dit Scenarie. Hvis lampeudtaget blev linket til at tænde når scenariet bliver fremkaldt, men er slukket når du gemmer Scenariet, så vil lyset fremover blive slukket når du fremkalder det pågældende Scenarie. Reguler Scenarie op - Bruges kun på wireless dimmer. Lys styrken bliver reguleret op fra du kalder Reguler Scenarie Op og indtil du enten kalder Reguler Scenarie ned, eller stop regulering af Scenarie. Reguler Scenarie ned - Bruges kun på wireless dimmer. Lys styrken bliver reguleret ned fra du kalder Reguler Scenarie ned og indtil du enten kalder Reguler Scenarie op, eller stop regulering af Scenarie. Stop regulering af Scenarie - Beskrevet oven over. Med andre ord. Hvis du vil bruge Scenarier til at tænde og slukke lyset, så skal hver FB have 2 Scenarier. Et hvor du linker lampeudtagene med status ON og et hvor du linker dem med status OFF. Når du vil tænde lyset fremkalder du scenariet hvor lampeudtagne er linket med status ON, og når du vil slukke fremkalder du scenariet hvor lampeudtagne er linket med status OFF. Der er ikke noget i vejen for at linke lyset i dit vaskerum, fyrrum og værksted til flere forskellige scenarier, og selvom du tænder lyset i alle 3 rum via et scenarie, kan du sagtens slukke det i et af rummene med et andet scenarie. Da LK IHC er event baseret, kan dette også lade sig gøre med alm. udgange. Men pas på. Hvis din funktions blok til lysstyring har et internt flag som holder øje med om der skal tændes eller slukkes for lyset når du næste gang trykker på kontakten, så kan dette flag meget nemt komme ud af sync med den reelle status på lyset, og så vil du skulle trykke 2 gange for at enten tænde eller slukke lyset for at komme tilbage i sync. Forskellen på et scenarie og en alm. udgang er at med en alm udgang i en funktions blok, så bliver lyset sat til det som du angiver i din funktions blok, mens det ved fremkaldelse af scenarier er afhængig af den status du linkede lampeudtaget med, eller den status lampeudtaget havde da du sidst gemte scenariet. Et lampeudtag kan sagtens linkes til flere udgange og scenarier på flere funktions blokke på samme tid, men det anbefales ikke at gøre det da man nemt mister overblikket over hvorvidt lyset er tændt eller slukket i programmet. Dit ønske til lysstyring i vaskerum, fyrrum og værksted kan laves både med og uden Scenarier. Umiddelbart kan jeg ikke se at Scenarier vil gøre hverken til eller fra. Brug FB 1.1.01.d avanceret kip (Visual 2.8.6) i hvert rum, og link så dine tryk som du gerne vil have at de skal tænde og slukke lyset. F.eks. NV på tryk i gang. linkes til en indgang i FB'erne som tænder lyset, mens NØ linkes til en indgang som slukker lyset. ØH og ØV i hvert rum linkes til en indgang på den lokale FB, som kipper lyset i rummene. Om du bruger udgange eller scenarier til at linke lampeudtagne til funktions blokkene gør ingen forskel, men lampeudtaget i hvert rum skal kun linkes til lysstyrings FB'en i det pågældende rum.

Jeg tror du blander en række begreber sammen, og det kan man ikke løse med dokumentation. Tilbagemelding bruges kun på wireless enheder, og er tilbagemelding fra enhederne om status efter en ændring. F.eks. dimmer melder aktuel lys styrke tilbage hvilket er meget praktisk på kombi dimmer som også kan styres via tryk på dimmeren. Som jeg skrev, så virker scenarier ikke meget anderledes end alm. udgange. Forskellen er primært hvad du kan linke til et scenarie. Rute lys kan programmers via scenarier ved at du linker alle de lamper på ruten til samme senarie. Når du vil fremkalde rutelyset starter du med at gemme rutelys status scenariet, præcist som i mit brand alarm eksemple. Herefter fremkalder du et scenarie, som tænder alle lamperne på ruten, og til sidst når du vil slukke rutelyset, fremkalder du det gemte scenarie eller et scenarie, som slukker alle lamperne. De samme lamper som er linket til scenariet, kan også linkes til andre funktioner, herunder sluk alt og dermed også styres individuelt. Anbefalingen er dog at man ikke styre udgange fra flere FB's, da man nemt taber overblikket over status på udgangen grundet den manglende tilbagemelding på alm. udgange. Normalt vil en scenarie ændring af en udgang også kunne ses i andre FB's som er linket til den samme udgang, men der er også tilfælde hvor dette ikke virker. Med andre ord. Dit rutelys børe programmers ved at du har en rutelys indgang i FB'er som styre lamperne som findes på ruten. Sidst men ikke mindst. Den bedste måde at lære noget er ved at prøve sig frem og se hvad der sker når forsøger at linke forskellige ting til f.eks. et scenarie og så lege med fremkaldelse og gem.

Har du prøvet at læse den villedning som findes under hjælp i Visual. Scenarier er godt beskrevet her i såvidt jeg husker. Den største forskel på Scenarier og andre styrings metoder er at du kan bruge scenarier til at styre flere ting på samme tid uden at skulle have flere udgange i din FB. Du kan f.eks. både linke en dimmer og en alm. on/off udgang til det samme scenarie. Det kan du ikke med en alm. udgang. Derudover kan du også linke f.eks. en stikkontakt til at gå ON når scenariet fremkaldes og en anden til at gå OFF når samme scenarie fremkaldes. Det kan du heller ikke med en alm. udgang. Du kan også gemme et scenarie, og fremkalde det igen senere. At fremkalde et gemt scenarie, betyder at du vender tilbage til en tidligere gemt status for alle linkede enheder. Jeg bruger det f.eks. til min brand alarm. Når alamen går gemmer jeg et scenarie før jeg tænder alt lys. Når brand alarmen bliver afstillet, fremkalder jeg scenariet igen og alle linkede lamper går tilbage til den status de havde før alarmen gik. Skulle jeg gøre det samme med alm. udgange, vil jeg skulle have en udgang for hver lampe i min brand FB.

LK har jo selvfølgelig også deres "IHC control 0-10V converter" og deres "IHC Control® 1-10 V dimmer IHC/SA" moduler. Jeg finder dog personligt begge temmelig ubrugelige til noget som helst praktisk formål. 0-10V converteren er nok den som kommer nærmest ønsket, men det er et tavle modul, som kun virker sammen med en wireless dimmer. Det kan ikke forbindes direkte til IHC controlleren.

IHC har ingen analoge udgange, så du skal ud i noget trejdeparts integration hvis du skal have det til at virke.

Udskiftning af en Visual 2 controller til en Visual 3 bør enhver IHC elektriker kunne klare. Det en 1-1 ombytning. Alle ledninger passer i samme terminaler, og programet kan direkte overføres. Eneste udfordring er at alle wireless enheder skal genlinkes og evt. touch dimmer funktions blokke erstattes med de nye 2 tast dimmer funktions blokke. Såfremt at den fysiske installation er i orden er jeg sikkert på at Henning eller en anden kode haj her på boardet kan fikse dit garagelys scenarie for dig. Enhver elektriker, incl. ikke IHC elektriker burde være i stand til at verificer at den fysiske installation er i orden.

Selvom det job du beskriver kræver en autorisation, tror jeg de fleste af os her på boardet selv er istand til at udføre det, og derfor ikke har nogle elektriker kontrakter som vi kan anbefale. Enhver elektriker som skriver noget om IHC på deres website bør være istand til at udføre det job du har beskrevet. Udskiftningen af controlleren og Iphone opsætning bør kunne klares på et par timer. Du kan iøvrigt få din Iphone til at virke med den Visual 2 controller hvis du opgrader firmwaren til seneste HW 6.2 version. Der findes flere tråde om emnet har på boardet, incl. workarounds til at få HW 6.2 firmware installeret på en HW 6.1 controller.

Ikke planlagt genstart af IHC er et kendt problem, og det er somregl netværks kommunikation som trikker det, hvilket er årsagen til at du først ser det nu hvor du har sat IHC bridge op. Du vil sandsynligvis have haft samme problem med IHC Captain, OpenHab etc. etc. etc. Grunden til genstarten er ofte dårlig programering. Der findes flere tråde her på boardet med gode råd til hvordan man ryder op i sit program, og dermed reducer de ikke planlagte genstarts. Jeg er selv gået fra ugentlige genstart til 6-12 mdr. mellem ikke planlagte genstart, ved at gennemgå mit program og rettet alt dårlig programmering og fjerne program stumper, som alligevel ikke blev brugt Grunden til at IHC bridge sender notifikationer, er sandsynligvis dårlig programering, hvor power up sekvensen i IHC controlleren gør at de udgange du monitorer med IHC bridge ændre status. Jeg kender dog ikke IHC bridge, så jeg kan ikke sige om problemet er at den er kodet til at sende notifikationer, når IHC controlleren genstarter.

Jeg forstår bare ikke hvorfor du bliver ved med at brokke dig her. Dit brok bør rettes mod LK, men de læser ikke med her, så der er ikke nogen relevant modtager for dit brok på dette site. Jeg betragter mig ikke som tilbagelænet eller at indtage en ligegyldig holdning. Men jeg gider ikke spille tid på at brokke mig over ting når der ikke er nogen relevant modtager tilstedde. Ret nu dit brok mod dem som kan ændre på problemet, isteddet for at forpeste dette board med din negativitet. Det ender bare med at os som rent faktisk fra tid til anden hjælper nogen med at løse et aktuelt problem dropper dette board. Og vedr. mit brok over dit brok, så er der den forskel at du kan stoppe med dit brok her på boardet. Så jeg har en modtager til mit brok. Det har du ikke.

Og den henstilling bør du sende til LK. Der er ingen som læser med her, som kan gøre hverken til eller fra på det område. Jeg kan sådan set godt sætte mig ind i det, men du er igen ude i at bruge produktet på en anden måde en tiltænkt fra LK. LK IHC er ikke designet til at hr. og fru danmark skal firmware opdater det eller programmer det. LK's model er at det er elektriker som har været på kursus som skal gøre dette. Du kan være uenig i dette, men det må du tage op med LK. At lufte din fustration her på boardet er bare nytteløs brok.

Dit had til LK er efterhånden godt kendt. Kan du ikke prøve at klage din nød direkte til LK isteddet for her på boardet hvor de alligevel ikke læser med. Det er ret trættende at se den samme plade spille igen og igen og igen og igen og igen. LK er et kommercielt firma. Hvis de så en kommerciel fordel i at handle anderledes, så gjorde de det. Hvorvidt du er enig i deres analyze er sådan set ligegyldigt. Det er deres produkt. De bestemmer hvordan det skal se ud. Er du utilfreds kan du brokke dig direkte til dem, eller lade være med at købe det. At brokke sig her igen og igen og igen og igen gør ikke produktet bedre og hjælpe ikke nogen med at læse deres problemer.

Hvad hvis SD kortet er defekt? F.eks. korrekt fil format, men korrupte data i filerne?

Jeg kender mange devices som ikke kan starte hvis SD kortet er defekt. Mine Raspberryes f.eks. Kunne LK have kodet sig uden om dette problem. Sikkert, men de har valgt at prioriter anderledes, uden at kende deres udviklings budget og mængden af udviklings opgaver vil jeg ikke græde snot over at de prioriter anderledes end hvad jeg set udefra synes vil være den rigtige prioritering. At SD kort ikke bruges de stedder du nævner, skyldes mere at der ikke er nogen added value ved at bruge SD kort, ikke at SD kort er et dårligt produkt. Data log på et SD kort er normalt ikke et problem. Slet ikke hvis det er traditionel data log, hvor man skriver sekventielt i en fil. Der hvor SD kort har problemer er når du har en database som ligger på SD kortet. Det kan de ikke holde til.

Hvis du læser villedningen, vil du se at du kan uploade et nyt program til controlleren, ved at lægge det på SD kortet på din PC og boote controlleren efter du har sat kortet i controlleren. Med andre ord. Controllerne læser programmet som ligger på SD kortet når den booter, og derfor kan den ikke boote med defekt SD kort. Dette har tidligere været diskuteret i en af trådene om SD kortet her på boardet.

Prøv at søge her på boardet. Der findes flere tråde om emnet og nogle af dine spørgsmål er besvaret i LK's manual, som følger med Visual 3 softwaren.

Prøv at læse LK's villedning som du finder under hjælp i Visual, så er jeg sikker på du selv kan lave ændringerne. Det kan laves med en simpel invertering af en indgang og en "and" funktions blok. Tror begge findes som standard i LK IHC Visual.

Såvidt jeg forstod, er der forskel i antallet af ledninger på de 2 tastatur. Hvis jeg ikke husker meget galt, skyldes det at deres er flere tal på de nye tastatur, hvilket sandsynligvis betyder at der skal ændres i programmet for at få det til at virke.

Det lyder ikke godt at LK support ikke kunne løse problemet. De havde tidligere et remote tool, så de kunne overtage den PC som var tilsluttet IHC controlleren, og den vej rundt lave de program ændringer, som elektrikeren ikke kan finde ud af.

For det første. Simulering er offline. Lamper m.m. tænder ikke når du køre simulering. Prøv at checke uret i din IHC controller via adminview. Hvis det går forkert, vil det virtuelle skumrings ikke virke korrekt. Check derudover via serviceview hvad der sker i controlleren når du mener lyset skal være tændt.

Trejdepart produkter kan være IHC Captain, OpenHab, Domotics, IHC bridge etc. De er alle software produkter. De fleste er freeware og kan kan køre på en Raspberry PI. En IHC controller kan kommuniker med op til 64 LK IHC wireless enheder, og kan have op til 128 fortråede indgange og 128 fortråede udgange. En controller koster mellem 5-10.000 kr. alt efter hvor du køber den. Dertil skal du nok bruge 1 8 ports output modul til din installation. Det koster mellem 300-1000 kr. Alt sammenhæng mellem ind og udgange er 100% programmer bar. Du kan downloade Visual softwaren på LK web site. Softwaren bruges til at programmer controlleren. Dette gøres offline og program afviklingen kan simuleres uden adgang til controlleren. Når du installer softwaren får du også adgang til LK's IHC dokumentation som i detaljer beskriver hvad du kan med produktet.

Det er over 20 år siden jeg forlod branchen, og jeg har ikke selv en Visual 1 controller, så jeg kan desværre ikke hjælpe dig her. Men mon ikke der er en af de andre her på boardet som kan hjælpe dig. Nogle af dem arbejder fortsat som elektriker. Ellers er der LK's facebook gruppe. Den har jeg dog ikke adgang til eftersom jeg ikke er på facebook.

Timerne er ikke de værste, men det er en kombination af antallet, og hvor meget de køre. Ideen med aktuel tid +1 sek. tror jeg vil koste flere resourcer grundet den tumpet måde som LK fanger tids events på. Bortset fra det, så tror jeg faktisk ikke at det kan lade sig gøre. Såvidt jeg husker understøtter LK IHC ikke at man sætter en variable=aktuel tid, og lægger 1 sek. til.

LK IHC wireless tryk virker kun med andre LK wireless enheder. Ø80 lampe udtag findes både som relæ og dimmer, og kan direkte erstatte de normale Ø80 lampeudtag. Man kan ikke med et 4 taste LK IHC wireless tryk styre 4 dimmer. Det skyldes at LK ikke længere supporter one touch på standalone wireless dimmer. Det kræver derfor 2 taster pr. LK IHC wireless dimmer. Hvis du går via en LK IHC controller er det en helt anden sag. Her programer du selv hvad der skal ske når du trykker på de enkelte taster og du kan via trejdeparts produkter kommuniker med andre wireless produkter end LK's.