TorbenSørensen

Har lige kigget på den styring du har lavet til dit badeværelse. Personligt synes det er meget rodet og især uoverskueligt, at finde ud af hvad der sker, når så mange (9stk) funktionsblokke flettes sammen på kryds og tværs. Jeg har derfor lige lavet én funktionsblok, hvor det hele er samlet (som jeg lige forstår det du har lavet). Så kan du prøve om den fungerer efter hensigten. Becker.vis

Ja den fb. der hedder Skumringsrelæ "hold", er en jeg har lavet til dig. Det er fra denne post fra 2012, hvor du havde problemer med at dit skumringsrelæ bliver påvirket at dit udv. lys. Du har så åbenbart siden tilføjet det virtuelle skumringsrelæ (det er Kenth der har lavet den fb., dog har jeg indsat flere tænd/sluk tider i v6.1), og bruger det i stedet for dit rigtige skumringsrelæ, og det er som Henning siger, lidt at gå over åen efter vand. Det du påtænker med en timer på 15-20 minutter, som tjekker om der er blevet lyst, vil ikke fungere når skumringsrelæet bliver påvirket af dit lys. Dit skumringsrelæ vil jo sige at der er lyst, selvom der stadig er mørkt udenfor, og det vil så resultere i, at lyset hver gang timeren udløber, vil slukke i ca. et minuts tid, for derefter at tænde igen, så længe at der stadig er mørkt udenfor. Fordelen med den Skumringsrelæ "hold" fremfor det virtuelle skumringsrelæ, vil være at du kan bruge dit rigtige skumringsrelæ til at fortælle controlleren hvornår der i virkeligheden bliver mørkt på din lokation, men et fastsat sluktidspunkt kan du ikke undgå, med mindre at du flytter skumringsrelæet til et sted, hvor det ikke bliver påvirket at dit udv. lys.

Yes sir!! Selv om man bruger den der hedder Touch, eller Tænd/reguler op og Sluk/reguler ned på wireless dimmer produktet, betyder det ikke at det er noget super lavpraktisk... Disse signaler fungerer også trådløst som når man sender et scenarie til dimmeren. Det er heller ikke forbudt at bruge Lys niveau på dimmeren, hvis man vil bruge den i sin programmering, til andet end bare at aflæse %-sats.

Tror du misforstår mig. Jeg bruger skam også scenarie på alle mine wireless dimmere. Det er når jeg regulerer på lysstyrken, at det foregår gennem den der hedder touch på dimmeren, i stedet for at det foregår gennem scenarielinket. Kan heller ikke lige se hvorfor man ligeså godt kan bruge en uni400?? Der skal jo ikke bruges 24V udgange til den regulering jeg laver, hvis det er det du tror, og jeg får jo stadig tilbagemelding til controlleren om % + info om tændt/slukket, hvilket jo ikke kan lade sig gøre på en uni400. Kan ligeledes styres via app.. Forskellen er altså udelukkende programmeringen af hvordan lysdæmperen styres.. Virkemåden er den samme. Jeg oplever som sagt aldrig det problem med at de låser. Om det er måden jeg styrer dem på, kontra den måde LK prøver at gøre det på med regulering af lysstyrke gennem scenarielink vil jeg ikke gøre mig til dommer over, men har hørt om en anden, som har løst det på samme måde. Hvis man kigger internt i eksempelvis 1.2.03.d. som mange bruger, kan man også se, at der ved et kort tryk på touch når man f.eks. vil slukke lyset, bliver sendt 2 scenarier afsted til dimmeren med få millisekunders mellemrum (reguler regulering ned + stop regulering af regulering) Om de wireless dimmere så kan håndtere 2 scenarier lige oveni hinanden, tør jeg ikke sige, da det er svært at teste, men ser det absolut som en mulighed for at de pludselig går i koma, da jeg ikke oplever problemet.

Prøv når problemet er der, at starte serviceview og se om du kan styre niveauet direkte på dimmeren i venstre skærmhalvdel - altså udenom funktionsblokken. Enten ved at justere %-sats eller påvirke de 2 udgange til at justere lysstyrken op/ned.

Jeg styrer både 50x50 og LU dimmere på samme måde, og har ingen problemer med dem, men ved da at andre har haft problemer med at også 50x50 pludselig "låser"... Jeg har dog stadig på fornemmelsen, at det er når touch-reguleringen sker gennem selve scenarielinket, at den pludselig går i koma. Lk har som sagt kendt til problemet i mange år, men har åbenbart ikke kunnet knække nødden. Det var på grund af dette problem, at der i 2014 kom en ny fw., som opdaterede radiomodulet i controlleren. Fik dengang at vide af en tidligere medarbejder hos LK, at der angiveligt var fundet fejl i algoritmen til wireless, og derfor skulle radiomodulet opdateres.. Nogle af de første 6.1 controllere kunne dog ikke opdateres i radiomodulet, og man kunne så få dem ombyttet.. Det viste sig dog at det ikke hjalp, og ombytningen af de controllere blev således stoppet igen. Her er også et LINK til en gammel tråd om samme problem... Link til LK's meddelelse om problemet er desværre dødt, efter de lavede ny hjemmeside, men der stod noget i stil med, at de var klar over problemet, men ikke vidste hvad det skyldtes. De skrev dog at det hverken var SW eller HW som var problemet, og at de arbejdede på en løsning.

Kan ikke lige se at jeg går glip af nogle fordele ved at styre dem som jeg gør.. Det er jo kun selve touch-funktionen jeg laver på en anden måde - altså når jeg via mit tryk vil regulére lysstyrken op/ned. Der er jo stadig tilbagemelding og info om %-sats.. Jeg bruger også stadig scenariet på dimmeren, hvis jeg bare vil fremkalde en fast %-sats.

Mine LU er HW1.. Er du sikker på at det er det rigtige produkt du forsøger med? Det skal være den som hedder Lampeudtag dimmer touch. Den som hedder Dimmer touch er til de 50x50 wireless dimmere.

Nej har selv lige prøvet Visual 2.8, og der kan jeg godt se at de ikke er med.. De har dog været med i Visual 2, men hvilken version kan jeg ikke huske. Ellers kan det da lade sig gøre at indsætte produkterne selv i mappen med produkter.

Det er software til Visual 3, men det er også sådan i Visual 2 softwaren. Den du viser dér, er IKKE en wireless dimmer, men en fortrådet dimmer.

Der hvor jeg har set problemet, er hvor selve regulering af lysstyrken (touch) op/ned, foregår gennem et scenarielink. Sådan fungerer det i f.eks.fb. 1.2.03.d. - 1.2.04.d. - og 1.2.05. Jeg styrer i stedet touchfunktionen på mine wireless dimmere ved at bruge en puls, og bruger kun scenarielink til at fremkalde en fast %-sats, og jeg oplever som sagt ikke de problemer med, at de lige pludseligt låser. Til at starte med, da LK introducerede de wireless dimmere, var produkterne man satte ind i venstre skærmhalvdel lidt anderledes, da der var en touchfunktion direkte i produktsiden. På et tidspunkt blev de dog genindført i visual, men de skal nu findes under specielle produkter. (se vedhæftede).

Det kan ikke flyttes, så du er nødt til at starte forfra.

Hvis du har opdateret fw i din controller, har du så også husket at opdatere dit IHC Visual program? IHC Visual SKAL matche med fw.

LK kender udemærket til problemet, men de ved åbenbart stadig ikke hvad de skal gøre ved det. Tror de fik fejlmeldinger helt tilbage i 2010/2011. Kan huske at de tilbage i 2013 udsendte en vejledning til midlertidig afhjælpning af problemet (indtil det sker næste gang), hvor de skrev at man skulle slette scenarielink og oprette det påny. Jeg har på fornemmelsen, at problemet kun opstår når man bruger scenarielinket til regulering af lysstyrken. Jeg bruger selv en puls til at regulere lysstyrken på mine wireless lysdæmpere, og jeg oplever aldrig det problem med at de låser. Bruger kun scenarie på dimmeren til at sende en fast %-sats - det kan f.eks. være 0% ved sluk alt, 10% til udv. lys og 100% ved detektion af PIR-sensor osv.

Vi kan da sagtens blive enige om, at det var bedre at den ikke genstarter med mellemrum, men det er jo ikke noget man selv kan gøre noget ved. Det kan ikke løses med de programmer LK stiller til rådighed til IHC. LK ved jo også godt, at controlleren genstarter af og til. Det kan du godt regne med, at de har fået at vide utallige gange, men enten kan det ikke løses, eller også gider de ikke at gøre noget ved problemet. Der er i hvert fald umiddelbart ikke andre, som kan gøre noget ved det end LK.

Der er i hvert fald mange, som har haft samme problem som dig med den model dér. Selve indsatsen er den samme, som den der har siddet i før. Du har ikke tilfældigvis stadig det gamle buede dæksel, så du kan prøve om det hjælper? Det passer i den yderste rille på fronten, og dækker derved skruerne samt de huller der er, så der ikke kommer luft den vej ind bag PIR'en. Jeg har ikke selv prøvet det tidligere omtalte adaptordæksel med den Fuga 180grader PIR, men har hørt at det skulle fungere ret godt, så i dit tilfælde ville jeg nok prøve den løsning, da det passer i selve det underlag som dine PIR sidder monteret i. De kræver en ekstra ledning til fast 24V+, men mon ikke der er trukket et 6 eller 10 ledet kabel til dine PIR? Dem du har dér bruger jo kun 2 ledere. Jeg bruger selv en PIR fra Servodan (41-272/41-262 + hætte 41-902) som har kørt upåklageligt nu i 10 år, men den model passer ikke lige så godt til montering som dine sidder. De passer bedre til montering på væg.

Det ligner at det er sådan en gammel sag af en Fuga PIR som er blevet monteret. >>>LINK<<< Den er egentlig magen til den gamle, men dækslet lukker ikke tæt som det originale fra Opus 73 modellen. Den er iøvrigt også udgået for mange år siden, og det er ikke lige den model som LK har haft størst succes med funktionsmæssigt - mildest talt. Som sagt har LK lavet et adaptordæksel, som kan anvendes med Opus 73/74 underlag, hvori man så kan montere en Fuga PIR, der ellers er beregnet til indendørs montering, men det skal så være en Fuga 180grader. Link til adaptordæksel : >>>LINK<<< Link til PIR : >>>LINK<<<

Hvilken type PIR er det du har monteret i det underlag? Umiddelbart ser det nemlig ikke helt rigtigt ud, da det buede dæksel plejer at være større på sådan en Opus 73 PIR. Den Opus 73 PIR er desuden udgået for flere år siden. Tænker om det måske er en PIR til indendørs montering du har anvendt? Der er lavet et adaptordæksel, som passer på et Opus 73/74 underlag, som gør at nogle af LK´s PIR til indendørs montering også kan anvendes udendørs.

Jeg kan se, at du styrer den kombidimmer du viser screenshot af fra andre funktionsblokke også. Derfor skal du på den indgang, som hedder Indgang andre tryk end scenarie, forbinde de tryk som styrer samme produkter gennem de andre funktionsblokke. Det er pga. at den anvendte fb. 1.1.03.f. ellers ikke ved, at der er ændret på scenariet. Dvs. at hvis du eksempelvis først har valgt scenarie 1 og derefter slukket fra en anden funktionsblok, ikke kan vælge scenarie 1 igen, da fb. 1.1.03.f. stadig "tror" at scenarie 1 er valgt. Det problem kommer du ud over, ved at forbinde de andre tryk til den indgang.

Nu er det jo ikke noget man selv kan gøre noget ved, da det er sådan LK har designet controlleren. Hvor ofte det sker, afhænger af programmet (og åbenbart firmware, som man jo ikke selv kan rette i), og vil også vove den påstand at din egen controller også vil genstarte af og til, hvis du bare lader den køre. Især efter at du har tilføjet varmestyring til din IHC. Nu har du jo lavet en del rettelser af dit IHC-program og opdateringer af firmware, og der genstarter den jo også hver gang, og så bliver tiden før den ville genstarte af sig selv jo nulstillet. Mange opdager heller aldrig at den genstarter, for controlleren kører jo bare videre efter genstarten. Jeg logger selv genstart af min egen controller - ellers ville jeg ikke opdage størsteparten af genstarterne. I Tkhansens tilfælde opdager han genstarten, da der i den tilrettede funktionsblok var problem ved powerup, som startede alarmen hvis den var aktiv under genstarten. Har engang hørt fra en LK’er, at brugen af timere vil få controlleren til at genstarte oftere. Sådanne funktionsblokke som varmestyringsfb. og nogle hjemmesimuleringsfb. kører jo med en del timere internt i funktionsblokken, som starter om og om igen, hvilket gør at controlleren kører hele programmet igennem igen og igen. Et program der eksempelvis kun består af kipfunktionsblokke, kører kun programmet igennem når man tænder/slukker et lys. Jeg har lagt mærke til, at LK gennem tiden har ændret en del af deres standard funktionsblokke som indeholdt timere, til at der internt i funktionsblokken bliver sat et “tidspunkt” som skal udføre en handling, i stedet for at der er timere som tæller ned. Om det har noget med sagen at gøre, eller om det bare er en medarbejder der bedre kan lide at lave funktionsblokkene på den måde, ved jeg dog ikke.

Super at det ser ud til at fungere... Det skal du ikke tænke på.. Forummet er jo bl.a. til for at hjælpe med sådanne små "udfordringer".. Det er nu MEGET normalt at controlleren genstarter af og til, men mange opdager det jo slet ikke, med mindre at der sker en eller anden uhensigtsmæssig hændelse, som eksempelvis den Tkhansen oplevede her. Du skal også huske på, at hver gang du retter/uploader program til din controller, vil den også genstarte, og du har jo rettet i dit program en del gange efterhånden. Jeg har dog set en controller som har kørt et års tid uden at genstarte, men der bestod programmet også udelukkende af kipfunktionsblokke og en alarmblok. Hvis man har et lidt mere avanceret program, vil jeg vove den påstånd, at den vil genstarte af og til. Der er også forskel på hvor ofte det sker afhængig af firmware.. Eksempelvis genstartede min controller ca. 1 gang/md. med fw. 2.7.199 og ca. hver 4. dag med fw 2.7.220 og det med akkurat samme program i controlleren.

Prøv at kigge i denne post >>> LINK <<< Der er en løsning med en nyere firmware, som skal indlæses med en ældre firmwareloader, for at få din controller til at fungere med iOS 11. Som du kan se i det link du har fundet på LK´s hjemmeside, skriver de at en HW6.1 controller som du har, ikke længere kan bruges med apps i iOS 11, men det kan altså lade sig gøre, som du kan læse om i den anden post... Alternativet er en ny/nyere controller, hvis du vil benytte LK´s apps.

Hmmm... Nå i det mindste virker logfunktionen da.. Prøv lige med vedhæftede, og se om der så er succes.. Controlleren "slipper" åbenbart alle magnetkontakterne ved genstarten, siden den kan nå at give alarm på dem alle på samme tid. Tkhansen_test_af_alarm_2.vis

Det var så lidt.. Egentlig mærkeligt at det slet ikke står nævnt i manualen.. Man kan se på billedet af det modem i manualen, at den gule knap har fået hele turen med en blyant/kuglepen, men det var da bedre at de lige beskrev fremgangsmåden.

Det var så lidt.. Er lidt spændt på resultatet, da dette scenarie jo ikke er til at teste i simulering.