HomeKit Bridge Coming Soon

[Colorado4Wheeler]

I've been hinting at this for a bit and I'm about ready to open this up to testers this week (depending on a few last minute details getting ironed out).

This can be considered the second generation of both Homebridge-Indigo by Webdeck and Homebridge Buddy by C4W as both have been completely rewritten for this new plugin.

To highlight a few differences between HBB and HomeKit Bridge:

• 100% server, this will never do anything more than be a server for HomeKit
• No more "treat as" or limitation to just 8 device types, this will open the entire HomeKit device list to Indigo
• No more Aliases and Wrappers, Indigo devices will be auto detected to match their HomeKit counterpart and mapped accordingly, the ability to tweak this will be added in future versions but there won't be any devices to do this, it'll all be form based from the plugin menu
• Alias names built in to the server. Just like the Alexa Hue bridge, you'll be able to provide an alias name when you select a device to be included in HomeKit, there won't be any need to create an alias if you don't want HomeKit to refer to it as the same name as it is in Indigo
• All server profiles saved under your home folder rather than in the plugin folder structure
• No support (nor will there be) for any other Homebridge plugins because the philosophy behind this plugin is "if it's supported in Indigo then it can be passed to HomeKit", I hope that this will include cameras too but time will tell. It will, however negate the need to have things like the iTunes plugin because you can already control iTunes (and Sonos, etc) from Indigo so if we can do it there we only need to map those functions to an appropriate device in HomeKit
• Instant notification of Indigo events. This was actually fixed in the latest version of HBB, but prior it was never fully functional that when an Indigo device changes it immediately updates HomeKit - that will be resolved in this plugin as every change instantly updates HomeKit.
• Support for COLOR! While the details are still getting ironed out, if your Indigo device supports color then you'll have access to that in HomeKit. This likely won't be available in the early testing because it's low priority, but it IS a priority

I'm posting this to see if anyone wants to jump on board for early beta testing. You CAN run this alongside both Homebridge Buddy and Homebridge-Indigo, and has actually been built so you could do that to make for an easy migration (which will be automatic in a future release).

This early plugin will be limited in what it can do as the basic functionality is tested and tweaked but it should be evident early on that it is going to far outshine HBB. If you are interested in testing this then please let me know so I can invite you to the private Git repository (you will need to have a Git account) as soon as the plugin is ready for testers (again, hopefully this week). Also if you have any questions about this new plugin you can use this thread to ask those.

Screen Shot 2018-02-05 at 2.44.58 PM.png (130.91 KiB) Viewed 4328 times

[jay (support)]

Sounds awesome! One thing you might want to reconsider:

All server profiles saved under your home folder rather than in the plugin folder structure

That's going to mean that to restore a fully working Indigo install that includes your plugin, the user will have to make sure that both the Indigo structure and your folder in their home directory will need to be restored. Here's what I'd recommend doing:

Code: Select all

path_to_install=indigo.server.getInstallFolderPath()
# Right now, you'll get back u'/Library/Application Support/Perceptive Automation/Indigo 7' but it will change with version changes
# Make the path point to a folder for your plugin in the Preferences folder (use the plugin ID from Info.plist)
path_to_my_prefs_dir = u'{}/Preferences/Plugins/com.mycompany.myplugin/'.format(path_to_install)
# Next, check to see if your plugin's prefs directory is present and if not create it
if not os.path.exists(path_to_install):
    os.makedirs(path_to_install)
# So, now you have a full path to a safe location (path_to_ that will get backed up with all of Indigo and a single restore
# and you can write anything you like to it.

I haven't tested the above, but it should be close. That directory is where your plugin's prefs are stored, and you can create the folder there to store anything else you want. That whole folder will get moved over by the Indigo installer when the major version number changes so it should be future proof.

[Coolcaper]

I’d love to give it a go...especially with the HomePod on the way!


Sent from my iPhone using Tapatalk

[Colorado4Wheeler]

That's going to mean that to restore a fully working Indigo install that includes your plugin, the user will have to make sure that both the Indigo structure and your folder in their home directory will need to be restored. Here's what I'd recommend doing:

Not really because it will be dynamically rebuilt from the data stored in the device. It's just so Homebridge can start and, in fact, the new plugin is far less reliant on that than the old one was. If the config went totally away then nothing would be impacted.

I’d love to give it a go...especially with the HomePod on the way!

That's why I wrote it .

[chobo]

Also happy to be an early tester! Thanks in advance for the great work, C4W!

[ZachBenz]

Happy to test also - I’m ZachBenz on github as well.

[Colorado4Wheeler]

Awesome. Once I have a solid test date I’ll get folks invited to Git.

[EddieJ]

Sign me up!!!! I love the plug in and the enhancements sound perfect!

[haavarda]

I would love to test this out.


Sent from my iPhone using Tapatalk

[Different Computers]

This is very exciting! Not sure I'm up for testing, but maybe. Especially with my wife off on a cruise with her mother for the next 2 weeks. I could test without harming WAF!

[Colorado4Wheeler]

UPDATE: Things are progressing nicely. The Homebridge component is looking slick and we are dialing in the communication with Indigo (it uses a new custom API). We may very well be on track for Friday! Once I'm able to get everything packaged up with the Homebridge server and have at least some of the communication running between the two then I'll open up the beta and send invites to everyone who has replied to this thread or PM'd me.

I could test without harming WAF!

LOL, you could anyway as it's designed to run in harmony with HBB anyway so you can add test devices or even use a device that's already being used in HBB and call it "Test Light" or whatever. In fact it's a better test for me to have people who run HB or HBB so I can make sure that harmony exists. If anything the new plugin would fail, not the old one.

[jay (support)]

Not really because it will be dynamically rebuilt from the data stored in the device. It's just so Homebridge can start and, in fact, the new plugin is far less reliant on that than the old one was. If the config went totally away then nothing would be impacted.

So why write it at all? Less code is generally a good thing...

[martinc]

I would like to test please.

[AndyVirus]

Yes Please! I would like to give it a go too.


Sent from my iPhone using Tapatalk

[Colorado4Wheeler]

Wow the request are more numerous than I thought they would be, sounds like there'll be a lot of folks testing it.

So why write it at all? Less code is generally a good thing...

It is, for sure . It was a side note only because a few folks ended up with MY server def folders in the plugin of HBB and it was confusing and that would have been avoided if I had stored them elsewhere. The reason for this in the first place is that HomeBridge requires a config file to start and it needs a place to store it's logs and plist info, so this folder is where it does all of that. Without it HB won't start, so it has to be there and the plugin has to write that config file. However it something happens to the folder (and there may be cases where that's a legit debug measure to manually remove the serverId folder) then the plugin will dynamically rebuild it when it tries to start the server again. For each server device there is a matching folder so that each server has its own config and log and plist. So 5 server devices = 5 server folders.

Does that make sense or am I misinterpreting your comments?