EjvindHald

Jeg har selv både IHC og Hue installation. Hue laver en meget fin app, som kan mange ting inkl. setup af scenarier. Men i mine øjne ender man nemt op med mange apps - typisk en pr. producent som fx Philips, Velux, Danfoss, Somfy (gardiner), Nest samt en del produkter helt uden integration og som stand alone produkter. Det er her, at jeg synes, at IHC er stærk og fleksibel med mulighed for at integrere på tværs af produkter, så man undgår isolerede løsninger. Hvis man dernæst kombinerer det med Hennings suveræne setup, så mener jeg, at man har en fin og fleksibel installation, der er lige så nem at ændre som Hue pærerne. I min installation har jeg produkter fra bl.a. Velux, Wavin, Somfy (gardiner), Alux (markiser), EcoBee og Nest termostater, LK (inputs, outputs, dimmere, komplet IHC alarm, røg, mm), Axis kameraer, Philips Hue, Sensus vandmåler, Resol solvarmestyring, styring af nødstrøm, solcelleproduktion, diverse 3. parts PIR uden falske alarmer, Air Condition, VOC måler og DanTherm ventilation. I øjeblikket hjælper Henning mig med med at lave tilbagemelding til IHC fra min portåbner, som er en ret billig model fra Life. Dvs. også her ender jeg forhåbentlig med ægte to-vejs integration. IHC er kernen i at styre mange af ovennævnte produkter og uden IHC vil jeg i stor udstrækning have produkter, som ikke var integreret. Man kan integrere dem på anden vis som fx IHC Captain eller openHAB, men jeg foretrækker, at det er IHC, som er det bærende, hvor det er muligt. Med IHC som kerne kan man benytte fysiske tryk eller automatik via funktionsblokke på tværs af producenterne til automatisk styring. Fx. at kort tid efter IHC alarmen er slået til, så lukker porten, kameraerne tænder og ventilationsanlægget sættes på minimum. Og der er mange flere eksempler. Den endelige beslutning må være en afvejning af behov og pris. Jeg foretrækker selv produkter, som er integreret.

Jeg tror ikke, at det er problemet. Check brugernavn, pwd, timeout og ip adresse en gang til. Brugeren skal være typen admin i controlleren, og det bør være samme subnet.

Enten kan Mikkel implementere det i IHC Captain eller du kan skifte til openHAB. Her kan du selv lave dine regler, som laver det du ønsker med Hue. Fx. har jeg selv en Hue lampe til at blinke grøn 30 sekunder, hvis ringeklokken ringer. Eller en anden meget synlig lampe til konstant at blinke rød, hvis IHC alarm er udløst.

Hej I vejledning til sokkel som hører til røgalarm LK nr. 120B1287 er der vist 4 forbindelser: Par 1: nul og out 24 som forsyning med mulighed for afbrydelse til brug for reset Par 2: nul og input 3mA til indikering af alarm Set uploaded billede med rød firkant. Jeg står nu og mangler én ledig ledning i et IHC link 10 kabel, så derfor dette spørgsmål: Kan jeg sløjfe nul ude i sokkelen, så der kun skal trækkes i alt 3 ledere til denne røgsokkel? Både outputmodul og inputmodul er forsynet via backup 24 volt, og jeg har kun ét backup modul.kupmodul.

Netop denne besked er speciel og skal konfigureres i Administrator og ikke i Scenedesign. Der kan kun være 1 modtager.

God point - jeg har også købt en 2 kanal dimmer, som snart skal monteres. Men det er rigtig, at der nævnes en effekt på 15,1 watt, og det er jeg først blevet opmærksom på nu ifm. dit spørgsmål. Derfor satte jeg mig for i dag at prøve at måle den faktiske effekt i dimmeren. Jeg brugte en Sparometer til at måle med - se link - som skulle have en god præcision også ved lave belastninger. Her målte jeg 2 pærer til at bruge hhv. 2,9 og 4,2 watt. Dernæst måler jeg dimmeren tilsluttet men uden lamper tilknyttet til 1,4 watt. Med en Fluke måler viser amperen på 24 volt forsyning nærmest nul. Herefter tilslutter jeg pærerne, og kan regulere op og ned og ved en 100 % belastning måles 8,9 watt. Dvs. konklusionen er, at stand-by effekten er 1,4 watt, som stiger til 1,8 watt (8,9 - 4,2 - 2,9) ved en samlet belastning på 7,1 watt. Så der er langt til det opgivne forbrug, og mit gæt er, at dette høje forbrug gælder ved høje belastninger. Dimmeren understøtter i alt 2 x 200 = 400 watt led. Ovenstående hjælper dig nok ikke med din varmeberegning til tavlen, men giver dog en indsigt i det faktiske mønster på afsat effekt.

Ja, det er der flere, som har gjordt ved at lave reverse engineering på IHC SOAP protokol. Se eksempelvis openHAB her og IHC Captain her. Info om integration til Home Assistent er her. Mht. Modbus kender jeg ingen, som kan kommunikere fuldt ud til IHC denne vej via RS485. Enten fordi det ikke er muligt, eller også fordi protokollen ikke er tilgængelig. Og der er ingen mulighed for reverse engineering via fx ServiceView.

Hej. Jeg har lavet en guide her, som måske kan være en hjælp. Hvis du blot installerer bindingen IHC/ELKO lavet af Pauli fra PaperUI menuen, og det er openHAB version 2.5.x, så behøver du ingen add-ons eller ihc.cfg fil. Hvis du gerne vil styre det via Google Home, skal der sættes nogle ekstra såkaldte "tags" på, og det er nemmest at gøre i filer. Det hele er vist med eksempler i mit best practice indlæg. Hvis du kører visility parallelt med openHAB, så har du to apps, som poller din controller samtidig. Det giver selvsagt en større belastning og afhængig af controller model, opdateringsfrekvens og antal items, som skal monitoreres, giver det måske et performanceproblem for din controller.

Somfy RTS har ganske rigtig ingen tilbagemelding, så derfor har jeg monteret en mini magnetkontakt på gardinet, der giver tilbagemelding til IHC. Somfy motorer og fjernbetjening type io-homecontrol har ægte tilbagemelding med tal mellem 0 og 100 ligesom en dimmer. Det kan bl.a. forbindes til velux klf200 modul, der igen kan integreres med openHAB. Og openHAB kan sende status videre til IHC. I mit tilfælde var jeg nødt til at købe RTS motorer, fordi mine gardiner kun er 45 cm brede, og der kan jeg kun bruge RTS motorer. I mit setup er det fortsat IHC, som bestemmer, og dermed er det integreret med samme muligheder, som Henning nævner. Men Hennings forslag er bestemt også smart, og så slipper man for at sætte sig ind i openHAB.

Det kan gøres på flere måder, og jeg beskriver her min opsætning. Jeg har gardiner med Somfy motorer med trådløs fjernbetjening af typen RTS. For at opnå den funktionalitet som du beskriver, har jeg installeret openHAB med binding til RFXCOM - se link - + købt device til formålet - se link. openHAB er naturligvis også forbundet til IHC via en binding vist her. Dette kører lokalt og har derfor ingen afhængighed til cloud, hvilket jeg foretrækker. Via simple regler i openHAB knyttes svagstrømstryk til op/ned/stop for gardiner. Sondring mellem kort og langt tryk er bedst at lave i IHC, fordi det er tættest på hardwaren - trykkene - og dermed mest stabil.

Som @Kandersen korrekt skriver, så bliver der ikke oprettet nogle filer, når du bruger paperUI grafisk menu. Derimod bliver det gemt i en lokal database. Ikke alle muligheder er tilgængelig i denne menu, men kun via filer. Derfor støder du hurtigt ind i en begrænsning, og dermed skal du alligevel bruge filer, og det er også meget nemmere. Fx. copy/paste af linier med mere, som man ikke så nemt kan gøre i det grafiske interface. Se eksempel i mit indlæg om best practice for openhab. Jeg foreslår, at du laver det med filer, som i mit eksempel. Hvis du fortsat har problemer, så skriv igen og vedlæg filindhold.

Prøv at læse denne her tråd igennem - der er mange gode pointer. Den 9. januar 2019 havde jeg et indlæg i tråden, hvor jeg vedlagde en simplificeret udgave til wireless lavet af Henning. Den har jeg benyttet siden, og det reducerede problemet for mig med wireless, men nu - godt 1 år senere - må jeg konstatere, at jeg fortsat har det en sjælden gang imellem. I disse tilfælde løses problemet med en controller restart.

Jeg foreslår, at du kontakter @Henning Pedersen som vil kunne give dig god guidance til at få alt relevant med.

Niko bliver brugt i dette udstillingshus lige udenfor Roskilde: https://www.fremtidenshjem.dk

Så har jeg ændret formateringen og præciseret navne på foldere.

EDIT 25. januar 2021: Nedenstående er baseret på Openhab version 2. I Openhab version 3 er menuen anderledes, og paperUI er erstattet af anden funktionalitet. Hermed et indlæg om Best Practice for openHAB binding version 2 som opfølgning på mit tidligere indlæg - se link her Først en stor tak til @Pauli Anttila for denne IHC Binding til openHAB ver 2. Dette indlæg er ikke ment som den nemmeste måde at komme i gang med openHAB 2 på. Tværtimod kan det virke lidt besværligt, men det giver mig mulighed for at styre min installation helt præcis til mindste detalje samt en nem måde at reetablere opsætningen i tilfælde af fejl. Som hardware kan man med fordel bruges enten Raspberry PI, Synology NAS eller Ubunto installeret på en PC. Gennem årene har jeg benyttet alle 3 varianter, og jeg er nu endt med Ubunto installeret på en ældre laptop med en driftssikker SSD disk. Det vil være nødvendigt at lære lidt om Linux, hvis man ikke kender det. Men det er god viden at tilegne sig.... På det valgte hardware installeres Oracle Java version 8 og dernæst følg installation af openHABian. Se link I openHAB kan man bl.a. have disse integrationer, og jeg fokuserer her på dem, som er mærket med rød boks. Efter installationen skal man angive ønskede integrationer - såkaldte bindings - og det gøres via paperUI, som default kan findes på http://lokalIPadresse:8080 Her vælges IHC Binding, som installeres - se skærmkopi: Nu kan man benytte funktionalitet i paperUI til automatisk at identificere input- og outputs i sin IHC installation, men jeg bruger ikke dette. I stedet angiver jeg alt i filer, fordi det - i det lange løb - er det nemmeste at arbejde med. Filerne skal lagres i /etc/openhab2/conf/things/ folderen - dog ikke Synology, som bruger andre foldere. Things Først angives såkaldte Things, som er en forbindelse til fysiske ting - i dette tilfælde IHC Controller med forbundne enheder. Herunder ses eksempel på en ihc.things fil: Benyt ikke Notepad i Windows til editering, men brug i stedet Visual Studio Code, som er gratis og med sikkerhed uden virus. Windows Notepad laver nogle karakterer i filen, som ikke fungerer i Linux. Bemærk "createChannelsAutomatically=false", hvilket gør, at bindingen ikke selv finder input og output. Læs mere her Hvis direction ikke er udfyldt, kan den pågældende enhed - fx en stikkontakt - både ændres og aflæses af openHAB, hvis den ændres af svagstrømstryk. Dvs. en statusændring kan sendes fra openHAB til IHC og omvendt. resourceID er entydig decimal værdi fra Visual, og man kan se den ved at holde Ctrl knappen nede, mens musen køres henover fx et svagstrømsinput. direction="ReadOnly" betyder, at openHAB kun kan aflæses status og ikke sætte den. Í mit tilfælde er det en stikkontakt. direction="WriteOnly" betyder, at openHAB kun kan sende status, men modtager intet ved ændring. I mit tilfælde et det input og output tryk, som jeg sender til. pulseWidth=80 betyder, at der kun sendes en puls på 80 millisekunder, hvorefter signalet sættes tilbage. I mit tilfælde er for at gøre det samme som ved fysisk at trykke på et svagstrømstryk. I det viste eksempel kan jeg få stikkontakten til at tænde og slukke, men det sker ved at simulere tryk på et svagstrømstryk. På den måde aktiverer jeg relevante fb'ere i IHC i stedet for blot at ændre output status. Items Dernæst skal man oprette en ihc.items fil i folderen /etc/openhab2/conf/items/. Eksempelvis således: Switch KaelderVaerVestStikkontakt "Stikkontakt" <poweroutlet> {channel="ihc:controller:haldIHC:ThKaelderVaerVestStikkontakt,ihc:controller:haldIHC:ThKaelderVaerVestTrykNederstHojre,ihc:controller:haldIHC:ThKaelderVaerVestTrykNederstVenstre"} Items er logiske objekter i openHAB, som har en status, og man ændre denne status. De kan forbindes til en thing, som viste i eksempler herover. Bemærk at der er nævnt 3 Things i channel med komma imellem. Det betyder, at modtagne og sendte status er forbundet til alle 3 Things. Men fordi vi har ReadOnly og WriteOnly i Things definitionen, så er det ikke alt, som sendes eller modtages fra IHC Controlleren. Det virker umiddelbart lidt besværligt, men fordelen er, at man altid vil have en openHAB, som er i sync med IHC også ved almindelig fysisk betjening samt at fb'ere aktiveres i stedet for blot at overskrive et output. Item i eksemplet ovenfor - KaelderVaerVestStikkontakt - skal man dernæst placere i en fil kaldet ihc.sitemap som vist i denne linie: Switch item=KaelderVaerVestStikkontakt hvorved man kan tilgå det via en browser og se og ændre status. Se eksemper herunder: Det vil default også være port 8080 på aktuelle ip adresse. En variant af switch er kip. Kip er karakteriseret ved, at du som bruger kan se, om der er lys eller ej (status) og du bruger dette til at beslutte, om du vil tænde eller slukke. Når det kommer til smart house, er det ikke altid optimalt, at aktuel status skal bestemme, om man vil tænde eller slukke. Ved kip forbinder jeg derfor altid to channels til hhv. Tænd og Sluk i min fb, og så lader svagstrømstrykket fortsat være forbundet til Kip i fb'en. Herved kan man undgå nogle udfordringer med kip. Dimmer Brug af lysdæmper i smart house er bedst med tilbagemelding, og det vil sige enten IHC wireless Ø80 eller den nye LED rs485 tavledimmer. I begge tilfælde skal det i openHAB være typen dimmer og resourceID skal pege på "Lys niveau" i Visual. Se eksempel tidligere med "ThKaelderVaerVestDimmer". ihc.items skal være: Dimmer KaelderVaerVestDimmer "Spot i loft dimmer" <light> {channel="ihc:controller:haldIHC:ThKaelderVaerVestDimmer"} ihc.sitemap skal være: Slider item=KaelderVaerVestDimmer hvorved man får en "slider" som vist i tidligere skærmkopi. Det var det! - så er man i gang med smart house til IHC med detailkontrol og fuld 2-vejs sync af ændringer. Tilmed er der rigtig mange muligheder i openHAB, og kan jeg ikke gennemgå alle her.

Undlad at opdatere til 2.7.220 - det vil give problemer med en ustabil controller. Hold fast i den version du har eller opgrader til 2.7.199, som indeholder en opgradering af radiomodulet.

Til både Home Assistent og openHAB er der adapter, så du kan forbinde til IHC og etablere smart house funktionalitet. I dit nye hus med Visual 1 er alt formentlig ledningsført, hvilket gerne skulle medføre meget stabilt setup uden wireless udfordringer. Med en nyere controller vil du dermed kunne få et godt setup for en minimal udskrivning. De nævnte firmware problemer skulle iflg. LK være løst nu. Du vil altid kunne argumenter for og imod forskellige produkter, men stod jeg i dit sted, ville jeg vælge en nyere IHC controller og så med en af de nævnte overbygninger eller IHC Captain.

https://www.se.com/dk/da/product/820B1250/lk-ihc-led-dimmer-2-kanal-din-36mm/

Yes, you are right. Thanks for clarifying this.

Question to @Pauli Anttila: I just discovered the concept of "Location" in paperUI, where you can have several tabs in the Control menu. Each Thing can be associated with a location - eg. bedroom - and it shows up in paperUI. This is implemented in several bindings such as Hue and Mqtt.(see Hue example here with Entrance) Can this also be configured for each Thing in the IHC binding? I as asking because I have + 100 Things, so this options would be very nice.

Hej Jeg hjælper gerne og vil foreslå, at du læser mit forrige indlæg igen. Det skal være dimmer både i Things og Item, men i dit sidste indlæg benytter du fortsat Switch. På min vedlagte skærmkopi kan du se, hvordan jeg har sat min op. Din dimmer Thing i openhab skal forbindes til 'Lys niveau', og så skal du forbinde til input eller en fb, som skruer op eller ned for lyset. Jeg bruger ikke LK's fb til wireless - i stedet bruger jeg Henning Pedersen's test fb, som er uploaded i mit indlæg her fra den 9. januar 2019. Det er for at få bedre stabilitet med wireless dimmere. Jeg anbefaler ikke at bruge paperUI til det, fordi den automatiske detektion kun finder input og output for at undgå, at der bliver for mange autodetektet. Det er også fint, men hvis man addressere en fb direkte, er det ikke så velegnet. Derfor er det nemmeste at bruge filer - og kun filer - til at beskrive Things, Channels og Items. Dette indlæg her på sitet er godt at læse igennem for at lære lidt om binding version 2 og opsætning i filer. Læs også Pauli's udmærkede dokumentation med eksempler her.

Hej igen Jeg kan se på ovenstående, at du bruger binding version 1 - jeg har netop opdateret mit indlæg her og præciseret, at det vedrører binding version 1. Mit forslag er, at du installerer openhab version 2.5, som er frigivet for kort tid siden. Heri er den senest binding version 2 indbygget, og den kan benyttes. Det betyder også, at dine filer skal sættes op på en lidt anden måde, og du skal bruges Things og Channels. På et tidspunkt laver jeg muligvis et indlæg med en generel vejledning. Til dit konkrete problem: Din lysdæmper er i openhab termer af type dimmer og ikke switch. Du har lavet den som switch, og de kan kun være on eller off, hvorimod en dimmer har en værdi mellem 0 og 100. Eksempel fra min Things file: Type dimmer : ThKaelderVaerVestDimmer [resourceId=13166941] //Status dimmer og items for den samme: Dimmer KaelderVaerVestDimmer "Spot i loft dimmer" <light> {channel="ihc:controller:haldIHC:ThKaelderVaerVestDimmer"} og sitemap: Slider item=KaelderVaerVestDimmer Det er en god ide først at være sikker på, at det fungerer i openhab, før du pågynder Google integrationen - et skridt ad gangen :-) Hvis du vil starte IHC scenarier, skal du nok lave en puls til en relevant fb, som aktiverer det pågældende scenarie. Det gør du med direction="WriteOnly" - se eksempel: Type switch : ThKaelderOpbvrumTrykOverstVenstre [resourceId=25434, direction="WriteOnly", pulseWidth=80] //Svagstrømstryk ØV kip Det svarer til dit eksempel >[ON:2442769:100] i binding version 1. God fornøjelse Ejvind

Mht items så kan man godt tilknytte on og off til samme input tryk ved kip. Dog vil jeg anbefale at forbinde til hhv. tænd og sluk i fb’en. ID på disse skal du finde manuelt og bruge. Vedr. lysdæmper så er 1 tryks ikke så velegnet til smart home. Det bedste er wireless ø80 ver 2 med tilbagemelding. Alternativt den nye LED rs485 tavledæmper, som snart kommer i handlen.

Jeg har en ekstra, som du kan købe. Hvis du er interesseret, så send mig en privat mail.