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