openHAB2 IHC binding

[Pauli Anttila]

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

 

 

[Kandersen]

29 minutter siden, Pauli Anttila skrev:

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

 

I get this error:

2019-03-07 18:36:33.106 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'ihc.things' has errors, therefore ignoring it: [4,27]: extraneous input '' expecting ':'

This is my ihc.things file

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 ]
}

 

[Pauli Anttila]

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 ]

}

 

[Kandersen]

Ahh damit..
It works now. And works with Google Home as well.. I´ll explain later.

[Kandersen]

Explanation.. 
I think I got it now. Having a switch-channel with direction WriteOnly will stay on.. However, the binding itself will send the OFF to the push button/whatever. And this is exactly what´s needed for Google Home to work, and it still believes the "thing" is ON, when it´s actually OFF. I used ServiceView to make sure..
I used the trail log to see what happens, but in this case I´ll never see the OFF beeing send. The actual item will stay on, but in the IHC controller the push-button will go off. Thats why I got this mixed up.   

Now, this was good news.

Bad news is, that even though this is a standard "Kip" operation in IHC, it wont work with binding settings createChannelsAutomatically=true, because direction=WriteOnly has to be set for the channel. So every push-buttons has to have channels created manually. Is that correct understood? 
In the old 1.13 binding, direction was set in items. Now it´s on channels setting, and default is both ways (ReadWrite).. Shouldn´t it be default to WriteOnly, when it´s a push-button, so this can be archived using createChannelsAutomatically?

Btw. Is there any specific reason why default PulsWidth is 1000ms ? As far as I remember from most Functions bloks in Visual using kip, 400ms is default?

[Pauli Anttila]

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

  

16 hours ago, Kandersen said:

Bad news is, that even though this is a standard "Kip" operation in IHC, it wont work with binding settings createChannelsAutomatically=true, because direction=WriteOnly has to be set for the channel. So every push-buttons has to have channels created manually. Is that correct understood? 

Yes, binding create channels automatically for all "physical" inputs/outputs.

16 hours ago, Kandersen said:

Shouldn´t it be default to WriteOnly, when it´s a push-button, so this can be archived using createChannelsAutomatically?

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" }

 

16 hours ago, Kandersen said:

Btw. Is there any specific reason why default PulsWidth is 1000ms ? As far as I remember from most Functions bloks in Visual using kip, 400ms is default?

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.

[Kandersen]

I do understand most part of it. What I´d fail to understand (misunderstood) is the puls sending ON and x=ms after sending OFF. This part it not noticable in the logfile, if it´s a switch channel, (ie a wired dimmer on the "touch" resourceID). Thats why I wrongly used a rule to trigger the item OFF.  

19 timer siden, Pauli Anttila skrev:

So if you want to control you light via Google Home, you should control the light output itself not emulate the push button press. 

Yes, thats what I learned the hard way, which the 2.4 binding 
My original idea was to let openhab simulate all  human aspect, (ie pushing buttons, which is why I focused on linking the buttons. But in many cases it seems more effective to link to the actual product itself (functionblok). However, this requires to create the channels manually, cause it requires channels options/paramters, like when linking to a wired dimmer. I can not used the auto created channel in that situation. This is okay, but I would have prefered to use the auto created channel, as it makes things alot easier.. 

However.. This example you just showed here, I believe it would be a problem tagging for Google Home controle....

19 timer siden, Pauli Anttila skrev:

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" }

 

How would you Tag that item? It´s both an ["Lighting"] and a ["Switchable"], cause you have both the trigger and the state in the same item? 

The above is almost like I have done it now, except, I had to use two items as well. One for triggering the "touch" resourceID of a wired UN400 dimmer. And the other resourceID for state of the UNi400 dimmer. Google Home Tag has to be set to the triggering item like this:

Switch kitchenLightTrigger ["Lighting"] { channel="ihc:controller:elko:trigger" }

And state like this:

Switch kitchenLightState { channel="ihc:controller:elko:state" }

I assume this is the correct way of doing it? (notice, without autoupdate="false") 

[Pauli Anttila]

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]

I´ll have to give it a try. Thats the least I can do 

[Kandersen]

Hi @Pauli Anttila

I tried the above. And it works fine.. However, I get a warning when I use direction="ReadOnly" for my light state. (the update still works though).

This is my things file:
 

ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="adminIHC0101", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] {
    Channels:

	   Type switch-channel   :bryggers_dimmer_fb       "Bryggers dimmer Trigger"   [ resourceId=12059409, direction="WriteOnly", pulseWidth=200 ]
	   Type switch-channel   :bryggers_dimmer_state    "Bryggers dimmer state"     [ resourceId=12062482, direction="ReadOnly" ]
	

}

This is my item:
 

Switch bryggers_DimmerLys     "Bryggers Halogenlys [%s]"    <light>    [ "Lighting" ] 	 { channel="ihc:controller:elko:bryggers_dimmer_fb", channel="ihc:controller:elko:bryggers_dimmer_state", autoupdate="false" }

And this is the warning I get, when the item is triggering. 
 

2019-03-11 23:48:54.603 [WARN ] [ding.ihc.internal.handler.IhcHandler] - Read only channel, skip the update to ihc:controller:elko:bryggers_dimmer_state

This is the resourceID´s I use.

[Pauli Anttila]

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

[Kandersen]

12 minutter siden, Pauli Anttila skrev:

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

Okay,. great.

 

12 minutter siden, Pauli Anttila skrev:

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

The above is a UNI400 wired dimmer. Unfortunaltly it doesn´t have a "real" output state. Thats why I use the function blok. I know it´s a small risk, but it´s the best these kind of dimmers can do. And I have never seen it do out of sync, yet. 
Other devices I monitor the output state on the product side. 

[Pauli Anttila]

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]

17 timer siden, Pauli Anttila skrev:

Controller address parameter is not anymore ip, but hostname

Why this change?? Wouldn´t it be better to allow both options?

17 timer siden, Pauli Anttila skrev:

Before that, new version can be found starting at tomorrow from official openHAB snapshot builds.

Where to download just the binding (.jar)? I dont want to install/upgrade my openhab 2.4 (yet) 

[Pauli Anttila]

5 hours ago, Kandersen said:

Why this change?? Wouldn´t it be better to allow both options?

Only parameter name has been changed, so you can still give a direct IP address to hostname variable with or without used TCP port.

6 hours ago, Kandersen said:

Where to download just the binding (.jar)?

Snaphots are available on openHAB main download page. This is the todays snapshot, which will be old tomorrow  

[Kandersen]

2 minutter siden, Pauli Anttila skrev:

Snaphots are available on openHAB main download page.

I know.. But that´s the main core openHAB system. 

6 minutter siden, Pauli Anttila skrev:

This is the todays snapshot, which will be old tomorrow

Thats what I was asking for  

[Kandersen]

På 12.3.2019 at 17:04 , Pauli Anttila skrev:

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.

@Pauli Anttila I just tried the 2.5.0 snapshot version (downloaded link). I cant get it online.. 
This is the logfile:
 

2019-03-14 21:54:01.874 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2019-03-14 21:54:02.287 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING)
2019-03-14 21:54:02.331 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED (HANDLER_CONFIGURATION_PENDING) to UNINITIALIZED (HANDLER_MISSING_ERROR)
2019-03-14 21:54:02.340 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:elko' has been updated.

This is my cfg file:
 

ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="adminIHC0101", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] {
    Channels:
	
	   Type switch   :stortbad_dimmer_fb       "Stortbad dimmer Trigger"   [ resourceId=5537553, direction="WriteOnly", pulseWidth=200 ]
	   Type switch   :stortbad_dimmer_state    "Stortbad dimmer state"     [ resourceId=5540626, direction="ReadOnly" ]

	   Type switch   :sove_80mm_fb              "Soveværelse 80mm Trigger"          [ resourceId=17073937, direction="WriteOnly", pulseWidth=400 ]	   
  	   Type switch   :sove_80mm_state           "Soveværelse 80mm lampeudtag"       [ resourceId=26459, direction="ReadOnly" ]

       Type switch   :bryggers_dimmer_fb       "Bryggers dimmer Trigger"   [ resourceId=12059409, direction="WriteOnly", pulseWidth=200 ]
	   Type switch   :bryggers_dimmer_state    "Bryggers dimmer state"     [ resourceId=12062482, direction="ReadOnly" ]
	   Type switch   :bryggers_skabslys_fb     "Bryggers skabslys Trigger" [ resourceId=1317905, direction="WriteOnly", pulseWidth=400 ]	   
	
       Type switch   :lillebad_dimmer_fb       "Lille Bad dimmer Trigger"   [ resourceId=12208913, direction="WriteOnly", pulseWidth=200 ]
	   Type switch   :lillebad_dimmer_state    "Lille Bad dimmer state"     [ resourceId=12211986, direction="ReadOnly" ]
	   
	   
}

 

[Kandersen]

@Pauli Anttila I just tried the 2.5.0 snapshot version (downloaded link). I cant get it online.. 
This is the logfile:
 

EDIT - Works now..Forgot the hostname 

 

[Kandersen]

@Pauli Anttila is it possible to set the read/write direction in the items file rather than in the things file?
Most of my output items only require a direction="ReadOnly". But when default is read/write, I have to create an thing, only for this. In the old binding we could make use of <> as for direction. 

[Kandersen]

@Pauli Anttila I need some help with controling a input for functionblok 1.1.04.c (følg/inverter).
I have tried all sorts of combination. But I simply cant get this work.
If I link the channel directly to the resourceID of the input and using the pulseWidth, then nothing happens at all. Like this:

Type switch   :Nilan_brugerfunktion         "Aktiver Nilan brugerfunktion"         [ resourceId=14474513, direction="WriteOnly", pulseWidth=1000 ]

The item I have linked to the channel receives ON just fine. But nothing happens in the IHC controller. <-- thats the weird part. 
 
If I link the channel to a push button resourceID without pulseWidth, the input goes ON, but does not return OFF. (due to not using the pulseWidth I assume).  Like this:
 

Type switch   :Nilan_brugerfunktion         "Aktiver Nilan brugerfunktion"         [ resourceId=20570 direction="WriteOnly" ]

For now, the only way to get this to work is to use the last option, and then use a rule to turn the input (switch button) to turn OFF again. 

I´m pretty sure this has something to do with the functionblok. But it´s way over my head, as it works just fine when pushing the push-button manually.  

This is a screendump of the funtionblok as well as the product: 
I have tried both input (function blok) and output (product side). Whenever I use pulseWidth, I get nothing through the IHC controller. 

[Pauli Anttila]

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

[Kandersen]

47 minutter siden, Pauli Anttila skrev:

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

I will add tracelog, hopefully tonight..
PulseWidth works fine with other items (teste with my UNI400 dimmers). Thats why I have a slight idea, it´s the function blok. But it doesn´t make sense, because the function blok works fine when using a push button.. I would expect the binding to do exactly the same. 

BUT!!
I had exactly the same problem with pulsewidth and another function blok for "ordinary kip" the day before yesterday..
For some reason I cant figure and cant explain, the "ordinary kip" function blok I use in my IHC program was NOT simular to the "ordinary Kip" function blok in Visual 2.8 I´m using.
(I think the previous owner of our house have made some changes, or this is an older "ordinary kip" function blok from an older version of Visual). 
I could NOT get pulsewidth to work with this function blok either. I exprienced exactly the same problem as mentioned above. Both "ordinary kip" function bloks are suppose to be the same version according to their notes, but the "wrong" one didn´t have the same inputs/outputs as descriped in the notes, which is why I discovered something was wrong, (beside binding didnt work with pulsewidth ofcouse). 
I exchanged the function blok with the same  "ordinary kip" function blok in the latest Visual, and then pulseWidth worked fine. (It took me quite some time to figure this one ) 
Whats even more strange.. This "wrong" "ordinary kip" function blok works fine using the old IHC 1.13 binding.  

As for the function blok mentioned above (1.1.04.c følg/inverter), I have no alternatives, so I cant´exchange it to something else 

I really hope this is not a typical situation. cause I have to start all over rediscovering resourceID´s whenever I exchange a function blok 

[h.hojgaard]

@Pauli Anttila I just upgraded the binding that I had from the dropbox link below

På 9.1.2019 at 18:13 , Pauli Anttila skrev:

https://www.dropbox.com/s/kaebm8nve8y84c7/org.openhab.binding.ihc_2.4.0.201901091843.jar?dl=0

to the latest snapshot build 12-3-2019

På 13.3.2019 at 16:43 , Pauli Anttila skrev:

Snaphots are available on openHAB main download page. This is the todays snapshot, which will be old tomorrow  

I did the changes as specified below to my .things file

På 19.5.2018 at 13:57 , Pauli Anttila skrev:

• Controller address parameter is not anymore ip, but hostname
• "-channel" suffix is removed from channel types. E.g. switch-channel is just switch.

and my .things file now looks as below, but what used to is not working anymore.

ihc:controller:b5a36ad0 [hostname="192.168.1.2", username="secret", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=true] {
Channels:
  Type switch  : FB_dim_output     "dimmer status"  [resourceId=2717970, direction="ReadOnly"]
  Type switch  : FB_dim_input1     "dimmer On"      [resourceId=2715409, direction="WriteOnly", pulseWidth=100, commandToReact="ON"]
  Type switch  : FB_dim_input2     "dimmer Off"     [resourceId=2715665, direction="WriteOnly", pulseWidth=100, commandToReact="OFF"]
}

The "status" channel works fine, but the light/dimmer is not switched On or Off anymore from openhab

Switch GF_K_Light "Spisebord" <light> (gLight) ["Lighting"] {channel="ihc:controller:b5a36ad0:FB_dim_output", channel="ihc:controller:b5a36ad0:FB_dim_input1", channel="ihc:controller:b5a36ad0:FB_dim_input2"}

If I change the channel configuration in my .things file to

ihc:controller:b5a36ad0 [hostname="192.168.1.2", username="secret", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=true] {
Channels:
  Type switch  : FB_dim_output     "dimmer status"  [resourceId=2717970, direction="ReadOnly"]
  Type switch  : FB_dim_input1     "dimmer On"      [resourceId=2715409]
}

the light/dimmer is turned on but then it's just working as a infinite LONG_PRESS (triggering the dimmer function) until I switch the light off from the button in my wall.

Is it some bug, or something I'm missing out?

[Pauli Anttila]

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

[Pauli Anttila]

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

[h.hojgaard]

24 minutter siden, Pauli Anttila skrev:

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

@Pauli Anttila Still want a part of the trace-log? - just a small section copy/paste - but it seems like it sends 100ms pulse to the correct ressourceId, but not triggering anything within the controller.

2019-03-15 18:03:58.775 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - 0 new notifications received from controller
2019-03-15 18:03:58.778 [TRACE] [ab.binding.ihc.internal.ws.IhcClient] - Wait new resource value notifications from controller
2019-03-15 18:03:58.780 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://192.168.1.2/ws/ResourceInteractionService, connectionPool=30972376, clientId=27920072 requestId=84, timeout=10000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?>
2019-03-15 18:04:03.254 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Received channel: ihc:controller:b5a36ad0:FB_dim_output, command: ON
2019-03-15 18:04:03.260 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Channel params: [ channelTypeId=switch, resourceId=2717970, direction=ReadOnly, commandToReact=null, pulseWidth=null, inverted=false, serialNumber=null, longPressTime=null ]
2019-03-15 18:04:03.262 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Read only channel, skip the update to ihc:controller:b5a36ad0:FB_dim_output
2019-03-15 18:04:03.267 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Received channel: ihc:controller:b5a36ad0:FB_dim_input2, command: ON
2019-03-15 18:04:03.272 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Channel params: [ channelTypeId=switch, resourceId=2715665, direction=WriteOnly, commandToReact=OFF, pulseWidth=100, inverted=false, serialNumber=null, longPressTime=null ]
2019-03-15 18:04:03.274 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Command 'ON' doesn't equal to reaction trigger parameter 'OFF', skip it
2019-03-15 18:04:03.278 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Received channel: ihc:controller:b5a36ad0:FB_dim_input1, command: ON
2019-03-15 18:04:03.282 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Channel params: [ channelTypeId=switch, resourceId=2715409, direction=WriteOnly, commandToReact=ON, pulseWidth=100, inverted=false, serialNumber=null, longPressTime=null ]
2019-03-15 18:04:03.285 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Command 'ON' equal to channel reaction parameter 'ON', execute it
2019-03-15 18:04:03.287 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Send 100ms pulse to resource: 2715409
2019-03-15 18:04:03.291 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Channel params: [ channelTypeId=switch, resourceId=2715409, direction=WriteOnly, commandToReact=ON, pulseWidth=100, inverted=false, serialNumber=null, longPressTime=null ]
2019-03-15 18:04:03.294 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Update resource value (inverted output=false): [resourceId=2715409, value=false]
2019-03-15 18:04:03.299 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://192.168.1.2/ws/ResourceInteractionService, connectionPool=30972376, clientId=27920072 requestId=85, timeout=5000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?>
2019-03-15 18:04:03.410 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Received response (connectionPool=30972376, clientId=27920072 requestId=85, in PT0.108S, headers=[content-type: text/xml; charset="utf-8", date: Fri, 15-Mar-2019 17:04:02 GMT, keep-alive: timeout=900, max=1000, connection: Keep-Alive, content-length: 363, server: Rogatkin's JWS based on Acme.Serve/$Revision: 1.39 $, mime-version: 1.0, set-cookie: JSESSIONID=-1552669084058-0-216]): <?xml version='1.0' encoding='UTF-8'?>
2019-03-15 18:04:03.423 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Sleeping: 100ms
2019-03-15 18:04:03.525 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Update resource value (inverted output=false): [resourceId=2715409, value=false]
2019-03-15 18:04:03.527 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://192.168.1.2/ws/ResourceInteractionService, connectionPool=30972376, clientId=27920072 requestId=86, timeout=5000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?>
2019-03-15 18:04:03.633 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Received response (connectionPool=30972376, clientId=27920072 requestId=86, in PT0.104S, headers=[content-type: text/xml; charset="utf-8", date: Fri, 15-Mar-2019 17:04:02 GMT, keep-alive: timeout=900, max=1000, connection: Keep-Alive, content-length: 363, server: Rogatkin's JWS based on Acme.Serve/$Revision: 1.39 $, mime-version: 1.0, set-cookie: JSESSIONID=-1552669084058-0-216]): <?xml version='1.0' encoding='UTF-8'?>
2019-03-15 18:04:03.892 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Received response (connectionPool=30972376, clientId=25146008 requestId=70, in PT5.145S, headers=[content-type: text/xml; charset="utf-8", date: Fri, 15-Mar-2019 17:03:58 GMT, keep-alive: timeout=900, max=1000, connection: Keep-Alive, content-length: 461, server: Rogatkin's JWS based on Acme.Serve/$Revision: 1.39 $, mime-version: 1.0, set-cookie: JSESSIONID=-1552669084058-0-216]): <?xml version='1.0' encoding='UTF-8'?>
2019-03-15 18:04:03.903 [TRACE] [ab.binding.ihc.internal.ws.IhcClient] - Controller state text.ctrl.state.ready
2019-03-15 18:04:03.905 [TRACE] [ab.binding.ihc.internal.ws.IhcClient] - Wait new state change notification from controller
2019-03-15 18:04:03.910 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Received response (connectionPool=30972376, clientId=27920072 requestId=84, in PT5.126S, headers=[content-type: text/xml; charset="utf-8", date: Fri, 15-Mar-2019 17:03:58 GMT, keep-alive: timeout=900, max=1000, connection: Keep-Alive, content-length: 446, server: Rogatkin's JWS based on Acme.Serve/$Revision: 1.39 $, mime-version: 1.0, set-cookie: JSESSIONID=-1552669084058-0-216]): <?xml version='1.0' encoding='UTF-8'?>
2019-03-15 18:04:03.908 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://192.168.1.2/ws/ControllerService, connectionPool=30972376, clientId=25146008 requestId=71, timeout=10000, headers=[SOAPAction: waitForControllerStateChange, content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?>
2019-03-15 18:04:03.923 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - 0 new notifications received from controller