search

kw123 / Hue-Lights-Indigo-plugin

Philips Hue control from Indigo
MIT License
7 stars 11 forks source link

Each hub should be it's own device #6

Open indigo-jay opened 2 years ago

indigo-jay commented 2 years ago

Rather than hard code the number of bridges, there should be a bridge device type which is then selected when adding a new device.

This is definitely something that's a longer-term item but I wanted to capture it.

kw123 commented 2 years ago

Jay Thanks for testing. I am not using all the functions yet so it is difficult to test All aspects.

Looking at the code. There was a ton of redundant sections. I am trying to streamline it step by step.

And yes I know re devices.

But the hub parameters were hard coded Into config and that way it was the easiest way to do it. I got 2 bridges as I have 78 bulb devices and growing. I needed a quick fix.

And on another sides it is unlikely that anyone will ever have more than 2 bridges it allows for 9 now.

Karl

On 10.03.2022, at 21:29, Jay Martin @.***> wrote:

 Rather than hard code the number of bridges, there should be a bridge device type which is then selected when adding a new device.

This is definitely something that's a longer-term item but I wanted to capture it.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

indigo-jay commented 2 years ago

Here's another reason for this: if one of your hubs becomes unavailable, you get repeated messages about the hub being gone. You need some way to disable one hub (and it's associated devices) such that it behaves like an unavailable/error state device. The user needs to be able to visualize this somehow, and to be able to disable and enable the hub and all it's devices as well as disabling individual devices.