Innr SmartPlug for Philips Hue – part 1

Philips Hue – Great, only E27 ad GU10 lights?

Great system, but what about the E14 lights that I have around the house, and some others where the bulbs can’t be replaced with one of the Hue lights? It seems that the Osram Lightify Plug can be connected. A solution without soldering and flashing firmware would take the fun out of it. The new brand Innr offers a SmartPlug, that uses the Zigbee HA protocol. Could it also be used with the Zigbee ZLL protocol used by Hue? The answer is yes. It only requires flashing a custom firmware. Read More

RFM69 OOK – DAGC, Sensitivity Boost and Modulation index

As a final step in exploring the optimal settings for receiving “foreign” OOK signals with the RFM69, the settings for DAGC, Sensitivity Boost and the effect of the Modulation index are explored. The modulation index is actually a FSK aspect, and no effect should be expected for OOK. However, as it can be programmed to High or Low, it is included in the exploration.

Foreign OOK refers to signals that are not natively produced by an RFM69, but are originating form various sensors or remote controls.

From the first results, it can be concluded that Sensitivity Boost has a clear advantage, and also DAGC enabled helps in icreasing sesnitivity:
RFM69SpecialModeHisto
Read More

RFM69 – Energy Count 3000 / ELV Cost Control

Conrad Energy Count 3000 and ELV Cost Control are wireles 230V electricity consumption measuring plugs Thomas Schulz has cracked the RF protocol of these device back in 2011 on the JeeLabs forum. The signals are FSK encoded and use the 868Mhz band. Thomas was able to receive them with a RFM12B module. Together with a JeeLink V3, it has found popular use with the German home automation software FEHM.

In this post I describe how the RFM69 can take over a task that earlier had to be performed in software.

One of the complications of the protocol is that the preamble of a series of 0x55 is scramble (whitened), and therefore more difficult to recognize. However, after scrambling it is still identical for all packets.

raw data 25 8A F9 59 DA 02 7E 15 ED 67 13 F1 85 D3 AC D2   [payload]   13 E6 84 A8 3B 
descramb 48 BB 55 55 55 55 55 55 55 55 55 55 55 55 55 7E   [payload]   7E 55 55 55 55 
               -------------------------------------- --   ---------   -- -----------
                             preamble                 HDLC  payload  HDLC  postamble

The original Jeelib-based RFM12B programs detection of valid packets was clumsy. Read More

RFM69 OOK compare antenna’s

The antenna design of a module like the RFM69 is important for the sensitivity to sognal and noise. Also antenna positioning is important. Putting an Nucleo STM32 with RFM69CW very close to a PC will result in a increase of several dBm’s in noise floor.

Gain 7 dB sensitivity with JeeNodes

The basic antenna design commonly used is a quarter wavelength wire antenna with ground plane.
quarterwavelengthantenna
From this informative paper from HopeRF, the manufacturer of the RFM69. Such an antenna has a 1/4 wavelength monopole, and a ground plane that serves to reflect (mirror) the wire so that one gets a half-wavelength dipole effect.

The 86mm wire (at 868MHz) connected to small JeeNode like devices is actually not having much of a ground plane. So this can probably be improved. There are very nice commercial designs for this at 868MHz and 433MHz. A.o from Conrad. So lets putthree 1/4 wavelength antenna’s to the test. The wire is compared to a home build and a commercial 1/4-wavelength with groundplane antenna. (See picture above this article, the blue wire crossing the Nucleo is the wire-antenna). Read More

RFM69 OOK RSSI and optimal bitrate

RFM69 OOK RSSI and optimal bitrate settings are key for proper reception and decoding of “foreign” OOK signals for example form remote controls as FS20, or wireless sensor such as Oregon scientific whether stations. In an earlier post, already some strange behavior of RSSI has been presented. A FS20 RC signal is recorded with 3 different bitrate settings in continuous OOK mode:

At high bitrates, the RSSI signal is much noisier. At 3000bps, the RSSI signal is hardly usable, although the internal bitslicer still can decode the signal, which has bit durations of 400 and 600us. So a too high bitrate will only lead excess noise.

From the 3000bps it can be seen that the RSSI signal is sampled with about 625us intervals. According to the datasheet, the RSSI sample duration depends on the duration of a bit:

t-rssi = 2 * t-bit

So for 3000bps, t-bit=333us, so t-rssi = 666us.
For 32768bps, the t-rssi=61us. As the RSSI signal is recorded with 25us intervals, most of the time two or three adjacent samples will have the same RSSI value.

In an earlier post, it was explained that the internal bitslicer can slice at 1/25 of the bitrate. The fastest signals we want to see have bit duration (ON-time or OFF-time) of 200us (Some Oregon Scientific sensors). So then a low bitrate setting of around 1000bps will do?

From further looking into exact timings or received signals, it appears that this is not true. When looking at a histogram of FS20 signals recorded with 2000bps, it can be seen that distributions of the 400us and 600us signals start overlapping. Also, the OFF-signals can be biased to shorter or longer durations, depending on the choice of OOK-PEAK or OOK-FIXED mode. As a result, the signal cannot be reliable decoded.

FS20 histo 2000bps

Now this is a bit messy. An ideal signal has both ON and OFF pulses taking either 400 or 600us:
FS20bit
Deciding whether a bit is a zero or one, should simply testing whther the pusle duration is longer or shorter than 500us. Clearly that does not work. Also note it is an odd signal. It has many zero-bits, and only 11 one-bits.

When moving to a higher bitrate (32768bps), the variation on the bit-timing is greatly reduced, and it also appears that the timing is hardly dependent on the OOK-PEAK or OOK-FIX setting.

FS20 histo 32768bps

In conclusion, the bitrate should be high enough for reliable bit timings, but not higher then needed, as a lower bitrate means a better noise filtering.

Plugwise-2-py with reconnecting websockets

One of the problems with the Plugwise-2-py web application (Plugwise-2-web.py) was that when a computer running a browser with the web client fell asleep, that in the next session the page had to be manually reloaded to get the websocket stream of power readings started again.

This seemed easy to fix, with a timeout call in the javascript or something like that. But before coding this I thought of gooling it. And of course it did already exist.
https://github.com/joewalnes/reconnecting-websocket
It did not only exist, but also got it working within 30 minutes. Reliably! Read More

SSL/HTTPS – Grade A+ python SimpleHTTPServer

After adding SSL to my HTTPWebSocket server, I found that originally it was not so secure due to the fact the the linux distribution I used did not get essential security updates. I used Qualsys SSL Labs: https://www.ssllabs.com/ssltest/analyze.html to analyze the security level of my server. Well, it started out with ‘grade E’. Finally, I ended up with ‘grade A+’. These are the steps to follow: Read More

SSL/HTTPS – Secure Web and WebSocket server in python

As a next step, I created a SSL/HTTPS – Secure Web and WebSocket server in python. It can be found in github as wotking example and as (updated) gist:
https://github.com/SevenW/httpwebsockethandler
https://gist.github.com/SevenW/47be2f9ab74cac26bf21

In this post, I described how to setup a python webserver that servers normal webpages, as well as websockets at the same port. In other words, at the same page. I real application using it is the Plugwise-2-py web application. This application can actually switch on and off lights, so there are some demands on its security and robustness.

Enabling SSL/HTTPS in a python webserver is actually very simple. Read More

SSL/HTTP – Securing the ODROID-XU

Ubuntu server 14.04 LTS does not get security updates to the ARM repository. Despite LTS standing for Long Term Support. Something that I did not expect.

When running webservers with SSL HTTPS on the Odroid-XU, it is vulnerable to several security issues, such as the POODLE and CCS Injection Vulnerability (CVE-2014-0224). This is solved in more recent versions of OpenSSL, but those are not available from the ARM repositories. To solve this OpenSSL can be build from source. CVE2014-0224 is solved from OpenSSL 1.0.1h, and POODLE from 1.0.1j. Generally it is best to install the most recent version of OpenSSL. The following steps describe how to get the job done. This is assuming the build is performed as the root user. Otherwise sudo may need to be added before the make install and cp and ln commands:

#update openssl to fix various SSL vulnerabilities
wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz
tar xzvf openssl-1.0.1m.tar.gz
cd openssl-1.0.1m
./config --prefix=/usr/ --openssldir=/etc/ssl shared
make #make -j5 fails!
make install

cp -a /lib/arm-linux-gnueabihf/libssl.so.1.0.0 /lib/arm-linux-gnueabihf/libssl.so.1.0.0.backup
cp -a /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0.backup
ln -sf /usr/lib/libssl.so.1.0.0 /lib/arm-linux-gnueabihf/libssl.so.1.0.0
ln -sf /usr/lib/libcrypto.so.1.0.0 /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0

Then to check whether the build succeeded, extended version information can be retrieved. Read More