Category: Testing

Once your Phrase Processor is correctly handling the test phrases in direct mode, it is time to move to narrated mode.

I am using my desktop PC to run the test player, so this is the first thing to get setup. Change the mode on line 22, and run the player. In narrated mode you get the option to step through each phrase in the list, and optionally repeat one if they were not recognised.

Here is a video of the Narrated test running on my home setup.

Once you are satisfied with your narrated tests, you can go live. The speech_reco.py program handles a number of miscellaneous commands that aren’t technically part of the home-hub domain: go to sleep, go away, repeat, etc.

I hope you have fun interacting with your home environment using voice.

You will recall this diagram from the introduction:

We should now have all the software installed to be able to complete the first stage of integration testing.

If you explore the files in code/vox you will find the test_player.py script. The test player can operate in one of three modes:

• Direct
• Narrated
• Log

For this test we want to set the Direct mode, where test phrases are piped to the processor. You can set the mode on line 22.  The Phrase Processor is initialised with 3 parameters:

• Base url for the home-hub
• Timeout (secs) for refreshing api cache
• Home Zone – so hub-vox can answer ‘where am I?’

Run the test player with the following command:

python test_player.py

I chose to run my tests on a Windows PC for convenience, as there is a simple interface with windows text-to-speech capabilities, so you may have to modify the test_player to run it on the pi.

I have provided a sample testfile to demonstrate the process, however, you will want to edit this to meet your own requirements, or start from scratch with your own list. During testing, you can move terms to the top of the list while you make adjustments to the Phrase Processor configuration to handle the phrase.

Once you are happy with the configuration and your test phrases are understood, you can move on to system testing, but first there are a couple of things that need to be completed: Google credentials and Snowboy watchword.

These are covered in the next post.

 

Now is a good time to test the database access from a Python script, but first we need to install the PostgreSQL adapter for Python –  psycopg.

sudo apt-get install python-psycopg2

Then we can place the following script in the /usr/local/bin/code/controller directory…

#
# hellodb.py script to show PostgreSQL and Pyscopg together
#

import sys
import psycopg2
import psycopg2.extras

try:
    cstr = "dbname='hub' user='postgres' host='localhost' password='raspberry'"
    conn = psycopg2.connect(cstr)
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor)
    cur.execute("SELECT * from \"Zone\"")
    rows = cur.fetchall()
    print "\nShow me the zones:\n"
    for row in rows:
        print row.get("ZoneID"), row.get("ZoneName")
except Exception:
    print("Unable to connect to the database")
    e = sys.exc_info()[0]
    print (e)

 

Run your script with the following…

cd /usr/local/bin/code/controller
sudo python hellodb.py

You should see the following output:

Show me the zones:

1 Kitchen
2 Bathroom

This script uses the Dictionary-like cursor found in the extras package. The advantage of this method of database access is that you can reference the columns by name instead of index, which makes the code more tolerant of database changes.

Having confirmed our controller can access the database, it is time to create the website.