node-red-contrib-alexa-home icon indicating copy to clipboard operation
node-red-contrib-alexa-home copied to clipboard

Published 20 hours ago • verified publisher icon mabunixda

msg.alexa_ip return only "undefined"

Open Sylvan86 opened this issue 2 years ago • 2 comments

description

According to the documentation, the value msg.alexa_ip should return the ip-address of the echo device with which the communication takes place. In my case, however, this value is always "undefined"

reproduce the bug

I use the following docker-compose.yml to run the official node-red docker image:

version: '3.5'

services:
    node-red:
        image: nodered/node-red:latest
        user: root
        environment:
            - TZ=Europe/Berlin
        network_mode: "host"
        expose:
            - "80"
            - "1880"
            - "60000"
            - "3456"
            - "3457"
            - "4200"
        cap_add:
            - NET_ADMIN
        restart: unless-stopped
        volumes:
            - "./data:/data"

Install the alexa-home node and import the following flow:

[{"id":"a3a36b639a1f161f","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"49d9268d0f834e76","type":"alexa-home-controller","z":"a3a36b639a1f161f","controllername":"Alexa Controller","port":"80","maxItems":"100","x":150,"y":100,"wires":[]},{"id":"4081cfc7081758f9","type":"alexa-home","z":"a3a36b639a1f161f","devicename":"my device","devicetype":"Dimmable light","x":120,"y":160,"wires":[["cb4fc616c3dfdec6"]]},{"id":"cb4fc616c3dfdec6","type":"debug","z":"a3a36b639a1f161f","name":"complete msg (incl. \"alexa_ip\")","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":450,"y":160,"wires":[]},{"id":"ccf946af24cf46d3","type":"catch","z":"a3a36b639a1f161f","name":"","scope":null,"uncaught":false,"x":120,"y":220,"wires":[["b570457416cd7e69"]]},{"id":"b570457416cd7e69","type":"debug","z":"a3a36b639a1f161f","name":"debugging","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":390,"y":220,"wires":[]}]
  • Let the echoes find the device.
  • Send an (on/off) command to the alexa-home device via Alexa.
  • The message should now appear in the debug tab.
  • The field msg.alexa_ip should take the value "undefined".
  • There is no relevant entry in the logs.

Expected behavior

I hoped to find the ip address of the echo device with which I communicate to identify the device in the flow. This would create completely new application possibilities. For example, with the single command "raise shutter" I could either raise the shutter in the kitchen or in the bathroom, etc., depending on where I am.

Screenshot

drawing

Environment

  • Alexa devices where the behaviour occurs: Echo Dot 2, Echo Dot 3, Echo Dot 4, Echo Plus 2, Echo 2, Echo 3, Echo 4
  • Node-RED version: v2.2.2
  • Node.js version: v14.18.2
  • Running in docker container (for configuration see above)
  • Linux 5.16.1-1-aarch64-ARCH arm64 LE on a raspberry pi 4B 4GB

Sylvan86 avatar Jul 11 '22 07:07 Sylvan86

Ok - can you turn on debugging by following: set an env variable DEBUG to node-red-contrib-alexa-home:

version: '3.5'

services:
    node-red:
        image: nodered/node-red:latest
        user: root
        environment:
            - TZ=Europe/Berlin
            - DEBUG=node-red-contrib-alexa-home
        network_mode: "host"
        expose:
            - "80"
            - "1880"
            - "60000"
            - "3456"
            - "3457"
            - "4200"
        cap_add:
            - NET_ADMIN
        restart: unless-stopped
        volumes:
            - "./data:/data"

This will add a lot of output but there should also an output of this line.

The actual alexa IP is defined within this code

But as far as my observation on this is at the moment - the alexa devices use a kind o mesh networking with a leader which controls the communication. If you are able to find any information about HTTP headers or whatever to detect which alexa device was starting the workflow - that would open new flows and ease many things

mabunixda avatar Jul 11 '22 10:07 mabunixda

Damn you are fast! I inserted the debug variable as described and then completely restarted the container.

I then completely reloaded the flow, let the device search again, and then sent an "on" command to the device. Meanwhile, I ran a tcpdump on port 80 and output it to a pcap file for Wireshark, which I uploaded here: alexa_home_tcpdump.zip

The Echo device that gave me the audiovisual feedback to confirm my command was the device with IP 192.168.0.110.

I have also attached the node red log which I get via "docker compose logs": alexa_home_debug.log I could not detect the line mentioned. The log level in the settings.js is set to "debug".

The web-based Node-Red debug log gave me the following info on the msg for my command: drawing

Sylvan86 avatar Jul 11 '22 11:07 Sylvan86

Anything new on this topic?

stereodruid avatar Sep 27 '22 13:09 stereodruid

@stereodruid well there should be an ip address , that code did not get any updates. On my deployment behind a reverse proxy I get an IP address reported. There is a need that somebody who is running nodered without a reverse proxy evaluates this code fragement

mabunixda avatar Sep 27 '22 13:09 mabunixda

@stereodruid please check with version 2.0.1 from my experience there is always a leader node that does the communication. If anybody finds more about properties which device was requesting/interacting - please update this issue!

mabunixda avatar Sep 27 '22 16:09 mabunixda

Thanks for your replay. I will look in to it.

stereodruid avatar Sep 28 '22 13:09 stereodruid

@stereodruid please check with version 2.0.1 from my experience there is always a leader node that does the communication. If anybody finds more about properties which device was requesting/interacting - please update this issue!

Hi mabunixda, after installing 2.0.2, alexa lost connection to my NR nodes. A new alexa device discovery returns 0 new devices. I deleted all nodes and created new ones. I also deleted all devices from my alexa. Still alexa isn't able to discover any devices created in node red. After rolling back to 2.0.0. everything works fine again. Sadly, no error log available because there haven't been any errors. Im using node red in a ioBroker. ioBroker runs in a VM(Ubuntu server) VM is hosted on a Proxmox server. If i can help or if you need more information, let me know.

stereodruid avatar Sep 28 '22 18:09 stereodruid

@stereodruid please check with version 2.0.1 from my experience there is always a leader node that does the communication. If anybody finds more about properties which device was requesting/interacting - please update this issue!

Hi mabunixda, after installing 2.0.2, alexa lost connection to my NR nodes. A new alexa device discovery returns 0 new devices. I deleted all nodes and created new ones. I also deleted all devices from my alexa. Still alexa isn't able to discover any devices created in node red. After rolling back to 2.0.0. everything works fine again. Sadly, no error log available because there haven't been any errors. Im using node red in a ioBroker. ioBroker runs in a VM(Ubuntu server) VM is hosted on a Proxmox server. If i can help or if you need more information, let me know.

I ment 2.0.1.

stereodruid avatar Sep 28 '22 18:09 stereodruid

@mabunixda How can I debug/monitor this?

stereodruid avatar Sep 29 '22 08:09 stereodruid

There should be an information also on info log level like this

29 Sep 14:21:53 - [info] [alexa-home-controller:Alexa Controller] 0 - alexa-home - Starting SSDP
29 Sep 14:21:53 - [info] [alexa-home-controller:Alexa Controller] 0 - announcing location is http://...

Can you run http://$your-vm-ip:$alexa_hub_port/setup.xml and afterwards with the referenced location from the log line ( if not the same )

alexa_hub_port can either be the node-red port, when running in proxy mode, otherwise the configured port from the controller node.

You can set the log level to DEBUG and then you should also find the information about communication.

mabunixda avatar Sep 29 '22 12:09 mabunixda

#119 Im getting the same error: TypeError: alexaHome.AlexaIPAddress is not a function at /opt/iobroker/iobroker-data/node-red/node_modules/node-red-contrib-alexa-home/alexa/alexa-hub.js:59:39 at Layer.handle [as handle_request] (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:328:13) at /opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:346:12) at next (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:280:10) at Layer.handle [as handle_request] (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/layer.js:91:12) at trim_prefix (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:328:13) at /opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:346:12) at next (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:280:10) at jsonParser (/opt/iobroker/iobroker-data/node-red/node_modules/body-parser/lib/types/json.js:110:7) at Layer.handle [as handle_request] (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:328:13) at /opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:346:12)TypeError: alexaHome.AlexaIPAddress is not a function at /opt/iobroker/iobroker-data/node-red/node_modules/node-red-contrib-alexa-home/alexa/alexa-hub.js:59:39 at Layer.handle [as handle_request] (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:328:13) at /opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:346:12) at next (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:280:10) at Layer.handle [as handle_request] (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/layer.js:91:12) at trim_prefix (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:328:13) at /opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:346:12) at next (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:280:10) at jsonParser (/opt/iobroker/iobroker-data/node-red/node_modules/body-parser/lib/types/json.js:110:7) at Layer.handle [as handle_request] (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:328:13) at /opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/opt/iobroker/iobroker-data/node-red/node_modules/express/lib/router/index.js:346:12)

stereodruid avatar Sep 29 '22 19:09 stereodruid

Yeah - kinda strange, but version 2.0.2 fixxes that problem

mabunixda avatar Sep 30 '22 07:09 mabunixda

Yeah - kinda strange, but version 2.0.2 fixxes that problem

Hey @mabunixda, i can confirm, device ip is now provided, runs as expected so far. I think @Sylvan86 can close this issue. God job, Thanks.

stereodruid avatar Sep 30 '22 10:09 stereodruid

@mabunixda on more question, would it be also possible to get the deviceSerialNumber or macAddress? It is nice to have the IP, but the ip is not reliable enough do to the ip can change.

stereodruid avatar Sep 30 '22 10:09 stereodruid

Yeah - kinda strange, but version 2.0.2 fixxes that problem

Hey @mabunixda, i can confirm, device ip is now provided, runs as expected so far. I think @Sylvan86 can close this issue. God job, Thanks.

Sorry after testing it with other alexa devices, i noticed that the ip is alway the same no matter what Alexa device i use.

stereodruid avatar Sep 30 '22 11:09 stereodruid

@mabunixda what i found out is that the ip provided is always that of my Echo plus wich has a hub integrated.

stereodruid avatar Sep 30 '22 12:09 stereodruid

@mabunixda what i found out is that the ip provided is always that of my Echo plus wich has a hub integrated.

If i turn of my Echo Plus the behavior is the same but the ip is a changed to another echo device and remains the same. NodeR info line: 30 Sep 13:06:21 - [info] [debug:debug 4] { username: 'removed', payload: { on: true, bri: 254, command: 'switch', bri_normalized: 100 }, alexa_ip: '192.168.178.35', change_direction: 0, device_name: 'Leinwand', light_id: 'b96586b8acccd6ce', _msgid: 'removed'}

stereodruid avatar Sep 30 '22 13:09 stereodruid

Yeah - that seems to be the implementation of the alexa devices of a single account, that these devices create a kind of swarm and select a leader which does all the communication. Sadly there is no more information available - even on the headers that are included on a single request. And the mac address is not available on such a HTTP request

mabunixda avatar Sep 30 '22 13:09 mabunixda

Yeah - that seems to be the implementation of the alexa devices of a single account, that these devices create a kind of swarm and select a leader which does all the communication. Sadly there is no more information available - even on the headers that are included on a single request. And the mac address is not available on such a HTTP request

Hmm, im not so sure about this. have a look at this outputs:

30.9.2022, 19:26:29[node: debug 4](http://192.168.178.29:1880/#)
msg : Object
{ username: "c6260f982b43a226b5542b967f612c…", payload: object, alexa_ip: **"192.168.178.25"**, change_direction: 0, device_name: "Licht" … }
30.9.2022, 19:26:34[node: debug 4](http://192.168.178.29:1880/#)
msg : Object
{ username: "c6260f982b43a226b5542b967f612c…", payload: object, alexa_ip: **"192.168.178.35"**, change_direction: 0, device_name: "Leinwand" … }
30.9.2022, 19:26:39[node: debug 4](http://192.168.178.29:1880/#)
msg : Object
{ username: "c6260f982b43a226b5542b967f612c…", payload: object, alexa_ip: **"192.168.178.49"**, change_direction: 0, device_name: "Computer" … }

So the behavior is strange. I used the same echo for all commands. It dos not matter wich echo i speak to, when i say:

turn on "Leinwand" it uses this ip:192.168.178.25 turn on "Licht" it uses this ip:192.168.178.35 turn on "Computer" it uses this ip:192.168.178.49 The result is always the same.

What Whireshark cptured for "Licht": [{"topic":"status/ca05e505da27ac27","data":{"text":"On","fill":"blue","shape":"dot"}},{"topic":"debug","data":{"id":"5dc66ecc4481e7c5","z":"94c4242c8a9ec666","path":"94c4242c8a9ec666","name":"debug 4","msg":"{"username":"c6260f982b43a226b5542b967f612ce","payload":{"on":true,"bri":254,"command":"switch","bri_normalized":100},"alexa_ip":"192.168.178.25","change_direction":0,"device_name":"Licht","light_id":"ca05e505da27ac27","_msgid":"84b40b7a5b67fd7a"}","format":"Object"}},{"topic":"status/0255662fbc4e181a","data":{"text":"broadlink2.0.RM:Broadlink-RMPROPLUS-c7-c8-4d.L.LichtAn: [object Object]","fill":"green","shape":"dot"}}]

stereodruid avatar Sep 30 '22 17:09 stereodruid

Yes the bug is fixed with version 2.0.2 for me. Unfortunately the result is not the hoped for, but this is not due to the alexa-node.

In my case, the IP is also sent from the most inconvenient Alexa.

Thx for fixing!

Sylvan86 avatar Oct 05 '22 15:10 Sylvan86