[Fixed] Mios binding 1.8 not working in openHAB2

@guessed, forget my last message, I think I just forgot to install first the compatibility layer bundle.
Will try again.

Bingo; it seems to work now. Great, great. Will start more tests.

1 Like

I found 1 issue when I try to play with any dimming light:

22:37:04.123 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'LampeEntreeDim' received command 81
22:37:04.130 [ERROR] [ding.mios.internal.MiosUnitConnector] - callDevice: The parameter is in the wrong format.  BindingConfig 'unit:house,device:430/service/urn:upnp-org:serviceId:Dimming1/LoadLevelStatus,command:MAP(miosDimmerCommand.map)', UPnP Action '81'

Except that, I found nothing else wrong.

But I only played with the UI, no rule yet enabled. That is the next step.

PS: the same controls are working well in 1.8.

What client are you using? When I do this with the Classic UI, using my imported sitemap’s ^ v buttons on the Dimmer UI component, they’re working correctly in my runtime (from the Eclipse IDE)

My addons.cfg has the lines to include mios Action/Binding as well as the map transform:

package = standard
binding = mios
ui =  basic,paper
persistence = rrd4j,mapdb
action = mios
transformation = map
tts = 
misc = 

and I have the usual miosDimmerCommand.map manually installed into OH2’ transform directory:

INCREASE=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=?++)
DECREASE=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=?--)
OFF=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=0)
ON=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=100)
_defaultCommand=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=??)

PS: Where did the slider UI go? Under 1.8, there’s a clean Slider, but under OH 2 we’ve got the older style ^ v buttons.

I used HABdroid to test the dimming lights.

MAP transformation service is installed in my OH2 too.
And my file miosDimmerCommand.map (identical to yours) is present in my conf/transform directory.

Under 1.8 this is heavily broken, see

Waiting for an 1.8.1 to fix that - and it should also be ported to ESH by @sebastian, he cancelled a first try.

I created another topic thinking in a first time that my problem was something else but in fact my problem seems to be sendMiosAction.

@guessed: I don’t have same error as you.

@guessed: I opened issue 3926 for the binding.
An issue has to be opened for the MiOS action.

Thanks @lolodomo!

Can you also tag this thread with “mios”, so it’ll be easier for me to chase down. There’s a lot of volume in postings lately.

I got it to reproduce using my iPhone, and drilled into it a little with the debugger and can see that OH 2 has changed the behavior of the MAP Transformation service (which I rely upon heavily for the MiOS Binding fallback values - Dimmers, Temp settings etc)

Under openHAB 1.x, calling upon a MAP transform would return null or "" if there was no mapped value, but under OH 2 it’s returning the original source value (similar to how the REGEX transform fails under openHAB 1.x)

Anyhow, I’ll change the MiOS Binding code to handle this scenario as well (it currently looks for null and "").

@Kai : I’m not sure that’s a desirable change in behavior, esp given folks have written Rules against the existing behavior, as the difference is subtle and will likely go un-noticed for a while.

1 Like

@lolodomo,
PR 3932 filed and out for peer review:

It now handles the openHAB 1.x result in addition to the new result from the OH 2/compat1x layer, so it’ll work either way.

NB: The previous JAR link on Box won’t have these fixes, but they’re less critical.

I think I have tracked this down to having been introduced together with the Scale transformation service in this commit.
As the Scale transformation service also exists in openHAB 1.8, I would actually expect the same code to be there as well?

You’re right about that ESH Checkin having normalized the behaviors in that env, but it wasn’t modified in OH:

and the OH 1.x Transformation framework is looking for a TransformationException to trigger the “return the original value” behavior, which won’t happen in the MAP Transform.

Here’s the specific part of the commit you’re referencing that changes the logic/behavior in ESH:

I haven’t seen anything overlaying what the intended behavior of a Transformation Service should be, so I can understand why it’s been implemented differently in each.

If it is going to change, then it needs to be release noted in the same location as the Undefined/Uninitialized -> UNDEF/NULL change. I recall you making reference to that, but I can’t find it now.

why it’s been implemented differently in each.

You mean different between OH1 and ESH or different between different transformation services?

Why it is how it is in ESH, we should probably ask Gael, but it seems he isn’t even a registered user here in the forum… I’ll try to ping him.

Sorry, I meant why it’s been implemented differently between the different Transformation services (within OH1). Haven’t had my coffee yet :wink:

So you mean it is actually cleaner in ESH, because all services behave the same way? So shall I get Gael in the discussion or do we agree what he did makes sense?

@guessed: as suggested by Kai, would it be possible that you update rhe feature file to get an automatic installation of all required MiOS map files when installing the binding from OH2 ?

Yeah, that’s the bit I’m working on atm.

@kai, I implemented this under PR 3946:

I spent a while trying to work out how to build the equivalent of the stand-alone ZIP, with my fixes included, but couldn’t work it out. It’ll likely need a second set of eyes, but I based it upon what the Demo does, along with a tweak to handle how the Maven plugin documents the intended usage of the <type> attribute.

Do you have a pointer for how to build the equivalent of the stand-alone ZIP so it can be tested locally, or do we roll the dice on the merge :wink:

Thanks! In general, all you would need to do is to run a maven build within the OH1 features folder, which will install the Karaf feature definition in your local Maven repo. If you then run a Maven build of openhab-distro, this should be automatically picked up and you can try the result directly.
As it is late at night for me already, I have chosen the shortcut through and merged your PR after looking at it (which was fine) - so let’s roll the dice :slight_smile: