Monthly Archives: August 2020

Access Windows Share from Raspberry Pi (revisited)

by

Last year I described a simple method of automounting a directory from my windows server to my Raspberry Pi. Since then I’ve gone down a couple of paths to simplify rebuilding my Raspberry Pi machines.

The method I used last year required modifying the /etc/hosts file, the /etc/fstab file, pre-creating the mount points, and creating a credentials file to store the windows login credentials.

My new method doesn’t require modification of the /etc/hosts or /etc/fstab files, or pre-creating the mount points. Instead I’m relying on two features, Multicast DNS and systemd.automount unit files.

In the old method, to find the windows server, I added it to the local hosts file on the raspberry pi. 

192.168.0.12 Acid

Using Multicast DNS, if I simply recognize that I can reach the server with the name Acid.WimsWorld.local the raspberry pi will find the server on the local network. My first step was to modify my /etc/fstab enty to use the local address and clean up my hosts file.

//acid.wimsworld.local/web /media/acid/web/ cifs credentials=/etc/wimsworld.smb.credentials,noauto,x-systemd.automount,x-systemd.idle-timeout=2min,_netdev 0 0

I’d never been happy with modifying the /etc/fstab file as part of my system configuration because in newer installations it is unique to each machine, specifying the boot partitions by their formatted serial number:

proc            /proc           proc    defaults          0       0
PARTUUID=142ff4e3-01  /boot           vfat    defaults          0       2
PARTUUID=142ff4e3-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

In my recent programming projects I’ve been working with systemd unit files to control my service processes and have come to understand how they work for automounting directories as well. I like that each directory has its own unit files meaning that a modification is less likely to cause problems for the system as a whole.

The single line from the /etc/fstab file above is removed and replaced by two unit files, /etc/systemd/system/media-acid-web.mount and /etc/systemd/system/media-acid-web.automount.

[Unit]
Description=Acid Web

[Mount]
What=//acid.wimsworld.local/web
Where=/media/acid/web
Type=cifs
Options=credentials=/etc/wimsworld.smb.credentials,vers=2.1

[Install]
WantedBy=multi-user.target

and

[Unit]
Description=Automount Acid Web

[Automount]
Where=/media/acid/web
TimeoutIdleSec=120

[Install]
WantedBy=multi-user.target

I still had to create the credentials file for this to work, since I wanted the credentials file to be only root readable in a different location. /etc/wimsworld.smb.credentials

username=WindowsUsername
password=WindowsPassword
domain=OptionalDomainName

After the three files are created, systemd needs to reload its database with the systemctl daemon-reload command, the automount needs to be enabled with the systemctl enable media-acid-web.automount command, and then started with the systemctl start media-acid-web.automount command.

The naming of the mount files is important, and described explicitly in the man pages for each of mount and automount. In my case, /media/acid/web gets named media-acid-web.mount and media-acid-web.automount. I didn’t need to create mount points in the /media directory, as systemd automatically takes care of that.

I was able to create all of the above with a simple paste into my terminal with the following string:

sudo bash
cat > /etc/systemd/system/media-acid-web.mount <<EOF
[Unit]
Description=Acid Web

[Mount]
What=//acid.wimsworld.local/web
Where=/media/acid/web
Type=cifs
Options=credentials=/etc/wimsworld.smb.credentials,vers=2.1

[Install]
WantedBy=multi-user.target
EOF
cat > /etc/systemd/system/media-acid-web.automount <<EOF
[Unit]
Description=Automount Acid Web

[Automount]
Where=/media/acid/web
TimeoutIdleSec=120

[Install]
WantedBy=multi-user.target
EOF
cat > /etc/wimsworld.smb.credentials <<EOF
username=WindowsUsername
password=WindowsPassword
domain=OptionalDomainName
EOF
chmod 0600 /etc/wimsworld.smb.credentials
systemctl daemon-reload
systemctl enable media-acid-web.automount
systemctl start media-acid-web.automount
exit

With the standard Raspberry Pi setup, the cat command is not available as a sudo command while the bash shell is. I’m taking advantage of that by running the bash shell as root and then all of the other commands with root privileges.

tp-link Smart Plugs with Energy Monitoring

by

Several years ago I picked up a TP-Link HS110 switch so that I could turn lights on and off on a schedule. It had an interesting feature of being able to monitor energy usage as well.

The HS110 has an unfortunate design that covers the second socket in a wall outlet and makes it unusable. I purchased several HS105 units over time because two can be plugged into a standard outlet with the only drawback being the extra distance the normal plug extends from the wall. The HS105 was on sale as multipack on a somewhat regular basis. The drawback of the HS105 is that it doesn’t offer energy monitoring.

I came across the HS300 power strip that offers six switched outlets plus energy monitoring for each outlet. It has a flat angled plug, allowing two devices to fit in a standard wall outlet.

Each of these devices seems to be rated at 15A (1875W) total. That should be fine, since most of the standard wall plugs they would be plugged into aren’t rated for more than that, but it’s interesting that the current handling of the largest devices is the same as the smallest.

The energy monitoring was an interesting feature, and I was hoping to get around to doing more than glancing at it from my phone occasionally. Nearly three years after my first purchase I finally got around to writing a program to do what I wanted to log the energy usage.

I’d come across https://www.softscheck.com/en/reverse-engineering-tp-link-hs110/ when I first bought the HS110, and thought I would get around to doing what I wanted quickly, but as with so many projects, it was set aside as less important. With the transient nature of the web, I’m glad that this site is still visible, and the resulting github repository tools proved invaluable for me getting my project working. https://github.com/softScheck/tplink-smartplug

There are several python projects for communicating with these devices which I also found useful, but I was hoping to build a small program with very few dependencies. Part of what I wanted to know was the communication protocol over the ethernet, and that took the most time to decipher.

https://github.com/wcbonner/KasaEnergyLogger is my project, with all of the work done in a single threaded C++ file. I’ll hopefully describe what I know of the protocol in the future. As it is, I’m pulling data from multiple devices and logging it using MRTG. I know there are significantly better graphics dashboards available, but this requires very little infrastructure, and I’m logging the raw data in case I ever really want to revisit it.

MRTG graph of AC Power Usage

For most people these devices connect to Alexa or Google Home and the scheduling plus voice controls are all that they will ever use.

I was very happy with having lamps set to turn on at sunset and turn off at specific times. The fact that I live at a latitude where sunset changes from after 9pm in the peak of summer to before 5pm midwinter was plenty for me. I also use them for controlling fans to adjust the climate in my home when I’m not relying on air conditioning.

From a system monitoring perspective I’ve considered having two Raspberry Pi, each plugged into a HS105, monitoring each other and power cycling the other device if it can’t be reached for a designated period of time.

Here are some of the other sites I found useful in getting to my current state: