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