I’m starting a new topic for this as I can’t find one that already covers it.
TAGGING is used for both the homekit and the google home integration and while the principle of giving a light or outlet a tag Lighting or Switchable to tell Google and Apple it’s a light or switch.
The problem I’m experiencing is that the tagging rules for homekit and google home are beginning to be non compatible as people start optimizing these.
The conflict works the other way around as well, simple temperature measurements show up in google home as a thermostat, which doesn’t make sense. In order to visually make them look like a temperature without being able to change/set value the work around is to define them as thermostat and put the mode to off.
This makes temperatures show up as thermostats in the Home app which isn’t the purpose.
So the question is: Shoudn’t we start thinking about different tags for google and homekit something like [“Google:Lighting”,“Homekit:Lighting”] so each binding can pick up its own tags and each binding can optimize tag usage depending on how it’s supported in google home and Homekit?
@MARZIMA what do you think as you actively maintain the google home binding but probably without taking into account homekit constraints?
@ranielsen not really because that would only work if all extrnal connection have similar support.
Take rollershutter for example, which might be supported by Homekit at some point in time and not by google home. A consistent naming convention would give the same issue as currently trying to use the same tag for every external binding.
Another option would be to have a cfg file for each binding, so removing the tags from the item files and having a googlehome.cfg file and a homekit.cfg file that defines what itels are linked and how they are linked depending on binding functionality
Rob, not really homekit understands Currenthumidity but as a stand alone value (similar to current temperature without thermostat context). In Google home Humidity is considered to be a thermostat value (next to the mode current temperature and target temperature) so you need to put it in the thermostat group.
A stand alone humidity value is understood by Homekit but not by google home, a thermostat humidity is understood by google home but not homekit.
This is only one example but you can clearly see how rollershutters, audio, tv commands etc could be supported differently by different Assistant systems. So the idea of one TAG for all integrations is not sustainable.
Each integration has its own implementation, so it is hard to use 1 set of tags.
The [ “homekit:HeatingCoolingMode” ] is already a Home-kit special tag, but is also used for Google Assistant and Amazon Alexa.
In my opinion, it is good to have tags for each integration.
I think seperate tags will give more flexibility easy to understand and sustainable.
The idea of generic ones for items supported by all in principle is nice but
you might want to expose a Switchable to Homekit and not to google home (a generic switchable tag wouldn’t give you this option, a specific one for each binding would)
today certain itels might have the same structure for all and a generic tag will work till a syntax change is introduced and it will break everything (see humidity or stand alone temp example).
I really think having specific tags for each binding will be the best long term solution
What would be the appropriate way,to;progress this, making a request in the github of each of the bindings or is this something that strategically is decided on OH architecture level and the. Pushed downwards as “guideline” ?
Not a developer myself, hence the question
