how to not send a on command hen send dim command via alexa?

[MattL0]

Incomprehensive message from me . Sorry can't delete it

[MattL0]

this is what is received when the light is off and A dim command is sent to alexa. So when i dim the light when it was off... it goes to 100 first... then go to the desired dim level ... I have not been able to deal with this issue .

msg : Object
object
on: true
bri: 39
hue: 0
sat: 254
ct: 199
colormode: "ct"
meta: object
insert: object
input: object
on: true
changes: object
on: false
rgb: array[3]
percentage: 15
payload: "on"
deviceid: "69a0d9b9f9df28"
topic: ""
_msgid: "55777948.84c038"
06/10/2019 à 20:48:02node: b86b1da5.087d2

msg : Object
object
on: true
bri: 39
hue: 0
sat: 254
ct: 199
colormode: "ct"
meta: object
insert: object
input: object
bri: 39
changes: object
empty
rgb: array[3]
percentage: 15
payload: "on"
deviceid: "69a0d9b9f9df28"
topic: ""
_msgid: "ff9c1a51.ee8968"

[Barabba11]

You can do it by functions

[MattL0]

Ok that will be project tonigh...lol

Do you know a starting point? How to I identify each message in a variable?

I do not see anything i can work with to identify ( (i mean discriminate))those two
Messages

Thanks

[AZDane]

Would be nice if it was passed as a parameter if Alexa was told on/off, Bri or Color.
I migrated from node-red-contrib-alexa-local and it had a Boolean msg.on_off_command which was useful.
node-red-contrib-alexa-home has a msg.payload.command = "switch|bri|color"
Would be extremely nice if something similar could be implemented for node-red-contrib-amazon-echo
If you search for msg.payload.command here it shows their implementation:
https://github.com/mabunixda/node-red-contrib-alexa-home/pull/22/files

[Barabba11]

Be sure you have 1.9 installed, use debug mode, tell Alexa the 2 commands, look deep in debug window, open sub objects like meta. Good work )

[AZDane]

I already did, but it is painful to retrieve what I want. I would have to make a function that compares "input object" with "changes object" and "on object". It would be much easier to implement in the code for the node.
It is very useful info to know. I use it all the time.
A command object that indicates if it was switch, brightness or Color would be super helpfull

[datech]

@AZDane
I'm not sure why you have to compare objects, as the "meta.changes" attribute is already containing changed states.

If you want to check based on the input command, you can use meta.input attribute.

If you want to check only when the state is changed, you can use meta.changes attribute.

Check the following example:

Alexa, turn off the bedroom light

meta.input: { on: false }
meta.changes: { on: true }

Alexa, turn off the bedroom light

meta.input: { on: false }
meta.changes: { }

Notice that after the second "turn off" command "meta.changes" hashmap is empty because the "on" state is not changed and it is still equal to "false".

[AZDane]

Because in my case, Home Assistant and Not Alexa is managing my states. So I can easily have some devices that have a different states than my Alexa think they have.
So its important for me to see that Alexa is given an on command and not a bri command even though she already thought the state was on.
Hope that makes sense.

[datech]

Indeed, Alexa's command (input) sent to the hub is stored without any modifications to "meta.input" hashmap.

[AZDane]

Yes, so if I tell Alexa to turn bedroom light on I will get
meta.changes: { on: true }
But if I turn it off in Home Assistant and then back on via Alexa, I get:
meta.changes: { }
So no way of telling that the trigger was an ON command.

[AZDane]

Would it not be possible to include the called property using something similar to what node-red-contrib-alexa-home does with the msg.payload.command = "switch|bri|color"

   // set color 
        if (msg.payload.xy) {
            RED.log.debug(this.name + " - Setting values on xy: " + msg.payload.xy)
            node.setConnectionStatusMsg("blue", "xy: " + msg.payload.xy);
            msg.payload.command = "color";
        }
        //Dimming or Temperature command
        if (msg.payload.bri) {
            RED.log.debug(this.name + " - Setting values on bri");
            msg.payload.on = msg.payload.bri > 0;
            msg.payload.command = "dim";
            node.setConnectionStatusMsg("blue",
                "bri:" + msg.payload.bri
            );
        }
        //On/off command
        else {
            RED.log.debug(this.name + " - Setting values on On/Off");
            var isOn = false;
            if (typeof msg.payload === "object") {
                isOn = msg.payload.on;
            } else {
                if (typeof msg.payload === "string") {
                    isOn = msg.payload === "1" || msg.payload === "on";
                } else if (typeof msg.payload === "number") {
                    isOn = msg.payload === 1;
                } else {
                    node.setConnectionStatusMsg("orange", "could not process input msg");
                    return;
                }
                msg.payload = {};
            }
            msg.payload.on = isOn;
            msg.payload.bri = isOn ? 255.0 : 0.0;

            if (msg.payload.xy == undefined) {
                msg.payload.command = "switch";
                //Node status
                node.setConnectionStatusMsg(
                    "blue",
                    (isOn ? "On" : "Off")
                );
            }

[datech]

"if I tell Alexa to turn bedroom light on I will get
meta.changes: { on: true }"

You will havemeta.changes: { on: true } only if the current "on" state is "false". So, the command that will trigger this change has to be turn off, not turn on

changes - Hashmap of all changed attributes and the corresponding old values

I believe in your case, it is better to use meta.input, because meta.changes is generated based on the previous state of the object stored in the hub.

[datech]

Commands are already included in the payload.

Switch command is when you have "on" key in meta.input
Dim command is when you have "bri" key in meta.input
Color change command is when you have "x" or "sat" key in meta.input

[AZDane]

Yes, you are right :) Sorry. it was late when I initially looked at this last night.

[datech]

BTW, I don't think it is a good idea to include command attribute in the payload (that's why we don't have it), because you may have multiple state changes if the input payload is sent directly to the hub without using Alexa.

Example:

{
  on: true,
  bri: 100,
  x: 0.123,
  y: 0.456
}

In this particular example, we have switch, dim, and color change commands.
So, the command is unknown or maybe "all I can do with this bulb" :)

[AZDane]

datech,
I see know what confused me yesterday. If I go from an off state to a brightness command I receive two objects. First one has input.on:true and the next has input.bri: 102
Is that expected behavior to get two objects? It complicates my flow a bit.

[datech]

Yep, that's how exactly Alexa is working when "on:false" and brightness is changed. Two separate commands will be sent to the hub:

• { on: true }
• { bri: <number> }

[AZDane]

hmmm. ok. Have to rethink how I will handle that one. Doesn't seem very smart in a flow based system like Node-red.

Alexa-local only forwarded one, so you only triggered the flow one time. Any recommendations on dealing with two objects? Will the on: true always arrive first? I need to drop the first one if there are two.

[AZDane]

datech,

So even if two separate commands are send to the hub, wouldn't it make sense to just forward one combined for the purpose of Node-red?

[datech]

I suppose that the logic is that you cannot change the brightness if the device is not turned on. So, I've tested it a few times before, and "on:true" is always the first command.

I prefer not to mess up with Alexa's logic. We have the same case when the color is changed, and "on" is set to "false". Alexa will send two commands:

• { on:true }
• { hue:7100, sat:254 }

[AZDane]

Would be nice if there was a way to indicate in the first package that its part of more commands.
My problem is that I use this to control my sun shades. I have logic to run the motors for a certain amount of time depending the percentage. If just on/off they have limit stops.
Now I have to find a smart way to always delay on/off packages so I receive the Brightness package first and then use a Throttle node to drop the second package :)

[datech]

I've just tried Delay node with following options:

• Action: Rate limit
• All messages
• 1 message per 1 sec
• drop intermediate messages selected

[AZDane]

Yes, but it's the second package thats interesting. I did however figure out how to receive the Bri package first and then drop the second package.

1. Switch node to see if msg.meta.input.bri is of type number
2. if it is send it straight to throttle node only allowing 1 message pr second (or your suggested delay)
3. if it isn't delay the message 200ms and the send it to the same throttle node.

[AZDane]

[Barabba11]

really interesting here, I haven't noticed myself Alexa sent 2 messages if she thinks it was off. I would suggest you to create a function and if Alexa incoming message is on you forward it again to the same function by a delay module, adding a flag that is was forwarded. Now if a second message is incoming with bri then you send a reset to the delay node, so the incoming delayed forwarded module will be discarded and never come back. If you receive the forwarded message you will send it as a good one and not to de dealy node. The question is just to set a proper time to the delay that in any case the second message can come after that. I suppose 200ms can be enough to be sure the bri already came.

The function can be something like this: (the function should have 2 outputs, on the second connect the input delay node, and connect the output of delay node to the input of the function)

`if (msg.meta.bri!==undefined) {msg2= {reset:1}, return [msg,msg2];

//help me to correct it, haven't test it yet, I suppose the meta contains the command, can't find a detailed example in the issue threads

forwarded=msg.forwarded || false;
if (forwarded===true) {msg2= {}, return [msg,msg2];} else { msg2=msg; msg={};}`

[datech]

I consider this issue as resolved.

For reference
here is a simple flow with limit rate delay node and drop. (same as the flow provided by @AZDane, just the throttle node is replaced with another delay node. So, it might be utilized in situations where throttle node is not installed or needed)

[MattL0]

Thanks all ! totally works !

[
{
"id": "74cd11bc.04453",
"type": "switch",
"z": "26c8e14a.1a10de",
"name": "",
"property": "meta.input.bri",
"propertyType": "msg",
"rules": [
{
"t": "istype",
"v": "number",
"vt": "number"
},
{
"t": "else"
}
],
"checkall": "true",
"repair": false,
"outputs": 2,
"x": 252.5,
"y": 144.6666717529297,
"wires": [
[
"10a9a0b1.7bc31f"
],
[
"7478d5c0.e171cc"
]
]
},
{
"id": "623c36b2.19bd68",
"type": "debug",
"z": "26c8e14a.1a10de",
"name": "",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "true",
"targetType": "full",
"x": 571.5,
"y": 309,
"wires": []
},
{
"id": "7478d5c0.e171cc",
"type": "delay",
"z": "26c8e14a.1a10de",
"name": "",
"pauseType": "delay",
"timeout": "200",
"timeoutUnits": "milliseconds",
"rate": "1",
"nbRateUnits": "1",
"rateUnits": "second",
"randomFirst": "1",
"randomLast": "5",
"randomUnits": "seconds",
"drop": false,
"x": 379.50000762939453,
"y": 207.66670036315918,
"wires": [
[
"10a9a0b1.7bc31f"
]
]
},
{
"id": "10a9a0b1.7bc31f",
"type": "delay",
"z": "26c8e14a.1a10de",
"name": "",
"pauseType": "rate",
"timeout": "200",
"timeoutUnits": "milliseconds",
"rate": "1",
"nbRateUnits": "1",
"rateUnits": "second",
"randomFirst": "1",
"randomLast": "5",
"randomUnits": "seconds",
"drop": true,
"x": 477,
"y": 133,
"wires": [
[
"623c36b2.19bd68"
]
]
}
]