Pauli Anttila

@Plindberg, IHC Visual seems to show RF device serial numbers in hex string format (0x640207381599) and IHC binding support serial numbers in decimal format. 0x640207381599 -> 109959873828249 Otherwise you channel and item definitions seems to be correct.

Sorry to jump in english, but I think you could do one button logic easily also via openHAB rules. For example... When push-button-trigger channel receive: 1. LONG_PRESS Check the current light state and send INCREASE or DECREASE command depending of the current state and store direction (up or down). You can also send value explicitly e.g. current dimmer value +/- 10 if INC or DEC is too slow. Start timer which will send next command e.g. after 100ms (INCREASE or DECREASE depending of the direction) and restart the timer which will send again new commmand and so on. When 0 or 100 value is reached you can change the direction or start it again from another head or what ever you want to do. 2. SHORT_PRESS Toggle light (check current state of the light and turn it on or off depending of the current state). Stop timer 3. RELEASED Stop timer

@EjvindHald, Location isn’t Thing specific feature, so it should be available for all things. https://www.openhab.org/docs/configuration/things.html#defining-things-using-files

Yes, configuration file contains hostname (new syntax), but binding itself is still the old which assume that address is ip rather than hostname.

@Jakob Hauerslev, most probably you are using old version of the binding where ihc controller address is not "hostname" but "ip". Newer binding version ihc:controller:1 [ hostname="192.168.1.10"... Older version: ihc:controller:1 [ ip="192.168.1.10"...

To be able to receive PRESSED, RELEASED, SHORT_PRESS, LONG_PRESS triggers, you need to introduce push-button-trigger channel. Channels can be added via PaperUI or via thing files. Thing files example: Type push-button-trigger : my_test_trigger "My Test Trigger" [ resourceId=3988827, longPressTime=1000 ] Rule example: rule "My test trigger test rule" when Channel 'ihc:controller:elko:my_test_trigger' triggered SHORT_PRESS then logInfo("Test","Short press detected") end See more details from binding documentation and examples.

@kerm, communication between openHAB and IHC controller doesn't work very well. Most of the communication ends up to timeout, which means that IHC controller didn't send response to IHC binding. You could try to increase the timeout which is by default 5000ms, but not sure if that will solve your problem. What are your IHC controller HW and SW versions? You are using rather old version of the binding (around 1 year old), so I recommend to use newer one.

@kerm, could you provide openhab logs (before and after openhab reboot), otherwise it's rather impossible to give any help. Anyhow, something is wrong in your pi enviroment. Do you use any other binding? Do they have same behaviour? Maybe your pi's filesystem is on read only mode?

@Nicholai85, most probably you using old snapshot version where hostname parameter doesn’t exists. In older version hostname parameter is called ”ip” rather than ”hostname”.

@Nicholai85, did you add new channel or tried to edit automatically created channel? I just tested PaperUI and added new channel with pulse width parameter + new item + linked channel to item fully via PaperUI without problem.

Same ResourceId can be used as many channels you want and there shouldn’t be any problems even they are linked. If they are linked to same item, then item commands are send multiple times to ihc controller.

@HFW, You shouldn't change automatically generated channels as you changes will be overwritten in next time when binding is reinitialised, which actually happen immediately when you click save button on paperUI. Only channels from inputs and outputs modules and wireless devices are generated automatically, and it doesn't make sense to define pulse width functionality to these real outputs. Function block staff need to be added manually. I don't use PaperUI my self for IHC binding, but I auto create basic channels and then introduce additional channels to things file. And then I link all channels (auto created and manually added) to items in item file. Thing file example: ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: Type switch : my_test_switch "My Additional Test Switch" [ resourceId=3988840 ] } Items file example: Switch auto_switch "Auto Switch" { channel="ihc:controller:elko:output3988827" } Switch manual_switch "Manual Switch" { channel="ihc:controller:elko:my_test_switch" } But if you want to use just PaperUI, you can add additional channels from there as well.

You should change ip parameter name to hostname ihc:controller:elko [ hostname="192.168.0.3:443", username="admin", password="password", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] Have you read https://www.openhab.org/addons/bindings/ihc/ ? And I propose to read https://www.openhab.org/docs/ pages to get understanding of the basic openHAB concepts. Read carefully the first page and then follow the links end of the pages. (next page is "Concepts Overview -> , etc"). After that you should have pretty clear understanding of the items, things, channels, etc.

@bozidar, I believe you are using rather new version of the binding, where controller network address is not anymore ip but hostname. Because hostname parameter is mandatory, binding is not started and you seen configuration pending error. From logs you most probably see the reason as well. Example ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ]

IHC binding 2 is merged after 2.5 M1 release. M1 is pretty old and because of openHAB build system update, there is no M2 release yet, but Snapshot releases contains the new IHC binding.

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.

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

@EjvindHald, contact channels have direction which is not support as contact is nativily read only channel, but those shouldn't cause any problems. Otherwise I didn't spot any mistakes. Could you enable trace level logs and sent them as well? Btw, you are not using latest version, but I can't remember if there has been any problems. Here is a link to latest version which I have copied to my dropbox: https://www.dropbox.com/s/xgfj233wdtezlje/org.openhab.binding.ihc-2.5.0.201904021823.jar?dl=0

@Morten H, did you modify auto discovered channel or did you add new custom channel which you modified? I quickly tested with custom channel and pulse width editing works fine on my environment.

Yes, openHAB (exactly speaking the Karaf) have cache folder which can contain old version of the binding. If you are using openhabian, cache folder is /var/lib/openhab2/cache/. Search openHAB forum more. From karat console you can see which version is running. openhab> bundle:list org.openhab.binding.ihc START LEVEL 100 , List Threshold: 50 ID │ State │ Lvl │ Version │ Name ────┼────────┼─────┼────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 300 │ Active │ 80 │ 2.4.0.201812182121 │ IHC / ELKO Binding When handling bindings manually by adding and removing them from add-on folder, it's always wise to stop the current binding before remove it by command bundle:stop org.openhab.binding.ihc And check that bundle State is Resolved before remove it.

@EjvindHald, ip parameter has been changed to hostname very lately. Version which you running still use ip parameter. This can be seen from the debug 2019-04-27 07:58:51.924 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [IP='something', username='openhabSVC']. Latest version should debug following 2019-04-27 07:58:51.924 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [hostname='something', username='openhabSVC'].

OH1 bindings support both item updates and commands. OH2 bindings supports only commans to channels. Your zwave sensor updates the item state, so update is not propagated to ihc item and therefore not to linked ihc channel. Thats why you need profiles or rule. Follow profile create command from item update, and that command is then send to ihc channel.

@Gilbert, Could you provide debug logs

@Gilbert, If fact, it doesn't work without rules as your zwave sensor doesn't send command but update to the item. So you need to introduce simple rule or use "follow" profile in item definition.

You have different channel names in item and thing files. Item file channels are divhus_ and thing file have drivhus_. Simplifying the setup, I added only one channel to following example. When ever that work, you can add more channels. ihc:controller:elko [ hostname="192.168.0.3", username="admin", password="password", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type number : drivhus_ihctemp "My Test temp" [ resourceId=2935316, direction="WriteOnly" ] } Number drivhus_sensor_ihctemp (drivhus) { channel="ihc:controller:elko:drivhus_ihctemp" } First of all, I assume that you have linked item drivhus_sensor_ihctemp to your zwave node temperature channel as well (e.g. via PaperUI)? So when ever item drivhus_sensor_ihctemp is update by the zwave node, IHC binding will send item drivhus_sensor_ihctemp value to resourceId 2935316. WriteOnly direction make sure that drivhus_sensor_ihctemp item is never updated from IHC controller (binding just mirror the value from item to IHC). WriteOnly direction is same as '>' in IHC v1 binding. You try to update value to IHC lux / temperatue sensor product? Do you have real lux / temperature sensor device connected to that or is it just virtual device in IHC side? I'm not sure if it's possible to write data to that (never tried that), but if that has been work with OH1 binding then it should work OH2 binding as well.