brightness problem with light node

[gerrieg]

Hi @andrei-tatar

I think there is a problem with the light node. When i say 'livingroom 50%', the message from the light node is: {"on":false,"brightness":50}

"on": false is wrong, because the switch in the google home app is on with 50% brightness. It should be: {"on":true,"brightness":50}

If i disable the complete state as payload in the node, the payload is always 0.

I also tried the light with openhab (via myopenhab.org) and there it works when i say 'livingroom 50%'.

Thanx for your great work!

[andrei-tatar]

I think this is because you can actually change the brightness while the device is off. At least that's what I understood. Don't think it's an issue in NORA but I will have another look.

When I say "set the light brightness to 50%" when the light is off and check google home, the light is still off, but the brightness slider is at 50.

[gerrieg]

I think this is because you can actually change the brightness while the device is off.

I think you are right, when i say the command, the switch in google home is off and the brightness is set. But when i manually drag the slider in the app, the switch jumps to on and the NORA message is still "on":false I only get the message "on":true when i touch the switch in the app. Can you confirm that?

[Chrischi-]

if google's behavior is so intended, why not just change it yourself? for example if someone says "brightness to 50%" then his intention was to turn on that light. Just like the app does when you move the slider. So just look at the msg if the brightness was transmitted/changed and then turn on the light, change the brightness and set the status backwards. So the app always shows the right status. I hope you know what I mean...

[andrei-tatar]

@gerrieg yes, same happens for me.

@Chrischi- I would rather stick with the default behavior and let users customize their own cases. You can just add a function node right after the output that checks if brightness changed and on is false => on = true.

[Chrischi-]

@andrei-tatar That's what I meant. I spoke from the users point of view and not from your point of view. Somewhat stupidly described but we hold the same opinion.

[GravityRZ]

@andrei-tatar i noticed this behaviour also but did not have problems with it in node-red now with the color implementation it is much more noticable.

indeed when you change brightness and the light is off it stays off the same goes for color now, you can change colors but the light stays off

i checked with siri behaviour ans siri DOES switch on the light when you change either brightness or color. i am trying to get things to work with functionnodes but since there are a lot of different situations this is not easy(yet)

to make it more complicated i sync my status with domoticz but i noticed domoticz is not capable of sending out the exact color settings through MQTT. At the moment i am using a HTTP request to the hub to get the status in and make a put http request to save the new value.

agreed we should stick with the standard but what exactly is that standard because Siri is doing things different(more logical)

[Chrischi-]

perhaps it might be better not to publish the whole payload and only the changed values. So the logic behind it (eg. node-red flow) can take place correctly.

I think I remember gBridge doing the same thing.

[GravityRZ]

i just checked and can solve a lot with a function which both checks hue and brightness changes. this however only works when you change to something different eg when the light is off and color is white and i give a command to change to blue it switches on and turns to blue. howevr when i switch off the light and try to do it again it does not work anymore(because the light is allready set to blue and the brightness is the same)

i think we need Nora to send the payload whenever it receives a command FROM GOOGLE now it only sends the payload when it senses a difference please check. google is reacting everytime it gets the same command. Nora howevr does not send out the payload every time so there is no way to act on a status which is not send out. @Chrischi
i rather always receive the complete payload so i can decide what to do with it. HUE also behaves like this.

like i said, if we receive the nora payload whenever google does something with the device i think we can do everything with scripting the way we want it.

The old google perception was that whenever a light was already on you could not turn it on again. Google realised that the world does not revolve around Google and they let this go.

now you can give the same command twice(very handy when you changed the device status by using another program)

[andrei-tatar]

@GravityRZ https://github.com/andrei-tatar/node-red-contrib-nora/issues/35#issuecomment-563297443

[GravityRZ]

Thanks Andrei. working(that is what you get when thinks work so good you never bother to check the config node anymore :-) )

[GravityRZ]

everything is working . i check against a flow variable oldhue and old brightness. if either of those are different the light will still switch from off to on when you have changed brightness/color.

ofcourse when you turn the lights to blue, turn them off and try to turn them back on with the same voice command it will not work because nothing has changed to accomplish this i use a get command to get the status of all the lights in 1 call. when a google light is triggered i check against those numbers.

[Dud3z]

@andrei-tatar why not just make a checkbox and let the user decide in the node if he wants to turn on the light with the changes of brightness. for me, as iam a heavy user of the google home app, it is very counterintuitive to turn on the light and after that change the brightness. The app does that right after i changed the brightness by itself. dont know how the other users are keeping track of their flows but i want mine as simple as possible and adding functions or change nodes only blows up the flows.

[tanker11]

Added a like to https://github.com/andrei-tatar/node-red-contrib-nora/issues/33#issuecomment-568323095 as I think countermeasures lead to too many nodes and functions for such a simple need. And having a bigger project with many dimmers would lead to a mess.

[andrei-tatar]

Should be fixed in versions >= 0.0.32 Added a new checkbox for each light node (Turn on when brightness changes)

[GravityRZ]

@andrei-tatar are you sure this will fix it It could also be that the color changes bit thr brightness stays the same

[andrei-tatar]

I only fixed it for brightness... will add a fix for color. The checkbox will be the same (probably with a different wording).

[andrei-tatar]

@GravityRZ the service should be updated... wording in the plugin will be updated with next version release.

[GravityRZ]

@andrei-tatar

just tested 0.0.32

Light in OFF position command :set brightness to xx % Result: light goes on to xx% old fuctionality(brightness would change but since the status was still false it did not switch on)

i also tested color change

Light in OFF position command :set light to color blue Result: light goes on in the color blue

switch light off command :set light to color blue Result: light goes on in the color blue

so it looks like you not only fixed the light switching on when changing the brightness but it also switches on when changing the color. what's best is it does so even when you turn the light off and give it the same command to switch on with the same color and brightness

i only did a couple of quick tests but it looks like you do not need to implement the color change anymore.(unless you had other functionality in mind)