Pauli Anttila

It's a timing issue. My MacBook have more processor cores and much more faster than Rpi, so bindings and core bundles startup orders are different.

@Kandersen, could try this version https://www.dropbox.com/s/2i4bgpeii8qzixp/org.openhab.binding.ihc_2.4.0.201812061319.jar?dl=0 Please, rerun your test with trace logs (full start + enable/disable) and send logs to me, so I can also verify if this solve the problem on your environment.

It seems to be exactly like I predicted. Some reason binding didn't get channel linked events for all items in start up. After disable/enable, binding receive more (all?) channel linked events like it should.

Well, you log didn't contain information about that, but I assume that reason is that when you enable and disable the thing, all openHAB core features are up and running (which might not be the case when start the whole system). Could you send log which contains both full startup and then thing restart? Most of the bindings are not interested the channel linked events, so if there is a problem, it might not have influence to other bindings. If my interpretation is correct, we should make a bug report about it.

@Kandersen, IHC binding orders resource ID updates from controller only for channels which are linked to items. Some reason IHC binding doesn't get all channelLinked events (only 3) from openHAB. 2018-12-03 18:35:57.331 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerState 2018-12-03 18:35:57.340 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerTime 2018-12-03 18:35:57.339 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerUptime So, reason not seem to be in the binding itself but openhab/smarthome core.

Could you enable logs with trace level and try to reproduce the issue?

I haven't had a single problem with 2.7.144, so I just don't want to break it Enable/disable button?

@Kandersen Could you try following version https://www.dropbox.com/s/bn3k50w8or10rro/org.openhab.binding.ihc_2.4.0.201811282019.jar?dl=0 RF channels are generated from project file rather than AirlinkManagementService RF device battery and signal strength channels have better description Temperature sensor alarm input description should be correct Controller SW and HW version channels are moved to thing properties Added more thing properties

@Kandersen Could you send serial numbers of those 10 devices (which device is which)?

Well, Binding is using controller AirlinkManagementService to ask detected devices and as you can see from the log, result contains 38 devices. What is the outcome if you press "Product liste" button in "LK IHC Wireless product linking" window?

@Kandersen Your controller is reporting 38 wireless devices. wireless_devices.txt Those are temperature sensor's alarm inputs. I don't know the reason why the location information isn't correct (it's not correct in my environment either). In fact, I haven't recognised those alarm inputs earlier (never looked so deeply), but I will check if those could be improved.

@Kandersen, Could you enable trace level logging and send me the log? Form karaf console: 1. bundle:stop "IHC / ELKO Binding" 2. log:set TRACE org.openhab.binding.ihc 3. bundle:start "IHC / ELKO Binding" 4. Wait a while and get log file 5. log:set DEFAULT org.openhab.binding.ihc

Hi @Kandersen, and yes, you can connect as many openHAB instances you want to the same controller. But as you said, IHC controller might be unstable. I have not had any issues with multiple connections.

Hi @Kandersen, Automatically created channels can't be edited, but you can keep createChannelsAutomatically=true and then add additional channels with extra options via PaperUI or by things file. This is actually how I use it.

https://github.com/openhab/openhab2-addons/pull/3708

It's hard to say as I can't do code review to my own binding. Hopefully it will merged before next release. Review process is nowadays the bottle neck as there are too many open pull request and too few people to do code reviews. But what you and others could do to hopefully speed up the process is to give a upvote to pull request (just give a +1 comment). You need to create GitHub account if you don't already have it.

Did you already checked the wiki? There is an example. Channels: Type push-button-trigger : my_test_trigger [ resourceId=3988827, shortPressMaxTime=1000, longPressMaxTime=2000, extraLongPressMaxTime=4000 ] } Will trigger LONG_PRESS when button is pressed more than 1000ms but less than 2000ms. Other triggers are SHORT_PRESS and EXTRA_LONG_PRESS. when Channel 'ihc:controller:elko:my_test_trigger' triggered LONG_PRESS then logInfo("Test","Long press detected") end

Thanks for the offer.

Great Tags are added to items and items are not related to bindings. Bindings communicate via channels.

I added airlink_relay, airlink_dimming and resource_humidity_level support to auto discovery. I don't own those devices, so can't test the support either. So someone who own those could try this version. Wireless dimmers supports only direct level adjustment (0-100). So increase and decrease functionality is not directly supported.

@Henrik Skaarup, trigger channels works without items and can be used directly in rules. rule "Short press" when Channel 'ihc:controller:d1a7b4dc:Keychain_Top' triggered SHORT_PRESS then // do something end

That's not correct. Wireless actuators are supported. Only limitation is the auto discovery, where only airlink_inputs and airlink_outputs are automatically discovered. All lego blocks are in place, so what can be configured via ver 1 binding can be manually configured via ver 2 binding as well.

@Vagn, I think I have found the reason for you problem. I have only one IHC controller, so I'm not able to test support properly. I made some fixes, so could you try this version? @BrianPedersen, I don't have any wireless dimmers, so I don't have a clue how they are implemented. That's also the reason why I have not included those to auto discovery. Have you used them with binding version 1? If yes, then you should be able add them manually to v2 binding as well. I could add the support, but I need details how they work.

Some reason Google translator translate pretty "bad" english, so it's pretty hard to fully understand what you try to reach on your example. Anyhow, following configuration is read only from openHAB perpective, meaning that only timer value change in IHC is updated to openHAB item. Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc="<0x1102410"} So if you change the U_TimerVand item value, it will not be updated to IHC. When every timer value is changed in IHC side (timer is running or you change it via service view), value is updated to openHAB item. Timers are in millisecond resolution in IHC, so I guess that, if timer is running, you will get a lot of updates. Maybe not every millisecond, but very often. So most probably it's not wise to sync timer value between openHAB and IHC. If you just want to change the timer value from openHAB to IHC, you could make it write only (>). If you want to know when timer is expired (counted to 0), your most probably should change the IHC code so that when timer is expired some kind of flag is set, which change is then syncronized to openHAB. Syntax explanation: Syncronization in both directions (IHC <-> openHAB): Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc="0x1102410"} Read only (IHC -> openHAB): Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc="<0x1102410"} Write only (openHAB -> IHC): Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc=">0x1102410"}

You should add comma between different bindings, otherwise it should be correct. Number th01_temp "TH01 Temperatur[%.2f °C]" <temperature> (Sonoff) { mqtt="<[broker:tele/th01/SENSOR:state:JSONPATH($.SI7021.Temperature)]", ihc=">1234567" }