HomeKit Bridge Closed Beta Discussion

Autolog reported an issue today about action groups that is on the known issues list and slated to be reviewed.

Garage doors aren’t yet working. There are still a lot of devices to incorporate, including doors.

Are you going to remap the values in the bridge? I'd hate for you to have to do that for every device type.

No, once the base definition is done for each major group it should work out. Garage door problems are a Homebridge issue right now.

I think I have the action group issue finally locked down, took a bit to figure out why it would hang up but a creative solution has resolved the problem and it'll be in the next beta release. Just letting folks know here since action groups are going to be a bigger deal early in the testing since so many other device types haven't yet been defined.

I think it would be useful (in the fullness of time) to emulate what is done in the Alexa-Hue Bridge (which emulates Indigo's Virtual devices). That is to be able to specify On, Off and Dim Actions and store the dim value in a variable. That would allow users using the Alexa-Hue Bridge to use the same actions in your plugin as well.

Just a suggestion

It's a good suggestion and I am open to all suggestions! I don't want to put it in the server config only because one of my goals with this plugin is to make it bulletproof in setup, no extra "stuff" to make it harder for the average bear to figure out. I'm not the average bear and the Alexa options are a bit overwhelming for me sometimes. That being said, it's also been on the roadmap from day 1 to have a way for advanced users to tweak device settings, such as what on/off/dim would do instead of the default. I've debated doing that in another plugin (likely Device Extensions) or doing it here, but again I want purity in this plugin and not inundate it with all sorts of other crap that might just break it. As it sits this plugin is a pretty complex piece of coding, if I were to do too much more than serve up HomeKit I fear that it would destabilize it or water down the core function.

Does that make sense?

The 4th Beta has been released. This'll take care of the Action group issues and adds thermostats to the mix.

Code: Select all

  HomeKit Bridge Warning          DEVELOPMENT TEST FUNCTION ACTIVE
   HomeKit Bridge Error            Exception in homekit.deviceInitialize line 595: local variable 'obj' referenced before assignment
                      CODE: self.alias.value = obj.name

This is on first install. Also got

Code: Select all

   HomeKit Bridge Error            HomeKit server 'Test' could not be started, please check the service logs for more information, now issuing a forced shutdown of the service to be safe.
   HomeKit Bridge                  Attempting to stop 'Test'
   HomeKit Bridge                  HomeKit server 'Test' has been stopped
   HomeKit Bridge Error            send "Test" on failed

on first attempt to run it. I'm unclear where the logs are aside from the Event Window.

I've deleted the bridge, recreated it with no devices, still no go.

I find the Include menu for the bridge to be SUPER awkward and unintuitive. Also, as I run the UNIFIAP plugin, I have literally hundreds of devices that I don't want to be included, so it's pretty tedious. Non-contiguous selecting doesn't seem to work right in the Include list, which is a big contributor to the awkwardness.

Also, once I've deleted enough devices to be below my 99 limit, I don't see any way of making devices that weren't in the first 99 appear.

Actions are working Ok for me now

Added a thermostat (Eurotronic Spirit). Its temperature range is from 8 to 28. The slider in the Home App goes from 10 to 38.
Can the range either be specified or have a lower limit.

A Stella-Z thermostat can go down to 6.

Controls work though on an an initial test.

I think it would be useful (in the fullness of time) to emulate what is done in the Alexa-Hue Bridge (which emulates Indigo's Virtual devices). That is to be able to specify On, Off and Dim Actions and store the dim value in a variable. That would allow users using the Alexa-Hue Bridge to use the same actions in your plugin as well.

Just a suggestion

It's a good suggestion and I am open to all suggestions! I don't want to put it in the server config only because one of my goals with this plugin is to make it bulletproof in setup, no extra "stuff" to make it harder for the average bear to figure out. I'm not the average bear and the Alexa options are a bit overwhelming for me sometimes. That being said, it's also been on the roadmap from day 1 to have a way for advanced users to tweak device settings, such as what on/off/dim would do instead of the default. I've debated doing that in another plugin (likely Device Extensions) or doing it here, but again I want purity in this plugin and not inundate it with all sorts of other crap that might just break it. As it sits this plugin is a pretty complex piece of coding, if I were to do too much more than serve up HomeKit I fear that it would destabilize it or water down the core function.

Does that make sense?

Putting it in another plugin would make it more complicated IMO. Having an advanced feature that could be selected would be good (as I said in the fullness of time). I was only suggesting it as I have found it useful for the Alexa-Hue Bridge. I also like the simplicity of your solution.

Would it be possible to define an Action Group as a Homekit Scene. In some ways that might be a more logical implementation of what you are currently doing for Action Groups - essentially click and play?

The slider in the Home App goes from 10 to 38.
Can the range either be specified or have a lower limit.

That limitation is Apple's hard coded into the HomeKit app, sorry .

Would it be possible to define an Action Group as a Homekit Scene.

No ability to do that just yet, it's 100% devices. No rooms, no scenes and no automation.

I moved the conversation here so all beta discussion is together.

I've deleted the bridge, recreated it with no devices, still no go.

I don't get that error, it's odd that you would, particularly since the dev test mode was disabled before I uploaded B4. Try adding devices, that may be a problem.

I find the Include menu for the bridge to be SUPER awkward and unintuitive

Wow, sorry.

I have literally hundreds of devices that I don't want to be included, so it's pretty tedious

I'm working on ways to make that easier. Do you find the Alexa SUPER awkward and tedious as well? If you have any ideas based on any past plugin development please do share and I'll see if I can improve it.

I don't see any way of making devices that weren't in the first 99 appear.

I don't think I understand this question.

Do you find the Alexa SUPER awkward and tedious as well? .

I don't have an Alexa, but if I did, I'm sure I would find it so. Sorry if I sounded harsh.

Here's what I would find simpler:

When I choose the Include menu the first time, ALL devices would appear but NOT be included. I could Command click on up to 99 choices to include them, then click "Include selected devices." If I finalize my choices and then come back to this menu, the devices I selected are still selected and unselected ones are still unselected.

EDIT: Exactly like how you add devices to a Virtual Device group.

As to the 99 devices, here's what I find, again in the Include menu:

When I click to add devices, it fills in the first 99 devices, alphabetically, and then I have to remove ones that I don't want. When I do, I'm told I can add new ones, BUT the device that was previously 99th is still the last device. I don't get new ones I can add.

Sorry if I sounded harsh.

I suppose I was thinking along the lines of more constructive and less "well this sucks" . Considering how much coding went into making that page work right it was a little kick in the teeth.

Let me explain why the screen is the way it is and, perhaps more importantly, why it's isn't another way. This doesn't mean I'm not willing to explore different ideas but there is a method to my madness.

One of the driving factors in this rewrite, other than general stability and expandability, was being able to not have to rely on Alias devices if I wanted to rename my Indigo devices. In my case I currently have 69 devices that do nothing more than provide a different name for voice controls than what they show up in Indigo as. At first it was really cool but now I find it extremely burdensome to deal with (you'll notice in this version the HBB devices show up in a special way on that list, this is the reason why). I wanted to come up with a way that was user friendly and familiar and this form is easy to figure out (I don't understand your complaint of it being unintuitive because it's only four fields) and it's familiar because it's very similar to how Alexa Hue works (and I'm willing to bet 75% or more of us will or do use both).

You should also consider that, as a beta, there might be more coming down the pike that just isn't here that addresses your issues specifically. And there is. I've said several times that there will be advanced editing and over the past couple of releases I've talked about a "Wizard" that will make setup much easier for those that don't want or need to cherry pick devices. The wizard, as it is and undergoing a bit of a rewrite, is meant to process your entire Indigo system but in a way that allows you to mass import with greater precision (such as importing by Indigo folder, Indigo Type or HomeKit type). Your complaint gives me an idea for having an exclusions list too.

In the end I'm trying to simplify the user experience. Most users find the current selection list and "treat as" system highly confusing and burdensome and so that's all gone. What is left is a system that with four self explanatory fields you can get voice control. In my mind the only "unintuitive" option is the "Fill" because it may not be obvious but this, as well as the rest of the form, I think is well documented on the Wiki for being this early of a beta.

In the end this might not be your cup of tea and there's nothing wrong with that. No harm, no foul, but to redesign the UI now would set me back probably 20-30 hours of work.

Your complaint gives me an idea for having an exclusions list too..

Ok, this will be available when I publish Beta 5, it's a change to the current dialog as well as an entirely new plugin menu option to manage and hide any Indigo objects from the plugin. I think this will help with the objections that Different Computers had about trying to manage devices while not requiring a whole new dialog to be built. It's an excellent suggestion and I think it is easy to use (you will now have "Delete and Exclude" in the dialog too to hide items on-the-fly).

manage-hidden-objects-screen-beta.png (145.05 KiB) Viewed 2012 times

Fair enough. And yes, I did find the HBB interface equally confusing. Ultimately I got my head around it and got it working.

Somehow, though, I'm not understanding how HKB's Include is supposed to work currently. Or do I have some sort of bug besides the fact that the HKB server won't start for me? Because here's that main thing: When I'm doing as I think I'm supposed to be, and automatically populating the list, then deleting things I don't want added, here's what happens:

The first 99 devices in Indigo appear, in alphabetical order.
Every time I delete a device, it tells me I can add a device. If I delete 10, it says I can add 10 more, etc.
There's no way I can see to make that window load any more.

(This post crossed the one above it in timing and isn't a response to it.)