Controlling a PC via Apple HomeKit: part 3

In the first 2 parts we installed the infrastructure and the tools to control the PCs. In this last part of the tutorial, we will create the scripts that will be run when the actions are triggered.

Create the Power On script on the Raspberry Pi

Create the directory where the script will be located. The directory structure is $HOME/.smart-pc-control/<topic>. The directory should contain a file named script.sh that receives the action data as a parameter.

The power on script uses Wake On Lan to start the remote PC. To install Wake On Lan on the raspbian:

sudo apt-get install wakeonlan

A remote PC can be woken up by just running the command wakeonlan <mac address>. For example:

wakeonlan 54:b2:03:09:09:c4

Then create a directory for the script:

mkdir -p $HOME/.smart-pc-control/pc/nuc/state/on/

Edit the script file

nano -w $HOME/.smart-pc-control/pc/nuc/state/on/script.sh
# !/bin/bash

if [[ $1 == "true" ]] ; then
     echo "[INFO] Waking up pluto"
     wakeonlan <mac address>
 fi

Make the script executable:

chmod +x $HOME/.smart-pc-control/pc/nuc/state/on/script.sh

Create the Power Off script on the PC

The Power Off script needs the same directories as the power on one. So, to create them:

mkdir -p $HOME/.smart-pc-control/pc/nuc/state/on/

Then, edit the file:

nano -w $HOME/.smart-pc-control/pc/nuc/state/on/script.sh

The contents should look like this: 

 #! /bin/bash

if [[ $1 == "false" ]] ; then
     echo "[INFO] About to shutdown the PC"
     nohup sudo shutdown -h now &
 else
     echo "[INFO] Nothing to do … the flag is on"
 fi

Make it executable:

chmod +x $HOME/.smart-pc-control/pc/nuc/state/on/script.sh

Launch the Home App on your Apple device, select the device and turn it on/off to test.

Controlling a PC via Apple HomeKit: part 2

On the first part of the tutorial, I showed how to install the infrastructure software to allow Apple devices to control a PC via Homekit. Now I am going to show how to install the services that interface with the infrastructure to execute the actions triggered by the Apple devices.

Installing the power on service on the Raspberry PI

The first service to install is the service responsible for powering on the PC using WakeOnLan. This is done using this small project I wrote: Smart PC Control.

This software is not packaged for Raspbian and it needs to be compiled from source along with 2 of its dependencies. Luckily this is a simple process.

First, let’s start by installing the build dependencies:

sudo apt-get install  build-essential gcc make cmake libjson-c-dev uuid-dev liburiparser-dev

With the build dependencies installed, we can proceed to install the first dependency: GRU.

git clone https://github.com/orpiske/gru.git
 cd gru 
 mkdir build && cd build 
 cmake ..
 make 
 sudo make install

Now we need to install the Eclipse Paho C MQTT client:

git clone https://github.com/eclipse/paho.mqtt.c.git -b v1.3.1
cd paho.mqtt.c 
mkdir build && cd build
cmake .. && make 
sudo make install

And, finally, the Smart PC Control project:

git clone https://github.com/orpiske/smart-pc-control.git
mkdir build && cd build
cmake ..
make
sudo make install

With this project installed we can proceed to its configuration.

Configuring the Power On Service on the Raspberry Pi

The Smart PC Control project install SystemD unit files and its respective configuration.

First, let’s edit the service configuration

cp /etc/sysconfig/smart-pc-control-power.set-me-up /etc/sysconfig/smart-pc-control-power
sudo nano -w /etc/sysconfig/smart-pc-control-power

The configuration should look similar to this:

# The URL of the MQTT broker
MQTT_BROKER_URL=tcp://localhost:1883

# Replace changeme with the hostname where the system is running
CLIENT_ID="power-control-changeme"

# Uncomment for clients that don't store any state
DAEMON_OPTIONS="--stateless"

# Ensure to export library dir if not using a standard location
# LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

Now, let’s edit the System D unit file: /usr/lib/systemd/system/smart-pc-control-power@.service.

The content should look like this:

[Unit]
Description=Smart PC Control - Power Daemon
After=syslog.target network.target

[Service]
 User=%i
Type=forking
EnvironmentFile=-//etc/sysconfig/smart-pc-control-power
ExecStart=/usr/local/bin/smart-pc-control-power -d -b $MQTT_BROKER_URL -i $CLIENT_ID $DAEMON_OPTIONS
PrivateTmp=false
Restart=on-failure

[Install]
WantedBy=multi-user.target

Enable the service

To enable the service for the pi user, run:

sudo systemctl enable --now smart-pc-control-power@pi.service

Install the Power Off Service on the PC

This part assumes a PC running Fedora. For other distributions or OSes, you have to build the tool manually and install it.

The software is fully package for Fedora and available on the awesome Fedora COPR. To do so:

sudo dnf copr enable orpiske/orp-tools-testing
sudo dnf install -y smart-pc-control

With the services installed, we can proceed to configuring its daemon

sudo nano -w /etc/sysconfig/smart-pc-control-power

The contents of the file should look like this:

# The URL of the MQTT broker
MQTT_BROKER_URL=tcp://mimas:1883

# Replace changeme with the hostname where the system is running
CLIENT_ID="power-control-changeme"

# Uncomment for clients that don't store any state
# DAEMON_OPTIONS="--stateless"

# Ensure to export library dir if not using a standard location
# LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64

Note that the DAEMON_OPTIONS is commented. The Power Off doesn’t need it.

To enable the service, run:

sudo systemctl enable --now smart-pc-control-power@USER.service

Note: replace USER with your actual user

This should be all that is required to install and run the power daemons.

Go to part 3.

Controlling a PC via Apple HomeKit

This tutorial will show how to integrate a regular computer to a Apple’s HomeKit and use your iOS or iPadOS device to turn it on or off.

This tutorial requires a iOS or iPadOS device, with the Home application, a Raspberry Pi and a computer with Wake on LAN support.

A MQTT broker along with Homekit2MQQ will be installed to provide support for the tooling.

Install Mosquito

sudo apt-get -y install mosquitto

Setup Mosquitto

To do that edit the file /etc/mosquitto/mosquitto.conf

The contents of the file should be:

pid_file /var/run/mosquitto.pid
persistence true
 persistence_location /var/lib/mosquitto/log_dest file /var/log/mosquitto/mosquitto.log
 allow_anonymous true
 listener 1883 0.0.0.0
 log_dest syslog
 log_dest stdout
 log_dest topic
 log_type error
 log_type warning
 log_type notice
 log_type information
 connection_messages true
 log_timestamp true

With the MQTT broker configured, enable it to start on boot.

sudo systemctl enable --now mosquitto

Setup the Homekit2Mqtt Bridge

The Homekit2Mqtt software provides a software bridge to the HomeKit via a MQTT broker.

This package requires NodeJs to be installed and configured.

Install Node 10x

The NodeJS packages on the default repositories for the Raspberry Pi contain a version to old to run Homekit2Mqtt. To install a NodeJS version that can be used to run it, execute the following commands:

curl -sL https://deb.nodesource.com/setup_10.x | sudo bash -
sudo apt-get install -y nodejs gcc g++ make
mkdir -p /opt/npm
npm config set prefix=/opt/npm
npm install -g homekit2mqtt --unsafe --per

This may take a while. After the NodeJS installation is finished, you must reate a directory on the home directory to store the Homekit2Mqtt configuration. 

mkdir -p $HOME/homekit-bridge/data

Create a SystemD unit file

The package does not come with a SystemD unit file and cannot be managed by SystemD out of the box. This makes it harder to ensure it can be started on boot or reinitialized on failure. To do so, we have to create a SystemD unit file.

First, we will use nano to edit the SystemD unit file. The file will be created in such a way that can be associated with user to run the service:

sudo nano -w /usr/lib/systemd/system/homekit-bridge@.service

The file have the following content:

[Unit]
 Description=Smart PC Control - HomeKit Bridge
 After=syslog.target network.target artemis.service

[Unit]
 Description=Smart PC Control - HomeKit Bridge
 After=syslog.target network.target artemis.service

[Service]
 User=%i
 Type=simple
 ExecStart=/usr/bin/nice -n20 /opt/npm/bin/homekit2mqtt --url mqtt://localhost:1883 --storagedir /home/%i//homekit-bridge/data/storage --mapfile /home/%i/homekit-bridge/data/my-home.json
 PrivateTmp=false
 Restart=on-failure

[Install]
 WantedBy=multi-user.target

Create an empty map file before starting the service (make sure to use the correct user for that – you don’t want to create this file with the root user):

echo "{}" > /home/pi/homekit-bridge/data/my-home.json

With the unit file created, we can go ahead and enable it. The service will be enabled to run with the user pi (the default user created by Raspbian) .

sudo systemctl enable --now homekit-bridge@.service

You can check if it is working by accessing the web UI at the address http://my-raspberry-pi:51888/ui/. The default user is homekit password and the password is the PIN 031-45-154 (if you haven’t changed it – you should). If everything is alright, you should see the Web UI for the Homekit2Mqtt.

Add The Bridge to the Home App

Click on Add Acessory, click on the Button “I Don’t Have a Code or Cannot Scan”. Put the PIN code from the Homekit2Mqtt bridge.


After that is complete, you should have a MQTT Bridge device listed on the Home App. Eventually, it will disappear and only display the devices connected to the bridge.

Go to Part 2.

Automating shelving of Jenkins jobs

The current version of the shelve plugin does not support shelving multiple projects. This can be a pain if you have a large Jenkins deployment. Luckily, it is possible to shelve multiple projects using a simple bash script.

If you have the jenkis-cli jar on your system, this can be can in two steps:

  1. First generate a list of jobs to shelve:

  1. Iterate over the list to shelve the projects:

This script uses a small delay between every couple shelve requests. This is useful if your jobs contain a lot of data and Jenkins will take too long to shelve them.

 

 

Running Apache Artemis with 32Mb of JVM heap memory

As part of the effort to run Maestro on the Minicloud, I decided to tweak the Maestro broker used by the test cluster. The broker component provides the infrastructure for the test nodes to exchange messages. It is used, for example, to synchronize the start and stop of the test execution and share success and failure notifications.

Given the resource restrictions I mentioned on the previous post, I decided to setup a dual purpose node, serving both as a Maestro client and as as Maestro broker. The virtual machine I setup for this purpose has only 1 vCPU and 512 Mb of RAM. At first sight is looks pretty small, but it should be sufficient for running both of the tasks allocated for it.

To accommodate for these resources, I decided to deploy Apache Artemis as the Maestro Broker.  One the cool things about Artemis is that it can run with ridiculously small amount of memory. The low scale of the Maestro Broker means that I can go pretty aggressive with the resource limitations and, as such, I decided go with as little as 32Mb of heap.

The first step to achieve this, is to adjust the artemis command-line for the download package. In its default setting, the heap is set to vary between 512Mb to 1Gb, which would exceed the capacity of the virtual machine I configured. This script runs the code that creates the broker instance, therefore, it’s not necessary to waste too much time tweaking it. Simply adjusting it for creating the broker instance should be sufficient.

This setting is adjusted on ${install.directory}/bin/artemis. The line to be changes is the one with JAVA_ARGS. I have adjusted the heap to a fixed size of 256Mb.

With that setting in place, the instance can be created. For example:

To start tweaking the instance,  the java heap memory for the instance can be adjusted. That is done on the  ${instance.directory}/etc/artemis.profile. Once again, the line to be adjusted is the one with JAVA_ARGS:

That alone should be sufficient for the very low scale of the Maestro Broker. However, given the very low memory settings, it is a good idea to disable a couple of extra things: the console and unused acceptors.

To disable the console we can modify the ${instance.directory}/etc/bootstrap.xml. The trick is to remove (or comment) the web element and all its contents. This is the content that should be removed:

Then, the last trick is to leave only the acceptors that are intended to be used in this broker instance. Since Maestro broker relies on MQTT, that’s the only one that can be left there. The acceptors configuration for Apache Artemis should look like this:

After that, the broker can be started. If you are unsure about the configuration, you can check the command lines using ps or jcmd.

In addition to these changes, the Artemis documentation mentions a lot of other tunnables that can be adjusted. For such a slow scale broker as this, I did not find the reason to adjust anything else other than what is mentioned here.

 

 

 

Minicloud: the Free OpenPower cloud

I recently got access to the Minicloud, a Free OpenPower Cloud hosted by Unicamp, one of the most prominent universities in Brazil. This cloud is a good way to ensure that your application provides good support for the Power architecture.

Having access to this cloud, I can help ensure that some of the projects I am interested about can be ran and supported on this architecture. Additionally, it offers me a Power environment to test the messaging-related packages I maintain on Fedora and CentOS – entirely on my free time.

To start with this cloud, I decided to go big and deploy Maestro there. Having only 4Gb, it means that I need to adjust very well the resources of my VMs so that I can maximize the usability of the cloud environment. I will write some posts about this.

The other project that I am interested in playing with in the Minicloud is Paho C, the MQTT client from Eclipse Foundation. As the Fedora maintainer for the package, having access to this environment means that I have a personal environment where I can ensure the quality of the packages.

Making it easy to play with Maestro

Maestro is a collection of tools that can be used for distributed performance testing. It is oriented towards testing of messaging oriented middleware (MOM), such as Apache ActiveMQ and its successor Apache Artemis , but can be extended to other performance test use cases.

Because Maestro forms a test cluster, it requires several components to run and deploying it can be tricky.

In order to simplify the development process as well as simplify it for users hoping to play with and run local tests, I created a set of containers (handled by Docker Compose) that can deploy a Maestro Test Cluster for local testing.

The process is extremely simple and you can go from 0 to the actual test execution in 3 commands (supposing docker-compose is already installed on your system):

1. Build and run the containers:

2.Run the client:

3. Execute a test (within the client):

After the test is completed, just point the browser to http://localhost:8000/ to read the report and view the details.

Additional details about this, such as how to tweak the tests or use a different messaging project, are available in this document within the Maestro Java source code.

 

Garmin Connect IQ on Fedora

Garmin Connect IQ is the SDK used to build applications and widgets for Garmin Devices such as the awesome Garmin Vivoactive 3.

Unfortunately, the package does not work on Fedora out of the box. In order to make it run, you have to take the following steps:

1. Install Gnucash (it is required because there’s no package for a compatible webkitgtk):

2. Export the path to the webkit library required (you might want to leave this on your shell profile or similar):

3. Install libjpeg8.

3.1 (Update) Enable this COPR and install libjpeg8 from there.

3.1 If you are using Fedora 27, you can install this RPM

3.2 If you are using Fedora 26, luck is on your side and you can just use the package from this COPR.

How to find the IP address of Linux guests

There’s a lot of examples in the internet showing how you can obtain the IP address of a libvirt guest virtual machine. Most of the examples show how to do that when the network is using NAT forwarding (aka “Virtual Networks”).

However, how to do that if your setup is using Bridged Networking and your guests receive an IP address from an external DHCP server?

One idea is to install the read the DHCP leases file straight from the guest FS. You can do that by using the libguestfs-tools to cat the file within the image. For RHEL 6 (and CentOS 6 and similar distributions) the process is similar to this:

For RHEL 7 (as well as CentOS 7 and similar) the process is slightly different due to the way NetworkManager stores the leases file:

In this Gist there’s a modified script I used to update the IP address of all guests in one shot.