Disaster recovery and virtualisation

[CatmanV2]

@elcid said in Apple Homepod mini:

@rafale77 said in Apple Homepod mini:

I can walk to any room ask it to turn lights on and it won't ask me which ones, it will just turn the ones in the room

I can do the same with alexa, but do like the sound of more local processing.

Mine used to do that, but it stopped a while back for no obvious reason.

C

[rafale77]

Found a side benefit of siri as I am refining the very old verahomekitbridge... I now get to "open and close" garage doors, locks and curtains while alexa had to "turn then on and off" since it was a hue emulator. I also found a workaround to control sonos volume using a virtual dimmer device on openLuup.

Even setting up groups and rooms is noticeably faster with HomeKit compared to doing the same with the Alexa app or webserver because of the local vs. cloud difference. I don’t dread as much resetting all my devices.

[Crille]

I love the simplicity of raising my hand and say to my watch "Open right garage door" when I'm approaching my home in my car, and if I forget, Siri asks me if I want to open it since I'm entering my geofence

[rafale77]

Ok been preoccupied with work and reaching full feature parity with what I had with the alexa habridge. I am now done. I managed to replace all the alexa skills with direct bridging with the verahomekitbridge (again old predecessor of homebridge but I didn't want to upgrade to it since I have little use of the extra features it brings... they are all redundant with Home Assistant). I have now siri change the volume of my pioneer receiver and my sonos system by reproducing all the habridge "tricks" I had in openLuup. So satisfying...

@Crille, I take it that you use the homekit geofence? I am actually thinking about integrating it into openLuup as well though so far the iPhoneLocator has served me well.

[Crille]

Yes, I’m using the HomeKit geofence and have some HomeKit automations since they are too easy to set up on the fly for not being used.
iPhoneLocator uses the same data for location but I have no use case for polling my position since my phone knows where it is and use the integrated automations I set up.

[Pabla]

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

[rafale77]

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!

[rafale77]

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:

[CatmanV2]

Great data, thanks @rafale77 !

C

[akbooer]

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?)

[Crille]

@akbooer Are you running the Homebridge UI?

[akbooer]

How would I know? I’m accessing it through the Home app on the iPad.

[Crille]

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.

[akbooer]

@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.

[therealdb]

@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...

[ronluna]

@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.

[akbooer]

@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.

[rafale77]

@akbooer

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.

[akbooer]

@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]

@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"?