## Introducing Sensors Unity

Sensors-Unity is a new lm-sensors GUI for the Unity Desktop. It allows monitoring the output of the sensors CLI utility while integrating with the Unity desktop. This means there is no GPU/ HDD support and no plotting.
If you need those you are probably better suited with psensor. However if you just need a overview of the sensor readings and if you appreciate a clean UI you should give it a shot.

Sensors Unity is available from this PPA

It is written in Python3 / GTK3 and uses sensors.py. You can contribute code or help translating via launchpad.

# Overview

In contrast to other applications the interface is designed around being a application. Instead of getting another indicator in the top-right, you get an icon in the launcher:

The idea is that you do not need the sensor information all the time. Instead you launch the app when you do. If you want to passively monitor some value you can minimize the app while selecting the value to display in the launcher icon.

To get the data libsensors is used which means that you need to get lm-sensors running before you will see anything.

However once the sensors command line utility works you will see the same results in Sensors-Unity as it shares the configuration in /etc/sensors3.conf.

# Configuration

Unfortunately configuring lm-sensors via /etc/sensors3.conf is quite poorly documented, so lets quickly recap the usage.

• /etc/sensors3.conf contains the configuration for all sensors known by lm-sensors
• however every mainboard can use each chip in a slightly different way
• therefore you can override /etc/sensors3.conf by placing your specific configuration in /etc/sensors.d/ (see this for details)
• you can find a list of these board specific configurations in the lm-sensors wiki
• to disable a sensor use the ignore statement
• #ignore everything from this chip
chip "acpitz-virtual-0"
ignore temp1
ignore temp2
• to change the label use the label statement
• chip "coretemp-*"
label temp1 "CPU Package"

## Sensors-Unity Specific Configuration

Sensors-Unity allows using the Pango Markup Language for sensor labels. For instance if you want “VAXG” instead of “CPU Graphics” to be displayed, you would write:

label in4 "V<sub>AXG</sub>"

In order not to interfere with other utilities and to allow per-user configuration of the labels/ sensors Sensors-Unity first tries to read ~/.config/sensors3.conf before continuing with the lm-sensors config lookup described above.

## introducing sensors.py

sensors.py is a new python wrapper for libsensors of the lm-sensors project. libsensors is what you want to use to programmatically read the sensor values of your PC with Linux instead of parsing the output of the sensors utility.

sensors.py is not the first wrapper – there are two alternatives, confusingly both named PySensors.

PySensors (ctypes) follows a similar approach to sensors.py by using ctypes. However instead of exposing the C API it tries to be a object-oriented(OO) abstraction, which unfortunately lacks many features and makes the mapping to the underlying API hard. Furthermore it does not support Python3.

PySensors (extension module)  does not use ctypes and thus is more efficient, but if you write a python script probably compiling a extension module is worse than losing some performance when reading the values.
Additionally there is python3 support and also some OO abstraction. The latter is somewhere in between the C API and proper OO: sensors_get_label(chip_name, feature) is ChipName.get_label(feature) instead of feature.get_label().

So what makes sensors.py immediately different is that it does not try to do any OO abstraction but instead gives you access to the raw C API. It only adds minor pythonification: you dont need to mess with pointers, errors are converted to exceptions and strings are correctly converted from/ to utf-8 for you.

However working with the C API directly is tiresome at times – therefore there is also an optional iterator API, which is best shown by a demo:

import sensors

sensors.init()

for chip in sensors.ChipIterator("coretemp-*"):

for feature in sensors.FeatureIterator(chip):
sfi = sensors.SubFeatureIterator(chip, feature)
vals = [sensors.get_value(chip, sf.number) for sf in sfi]
label = sensors.get_label(chip, feature)

print("\t"+label+": "+str(vals))

sensors.cleanup()

result:

coretemp-isa-0000 (ISA adapter)
Physical id 0: [38.0, 80.0, 100.0, 0.0]
Core 0: [37.0, 80.0, 100.0, 0.0]
Core 1: [35.0, 80.0, 100.0, 0.0]
Core 2: [38.0, 80.0, 100.0, 0.0]
Core 3: [36.0, 80.0, 100.0, 0.0]


for a more sophisticated example see the example.py in the repository.

## Replacing your desktop laptop with a ITX workstation

If you use your laptop as a desktop replacement, you will at some point get an external display and a mouse/ keyboard for more convenient usage.
At this point the laptop becomes only a small case of non-upgradable components.

Now you could as well replace your laptop by a real case of comparable size.  This will make your PC not only easily upgradable, but allow higher-end components while being more silent at the same time.

## Streaming the Screen on Android

In this post I want to discuss way of getting the screen content of your Android device to the TV or monitor. If you wonder why one might want to do such a thing – just think about playing some Android games with a bluetooth gamepad or watching a movie where your PC is not available.

Specifically I want to introduce SlimPort. SlimPort is a feature of Nexus devices which is unfortunately not covered much in reviews.
Basically SlimPort is DisplayPort over the Micro-USB connection of your device allowing you to mirror its display.

# But the future has arrived: we got Miracast!

One might wonder why one should go through the hassle of using a old-school HDMI cable.

# Building the program

To trigger a rebuild of the program simply execute

dpkg-buildpackage

To upload a package to a PPA you first need to sign it to prove that you are the author. To do this you have to execute the following in the <packagename><newversion> directory

debuild -S

sudo apt-get install dput

Now change to <somedir> and execute

dput ppa:<your_username>/<repository> <source.changes>

## Secure Owncloud setup

While the Owncloud Manual suggests enabling SSL, it unfortunately does not go into detail how to get a secure setup. The core problem is that the default SSL settings of Apache are not sane as in they do not enforce strong encryption. Furthermore the used default certificate will not match your server name and produce errors in the browser.

In the following a short guide in how to set-up a secure Apache 2.4 server for Owncloud will be presented.

# The Big Picture

Android consists of three parts relevant to rooting

2. recovery system
3. main system

typically only the main system is running, that is the Linux Kernel, the launcher, the phone app etc.. If we talk about rooting, that means we want to add an additional app to the main system which may access secured parts of the main system and also acts as a gatekeeper for other apps that want to get access too.

The problem is that we need access to the secure parts of the system in order to do so, which means that we cant simply install that app (e.g. an apk) from within the main system.

This means we have to go one level down. This is where the recovery system is. Typically you do not see it, as it is only active when the main system can not run – either because a system update is installed or because you do a factory reset.
As the recovery system can do a full system update, it means that it has also access to the secured parts of the main system – exactly what we need. Unfortunately the stock recovery system does not allow installing apps, so we have to replace it.

The bootloader is a tiny piece of software which decides wether to start the recovery or the main system (or another main system, like Ubuntu Phone). But in the default configuration in only starts systems that it knows and trusts. In this configuration the bootloader is called locked. Although it prevents malicious software to change the phone and spy on us, it also prevents us from replacing the recovery system. This concept is also coming to the PC btw where it is called secure-boot.

Here is a graphical overview of the Android components:

So what we need to do in order to get root access is

2. replace the recovery system
3. install a superuser app

Note that unlocking the bootloader also allows attackers to circumvent any of the android security features. It is possible directly access all the files on the phone from the bootloader.
Therefore android will wipe all userdata when the bootloader is unlocked

# Preparations

First you need to install the fastboot binary to be able to perform low-level communication with the device

apt-get install android-tools-fastboot

Next you have to allow non-root users to execute commands over USB, so you do not have to run fastboot as root. For this create the file

/etc/udev/rules.d/51-android.rules

with the following content

SUBSYSTEM=="usb", ATTR{idVendor}=="<VENDOR>", MODE="0666", GROUP="plugdev"

you can find the value for <VENDOR> on the page linked here.

Finally you have to reboot into fastboot mode. Usually there is a key combination you have to press on startup.

Remember this key combination as you will need some more times.

Samsung Devices however, like the Galaxy S3, do not support the fastboot mode – instead they have a download mode, which uses a proprietary Samsung protocol. To flash those you have to use the Heimdall tool. While this article does not cover the heimdall CLI calls, the general discussion still applies.

for google devices, like a Nexus 4 or Nexus 7 it is just

fastboot oem unlock

if you have a Sony Xperia device, like a Xperia Z, you additionally have to request a unlock key and then do

fastboot oem unlock 0x<KEY>

where <KEY> is the key you obtained.

# Replacing the Recovery System

There are two prominent alternative recovery systems with the ability to install apps

Clock Work Mod (CWM) is probably most known so we will use that one. From the Website linked above download the recovery image which fits your phone.
Here you have the choice between the ordinary recovery which uses the volume buttons of your device for navigation and the touch recovery which supports the touch screen.

fastboot flash recovery <RECOVERY>.img

where <RECOVERY> is the name of the file you downloaded. For instance for a Nexus 5 and CWM 6.0.4.5 it would be

fastboot flash recovery recovery-clockwork-6.0.4.5-hammerhead.img

# Installing the superuser app

To my knowledge the only one superuser app that works with Android 5.0 lollipop is SuperSU. So we will have to use that. However there is also a pull-request for Superuser by CWM which might make it also work with Android 5.0 in the future.

The installation procedure is a little bit different. In the appropriate package for your device you will find a boot image which we have just to start once with

fastboot boot image/CF-Auto-Root-hammerhead-hammerhead-nexus5.img

note that there is no flash in the line above. The image which starts contains a script which installs SuperSU and modifies the startup procedure so it can get around SELinux.

## Pre Android 5.0 lollipop

If you run devices with Adroid older than 5.0 lollipop you have several choices here

although SuperSU is the most prominent one, I would recommend getting Superuser by CWM, as it is open source and also nag-free as there is no “pro” version of it.

To install we need to get this zip archive and copy it to the device. To install it, we need to reboot into fastboot mode and then select “Recovery Mode” to get to the recovery system. Once in Recovery mode select

install zip -> choose zip from /sdcard

then browse and select the “superuser.zip” you just copied.

Once installed select

Go Back -> reboot system now

Once the system has started you should have a “Superuser” App on your device. Congratulations, you are done.

# Optional: flash stock recovery

As the recovery is responsible for installing system updates it is a good idea to revert to stock version after you installed root, so the system can auto-update itself again. However a system update will also remove your superuser app so you will have to repeat the above procedure again.

If you have a Google Nexus Device, you can grab the factory images here.  There you will find a image of the stock recovery and restore it by

fastboot flash recovery recovery.img

## Repairing the Philips HD4685 Kettle

The Philips HD4685 is one of the more advanced kettles, as not only automatically shuts-off when the water is boiled, but also allows setting a target temperature below 100°C. This is quite handy if you want to drink green tea, which is supposed to be boiled with only 80°C warm water. Unfortunately the extra electronics is another part which can make the Kettle fail. And this is exactly what happened to me.

# Symptoms

I used the kettle for about 3 years on daily basis. One day however it stopped to make the “beep” which indicates that the water is ready when cooking at 100°C. But as this is not an essential functionality I just kept using the kettle. Unfortunately a few weeks later it did not cook at 100°C at all. Instead the kettle just turned off after reaching 80°C – even though 100°C were set.

# Diagnosis

Under the hood one of the capacitors forming the capacitive power supply for the electronics started failing. Instead of supplying 0.47 μF, it merely supplied 0.1μF. So what was happening is that once more power consumer like the 100°C LED and the speaker were activated the power supply broke down and the whole circuit shut down.

So the solution is to replace the respective capacitor.

# Therapy

Before you try to fix the kettle on your own, be aware that wrong assembly of the kettle can lead to a short-circuit that can cause a fire or lead to an electric shock. You should have fundamental knowledge of electrical engineering.

To access the faulty capacitor one must first disassemble almost the whole kettle:

1. remove the screws on the bottom cover (torx 8)
2. lever out the bottom plate with a flat screwdriver
3. disconnect the power supply cables
4. remove the screws on the top cover (torx 10). Then remove the top cover and the metallic ring. Also remove the handle cover.
5. Pull out the electronics box, which is now free as you disconnected the power cables(3)
6. unscrew and open the electronics box.
7. replace the capacitor C1. (requires soldering) The capacitor specifications are MKP X2, 26.5 x 10 x 19 mm, 0.47 µF 275 V/AC ±10%, 22.5 mm pitch

For reassembly perform the steps in reverse order. The kettle should work now.

I would like to give credit to the according thread at elektronikwerkstatt.de, where I found the informations to create this post.

# Final Words

I am not really sure if this is a case of planned obsolescence or just of insufficient testing, but I would really like philips to use higher quality capacitors and/ or rethink their power supply design. The kettle which is worth 50€ is still fully functional and just failed because of a 1€ part.