From your squeezealexa
directory,
bin/local_test.py
This assumes you have Python. You can run this more explicitly (e.g. on Windows):
python bin/local_test.py
Note, you may need to specify python3
on systems with both Python 2 and 3 installed.
local_test.py
can now diagnose some common connection problems 😄
This should connect with your settings as per settings.py
. The latest diagnostics can help you find the root cause of many common connection / certificate problems (but not 100% accurate).
Some examples of how this can happen are included in the tests.
🆕 Note that in versions 1.2+, squeeze-alexa
will attempt to get Alexa to respond in semi-English text / cards.
A bit HAL-9000, but it's quicker than checking Cloudwatch logs 😄
You can disable this by changing USE_SPOKEN_ERRORS
to False
in your settings.
If everything is installed and the connectivity working, but your Echo is saying "there was a problem with your skill" or similar, try checking the Cloudwatch logs (note there's a delay in getting the latest logs). The squeeze-alexa logs are designed to be quite readable, and should help track down the problem.
If you think it's the speech, try using the test input page on the Amazon dev account portal.
If all else fails, raise an issue here...
If you're getting permission denied IOErrors
reported in the logs,
make sure you cert file has world read (i.e. run chmod 644 squeeze-alexa.pem
)
openssl x509 -in squeeze-alexa.pem -text -noout
If you just want to check the expiry date:
openssl x509 -in squeeze-alexa.pem -enddate -noout
For $MY_HOSTNAME
and $MY_PORT
you can substitute your home IP / domain name (as used above). It also assumes your client cert is called squeeze-alexa.pem
:
openssl s_client -connect $MY_HOSTNAME:$MY_PORT -cert squeeze-alexa.pem | openssl x509
Type Ctrld to exit. If successful, this should give you a PEM-style certificate block with some info about your cert).
OK let's try seeing the problem:
openssl s_client -connect $MY_HOSTNAME:$MY_PORT -cert squeeze-alexa.pem
Note especially towards the end, the Verify return code. This is very helpful getting to the bottom of connection problems.
For more debugging:
openssl s_client -connect $MY_HOSTNAME:$MY_PORT -quiet -cert squeeze-alexa.pem
Type status
, and if a successful end-to-end connection is made you should see some gibberish that looks a bit like:
...status player_name%3AUpstairs...player_connected%3A1 player_ip%3A192.168.1...
Assuming your LMS IP restrictions allow it (check the LMS GUI security settings), and that you are using the standard 9090 CLI port, you can normally telnet from your computer:
telnet $LMS 9090
where LMS
is the address of your Squeezebox server - usually this will be the same as $MY_HOSTNAME
(though you might use the local name).
Then type status
, or some other command, and see if you get an encoded response. If not, you need to fix this first.
You can also try it directly on the LMS box if you think there's some networking problem. Use netcat
(e.g. opkg install netcat
) if you have it:
echo "status" | netcat $LMS 9090
(and try localhost
if that's not working. If still no joy, your DNS setup might be confused).
For the hardcore amongst you, you can check performance (and that there are no TLS bugs / obvious holes):
openssl s_time -bugs -connect $MY_HOSTNAME:$MY_PORT -cert squeeze-alexa.pem -verify 4