Claus Skovgaard

Du skal udelukkende koble klemme 1 og 2 gennem relæet. Ikke noget med at koble IHC 24/0V til din garageportstyring. Diagrammet viser at styringen selv har en 24V udgang (fx til at trække en fotocelle). Prøv til en start at kortslutte klemme 1 og 2 manuelt for at sikre dig det åbner og lukker porten.

Forbind magnerkontakten til en ledig indgang på et 24/3 input modul. Nu kan du oprette en magnetkontakt i venstre vindue i Visual og derefter forbinde den til din alarm FB som har en indgang for magnetkontaktsløjfe.

@Hmlfc Hvis det var mig, ville jeg finde en manual eller specifikationer på nettet om dit system. Det kan jo være at låsen også kan klare 24V, hvormed du ikke behøver relæ og strømforsyning, men kan bruge en 24V udgang direkte.

Fordi der ikke er ændret i ihc-binding og jeg i øvrigt ikke har fundet noget der skulle forårsage det i den åbne openhab kode. Det virker også besynderligt hvi en timeout skulle ske internt. Fordi jeg opdaterede IHC FW og problemet kom umiddelbart derefter uden at jeg havde ændret min visual eller openhab opsætning nævneværdigt På forum er der flere der efter FW 2.8.3 opdatering har lange svartider med controlleren. Jeg kan dog ikke sige om det har noget med hinanden at gøre. http://www.ihc-user.dk/forum/forums/topic/6099-ustabilt/#comment-41626 http://www.ihc-user.dk/forum/forums/topic/5866-fejl-i-opdatering-af-ny-firmware/?do=findComment&comment=39650

Som Brian skriver skal du bare koble den på "Totalalarm aktiveret". Dog med en invertering FB i mellem (1.1.04.c). Så vil den give 0V når alarmen er tændt og 24V når den er frakoblet.

Fin guide Ejvind. Jeg vil lige komme med et fif til dem som har problemer med svartider eller lign. Efter jeg opgraderede min controller (HW 6.2) til firmware 2.8.3, begyndte jeg ind i mellem at opleve lange svartider (og sommetider ingen respons overhovedet). Jeg kunne se i diverse logs at opdateringer fra controller fint kom over til openHAB, men mine kommandoer kun ind i mellem gjorde. I forum fandt jeg at også at @Raverlution og @Johan Vase også har observeret det samme. Løsningen er en work-around med to elementer. Opjuster timeout på IHC (i openhab.cfg eller ihc.cfg) fra 5000 (default) til 10000. Det løste "blokeringen" og jeg kunne se i loggen at der nu altid kom svar (dog først efter ca. 7 sekunder). Indsæt en rule som sender en dummy kommando til controlleren fx hvert kvarter. Dette løste at den nu aldrig hænger mere. Switch ihc_keepalive "" {ihc=">[ON:0x505a:100]", autoupdate="false"} rule "Avoid IHC command delay" when Time cron "0 12/15 * * * ?" then sendCommand(ihc_keepalive, ON) end Det er en work-around, men det ser ud til at virke. Jeg tror årsagen er IHC-controlleren, og det er jo svært at gøre noget ved.

Er det ikke det man opnår netop i den sidste metode jeg beskriver? Eller misforstår jeg?

Hej Simon. Det gælder for så vidt både OH1 og OH2. IHC bindingen virker i OH2 i legacy mode - dvs du skal lave opsætningen ligesom i OH1 med .items fil (linkning) og .sitemap fil (præsentation/brugerflade). Før nogen opgraderer IHC bindingen til OH2, kan du ikke gøre som du snakker om.

Jeg har også samme holdning. I dette tilfælde at OpenHAB er et add-on til IHC installationen, hvor kommunikationen bør gå via kontakterne eller dedikerede FB'ere, så IHC selv står for logikken og ikke er afhængig af at OpenHAB kører. I forbindelse med de udfordringer I har haft med dette og de forskellige løsninger man kan overveje, vil jeg lige starte med at lave en lille analyse af forskellene mellem IHC og OpenHAB på "kontakt-området". Dette er for at klarlægge mulighederne man har når man skal mappe sine IHC tryk over i OpenHAB. IHC (den fysiske verden): Kontakterne kan ikke vise tilstand Kontakternes "sluttetid" bestemmes af den der trykker Et kontakt kan have en diode associeret, men rent teknisk har denne jo intet med kontakten at gøre IHC (software): Et tryk kan fx fremkalde et scenarie, skrue op/ned for lyd, styre en markise el. og associeres så umiddelbart ikke med nogen (binær) tilstand Et tryk kan have en kip-funktion (simpel eller avanceret) og kan så associeres med tilstanden on/off OpenHAB kontakterne kan konfigureres til at være en: Traditionel kontakt (viser tilstand) Switch ihc_tryk1 {ihc="0x13b6045d"} I OpenHAB vises en kontakt der repræsenterer IHC værdien og samtidig kan ændre den. Trykknap (som IHC) Switch ihc_tryk2 {ihc=">[ON:0x14268d11:100]", autoupdate="false"} Syntaksen ":100" betyder at det linkede IHC input (kan fx være et fysisk tryk) sættes on i 100ms (svarende til et tryk på en IHC kontakt). I OpenHAB vises én knap. Scenarieknap (on/off for Switch item og muligvis mere avancerede ved fx Number item - har ikke prøvet endnu) Switch ihc_tryk3 {ihc=">[ON:0x13b6025f:200],>[OFF:0x13b60360:200]", autoupdate="false"} Som ovenfor, men her vises i OpenHAB to knapper med hver deres link til IHC, som fx kan være til tænd og sluk på en FB. Da der i IHC ikke findes traditionelle kontakter har 3.1 umiddelbart lille værdi i denne kontekst. Ved linkning til FB'ere findes der dog eksempler på konstante input signaler man kunne forestille sig brugt, fx serviceafbryder til alarm FB'en, ude/hjemme tilstand, hjemmesimulering m.m. hvis dette ikke styres automatisk. Konfigurationen 3.2 svarer 1:1 til et IHC tryk, bortset fra man på forhånd bestemmer sluttetiden og dermed ikke kan kombinere fx kort og langt tryk på samme knap. Hvis man vil det kan man benytte 3.3 og i sitemap opsætte strengene på knapperne, fx .items: Switch ihc_tryk3_1 {ihc=">[ON:0x13b6025f:200],>[OFF:0x13b6025f:1000]", autoupdate="false"} .sitemap: Switch item=ihc_tryk3_1 mappings=[ON="Kort", OFF="Langt"] Til sidst vil jeg lige gennemgå hvordan jeg håndterer de situationen med knapper hvor jeg gerne vil have en tilstand associeret. Situationer med dioden sammen med trykket kan løses ved at have et Switch item for trykket (3.2) og et input Switch item for dioden som vises med ikon/tekst i stedet for en knap: .items: Switch ihc_tryk2_1 {ihc=">[ON:0x14268d11:100]", autoupdate="false"} Switch ihc_diode1 "diode" <onoff> {ihc="<0x128f1212"} .sitemap Switch item=ihc_tryk2_1 Text item=ihc_diode1 Ikon og tekst kan opsættes helt som man har lyst til. Denne metode kan også bruges ved avanceret feedback (tekst eller tal). Fx hvor tryk på en knap skifter igennem et antal scenarier. Der er dog et lidt smartere måde at gøre det på, hvor man faktisk tager 3.1 i brug. Man kan opsætte et input link og samtidig to output links. Dermed får man en trykknap med med feedback fra et vilkårligt sted. Bemærk dog at det ikke giver den store mening at linke med en diode der fx blinker. .items: Switch ihc_tryk_feedback "Ventilator" <onoff> {ihc="<0x143cc712,>[ON:0x143cc311:100],>[OFF:0x143cc311:100]"} .sitemap Switch item=ihc_tryk_feedback Man kan linke ON/OFF til samme (kip tryk) eller direkte til tænd/sluk på en FB'en. Og input link kan fx være "lys indikation" fra en lampen. Jeg håber det kan bruges. Det har løst de fleste af mine behov indtil videre. Og bemærk at der ikke kræves nogen brug af rules. Mvh Claus

Det ser ud til at du har kontakt Prøv at kigge dette forum igennem for hjælp til opsætning samt eksempler: http://www.ihc-user.dk/forum/forums/forum/46-openhab/ Mvh Claus

Alternativt blot en blink funktion med en invertering bagefter til dioden, som vedhæftede. blink-konstant.vis

Det vil jeg mene du sagtens kan gøre. Men prøv først uden modstanden. Jeg synes ikke altid det holder med den minimumsbelastning. Du kan også bruge metoden ved visse LED pærer som skulle være dæmpbare, men som viser sig ikke at fungere med LKs lysdæmpere. Det har jeg selv gjort ved bl.a. mine udendørs væglamper, hvor jeg i en af lamperne har en halogenpære svarende nogenlunde til farve og lumensværdi for LED pærerne.

Jeg har selv brugt Siemens PDM-I12 med god succes. Den er dog ikke så udbredt herhjemme, men kan fås i detailhandlen fx her: https://www.vvsfittings.dk/magic-detektor-pdm-i12-12-meter.html Der findes en "pet clip" til den: https://noeglesmeden.dk/detektor-tilbehor/2080-vanderbilt-po-cl-pet-clip-for-pdm-i12.html

Hej Thomas Samtalen her går ikke som sådan på v2. Jeg venter selv med at gå i gang med v2 til den er mere eller mindre released, så derfor har jeg ikke så megen viden om den pt. Men jeg mener at du har ret i at mht. IHC binding skal den konfigureres som v1.8. Certifikatsnakken herover skulle ikke være nødvendig længere (siden 1.7.0) ifølge udvikleren. Derfor burde det bare være følgende: tilføj IHC binding configuration (i v1.8 er alle samlet i configurations/openhab.cfg, i v2 er der vist en separat for hver binding?) Tilføj items (se binding wiki og evt. andre tråde her på forum Tilføj items til en sitemap Håber det kan hjælpe dig videre. Ellers må du spørge mere specifikt. Mvh Claus

Hej og velkommen Vedr. forbindelsen til controlleren: Hvis du har en seriel com-port på din PC bruger du bare den sammen med et stik. Hvis du kun har USB, skal du have fat i en USB->RS232 converter (a la denne http://www.mytrendyphone.dk/shop/usb-to-rs232-16000p.html). Der er flere tråde her på siden omkring forbindelsen og evt. problemer. Fx denne: Vedr software: Se LK download side (http://www.lk.dk/support/professionel/ihc-software/). Det er vel nok en "Visual 1" du har?) Vedr. PIR: Servodans 12V PIR er vist udgået - ved ikke om der er alternativer, men du kan fx bruge deres 24V 41-262 i stedet. Du behøver bare at flytte ledningerne fra 12V backup modul kredsen over på den alm. 24V kreds som controller og input/output moduler kører med. Mvh Claus

Sorry for the late reply - I didn't see your answer. I now realise that your choises made during development of the binding are based on a slighty different paradigm than mine. In my setup, I would like the IHC controller to be fully in charge of the alarm and electrical installation based on physical and virtual inputs and thus be able to function 100% independently of OpenHAB. This means OpenHAB in my case will be an add-on to the IHC installation. This also means I want to avoid setting IHC outputs directly from OpenHAB. It also implies that logic concerning the electrical installation should be placed on the IHC controller, not in OpenHAB. By setting an output directly in OpenHAB would bypass the logic in the IHC controller and thus make complications. So my question came from this background. I would like to push a virtual button in OpenHAB same same way as a physical button, and then read the status from somewhere else. It can be hacked by adding a IHC FB for this purpose, but I wondered if it was possible without. In your case, I expect by your answer that you have most of your "IHC/electrical logic" in OpenHAB and merely use the IHC controller as a proxy!? Best regards Claus

Jeg kan heller ikke se fejl i dit projekt. Hvis Hennings forslag ikke løste det, kan også være uret på din controller der ikke passer? Du kan jo tjekke efter skumring (og inden kl. 20) om dine spots tænder ved PIR aktivitet, for det burde de ikke før midnat p.g.a. ur-spærringen.

Hej Peter (og Peter) Jeg har kørt med OpenHAB (og IHC) i 1½ år nu og er meget godt tilfreds. OpenHAB sammen med RPi giver nærmest uendelige muligheder for at koble tingene sammen, også uden at det behøver omkring skyen (som jeg mener er noget af det vigtigste). Dog kan man hurtigt få brugt en masse tid på det og læringskurven er stejl i starten. Heldigvis er der mange gode eksempler at finde rundt omkring. Kompleksiteten og læringskurven er noget af det de prøver at forbedre i v2. Det burde ikke blive det store problem at opgradere til den tid. God fornøjelse med jeres setup :-) Dette er min nuværende hovedmenu:

OK, men som sagt har du haft den del med hele tiden.

Hvad har du ændret her? Den ligner til forveksling den jeg postede - altså uden "Dag" tjekket under Skumring.

Hej Torben Jeg har kigget på det, og du har rettet problemet med energiudgangen et andet sted - i underprogrammet "Dag" hvor du har indsat en betingelse for at håndtere det. Det skulle jo stadig virke fint i forhold til den originale blok hvor den ukritisk sætter Energi -> ON ved masterbeskeden "Dag". Mvh Claus

Jeg har rettet master til og vedhæftet den. Det synes at virke fint nu. Jeg kan ikke se en fornuftig ide med at spørge på om masterbesked er <> Dag, så det tjek er fjernet. Mvh Claus masterTilrettet.vis

Jeg har undersøgt det nærmere, og fandt ud af at fejlen kun er i Torbens tilrettede udgave som jeg også bruger. I den originale funktionsblok er der ikke noget tjek, så måske var det noget @TorbenSørensen tilføjede af en eller anden grund?

Hej Søren Jeg har også observeret fejlen med velkomstlys der tændes (selvom skumring er off). Jeg har nu kigget i Bolig Master blokken, og kan se at Masterbeskeden "SkumringPassiv" kun sættes hvis den nuværende masterbesked er forskellig fra "Dag" !? I mit setup starter dagen med timer 06:45 (fb'en Dag og Nat). For tiden går skumring off ca. 08:15. Som oftest er der stadig nogen hjemme der, hvorfor masterbeskeden så stadig vil være "Dag" og "skumring off" dermed ikke kommer ud til bolig rumstyring fb'erne som er dem der gemmer tilstanden til brug fx i forbindelse med velkomst. Er der nogen der har en ide om hvorfor der tjekkes på om masterbeskeden er "Dag"? Det virker ret tilfældigt, for er man ude af huset inden skumring går off (og masterbesden derfor er en anden, fx "SlukAlt"), så vil det jo virke fint.. Mvh Claus

Alternativt OpenHAB med IHC binding og enten Google Calender eller my.openHAB (IFTTT) binding.