Add origin to internal messages?

[flatsiedatsie]

I'm attempting to modify the gateway so that when an internal message is sent from a rule to change a value (or an action) it will also send an 'origin' attribute.

That way, my Zigbee addon will be able to discern between a user-initiated value change and an automation-initiated value change.

Why is this useful?

Well, currently when the brightness property of a light is changed, it also turns on the light.

But I'd like to have actions that change the brightness of a light throughout the day, independent of whether it's on or not.

That way, if I turn on a light at night, the zigbee addon can then apply the brightness value, but not while it was off.

User story:
I want to be able to create automations that adjust properties like brightness and color, without that change also triggering the light to turn on.

In the Zigbee addon:
A. user changes brightness -> brightness is applied and light switches on if it wasn't on already.
B . automation changes brightness -> If the light is off, the Zigbee addon remembers the desired brightness, but doesn't apply it, so that the light doesn't turn on. Then, when the light's state property is turned on, only then does the addon also apply the remembered brightness.

I thought I would share this, as there might be a better way to implement this? Perhaps even outside of the addon? I'm not even sure where the logic to also turn on a light if its brightness changes is located. I'm guessing it's in the capability code.

Even then, I think knowing what the origin of any event is is useful. For example, Voco keeps track of origins such as voice input, chat window input, remote mobile phone input, etc. If it's a voice origin, then the response will be a generated voice. If it's a chat origin, then the response is sent to that 'destination'. Sometimes it needs to be sent to all possible outputs, or any output that is text-based. And so forth.

So thinking ahead, maybe a destination array might also be useful? Maybe both could be inside a meta(data) key?

Similar code in the Gateway might be the importance level that notifiers use?

Curious as to your thoughts.

[benfrancis]

@flatsiedatsie wrote:

In the Zigbee addon:
A. user changes brightness -> brightness is applied and light switches on if it wasn't on already.

I think this behaviour must be specific to the Zigbee add-on or the individual device, because if you add a virtual dimmable light using the Virtual Things add-on then setting brightness above zero does not automatically turn the light on.

You could argue that this is a bug in the Zigbee adapter, but it may also just be the way the particular device behaves when you set its brightness above zero.

Ultimately I think my instinct is that it shouldn't matter what entity requested a property to change via the API, the behaviour should always be consistent. It should ideally also be consistent across devices and protocols, but that may not always be possible.

Voco keeps track of origins such as voice input, chat window input, remote mobile phone input, etc. If it's a voice origin, then the response will be a generated voice.

I think this is a different layer of abstraction above the physical state of a device represented by the API, it's about providing different user interfaces on top of the same API.

I would be interested to know whether the behaviour you've observed is logic in the Zigbee adapter or specific to your particular hardware. If it's the former then the behaviour could potentially be changed to model the two properties separately where hardware supports this. If it's the latter then achieving the behaviour you want could be tricky because it would require the gateway/adapter to store brightness changes rather than passing them onto the adapter/device, and then only setting the brightness on the device once the user sets the on/off property.

Playing devil's advocate, you could also argue that setting brightness above zero should always turn the on/off property to true, since brightness describes the physical state of the device and it can't be at 100% brightness if the light is turned off!

[flatsiedatsie]

Thanks.

I think this behaviour must be specific to the Zigbee add-on or the individual device, because if you add a virtual dimmable light using the Virtual Things add-on then setting brightness above zero does not automatically turn the light on.

Ah darn, I should have tested that, sorry. I assumed it was part of the capabilities. And you're right.. it could even be in the (IKEA) light bulb themselves 0_0.

I'll have to figure out where in the chain this combining occurs.

This is good news really.

since brightness describes the physical state of the device and it can't be at 100% brightness if the light is turned off!

And when a color light bulb is off it should show it's color as black ;-)

but it may also just be the way the particular device behaves when you set its brightness above zero.

Hmm. That implies that even if the Gateway is "consistent", buying different brand light bulbs would still fudge that consistency, since some of them would essentially have 'internal rules' that the user can't change.

So a plausible scenario is now:

• User has a (Matter) lightbulb which does not automatically turn on when brightness is changed.
• User creates two rules to the changes the brightness of the bulb depending on the time of day:

at 18:00 set brightness to 50%
at 4:00 set brightness back to 100%

Now whenever they turn it on it will be pre-set to a reasonable brightness.

• User purchases an IKEA light bulb, and applies the same rules to the IKEA bulb.
• Unexpectedly the new light turns on at 4 in the morning.

If it's the latter then achieving the behaviour you want could be tricky because it would require the gateway/adapter to store brightness changes rather than passing them onto the adapter/device, and then only setting the brightness on the device once the user sets the on/off property.

Exactly. Buffering the desired brightness would be a work-around to have IKEA bulbs work the same as the others. A polyfill for a lightbulb, as it were.

Ultimately I think my instinct is that it shouldn't matter what entity requested a property to change via the API, the behaviour should always be consistent.

If a user understands this and desires this, is it 'inconsistent', or is it simply a feature?

It seemed useful enough to me to already experimentaly implement it. It was a small change where an internal message from a rule has an additional 'origin: rule' attribute, and all the other messages are unchanged. That's enough to have the Zigbee2MQTT addon buffer brightness changes from rules, but still allow the convenience of the "brightness change also turns it on" when a user changes explicitly.

I guess in my ideal scenario the rule system that would give users the ability to select 'was triggered by a human' as a condition. i.e. "If the brightness was changed by a human, then also turn the light on".

[benfrancis]

And when a color light bulb is off it should show it's color as black ;-)

Well yes :) I was just playing devil's advocate. I do actually think it's useful to be able to set the brightness independently of the on/off state if the hardware supports this.

If a user understands this and desires this, is it 'inconsistent', or is it simply a feature?

I don't think users should have to care about what happens at the API level.

It was a small change where an internal message from a rule has an additional 'origin: rule' attribute, and all the other messages are unchanged.

What do you mean by "internal message" here?

I guess in my ideal scenario the rule system that would give users the ability to select 'was triggered by a human' as a condition. i.e. "If the brightness was changed by a human, then also turn the light on".

I think that would get very confusing, and "triggered by a human" is not a simple objective statement which applies obviously to any device. A human could trigger a light to come on in various indirect ways like triggering a motion sensor or pressing an associated button, and when you extend that beyond lights it gets even more complicated. E.g. did a human trigger a smoke alarm by lighting a match under it?

I think the API just just behave the same regardless of what caused it to be called. Ideally brightness and on/off should be treated separately if the hardware supports that. In your example you could configure separate rules for time-based inputs and physical inputs like a button.

[flatsiedatsie]

I'm not even sure where to begin with addressing the miscommunication. Perhaps to put it more pragmatically: this discussion is about adding one word to the gateway-addon-node:

https://github.com/createcandle/gateway-addon-node/blob/a67981b8c0697a12fdef2c3e51caaa4dabcb1a85/src/property.ts#L197

from

setValue(value: T): Promise<T> {

to

setValue(value: T, meta?: Any): Promise<T> {

A change that should allow me to experiment with adding meta.origin (and meta.other_stuff) to the flow of messages between, say, the rule system and addons.

I was curious if you'd be more open to me upstreaming things that are useful for my experiments. Does it really matter if you agree with the concepts of those experiments?