Pauli Anttila

I have now used this new version on my "production" openHAB system almost one month without single problem, so it seems to be pretty rock solid. I have done some refactoring to binding since last version (in 1st page). Binding it's not yet merged to openHAB main repo, but official PR snapshot builds can be found here.

Sorry to answer in english, but rules are not needed. It depends how you are using MQTT and openHAB: 1. If you are using MQTT event bus binding configuration (no need to bind items to mqtt as they are binded automatically in event bus level) and you have openHAB item already which have e.g. temperature from MQTT (e.g. mqttTemperature), you just need to bind the item to IHC. Number mqttTemperature "Temperature [%.1f °C]" { ihc=">1234567" } So when ever mqttTemperature is updated, openHAB will send update to IHC resource 1234567. 2. If you are using MQTT item configuration, then you need to add binding to IHC as well. Number mqttTemperature "Temperature [%.1f °C] { mqtt"...", ihc=">1234567" } @Kandersen and @Ejvind Hald can translate if needed

@EjvindHald, it works like you have configured it to work . When ever Number item receive a command (1, 2, 3, 4), binding send 1000ms "pulse" to 11390475 resource. When pulseWidth parameter is defined, binding send ON command, wait 1000ms and send OFF command. ON and OFF commands are converted automatically to IHC resource value type. Normally, pulse is used with boolean resource (IHC binary input), but in your case IHC resource value is numeric, therefore binding converts ON command to value 100 and OFF command to value 0. So ultimately binding send value 100 (ON), sleep 1000ms and then send value 0 (OFF). I can't remember why I have selected value 100 when ON command is converted to numeric resource value as conversion functions are taken from OH1 binding. Most probably the reason was that Dimmer item types, value 100 present the full brightness. I guess you want to send a item value rather than generate a pulse, so you shouldn't define pulseWidth in this case. Type number-channel : ihc2number "IHC vent" [resourceId=11390475, direction="WriteOnly"] //vent Then binding send item value (1, 2, 3, 4) to IHC resource, which then match you OH1 configuration ihc="<0xadd90b,>[*:0xadce0b]"

If you want that number channel react to all commands, you ignore the whole commandToReact parameter. If you want that channel just react to number 5 then defined so. So commandToReact is exactly the command which you send to items. If pulseWidth is defined, then binding don't send the item value but generate the pulse.

Just updated the link to latest binding version. I have made many breaking changes to the binding. I removed pulse output channel as now every channel can send pulse if pulseWidth parameter is defined. Every channel also have now commandToReact parameter which can be used to filter commands. So following should be now possible Type switch-channel : ihcoutput "IHC output" [ resourceId=1736539, direction="ReadOnly" ] Type switch-channel : ihcinput1 "IHC input 1" [ resourceId=2448474, direction="WriteOnly", pulseWidth=1000, commandToReact="ON" ] Type switch-channel : ihcinput2 "IHC input 2" [ resourceId=2448218, direction="WriteOnly", pulseWidth=1000, commandToReact="OFF" ] I have not test new version very well, so there could be bugs.

Yes, this is how it works as trigger parameter is not yet implemented

Well, my idea was to introduce trigger parameter to pulse output channel, where you can choose when pulse is send (ON->OFF, OFF->ON, Both) Then following should work. Type switch-channel : ihcoutput "IHC output" [ resourceId=1736539, direction="ReadOnly" ] Type pulse-output-channel : ihcinput1 "IHC input 1" [ resourceId=2448474, direction="WriteOnly", pulseLength=1000, trigger="ON" ] Type pulse-output-channel : ihcinput2 "IHC input 2" [ resourceId=2448218, direction="WriteOnly", pulseLength=1000, trigger="OFF" ]

OK, reason why it doesn't work is that currently pulse output channel only send pulse when state changes from off to on. So if I extended the pulse output channel so that pulse can be configured to send also when state changes from on to off, it most probably work fine then. OpenHAB support multi channel linking and it doesn't have any black magic behind. When item receive a command, openHAB send command to every channel linked to the item. When channels are updated, item state is updated as well. IHC binding channels support direction configuration parameter, so if ReadOnly is enabled, IHC binding doesn't send any commands from item to configured IHC resource. If IHC binding receive update from IHC controller, channel is updated. If WriteOnly is enabled, binding just send commands to IHC controller, but doesn't update the channel state when update is received from IHC controller. So direction works exactly like < and > operators in version 1 binding.

@EjvindHald, I think following should work fine? Channels: Type switch-channel : ihcoutput "IHC output" [ resourceId=2845531, direction="ReadOnly" ] //output Type pulse-output-channel : ihcinput "IHC input" [ resourceId=1417818, direction="WriteOnly", pulseLength=1000 ] //input Items: Switch IHC2Spisebord "Spisebord" { channel="ihc:controller:haldIHC:ihcoutput", channel="ihc:controller:haldIHC:ihcinput" }

@EjvindHald, could you post your test items and rules?

@EjvindHald, Currently only one resource Id per channel is supported. It could be challenging to model this in openHAB2. What is the real use case behind this and do you (or anyone else) have many items which use this kind configuration. This functionality can always be imitated by several channels, virtual items and rules.

I have made lot of improvements the binding and now all features which I planned to implement is implemented. I updated the first post, where is a link to latest jar file and also link to the documentation (draft). I have made some breaking modifications to the binding, so you might need to remove existing thing and add it again. I really appreciate all help in documentation side (more detailed descriptions and examples, etc) as I don't need any documentation myself, so it's purely for your purposes

Thanks Mikkel

Does anyone have idea what is the scale (min, max, etc) of the battery level and signal strength for wireless devices?

Items can't be created as a thing. Which screenshot you are referring? I have created channels which can be then linked to the items. Every channel also have a data type, e.g. Switch, which can be then linked to Switch item.

You can see full channel links e.g. from Paper UI. In my example (test-switch), item definition is Switch testSwitch { channel="ihc:controller:elko:test-switch" }

You can add channels manually from Paper UI Add e.g. switch channel Which will then look like following Or you can manage things and channels via things file (e.g. ihc.things) ihc:controller:elko [ ip="192.168.1.2", username="openhab", password="openhab", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type switch-channel : my_test_switch "My Test Switch" [ resourceId=3988827 ] Type contact-channel : my_test_contact "My Test Contact" [ resourceId=3988827 ] Type number-channel : my_test_number "My Test Number" [ resourceId=3988827 ] } which will look like following

I updated the dropbox link to to updated binding version, which hopefully solve the linking problem. 2.3.0 RC1 Paper UI (at least) have couple issues now open related to channel linking, so there might still be some difficulties to link in some circumstances.

OK, then I guess there is a real problem. What if you add channel manually? Can that be linked?

Did you try to refresh the page (reload the Paper UI page)? I have seen similar problem, but page refresh have always helped (issue is related to Paper UI not the binding itself).

It should work fine.

Here is the link to the first test version <-- see first post --> Just drop the jar file to openHAB addons folder. Binding should work fine also with 2.2 openHAB version. Both version 1 and this new should run parallels also in the same openHAB instance. There is no documentation available yet, so I hope you familiar with the openHAB 2 and paper UI (or things file). I will create documentation, when channel structures and functionalities are more close to the final. Good luck Add new thing... You can add new channels manually from icon right side of the Channels text.

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

You just need to use button state change as a trigger. E.g. Switch light_switch Switch light rule "Toggle light by switch" when Item light_switch changed from OFF to ON then if (light.state == OFF) { light.sendCommand(ON) } else { light.sendCommand(OFF) } end

Sorry the English, but I can't express my self in Danish @Dan Nielsen_30707077, I propose you to run you openHAB instance firstly in windows or mac (if you have any), and when your environment is working fine, then try to move it to Synology. If you start openHAB from command line (start.bat or start.sh) you can easily access Karaf console (without setup SSH). In Karaf console you can easily see logs and change e.g. IHC binding logging level to get more information. http://docs.openhab.org/administration/console.html http://docs.openhab.org/administration/logging.html I also encourage you to search and ask help from openHAB community (https://community.openhab.org/latest), which is very active. @Kandersen, Frontail is not part of the openHAB, but part of the openhabian (http://docs.openhab.org/installation/openhabian.html). Openhabian is script tool set to install openHAB easily to linux environments and it also include some other tools like frontail.