Translate

Saturday, July 23, 2022

Server chronicles - HA temporary server (UPDATED)


Among many other services, my server hosts some HA services to control my X10 lights and some operations.
Since my glorious server need to be rebuilt and as usual I don't have time, I needed to find a quick solution for my X10 server.
I decided to use a spare Raspberry I have around and create a temporary HA server, until the main one will be restored.

Basically I need :

  1. a Raspberry Pi
  2. connect a CM11a to the Raspberry
  3. install Heyu 
    1. configure it for the X10 modules installed
    2. configure crontab for some automated operations
  4. Install the Alexa interface with Heyu
  5. setting up the system

Raspberry Pi

Original


I do have around many Raspberry, but as usual because my laziness I did pick up one already used for another project : the speedtester.
So I did grab the Pi and started with an overall update of the system, leaving untouched the speed test functionality.
It can always be handy and anyway what I need to install would not overload the Pi, it is a slow load operations. 
The Raspberry is using :

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

New version

For the new version I formatted an SD card and loaded the latest image using the Raspberry Pi Imager.
I choose a basic image without desktop
Then I connected the Raspberry to the wired LAN, a monitor and a USB Keyboard and configured.
The usual :
  • enable WLAN (on my WiFi)
  • enable SSH
  • enable I2C
  • expand the system space on the SD card
  • update the system
At this point I had a ready to go basic Raspbian system.

Connecting a CM11a


The CM11a is a serial RS232 interface capable to send X10 commands over a house.
The Raspberry doesn't have any serial port so is necessary to use a USB<->RS232 converter.
I have some of them around and of course the first I did pick up was not recognized by the Raspi.
dmesg recognized it as :

[38545.475415] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
[38545.608572] usb 1-1.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.54
[38545.608597] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[38545.608613] usb 1-1.4: Product: USB2.0-Ser!

After playing around the problem for a while I did find lot of suggestions about how install a driver for that specific serial/USB converter, downloading source code, building/etc.
However often the solution is more simple than one expect.
After updating the system, I simply didn't reboot the machine and the new kernel with all the driver was not yet loaded.

After the boot I did find the /dev/ttyUSB0 up and ready for me :)

Lesson learned : the version of Raspbian used is fully capable to recognize the USB <-> RS232 adapter I have without the need to install anything.

Installing Heyu


At this point is possible to install Heyu.
Many guides are online describing what to do.
For example :
Let start  to install Java first.
I did use : 
  • sudo apt update
  • sudo apt install default-jdk
It install (at this time) Java 11, Heyu requires at least Java 8.
So far no problems, Heyu like it.

Then I downloaded Heyu from the repository (heyu_master), extracted (unzip) and then built it.
  • cd heyu_master
  • ./Configure.sh
  • make
  • sudo make install
I did choose to install the configuration file under /etc/heyu.
Then I copied in the x10.conf the previous configuration file

After completing the installation, I did try the system and voila', the raspberry is capable to read/write the interface :

$ heyu info
Heyu version 2.11-rc3
Configuration at /etc/heyu/x10.conf
Powerline interface on /dev/ttyUSB0
Firmware revision Level = 1
Interface battery usage = 0:00  (hh:mm)
Raw interface clock: Sat, Day 202, 04:10:58
(--> Civil Time: Sat 22 Jul 2023   05:10:58 BST)
No schedule has been uploaded by Heyu.
Housecode = A
0 = off, 1 = on,               unit  16.......8...4..1
Last addressed device =       0x0000 (0000000000000000)
Status of monitored devices = 0x0000 (0000000000000000)
Status of dimmed devices =    0x0000 (0000000000000000)

Configuring Heyu


Depending where you choose to install the configuration file during the building phase, editing it can add more personality using the ALIAS command.
So if we assign an ALIAS to the module A3 (for example) calling it kitchen_light, will be possible just to issue the command : heyu on kitchen_light

Important to document the assigned alias since they will be used by the Ha-bridge to simplify the activation.

Be sure to manually test each alias to be sure the X10 address used is actually working.

Installing Ha-Bridge


Ha-bridge allows to interface Heyu to the Alexa world, basically having the possibility to control lights (and more) via voice and via a webpage (hosted by the server itself).
This is the code that requires Java installed on the system.
As the other components, I strongly suggest to use the instructions by Corey.
In the end I did install the version 5.4.1 of Ha-bridge and everything did work perfectly but not the Alexa integration (see below)

I discovered that after installing the HA-Bridge is necessary to assign the devices and make them discoverable to Alexa

Configuring HA-Bridge

The tedious part is to add the devices you want to use to the HA-Bridge using the web page.

Using the Heyu alias and the full path for both Heyu and the Heyu configuration file, is possible to create the list of devices Ha-Bridge use.
The "name" assigned by the device is the name that will be used by Alexa in the vocal command.

Note that is possible to use HA-Bridge not only with Heyu but also scripts and other programs.
Some "device entries" actually can trigger complex operations, like waking up a computer or execute "scenes".

Make devices discoverable

In order to make the devices discoverable by Alexa, probably due from latest Amazon modifications, each unique ID assigned to the device need to be changed.

This unique ID has 8 groups of 2 digits in the format xx:xx:xx:xx:xx:xx:xx-xx
Alexa expects to find an ID with 9 groups of 2 digits, i.e. with the format : xx:xx:xx:xx:xx:xx:xx:xx-xx

To change the unique ID is necessary to :
  • stop ha-bridge
    For example :  sudo service habridge stop
  • edit the file device.db : /home/pi/habridge/device.db
    I used nano
    • search for the string uniqueid
    • add a new 2 group digit
    • repeat for all the unique id in the file
    • save file
  • start ha-bridge
    For example : sudo service habridge start
It is important to remember that in case a name of a device need to be changed is necessary to follow this procedure :
  • change the name of the device on HA bridge
  • go on the Alexa app, Settings/Devices
  • locate the OLD (current) name of the device
  • erase it
  • perform a discovery
  • the device with the new name will be discovered
  • reinstall it on the routines eventually (when a device is removed, is also removed form the routines)

Setting up the system


The HA server has also some automated functionalities, like turning all the lights OFF at a specific time or turning them on and turn on/off the main computer.
A series of bash scripts need to be prepared :
  • x10alloff
    Turn off all the lights
  • x10allon
    Turn on all the lights
  • x10morningon
    Turn on the lights for the morning routine
  • wakemilo
    Turn on the main computer (Milo)

Waking up/Shutdown Milo


Milo is my main machine and I like to turn it on and off using a vocal command via Alexa.
Basically I have two routines in Alexa, one triggers the Milo turning on procedure and one triggers the Milo turning off procedure

Turn Milo On

To turn on Milo I use the Wake On Lan (WOL) capability.
Basically sending a "magic packet" to the network card in Milo, triggers the computer on.
The program wakeonlan must be installed on the HA server (the Raspberry).
A script is created to call the wakeonlan program with the Ethernet address of the card in Milo.
Milo need to be enabled for the WOL procedure.

To retrieve the MAC address of the PC :
  • open a terminal on the PC to be turned ON via WOL
  • execute : ifconfig -a
  • look for the interface that is associated with the IP assigned to that PC
  • look the MAC address
For example on mine (I changed some values) :

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.5.90  netmask 255.255.255.0  broadcast 192.168.5.255
        inet6 fe80::2eab:aadf:4324:9f0e  prefixlen 64  scopeid 0x20<link>
        ether 90:b1:1d:91:2a:d0  txqueuelen 1000  (Ethernet)
        RX packets 369669  bytes 293449054 (293.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 184392  bytes 34546388 (34.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xef400000-ef420000  

look for inet for the IP and the associate MAC is on the line ether, i.e. 90:b1:1d:91:2a:d0

The command to wake up the PC should be : wakeonlan 90:b1:1d:91:2a:d0

To verify that the magic packet is received is possible to operate in this way :
  • open two terminals on the computer to be turned on
  • on one terminal,m let call it Terminal A,  login to the HA server
  • on the second one, let call it Terminal B, execute the command :
    nc -ul 9
  • on the Terminal A : wakeonlan <MAC address>


Turn Milo Off

Turning Off Milo is little bit more complicated.
Basically is necessary to login via ssh and issue the command "sudo shutdown -h now" or "sudo poweroff"
The trick is to set up the system in order to accept ssh login without password, aka a key need to be set and used.
To do so, is necessary to create a key to be used to login remotely.

On the HA server :
  • create a key without password using ssh-keygen
  • copy the public key
On the machine to control
  • open the file authorized_keys (located under .ssh )
  • copy the public key obtained from the HA server
  • save the file
From now on an ssh connection made from the HA server toward the machine to control, will be done without asking for a password.

Thus the command :

ssh <username>@<machine_IP> "sudo poweroff"

will turn off the machine

No comments:

Post a Comment