brightness & state seit 3.3.5 !

[AdamK-DE]

hi,

[HUE Birnen]

anscheinend seit 3.3.5 wird nun state gemeinsamm mit brightenss automatisch gesetzt?!
brightness=0 und state geht auf false. brightness über 1 und state geht auf true. TOP! (verstand nie wieso das nicht schon immer so war)

ist das so gewollt und neu?
ich deaktivierte gerade für all meine hue birnen die blocklys die dieses verhalten schon früher hier immer machten..
nach 3s brightness=0 wurde state=false gesetzt.. gab nun fehlschaltungen ohne ende.. licht an/aus im wechel da sich das alles in die quere kam..

aber: state=false per adapter setzt dann irgendeine brightness ein und nie 0. wieso und woher kommt dieser wert? testete eben und mal wird 12, 13, 36 gesetzt. irgendwas.. wieso?
sieht in der VIS so etwas blöd aus.. dort nutzt man ja nem button für state an/aus und zusätzlich nem slider fürs dimmen. nun wird der button dann AUS angezeigt aber der slider zuckt auf irgendwas hoch und bleibt dann so.. nicht wild, nur unschön optisch.. da wäre bri=0 bei state=false schon schlauer...

[AdamK-DE]

ja da ist irgendwo noch ein bug.. zigbee-adapter setzt brightness bei state=false falsch. sollte auf 0 bei AUS aber da wird eine der zahlen vorher genommen. aus 70 wird dann 17 oder aus 57 dann 7.. da ist irgendein system dahinter im bug ;) manchmal wird bei state=true auch +1 bei brightness gemacht. wieso auch immer...

super unschön.. spiegeln von 2x HUE birnen so kaum möglich. auch wiel der zigbee-adapter da 2s nach dem setzen noch was macht und verstellt... testete da schon herum. man braucht über 2s pausen dann beim setzen das es auch mal bleibt..

momentan mit blocklys:
spiegle eine birne auf die andere
ging früher 1A nun so gar nicht mehr!
triggere nun auf state.. prüfe dazu brightness was gar nicht möglich ist da diese ja auch 2s danahc noch verstellt wird.. setzt man dazwischen wie hier bri=50 dann überschreibt das der zigbee-adapter 1s später wieder mir irgendwas... der würfelt wohl was er bei state=true wieder ins brightness feld setzt. das sind hier nie werte die ich mal hatte...

differenzierung so "wer schaltete" + spiegeln ist fast unmöglich...
hier: licht wird per PIR und/oder anders geschalten was PIR überschreibt bzw. dem ausser betrieb setzt für zeit X..

finde zigbee-adapter sollte sich da mal entscheiden ;( alexa & matter-adapter auch.. früher wurde da der state nie angerührt. auch alexa setzte bei "licht aus" nur brightness auf 0 und fertig. damit konnte man arbeiten..
nun setzt alexa auch state per matter-adapter........ brightness bleibt dann stehen bzw de rzigbee-adapter setzt es nun auf irgendwas..

[asgothian]

The function was supposed to be added as an option - unfortunately, the UI element for the option never made it into the stable code. This will become available with the 3.4 version, which is still a few days out.

As to the delay:
The adapter does not set the brightness to any fixed stored value when the state is changed. Nor does it set the state to any fixed value when the brightness is changed.
What the adapter does do is read the brightness from the device after the state was changed and vice versa. Due to the transition_time property, this read needs to be delayed until the device itself has completely changed the status. This is the reason for the delayed action, and - in case of some Hue devices - the reason for the odd numbers, as they sometimes seem to use an internal transition_time when being switched - which leads to the read being executed before the lamp has reached its final state.

In the future, this behavior will be switchable via a model / device specific option as well as a global option.

A.

[AdamK-DE]

oh je ;) dann hoffe ich mal das diese option die bei 3.3.5 ausversehen schon AN ist auch weiterhin per default AN sein wird.. ansonsten chaos pur bei allen die anfingen alles darauf umzuschreiben..

und ja das mit der trans_time kann das gut sein. switche da von 0.5 bis 5s herum.. erklärt wieso dann immer andere zahlen bei rauskommen ..

[asgothian]

It was always planned to have this behavior as standard, so yes, once the option is available, it can be used to disable this behavior.

There also will be improvements on the timing, which should give better results.

A.

[asgothian]

One thing - you can try to patch the adapter you are running for a more stable solution with Hue devices:

in the file /opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js

change this code (line 1468 ff)

                        if (readKey.converter) {
                            const tt = preparedOptions.transition || preparedOptions.transition_time;
                            const did = deviceId;
                            setTimeout(async () => {
                                try {
                                    await readKey.converter.convertGet(target, readKey.key, {device:entity.device}) }
                                catch (error) {
                                    this.warn(`error reading ${readKey.key} from ${deviceId} : ${error?.message}`);
                                }
                            }, tt ? tt * 1000 : 100);
                        }

to this:

                        if (readKey.converter) {
                            const tt = preparedOptions.transition || preparedOptions.transition_time;
                            const did = deviceId;
                            setTimeout(async () => {
                                try {
                                    await readKey.converter.convertGet(target, readKey.key, {device:entity.device}) }
                                catch (error) {
                                    this.warn(`error reading ${readKey.key} from ${deviceId} : ${error?.message}`);
                                }
                            },  tt ? tt * 1000+250 : 1000);
                        }

A.

[asgothian]

You can install the current github version of the adapter - it will include a global option to disable the read, as well as device/model specific options to limit the read to either brightness or state.

Note that the github version is under development - the 'binding' subsystem is currently not functional - you cannot modify bindings from the Adapter UI.

A.

[asgothian]

Current github / latest version includes this option, but not the default behaviour at this time.