Apple Homepod mini
-
Also one upside to HomeKit for MyQ users (like myself) they have a official plugin for Homekit and you can use that integration with some virtual switches to gain control of your garages in your Vera since the plugin no longer works. Since its an official plugin it will always (hopefully) work unlike the unofficial plugins we have used in the past.
Also Homekit geofencing is rock solid btw
-
Thanks guys. It makes a lot of sense when moving from a polling based methodology to an event base for geofencing... It is both more efficient and more reliable. I may test this in parallel with iPhoneLocator to see if it increases reliability. I think I will still need iPhoneLocator for its distance measurement capability which I am using as trigger for other things. It makes @ronluna's plugin to bridge in HomeKit devices to openLuup even more enticing. I note also that my locks and garage doors can't be open by the homepods due to security and require a phone unlock step for siri to open them.
My final count is 3 Homepod Mini's + 1 iPad replacing 18 echo devices. $550 cost replacing >$1200 of amazon devices. The rest is reuse of devices I used for other things. I am thrilled! -
Also one upside to HomeKit for MyQ users (like myself) they have a official plugin for Homekit and you can use that integration with some virtual switches to gain control of your garages in your Vera since the plugin no longer works. Since its an official plugin it will always (hopefully) work unlike the unofficial plugins we have used in the past.
Also Homekit geofencing is rock solid btw
Just upgraded my watch from a watch3 to the latest watch6 and can confirm that the watch6 processes the voice locally unlike the watch3: When a command is sent it responds immediately that it "got it" and sent the command but unlike using an iOS, MacOS device or the homepod, the action itself has a little latency which I suspect is due to the need for the command to go in the cloud and come back to the home hub to be executed. By contrast the watch3 has an additional delay just to understand the voice command.
Summary of my testing results below:
-
OK, I’m enthused to try Siri, using my new iPad Pro, which I understand should give me near instant response and do all its processing locally.
I have:
- openLuup (obviously) now running in an Alpine Docker,
- oznu/Homebridge also running on Docker, ...
- ...absolutely no understanding of what to do next.
Homebridge finds my two Philips Hue bridges, but how to link openLuup devices to it? I’ve trawled some rather old Vera plug-in posts and various GitHub repositories, but still none the wiser.
Help needed, and welcomed!
(PS: I’ve looked also at the @ronluna plug-in, but that seems to go in the other direction?)
-
OK, I’m enthused to try Siri, using my new iPad Pro, which I understand should give me near instant response and do all its processing locally.
I have:
- openLuup (obviously) now running in an Alpine Docker,
- oznu/Homebridge also running on Docker, ...
- ...absolutely no understanding of what to do next.
Homebridge finds my two Philips Hue bridges, but how to link openLuup devices to it? I’ve trawled some rather old Vera plug-in posts and various GitHub repositories, but still none the wiser.
Help needed, and welcomed!
(PS: I’ve looked also at the @ronluna plug-in, but that seems to go in the other direction?)
-
Go to [Homebridge docker IP]:8581, if there is a Homebridge page you can configure it from UI. You need to install the old Vera plugin from damianxd https://github.com/damianxd/homebridge-vera and configure it, either from UI or console.
-
Go to [Homebridge docker IP]:8581, if there is a Homebridge page you can configure it from UI. You need to install the old Vera plugin from damianxd https://github.com/damianxd/homebridge-vera and configure it, either from UI or console.
@crille said in Apple Homepod mini:
You need to install the old Vera plugin from damianxd https://github.com/damianxd/homebridge-vera and configure it, either from UI or console.
Ah, that was the bit I was missing. Thanks.
-
Go to [Homebridge docker IP]:8581, if there is a Homebridge page you can configure it from UI. You need to install the old Vera plugin from damianxd https://github.com/damianxd/homebridge-vera and configure it, either from UI or console.
@crille said in Apple Homepod mini:
Go to [Homebridge docker IP]:8581, if there is a Homebridge page you can configure it from UI. You need to install the old Vera plugin from damianxd https://github.com/damianxd/homebridge-vera and configure it, either from UI or console.
Speaking of it, maybe someone wants to embark into a rewrite, because it's not really supporting every device out there...
--
On a mission to automate everything. -
@akbooer get the latest copy directly from github at https://github.com/damianxd/homebridge-vera as npm is not current/synced with the github repo. In other words, install the plugin through the homebridge plugin section and then replace all the files located at "/usr/lib/node_modules/homebridge-vera/" with the latest on github.
-
@crille said in Apple Homepod mini:
Go to [Homebridge docker IP]:8581, if there is a Homebridge page you can configure it from UI. You need to install the old Vera plugin from damianxd https://github.com/damianxd/homebridge-vera and configure it, either from UI or console.
Speaking of it, maybe someone wants to embark into a rewrite, because it's not really supporting every device out there...
@therealdb said in Apple Homepod mini:
maybe someone wants to embark into a rewrite, because it's not really supporting every device out there...
...actually, I see now that there is an Homebridge/MQTT bridge
npm: homebridge-mqttthing
Homebridge plugin supporting various services over MQTT. Latest version: 1.1.47, last published: a year ago. Start using homebridge-mqttthing in your project by running `npm i homebridge-mqttthing`. There are no other projects in the npm registry using homebridge-mqttthing.
-
@therealdb said in Apple Homepod mini:
maybe someone wants to embark into a rewrite, because it's not really supporting every device out there...
...actually, I see now that there is an Homebridge/MQTT bridge
npm: homebridge-mqttthing
Homebridge plugin supporting various services over MQTT. Latest version: 1.1.47, last published: a year ago. Start using homebridge-mqttthing in your project by running `npm i homebridge-mqttthing`. There are no other projects in the npm registry using homebridge-mqttthing.
Trying to be more explicit here:
The very old VeraHomeKitBridge still works great. I forked it to make it support more devices and is similar to the alexa habridge. It just doesn't need to emulate a hue hub and doesn't have all the discovery problems the amazon system has. This is kind of the (my) lazy way... It has no UI but since I am using homekit as the highest level of abstraction and control, I am only publishing the devices I want to voice control. I have been catching myself not using Homewave anymore and most of the time using the iOS Home app when I want manual actuation which is extremely rare.
GitHub - rafale77/VeraHomeKitBridge
Contribute to rafale77/VeraHomeKitBridge development by creating an account on GitHub.
Homebridge is a much better choice as it has a UI and offers bridging many other platforms through plugins. It's purpose is to publish these platforms to Homekit. Once installed, you indeed need to also install the vera bridge plugin for openLuup. Like its predecessor above, it is a one way bridge: Homekit will see, and control openLuup devices, not the other way around. There is nothing to do on openLuup.
@ronluna's plugin bridges the other way, publishing homekit devices back into openLuup and is therefore an openLuup plugin.
-
Trying to be more explicit here:
The very old VeraHomeKitBridge still works great. I forked it to make it support more devices and is similar to the alexa habridge. It just doesn't need to emulate a hue hub and doesn't have all the discovery problems the amazon system has. This is kind of the (my) lazy way... It has no UI but since I am using homekit as the highest level of abstraction and control, I am only publishing the devices I want to voice control. I have been catching myself not using Homewave anymore and most of the time using the iOS Home app when I want manual actuation which is extremely rare.
GitHub - rafale77/VeraHomeKitBridge
Contribute to rafale77/VeraHomeKitBridge development by creating an account on GitHub.
Homebridge is a much better choice as it has a UI and offers bridging many other platforms through plugins. It's purpose is to publish these platforms to Homekit. Once installed, you indeed need to also install the vera bridge plugin for openLuup. Like its predecessor above, it is a one way bridge: Homekit will see, and control openLuup devices, not the other way around. There is nothing to do on openLuup.
@ronluna's plugin bridges the other way, publishing homekit devices back into openLuup and is therefore an openLuup plugin.
@rafale77 said in Apple Homepod mini:
Once installed, you indeed need to also install the vera bridge plugin for openLuup.
Thanks for that explanation. The weak link, as far as openLuup is concerned, is the Vera bridge plugin, because it (obviously) relies on the rather inefficient Luup status request. Indeed, it uses it very inefficiently:
2021-04-06 14:46:46.215 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c8914c8f68
2021-04-06 14:46:47.204 openLuup.io.server:: HTTP:3480 connection from 172.16.42.10 tcp{client}: 0x55c892db3648
2021-04-06 14:46:47.206 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55c892db3648
2021-04-06 14:46:47.216 openLuup.server:: request completed (51616 bytes, 4 chunks, 10 ms) tcp{client}: 0x55c892db3648
2021-04-06 14:46:47.217 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c892db3648
2021-04-06 14:46:48.206 openLuup.io.server:: HTTP:3480 connection from 172.16.42.10 tcp{client}: 0x55c89288ad88
2021-04-06 14:46:48.207 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55c89288ad88
2021-04-06 14:46:48.217 openLuup.server:: request completed (51616 bytes, 4 chunks, 10 ms) tcp{client}: 0x55c89288ad88
2021-04-06 14:46:48.218 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c89288ad88
2021-04-06 14:46:49.207 openLuup.io.server:: HTTP:3480 connection from 172.16.42.10 tcp{client}: 0x55c891f01508
2021-04-06 14:46:49.208 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55c891f01508
2021-04-06 14:46:49.219 openLuup.server:: request completed (51616 bytes, 4 chunks, 10 ms) tcp{client}: 0x55c891f01508
2021-04-06 14:46:49.219 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c891f01508...it doesn't even use the syntax for incremental changes from last time, and, although it's not fatal, this increases my CPU from 0.2% to 2.7%
I've also had problems with it not coping with duplicate device names, and Homebridge has also mapped my Hue devices twice – one directly and once via openLuup. So there's a few thing to think about and work through here, from a configuration point of view.
One voice-actuated 'gotcha' I've found already is that "Hall" sounds very much like "All", but means something very different!
-
@rafale77 said in Apple Homepod mini:
Once installed, you indeed need to also install the vera bridge plugin for openLuup.
Thanks for that explanation. The weak link, as far as openLuup is concerned, is the Vera bridge plugin, because it (obviously) relies on the rather inefficient Luup status request. Indeed, it uses it very inefficiently:
2021-04-06 14:46:46.215 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c8914c8f68
2021-04-06 14:46:47.204 openLuup.io.server:: HTTP:3480 connection from 172.16.42.10 tcp{client}: 0x55c892db3648
2021-04-06 14:46:47.206 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55c892db3648
2021-04-06 14:46:47.216 openLuup.server:: request completed (51616 bytes, 4 chunks, 10 ms) tcp{client}: 0x55c892db3648
2021-04-06 14:46:47.217 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c892db3648
2021-04-06 14:46:48.206 openLuup.io.server:: HTTP:3480 connection from 172.16.42.10 tcp{client}: 0x55c89288ad88
2021-04-06 14:46:48.207 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55c89288ad88
2021-04-06 14:46:48.217 openLuup.server:: request completed (51616 bytes, 4 chunks, 10 ms) tcp{client}: 0x55c89288ad88
2021-04-06 14:46:48.218 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c89288ad88
2021-04-06 14:46:49.207 openLuup.io.server:: HTTP:3480 connection from 172.16.42.10 tcp{client}: 0x55c891f01508
2021-04-06 14:46:49.208 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55c891f01508
2021-04-06 14:46:49.219 openLuup.server:: request completed (51616 bytes, 4 chunks, 10 ms) tcp{client}: 0x55c891f01508
2021-04-06 14:46:49.219 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c891f01508...it doesn't even use the syntax for incremental changes from last time, and, although it's not fatal, this increases my CPU from 0.2% to 2.7%
I've also had problems with it not coping with duplicate device names, and Homebridge has also mapped my Hue devices twice – one directly and once via openLuup. So there's a few thing to think about and work through here, from a configuration point of view.
One voice-actuated 'gotcha' I've found already is that "Hall" sounds very much like "All", but means something very different!
@akbooer said in Apple Homepod mini:
...it doesn't even use the syntax for incremental changes from last time, and, although it's not fatal, this increases my CPU from 0.2% to 2.7%
Interesting... I have not tested homebridge myself but don't seem to have this problem with my older version of the bridge.
I've also had problems with it not coping with duplicate device names, and Homebridge has also mapped my Hue devices twice – one directly and once via openLuup. So there's a few thing to think about and work through here, from a configuration point of view.
Yes... this where one needs to make choices. I have the same problem and decided to not bridge my hue devices through openLuup.
One voice-actuated 'gotcha' I've found already is that "Hall" sounds very much like "All", but means something very different!
I never had this problem even with my French accent (we tend to forget to pronounce the "h" because this letter is mute in french). Maybe use "hallway"? -
@akbooer said in Apple Homepod mini:
...it doesn't even use the syntax for incremental changes from last time, and, although it's not fatal, this increases my CPU from 0.2% to 2.7%
Interesting... I have not tested homebridge myself but don't seem to have this problem with my older version of the bridge.
I've also had problems with it not coping with duplicate device names, and Homebridge has also mapped my Hue devices twice – one directly and once via openLuup. So there's a few thing to think about and work through here, from a configuration point of view.
Yes... this where one needs to make choices. I have the same problem and decided to not bridge my hue devices through openLuup.
One voice-actuated 'gotcha' I've found already is that "Hall" sounds very much like "All", but means something very different!
I never had this problem even with my French accent (we tend to forget to pronounce the "h" because this letter is mute in french). Maybe use "hallway"? -
OK, I’m a Homebridge convert. With it running in a Docker, and using just a few Homebridge plugins (MQTT in particular, also Netatmo) and the Home app on an iPad, I can do just about everything I need. Amazingly, I now see this as a viable replacement for my beloved Zwave Minimotes (I have nine of them, strategically placed.). This means that every Zwave device I had, except for two pulse meter readers, can be replaced by Hues, Shellies, and Homebridge. Not much further need for Vera or ZWay. Of course, openLuup is still central, especially for data archiving with Historian, but UI access to it is rare.
Perhaps I do just need a HomePod Mini (or two) to complete the experience...?
-
OK, I’m a Homebridge convert. With it running in a Docker, and using just a few Homebridge plugins (MQTT in particular, also Netatmo) and the Home app on an iPad, I can do just about everything I need. Amazingly, I now see this as a viable replacement for my beloved Zwave Minimotes (I have nine of them, strategically placed.). This means that every Zwave device I had, except for two pulse meter readers, can be replaced by Hues, Shellies, and Homebridge. Not much further need for Vera or ZWay. Of course, openLuup is still central, especially for data archiving with Historian, but UI access to it is rare.
Perhaps I do just need a HomePod Mini (or two) to complete the experience...?
-
@akbooer That's right... and just like that... apple is taking over then entire home automation industry.... too bad there is no Home app for Android. Well Front end and first layer voice control related...
@ronluna said in Apple Homepod mini:
@akbooer That's right... and just like that... apple is taking over then entire home automation industry.... too bad there is no Home app for Android. Well Front end and first layer voice control related...
Not sure I would call that a takeover quite yet. Homekit is not the panacea when it comes to automation but it certainly does a lot of things better than others. It's certainly taken a long time for them to come up with a device like this. The original HomePod was just too expensive for this application. My original idea for the homekit bridge was to use an iPad as a console by the front door on which I could use siri. This was 5 years ago in my previous house. I more or less shelved Homekit until this past month seeing that thread on the hubitat forum.
I just read this for the first time today and I completely agree with the vision:
It is 5 years old and am pretty sad with the obsession of all these companies with the cloud, wanting to get our data in it. Sadly Apple is the only one of the bigs offering complete local processing and is why I switched over. It has enabled finally completed my vision of full cloud independence: TTS is local through macOS, voice control is local through siri, the only house control app, I will end up having is likely going to be the iOS home app... But the automation still is on openLuup and a large number of integrations on Home Assistant with z-way still controlling a large zwave network.
-
@ronluna said in Apple Homepod mini:
@akbooer That's right... and just like that... apple is taking over then entire home automation industry.... too bad there is no Home app for Android. Well Front end and first layer voice control related...
Not sure I would call that a takeover quite yet. Homekit is not the panacea when it comes to automation but it certainly does a lot of things better than others. It's certainly taken a long time for them to come up with a device like this. The original HomePod was just too expensive for this application. My original idea for the homekit bridge was to use an iPad as a console by the front door on which I could use siri. This was 5 years ago in my previous house. I more or less shelved Homekit until this past month seeing that thread on the hubitat forum.
I just read this for the first time today and I completely agree with the vision:
It is 5 years old and am pretty sad with the obsession of all these companies with the cloud, wanting to get our data in it. Sadly Apple is the only one of the bigs offering complete local processing and is why I switched over. It has enabled finally completed my vision of full cloud independence: TTS is local through macOS, voice control is local through siri, the only house control app, I will end up having is likely going to be the iOS home app... But the automation still is on openLuup and a large number of integrations on Home Assistant with z-way still controlling a large zwave network.
Perfect Home Automation
