Basically the select entity already exists right now. Instead of adding the entities directly in an automation, you ‘call a service’ and you choose the select.select service, point it to the select.harmony_hub_wohnzimmer entity and then under ‘options’ you have to fill out the name of the activity you want. I can tell you that power_off is the generic harmony power off option you want but the OTHER options, which are definitely case specific, are found in either the drop down list in the device integration itself, or you can find them using ‘developer tools’ to look and test the state for that entity. Based on your screenshot, I’m assuming that maybe it’s going to be Smart TV, Fernseher and Computer
Yeah, not super intuitive.
Now then, if you want to present this to homekit the same way you have been, which is what I want to do for google home, you will ADDITIONALLY need to create a helper that’s just a toggle switch, and then create an automation so that when the toggle is on, it turns on one thing and when it’s off it does that power_off that I mentioned.
You should then be able to present that entity to home kit with a name you like and it’ll treat it just like ‘on/off’ from before. What a pain though, eh?
edit: to clarify, the current switch entities are going away, so when you upgrade to 2024.6, your current automations with them will break. You can’t present the new select entity to homekit directly, you have to create an automation that will leverage it and then come up with a way to present THAT to homekit.
Hey, yes this really is a joke, then I got it right. Looks like they want to move away from switch, but no explanation far and wide. Would at least understand if they would update the addon and change switches to input.select. But like you wrote, we’re all just making unnecessary automations and helpers.
I’ve just seen that I can also add automations in Homekit.
Your assumption of my activities was correct, try creating automations now and get back to me.
If you rename the entity_id’s of the deprecated switches, and disable them, you can even use the existing entity_id’s for the new template switches. Barely 10 minutes work, and no need to change any existing scripts or automations.
@reste_narquois, that sounds like the solution we were looking for. I had it in my head somehow, but then couldn’t put it into words either. Your example was super super helpful, I’ve now changed it, THANK YOU SO MUCH!
As already mentioned, I’m very happy with the current solution, because so far we’ve only been told that they’re banning switches from the Logitech application, but somehow it sounds so far into the future that I’m afraid they’ll take the switches out of HA altogether and replace them with Input Select - Home Assistant. Or am I talking nonsense? Or am I perhaps talking rubbish? In any case, it doesn’t make it any easier and a little more complicated in my head. Or has someone already started to change it cleanly. Then you would rather think in scenes and automations - crazy.
To be blunt, yes. This change simply concerns the Harmony integration only, and its rationale was about reducing its complexity. You may disagree with that rationale of course, but this does not presage a removal of switches from HA - that would be absurd frankly.
Incidentally, for those with long memories, the Harmony integration never had these switches at all, and the remote was the only entity it created. You always had to create your own template switches.
Then the switches were added, then finally the select entity, which is a relative newcomer to the overall HA architecture.
If I understand correctly, this is in part about making the integration report the chosen activity to HA much more immediately - in earlier versions of the integration there was always a bit of a lag as it waited for the activity to fully finish loading. This could lead to uninitiated users (by which I mean other members of my family!) unnecessarily repeatedly pressing buttons because nothing seemed to be happening, causing general meltdowns to both tech and users.
Can you tell me where you got the specific information about the reasoning for the change in the integration so that I know where to find that sort of thing in the future?
You can see it actually lay dormant for a while. And that opposing arguments were also made. The line seems to be that with the addition of the select entity, there were now effectively 3 ways to do the same thing, adding redundancy.
I personally liked the switches, but was happy enough to reactivate the template switches that I had before as a workaround. As long as there is some kind of solution, I’m trying to hold on to the attitude that life’s too short to get really worked up about this sort of thing!
Also trying to adopt that approach especially as it’s opensource and we are lucky to have it however as it is leading to creation of extra helpers. automations and/or yaml; it is really rather annoying!
Ah, thanks, okay, I’m relatively new to github as a whole, so looking at comments around specific pull requests is a place that it didn’t occur to me to check. Thanks very much!
So, if I want to keep the convenience of asking Google Assistant to “turn on” “my activity”, I have to create a template switch in Yaml… Very convenient indeed. I think Home Assistant has a long way before it can be used by the layman
I am afraid that I still not not quite understand what to do until the mid of 2024. I use the “switch” to retrieve the state of the remote. For example, if I watch TV, use a stick, or play the XBox, I want the Harmony Hub to switch the volume up and down every :05 minutes after the hour, because otherwise the TV automatically switches off (no joke, this is supposed to be a feature).
Therefore, I provided the following automation:
alias: Reactivate TV every hour
description: Shortly sets volume down and up five minutes after every full hour
trigger:
- platform: time_pattern
minutes: "5"
condition:
- condition: or
conditions:
- condition: device
type: is_on
device_id: 5c592c0bcb78097b0a5e662e5b6763b4
entity_id: switch.harmony_hub_2_watchtv
domain: switch
- condition: device
type: is_on
device_id: 5c592c0bcb78097b0a5e662e5b6763b4
entity_id: switch.harmony_hub_2_xbox_play
domain: switch
- condition: device
type: is_on
device_id: 5c592c0bcb78097b0a5e662e5b6763b4
entity_id: switch.harmony_hub_2_fire_tv_watch
domain: switch
- condition: device
type: is_on
device_id: 5c592c0bcb78097b0a5e662e5b6763b4
entity_id: switch.harmony_hub_2_television_only_tv
domain: switch
action:
- service: remote.send_command
data:
delay_secs: 0.6
device: "68048731"
command:
- VolumeDown
- VolumeUp
mode: single
How would I be supposed to change this? To me, this is not clear from the earlier posts in this thread. Thank you in advance.
Currently I use Google Home and/or HomeKit to turn the various Harmony Hub scenes on for different TV inputs (AppleTV, Chromecast etc). I’ve created the new Template switches, and they seem to work but they don’t have the full functionality of the built-in switches.
If I turn the AppleTV on, it will turn on the TV, AppleTV and Receiver, and set them to the appropriate inputs. If I then turn on the Chromecast, the Harmony Hub will only change the inputs (knowing that I still need the TV and Receiver on), but it will also turn off the AppleTV switch.
With my new Template switches, I can turn on the AppleTV, then the ChromeCast, but if I then try to turn on the AppleTV again, either immediately or after turning off the Chromecast, this won’t work as Home Assistant thinks the AppleTV is already on (or at least it seems inconsistent when it will or won’t work in this situation). Is there a way to mimic the existing switch behaviour?
I also have a Broadlink RM4 device that suffers the same problem so it would be good to have a generic solution that allows only one switch from a group to be on at a time without the off routine of other switch(s) also firing when they’re turned off.
If I turn one on and then a second, this will leave the first switch on. With the built in Harmony Hub integration switches, the first switch would have been turned off.
There’s also a slight difference in the appearance of the switch in the Home Assistant interface. These switches look like this with two sections.
Where as other non-template (?) switches look like this; more of a slider.
This seems to only be a visual thing though, not functional, so I’m not particularly concerned, it just seemed strange to have two different ways of presenting a two position switch.
You need to add a value_template key so that the switch reports its state to Home Assistant. Otherwise, the switch state defaults to optimistic, which usually means it stays on after it is switched on, unless directly switched off. The absence of this key also explains why it looks different in the frontend.
