Pauli Anttila

@Kandersen, I think that is openHAB core issue and not related to binding. I assume that correct level is used if you restart the openHAB?

@Kandersen, from here you can find first test version for configurable ON level. It should work with dimmer channels and you need to add onLevel channel parameter (e.g. onLevel=70). I don't have IHC dimmers so I didn't test it well.

Not sure what do you mean by this? OH2 binding doesn’t have any dependencies to OH1 binding. Or do you mean that is all OH1 features supported by the OH2 binding? If yes, it’s pretty impossible the say as there is so many different ways one can use the binding, so basically you need to try by you self and see if you can fully replace OH1 binding by OH2 binding.

Changes are merged, so latest official snapshot should be ok. Yes, I'm aware of what is happening on development side pretty well. Latest 7 years, I have developed over 10 OH1 bindings, 8 OH2 bindings (+2 is in pipeline), several transformation services and countless amount of improvements and bug fixes to many other bindings and core features.

@Kandersen, the fixes are now merged to main repo. I also fixed the Dimmer ON command bug. Binding now set Dimmer to 100 when ON command is received. In fact, binding set resource to resource max value by ON command and to resource min value by OFF command. Dimmer min is 0 and max is 100, but some other resources min and max could be something else. I didn't introduce configurable level yet.

@Kandersen, I’m currently travelling, so I will fix that near future (after week or so).

@Kandersen, I guess that this is not ihc binding problem, but related to google home or openhab core. 2019-03-18 22:36:29.668 [ome.event.ItemCommandEvent] - Item 'casperDimmerLys' received command ON 2019-03-18 22:36:29.967 [ome.event.ItemCommandEvent] - Item 'casperDimmerLys' received command ON 2019-03-18 22:36:30.472 [vent.ItemStateChangedEvent] - casperDimmerLys changed from OFF to ON Two ON commands are logged by the openHAB framework, so even if you remove ihc binding you should see the same.

@Kandersen, I agree, value should be 100. Anyhow, could you prove logs. It should also be possibe to introduce level parameter for dimmer channel, which define the ON level (e.g. 80%).

@h.hojgaard, @Kandersen, thats great I encourage all others test the lates version as well, so that I can fix all problem hopefully before openHAB 2.5 release.

Could you try this version?

@h.hojgaard, @Kandersen Pulse command doesn't work correctly, I try fix it soon.

@h.hojgaard, i have made small changes lataly here and there because of code review process, so it’s possible that I have broke something. I don’t personaly e.g. use pulse feature or multi channel per item features at all, so I have not made good testing either. Could you enable trace level logs, so that I can see what is happening between openhan and controller?

@Kandersen, could you enable TRACE level logs and sent them to me, so that we can see what is going on. Does pulseWidth parameter work with other items?

Only parameter name has been changed, so you can still give a direct IP address to hostname variable with or without used TCP port. Snaphots are available on openHAB main download page. This is the todays snapshot, which will be old tomorrow

Binding has been merged to openHAB main repository and will available in 2.5 version. Before that, new version can be found starting at tomorrow 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.

@Kandersen, you can ignore the warning. That was accidental logged in warning level, but I have fixed this already in newer versions (can't remember in which version). You monitor light state from functional block (resource id 12062482). That work fine if functional block really knows the light state all the time. I don't know your whole setup, but I still recommend you to monitor the output (controller output) where light is connected to. Then openHAB also knows the real state of the light (not just functional block understanding).

I don't see any reason why you should have two items for one light. Light should be on item and if it's light then tag should be light as well, right. If you control light directly, without function block, you only need one item, right. But when you use functional block to control the light state, resource id doesn't tell in which state the light is and that's why you need additional readonly channel. So, with following Channels: Type switch-channel : trigger "Light trigger" [ resourceId=1001, direction="WriteOnly", pulseWidth=400 ] Type switch-channel : state "Light state" [ resourceId=1002, direction="ReadOnly" ] Switch kitchenLight { channel="ihc:controller:elko:trigger", channel="ihc:controller:elko:state", autoupdate="false" } when you send command to kitchenLight item by rules, by UI or by Google Home, IHC binding will send triggering pulse to function block (resource id 1001). Function block then do what is defined. If at the end, light state will change by the function block, IHC controller will send state change notification to the binding (resource id 1002) and IHC binding will update kitchenLight to match the light state. If you then push your physical button, IHC controller will then send again state change notification to the binding (resource id 1002) and IHC binding will update kitchenLight to match the light state. Autoupdate=false is needed that openHAB itself doesn't make any expectation about light state, but it will fully follow the IHC controller state.

@Kandersen, not sure if you have fully understand the openHAB 2 concept. So, let me try to explain the basics. Items represent the home automation capabilities, which aren't linked to any physical device. So let say that we have switch item which represents the kitchen light. If you want to put kitchen light ON, you send a COMMAND to item. If you know that the light is ON, and you want Switch item to reprints the light state, you send an UPDATE to item. As items are not linked to any physical device (bindings) by default, there is a autoupdate binding linked to all items by default. This means that, when you send a command to item, openHAB core will set/update item state to match the command automatically. So if you send ON command to item, item will be updated to state ON automatically. All openHAB UI's send commands when you want to control something. Also when you want to control some items by the rules, you send commands. Also Google Home send commands when you want to control something by voice. Now, if you link your items to physical device, you link item to Thing channel, which can be channel from IHC binding or e.g. Philips Hue channel. When you send a command to item which have linked to binding, openHAB core will pass the command to binding, which will the control the physical device. Autoupdate binding is still enable by the default, so item state is updated, even binding could not control the physical device. Binding duty is also update the channel state if physical device state changes . This depends on binding implementation and protocol capabilities between physical device and binding if this is possible. So if you physical item is e.g. Philips hue lamp and you put you lamp ON by hue application on your phone, hue binding will recognise the lamp state change and send an update to channel which will be then propagated to item state. So those basic principles are valid for IHC binding as well. If you disable autoupdate binding from you IHC connected item, item state will follow the resource id state (direction is not set). If you send a command to item, command is send to IHC resource. If IHC controller accept the command, controller will send the status update to binding and binding will update the channel state which is then propagated to linked item. IHC binding channel have now couple of special features like direction and pulseWidth. Those parameters can be used to change this normal behaviour. By default, direction is ReadWrite, which means that command are send to IHC controller (write) and also updates from controller are updated to channel (read). This behaviour can now be changed. If you configure direction to write only, binding will only send commands to IHC controller, but ignore all updates from controller for that specific resource id (channel). If you configure direction to read only, binding will reject all commands but just make update from controller to channels. Remember that autoupdate binding will still change the item state if it's enabled. Pulse width parameter is special functionality to trigger function block inputs, which normally need rising edge to do something. If pulse width parameter is enabled, binding will always send boolean ON to resource id, wait specified milliseconds and then set resource id back to boolean OFF (this is the pulse). So it doesn't matter is item switch item or Dimmer item, binding will always send a pulse to controller resource. Resource id need to be boolean variable in the IHC side of course when pulse width is used. Yes, binding create channels automatically for all "physical" inputs/outputs. No, default actually should be read only for inputs Or inputs should be Contact channels not Switch channels. Push button's output (wire) is connected to IHC controller's input, so input is the input of the IHC controller, not output of the push button. So in that sense IHC binding shouldn't set input states, but I didn't want to make restriction by default, so also inputs are readwrite by default. So opinion is still that you and others try to model you openHAB items wrongly with IHC binding. And that's also the reason why you struggling and have so many problems.So if you want to control you light via Google Home, you should control the light output itself not emulate the push button press. If you still want to control the light via function block (one input), you should define at least two channels. One is write only and other read only, which is the output state (the light itself). Channels: Type switch-channel : trigger "Light trigger" [ resourceId=1001, direction="WriteOnly", pulseWidth=400 ] Type switch-channel : state "Light state" [ resourceId=1002, direction="ReadOnly" ] Switch kitchenLight { channel="ihc:controller:elko:trigger", channel="ihc:controller:elko:state", autoupdate="false" } There is no default value, you need always define pulse width parameter if you want to use it and you can give anything you want.

There seems to be illegal character (invisible) immediately after switch-channel. ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="password", timeout=8000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type switch-channel� : my_test_trigger "My Test Trigger" [ resourceId=20058, direction="WriteOnly", pulseWidth=1000 ] }

Sorry @Kandersen, that's old staff. There is no anymore dedicated pulse output channel as you can define pulse width in every channel type. So, Type switch-channel : my_test_trigger "My Test Trigger" [ resourceId=20058, direction="WriteOnly", pulseWidth=1000 ] should work (not tested)...edited pulseLenght -> pulseWidth nowadays

Your thing file have an error somewhere. Could your post whole file content?

You don’t need to introduce two channels, because you control only one resource id fron ihc controller. Type pulse-output-channel : ihcinput "IHC input" [resourceId=3931665, direction="WriteOnly", pulseLength=1000]  this will generate on/off “pulse” (pulse width 1000ms) to resourceId 3931665 and channel will not follow the resourceId 3931665 state as direction is set to write only mode. So binding will set input ON, wait 1000ms and then set input back OFF. Trigger parameter, nowadays commandToReact is used if you just want to send pulse when channel/item receive certain command (like ON or e.g. for dimmer type INCRESE).

@Kandersen, So there is a function block behind of input30298? Function block input need raising/falling edge to do something, right? As input state is already OFF when OFF is written, nothing happens. There is a pulseWidth parameter which can be used to send pulse to input rather than switch state. See page 2 and 3 on OH2 binding topic in this forum

@Kandersen, So if I understand this correctly, you have a rule which will set Switch OFF after 200ms? If yes, this is most probably the reason why it doesn't work from Google Home when you say OFF as you item state is already OFF. You should be able to see this from openHAB logs. What happens when you say OFF, will item receive OFF command? You can even remove IHC binding linking from the item as it shouldn't have influence to this.

IHC controller doesn't provide battery level information. There is only boolean info available. Battery level is good or low and rf-device-low-battery-channel will follow that information.