Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
HomeKit Essentials Worth Checking Out
- Thread starter MacRumors
- Start date
- Sort by reaction score
I have the Abode system - that's really the best system that combines a stand-alone security system and one that integrates with HomeKit
If you want a dead simple version of this for Nest products only, the Starling Nest HomeBridge enables Nest products to interact with HomeKit flawlessly.
Starling - Nest HomeKit Integration
The most annoying ones are those related to light and presence.
I have hiome detectors in a few rooms to detect presence, and they work pretty well, I can't really complain about them.
Then there are rules that do things like
- when a room goes empty start a 3-minute timer. When that timer fires, dim the lights to 50%
- when a room goes non-empty, put the lights back to 100% (and cancel the timer if it was running... 😀 )
It's pathetic the hoops you have to go through to create such a simple routine (multiple automations, use of Homebridge, ...) but that's not the point here.
The point is that this is a very obvious failure point because rooms are entered and exited dozens of times a day. When aTV is running the show, this basically works like it should -- you leave a room, it stays bright and it's bright if you return after a short exit; if you leave for longer it dims to 50%, and reverts to bright as soon as you walk through the door. It works, response is fast enough (I'd like it to be a few ms faster, but it's good enough), and it fails maybe once a month (easily fixed by just leaving and returning through the door).
With HomePod in charge it's a disaster; every third or fourth walk through a door the lights just don't go on, or take 30 seconds or more to finally switch on. Why the difference? No clue. But, like you said, Apple provides us with ZERO tools to solve these issues (and, BTW, to help THEM create a better product).
There also appear to be constant lingering bugs in so much of Automation functionality. For example you're supposed to be able to chain together OR functionality (any trigger can fire an automation) along with AND functionality (all conditions have to hold). The AND functionality works, but in my experience the OR functionality is useless -- I have never once got a non-trivial automation with two trigger clauses to fire (neither of the triggers ever worked).
The new HomeKit team under Andreas Gal is supposed to be trying to fix everything. But they've been saying that since October 2019, and I didn't see any great improvement with the 2020 suite of OS releases... The ONLY significant change I've seen is the Thread related stuff, and while I appreciate that re-architecting the system takes time, they seem utterly uninterested in even trivial improvements and fixes (like being able to lock to a particular homekit hub, or logging functionality).
My hope is that once Apple Silicon is settled down, we'll get *full* HomeKit functionality on macOS, including a set of powerAPIs that can be used to create something like a HomeKit Studio serious automation environment + home control hub. But that could be three or four years from now.
I definitely was in a few meetings with Peter G, but had nothing much to say. I guess the fruits of that effort would have been Quartz Extreme which came out soon after I left.If it was very early, then Steve Perlman would have been one of the people (I know there were others, but I am old now and cannot remember who else from that period).At the end it would have been Frank C, and some of those who were involved with the standardization efforts.
So you left before Peter G took over all the graphics stuff, and were not involved in the rewrite for macOS X then?
Mostly I worked on PPC stuff; I came in at the start of the PPC era and left at the start of the OSX era. My main project throughout that time was MPEG (first the baseline code, then MPEG2, then DVD player, then MPEG4 and 264). But I also did the optimization of a bunch of codecs, from Sorenson when I first started through JPEG2K, AAC, a lot of blitters, ...
Everybody on the team was very smart, but we all knew different things. I was more comfortable than most with the math details of the codecs, and with PPC assembly (and general concepts of what was fast in modern superscalar OoO CPUs) so I tended to be the optimization guy.
How did you EASILY enroll devices on only the 2.4GHz network?
Amplifi doesn't seem to offer a way to switch off the 5GHz network. So my choices are
- rename the 5GHz network temporarily then name it back (hassle)
- connect the iphone to the 2.4GHz SSID and connect to Meross (seems like it would work, but it doesn't. At some point the phone seems to want to connect to the Meross plug and back to the network, and during those transitions it reconnects to the 5GHz network)
- tell the phone to forget the 5GHz network (and then I have to re-enroll it with the 5GHz network)
These all strike me as an intolerable level of ******** to have imposed on me by a company that's too incompetent to do what plenty of other 2.4GHz only companies have done just fine. Meross' real problem seems to be this intermediate stage where they insist on some sort of weird dance between the initial WiFi network, then a phone-to-meross-plug network, then the phone goes back to the main WiFi network then back to the phone-to-meross-plug network. It's fragile and god knows why it's necessary. Every sane device has a BT connection (you pick it up for free on the chipset!) to handle precisely this small amount of setup back and forth so that the phone can tell the device the WiFi credentials.
So point is what you care about is not just the dimmer functionality, but the round knob to turn?
Yeah, that I can't help with. I don't know anyone who makes something like that.
With anything that involves networking code written by non-networking focused companies, one must always begin with a chicken.
- Start by waving the chicken around, head down three times clockwise around the device.
- Then three times head up, counter-clockwise around the access point.
- Next create a separate SSID just for the IoT devices and name it something like:
- IoT-2.4GHz-Net.
- Make it 2.4GHz only. (Does Amplifi support multiple, independent SSIDs?)
- For more security it can be on a separate VLAN (there is some routing that is needed, I can send you examples if you want).
- Now, have your iOS device join that SSID.
- Finally, use your device to attach the new IoT device to the IoT SSID.
That is a cleaner and simpler way of doing the configuration, but it is still nice to have a separate IoT SSID.
Got it. He is a great guy. Very smart and super nice.
Cool. I think that team in conjunction with the Jony Soruji’s team is responsible for the hardware assisted H.265 codec for Apple Silicon.
Wow that looks sick thank you for the share. Any idea if there’s something like this for Canada?
The other annoyance I have with my Nest cams is that in Canada they’re limited to 2.4GHz even though they come with the 5GHz hardware. Super weird
You are missing an essential point, one I described in my post.
IF the above is ALL you do, then your phone will, preferentially, when there is an occasion to *re-attach* to the home network, attach to the 5GHz SSID. That is what I was describing as the Meross nonsense as the app constantly renegotiates different connections with different wifi networks.
That is why I said that if you want to enroll a Meross device it is not enough to have a named 2.4GHz SSID and to connect the phone to it. You also have to (somehow) remove the possibility of the phone ever being able to connect to the 5GHz SSID until the Meross enrollment is over (and every time you want to update firmware).
Like I said, fsck that! Garbage product.
Honestly who knows? My guess would be that Apple negotiated the base cell from some company that specializes in cells for video codecs, but then over time has modified it to suit their needs.
Really the only real involvement with the QT team that makes sense is negotiating the functionality/API of the driver that's sitting between QT and the HW -- that's the point where the speciality's of the two teams have to meet...
I run Home Assistant on Debian 10 Stretch in a Docker container which controls a zwave lock using an Aeotech Gen 5 USB zwave controller and the Homekit integration, which exposes the lock controls and status to Homekit so I can use Siri. This is running on a Lenovo Thinkpad X220 sitting in my server rack docked in an Ultrabase and wired to my network. I also use this to control a Sonos Speaker.
I also run Homebridge on a Raspberry Pi 1.2 B+ which runs my Nest stuff (Doorbell, Smoke Detectors, Nest Protect) and MyQ for my Liftmaster Garage Door opener. This is also wired to my network. All my lights are Phillips Hue or a Phillips hue switch or Lutron with Homekit.
I probably could run everything on the Raspberry Pi with Home Assistant, but I struggled to get secure network working for adding my zwave lock, so I went the double device route to keep the really stable devices controlled by their own device. It's been fun to toy with Homebridge and Home Assistant.
I also run Homebridge on a Raspberry Pi 1.2 B+ which runs my Nest stuff (Doorbell, Smoke Detectors, Nest Protect) and MyQ for my Liftmaster Garage Door opener. This is also wired to my network. All my lights are Phillips Hue or a Phillips hue switch or Lutron with Homekit.
I probably could run everything on the Raspberry Pi with Home Assistant, but I struggled to get secure network working for adding my zwave lock, so I went the double device route to keep the really stable devices controlled by their own device. It's been fun to toy with Homebridge and Home Assistant.