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.
-
@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.
-
@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...
-
@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.
-
@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: 8 months 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.
-
rafale77replied to akbooer on Apr 6, 2021, 2:14 PM last edited by rafale77 Apr 6, 2021, 10:16 AM
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.
-
akbooerreplied to rafale77 on Apr 6, 2021, 2:24 PM last edited by akbooer Apr 6, 2021, 10:24 AM
@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!
-
rafale77replied to akbooer on Apr 6, 2021, 2:30 PM last edited by rafale77 Apr 6, 2021, 10:31 AM
@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...?
-
ronlunareplied to akbooer on Apr 9, 2021, 12:12 AM last edited by ronluna Apr 8, 2021, 8:15 PM
@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.
-
-
@rafale77 said in Apple Homepod mini:
My setup:
Z-way + home assistant -> openLuup -> HomeKitBridge -> Homekitand all I'm doing now is:
openLuup <--> MQTT <--> Homebridge (using homebridge-mqttthing)
with both openLuup and Homebridge directly connecting to Philips Hue hubs for Zigbee.
-
My Homepod mini arrived today. Very slick setup using an iPad. Happily discovered the Homebridge running in my Synology Docker, and all the configured devices (including my new Shelly Button 1!)
The revelation here is that the Homepod solves the remote access issue for openLuup, in that all the devices exposed (via MQTT) to the Homebridge are fully functional.
Love it! Thanks for the initial recommendation @rafale77 .
Perfect Home Automation
57/62