Amazon Echo and ISY

[barrygordon]

Ross,

 

If the rc.local file is okay, then I suspect a permissions problem.

 

When looking at the echobridge directory (using WINSCP e.g.) what are the permissions (rights) and owners of the data and logs sub directories?

On my Pi the rights are rwxr-xr-x and the owner is root.  Also the owner of the jar file is root.

 

If you can send a screen snap of WINSCP when it is sitting at the /home/pi/echobridge directory that might also help.

 

I have attached  a sceenshot of mine

PI_2.bmp

[rossarmstrong]

I have done all my setup of my RPi as the user pi. I never logged in as root.

 

The echobridge folder and subfolder/files all were set with pi as the owner.

 

I logged in as root and set ownership to root, manually ran the full command and the HA-bridge was running. There was also a log81.txt file that was created and had data. However, nothing in the data folder.

 

I rebooted and hoped that all four listed in the rc.local file were start - no luck. None started.

 

I will email barrygordon my rc.local file to give it a QC check, but perhaps my problems are related to the fact I did all the setup and while remotely logged in as the normal user pi. Although I remember several of the steps I followed included commands with sudo.

 

I think we're getting close to solving this!! 

[barrygordon]

The data folder should have nothing until you run the configuration program and choose the ISY devices you want the bridge to have. 

 

It seems that for some reason your rc.local is not working.  I will look at it shortly.

 

There were errors in your rc. local.  I cleaned it up and emailed it back with an explanation.  I set it up to run only one emulator, as you had two instances set to the same ports.

 

Once that is working It will be trivial to make it run multiples.

[kck]

Barry,

Loaded up your new version.  Spoken names work fine for devices.  They don't seem to work for scenes though.

 

Unfortunately my bridges seem to have developed the problem other folks are seeing and are not longer appearing as Upnp devices on my network.  I can't think of anything I changed.  They start fine and so long as I give your utility the actual addresses of the bridges you can configure them fine.  Your utility won't find them though by searching and neither with my echo any longer.  They respond fine on the 8081 and 8082 ports (I'm running 2 bridges) but for whatever reason don't seem to be responding to upnp discovery.  I turned on upnp trace in the bridges and they seem to set themselves up or at least don't report any errors.  However, none of Echo, your tool, nor a small Upnp Discovery app seem to see the bridges.  There is something really strange going on here.

 

Edit to add:

It appears that the bridges are listening on port 1900 for udp6 (ipV6) packets but not for ipV4 udp packets.  I think it should be listening on both.  I get this from a netstat on the running RPi.  This would suggest that something is awry in the bridge code.  You seem to have a contact with the guy who has been developing that - can you pass this along to him?  I'm happy to do it myself or to do further debugging for him if needed.

 

Kevin

[barrygordon]

I just checked my system and I can find the emulators and/or the ISY fine using the uPnP search.  I suspect some sort of network issue.  Did you recently install windows 10?

 

I will add the same capability for scenes tomorrow, just didn't realize you could do it there too. I don't see it available for programs though.

[apnar]

Barry,

 

I've seen a few folks with issues with their rc.local files.  Thought I'd share this rework which may reduce some issues.  Nothing fancy, but changes a few things to cover issues some folks have run into including multiple instances on same port, data or log directories not existing, and starting before getting IP address from DHCP.  It also moves editable fields up into variables so they don't have to be changed more than once.  Anyway here it is for anyone that wants to give it a try:

#!/bin/sh -e

ISY_IP=192.168.1.10
NUMBER_OF_BRIDGES=3
BASE_PATH=/home/pi/echobridge
JAR_FILE=${BASE_PATH}/ha-bridge-0.4.9.jar

STARTING_PORT=8081
STARTING_UPNP_PORT=50001

DATA_PATH=${BASE_PATH}/data
LOG_PATH=${BASE_PATH}/logs

echo "Running the RC.local Bash script, Getting my IP address"
# check for valid IP by seeing which IP would be used for extenral traffic
IP=$(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}')
while [[ $IP != 192.168.* ]]
do
  sleep 1
  IP=$(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}')
done
echo "My IP address is $IP"

# Make directoris if they don't exist
[ ! -d ${DATA_PATH} ] && mkdir -p ${DATA_PATH}
[ ! -d ${LOG_PATH} ] && mkdir -p ${LOG_PATH}

echo "Starting the Echo Bridge Emulators"
for i in $(seq 1 ${NUMBER_OF_BRIDGES})
do
 nohup java -jar -Dvera.address=${ISY_IP} -Dupnp.config.address=${IP} -Dserver.port=${STARTING_PORT} \
   -Dupnp.response.port=${STARTING_UPNP_PORT} -Dupnp.device.db=${DATA_PATH}/device_${STARTING_PORT}.db \
   ${JAR_FILE} > ${LOG_PATH}/log_${STARTING_PORT}.txt 2>&1 &
 let STARTING_PORT=STARTING_PORT+1
 let STARTING_UPNP_PORT=STARTING_UPNP_PORT+1
done

#echo "Starting the tightvncserver, to handle SSL protocol for my skill 'Sarah'"
#/etc/init.d/tightvncserver start

echo "The RC.local Bash script has completed"
exit 0

[barrygordon]

apnar,

 

Nice!

 

By the way the echo comment 

#echo "Starting the tightvncserver, to handle SSL protocol for my skill 'Sarah'"

 

 

Should just be #echo "Starting the tightVNCserver to handle my PC as keyboard/mouse"

 

In my actual rc.local file I also start a program called stunnel which handles all ssl encryption for the endpoint to my Echo skill 'Sarah' which amazon requires. 

[apnar]

Barry,

 

I'm curious why you use a VNC server? What are you doing that you need a GUI for that you can't do via text through SSH?

 

Also, is "Sarah" a Eureka reference?

[kck]

Barry,

Figured that maybe you hadn't realized that scenes had spoken names also.

 

At the moment I am just stumped (and I am a pretty good networks guy since in a past life I developed this sort of stuff including some of the early UPnP specs).  I've been running your stuff on Win10 from the start and the bridges (and the emulator before that) on the RPi.  I didn't think I changed anything when I upgraded to your recent version today.  In thinking back, I think the upnp discovery was just gone when I started.  I had run your previous version without explicit IP address for the bridge so I know it was discovering upnp items at that point.  Now it just isn't.  I've turned on all the logging in the BWS code and nothing really looks amiss.  What I see on my RPi when I do a netstat -a is that there are 2 entries (I run 2 bridges) for listeners on port 1900 that show as "udp6".  I see no listeners for port 1900 that show udp.  If I look at network devices on my Win10 system I don't see the bridges  and I would have thought, but can't be sure, that they would appear there if they were being discovered (my Sonos devices appear there).  I also have a little free upnp discovery app on the Win system and it also doesn't see the bridges.  So it looks to me like there is something breaking in getting upnp set up.  It may well be something I am doing wrong but I just don't see it.  My suspicion is that there is some sort of subtle interaction between some particular aspect of some RPi configurations and the bridge code that is causing all this but I sure don't see what it could be.

[KMan]

Just want to say thanks to everyone who has contributed to this effort.  Got my Echo and ISY integrated over the weekend ... just the basics right now, but am looking forward to extending the functionality.  Wife was pretty tickled when she was able to turn lights on/off through the echo.

 

I followed the instructions posted by jackal in post 867 ... had a few bumps along the way, mostly with resurrecting my RPi (and my lack of Linux experience).

[apnar]

Barry,

Figured that maybe you hadn't realized that scenes had spoken names also.

 

At the moment I am just stumped (and I am a pretty good networks guy since in a past life I developed this sort of stuff including some of the early UPnP specs).  I've been running your stuff on Win10 from the start and the bridges (and the emulator before that) on the RPi.  I didn't think I changed anything when I upgraded to your recent version today.  In thinking back, I think the upnp discovery was just gone when I started.  I had run your previous version without explicit IP address for the bridge so I know it was discovering upnp items at that point.  Now it just isn't.  I've turned on all the logging in the BWS code and nothing really looks amiss.  What I see on my RPi when I do a netstat -a is that there are 2 entries (I run 2 bridges) for listeners on port 1900 that show as "udp6".  I see no listeners for port 1900 that show udp.  If I look at network devices on my Win10 system I don't see the bridges  and I would have thought, but can't be sure, that they would appear there if they were being discovered (my Sonos devices appear there).  I also have a little free upnp discovery app on the Win system and it also doesn't see the bridges.  So it looks to me like there is something breaking in getting upnp set up.  It may well be something I am doing wrong but I just don't see it.  My suspicion is that there is some sort of subtle interaction between some particular aspect of some RPi configurations and the bridge code that is causing all this but I sure don't see what it could be.

 

So the udp6 (and tcp6) is normal, I just checked my working install and netstat doesn't list anything for either udp or tcp, only the 6 ones.  I found this a bit odd as I can connect just fine to service via ipv4.  After a bit of digging I found that this is likely due to the use of IPv4-mapped IPv6 addresses in the servers network code.  It's a way for a dual-stack program to listen on both v4 and v6 without needing to use double work.  It's the first time I've seen it before but found examples of its use by Apache and EleasticSearch so it's not too uncommon.

[Big517]

Not sure if anyone else had this, but I was pulling my hair out for an entire day trying to get Barry's software to pick up the Server...  In the config file there are 4 server lines... for some reason after updating the software it would ONLY find whatever server was on LINE 2 of the server lists!  I copied exactly what was showing on line 1 to line 2

'192.168.X.X:8080-ISY
192.168.X.X:8080-ISY
'192.168.X.X:8083-SERVER3
'192.168.X.X:8084-SERVER4

I assume I did something wrong, but this fixed it and allowed Barry's software to FIND my server... 

You can also test if your server is running by pulling it up in the browser as 192.168.x.x:8080

[kck]

apnar,

Thanks for the udp6 info.  I hadn't seen that either.  Also thanks for the nice rc.local script - much cleaner and easier to maintain.  Further playing on my end last night saw continued weirdness that makes me think it is some larger network connectivity issue.  I switched my RPi over to wired and the (for a short while) Barry's configurator could search discover it.  So could the echo.  Now though Barry's program (on a wired Win10 box) again doesn't find it via discovery. Strangely the echo (on wireless of course) does still.  So it seems that something is messing with the upnp discovery traffic on my larger network.  Stumped but at least for the moment Echo control is back. When I get a change I will probably turn on debugging in the bridge and see if anything looks odd there with the new setup.  I really need to eventually get the RPi back on the wireless net for location reasons.  Sigh.  Feels like the sort of software debugging I last did about 25 years ago!

[kck]

Not sure if anyone else had this, but I was pulling my hair out for an entire day trying to get Barry's software to pick up the Server...  In the config file there are 4 server lines... for some reason after updating the software it would ONLY find whatever server was on LINE 2 of the server lists!  I copied exactly what was showing on line 1 to line 2

'192.168.X.X:8080-ISY
192.168.X.X:8080-ISY
'192.168.X.X:8083-SERVER3
'192.168.X.X:8084-SERVER4

I assume I did something wrong, but this fixed it and allowed Barry's software to FIND my server... 

You can also test if your server is running by pulling it up in the browser as 192.168.x.x:8080

 

Those single quote marks are "line ignores".  So lines 1, 3, and 4 are comments if that is actually what is in your config file.

[barrygordon]

Big517, 

 

As kck said a single quote in an ini file makes everything to the right of it on that line a comment. Different systems use different characters to mark the start of a comment. Windows ini files use the single quote. Just remove the single quote (') to un-comment the three lines if you want them to be active.

 

apnar,

 

No real reason for using VNC vs SSH, I have both available on my development machine (a PC), I am used to the graphic interface on the Pi.

 

Yes 'Sarah'  is from Eureka.  For those scratching their heads Eureka was an interesting (to some) show about a non-techie Sherriff in a town of Nerd/Geniuses. He lived in a fully automated house named S.A.R.A.H and when he wanted something he would ask or tell Sarah. the acronym stood for Self Actuated Residential Automated Habitat.  

 

Regarding uPnP discovery,

 

I am convinced that the people who have uPnP discovery issues have some network issue that will be extremely difficult to diagnose remotely. In my home the configuration system always successfully finds all instances of the HA Bridge and The ISY if I set it to do uPnP discovery in the ini control file. I set the ini paramater for 4 units to be discovered and 10 seconds of time to wait maximum.  

 

I do have to tell the Echo to discover devices more than once to cause it to find my current count of 93 devices spread over 4 HA Bridge instances. When I first started, the Echo would always discover all my devices (93 of them) in one pass. Now it takes 3 or 4 passes to do so.  I think that is an Amazon timing problem.

 

If anyone discovers what the uPnP problem is please post it in this thread..   

[Big517]

I completely understand that which is why I'm posting this...  The strange part is when the first line was un-commented it did not work.. .only until I used the same server on line 2 uncommented did it work.  

 

DID NOT WORK

192.168.X.X:8080-ISY
'192.168.X.X:8080-ISY
'192.168.X.X:8083-SERVER3
'192.168.X.X:8084-SERVER4

WORKED

'192.168.X.X:8080-ISY
192.168.X.X:8080-ISY
'192.168.X.X:8083-SERVER3
'192.168.X.X:8084-SERVER4

Seemed strange, but might be a small bug..

[barrygordon]

As an aid to non-linux experts (90% of us including me) I will try and explain what the ending text in the rc.local startup line means:

. . . /home/pi/echobridge/ha-bridge-1.2.1.jar > /home/pi/echobridge/logs/log81.txt 2>&1 &

 

The sequence (space)>(space) after the command to start the HA Bridge calls for a redirection of the output of the invoked process (/home/pi/echobridge/ha-bridge-1.2.1) into the file named '/home/pi/echobridge/logs/log81.txt'. If the file does not exist it is created. The directory '/home/pi/echobridge/logs' must exist. Normally the output would go to the standard output device (generally the terminal screen).

 

The sequence (space)2>&1(space)  causes the standard error output to be redirected to the the standard output in the Bourne shell.  The rc.local file is a Bourne shell script so it is running in the Bourne shell.  We have already directed the standard output to a file so the net effect is that both the standard output and the standard error output locations are now the named file.

 

The final sequence (space)& causes the command (the invocation of an instance of an HA Bridge) to be run in the background so the rc.local is not held up and continues while the command is executed. The command to start the bridge is run in the background, not the bridge itself.

 

How do I know that?   "Every man has the will to know and the wit to learn, but the key to knowledge is the open book". When it comes to Linux my "book" is " The complete reference LINUX 4th edition" by Richard Petersen, Osborne publisher.  I just looked up the section on redirection, pages 234-239.  I have a whole shelf of reference books on the wall above my desk. I am much older than the Internet, and many of my books are just as old.

[barrygordon]

Big517,  

 

I can not reproduce your problem. Could you email me your ini file which does not work. I want to look at it with a hex editor.

[switzch]

Thanks to everyone who got this working. I setup a new echo over the weekend with Barry's tool and I am now controlling everything on my ISY with voice commands.  Works insanely well and the wife is loving it.  We are living in the future!

 

For those setting up for the first time, here are a few things I noticed (probably very obvious for most).

- In the setup tool, for IP address of emulator, if you are running the emulator locally (i am not using rpi yet) use 127.0.0.1:8080 (not 192.168 <-whatever the actual IP is of the PC)

- The setup instructions on the very first post of this thread work fine but use Barry's config tool (vs. g1of4's which as of writing this does also work)

 

Still need to figure out a few things:

- How to have it work with "Alexa Watch TV" vs. "Alexa Turn on TV" (maybe its a limitation of the emulator in that you have to say ON/OFF as a command.

- Also dimming commands "Alexa set Kitchen Lights to 50%"

- Run the emulator on RPi

[barrygordon]

The Amazon system (Alexa/Echo) has a specific vocabulary. Watch is not a legal verb. Generally since we are emulating a HUE Hub which only controls lights you are limited in the Alexa vocabulary to 'Turn on', 'Turn off'.  A synonym for 'Turn off' is 'Shut the'.

 

To dim a light the correct utterance is

'Alexa dim the <friendlyname> to <XX> percent'   e.g. 'Alexa dim the office lights to 50 percent'.  Set does not work as a command.

where XX is a number between 1 and 99. 

 

Hope that helps

[Big517]

I have noticed that I cannot "TURN ON" a dimmable light.. I have to say "Alexa "brighten" device"

[KMan]

I have noticed that I cannot "TURN ON" a dimmable light.. I have to say "Alexa "brighten" device"

 

I had the same problem on 2 switchlincs (all that I've tried so far) ... but they both started working after I told them to brighten to 100 (didn't try anything else before 100).  Working means that "Turn on" now works for both of them.

[jackal]

A small tip:  Currently amazon echo only allow 2 wake keywords:   "Alexa" and "Amazon".  However, I discovered that "Lexa" keyword worked equally well. For everyone who wants to shorten the echo command.

[barrygordon]

Echo is getting confused, hearing Lexa as Alexa. Serendipity!

[barrygordon]

This is for UDI ISY users that are using HA Bridge version 1.2.1 from BWS Systems and have the Harmony features turned on.

 

There seems to be a problem where communications between my configuration program and that version of the HA Bridge emulator regarding retrieving the harmony version, devices and activity is not working.  

 

HA Bridge versions 1.0.8 and 1.1.0 are both working So I suspect an error has cropped up in the Bridge or I have missed a protocol change.  

 

I am in contact with BWS Systems to get this resolved.  

 

This has nothing, to my knowledge, to do with the issue of the Echo not finding the HA Bridge(s); although I suspect that problem to be related to a network issue in the LANs that are not allowing discovery.  On My LAN the Echo discovers all devices defined in the bridge(s) but may need several passes to do so.

 

Also on my LAN The AWS configuration system is able to find all instances of the HA Bridge and the location of the ISY with a uPnP search; so I suspect that may also be related to a LAN issue. A google of the web with regard to uPnP search problems might shed some light.