MikeK

Great information, thank you!

Thanks for posting your experience! What was it about the Touch that made it the go-to for you?

Isn't this exactly what the non-touch Halo remotes do? And the SR series, for that matter?

Not sure what you mean exactly about "hav[ing] the navigation pad operate in two different ways". That's exactly the situation today if you switch between those two remotes, and you're quite right, it's confusing.

Exactly. I think, given the cost of the Touch remote in particular, it will be unrealistic for many people to put one in every room. But you might want one in a main zone while you could have a regular Halo in a less-used zone. If they behave totally differently, that's an impediment. Such a shame, because to look at them, they have been designed in such a way as to readily transfer a user's habits from one to another, given how the button layouts on the Touch follow the ones on the non-touch Halo. Perhaps we'll hear some news at CEDIA. I hope Control4 will get this feedback a lot at the show.

Appreciate that feedback. I saw a YouTube video on the Techthusiasm channel where he demoed the remote, and this was the first thing that struck me as well. It seems like it will turn a lot of one-hand, no-look operations into two-hand, eyes-down operations. For example, with my SR-250, I know that if I want to select a particular source, I can click the Watch button (by feel), then down three times and select. I believe the non-touch Halo can do the same. I really hope they change that behavior on the Touch.

Ah! Thanks, I had seen mention of that, but Yatun has a message on their site saying that they no longer support drivers, and that they had sold off the popular ones. I wasn't able to find that one before. Seems to require a login to download it. I will see if I can get it, though!

Yeah, I was just trying to understand how it works exactly, since I don't have a Halo yet. (Trying to decide between touch and non-touch...) I can certainly (and do) use my phone or especially my watch for this purpose today. I also have a HomePod (original big one) in my kitchen, and I really like the ease of just speaking to the room and having it respond. I also like how the Siri stuff is smart enough to resolve ambiguity by assuming you meant to do something in that room (e.g. "lights off" turns off the lights in that room). I will probably eventually put a HomePod in each of my main rooms. I would have done so already, but I'm not that impressed with the HomePod Mini, so I'm hoping for a new version that's closer to the original in terms of fidelity. Thanks for the information!

All of that makes perfect sense. I'm familiar with how the existing HomeKit integration works (although your excellent summary is appreciated!) -- I've been using the Varietas driver for awhile for HomeKit integration at home, and I'm currently trying out the one from Finite Labs to see if it's worth switching. The one thing I'm not sure I understand is you said, "(when targeting Apple TV)". Does that mean that you have to have the Apple TV selected as your current source in that room? Or is there a way to tell the Halo to always send commands to a specific Apple TV, even if the room is "off"?

That would be excellent. I haven't found a way to do that but perhaps someone knows?

Thanks, Alan. Would be a handy feature.

Yeah, thanks, that's the one I mentioned earlier. As far as I can tell from its documentation, it will let you assemble strings by formatting the contents of other variables, but it doesn't have an ability to truncate or compare a substring.

I'm not sure if I understood this comment correctly. Do you mean that if you have a HomeKit driver set up that it's possible to use the voice command button on the remote to route commands to Siri that way?

Ah! I just discovered that the newer driver for this lock (the one with the Locked Proxy event) has a similar status variable, but it does not tack the date/time onto the end. It seems to provide distinct messages for all three lock events: Manually Locked Keypad Locked by Keypad Command Locked This may be good enough. I'm still interested to know if there's a way to compare against a substring, though, because it would save me a little work to not have to replace the drivers for each of these locks.

Thanks for your reply! Unfortunately, there doesn't seem to be a way to use the events from the driver I'm using to get what I want. On this driver (which is for the Baldwin Zigbee lock that Control4 used to re-sell), there are two lock events: "Locked" and "Locked Manually". Locked fires whenever the lock is locked using the motor. So this means that it is triggered if you press the button on the exterior keypad, or if you send it a command by ZigBee. Locked Manually fires if you lock the lock with the knob or the key. I want to have programming run only when the lock is locked from the exterior keypad (because that means that I'm leaving the house and I want to have lights and TVs turn off, etc.) There's a newer version of the lock driver that has a "Locked Proxy" event like the one you've shown for the August. That means that it was locked by programming. Unfortunately, that driver treats the keypad locking and the knob/key locking equivalently. They're both called "Locked Manually". So, both versions of the driver combine "locked with the keypad" with one of the other methods, making it impossible to use the events to distinguish. What I discovered, though, is that the status message that the older driver puts into that variable is unique for proxy, keypad, and knob/key, so if I can just parse that string, I can fully distinguish. But since it tacks the stupid date/time on there, I can't use a string comparison.