EjvindHald

Der er flere, som har haft udfordringer med opgradering af en hw7 controller til firmware 03.03.18. Derfor besluttede jeg at være lidt forsigtig og gjorde følgende:
Fandt en ældre ledig bærbar PC, som jeg installerede Ubuntu linux distribution på. Det var faktisk overraskende nemt med simple peg og klik. Tog SD kortet ud af min hw7 controller og kopierede alle filer til PC'en. Der var ingen 'hidden' filer. Formaterede et gammelt 64Gb SD kort i ext3 format, som også er formatet, der bruges i LKs sd kort. Herefter kopierede jeg alle filer til det nye kort og satte det i controlleren. Controlleren blev genstartet og startede fejlfrit op med mit eget SD kort - se skærmkopi. Herefter opgradede jeg firmware til 03.03.18 på mit kort og det fungerede fejlfrit. Mit eget kort brugt til den første test blev atter fjernet og erstattet af det oprindelig kort fra LK, hvor jeg ligeledes foretog firmware opgradering uden fejl. Så det er muligt at have sit eget SD kort dels til aftestning af ny firmware før endelig installation, dels som backup, hvis det originale LK kort skulle blive defekt.
 

Edit: Det er efterfølgende gået op for mig, at man ikke kan konkludere, at sd kortet indeholder firmwaren. Jeg kontrollerede ikke firmware nr før opgradering nr. 2. Der er kun én fil på kortet, som hedder "stored". Den fylder i mit tilfælde kun 194 KB, hvilket nok ikke kan rumme firmwaren - selv i compileret format.

Der er flere, som har haft udfordringer med opgradering af en hw7 controller til firmware 03.03.18. Derfor besluttede jeg at være lidt forsigtig og gjorde følgende:
Fandt en ældre ledig bærbar PC, som jeg installerede Ubuntu linux distribution på. Det var faktisk overraskende nemt med simple peg og klik. Tog SD kortet ud af min hw7 controller og kopierede alle filer til PC'en. Der var ingen 'hidden' filer. Formaterede et gammelt 64Gb SD kort i ext3 format, som også er formatet, der bruges i LKs sd kort. Herefter kopierede jeg alle filer til det nye kort og satte det i controlleren. Controlleren blev genstartet og startede fejlfrit op med mit eget SD kort - se skærmkopi. Herefter opgradede jeg firmware til 03.03.18 på mit kort og det fungerede fejlfrit. Mit eget kort brugt til den første test blev atter fjernet og erstattet af det oprindelig kort fra LK, hvor jeg ligeledes foretog firmware opgradering uden fejl. Så det er muligt at have sit eget SD kort dels til aftestning af ny firmware før endelig installation, dels som backup, hvis det originale LK kort skulle blive defekt.
 

Edit: Det er efterfølgende gået op for mig, at man ikke kan konkludere, at sd kortet indeholder firmwaren. Jeg kontrollerede ikke firmware nr før opgradering nr. 2. Der er kun én fil på kortet, som hedder "stored". Den fylder i mit tilfælde kun 194 KB, hvilket nok ikke kan rumme firmwaren - selv i compileret format.

Dit regnestykke fejler ikke noget, men dine forudsætninger er ikke korrekte.
Den opgivende effekt på telestaten er ved drift. Forbruget er væsentligt højere ved start, jeg plejer at regne x6. Startstrømme er ikke kun et splitsekund, der går op til 2 minutter før strømforbruget er nede på de 2w. Dermed skal du også seriøst overveje enten, at styre dine telestater intelligent eller købe en ekstra strømforsyning til dem.
Ovennævnte er også årsagen til at mange får problemer med at deres IHC installation "går ned" når boligen begynder at kalde på varme om efteråret.

Nej, men det har producenten.

 
Enig, men nu skriver jeg ikke at de kører med fuld startstrøm i 2 minutter, men at der går op til 2 minutter før forbruget er nede på de 2w.

I have 63 switches in my ihc.items file, and they are all using this feature. Besides that I have a few contacts and numbers, and they have mainly readonly definition. One number for the level in my ventilation system has ReadWrite definition.
The real use case is that this feature provide a very simple and reliable method of having correct status in openHAB regardless of whether a change was initiated by openHAB UI or a physical input push button attached to IHC. In openHAB it can be quite cumbersome to detect the origin of a change, and suppress additional activities if it was initiated by a physical button, because then everything is done. Before I discovered you smart binding options, I tried a variety of rules including wait, circular refences and sometimes also unintended endless loops inside openHAB. I wrote a posting about this, and it can be read on here (use Chrome to have English translation).
With this feature I can map my entire IHC installation quite simple without the need for rules. Rules are only needed, when I would like a special functionality. It is important for me that IHC is the master and holds all relevant logic and status. There are several reasons for this and one is that the installations in the house must always be working without being depending on 3rd party software such as openHAB.

Det hele er fint beskrevet i LK's vejledning, som du kan finde her.

Det hele er fint beskrevet i LK's vejledning, som du kan finde her.

Update 12.3.2019:
Binding has been merged to openHAB main repository and will available in 2.5 version. Before that, new version can be found from official openHAB snapshot builds.
Before official add-on documentation page is updated, binding documentation can found here.
 
NOTE. If you have used older beta versions of the binding, beware that there has been some breaking changes lately:
Controller address parameter is not anymore ip, but hostname "-channel" suffix is removed from channel types. E.g. switch-channel is just switch.  
###########################################################################################################################
 
Even openHAB 1 IHC binding has been rock solid for many years, I finally decided to port the binding to support openHAB 2 features.
Latest version: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.ihc/2.4.0-SNAPSHOT/
Documentation link
Some improvements / features:
By default, binding create channels automatically from project file (currently all dataline_inputs, dataline_outputs, airlink_inputs, airlink_outputs and resource_temperature). Auto creation can be disabled, and channels can be created manually (then all resource id's are supported). Support both Paper UI and thing files configuration. Channels for basic controller information (state, SW and HW version, controller uptime, etc). Trigger channels support (button short press, long press and extra long press). Support multiple controllers (those who have e.g. two controllers environment).  

 

Hvis vi ved det hele, så kan opgaven vel burges som et klassisk eksempel på hvorfor nogle har dårlige oplevelser med IHC.
"Kunden" fremstå på ingen måde afklaret i sine ønsker, hvilket peger mod mangelfuld eller direkte dårlig rådgivning - jeg hælder nok mest til det sidste. Dermed sender "mester" problemet videre til hans personale, som ikke har en kinamands chance for at lave et tilfredsstillende program til kunden. = utilfreds kunde = sur mester = dårligt arbejdsmiljø.
Hvilket igen giver anledning til at fremhæve at det vigtigste arbejde er en ordenlig afklaring af "kundens" ønsker og krav.
 

Jeg har endnu ikke oplevet impulsive genstarter - alt er foreløbig kørt stabilt inkl. openhab og Homekit.
Dog ser der ud til, at æ, ø og å ikke kan bruges i beskeder i SMS modemet. Jeg har meldt det til LK, men ved ikke, om de gør noget ved det. Hvis der er andre, som kan påvirke LK, vil det være fint. Det skulle være nemt at efterprøve.
Der er med sikkerhed ikke brug for en KeepAlive rule eller forøget timeout interval til openhab som i de seneste versioner af firmware 2.x

Mig bekendt understøtter smtp serveren hos one.com ikke port 110 af sikkerhedshensyn. Hvis du vil bruge IHC mail, så tror jeg, at det er bedst at bruge smtp server hos din internetudbyder.
Jeg bruger selv openhab + ihc sms modem. 

Ja

Mange tak - godt forslag, som jeg vil overveje. Men den giver 1-10 volt, og jeg skal bruge 0-10 volt. Derfor ved jeg ikke, om det vil fungere korrekt. Helt præcis skal jeg bruge den til Dantherm ventilationsanlæg HCH5, som via en tilbehørsboks kan styres via 0-10 volt signal. 

Hej Bjarne. Danterm HCH5 er et ganske glimrende produkt, som jeg er meget tilfreds med. Imidlertid er det sket en par gange, at jeg godt vil fjernbetjene det - senest i sommerferien, hvor jeg glemte at sætte den i "Rejseindstilling" før afgang. Så ved at benytte HAC1 tilbehør kan jeg kan bruge 0-10 volt indgangen oprindelig beregnet til Co2 sensor til at styre det hele fra IHC håber jeg. Det er også muligt at bruge en 0-10 volt z-wave dims via openHAB, men jeg foretrækker, at alt fungerer via IHC, så jeg ikke opbygger en funktionsmæssig afhængighed til openHAB og Homekit. Endnu ved jeg ikke, om jeg kan få hardware dimsen, men jeg har netop talt med den europæiske distributør i UK, som finder en pris. Ved heller ikke om jeg kan hitte ud af at bygge en fb til formålet, men så må jeg have Henning eller en anden til at hjælpe.

Der er også denne fra lk, den styres af wireless dæmper.....
http://www.lk.dk/produkt/5703302139311

Hvilket udstyr vil du bruge til trådløs distribution af et kabel TV antenne signal i dit hus?
Derudover kan jeg komme på MANGE grunde til ikke at køre rent trådløst.

Slettet. Overså at Bjarne allerede havde svaret.

Så har jeg købt den nye IHC Controller, HW 7.1, hvor man skal bruge Visual 3 til projektet. Jeg tilsluttede den til strøm og netværk, ændrede default ip adresse til en ledig i mit netværk og oprettede samme user+pwd som i min nuværende HW 6.1 controller. Der er ingen input- eller output moduler tilsluttet den nye controller endnu. Dernæst kopierede jeg mit Visual 2 projekt ind i Visual 3, åbnede projektet og sendte det til den nye controller fra Visual 3. 
I OpenHAB ændrede jeg dernæst ip adressen til den nye controller og genstartede OpenHAB. Herefter kan jeg konstatere, at OpenHAB starter fejlfrit op. OpenHAB fungerer - men viser naturligvis 0 grader ved temperaturer m.m. - og jeg kan påvirke input og fb'ere som normalt. Når dette sker, kan jeg konstatere i den nye ServiceView, at status rent faktisk ændres som følge af OpenHAB input. Så alt ser umiddelbart ud til at fungere - vældig fint!
Jeg har endnu ikke indblik i stabilitet på controlleren, eller om det er nødvendigt med en KeepAlive rule som i de sidste versioner af firmware til HW 6.2.

Så har jeg købt den nye IHC Controller, HW 7.1, hvor man skal bruge Visual 3 til projektet. Jeg tilsluttede den til strøm og netværk, ændrede default ip adresse til en ledig i mit netværk og oprettede samme user+pwd som i min nuværende HW 6.1 controller. Der er ingen input- eller output moduler tilsluttet den nye controller endnu. Dernæst kopierede jeg mit Visual 2 projekt ind i Visual 3, åbnede projektet og sendte det til den nye controller fra Visual 3. 
I OpenHAB ændrede jeg dernæst ip adressen til den nye controller og genstartede OpenHAB. Herefter kan jeg konstatere, at OpenHAB starter fejlfrit op. OpenHAB fungerer - men viser naturligvis 0 grader ved temperaturer m.m. - og jeg kan påvirke input og fb'ere som normalt. Når dette sker, kan jeg konstatere i den nye ServiceView, at status rent faktisk ændres som følge af OpenHAB input. Så alt ser umiddelbart ud til at fungere - vældig fint!
Jeg har endnu ikke indblik i stabilitet på controlleren, eller om det er nødvendigt med en KeepAlive rule som i de sidste versioner af firmware til HW 6.2.

Så har jeg købt den nye IHC Controller, HW 7.1, hvor man skal bruge Visual 3 til projektet. Jeg tilsluttede den til strøm og netværk, ændrede default ip adresse til en ledig i mit netværk og oprettede samme user+pwd som i min nuværende HW 6.1 controller. Der er ingen input- eller output moduler tilsluttet den nye controller endnu. Dernæst kopierede jeg mit Visual 2 projekt ind i Visual 3, åbnede projektet og sendte det til den nye controller fra Visual 3. 
I OpenHAB ændrede jeg dernæst ip adressen til den nye controller og genstartede OpenHAB. Herefter kan jeg konstatere, at OpenHAB starter fejlfrit op. OpenHAB fungerer - men viser naturligvis 0 grader ved temperaturer m.m. - og jeg kan påvirke input og fb'ere som normalt. Når dette sker, kan jeg konstatere i den nye ServiceView, at status rent faktisk ændres som følge af OpenHAB input. Så alt ser umiddelbart ud til at fungere - vældig fint!
Jeg har endnu ikke indblik i stabilitet på controlleren, eller om det er nødvendigt med en KeepAlive rule som i de sidste versioner af firmware til HW 6.2.

Så har jeg købt den nye IHC Controller, HW 7.1, hvor man skal bruge Visual 3 til projektet. Jeg tilsluttede den til strøm og netværk, ændrede default ip adresse til en ledig i mit netværk og oprettede samme user+pwd som i min nuværende HW 6.1 controller. Der er ingen input- eller output moduler tilsluttet den nye controller endnu. Dernæst kopierede jeg mit Visual 2 projekt ind i Visual 3, åbnede projektet og sendte det til den nye controller fra Visual 3. 
I OpenHAB ændrede jeg dernæst ip adressen til den nye controller og genstartede OpenHAB. Herefter kan jeg konstatere, at OpenHAB starter fejlfrit op. OpenHAB fungerer - men viser naturligvis 0 grader ved temperaturer m.m. - og jeg kan påvirke input og fb'ere som normalt. Når dette sker, kan jeg konstatere i den nye ServiceView, at status rent faktisk ændres som følge af OpenHAB input. Så alt ser umiddelbart ud til at fungere - vældig fint!
Jeg har endnu ikke indblik i stabilitet på controlleren, eller om det er nødvendigt med en KeepAlive rule som i de sidste versioner af firmware til HW 6.2.

Til IHC har @Pauli Anttila lavet binding version 1.x. Openhab version 2 er bagudkompatibel med bindings version 1.x, men de bliver ikke vist i configuration bindings eller inboxen - det gør kun bindings version 2.x. Endnu har ingen påtaget sig opgaven med at opgradere IHC binding fra version 1.x til 2.x, og jeg har desværre ikke selv know-how til det. Efter installation af binding er det ret simpelt, at du laver dine filer i openHAB2/conf mappen med subfolders. Først i Services folderen skal du lave en fil ihc.cfg, som skal udfyldes ret præcis. Kontroller dernæst at den rent faktisk har fobindelse til IHC Controlleren. Dernæst skal du lave en fil kaldet ihc.items i folderen openHAB2/conf/Items med alle items. Det er nemmest at lave med Eclipse SmartHome Designer, som er gratis download program fra Openhab. Brug ikke Notepad i Windows til redigering, da det indsætter nogle karakterer, som ikke er OK i Linux.

Tilføjelse December 2019: Nedenstående gælder for IHC Binding version 1. Indlæg vedr. Binding version 2 findes her.
Jeg har brugt nogen tid på Openhab2 med integration til bl.a. IHC og Homekit. En del fra dette forum - bl.a. Pauli Anttila og Claus Skovgaard - har givet væsentlige bidrag, så jeg kunne komme videre. Derfor vil jeg hermed komme med, hvad jeg synes er 'best practice' og simpelt, så andre måske kan spare lidt tid.
Et vigtigt kriterie er, at IHC systemet skal kunne fungere selvstændigt uden at være afhængig af 3. parts software fra fx Openhab eller Apple. Det betyder, at man ikke i væsentlig grad må være afhængig af denne type software for at kunne foretage de mest basale ting i sit hus. 
Løsningen er ret simpel - efter setup af bindings behøver man faktisk kun lave én fil kaldet ihc.items, og den kan se sådan ud:

Eksemplet viser, at udgangen styrer on/off visning i Homekit, mens en tænding i Homekit ved at trykke på ikonet aktiverer øverst venstre svagstrømstryk, og slukning aktiverer øverst højre svagstrømstryk. Det betyder, at man ikke aktiverer output i IHC direkte, men kun input - fuldstændig som hvis man fysisk trykker på et svagstrømstryk.
Resource ID fra IHC kan ses ved at hold CTRL knappen nede i Visual, mens man kører musen over elementet. Tallet 80 betyder, at pulsen varen 80 millisekunder.
Pauli Anttila fra dette forum har lavet en rigtig smart binding, hvor man for hver funktion - fx en spot i loftet - kan angive, hvad i IHC der skal vise status i Homekit, hvad der påvirkes i IHC, når man i Homekit sætter noget ON og ditto, når man sætter OFF i Homekit. Det er konfigureret i tegningen herover, og det ser således ud i Iphone:
 

 
Det er dokumenteret af Pauli, men den fulde konsekvens og muligheder fandt jeg først efter indlægget fra Claus Skovgaard. Eksempelvis kan man tilføje Alarm til Homekit, hvis man har tiltro til Apples eksterne sikkerhed. Her er pegepinden til IHC dog ikke input, men til en Alarm funktionsblok. Se dette eksempel fra Visual:

 
Samlet betyder det, at IHC holder al logik med mulighed for egne add-ons, hvis der er behov. Man behøver kun at lave ihc.items og ingen rules eller sitemap, hvis man benytter Habpanel eller Homekit bruger interface.  
Jeg benytter hw 6.1 med firmware 2.7.199 og har endnu ikke oplevet genstart af controller eller andre problemer. Der er ca. 60 IHC elementer koblet til, og svartiden er instant - dvs. < 1 sekund. Det afvikles på den mindste model af Synology NAS server, som jeg i forvejen har tændt 24/7 til backup formål. Openhab2 har installationspakker til bl.a. Windows, Synology og RPi. 
mvh / Ejvind
 

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.

Tilføjelse December 2019: Nedenstående gælder for IHC Binding version 1. Indlæg vedr. Binding version 2 findes her.
Jeg har brugt nogen tid på Openhab2 med integration til bl.a. IHC og Homekit. En del fra dette forum - bl.a. Pauli Anttila og Claus Skovgaard - har givet væsentlige bidrag, så jeg kunne komme videre. Derfor vil jeg hermed komme med, hvad jeg synes er 'best practice' og simpelt, så andre måske kan spare lidt tid.
Et vigtigt kriterie er, at IHC systemet skal kunne fungere selvstændigt uden at være afhængig af 3. parts software fra fx Openhab eller Apple. Det betyder, at man ikke i væsentlig grad må være afhængig af denne type software for at kunne foretage de mest basale ting i sit hus. 
Løsningen er ret simpel - efter setup af bindings behøver man faktisk kun lave én fil kaldet ihc.items, og den kan se sådan ud:

Eksemplet viser, at udgangen styrer on/off visning i Homekit, mens en tænding i Homekit ved at trykke på ikonet aktiverer øverst venstre svagstrømstryk, og slukning aktiverer øverst højre svagstrømstryk. Det betyder, at man ikke aktiverer output i IHC direkte, men kun input - fuldstændig som hvis man fysisk trykker på et svagstrømstryk.
Resource ID fra IHC kan ses ved at hold CTRL knappen nede i Visual, mens man kører musen over elementet. Tallet 80 betyder, at pulsen varen 80 millisekunder.
Pauli Anttila fra dette forum har lavet en rigtig smart binding, hvor man for hver funktion - fx en spot i loftet - kan angive, hvad i IHC der skal vise status i Homekit, hvad der påvirkes i IHC, når man i Homekit sætter noget ON og ditto, når man sætter OFF i Homekit. Det er konfigureret i tegningen herover, og det ser således ud i Iphone:
 

 
Det er dokumenteret af Pauli, men den fulde konsekvens og muligheder fandt jeg først efter indlægget fra Claus Skovgaard. Eksempelvis kan man tilføje Alarm til Homekit, hvis man har tiltro til Apples eksterne sikkerhed. Her er pegepinden til IHC dog ikke input, men til en Alarm funktionsblok. Se dette eksempel fra Visual:

 
Samlet betyder det, at IHC holder al logik med mulighed for egne add-ons, hvis der er behov. Man behøver kun at lave ihc.items og ingen rules eller sitemap, hvis man benytter Habpanel eller Homekit bruger interface.  
Jeg benytter hw 6.1 med firmware 2.7.199 og har endnu ikke oplevet genstart af controller eller andre problemer. Der er ca. 60 IHC elementer koblet til, og svartiden er instant - dvs. < 1 sekund. Det afvikles på den mindste model af Synology NAS server, som jeg i forvejen har tændt 24/7 til backup formål. Openhab2 har installationspakker til bl.a. Windows, Synology og RPi. 
mvh / Ejvind