Jump to content
IHC-User.dk
  • 0

Question

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).

 5b000b95160a8_ScreenShot2018-05-19at14_32_14.thumb.png.4093d93247a17cd4fc3d66307c895976.png

5b000ba2cc62b_ScreenShot2018-05-19at14_33_06.thumb.png.648edf0e40855577f58e973c448514b6.png

 

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

@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

Share this post


Link to post
Share on other sites
  • 0
1 time siden, EjvindHald skrev:

Yes, I am running binding 1 and 2 side by side until all items are converted.

Could that be the issue? If you use the same resourceID in another binding.. When I moved to the new binding, I move the resourceID´s as well, to make sure it wasn´t active in the old one.. Hmm actually I removed the whole binding, and then made the move..
But it´s just a guess..  

Share this post


Link to post
Share on other sites
  • 0
14 timer siden, Kandersen skrev:

Could that be the issue? If you use the same resourceID in another binding.. When I moved to the new binding, I move the resourceID´s as well, to make sure it wasn´t active in the old one.. Hmm actually I removed the whole binding, and then made the move..
But it´s just a guess..  

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
 

 

Share this post


Link to post
Share on other sites
  • 0

@EjvindHald, you log is somehow weird as it miss lot of log information what should be logged in trace and debug level. Please update the latest binding version, clear openHAB caches, etc. You should clear the log file as well. Start whole openHAB and send new logs so that we can see that startup procedure is correct. 

By command "bundle:list org.openhab.binding.ihc" in Karaf console you should see which ihc binding version you are really using.

 

Share this post


Link to post
Share on other sites
  • 0
3 timer siden, EjvindHald skrev:

However, I still do not understand why I get these messages in the log when starting the IHC binding:

I´m out of ideas unfortunatly. The binding runs awesome on my system. Actually I would go as far and claim, the IHC binding is the most stable binding I´m using. So I understand you´r frustrations. 

Share this post


Link to post
Share on other sites
  • 0

I still think that you ihc binding version is wrong. Log shows that controller address in the log is IP not hostname as it should. 

Connecting to IHC / ELKO LS controller [IP='192.168.1.31:444' 

Old binding versions defines channel types with channel prefix (switch-channel not just switch), so most probably that's the reason for  "Channel type ihc:switch could not be resolved" errors.

Share this post


Link to post
Share on other sites
  • 0

@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.

Share this post


Link to post
Share on other sites
  • 0

Jag ska försöka få igång Openhab2 har LINUX på en gammal bärbar och opnehab installerat

:~$ dpkg --list | grep openhab
ii  openhab2                                   2.5.0~M1-1                                   all          openhab2
ii  openhab2-addons                            2.5.0~M1-1                                   all          openhab2-addons

men jag hittar ingen version 2 av IHC binding i paper UI.

kan jag ladda ned den senaste IHC bindingen någonstans?

Share this post


Link to post
Share on other sites
  • 0

@Pauli Anttila could you put the latest .jar to download? I´m not keen on using the snapshot version.. I used to, but there has been too many serious problems. So I´m back to 2.5M1. I am using a newer IHC binding though, just installed manually. 

And speaking of IHC binding.. Yesterday I discovered something was very wrong with my openhab<->IHC.. PaperUI showed the controller was online, but I received no info at all from any things.. (it turned out it has been like that for the whole day/night). 
I really struggled getting the connection back. I uninstalled the binding, cleared cache/tmp, restarted my Rpi, restarted my IHC controller.. Even removed the power from the controller etc.. But no matter what I did, I ended up with a timeout connection from the IHC binding.

I have done no changes lately, and it has been running rock steady for weeks, (since I moved back to openhab 2.5M1). Before that, I was using snapshot build 1575, and the IHC binding have never caused any problems. 

To fix the connection again, I had to raise the timeout in the config from 8000 to 10000.. Then I could get the binding to connect just fine again. And it has been running like that since yesterday.. Now I wonder - What can cause this problem all of a sudden?

Second - How come PaperUI says the controller is ONLINE, when it´s actually not? I can tell from the log, that the binding do connects, but a couple of seconds after, it gives the timeout error. Shouldn´t the controller have been offline then??

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

Privacy Policy og We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.