EjvindHald

Jeg har ikke oplevet dette problem, men release 2.5 er ikke frigivet endnu, så der kan muligvis være fejl i den. Endvidere bruger du ihc binding version 1, og disse ældre bindings bliver formentlig ikke testet så godt mere. Jeg bruger selv openHAB version 2.4, og de fleste ihc enheder er nu på binding version 2. Derudover bruger jeg bl.a. Hue binding som dig - dog ikke med sensorer. Mine sensorer er ledningsførte via ihc for at undgå batteridrift. Det hele afvikles fint på hw7.1.

På hvilket link fandt du den?

Thanks. This is very useful info. However, I sm still not quite sure, what is wrong. I have tried completely without a things file and letting paperUI detect. This also gives an error. I have tried copied both the recent 2.5 snapshot binding and the latest 2.4 version from your dropbox folder into Addons folder and restarted openHAB. I used the links from this thread. Both versions gives the error. Could openHAB use another version of the binding copied previously to an internal destination somewhere?

I have tried to go with both the latest 2.4 and 2.5 bindings, but I cannot get the IHC Controller Thing online. I keep getting "Offline - Bridge Offline" or other error messages. I have tried both using a things file and having paperUI add a thing. Both gives errors. The log shows this: root@HaldNAS:~# tail -f /volume1/@appstore/openHAB/userdata/logs/openhab.log at org.openhab.binding.ihc.internal.handler.IhcHandler.updateControllerProperties(IhcHandler.java:277) ~[?:?] at org.openhab.binding.ihc.internal.handler.IhcHandler.connect(IhcHandler.java:497) ~[?:?] at org.openhab.binding.ihc.internal.handler.IhcHandler.reconnectCheck(IhcHandler.java:767) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?] at java.lang.Thread.run(Thread.java:748) [?:?] And from Karaf console: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <authenticate1 xmlns="utcs"> <password>secret</password> <username>openhabSVC</username> <application>treeview</application> </authenticate1> </soapenv:Body> </soapenv:Envelope> 2019-04-27 07:58:50.921 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Can't open connection to controller 2019-04-27 07:58:51.923 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Closing connection 2019-04-27 07:58:51.924 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Connection closed 2019-04-27 07:58:51.924 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [IP='null', username='openhabSVC']. 2019-04-27 07:58:51.925 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Opening connection 2019-04-27 07:58:51.926 [DEBUG] [c.internal.ws.http.IhcConnectionPool] - Initialize SSL context 2019-04-27 07:58:51.927 [DEBUG] [ws.services.IhcAuthenticationService] - Open connection 2019-04-27 07:58:51.927 [DEBUG] [.ihc.internal.ws.http.IhcHttpsClient] - Open connection to 'https://null/ws/AuthenticationService' 2019-04-27 07:58:51.929 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (connectionPool=7035853, clientId=16128980 requestId=0, timeout=10000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?> Please note it seems like the IP address seems to be 'null' The header of my things.file look like this: ihc:controller:haldIHC [ hostname="192.168.1.31:444", username="openhabSVC", password="g75Ja!qen", timeout=10000, loadProjectFile=true, createChannelsAutomatically=false ] { so I using a custom port 444. Is that not supported by IHC binding 2 or openHAB 2.4 anymore? I am using Java 8.161 and openHAB 2.4 installed on a Synology DiskStation. My IHC Controller is HW 7.

@Henning Pedersen Hvorfor mener du, at Philips Hue kun er til sjov?

I denne tråd har jeg den 9. januar 2019 uploaded en reduceret udgave af fb 1.2.04/1.2.05 for at få be- eller afkræftet, om det er et problem med wireless med lysregulering via scenarier. Jeg har selv haft samme problem og symptomer som dine, og jeg forsøger, om det er muligt at identificere en mulig fejl i firmwaren. Du er velkommen til at teste denne fb og poste, om det gør en forskel. Se i øvrigt denne tråd om samme emne.

Jeg vil gerne købe nogle Danfoss termostater type RET24 VF, som ikke længere produceres. Denne model findes også i 2 andre varianter med hhv. natsænkning og ikke potentialfri, men de har ingen interesse. Typeangivelsen kan ses på bagsiden af hovedmodulet, og der er mere info her Skal bruges som reservedel til eksisterende varmestyring via IHC.

På I det vedlagte screen shot fra Ulrik er Tænd/reguler op og Sluk/reguler ned på dimmeren ikke forbundet. Det er netop disse 2, som benyttes til regulering i den test fb, som jeg henviser til.

Hvis du ser denne tråd igennem, kan du læse, at der muligvis er et firmware problem med lysregulering op og ned via scenarier. Det er kun regulering, som er mistænkt - ikke at sætte et scenarie eller tilbagemelding fra dimmeren. Derfor har jeg i den samme tråd den 9. januar 2019 uploaded en reduceret udgave af fb 1.2.04/1.2.05 for at få be- eller afkræftet, om det er korrekt. Du er velkommen til at teste denne. Selv har jeg benyttet denne fb siden 8. januar i år uden problemer, men det er ikke nok til endeligt at få be- eller afkræftet, om det forholder sig sådan. Flere testere vil være fint. Inden da havde jeg samme symptom som det du beskriver. Hvis det viser sig, at mange oplever forbedret stabilitet, vil det være et testresultat, som kan videregives til LK med henblik på, at de etablerer en permanent løsning.

Jeg benytter denne her, som giver 0-10 volt analog signal ud afhængig af tiden med højt signal. Dvs. hvis en output 24 udgang er åben i 4,3 sekunder, så giver den 4,3 volt. Denne spænding holdes, indtil output modulet igen går høj i en periode. @Henning Pedersen har venligt lavet en fb til at styre den med.

SD kort indhold View File Jeg har her placeret indholdet af mit SD kort til hw7. Yderste folder er en guid, og jeg ved ikke, om denne værdi er specifik for min installation eller generisk. Selve SD kortet er formateret i linux formatet ext3. Submitter EjvindHald Submitted 01/14/2019 Category IHC Control Visual 3 Firmware

Jeg har netop nu uploaded indholdet af mit SD kort i download sektionen. Men jeg var muligvis for hurtig, idet filens størrelse kun er 194 KB, hvilket nok er for lille til at kunne rumme firmwaren. Muligvis er det VIS projektet komprimeret.

Måske var jeg lige lidt for hurtig. Der er kun én fil på kortet, og den hedder "stored" uden extension. Den er ret lille - kun 194 kb - så jeg tror alligevel ikke, at det er firmwaren. Måske er det VIS projektet i komprimeret format. Hvis jeg åbner denne "stored" fil i Notepad, så er det helt ulæseligt. Tak for dit spørgsmål - jeg har rettet mit indlæg jf. dette.

Kortet er næsten tomt i lighed med LK's eget sd kort, hvis man ikke har slået logning til. Men der er betydeligt større kapacitet end LK's eget kort, som kun er på 512 MB. I et sådant embedded linux produkt - som IHC controlleren er - er belastningen på SD kortet lille med deraf lav sandsynlighed for et defekt kort. Hvis man alligevel ønsker et ekstra robust sd kort, kan man overveje en type V30 - se link her. Standarden er lavet med udgangspunkt i kontinuerlige videooptagelser, som nok er den belastningstype, der giver højst belastning på sd kort. Kameraproducenten Axis anbefaler V30.

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.

Se indlægget her fra @Claus Skovgaard den 24. marts 2018. Hvis du gør sådan, så undgår du regler, og dine kip bliver meget simple. På fb 1.10 Simpel Kip har du også en tænd og sluk og den forbinder du bare i Openhab. Enten Items ved binding 1 eller som Channel i binding 2.

Du burde blot kunne sige “ok google sluk alt lys”, hvorefter den selv finder alle lys og slukker disse. Dvs. den bruger ikke din funktion. Men hos mig kan jeg ikke få det at fungere korrekt - det ser ud til at den i visse tilfælde laver et kip. Det virker fint i Siri.

Jeg oplever det samme - måske er det Homekit bindingen.

Tak for input fra mange - også via telefon. Ingen kender præcis årsagen til, hvorfor en wireless dimmer til tider bliver ustabil, men - baseret på jeres input - gætter jeg på følgende: Afvikling af scenarier sker serielt, og hvis der optræder et problem (fx kommunikation), så kan det - af ukendte årsager - stoppe wireless kodeafviklingen helt. Op- og nedregulering af lysstyrke via scenarier kan - i visse tilfælde - give et problem, og årsagen er ukendt. Dette trigger dermed punkt 1. Jeg har i dag forelagt det for @Henning Pedersen, og samtidig spurgt om han ville lave en helt simpel funktionsblok, som ikke benytter scenarier til regulering af lys. Lyset reguleres i stedet via op og ned på produktet. Det har han venligt lavet, og jeg har installeret den hos mig, og den fungerer fint som tiltænkt. Et projekt med fb'en er vedlagt dette indlæg. Det er en helt simpel fb, som kun er beregnet til test. Jeg kan forstå på indlægget fra @Lars1 herover, at det ikke anbefales af LK, men jeg synes alligevel, at det kunne være interessant at se, om det løser nogle problemer med ustabilitet. Hvis ja, så er problemet indkredset lidt mere. @Henning Pedersen oplyste til mig, at han ikke har oplevet ustabilitet hos sine kunder, og han benytter primært sine egne sæt af blokke, som bl.a. er baseret på ovenstående princip. Derfor: Hvis nogle af jer, som har problemer med stabilitet, vil afprøve vedlagte fra Henning, vil det være rigtig fint. Hvis det grundlæggende problem er kommunikation, så gør fb'en naturligvis ingen forskel. Ser frem til feedback -:) Test af Wireless.vis

Du bør ikke bruge strømforsyning fra IHC til tilsluttede enheder. Det mest korrekte er en seperat forsyning og kontaktor, som 24 volt output kan tænde og slukke. Eltako laver fine DIN skinne moduler til dette, som jeg benytter i lignende setup til både 12 og 24 volt enheder. Eltako købes billigst i Tyskland på nettet.

Desværre oplever jeg nu lignende problemer med hw7 controller med 2 stk. wireless Ø80 hw2 og fb 1.2.05. Problemet minder mest om symptomet fra Coralreef, hvor det er som om wireless delen nogle gange bliver låst i controlleren, og begge mine wireless dimmere ophører med at fungere. Enten virker begge mine dimmere, eller ingen virker. Serviceview viser korrekt, men fysisk lys svarer ikke til den viste procent i serviceview. Håber der nogle, som måske har indsigt. @Thomas Brejner: Kom der er LK tekniker ud til din kunde med over 50 dæmpere, og hvad var konklusionen? @Coralreef: Virker det nu, og er du kommet nærmere root cause? - fik du afprøvet fb'en fra @Henning Pedersen? @TorbenSørensen: På dette link er der en kommentar fra @Lars1 om, at der er fjernet support i firmware for wireless touch. Betyder det, at løsningsforslaget i denne tråd fra dig om at benytte den til regulering ikke længere er mulig? Takker.

Jeg bor i Nordsjælland og har en hw2 du kan låne i et par dage inden montering i slutningen af uge 1. Hvis interesseret så send mig en pm.

As far as I recall others have had problem in Windows environment. I recommend using a Linux based environment instead.

Virker fint hos mig på hw7 uden krav om brugernavn eller kode.