search

eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
865 stars 782 forks source link

Hue lamp is not removed when removing hue bridge #1763

Open afuechsel opened 8 years ago

afuechsel commented 8 years ago

A hue lamp is not removed, when the bridge is removed. Furthermore, the lamp status is still ONLINE and won't even change, when sending a command to the bulb is answered with this log entry: "16:13:15.600 WARN o.e.s.b.h.h.HueBridgeHandler[:203] - No bridge connected or selected. Cannot set light state."

afuechsel commented 7 years ago

With the current release, this issue is slightly different. The lamp is still not being removed but now its state is "UNINITIALIZED - HANDLER_MISSING_ERROR". If trying to remove it, it stays in REMOVING and must be forcefully removed.

Wouldn't it be mich better to add a logic to the BaseBridgeHandler, to remove all of its children when the bridge is being removed, @kaikreuzer ?

afuechsel commented 7 years ago

Looks like #2757 is not fixed (at least in the hue binding)

kaikreuzer commented 7 years ago

Wouldn't it be mich better to add a logic to the BaseBridgeHandler, to remove all of its children when the bridge is being removed, @kaikreuzer ?

Well, at least @J-N-K would be against that, see https://github.com/eclipse/smarthome/issues/2757#issuecomment-272390904.

J-N-K commented 7 years ago

I don't have HUE lamps, so I can't comment in detail, but: is it possible to define things in textual configuration? These can't be removed automatically. IMO it is very confusing if things are treated differently. And like I said in #2757, for the upcoming DMX binding (#2704) it would be a very bad idea to remove the things only because no bridge is assigned.

BTW, This is a perfect example, why #4182 should be implemented the way I proposed. If no handler is available, we should warn the user about the dangers and force removal of the thing on the first try.

J-N-K commented 7 years ago

Oh. And as far as I can see our thing lifecycle is not very clear here. It does not state what the correct status for a thing missing the bridge or the bridge handler (not having an OFFLINE bridge) is.

If the bridge configuration is missing or the bridge handler is not available, the thing is set to "OFFLINE/BRIDGE_OFFLINE" in the HUE binding (IMO should better be OFFLINE/CONFIGURATION_ERROR if the confiuration is missing a bridge), but it switches to "UNINITIALIZED/HANDLER_MISSING" if the bridge is removed? Probably it'll also stay in UNINITIALIZED/HANDLER_MISSING if a bridge is configured but missing befor initialization.

triller-telekom commented 6 years ago

To dig this issue out again because I am now reading it probably the 10th time:

I would vote for @afuechsel's proposal. If a user intentionally removes a bridge, i.e. he clicks on "remove" in the things view of paperui, ALL of its children are removed too.

Of course this has to be supported by the UI in a sense that it is transparent for the user what happens. For now the things view is a flat list, but it would be better if it would be grouped by bridge, so a user sees which things belong to the bridge and will be removed as well.

@J-N-K Why would it be a bad idea for the DMX bindingif the user intentionally deletes a bridge? If the user's intention is to get rid of the bridge (assuming he wants to get rid of his dmx devices), this should be alright, shouldn't it?

J-N-K commented 6 years ago

I think it is a bad idea. Some weeks ago I had a hardware failure and my sACN Bridge was replaced by an ArtNet device. I deleted my old bridge, created a new one and assigned all things to that new bridge.

Of course I could have changed the bridge in all things before deleting the old bridge. But IMO this is very error prone. If it is like it is now, a thing I forgot to switch to the new bridge is simply offline, because the bridge is missing. If it is deleted on bridge deletion, it will be lost. Since there is no „undelete thing/bridge“, this seems too dangerous.

I agree on the grouping, that would be a very nice feature.

triller-telekom commented 6 years ago

Hmm I guess your DMX use-case is different than I would say the "usual" one. Most of the time there is only one bridge type. So for philips hue or ikea tradfri for example, if the gateway is broken you replace it with the new hardware and update your bridge thing in ESH, then you are done.

Your case is only problematic because there are different types of bridges involved. I wonder if this is the exception or if we will see more bindings in the future...

Another solution to the problem would be a thing-type migration which we already support, but for this scenario we would have to define how and where it will be triggered. We could migrate from the sACN Bridge type to the ArtNet bridge type, similar to just updating the bridge thing in the hue and tradfri case. WDYT?

J-N-K commented 6 years ago

I agree that - at least from all bindings I use - the DMX binding is special here. If changing the thing-types for bridges is easy, that might be a solution.

Another binding that will probably support different bridge types is the OneWire binding I'm currently developing. In the first version I'll only support OWFS/owserver as bridge, but I'm thinking of direct support for USB-busmaster devices as bridges in a later version.

However I still think that accidentally deleting the bridge may result in lots of thing configuration work being lost. Do you think it would be possible to provide some "undelete" functionality for that?

And - last but not least - please make sure that all links are also removed. I didn't dig deeper into that issue because I was busy with other things but when I deleted a thing with a channel linked to an item, the thing disappeared - as expected. Later I created a new thing with the same id. The channel-item-link was still there. This is probably more unexpected than things that continue to exist when the bridge is removed. If you think this is a bug, I'll file an issue for that.

triller-telekom commented 6 years ago

As I said we currently allow migration of thing types already, so we should also allow that for bridges in my opinion.

How do you "accidentally" delete a thing? There is at least a confirmation dialog. This dialog should of course be extended to make clear that all child things will be removed.

I think the deleting of channels if you delete a thing is related to https://github.com/eclipse/smarthome/issues/1018 where we are discussing what happens with a link if we delete an item.

maggu2810 commented 6 years ago

If we have a filter expression on get and remove things (see https://github.com/eclipse/smarthome/issues/4302) the UI could provide a "delete all things of bridge" trigger. It could simply ask "you remove the bridge, should all assigned things be removed, too" and send send that additional REST call. IMHO this is something the user should trigger and not automatically be done by some logic itself.

J-N-K commented 6 years ago

I agree with @maggu2810. An extra confirmation for thing deletion would be ok for me.