switched from homekit to ESH ontology #946
Conversation
Signed-off-by: Kai Kreuzer <kai@openhab.org>
|
@beowulfe @digitaldan: Since I want to publish a beta3 this weekend and more people will go and use the HomeKit and Alexa integration, I wanted to get rid off the homekit prefix before that, before it get's too established among openHAB users. I didn't yet manage to define (and document) an ontology for ESH, but I tried my best to come up with terms that I'll likely use for the functionality in question. So any tag without a prefix is automatically considered to be referencing the ESH ontology; the only remaining "homekit:" one is for the thermostat mode. I have updated the code as well as the documentation, so this is just FYI (and I hope you approve my changes). |
|
@kaikreuzer are these any notes or discussions on the future use of these ESH ontologies? Is it worth other developers updating their bindings to add these tags in? |
|
You should follow eclipse-archived/smarthome#1093 for more info - at the moment it is imho too early for developers to update the bindings. |
| </tr> | ||
| <tr> | ||
| <td> </td> | ||
| <td>heatingCoolingMode</td> | ||
| <td>homekit:HeatingCoolingMode</td> |
There was a problem hiding this comment.
Actually I don't think this is homekit specific, Amazon uses the same format so I believe this will be important going forward. We are currently depending on this for the Alexa integration.
There was a problem hiding this comment.
@kaikreuzer will also add that the homekit binding has some properties that have to be set as config options, like
org.openhab.homekit:useFahrenheitTemperature=true
org.openhab.homekit:thermostatCoolMode=CoolOn
org.openhab.homekit:thermostatHeatMode=HeatOn
org.openhab.homekit:thermostatAutoMode=Auto
org.openhab.homekit:thermostatOffMode=Off
The temperature format is very important to other integrations, I would propose this be moved to a tag that can be set on the "Thermostat" . The heating modes would also be nice to be able to set not through a specific binding.
There was a problem hiding this comment.
Actually I don't think this is homekit specific
Right, but I am not yet at all clear on how I will model this exactly in the ontology (incl. naming). And since it is then anyhow likely to change again in future, I preferred to keep it here for the moment.
There was a problem hiding this comment.
The temperature format is very important to other integrations
You mean the unit? This will be addressed by eclipse-archived/smarthome#601.
There was a problem hiding this comment.
You mean the unit? This will be addressed by eclipse-archived/smarthome#601.
Hopefully that work will get revived soon.
Right, but I am not yet at all clear on how I will model this exactly in the ontology (incl. naming). And since it is then anyhow likely to change again in future, I preferred to keep it here for the moment.
No problem. Just for reference, the Alexa api has 'temperatureMode' which can be ' AUTO, COOL, HEAT' . It seems this is a common pattern.
Signed-off-by: Kai Kreuzer <kai@openhab.org>
|
@kaikreuzer - I'm working on adding support for WindowCoverings and GarageDoors, with Locks and Fans soon to follow. Any thoughts on including these in the ontology? For Homekit, the characteristics of a WindowCovering we'd be interested in are: GarageDoor supports a value of: Open, Closed, Opening, Closing, Stopped. You can only write Open or Closed. I think I'll need to use a String here, which repeats the weirdness of heatingCoolingMode. Lock supports a value of: Unsecured, Secured, Jammed, Unknown. You can only write Unsecured or Secured. Same issue as GarageDoor. Fan has: |
|
Hi @beowulfe, I would suggest that you add a comment about these requirements at eclipse-archived/smarthome#1093. We can then discuss how to appropriately address them. |
Signed-off-by: Kai Kreuzer <kai@openhab.org>
Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
Signed-off-by: Kai Kreuzer kai@openhab.org