MIOS Binding Thermostat

jpete7683 · October 10, 2016, 2:05pm

Here is my logging:
openhab> log:list
Logger | Level

Here is the output in the log with debug logging:
2016-10-10 08:56:24.709 [DEBUG] [ab.binding.mios.internal.MiosBinding] - internalReceiveCommand: itemName ‘CT100_SETPOINT_HEAT’, command '69.0’
2016-10-10 08:56:24.710 [DEBUG] [ding.mios.internal.MiosUnitConnector] - callDevice: Need to remote-invoke Device ‘unit:house,device:3/service/urn:upnp-org:serviceId:TemperatureSetpoint1_Heat/CurrentSetpoint’ action ‘69.0’ and current state ‘70’)
2016-10-10 08:56:24.712 [ERROR] [ab.binding.mios.internal.MiosBinding] - Error handling command
org.openhab.core.transform.TransformationException: An error occured while opening file.
at org.openhab.core.transform.TransformationHelper$TransformationServiceDelegate.transform(TransformationHelper.java:63)[196:org.openhab.core.compat1x:2.0.0.201610072017]
at org.openhab.binding.mios.internal.config.DeviceBindingConfig.transformCommand(DeviceBindingConfig.java:442)[195:org.openhab.binding.mios:1.9.0.201610070111]
at org.openhab.binding.mios.internal.MiosUnitConnector.callDevice(MiosUnitConnector.java:192)[195:org.openhab.binding.mios:1.9.0.201610070111]
at org.openhab.binding.mios.internal.MiosUnitConnector.invokeCommand(MiosUnitConnector.java:378)[195:org.openhab.binding.mios:1.9.0.201610070111]
at org.openhab.binding.mios.internal.MiosBinding.internalReceiveCommand(MiosBinding.java:271)[195:org.openhab.binding.mios:1.9.0.201610070111]
at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97)[196:org.openhab.core.compat1x:2.0.0.201610072017]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:42)[196:org.openhab.core.compat1x:2.0.0.201610072017]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[3:org.apache.karaf.services.eventadmin:4.0.4]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[3:org.apache.karaf.services.eventadmin:4.0.4]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_91]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_91]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_91]

Here is the transformation files that I have:
readme.txt
en.map
de.map
miosZWaveStatusIn.map
miosWeatherConditionGroupIn.map
miosUnSwitchIn.map
miosUPnPTransportStatePlayModeCommand.map
miosUPnPRenderingControlVolumeCommand.map
miosUPnPRenderingControlMuteCommand.map
miosTStatSetpointHeatCommand.map
miosTStatSetpointCoolCommand.map
miosTStatModeStatusCommand.map
miosTStatFanOperatingModeCommand.map
miosSwitchOut.map
miosSwitchIn.map
miosStatusIn.map
miosShutterCommand.map
miosSceneActiveIn.map
miosMSwitch8.map
miosMSwitch7.map
miosMSwitch6.map
miosMSwitch5.map
miosMSwitch4.map
miosMSwitch3.map
miosMSwitch2.map
miosMSwitch1.map
miosLockCommand.map
miosDimmerCommand.map
miosDeviceStatusUI.map
miosContactOut.map
miosContactIn.map
miosArmedCommand.map

guessed · October 11, 2016, 3:35pm

That’s odd. Based upon the stack you’re seeing, and the (likely) type of the Item CT100_SETPOINT_HEAT, it should be looking for this Transformation:

miosTStatSetpointHeatCommand.map

You already have that in your list, so the only thing I can think of is that the Transformations haven’t been placed in the correct directory (or a file/directory permissions problem). That said, I’d expect you’d also see errors with your switches if the directory perms were incorrect (as they need access to miosSwitch{In|Out}.map)

Can you paste a copy of the Item declaration?

jpete7683 · October 11, 2016, 7:03pm

I found the error in my ways… File name changed in transformations and need to update my items to reflect the correct file names.

jpete7683 · October 11, 2016, 7:58pm

I am having issues with homekit and setting the mode on my thermostat. I resolved setting the SetPoint since I use UI7 and they deprecated the Setpoint_Cool and Heat and just use SetPoint and that is now working, but for some reason the modes will not change. I have the modes correctly mapped but that isn’t working. Any thoughts?

guessed · October 12, 2016, 3:28pm

I found the error in my ways… File name changed in transformations and need to update my items to reflect the correct file names.

I don’t remember renaming the file in the move to openHAB 2.x compat. Is there something I need to correct at my end for this to be right?

guessed · October 12, 2016, 3:30pm

If you can provide me with the JSON snippet for UI7, along with the changed (UI7) HVAC definitions, I can probably make the generator spit out the correct logic (along with including the correct MAP Transforms to handle the incompatibility UI7 Introduced.

jpete7683 · October 12, 2016, 4:44pm

I was one of the original testers on OH1 so I may have just had out of date stuff. I just had to change in my items file what the mapping file was that it pointed to. Your documentation is correct, but it was just a simple oversight.

jpete7683 · October 12, 2016, 4:45pm

Here is the link to the HVAC changes for UI7. Any idea why I can’t get homekit to work with setting the mode? I can do it through the regular app so it obviously isn’t something in the mios binding code but just wanted to know if you had any ideas.

http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions#TemperatureSetpoint1

jpete7683 · October 13, 2016, 4:13pm

Also the homekit slider for temperature set displays whole numbers but passes decimal based numbers. The normal openhab iOS stepper only does whole numbers and the same with the Vera app… Is there a way to make the mios binding round down or up what value they are passed to the nearest whole number?

guessed · October 13, 2016, 4:31pm

I just had to change in my items file what the mapping file was that it pointed to. Your documentation is correct, but it was just a simple oversight.

ok, that makes sense. It sounds like your Items file has explicit settings to the (named) MAP files. In the early versions, that was required. After the initial feedback I added a bunch of internal defaults so you rarely need to spec the MAP files in the Item declarations.

If you post your definitions, I’ll take a stab at a cleanup of them.

Here is the link to the HVAC changes for UI7

Perfect, I’ll wire it up on the weekend and add to the 1.9.x version of the Binding (for OH 2.x compat)

Any idea why I can’t get homekit to work with setting the mode? I can do it through the regular app so it obviously isn’t something in the mios binding code but just wanted to know if you had any ideas.

I’d have to see your Items and rules (etc).

The way the current MiOS Item Generator mappings work, they’d only handle UI5-style TStats. The UI7 ones have the new interface you’ve listed, so they’ll need a new mapping to handle the interactions correctly.

That said, the mapping can be worked out, and inlined, without needing a new binding rev (I’ll do that anyhow, but it won’t block you from using the defn, once we work it out)

It’ll end up looking something like (not-validated):

Number   ThermostatUpstairsCurrentSetpoint "Setpoint [%.1f °F]" <temperature> (GThermostatUpstairs)
  {mios="unit:house,device:335/service/urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint,command:MAP(miosTStatSetpointCommand.map)"}

Where miosTStatSetpointCommand.map needs to be created. It’ll look something like:

_defaultCommand=urn:upnp-org:serviceId:TemperatureSetpoint1/SetCurrentSetpoint(NewCurrentSetpoint=??)

It usually takes a little fiddling to get these right, by looking at the Vera logs when the requests are made against it, in order to see where they’re going astray. In the past, it was simple things like upper/lowercase variable/service names since they’re all case sensitive.

If you want to post your configs, and PM me your logs, I can look over them to see what’s going wrong.

guessed · October 16, 2016, 8:25pm

I’m not familiar with the HomeKit functions, but reading the doc it looks like they rely upon both an annotation/tag, and some core config.

I’d take a stab in the dark that some of these configs aren’t set correctly in your homekit.cfg, or aren’t aligned with the values that MiOS is expecting to receive.

Here are the example values from the homekit doc:

org.openhab.homekit:thermostatCoolMode=CoolOn
org.openhab.homekit:thermostatHeatMode=HeatOn
org.openhab.homekit:thermostatAutoMode=Auto
org.openhab.homekit:thermostatOffMode=Off

Can you publish how yours are set? The defaults here look correct, if they’re set in your env, with the exception of Auto (AutoChangeOver in MiOS)

You should be able to see the values being requested of the MiOS Binding by looking at the openHAB event.log file. if that fails, something similar in either the openhab.log or the MiOS /var/log/cmh/LuaUPnP.log file

One of these will print the values being passed through, and you’ll be able to determine what’s amiss.

guessed · October 16, 2016, 8:26pm

ok, I’ve sent you a regenerated Items file, using some new rules that I’ve put into the MiOS Item Generator to handle MiOS UI7. Let me know how they go. If they’re better, I’ll add them permanently via a PR into 1.9

jpete7683 · October 16, 2016, 10:35pm

I will have to look into creating the homekit.cfg, as up to this point I have just set these values in the PaperUI and can’t find any configuration file on disk that corresponds. I am guessing that it is stored directly in one of the persistence storages. I will attempt to make the cfg to see if there is any difference. From the logging I am not even seeing an event come in from homekit when dealing with the modes, starting to wonder if there is a bug on that binding as I see trace logs for the specific temp changes. Additionally, can we add logic to the MIOS binding so that it rounds temp degrees as the slider in homekit isn’t accurate as it doesn’t show decimal places and I end up with odd setpoint values and can never get back to a whole number.

guessed · October 17, 2016, 3:20pm

You should be able to achieve this in a rule. Did that not work?

jpete7683 · October 17, 2016, 3:42pm

I never attempted to approach this from a rule perspective as the default behavior or OH1 and iOS OH was always to increment by whole numbers, never allowing decimal changes, unless something was defaulted in the stepper that I previously setup but was unaware. It seems to me that most people would rather got to the next whole number instead of decimal places. Just looking for common functionality across clients and for the binding to enforce that but if a rule is the best approach I will go down that path.

guessed · October 18, 2016, 3:49pm

By doing it as a rule, you’ll be operating on values common to all things attached to the openHAB event-bus, and everyone will see consistent values.

If it’s done at/in a particular binding, there’s a good likelihood that only the Device (on the other side of the Binding) will see the revised value, and things may get out of sync.

On a side-note, there are MiOS Plugins supporting Temp values with decimal precision. I don’t want to arbitrarily restrict that (it’s a topic that used to get heated on the MiOS forum, as they clamp ZWave tstats to whole values only)

jpete7683 · October 18, 2016, 4:00pm

Thanks for the reply and I was just wanting to get your point of view on it. I am not objected by any means to doing it via a rule and will proceed to implement it in that fashion. Just for your information I have been dabbling in OH2 and wrote a binding for Roku to get my feet wet. Have you begun the OH2 binding for this? If not I would love to take a stab but didn’t want to duplicate effort if you had already begun. I think the auto discovery of things could really bring Vera users to this as it will make it easier for them to build their system. Would love to assist in any way so just let me know.

watou · October 18, 2016, 4:20pm

Just to add to what @jpete7683 said, Things and Channels map kind of nicely to Vera Devices and variables, so Thing Types could be built dynamically based on the massive JSON dump from Vera. It’s probably a fair bit of work, and for a dwindling population of potential users, but it would be a fun exercise if time is on your side.

jpete7683 · October 18, 2016, 4:42pm

I am in 100% agreement with @watou on things and channels and would be willing to assist if not lead that effort, my only problem at this point is I haven’t looked at the code of the current binding and if we wanted to make something that was backwards compatible I would probably not be the best person to lead this project. However, if we were making a OH2 specific binding for MIOS that isn’t backwards compatible I would love to take a stab at the discovery part of it. One thing in question is that I believe the use of HTTP Long-Polling is required now for the OH1 binding, is that still an option for the OH2 framework and is there plans of removing that functionality from OH2? I thought I had read somewhere that it isn’t recommended and maybe hinted that it would be going away.

guessed · October 19, 2016, 3:55pm

Nope. I have a list of things I’d need to do write before I use openHAB 2.0, and time is very tight these days to do that. Instead, my focus is on data collection/analysis - and far less on which engine(s) are running the system.

If you want to write a Vera Binding for OH 2.0, absolutely you should go for it.

It’ll likely be structured differently, since it would need to merge the info (ServiceID’s, Types) from the Item Generator and the parts of the connectivity from the MiOS 1.x Binding itself. The latter will have some components that could be reused, but I’d imagine it’d mostly be a rewrite.

LP is the MiOS communication method, and also for a number of other devices, so I doubt that’s going away anytime soon. I wouldn’t worry about that.

MIOS Binding Thermostat

Here is my logging: openhab> log:list Logger | Level

Here is my logging:
openhab> log:list
Logger | Level