ThomasHej

Det ser totalt flot ud. Og der er en særlig form for tilfredsstillelse over at kigge på den tavle. Men, når det så er sagt - og bare for at være lidt anderledes - hvorfor så sætte en "virtualisering" (klemrækkerne) mellem modulerne og link-ledningerne. Man er naturligvis forberedt på at man senere måske skal have nye tryk og dermed kan "flytte rundt" uden at skulle afmontere ledninger på moduler. Eller omvendt, flytte rundt på moduler uden at skulle pille ved link-ledningerne. Men hvor tit er det så lige at det sker? Min første IHC tavle blev lavet af en rodemikkel af en elektriker, men jeg fik da lavet dokumentation og har kun ændret programmet (mange gange), men ikke hardwaren - faktisk har de fleste udvidelser været med wireless komponenter (lysdæmpere) og fjernbetjeninger. Min anden (forældrekøbslejlighed og totalrennovering), var væsentlig mere struktureret, men stadig "pragmatisk".... :-) Men som en nørd til en anden - fand'me en flot tavle :-) Den flotteste jeg har set.

Mange tak Lars for at du deler din ekspertise. Jeg er nu helt uenig i at IHC programmering er usammenligneligt med anden programmering - tværtimod. Vi har med en state-machine at gøre, og der er nu altså mønstre omkring disse som også lader sig anvende på IHC. Windows-programmering (i gamle dage med WM_Command) mindede meget om IHC. Forskellen på SendMessage og PushMessage - om en ændring blev lagt "i kø" eller kaldte notifikations-triggeren direkte var ikke altid til at regne ud, da man ikke vidste hvordan koden så ud (ligesom med IHC). Faldgruberne som du identificerer, er jo blot en anden måde at udtrykke, at IHC ikke altid er konsistent i sin udførsel - men det er IHC absolut ikke ene om. I mit tilfælde, har min Powerup blok, kode som sætter alle relæer til OFF og sætter desuden intern state til STOP. Et igangsætter-tryk, vil altid blot sætte intern-state til hvad der nu kræves. Når intern-state ændres vil relæer igen blive sat til STOP. Og et enkelt tændes muligvis. Når et relæ starter movement, kan der ikke startes movement i den anden retning før begge igen har været på stop i et lille stykke tid etc. Jeg kan dog se en ting hvor det kan gå galt. Da mine relæer er trådløse, kunne man teoretisk forestille sig, at radio-signalet til at sætte et relæ "off" gik tabt, og min FB derefter - i bedste tro - tændte relæer for modsat retning. Det vil dog kræve, at mindst 2 pakker gik tabt, men det er velsagtens teoretisk muligt. Jeg har dog checket at mine motorer ikke brænder sammen hvis de får strøm i "begge retninger". Det er faktisk sjovt du nævner faldgruber i IHC. Jeg har aldrig mødt en eneste af dem - men jeg er også meget defensiv i min kode. Jeg forsøger ALDRIG at "regne med state" efter en powerup - men sætter aktivt intern state (og dermed afledt output-port) til fast værdi (typisk OFF). Jeg læser ALDRIG en output-port og bruger den som "state". Der er altid en bagvedliggende "master" som indikerer hvad som ønskes - output porte er blot manifestationen af intentionen. Dette betyder, at en knap blot sætter f.eks. StueLys = BordOgSofa. Dette dækker intention. Derefter er der en trigger på skift i intention som sætter de enkelte output-porte. På den måde er det meget nemt at ændre og udvide. Kombinationer af lange tryk dobbelt-tryk osv, er blot også states. PushAndHold state er min ven... :-) ...og dog - så passer det ikke helt af jeg aldrig er løbet på en faldgrube. Jeg rendte faktisk på en faldgrube omkring CASE. Hvis man laver en CASE og retter værdien som evalueres af CASE'en, så risikerer man at ramme flere af program-stumperne, alt efter deres rækkefølge - yikes. Dette er dog mere sproget som der er noget galt med. Men under alle omstændigheder, er det velsagtens dårlig stil at ændre den variabel som er genstand for CASE. Hvis man virkeligt ville udnytte ovenstående, kunne man jo blot lave flere "IF" efter hinanden uden at kode i "ELSE" blokken. Så ville det være mere klart hvad som sker (men stadig dårligt design). Men så et helt andet spørgsmål. Efterhånden som ens program bliver større, tager det længere tid at "hente/opdatere kørselsværdier", har du et trick som kan fikse dette? Thomas ...Og endnu en gang tak for dine mange værdifulde inputs og svar her på siden - megen inspiration er fundet her.

Hej Lars, Missede lige dit svar, men tak for det anyways. Jeg har selv rodet med IHC i mange år efterhånden (dog ikke 20), men jeg har programmeret hvad-som-helst i ca 40 år, men er til gengæld totalt rookie når det kommer til "rå elektronik". Det er derfor jeg gerne ville have et helt konkret link til et relæ som jeg ville kunne bruge. "Det findes 100 forskellige" hjælper mig ikke rigtigt :-) Jeg er helt med på din betragtning omkring opstart af controller. Dog er jeg rimelig sikker på, at jeg aldrig kommer til at sende strøm på begge relæer. Udgangspunktet er, at markisen kunne være i bevægelse under opstart, men det første som opstart-eventen gør er at stoppe alt bevælgelse, slukke alle relæer og sætte intern state. Ved enhver relæ ændring, startes desuden en timer, som sørger for at der ikke kan foretages endnu en ændring før "things have settled". IHC er ganske rigtigt en state-machine, men det forhinder ikke at man stadig kan lave god kode omkring den. Jeg ville som dig, aldrig stole på output porte, men anvender altid interne variable som "master". Alle porte er derefter afledt information. Dette tillader at man i sin funktionsblok aldrig er i tvivl. Nok om det. Jeg vil stadig sætte pris på et konkret link som ville kunne have løst ovenstående med et smart relæ. Thomas

Tak Lars, Jeg søgte skam en helt masse, men fandt ikke det svar du kommer med foroven. Nu har jeg købt og monteret mine 4 relæer, og med den blok jeg har skrevet, skulle det absolut ikke kunne lade sig gøre at sende strøm på begge på samme tid. I en genstarts-situation stopper markisen hvis den skulle være i bevægelse. Har du et link til disse NC/NO relæer, til en anden god gang... ? Thomas

Nå, ingen svar. Jeg endte med at opsætte 4 IHC relæer, som styrer mine 2 markiser. Hver markise styres så af 2 relæer, et som "kører ud" og et som "kører ind". Jeg kodede en lille funktions-blok, som med et enklet tryk per markise, kan: 1) Kort tryk, markises kører ud (ved næste tryk køres modsat retning) til enden. Trykkes igen mens den kører, stoppes der på nuværende position. 2) Langt tryk, markisen kører ud (ved næste tryk køres modsat regning) men stopper når tasten slippes. Desuden er der indgang for 2-knaps betjening, hvor den ene tast altid kører ud, og den anden altid ind. Der kører i maksimalt 45 sekunder (kan ændres), så stoppes markisen. Funktionsblokken kan aldrig tænde begge relæer samtidigt, og der er mindst 0.4 sekunds pause imellem forskellige operationer/retninger. Det virker perfekt. Markisestyring.ifb

Hej Folkens, Jeg har 2 markiser, som først blev leveret med "intelligente" motorer, forbundet til 230v 3-leder (jord,nul,fase) og en fjernbetjening (en til hver) - ikke nemt at forbinde til IHC. Jeg har nu fået byttet motorerne til 2 Becker motorer, som er forbundet med 4-leder kabel (jord,nul,fase ud,fase ind) og så er sagen jo lige til. Jeg kan naturligvis styre dette med 4 stk 230v output porte eller 4 stk wireless relæer, og så selv kode det nødvendige. ELLER (tænkte jeg), jeg kan købe 2 wireless jalousi standard og så er det jo nemt. Problemet er, at disse wireless jalousi standard er helt "døde" når de forbindes korrekt. De er jo også lidt specielle idet de ikke har nul forbundet og dermed lever at "krybestrøm" hele tiden. Jeg tror motoren har en elektronisk cut-off (endestop) som gør at der ikke kan løbe "krybestrøm". Jeg er helt blank her. Hvad har i andre gjort? Kan man lave et lille kredsløb som kan forsyne jalousi relæerne med strøm? Thomas

Tak for svar Lars, Endte med at fjerne 12volts fordeleren og bare forbinde ledningerne direkte til strømforsyningen - det virkede. I bund og grund har jeg haft 2 12volts fordelere (dem som sidder under strømforsyningen og tillader de runde 12v stik at blive sat i) som har være defekte. Helt usandsynligt og utroligt, men tingene virker nu... Thomas

Hej folkens, Jeg forstår intet - og har seriøst brug for hjælp... - og jeg forstår ellers normalt alting... :-) Har i min tavle monteret IHC-NET switch og IHC-Net Antenne modul (1165). Kommer efter rejse hjem og opdager at mit fjernsyn ikke længere har noget antennesignal. Forklaring simpel, antennemodulet lyser ikke grønt og det gør switch-modulet heller ikke. Første konklusion: Strømforsyningen (LK strømforsyning til montage bag IHC-NET panelet), må tilsyneladende være "gået". 750 kr senere og med en ny strømforsyning (af den nye slags - hvid med grøn forsynings-lampe) monteret i min tavle - forbind og... 1) Når jeg forbinder min switch lyser den ikke grønt og desuden slukker den grønne lampe på den nye strømforsyning (kortslutning). Hmm, mit switch-modul må også være i stykker. 2) Når jeg forbinder mit antennemodul lyser det ikke grønt. Anden konklusion: Der må have været lyn-nedslag/tordenvejr, og den gamle strømforsyning har "brændt" min switch OG mit antennemodul af. Ok, jeg kan undvære switchen, og køber derfor et nyt antennemodul. Nu har jeg altså en ny strømforsyning, og et nyt antennemodul. Det virker stadig ikke - antennemodulet lyser ikke grønt når det får spænding. Jeg måler 230v ind og 12v ud på strømforsyningen. Jeg fatter intet. Er det nogle som har et bud? Hjælp... Thomas

Der er ikke noget som virker... hmm... Er der en som kan give en livline i form af et tlfnr?

Hej Lasse, Har også været igennem en større undersøgelse, købt mange forskellige pærer, og endt med følgende parametre som prioritet: 2700 Kelvin. Køb ikke højere, da lyset så bliver "blåhvidt" RA værdi, så høj som muligt. Gerne 85 eller bedre. Denne værdi reflekterer hvordan vi som mennesker oplever farveægthed af ting belyst af pæren. Er RA for lav "ser" f.eks mad "forkert ud" uden man præcist kan fortælle hvorfor. Spredning, 35-40 grader, ikke mere! En gammeldags halogen spreder lyset med ca 37 grader, og giver derfor en lyskegle med "plet" hvor den rammer. Dette producerer skygger som vi er vant til. Går man højere end 35-40 grader, bliver lyset diffust og man "føler" det "forkert". Dæmpning: Alle mine pærer kan dæmpes, men ikke alle bliver dæmpet. Jeg benytter både wireless IHC dæmpere og UNI dæmpere monteret i tavle. Pæn at se på, når slukket. Nogle pærer har synlige gule "klatter", elle synlige "linser" bladr! Dæmpning går fra hvid til gul. Dette er gløde- og halogen-pærens højborg. Lysets farve ændres imod gul (hygge) når disse pærer dæmpes. Jeg har kun set en led pære som kan dette (Philips) og de gør det ved at "snyde" med 2 lyskilder med forskellige Kelvin værdier inde i pæren (som derfor er meget stor), jeg har ikke set spots med dual K værdier. Jeg havde over 10 forskellige pærer købt og test monteret, før jeg endte med denne: http://nordtronic.dk/da/product/1844-sharp-led-5w-230vac/ Denne pære var min favorit. Den opfylder alle krav undtagen "går mod gul ved dæmpning", men den dæmper alligevel "pænt". Håber det hjalp lidt... Jeg har over 100 spots, og du er velkommen til at komme og kigge :-) Thomas

Er der slet ikke nogle som kan Hjælpe?

Hej Nielsen, Tak for svar... Desværre table du mig undervejs... Kan du fortælle præcise hvilke filer jeg skal oprette, hvor de skal ligger, og deres indhold. Jeg har lavet en .rules fil og en sitemap fil. Jeg kan få min "knap" til at vise sig selv og med "Tryk" som action i UI, og når jeg trykker på den, tænder eller slukker lyset, men derefter "hænger" knappen i "ON"-state og "Tryk" lyser konstant. Det er helt som om rules ignoreres. Her er indhold af min kontor.rules fil: -------- rule "tryk_KontorUL" when Item KontorUL received update ON then sendCommand(KontorUL, OFF) end ------ Og her er indhold af min kontor.items fil: ------ Switch KontorUL {ihc="0x322c5c"} ----- Og endelig, her er indhold af min kontor.sitemap fil: ------ sitemap demo label="Main menu" { Frame label="Frame" { Switch item=KontorUL label="KontorULLabel" mappings=[ON="Tryk"] } } Og bare for at være helt komplet, snippet fra min .VIS fil... ---- <product_airlink id="_0x322b54" product_identifier="_0x4404" device_type="_0x807" name="Kombi relæ 4 tast" serialnumber="_0x640713450014" locked="yes" enduser_report="yes" position="Kontor Spots" icon="_0x85"> <airlink_input id="_0x322c5c" name="Tryk (øverst venstre)" address_channel="_0x1"> <link_from_resource id="_0x325e2d" name="Følg Link" icon="_0x47" link="_0x325f2c"/> <link_from_resource id="_0x32642d" name="Følg Link" icon="_0x47" link="_0x32652c"/> </airlink_input> <airlink_input id="_0x322d5c" name="Tryk (øverst højre)" address_channel="_0x2"> <link_from_resource id="_0x32602d" name="Følg Link" icon="_0x47" link="_0x32612c"/> <link_from_resource id="_0x32662d" name="Følg Link" icon="_0x47" link="_0x32672c"/> </airlink_input> <airlink_input id="_0x322e5c" name="Tryk (nederst venstre)" address_channel="_0x3"/> <airlink_input id="_0x322f5c" name="Tryk (nederst højre)" address_channel="_0x4"/> <airlink_relay id="_0x32305e" name="Udgang" address_channel="_0x1" backup="yes"> <link_to_resource id="_0x32632c" name="Følg Link" icon="_0x4a" link="_0x32622d"/> </airlink_relay> Hvad er det som jeg gør forkert? På forhånd tak, Thomas

Folkens, Jeg har købt mig en Raspberry PI og har fået "kontakt" til min IHC. Jeg har oprettet en items fil, og linket et fysisk output og oprettet et test panel og HabPanel og minsanten det hele virker. Så langt så godt. Men, nu er mit spørgsmål: Hvorledes er anbefalingen til opsætning... Det virker som en utrolig dårlig idé direkte at manipulere med de fysiske outputs, og jeg ville i virkeligheden meget hellere betragte OpenHAB som en alternativ måde at "trykke på knapperne" på, og så lade IHC logikken styre tingene efter der er "trykket på knappen". Så helt konkret: Jeg har en kontakt (Input) som via en funktionsblok tænder et lampested med en timer-sluk og blinker med en diode når den er tændt. Jeg ønsker ikke fra OpenHab at tænde for lampestedet direkte da det vil bypasse al logik. Jeg vil helst fra OpenHab kunne "Trykke på knappen" og så måske aflæse status enten fra diode-output eller fra lampestedet direkte. Altså en ID til at trykke på knappen, og et andet ID til at aflæse status. Skal jeg virkelig selv kode "Sæt ON", vent 150ms, "Sæt OFF" logik i OpenHab eller er der en smartere måde. Hvad gør I andre? Thomas

Hej Kim, Jeg har selv været igennem samme øvelse - det er rimeligt nemt. Du kan dog ikke mikse en klassisk korrespondancekontakt med en IHC kontakt og så få den gamle korrespondance funktionalitet. Begge kontakter skal tilhøre IHC-verdenen om du vil. Det absolut nemmeste som ikke kræver nye ledninger, er at erstatte den ene korrespondancekontakt med et IHC Wireless kombi relæ (som har både tryk og et relæ) og erstatte den anden korrespondancekontakt med et Wireless batteritryk (som slet ikke benytter ledninger). Her er hvad du/i skal gøre: 1) Beslut i hvilken ende som relæet skal sidde (begge ender vil kunne virke). Dette kræver en dåse med "god plads", idet relæet fylder det meste af dåsen ud. Samtidigt kræver det adgang til nul-ledningen (normalt den blå ledning) i denne dåse. (Normalt er den til stede, men strengt taget behøves den ikke i det gamle setup). I begge ender er der på korrespondancekontakten monteret ledninger på 3 poler. En rød pol og 2 sorte poler. Korrespondance-kontakten skifter forbindelsen fra den røde pol til en af de 2 sorte. Typisk vil der ved hver pol være monteret 1 eller 2 ledninger. 2) Du skal nu i den ene ende montere kombirelæet. Ledningerne fra korrespondancekontaktens røde pol monteres på relæets røde pol. Nul-ledningen (typisk blå) som du fandt i dåsen monteres til relæets blå pol. Noter dig, hvilke ledninger som sad på korrespondancekontaktens ene hhv anden sorte pol. Ledningerne fra den ene sorte pol skal monteres til relæets sorte pol, ledningerne fra den anden sorte pol skal blot muffes sammen. Grunden til at du skal holde styr på hvilke ledninger som sad på hvilken sort pol, er at du måske skal bytte om på hvilke som nu går til relæet og hvilke som blev muffet. (Det kommer vi til) 3) I den anden ende, afmonteres korrespondancekontakten helt, og ledningerne som sad på den røde pol, muffes sammen med ledningerne som sad på en af de sorte poler. Ledningerne fra den anden sorte pol muffes sammen med sig selv. Batteritryk som skal monteres her senere bruger slet ikke ledninger. Du har nu opnået det, at du har valgt en af de 4 kombinationer som korrespondance-kontakterne kunne stå i og monteret ledningerne som svarer til denne kombination. Med lidt held vil det hele virke, hvis ikke, skal du forsøge at bytte om på de 2 sæt ledninger som sad på de sorte poler i det gamle setup. Det er lige meget i hvilken ende du forsøger først, og der er kun 4 kombinationer hvor typisk de 2 vil virke for dig. Hvis du har en polsøger kan du gøre dette meget hurtigere, men princippet er det samme. Når du er færdig, kan du derefter montere et batteritryk lige hvor du vil have det. Kombi-relæet har 4 tryk-knapper - og du kan få dem til at styre lige hvad du vil. De behøver ikke nødvendigvis styre relæet (selvom det jo nok er typisk at mindst en af dem gør det). Jeg har netop været igennem en om/til-bygning (som har IHC) men nu har jeg efterhånden også byttet hele den eksisterende installation ud - herunder mange korrespondancekontakter... Thomas

Hej Jesper, Tak for dit svar - med dit lille eksempel fik du faktisk svaret på mit originale spørgsmål. (Triggers ekseveres med det samme). Jeg tror dog stadig der er et issue... Værdi af udgang og status følges ikke ad. Jeg ville mene at man savner en "atomic operation" som kunne sætte udgang til ON og status til XXX, før events blev kaldt. Som det er lige nu, kaldes events så snart udgang sættes til ON (på dette tidspunkt er status ikke opdateret). Hvis en anden komponent har udgang og status som indgang vil han nu få en inkonsistent tilstand. Sagt anderledes: Da det er en trigger på udgang som indirekte ender med at opdatere status, SKAL denne udgang's trigger kaldes først før status igen er opdateret. Hvis man har flere ting på udgang som måtte være afhængige af status har man et problem. Løsningen er vel at lave et enkelt flag som "trigger". Inden da, sætter man alle udgange og status korrekt (hvilket ikke udløser triggere), og til sidst kip'per man sit flag som alle eksterne komponenter så har deres trigger sat op på. Nu er status/udgang konsistent. Men det er til gengæld nok meget besværligt, og nok totalt overkill... Jeg synes man ender i en situation hvor det er svært at vide "hvor master-info" er. Normalt arbejder jeg altid med én master og flere afledte værdier. Det er ikke helt nemt at definere hvad som er master og hvad som er afledt i IHC systemet. Og hvis først man har tabt hvor master-info er henne, har man tabt slaget... I et rum som f.eks. køkken-alrum som mange lamper, ind- og udgange samt dioder for status af andre ting, føler man sig fristet til at skrivet en "RumKontrol" FB som håndterer hele dette rum, og internt have fuldstændig styr på master-data. Er jeg den eneste som har det sådan? Thomas

Ikke tosset... Slet ikke tosset. Men, igen, hvad er rækkefølgen her. Lad os sige at jeg sender en puls på Ingang Toggle, hvilket nu sætter udgang lamper til ON, hvilket (via indgangene) beregner status. Men hvis udgange lamper laver noget andet som regner med at status allerede er sat, så burde man vel sætte intern status før man sætter udgangen... Men løsningen er helt fin, jeg havde ikke lige tænkt indgang men i stedet flere udgange... Thomas

Takker for svar so far... Jeg er temmelig godt hjemme i programmering (kodede mit første program i 1975, og arbejder i dag for Microsoft), og er samtidigt gammel nok til at have lavet Windows programmer dengang vi ikke havde MFC, Delphi, .NET eller hvad ved jeg. Dengang (og stadig i dag) var det blot en state-machine med messages. IHC er blot en simpel version med et message loop, men reglerne er åbenbart ikke kendte... :-) Jeg spurgte netop - som Torben også skriver - at rækkefølgen absolut ikke er ligegyldig og on messages SEND'es eller POST'es er absolut også relevant. Opgaven jeg var i gang med er ganske simpel. En gruppe-kip som kan tænde og slukke - lad os sige 5 - lampesteder samtidigt give en status (ON/OFF/MIDDLE). Dette med så få indgange/udgange som muligt og samtidigt skal FB'en kunne "opdage" at man "udenoms" har ændret en eller flere af de 5 og så automatisk opdatere status korrekt. Fremkald scenarie har denne "tryk som piller indgang" men det er sgu snyd. Det må være muligt at lave det så det virker uden at man skal huske at forbinde tryk til ren info. Desuden er status ikke korrekt hvis man "manuelt udenom" fremkalder et scenarie... Thomas

Du kan som Lars skriver anvende en kort-lang tryk blok. Der er en sådan en med som standard (4.1.15). En sådan blok, har en indgang som du forbinder til dit knap, og derefter har den en "kort-tryk puls" og en "lang-tryk puls/følg" udgang som du kan forbinde til andre FB'ere. 4.1.16 (fremkald scenarie) kan sagtens monteres til 4.1.15 -udgang for at opnå det du vil. I øvrigt, er det også muligt at lave 3 funktioner på samme knap. Kort Tryk, Langt Tryk og Dobbelt-Tryk. Jeg havde præcis samme situation som dig, men blev irriteret over at skulle lave "langt tryk" og valgte derfor "dobbelt tryk" i stedet. Dette bruger jeg f.eks. også på enkelt-knap-lysdæmpere, hvor langt-tryk allerede har en funktion. Her kan dobbelt-tryk bruges til f.eks. at tænde på 100% Dog skal man være opmærksom på, at dobbelt-tryk typisk kræver trådførte kontakter, da de Wireless ikke altid er lige hurtige og kan finde på at "springe" et klik over hvis de kommer hurtigt efter hinanden. Da mine kontakter, hvor relevant, er trådførte har jeg aldrig haft problemer og det er super med muligheden for 3 funktioner i én knap. Jeg uploader lige min DobbeltTryk FB Thomas

Hej folkens, Er der nogle som har dybere information omkring regelsættet omkring afvikling af IHC function-Blocks? Spørgsmålet er lidt kryptisk, man hvad jeg mener er svar på en række spørgsmål som f.eks. 1) Hvis jeg i en FB tænder en udgang som nu vil trigge 2 events (FB'ere) som skal afvikles. Under afvikling af FB 1, sætter jeg en anden udgang som trigger endnu et event... Hvad er nu rækkefølgen? Generelt er der 3 muligheder: Når man fra en FB trigger et ny event, kan dette (a) eksekveres med det samme og derefter returneres til original FB. Det triggerede event kan lægges i kø til eksekvering når indeværende FB er færdig - I så tilfælde kan det lægges ( forrest i køen, © bagerst i køen. Dernæst: Hvis man inden man når til dette event i køen, ændrer udgangen tilbage så det ikke længere er relevant med triggeren, hvad sker så? Igen er der flere muligheder: (a) Hvert triggered event lægges i kø med værdien på det tidspunkt triggeren skete - i så fald vil der i ovenstående situation blot blive lagt en ON efterfulgt af en OFF senere. Men man kunne også have en mekanisme som udryddede disse events som går "mod hinanden". 2) Sammenhæng mellem FB indgange/udgange og fysiske porte - Cirkulære referencer Forestiller man sig, at man gerne vil lave en "gruppe-kip" (lad os blot glemme scenarier et øjeblik). Altså en FB som skal kunne tænde og slukke (on/off) for 3 lamper. 1.version er nem: Vi laver en simpel Kip og forbinder blot de 3 lamper til udgangen. - så langt så godt. Nu kommer der desværre et krav om en status indikering som skal kunne vise: ON, OFF eller "midt i mellem". Med det sidste menes den situation, at man efter at have tændt de 3 lamper via gruppe-kip FB'en, slukker en af lamperne via et andet tryk eller funktion. Vi er nu i den situation at 2 af de 3 lamper er tændt. Dette leder til et par spørgsmål: a) Når man har en udgang hvortil der er linket flere fysiske og/eller logiske enheder, og disse tændes/slukkes fra ekstern side, hvad er så værdien af den udgang i min gruppe-kip FB? Altså, GruppeKip.Udgang = ON. -> 3 lamper ON. (Forventeligt) Ekstern event, Lampe 2 OFF -> GruppeKip.Udgang = ? Det leder til adskillige spørgsmål omkring sammenhængen mellem logiske udgange (f.eks. GruppeKip.Udgang) og så de fysiske. Hvilken vej er flowet i IHC systemet og hvordan håndteres cirkulære referencer? (jeg ved de stoppes, men på hvilket niveau? Samme event eller blot et event i samme FB? eller noget tredje?) Nå, tilbage til GruppeKip. Uanset hvad svaret er på ovenstående, kan GruppeKip.Udgang ikke være 66% on, så vi er nødt til at lave vores FB om, så vi kan "se" de enkelte lamper en ad gangen. Altså: GruppeKip.Udgang1 er forbundet til lampe1 GruppeKip.Udgang2 er forbundet til lampe2 GruppeKip.Udgang3 er forbundet til lampe3 Et enkelt event responderer på samtlige ændringer af de 3 udagnge og kan derefter sætte status til ALLE ON, ALLE OFF, MIDT-I-MELLEM Problemet er blot, at når man fra ekstern kilde (lad os sige en simpel kip direkte til lampe 2), ændrer denne, bliver mit event ikke kaldt. Altså: SimpelKip.Udgang = OFF -> Lampe2 = OFF -> GruppeKip.Udgang2 = OFF Det sidste sker ikke. GruppeKip.Udgang2 bliver i serviceview vist som OFF, men event som responderer på GruppeKip.Udgang2's ændringer kaldes ikke i denne situation. Alt dette leder mig til at spørge... Er der nogle som har "regel-sættet" omkring hvilke actions som kalder hvilke events, og hvilke som ikke trigger FB'ere... Thomas

Hej MaBoNi, Jeg er helt enig med Lars, at isoleret set så er og bliver IHC en luksus/lege ting som på ingen måde kan forsvares økonomisk. For mange år siden (1992) byggede jeg mit hus, og stod med præcis samme overvejelse. Jeg valgte at sige nej (prisen var sjovt nok også 50.000 kr dengang, men det var jo så 1992-kr). Jeg har fortrudt det mange gange siden. Dels irritationen ved at "kontakten ved køkkenet" tænder det gale lampested og at man - trods alle forsøg - ikke kunne planlægge det hele. De værste fejl blev rettet med en elektriker som kom og "omforbandt" korrespondancekontakter, lampesteder osv, men flere gange ville man nu alligevel gerne have noget som var lidt smartere. Her i 2013/2014 lavede jeg så en ombygning/tilbygning af huset, og denne gang kom der IHC (trådført) i alt det nye, og derefter har jeg i samme omgang lavet en kombination af Wireless og trådført i det gamle. Det var dyrt, men også dejligt. I alt er jeg endt med 7 stk 24v input moduler,9 stk 24v output moduler, 3 stk 220v outpiut, 1 stk 400v output, samt en del batteritryk/Wireless relæer. Er par tips (jeg er helt enig med Lars' tips) Trådførte kontakter er mere responsive end Wireless. Med dette menes at Wireless kontakter godt kan have en lille forsinkelse (2-300 ms) som man som menneske kun sjældent bemærker, men som kan have betydning hvis man vil lave f.eks funktioner med dobbelt-tryk (ligesom dobbelt-klik med en mus). Så kan det være at kun trådførte kontakter kan håndtere dette.Kun trådførte kontakter kan have lysdioder. Jeg har lysdioder i samtlige trådførte kontakter - og det er guld værd. Du bestemmer selv hvad dioden skal lave (den har som så intet med kontakten at gøre), men typisk anvendelse er ledelys, on-lys til f.eks lys bag en dør, blik til at henvise opmærksomhed på en timer er ved at løbe ud, eller hvad ved jeg.Hvis du på nogen måde er teknisk anlagt, så skal du programmere systemet selv. Det er slet ikke så svært når man først kommer i gang, Der er mange herinde som kan hjælpe med råd, og du er velkommen til at give mig et kald hvis du vil: 29229886 (Thomas)Indkøb af IHC er billigst på nettet. Jeg lavede en aftale med min elektriker, at jeg indkøbte og leverede alle moduler. Jeg lavede en god deal med en netbutik som i forvejen var billig, og fik derefter yderligere rabat. Langt under hvad elektrikeren kunne levere (selv uden at tage nogen avance).Som Lars skriver. Wireless dimmere er et must ved installation af dimmere. Du skal ikke købe UNI400 dimmere til tavlemontering. De kan ikke "oplyse" om de er tændt eller slukket til IHC systemet og kan ikke indstilles på en fast % fra et IHC program. Sagt anderledes, du har flere muligheder med en Wireless dimmer. Der er omveje til at opnå næsten det samme med UNI400 men det er besværligt.Et ny-byg råd vedr. EL. Tænk dine hverdags-situationer igennem. F.eks. det er aften og du går nu ind i et mørkt soveværelse. Det ville være rart at du ved døren kunne tænde sengelamperne, og når du så har lagt dig at du derefter fra sengen kunne slukke dem igen. I gamle dage kunne man lave et udtag ved gulvet som man kunne sætte sengelamperne til, og så 2 korrespondance kontakter, en ved døren og en ved sengen som styrede denne udgang. Med IHC kan du blot sætte en styret stikkontakt op ved gulvet og så 2 kontakter (trådførte eller Wireless) som styrer stikkontakten. Måske kan du så også lade kontakten have en "sluk badeværelset" funktion når du nu er i gang (man ligger i sengen og opdager lyset brænder på badeværelset)... IHC er smart når først man har oplevet det. PS: I hele min ombygning fik jeg også sat LED lys op - jeg brugte meget lang tid og indkøbte mange forskellige LED spots, før jeg "så lyset". Jeg valgte en NordTronic QuickInstall med 5w LED, 2700k, 40 gr spredning. Den lyser fuldstændig som en halogen. Alle de andre jeg så, var "blå" i en-eller-anden grad. Thomas

Heldigvis har vi jo så salg fra nettet. Priserne der er typisk under hvad VVS/EL kan købe til hos deres grossister (selv med deres rabat)... Ikke at IHC er dyrt, men listepriserne er helt vandvittige - dem er der vel ingen som betaler...

Jeg har netop fået monteret 62 LED spots (230v) af typen NordTronic. www.nordtronic.dk/1431.aspx De lyser virkelig pænt og naturligt (2700kelvin, 40gr vinkel), og nogle af dem dæmpes uden problemer med UNI400 dæmper monteret i tavle. Jeg købte adskillige typer spots og LED pærer før jeg turde forlade halogen-land (og konen skulle også godkende) Kan klart anbefales!! Thomas

Hej kloge hoveder, Jeg har et spørgsmål omkring opdatering af funktionsblokke, gemte funktionsblokke, funktionsblok-bibliotek etc. Lad os antage jeg selv har skrevet en funktionsblok, og har gemt den i biblioteket (eller blot som fil), den er altså "lukket" firkant i Visual. Funktionsblokken er derefter anvendt 999 gange i mit setup, og så finder jeg en fejl i den. Hvordan fikser man det? 1) Retter 999 steder (av!) 2) Retter en gang og gemmer igen i bibliotek og vupti så er den opdateret alle steder 3) Noget helt tredie? Næste spørgsmål: Kan man lave en funktionsblok som bygger videre på andre funktionsblokke uden at "kopiere" disse ind som ens egen? Hvis jeg f.eks. har en kip efterfulgt af en invert for at lave en "samlet" funktionsblok med mulighed for ledelys, kan jeg så gemme denne "kombo" som en ny funktionsblok? På forhånd tak, Thomas