wrong group state

[dercaptainbc]

Hi realized that if at least only one lamp in a group is on (my group contains 3 lamps in two different zones, Essbereich und Wohnbereich) the group state is false, but it should be on.

The indicator for any_on is true

Because of that I can not turn off the one lamp per _commands for the other zone (with two lamps it works fine)

[daniel1v]

Hi, I also recognized this behavior and do not like it very much because it often prevents me from turning off my groups with a single tap on a switch in vis. Also the switch often shows a wrong state because of this.

But I think the issue here is not in the hue-extended adapter. The wrong "on" value comes from the hue bridge and I don't know if it makes sense to make a workaround, because then it differs from the native hue behavior and could lead to other issues. (or maybe not?)

Nevertheless I will try to find a fix and will post it here, because -as I wrote above- I also do not like it the way it behaves.

[Zefau]

@dercaptainbc @daniel1v could you try with current Github version v1.2.0 if this is fixed?

[daniel1v]

@Zefau After some testing it seems to me like there is no difference.

But as I stated before: I do not think it is a bug in your adapter, because it correctly sends the values to the bridge and reads the values correctly from the bridge.

The issue is, that sending group values (on/off, brightness...) via API leads to a different behavior than changing it via Hue App. The logic for this seems to be programmed inside the Hue App and not on the bridge.

[Zefau]

@daniel1v @dercaptainbc Could you try if current Github version v1.2.2 (65b1063) changes the behavior? The on state within the action tree is not set to the same value as any_on.

[Zefau]

@daniel1v @dercaptainbc Have you had the chance to try the latest version? With that version on should be equal to any_on.

[dercaptainbc]

@Zefau I'll let you know after updating to the latest version

[dercaptainbc]

@Zefau now I had time to check but on is still not equal to any_on. My current Version is 1.2.3

[daniel1v]

@Zefau Thank you for the good support here.

I can confirm what @dercaptainbc is writing. I installed 1.2.3 and on is still not equal to any_on.

[Zefau]

Please try again with current Github version (no version change, but updated). I think I got it now.

[dercaptainbc]

@Zefau for me it looks like it is fixed. on & any_on are synchron now.

[dercaptainbc]

Okay .. sorry but I found a strange behavior...

I've three Lamps in one of my groups (2x Hue Plays and 1x E14 Bulb) only when I turn one special Hue Play the on & any_on are equal. When I try it with the E14 or the other Hue Play on & any_on are not equal.

[dercaptainbc]

I don't know if it make sense for you but I found out that on & any_on are only equal if the turned on lamp is the last one in the group (which is displayed as last in the group overview in the Hue app)

[daniel1v]

@dercaptainbc
I was also a bit confused by this behaviour and opened a similar issue some time ago. after some research with the CLIP API debugger it turned out, that this strange values come from the hue bridge.

• the any_on state does what it sounds like: it is true as soon as any lamp is turned on.
• the on state seems to be always similar to one special lamp inside the group, what is, as you wrote, a little bit strange.

similar behaviour can be observed for brightness, color and color temperature attributes.

[daniel1v]

@Zefau
basically it seems to work now. when i turn on any single lamp inside a group, the the groups on and any_on state are both set to true. it doesn't matter if the lamp is turned on via dimmer switch, the android app or iobroker.

Also when I turn off the lamp inside iobroker the group value is correctly set to false.

BUT: when I turn off the lamp outside iobroker, the groups on stays true, while any_on switches correctly to false. also the on state of the single lamp stays true, although it is definitely off. I am not sure, if the bug is related to the recent changes or if it was there before.

if you want, I can open a new issue for this, as it seems that it does not only affect the group state, but rather the single lamps state.

[Zefau]

Thanks for the feedback! Very much appreciated! Could you try v1.3.1 if this fixes the bug?

[Zefau]

@daniel1v @dercaptainbc

[daniel1v]

After a few tests I can say it seems to work now. Well done. :)

[Zafford]

I'm not sure that the state behavior should be like that. Why should the group state be "on" if only some of the lights in the group are on? In my case I have a "TV" group with two lights and an "office" group with two lights and these 5 lights are in the "Top Floor" group. If I turn on the "TV" group, the "top floor" group switches to "on". I would assume that this should only go to "on", if all lights in the group are on. In the current setup I can't move the "top floor" to "on", because it is already on, even though only some of the lights are on (using version 1.3.2)

[Zefau]

@daniel1v what do you think?

[daniel1v]

@Zafford is basically right. As soon as one light is on, you lose the ability to turn on all the lights, because the group state is "on".

But there is always a tradeoff on this topic:
A) You lose the ability to turn on a group as soon as one light in the group is on
or
B) You lose the ability to turn off a group as soon as one light in the group is on.

There is no absolute right or wrong on this topic and the downsides of both solutions are very similar. But there is another point to consider: The actual behaviour of the adaptor keeps consistency to the official hue app (and also most 3rd party apps) and I think it is important to be consistent.

Every other behaviour is (in my opinion) customizing and should be done in custom scripts and not in the adaptor itself.

At most there could be an "advanced setting", which switches this behaviour.

[Zafford]

@daniel1v @Zefau I understand your point, though I might not agree with that being a trade-off. I'm not sure why the ability to turn off a sub-group by turning off the super-group would be something desirable 😀 The most glaring case would be the example of one light in a "alone" group and the "all lights" group. If you turn on the "alone" group the "all lights" group would be shown as "on". IMHO it seems a stretch to think of the "all lights" group as on in that case.
I understand the wish to be consistent to others, it just strikes me as illogical 😉
So if we stick to the current behavior, can anybody point me to a way to implement "my" behavior in a script?

[daniel1v]

@Zafford thank you for your answer. I do not exactly agree with your argumentation. in fact it is a trade-off in terms of program logic:

As soon as one lamp in a group is turned on, the group state is neither "on" nor "off" in the real world, we are living. It is "something in between". But being bound to a boolean variable, the developer has to decide, what makes more sense. As I stated before: both solutions have similar disadvantages. I would not claim that one of them is more logical, or "illogical". The only thing that could be taken into account is the way, the device manufacturer solves this issue.

There will always be cases where one way seems better than the other and vice versa. Cherrypicking of single examples does not change that fact. Here my "most glaring case" for you: Think of twenty lamps in my "all lights" group. Nineteen are turned on and one is turned off. Why should it make more sense, to say, "all lights" are "off"?

It is not up to me, to decide this, because I'm not an active developer here. But being asked for my opinion I just wanted to clarify, that is in fact a trade off and no side has better arguments in terms of pure logic. So it is not neccessary to call my preferred solution "illogical".

Also to answer your question:
One solution could be to fork this repo, implement the desired behaviour and use your own version of hue-extended. If you want to help others, who share your point of view, you could implement a checkbox in the settings page, so that the user can choose which behaviour fits best and then make a pull request, to give @Zefau the ability to include it in the official version.

Another solution would be a javascript that watches for changes to the "all_on" state of the group and writes this changes to the "on" state of the group.

@Zefau, what do you think?

[Zafford]

@daniel1v first let me apologize for what seems to be my poor choice of words, might be for"not-my-first-language-reasons". I get your point and will look for other ways to get my reasoning implemented. And yes, for me "on" is a much more narrow defined concept as "off". So in your example for me "all lights" is still not "on". It might also be not "off", but for me whatever is not "on" or boolean true is boolean false or "off". Thanks for your detailed explanation...

[daniel1v]

@Zafford no problem so far. It is is more a personal opinion or some kind of philosophical question, because one could also state that not false must be true. At least in boolean logic, where only this both states exist.

As stated before: it is not up to me, to decide about changes and I understand what you mean. Maybe @Zefau has the same opinion as you.

The reason we discussed this issue some time ago was, because the initial behaviour of hue-extended was as you described and because of that it differed from other popular user interfaces, like official hue app, all 4 hue, etc.). The conclusion at that time was, to make the behavoiur similar to other apps, to avoid confusion.

[Zefau]

@daniel1v @Zafford thanks guys for the discussions! But what could be a possible solution?

From my perspective as a developer we have a lot of options to implement additional states or additional adapter options to reflect any feature requests.

Meaning that we leave the on as it is implemented now, because it is consistent with official behavior and implement e.g. some additional states.

To be honest though, I do not fully understand the problem so far. Regarding the state (not action) the adapter provides the states state.all_on and state.any_on to reflect if any light or all lights in the group are on.
So from my understanding the issue is only in regard to the action (thus setting the lights), is that right?

For that I could simply move the states from state to action and assign different behaviors, particularly all_on will turn on all lights while any_on would turn them all off?
While writing this I'm thinking it is probably best to keep the states and add the actions as buttons (without state indication and only to trigger the action).

What do you guys think? Would that solve this issue finally?

[daniel1v]

@Zefau I think you got it right. as far as I understood, @Zafford wants the "action.on" to have the same value as "state.all_on". At the moment it behaves like "any_on".

What about a checkbox in the settings page, to switch the behaviour? The setting could be named like "set action.on to state.all_on".

[Zefau]

@daniel1v Introducing a new checkbox and switching the behavior means brings the trade-off in effect.

Introducing an additional state / button allows both at the same time, which is why I prefer that option. What do you think?

[Zafford]

@Zefau I'm really not sure what the way to go is. I would like to have the state indication kept with the action so I can use it as indicator and switch. I think that would be the "checkbox" option. But maybe we could have an action.all_on, action.any_on and an action.on that behaves like the official behaviour.

[Zefau]

@Zafford Could you try the latest version from Github? I slightly changed the on action datapoint for groups. Maybe this fits you?

Since action.any_on would be the same as action.on, I will only add action.all_on.

And for the comprehensive understanding of it: The action of all_on and any_on will be the same (it turns on or off all lights in the group). Only the state indication is different. Is that right?

[Zafford]

@Zefau how can I install from Github to my Windows installation? I'm normally only using the repository?

[Zefau]

In the adapters tab within ioBroker is an icon of a cat. Click on that one and paste the URL of this repo https://github.com/Zefau/ioBroker.hue-extended.

[Zafford]

I installed 1.3.4 from github, I can't really see a difference - "on" in the groups seems to behave as before...

[Zefau]

Please try v1.3.5 from Github. This introduces a new action called onOffAllLights. That state reflects all_on (whilst the action on reflect the state any_on).

Please let me know if that is what you need. Cheers

[Zafford]

Just checked it out and it seems to be exactly what I needed. Thanks a lot.