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 
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
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 
Thanks Kai, still getting used to the new multi-repo model.
As it turned out, there were build related errors as a result of my change that only cropped up when I did mvn clean install from the openhab-distro repo.
I submitted & merged PR 3947 to correct those, hopefully I got in before the nightly build
@lolodomo,
With the combined set of changes, I have confirmed that I’m able to install the MiOS Action as an Extension from within the Paper UI and that pulls in the MiOS Binding, along with the conf/services/mios.cfg file, and the required conf/transform/mios*.map files.
It’s still a compatability-mode Binding, and folks will need to configure the IP/DNS address of their MiOS unit (via the conf/services/mios.cfg file) and use the MiOS Item generator to get a starting Items file, but it’s a lot simpler to get going now.
There will likely still be rough edges, and these can be followed up in separate community threads and/or GitHub issues.
Thanks for the push!
@guessed: using OH2 snapshot 114, that looks good.
MAP files were installed automatically.
The only problem I encountered is that I was using a special MAP file I probably created in the past, a file named miosBooleanIn.map with this content:
1=ON
true=ON
yes=ON
0=OFF
false=OFF
no=OFF
Of course, this file was missing.
Regarding the dimming slider in HABdroid, that is now working well but I got this warning:
21:05:16.219 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'LampeEntreeDim' received command 0
21:05:16.223 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '0' with the file 'miosDimmerCommand.map'.
No problem with my MiOS actions in rules.
1 Like
Yup, that’s the same WARN that’s logged under openHAB 1.x
It occurs because, for this situation, I run the transform twice. The first time is a key-miss for the numeric value, and the second time around I look for the value of the key _defaultCommand, and I substitute in the real value for the ??
Here’s miosDimmerCommand.map:
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=??)
So the first time we look for 0, we don’t find a map entry, and the second time around, we look for the value of _defaultCommand, substitute 0 for the ?? pattern in the returned value, and end up with:
urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=0)
which will look familiar to you.
I could pre-include values 0...100, but that would be overkill. It might be worthwhile adding in defaults for 0, 50 & 100… not sure how much that’d really reduce the log-noise though 
I’ll add these to miosSwitchIn.map, so you can cutover to using a pre-configured/shipped MAP file. They can’t be in the reverse map (miosSwitchOut.map), for obv reasons, but it should save users a step.
I’ll bundle it with another dependency fix I need to make.