You will have seen references to the slave flag in the main scheduler program. This is a boolean value passed in when the controller is first started up. We have set it to false for all operations to date, as we have been building our master hub, but if we set this flag to true then we would launch the hub in slave mode.
A Slave hub is a cut-down appliance that is focused on reading sensors and driving actuators. It still has all of the software installation of a master hub, but some routines are not used. I will be publishing an installation script and SD image file in the resources section soon, so you don’t have to manually construct another hub. The master hub will talk to the slave over the network, giving you the extended reach for your sensors and actuators. The Pi Zero W is the ideal candidate for implementing a slave hub.
Once you have your second pi up and running, all that is required to make it a slave is the following:
1. Install the api:
wget -P /var/www/html http://www.warrensoft.co.uk/home-hub/code/website/html/api.php
2. Change the slave hostname – to distinguish master and slave when configuring
3. Edit /etc/rc.local and change the –slave=false to –slave=true in the line launching main_sched.py and optionally reduce the logging level to just errors –log=ERROR or no logging –log=CRITICAL
4. Reboot the slave
5. Test the api:
http://slave-hub/api.php?sensor=1
Now we need to add some software to our master hub to equip it to talk to slaves. This comes in the form of a remote sensor helper and a remote actuator helper.
wget -nH -x --cut-dirs=3 -P /usr/local/bin/code/controller/ -i /usr/local/bin/code/controller/manifest5.txt http://www.warrensoft.co.uk/home-hub/manifests/controller/manifest5.txt
These helpers need to be un-commented in their respective __init__.py files.
We also need the python requests module, via pip:
sudo apt-get install python-pip
sudo pip install requests sudo pip install --upgrade requests-cache
Restart the controller and add a new sensor, this time with the Sensor Function of the form:
remote.x.y
where x represents the least significant part of the ip address of the slave, and y represents the remote sensor number. For example, if we had a master hub on 170.30.90.40, and a slave on 170.30.90.41 with a Sensor S3, then the sensor function in the master would be:
remote.41.3
Once configured the remote sensor is identical to a local sensor, and can be sampled, alerted, monitored, etc.
An identical approach applies to remote actuators, so the actuator function remote.41.4 would control actuator 4 on the slave hub.
Just a note about security. Remote access to the api page is not secure, unlike the normal website functions. Rather than publish details on a public blog, it is left to the reader to implement whatever mechanism they feel is appropriate. One possible setup is to make just the master hub website accessible over the internet, on a different port, but not the slave hub(s). Consult your router documentation for details.
Next we will look at fetching our readings from slightly further afield.