Adding different metrics sections to the start page

In the initial version of the SUSI.AI Skill CMS we simply displayed all the skills present in the system in the form of cards. Once the skill analytics was incorporated into the CMS we got a bunch of skill statistics and thus we enhanced the start page by incorporating horizontally scrollable skill cards as per skill metrics like top rated skills, most used skills, skills which have received the most feedback etc. I worked on adding the skills with most feedback section and the section for the top games. This post will majorly deal with how the metrics sections are implemented on the start page and how any new metrics can be incorporated into the system and thus displayed on the CMS.

About the API


Sample API call:


This will return a JSON which contains the skill data for all the metrics.

 "accepted": true,
 "model": "general",
 "group": "All",
 "language": "en",
 "metrics": {
        "newest": [...],
     "rating": [...],
 "message": "Success: Fetched skill data based on metrics",
   "session": {"identity": {
           "type": "host",
          "name": "",
          "anonymous": true


All of the data for several metics comes from the metrics object of the response which in turn contains arrays of skill data for each metric.

CMS Implementation

Once the BrowseSkill component is mounted we make an API call to the server to fetch all the data and save it to the component state, this data is then fed to the ScrollCardList component as props and the scroll component is rendered with appropriate data for different metrics.

loadMetricsSkills = () => {
   let url;
   url =
           urls.API_URL +
           '/cms/getSkillMetricsData.json?language=' +
   let self = this;
           url: url,
           dataType: 'jsonp',
           jsonp: 'callback',
           crossDomain: true,
           success: function(data) {
                           skillsLoaded: true,
                           staffPicksSkills: data.metrics.staffPicks,
                           topRatedSkills: data.metrics.rating,
                           topUsedSkills: data.metrics.usage,
                           latestUpdatedSkills: data.metrics.latest,
                           newestSkills: data.metrics.newest,
                           topGames: data.metrics['Games, Trivia and Accessories'],
           error: function(e) {
                   console.log('Error while fetching skills based on top metrics', e);
                   return self.loadMetricsSkills();


We are using a single component for skill metrics and skill listing which show up on applying any filter or visiting any category. Thus we think of a condition when the skill metrics are to be displayed and conditionally render the metrics section depending on the condition.

So the metrics section shows up only when we have not visited any category or language page, there’s no search query in the search bar, there’s no rating refine filter applied and no time filter applied.

let metricsHidden =
         this.props.routeType ||
         this.state.searchQuery.length > 0 ||
         this.state.ratingRefine ||


Depending on the section you want to display, pass appropriate data as props to the SkillCardScrollList component, say we want to display the section with most feedback

{this.state.topFeedbackSkills.length &&
!metricsHidden ? (
   <div style={metricsContainerStyle}>
                           {'"SUSI, what are the skills with most feedback?"'}
           {/* Scroll Id must be unique for all instances of SkillCardList*/}
           {!this.props.routeType && (
) : null}


So if there are skills preset in the topFeedbackSkills array which was saved in the state from the server initially and the condition to hide metrics is false we render the component and pass appropriate props for scrollId, skills data, language and model values and skill url.

In a similar way any metrics section can be implemented in the CMS, if the data is not present in the API, modify the endpoint to enclose the data you need, fetch data data from the server and just render it.

So I hope after reading through this you have a more clearer understanding about how the metrics sections are implemented on the CMS.


Continue Reading

A Workflow of Auto Executing Services on SUSI.AI Smart Speaker

As we plan to create a headless client on RaspberryPi, the requirement was that the SUSI.AI programs should run automatically. To do so, we had to figure out a way to boot up various scripts on startup.

We had the following options to execute the scripts on startup:

  1. Editing Rc.local file
  2. Systemd Rules
  3. Crontab

We decided to proceed with Systemd Rules because using Rc.local and Crontab requires modifying the default system files which in case of any error would make the os functionalities to crash very soon.

We then created the SystemD rules for the following services:

2. python-flask.service
3. susi-server.service
4. update-daemon.service
5. susi-linux.service

Now I’ll demonstrate the working and the functionality of each service being implemented.

1. Factory-Daemon Service

This service initiates the factory daemon with the raspberry Pi startup and then keeps it running continuously looking for any input from the GPiO port.

Description=SUSI Linux Factory Daemon

ExecStart=/usr/bin/python3 /home/pi/SUSI.AI/susi_linux/factory_reset/


2. Python-Flask Service

This service starts a python Server to allow handshake between mobile apps and the Smart Speaker which will allow the user to configure SUSI Smart Speaker accordingly.

Description=Python Server for SUSI Linux

ExecStart=/usr/bin/python3  /home/pi/SUSI.AI/susi_linux/access_point/server/


3.SUSI-Server Service

This service starts the Local SUSI Server as soon as the Raspberry Pi starts up which in turn allows the SUSI Linux programs to fetch responses of queries very quickly.

Description=Starting SUSI Server for SUSI Linux



4. Update-Daemon Service

This Service creates a Daemon which starts with the Raspberry Pi and fetches the latest updates from the repository from the upstream branch.

Description=Update Check- SUSI Linux



5. SUSI-Linux Service

This Service finally runs the main SUSI Linux software after everything has started.

Description=Starting SUSI Linux

ExecStart=/usr/bin/python3 -m main


This blog gives a brief workflow of auto-executing services on SUSI Smart Speaker.


Continue Reading

Configuring LED Lights with SUSI Smart Speaker

To make the SUSI Smart Speaker more interactive and to improve the visual aesthetics, we configured SUSI Smart Speaker’s response with 3 RGB led lights. We have used a new piHat as an external hardware to configure the LEDs.

Now the new hardware specs of the SUSI Smart Speaker are:

  1. Raspberry Pi
  2. ReSpeaker PiHat 2 Mic Array
  3. External Speakers

Using an external PiHat not only added the RGB light functionality but also eliminated the need to use a USB microphone and configured a factory reset button

Configuring the PiHat as the default Audio driver

To Use the PiHat as the default input driver, we use the package called PulseAudio.

And we use the following command in the installation script.

pacmd set-sink-port alsa_output.platform-soc_sound.analog-stereo analog-output-headphones

Configuring PiHat’s GPIO Button with Factory Reset

There is an onboard User Button, which is connected to GPIO17. We use the python library RPi.GPIO to detect the user button. The python script is used in the following way

i = 1
while True:
if GPIO.input(17) == 1:
   elif GPIO.input(17) == 0 :
       start = time.time()
       while GPIO.input(17) == 0 :
       end = time.time()
       total = end – start
       if total >= 7 :
 [‘bash’,‘’])  # nosec #pylint-disable type: ignore
       else :
           mixer = alsaaudio.Mixer()
           value = mixer.getvolume()[0]
           if value != 0:


This script checks on the button which is configured on GPIO port 17 on the PiHat. If the button is pressed for than 7 secs, the factory reset process takes place, else the device is muted.

Configuring PiHat’s LED with Speaker’s Response

We use a python library called SPIDEV to sync the LED lights with SUSI’s response. SPIDEV is usually used to send a response to the bus devices on the Raspberry Pi.

The first step was installing spidev

sudo pip install spidev

Now we create a class where we store all the methods where we send the signal to the bus port. We treat the LED lights as a circular array and then have a rotation of RGB lights

class LED_COLOR:
    # Constants
   MAX_BRIGHTNESS = 0b11111    LED_START = 0b11100000
    def __init__(self, num_led, global_brightness=MAX_BRIGHTNESS,
                order=‘rgb’, bus=0, device=1, max_speed_hz=8000000):
       self.num_led = num_led
       order = order.lower()
       self.rgb = RGB_MAP.get(order, RGB_MAP[‘rgb’])
       if global_brightness > self.MAX_BRIGHTNESS:
           self.global_brightness = self.MAX_BRIGHTNESS
           self.global_brightness = global_brightness
        self.leds = [self.LED_START, 0, 0, 0] * self.num_led
       self.spi = spidev.SpiDev(), device)
       if max_speed_hz:
           self.spi.max_speed_hz = max_speed_hz
    def clear_strip(self):
        for led in range(self.num_led):
           self.set_pixel(led, 0, 0, 0)
    def set_pixel(self, led_num, red, green, blue, bright_percent=100):
       if led_num < 0:
           return          if led_num >= self.num_led:
       brightness = int(ceil(bright_percent * self.global_brightness / 100.0))
       ledstart = (brightness & 0b00011111) | self.LED_START
        start_index = 4 * led_num
       self.leds[start_index] = ledstart
       self.leds[start_index + self.rgb[0]] = red
       self.leds[start_index + self.rgb[1]] = green
       self.leds[start_index + self.rgb[2]] = blue
    def set_pixel_rgb(self, led_num, rgb_color, bright_percent=100):
       self.set_pixel(led_num, (rgb_color & 0xFF0000) >> 16,
                      (rgb_color & 0x00FF00) >> 8, rgb_color & 0x0000FF, bright_percent)
    def rotate(self, positions=1):
       cutoff = 4 * (positions % self.num_led)
       self.leds = self.leds[cutoff:] + self.leds[:cutoff]
    def show(self):
       data = list(self.leds)
       while data:
           data = data[32:]
    def cleanup(self):
       self.spi.close()  # Close SPI port
    def wheel(self, wheel_pos):
       “””Get a color from a color wheel; Green -> Red -> Blue -> Green”””
        if wheel_pos > 255:
           wheel_pos = 255  # Safeguard
       if wheel_pos < 85:  # Green -> Red
           return self.combine_color(wheel_pos * 3, 255 – wheel_pos * 3, 0)
       if wheel_pos < 170:  # Red -> Blue
           wheel_pos -= 85
           return self.combine_color(255 – wheel_pos * 3, 0, wheel_pos * 3)
       wheel_pos -= 170
       return self.combine_color(0, wheel_pos * 3, 255 – wheel_pos * 3)


Now we use the threading to create non-blocking code which will allow SUSI to send response as well as change the LED’s simultaneously.

class Lights:
   LIGHTS_N = 3
    def __init__(self): = threading.Event()
       self.queue = Queue.Queue()
       self.thread = threading.Thread(target=self._run)
       self.thread.daemon = True
    def wakeup(self, direction=0):
       def f():
    def listen(self):
    def think(self):
    def speak(self):
    def off(self):

This is how LED lights are configured with SUSI’s response


Additional Resources

Continue Reading

Connecting the Smart Speaker with Mobile Clients

The beauty of SUSI Smart Speaker lies in it being customizable according to the user’s needs. And we allow the user to customize it by providing an interface through the mobile clients. To do so, we create a local server on the Raspberry Pi itself. The Raspberry Pi is started in an Access Point mode and the mobile clients hit the endpoints in a specific order and then the configuration is sent to the server and stored according to the user.


The following API’s are required to be executed by the mobile clients

1> /speaker_config

2> /wifi_credentials

3> /auth

4> /config


The following is the order of API execution

1. /speaker_config

This endpoint only takes the room name as a parameter. And then send send to the server to store the location of the device under the user’s account

def speaker_config():
   room_name = request.args.get(‘room_name’)
   config = json_config.connect(config_json_folder)
   config[‘room_name’] = rogom_name


2. /wifi_credentials

This endpoint takes the wifi ssid and wifi password as the parameters and then stores it in the raspberry Pi wifi config file.


def wifi_config():
   wifi_ssid = request.args.get(‘wifissid’)
   wifi_password = request.args.get(‘wifipassd’)[‘sudo’, ‘bash’, wifi_search_folder + ‘/’, wifi_ssid, wifi_password])
   display_message = {“wifi”:“configured”, “wifi_ssid”:wifi_ssid, “wifi_password”: wifi_password}
   resp = jsonify(display_message)
   resp.status_code = 200
   return resp


Now the script wifi_search is called which stores the wifi credentials in the wifi_config file using the following command


cat >> /etc/wpa_supplicant/wpa_supplicant.conf <<EOF


3. /auth

This endpoint takes the SUSI’s login credentials as parameters, i.e. the registered email id and the corresponding password.


def login():
   auth = request.args.get(‘auth’)
   email = request.args.get(’email’)
   password = request.args.get(‘password’)[‘sudo’, ‘bash’, access_point_folder + ‘/’, auth, email, password])
   display_message = {“authentication”:“successful”, “auth”: auth, “email”: email, “password”: password}
   resp = jsonify(display_message)
   resp.status_code = 200
   return resp


4. /config

Finally, this endpoint takes the stt, tts, hotword detection engine and wake button as the parameters and configures the speaker accordingly.


def config():
   stt = request.args.get(‘stt’)
   tts = request.args.get(‘tts’)
   hotword = request.args.get(‘hotword’)
   wake = request.args.get(‘wake’)
   subprocess.Popen([‘sudo’, ‘bash’, access_point_folder + ‘/ ‘, stt, tts, hotword, wake])
   display_message = {“configuration”:“successful”, “stt”: stt, “tts”: tts, “hotword”: hotword, “wake”:wake}
   resp = jsonify(display_message)
   resp.status_code = 200
   return resp


Now, this function runs a script called which in turn runs a script called to convert the Raspberry Pi to normal mode and then finally start SUSI on startup.



if [ $EUID -ne 0 ]
then echo “Must be root”

cd /etc/hostapd/
sed -i ‘1,14d’ hostapd.conf

cd /etc/
sed -i ‘57,60d’ dhcpcd.conf

cd /etc/network/
sed -i ‘9,17d’ interfaces

echo “Please reboot”
sudo reboot


After successfully hitting all the endpoint from the client, your Smart Speaker would restart and would see the following screen on your client.



Additional Resources


fossasia, susi,, gsoc, gsoc’18, handshake

Continue Reading

Modifying Finite State Architecture On SUSI Linux to Process Multiple Queries

During the initial stages of SUSI Linux: As the code base grew, it was getting very difficult to manage code, so we opted to implement a Finite State Architecture in our repo. But, as there were new features implemented in the Repo, we realized that we couldn’t process more than one query at a time which restricted a lot of features. eg. The smart speaker was converted to a simple Bluetooth speaker since no response regarding playing/pausing were accepted.

To solve this issue, we made a slight modification in the architecture.

Brief About SUSI States

SUSI is working as a Finite State Machine and is present in 3 states namely IDLE state, Recognising state and Busy state. The State Machine executes in the following order.

  1. IDLE State:
    When the SUSI state Machine is in this State, SUSI is searching for the hotword “SUSI”, waiting to trigger the complete Machine.
  2. Recognizing State

In this State , the State Machine has started the STT client. After recognition, SUSI sends the query to the Server awaiting the response

  1. Busy State

After the response has been received, the TTS client is triggered and the answer is given out by SUSI

Adding a Second Hotword Recognition Class

Now, to allow SUSI to process the second query, The State machine must be triggered while SUSI is giving out the first response and to trigger the State Machine, we must have hotword recognition while SUSI is speaking the answer to the previous query. Hence, a hotword recognition engine is now initiated every time the State Machine enters the busy state.

We will be using Snowboy as Hotword Detection Engine.


import os
TOP_DIR = os.path.dirname(os.path.abspath(__file__))
RESOURCE_FILE = os.path.join(TOP_DIR, “susi.pmdl”)
class StopDetector():
   “””This implements the Stop Detection with Snowboy Hotword Detection Engine.”””
    def __init__(self, detection) -> None:
       self.detector = snowboydecoder.HotwordDetector(
           RESOURCE_FILE, sensitivity=0.6)
       self.detection = detection
    def run(self):
       “”” Implementation of run abstract method in HotwordDetector. This method is called when thread is
started for the first time. We start the Snowboy detection and declare detected callback as
       detection_callback method declared ina parent class.


Now, this class takes the Callback function as a parameter which is passed when the transition to busy state takes place from the recognition state.


Modifying the State Machine Architecture

After declaring a second hotword recognition engine , we must modify how the transitions take place between the States of the SUSI State Machine.

Hence the callback that will be triggered is passed from the busy state.


def detection(self):
       “””This callback is fired when a Hotword Detector detects a hotword.
       :return: None
       if hasattr(self, ‘video_process’):
           subprocess.Popen([‘play’, str(self.components.config[‘detection_bell_sound’])])
       if hasattr(self, ‘audio_process’):
           subprocess.Popen([‘play’, str(self.components.config[‘detection_bell_sound’])])


As soon as the hotword is detected ,the state machine makes transitions to the Recognition State while pausing the current Music and resumes the Music after the second query has been completed.


This is how SUSI processes multiple queries simultaneously while still maintaining finite state archi.


Additional Resources


gsoc, gsoc’18, finite_state_machine, susi_linux, multiple_query,, susi


Continue Reading

Creating a Custom Raspbian Image containing SUSI.AI Linux Libraries

Installing Raspbian and SUSI Linux on your Raspberry Pi can be a long process and if your raspberry Pi crashes due to some bug, you have to repeat the process again and again.

It wastes a lot of valuable time. So, we will discuss a method in which we will have to install the SUSI Linux repo only once and can use it again in case of any issues.

First, we’ll go through the requirements for f installing SUSI Linux on our hardware

Hardware Requirements

1> Raspberry Pi

2> Micro SD card (16GB or greater)

3> USB Mic

4> USB Mouse and USB Keyboard

5> HDMI Monitor

6> ReSpeaker Pi Hat 2 Mic Array(optional)

7> 3.5 mm Jack Headphones / Speaker


Step 1: Preparing SD for Installation

1> To format your SD card

  • You can use softwares like SDCardformater to do so.

2> To install Raspbian

  • Download raspbian official build from here
  • Now mount the Image using software like Etcher or win32diskimager


Step 2: Installing SUSI Linux on your Pi

1> Navigate to the folder `/home/pi` and make a folder called SUSI.AI


cd /home/pi
mkdir SUSI.AI


2> Clone the SUSI Linux repo from here and navigate in the repo


git clone

cd susi_linux/


3> Run the installation script by using the command `./`




4> Run the configuration script by using the following command

`python3 <stt> <tts> <hotword> <wake>`


5> Run SUSI linux with the following command

`python3 -m main`


If it plays a bell after you say ‘SUSI’ , it means that your software has been successfully installed

Step 3: Creating the image

1> Now that you have successfully installed SUSI Linux on your raspberry Pi , we will make a backup of the current stage of the system and use it for future references


2>Turn off the raspberry Pi , and remove the SD card from the Pi and insert it in your system.


3> To create the custom Image , use something like win32 imager and follow the steps below

  • In the text box , create a custom where you want your image to exist
  • Click on read button
  • And voila




Fossasia, gsoc’18, SUSI.AI , susi_linux , gsoc, SUSI HW, installation

Continue Reading

Implementing Volume Action in SUSI Smart Speaker

We all know that a Smart Speaker to excel above its competitors has to excel in first being a good “Speaker” and a speaker has a basic and essential feature which is “volume control”. But things get better if you can control your volume with your voice.

So, we have implemented a feature that allows the user to control the volume of the audio with his/her voice.

Below are the steps we had to follow to implement this feature


Step 1: Creating the Skills

The skills required to implement the ‘volume-action’ is implemented in the SUSI Server repo itself.

The skill is located in



And below are the skills required


set audio volume to *|set audio volume to * percent|set audio volume to * points|set volume to *|set volume to * percent|set volume to * points
!console:Audio volume is now $1$ percent.
{“type”:“audio_volume”, “volume”:$1$}


We get the following response from the server


“actions”: [
       “volume”: “80”,
       “type”: “audio_volume”
       “type”: “answer”,
       “expression”: “Audio volume is now 80 percent.”


Step 2: Finding Volume Action in the server response

Now that our Server responds to our queries regarding the voice change action , we must implement it in our Smart Speaker Client.

We first create a custom class in our in the SUSI API Wrapper repo which has only one member


class VolumeAction(BaseAction):
   def __init__(self , volume):
       self.volume = volume


We check through the actions in the server’s response


elif isinstance(action, VolumeAction):
           result[‘volume’] = action.volume


Step 3: Implementing it in the client

Now to implement the action in our client we use a library called ‘alsaaudio’ to control the master volume of our RaspberryPi


              m = alsaaudio.Mixer()
               os.system(‘play {0} &’.format(self.components.config[‘detection_bell_sound’]))  # nosec #pylint-disable type: ignore                m = alsaaudio.Mixer()
               os.system(‘play {0} &’.format(self.components.config[‘detection_bell_sound’]))  # nosec #pylint-disable type: ignore


Now the user can easily change the speaker using the voice commands




GSoC, GSoC’18, SUSI.AI, SUSI Linux, Smart Speaker , SUSI API Wrapper, SUSI Server, FOSSASIA, Volume Action

Continue Reading

Displaying SUSI Smart speaker under Devices while logging in

The user should be given an ability to access all his devices on one page(Smart Speaker, IOS Device, WebClient and the Android Device). The user was previously allowed to access his/her web app account, the IOS app, Android App. But not the Smart Speaker. Now, this feature will allow the user to easily manage the Smart Speaker devices without many hassles.

In this post, we will be talking about the API’s that we have used to send the details of the Smart-Speaker to the server.

About the API’s

  1. Below is the API endpoint which will return the list of all devices present under the user’s account

We use the following endpoint



Below is sample response :

“devices”: {
“8C-39-45-cc-eb-95”: {
“name”: “Device 1”,
“room”: “Room 1”,
“geolocation”: {
“latitude”: “52.34567”,
“longitude”: “62.34567”


  1. The second endpoint that we will be using is to add a new Device under the devices section

API Endpoint



This endpoint has the following parameters

  • macid (Mac address of the device)
  • name (Name of the device)
  • room (Room info of the device)
  • latitude (Latitude info of the device)
  • longitude (Longitude info of the device)


After successfully hitting the endpoint , you’ll get the following response


“accepted”: true,
“message”: “You have successfully added the device!”,
“session”: {“identity”: {
“type”: “email”,
“name”: [email protected],
“anonymous”: false


Implementing the API’s

  1. First, we check the server for existing devices. This step is implemented primarily to check weather our current Smart Speaker is already configured or not.
get_device_info = api_endpoint + ‘/aaa/listUserSettings.json?’

param1 = {

   # print(access_token)

   if access_token is not None:
       device_info_response = requests.get(get_device_info,param1)
       device_info = device_info_response.json()

   # print(device_info)

If the current device is not already configured on Server, we proceed to next step.

  1. Now we will configure the device with the server and then post the device settings there.
    We will implement the API in the following way:


if device_info is not None:
   device = device_info[‘devices’] # list of existing mac ids
   session = device_info[‘session’] # session info
   identity = session[‘identity’]
   name = identity[‘name’]
   params2 = {
   ‘macid’: macid,
   ‘name’: name,
   ‘device’: ‘Smart Speaker’,
   ‘access_token’: access_token

   for dev in device:
       if dev == macid:
           print(‘Device already configured’)
       else :
           adding_device =, params2)


To extract the mac address from the speaker and pass it as the params , we use a python library called UUID and this is how SUSI Smart Speaker is displayed on the web client(




Continue Reading

Creating an Update Daemon for SUSI Smart Speaker

A daemon in reference of operating systems is a computer program that runs as a background process rather than under direct control of the user. Various daemons are being used in SUSI smart speaker.

The following daemons have been created

  • Update Daemon
  • Media Discovery Daemon
  • Factory Reset Daemon 

In this blog, we’ll be discussing the implementation of the Update Daemon in SUSI.AI

Update Daemon

Due to the ever-growing coding community, it is needed to provide regular updates to the smart speaker and keep it in sync with the latest technology. Hence an Update Daemon was required that could fetch updates at a regular interval.

The Updated Daemon was implemented in the following steps

1.Deciding the Update Interval

How frequently should we check for updates was the first question that was tackled while implementing this daemon.
We decided that we should check for Update, every time the Raspberry Pi starts and an internet connection was available.

2. Implementing The Decision

To start the Update script every time the Raspberry Pi starts, we decided to create Systemd rules.

Description=Update Check- SUSI Linux



The above rule waits for a network connection to be established with the Raspberry Pi and then triggers a bash script that fetches updates

3. Fetching The Updates

Now, a bash script was prepared that would fetch the latest changes from the online repo and merge the latest changes in the local repo



LOCAL=$(git rev-parse @)
REMOTE=$(git rev-parse “$UPSTREAM”)
BASE=$(git merge-base @ “$UPSTREAM”)
if [ $LOCAL = $REMOTE ]
   echo “Up-to-date”
elif [ $LOCAL = $BASE ]
   echo “Need to pull”
   echo “Diverged”

if [$CHECK = “Need-to-pull”]
   git fetch UPSTREAM
   git merge UPSTREAM/master



Tags, gsoc, gsoc’18, fossasia, update, daemon, update_daemon, smart speaker, systemd, hardware

Continue Reading

Create a Wireless Access Point Using a Raspberry Pi to Connect with SUSI Smart Speaker

To use the pi as a wifi bridge, a local network or just as a wifi range extender.We at FOSSASIA are using it as a network to connect between our SUSI.AI smart speaker and the Android and IOS devices. Or maybe because you can !! :’)


  1. Raspberry Pi Model 3(since we will be using an internal wifi)
  2. Power supply for the Pi.
  3. Monitor (optional)
  4. Keyboard (optional)
  5. Mouse (optional)


1.Install and upgrade raspbian


Sudo apt-get update && sudo apt-get install


2. Install hostapd and dnsmasq .
This will allow us to use our raspberry pi as a wireless access point


apt-get remove –purge hostapd -yqq
apt-get update -yqq
apt-get upgrade -yqq
apt-get install hostapd dnsmasq -yqq


3. Now we will add broadcasting IP and DNS address in the dnsmasq configuration file

To access the configuration file use:

sudo nano /etc/


And to the bottom of the file, add the following commands




  1. Now to select the SSID and the PASSWORD for the access point, we’ll need to change the configurations of hostapd package
sudo nano /etc/hostapd/hostapd.conf


Then, use the following commands :




  1. To finally sum up the configuration, we’ll have to create a  custom network interface that combines all the settings that we have made.
sudo nano /etc/network/interfaces


And add the following lines it the EOF

allow-hotplug wlan0
iface wlan0 inet static


Now, we just have to have to disable default interfaces so that they do not interfere with the custom interfaces that we have made.

To do so


sudo nano /etc/dhcpcd.conf


Add the following line at the end of the file

denyinterfaces wlan0


  1. Now just restart the services


systemctl enable hostapd && systemctl enable dnsmasq

sudo service hostapd start && sudo service dnsmasq start

sudo reboot


Now, you will be able to enjoy a self-made access point which is used as a basic mode of connection in SUSI Smart Speaker and can also be used in various other access point methods.






Continue Reading
Close Menu