EjvindHald

Jeg overvejer at erstatte mine Danfoss potentialfri termostater med Nest termostat E. Begge fødes med 24 volt AC, men Nest termostaten har ikke potentialfri udgang, så jeg skal have en kontaktor eller relæ imellem til mit ihc indgangsmodul. Min udfordring er, at jeg gerne vil have en løsning, som fylder et minimum, gerne så relæet kan være sammen med selve termostaten. Måske et reed relæ kan benyttes, men det kender jeg ikke så meget til. Bemærk at det er AC og ikke DC. Venligst undlad at starte en debat om funktionaliteten i Nest E termostaten i denne tråd. På forhånd tak for input.

Jeg har brugt denne her i et tilfælde. Afhængig af hvor lang tid en out 24 er on, sættes mellem 0 og 10 volt på udgangen, og det bevares indtil næste gang, at den pågældende out 24 er on. Henning lavede en fin fb, som jeg brugte. Der er en del udstyr, som er kompatibel med 0-10 volt signal.

Jeg foreslår at efterse nedenstående: - Hvis du har backup modul installeret, er batteriet udtjent? - Kontrollere for evt. defekt ledning fra et udgangsmodul til IHC status på tastaturet - det styrer rød/grøn. - Endelig kan IHC tastaturet i visse tilfælde blive defekt grundet fugt efter nogle års brug.

@Pauli Anttila : Thanks. I am not at home now, so I will get back to you in a few hours. Edit: I AM running the correct binding version according to karaf console status info (bundle:list org.openhab.binding.ihc) . However, the problem seems to be in the physical cache and tmp files as also @Kandersen has experienced. When trying to delete files these I made a typo, and my whole Synology server needs to be reinstalled. I will get back later with status. Edit2: I found the error and it was me doing a type error, so the resource id actually did not exist. The IHC binding is fine. Suggestion to @Pauli Anttila: When I make a type error in the Things file, and fix it afterwards to the correct value, then openHAB often needs to be restarted. Not sure if this is related to the binding or openHAB, but if it is possible to make a more robust functionality, that would be cool. Binding 1 was more robust and a typing error could be fixed without a restart. Thanks.

Thanks, but this is not the problem. However, I still do not understand why I get these messages in the log when starting the IHC binding: 2019-05-12 08:47:20.353 [INFO ] [nhab.binding.ihc.internal.IhcBinding] - Connecting to IHC / ELKO LS controller [IP='192.168.1.31:444' Username='openhabSVC']. 2019-05-12 08:47:20.518 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. 2019-05-12 08:47:20.521 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:dimmer could not be resolved. 2019-05-12 08:47:20.523 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. 2019-05-12 08:47:20.525 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. 2019-05-12 08:47:20.528 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. 2019-05-12 08:47:20.530 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. 2019-05-12 08:47:20.532 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:dimmer could not be resolved. 2019-05-12 08:47:20.534 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. .. and many more followed by: 2019-05-12 08:47:20.700 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:contact could not be resolved. 2019-05-12 08:47:36.690 [WARN ] [ding.ihc.internal.handler.IhcHandler] - Unknown error occured, reason: null. java.lang.NullPointerException: null at org.openhab.binding.ihc.internal.converters.ConverterFactory.getConverter(ConverterFactory.java:120) ~[?:?] at org.openhab.binding.ihc.internal.handler.IhcHandler.updateChannelState(IhcHandler.java:744) ~[?:?] at org.openhab.binding.ihc.internal.handler.IhcHandler.lambda$5(IhcHandler.java:719) ~[?:?] at java.util.ArrayList.forEach(ArrayList.java:1257) [?:?] at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080) [?:?] at org.openhab.binding.ihc.internal.handler.IhcHandler.resourceValueUpdateReceived(IhcHandler.java:715) [215:org.openhab.binding.ihc:2.5.0.201904021522] at org.openhab.binding.ihc.internal.ws.IhcClient.sendResourceValueUpdateEvent(IhcClient.java:570) [215:org.openhab.binding.ihc:2.5.0.201904021522] at org.openhab.binding.ihc.internal.ws.IhcClient.access$2(IhcClient.java:564) [215:org.openhab.binding.ihc:2.5.0.201904021522] at org.openhab.binding.ihc.internal.ws.IhcClient$IhcResourceValueNotificationListener.waitResourceNotifications(IhcClient.java:459) [215:org.openhab.binding.ihc:2.5.0.201904021522] at org.openhab.binding.ihc.internal.ws.IhcClient$IhcResourceValueNotificationListener.run(IhcClient.java:447) [215:org.openhab.binding.ihc:2.5.0.201904021522] 2019-05-12 08:47:36.717 [WARN ] [ding.ihc.internal.handler.IhcHandler] - Unknown error occured, reason: null. java.lang.NullPointerException: null

@Kandersen: Yes, I am running binding 1 and 2 side by side until all items are converted. @Pauli Anttila: I have removed readonly from contact, installed the newest build and tried again with same result. I have uploaded the log file, where you can search for ThStueplanStueTrykOverstVenstre, which gives an error - resource id not found. Thanks. openhab.log

Also my idea, so I have tried searching for these, but was not able to locate any. Therefore, I uploaded my Things file, so maybe other can see if there any problems like this.

Hi @Pauli Anttila I am in the process of convertering all my items from binding version 1 to version 2. This means I have both old and new binding enabled. It all goes fine until I keep getting an error, which I cannot solve. Upon start of the binding, I get many of these, and I have only shown 3: 2019-05-11 11:42:12.619 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. 2019-05-11 11:42:12.621 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:dimmer could not be resolved. 2019-05-11 11:42:12.623 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:switch could not be resolved. and the first many Things works fine, but when I add one more, it throws this error: 2019-05-11 11:43:15.606 [ERROR] [ding.ihc.internal.handler.IhcHandler] - Can't update channel 'ihc:controller:haldIHC:ThStueplanStueTrykOverstVenstre' value, cause org.openhab.binding.ihc.internal.ws.exeptions.IhcExecption: No resource id found at org.openhab.binding.ihc.internal.ws.services.IhcResourceInteractionService.resourceQuery(IhcResourceInteractionService.java:81) ~[212:org.openhab.binding.ihc:2.5.0.201903151801] The bold is mine. However, that resource id actually exist, and if I move some lines around in my Things file, then it is suddenly another one with that problem. I do not know if this problem is related to the binding, openHAB or lack of CPU resources. I am running openhab version 2.4.0 with your binding org.openhab.binding.ihc-2.5.0-SNAPSHOT on a Synology NAS server. I have attached my Things file. If I open karaf console, I get a lot of rows. Thanks. ihc without pwd.things

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.