Adding the 4 channel relay board ks0212 to the MQTT universe
We just hacked a trotec dehumidifier for HerwigsObservatory. The idea was to additionally activate the dehumidifier when the difference between outside and inside humidity is above 10%. Normally there is a fan taking care of it but sometimes the differents gets to high. As there is already a raspberry pi running in the observatory for the weatherstation and the flightradar24 installation we just added the 4 channel relay board ks0212 from keyestudio. Not touching the 220V part we directly used the relay to “press” the TTL switch on the board for 0.5 seconds to turn on and off the dehumidifier. Here are the code snipped we used for this. The control is completely handled via MQTT.
For the sake of simplicity we used python and the GPIO library wiringpi. Therefore we first install the python development parts and them the python libraries for wiringpi and MQTT. As this is a dedicated hardware installation we don’t use virtualenv and directly install the library as root system wide.
The python program
import time
import wiringpi
import paho.mqtt.client as mqtt
def setup():
wiringpi.wiringPiSetup()
wiringpi.pinMode(3, 1)
wiringpi.pinMode(7, 1)
wiringpi.pinMode(22, 1)
wiringpi.pinMode(25, 1)
def short(pin):
switch_on(pin)
time.sleep(0.5)
switch_off(pin)
def switch_on(pin):
wiringpi.digitalWrite(pin, 1)
def switch_off(pin):
wiringpi.digitalWrite(pin, 0)
def on_connect(self, client, userdata, rc):
mqclient.subscribe("sternwarte/relay/#")
def on_message(client, userdata, msg):
m = msg.topic.split("/")
pin = 0
if m[-1] == "j3":
pin = 3
if m[-1] == "j2":
pin = 7
if m[-1] == "j4":
pin = 22
if m[-1] == "j5":
pin = 25
if pin != 0:
if msg.payload == "on":
switch_on(pin)
if msg.payload == "off":
switch_off(pin)
if msg.payload == "press":
short(pin)
if __name__ == "__main__":
setup()
mqclient = mqtt.Client(clean_session=True)
mqclient.connect("192.168.2.5", 1883, 60)
mqclient.on_connect = on_connect
mqclient.on_message = on_message
mqclient.loop_forever()
Again, a very simple python script, basically attaching to a (you need to change the code, there is no config) mqtt server and subscribes itself to a certain topic. Then it waits for messages and cuts off the last part of the topic to identify the relay. The naming convention is based on the relay name printed on the ks0212 pcb. As payload you can send “on“, “off” and “press“. “press” switches the relay on for half a second in order to simulate a button press as we need it for our dehumidifier.
Adding a systemd service
In order to keep the wantabe daemon up and running and also start it automatically at system start we add this service configuration file in “/lib/systemd/system/relayboard.service“:
If you want to do some hacking with the ks0212 relay board on your own here is the pin mapping table. I used the very cool side https://pinout.xyz/pinout/wiringpi for getting the numbers:
Every now and then you want to test your installation, your server or your setup. Specially when you want to test auto scaling functionalities. Kubernetes has an out of the box auto scaler and the official descriptions recommends a test docker container for testing with a apache and php installation. This is really great for testing a web application where you have some workload for a relatively short time frame. But I would also like to test a scenario where the workload runs for a longer time in the kubernetes setup and generates way more cpu workload then a web application. Therefore I hacked a nice docker container based on a c program load generator.
The docker container
The docker container is basically a very very simple Flask server with only one entry point “/”. The workload itself can be configured via two parameters:
percentage How much cpu load will be generated
seconds How long will the workload be active
The docker container itself uses nearly no CPU cycles as Flask is the only python process being active and waits for calls to start using CPU cycles.
lookbusy
I use a very nice open source tool called lookbusy from Devin Carraway which consumes memory and cpu cycles based on command line parameters. Unfortunately the program has no parameter to configure the time span it shout run. Therefore I call it the unix command timeout to terminate its execution after the given amount of seconds.
The Flask python wrapper
import subprocess
from threading import Thread
from flask import Flask, request
app = Flask(__name__)
def worker(percentage, seconds):
subprocess.run(['timeout', str(seconds), '/usr/local/bin/lookbusy', '-c', str(percentage)])
@app.route('/')
def load():
percentage = request.args.get('percentage') if "percentage" in request.args else 50
seconds = request.args.get('seconds') if "seconds" in request.args else 10
Thread(target=worker, args=(percentage, seconds)).start()
return "started"
if __name__ == "__main__":
app.run(host='0.0.0.0', port=80, processes=10)
The only program is a python Flask one, very short and only takes the get call to its root folder, checks for the two parameters and starts a thread with the subprocess. The get call immediately returns as it also supports long run workload simulations.
The Dockerfile
FROM python:latest
RUN curl http://www.devin.com/lookbusy/download/lookbusy-1.4.tar.gz | tar xvz && \
cd lookbusy-1.4 && ./configure && \
make && make install && cd .. && rm -rf lookbusy-1.4
RUN pip install Flask
ADD server.py server.py
EXPOSE 80
CMD python -u server.py
The docker container is based on python latest (at this time 3.6.4). I put all the curl, make, install and rm calls into a single line in order to have a minimal footprint for the docker layer as we do not need the source code any more. As Flask is the only requirements I also call it directly without the requirements.txt file. The “-u” parameter for the python call is necessary to prevent python from buffering the output. Otherwise it can be quite disturbing when trying to read the debug log file.
This command uses the bluemix CLI with the cluster plugin to control and configure kubernetes on the IBM infrastructure. The parameters are
–name to give your cluster a name (will be very important later on)
–location which datacenter to use (in this case dallas). Use “bx cs locations” to get your possible locations for the chosen region
–workers how many worker nodes are requested
–kube-version which kubernetes version should be used. Use “bx cs kube-versions” to get the available versions. “(default)” is not part of the parameter call.
–private-vlan which vlan for the private network should be used. Use “bx cs vlans <location>” to get the available public and private vlans
–public-vlan see private vlan
–machine-type which kind of underlying configuration you want to use for your worker node. Use “bx cs machine-types <location>” to get the available machine types. The first number after the “.” is the amount of cores and one after “x” the the amount of RAM in GB.
This command takes some time (~1h) to generate the kubernetes cluster. BTW my bluemix cli docker container has all necessary tools and also a nice script called “start_cluster.sh” to query all parameters and start a new cluster. After the cluster is up and running we can get the kubernetes configuration with
bx cs cluster-config ansi-blog
OK
The configuration for ansi-blogtest was downloaded successfully. Export environment variables to start using Kubernetes.
export KUBECONFIG=/root/.bluemix/plugins/container-service/clusters/ansi-blog/kube-config-dal10-ansi-blog.yml
Starting a pod and replica set
kubectl run loadtest --image=ansi/lookbusy --requests=cpu=200m
We start the pod and replica set without a yaml file because the request is very straight forward. Important here is the parameter “–requests“. Without it the autoscaler can not measure the cpu load and it never triggers.
Again because the call is so simple we directly call kubectl without a yaml file to expose the Port 80. We can check for the public IP with
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
loadtest LoadBalancer 172.21.3.160 <pending> 80:31277/TCP 23m
In case the cloud runs out of public IP addresses and the “EXTERNAL_IP” is still pending after several minutes we can use one of the workers public ip addresses and the dynamic assigned port. The port is visible with “kubectl get svc” at the “PORTS” section. The syntax is as always in docker internalport:externalport. The workers public IP can be checked with
bx cs workers ansi-blog
ID Public IP Private IP Machine Type State Status Version
kube-dal10-cr1dd768315d654d4bb4340ee8159faa17-w1 169.47.252.96 10.177.184.212 b2c.4x16.encrypted normal Ready 1.8.6_1506
So instead of calling our service with a official public ip address on port 80 we can use
http://169.47.252.96:31277
Autoscaler
Kubernetes has a build in horizontal autoscaler which can be started with
In this case it measures the cpu load and starts new pods when the load is over 50%. The autoscaler in this configuration never starts more than 10 and never less than 2 pods. The current measurements and parameters can be checked with
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
loadtest Deployment/loadtest 0% / 50% 1 10 1 23m
So right now the cpu load is 0 and only one replica is running.
Loadtest
Time to get call our container and start the load test. Depending on the URL we an use curl to start the test with