Using Node-RED for publishing Telldus Live data to MQTT

Tellstick Net and DuoTelldus has a set of nice little gadgets (“Tellstick”, for short) that both allow you to control remote switches over radio (433.92 MHz), and to read sensors transmitting on that same frequency. Telldus also has a backend service, Telldus Live, which offer Tellstick users scheduling features (turning lamps on/off at certain times, or when certain conditions occur), as well as showing the latest sensor readings.

The above is at least true if you have a Tellstick Net, which connects to your home network and sends device and sensor data to the Telldus Live service. You can also achieve the same thing with the non-connected Tellstick models, and an always-on computer running Telldus’ software.

Anyway – let’s assume that Telldus Live can see your switches, sensors and other connected devices. Would it not be cool if you could bring all that data into Node-RED, and from there create whatever feature you dreamt of.

How about sending an SMS when the  garage door is still open, but your presence data indicate that you have left for work? Easy.

Or the opposite: Send a tweet to your Node-RED server, which will then fire off an event to Telldus Live, turning a switch on, and by doing so closing the garage door? No problem.

Continue reading “Using Node-RED for publishing Telldus Live data to MQTT”

Enabling Mosquitto websockets on Synology NAS

Websockets are cool. They are the modern sibling of http in that they run over tcp, but "EthernetCableBlue2" by Raysonho @ Open Grid Scheduler / Grid Engine - Own work. Licensed under CC0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:EthernetCableBlue2.jpg#/media/File:EthernetCableBlue2.pngwebsockets offer a lot more, most notably full duplex (i.e. data can be sent in both directions) and realtime delivery of messages.

Those two features enable the creation of web pages that update dynamically as soon as new data is available on the server. No need to reload the web page in the user’s browser.

I have been struggling with how to get websockets integrated with MQTT on my Synology DS1515+ NAS, but in the end it turned out to be pretty easy!

Continue reading “Enabling Mosquitto websockets on Synology NAS”

CrashPlan stopped working after Synology DSM 5.2 update

DS1515+

 

I must say I am pretty happy with the backup solution here. It took a few years to find a setup I am happy with, but this one works:

 

  • Storing important files and data on the Synology DS1515+, with ca 8 TB disk (effective raided size) and 2 SSD drives for cache.  Using WD Red 5TB SOHO NAS SATA-600 drives as main storage.
  • Using CrashPlan to add another layer of off-site backup for data on the DS1515+.
  • CrashPlan running on the DS1515+ also receives backups from a bunch of other computers, both around here and for friends and family.

Continue reading “CrashPlan stopped working after Synology DSM 5.2 update”

More memory for Synology DS1515+

Update: Let’s work together and capture data on what memory modules work, and which don’t, on the DS1515+ and other Synology NAS models!

 

As noted in a previous post, a new Synology DS1515+ NAS landed here the other week. It’s a very nice products in most respects, but a couple of rather annoying details bring the overall impression down – more on that in a later post.

The DS1515+ ships with 2 GB of RAM, with an extra, empty memory slot available for memory upgrades. 2 GB is really on the low side if you intend to run additional applications on the NAS. CrashPlan for example is built on Java, which is pretty resource hungry to begin with, then the memory consumption goes up with the number of files backed up.

Synology specs tells us that a 4 GB SO-DIMM can be added, for a total of 6 GB. Stories from the Synology forum however indicate that it is quite possible to replace both the internal (some disassembly required, probably voiding warranty..) and user accessible RAM modules, for a total of 16 GB RAM.

With a bunch of different SO-DIMM modules in the drawers here, let’s test them to see which ones can be used with the DS1515+ and which ones cannot.

Continue reading “More memory for Synology DS1515+”

A new NAS arrives – meet the Synology DS1515+

The trusty Netgear ReadyNAS 312 has served very well over the past couple of years, and is still doing ok. It has however started to run out of space, and even though the disks could be replaced by bigger ones, it was time to move to something larger.

As much as I have come to like the ReadyNAS products in general, and the support forums in particular, it would be interesting to try something else. The Synology products seems to have a loyal following, the UI seems nice, and said to have good build quality.

The new DS415+, DS1515+ and DS1518+ models came out recently each sporting a quad core Atom C2538 CPU, that was quite tempting… The 415+ has two Ethernet ports, while 1515+ and 1518+ both have FOUR 1 Gbit ports. Nice.
A quick check on the Synology forums indicate that they are very active and at least as extensive as the Netgear/ReadyNAS ones. That’s just at first glance though – time will tell if there is both volume and quality there.

Continue reading “A new NAS arrives – meet the Synology DS1515+”

A new home for the blog

 

DO_Logo_Vertical_Blue-75e0d68b

Change for the sake of change?

Maybe… or a chance to learn something new.

 

Either way, this blog has now been moved away from WordPress.com to a new host.

After a fair bit of research, the decision was to go with the Virtual Private Servers offered by Digital Ocean.

With monthly plans starting at USD 5 per month it is very affordable to get started, but still easy to grow into larger servers if/when needed.

Pre defined templates for all sorts of different application servers (including WordPress) made it super simple to transfer the blog from wordpress.com – in less than 15 minutes the blog was serving pages from the new host. Nice!

Fixing bash Shellshock vulnerability on Raspberry Pi

The recent bash vulnerability, a.k.a. “Shellshock”, is pretty bad, considering it might actually have been around for a very long time, maybe even dating back to the predecessor of bash. Not good.

So what about Raspberry Pi’s?
Are they vulnerable?

Turns out they are, but there is already a fix available for them and patching a Raspi is very simple. Whether your actual Raspi is vulnerable depends on what distribution you are using, and how recently you upgraded the software in it.
The Raspi used below is running IPE-R1, which is a blackout-proof version of Raspian.

First let’s find out what bash version we have:

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1
root@raspi-2:~#

You can also run this little script to determine whether your Raspi is vulnerable to Shellshock

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;
WARNING: SHELLSHOCK DETECTED
root@raspi-2:~#

Let’s fix this. Just refresh the repos and upgrade bash (the patched version is available in the main repos).

root@raspi-2:~# apt-get update && apt-get install --only-upgrade bash
Get:1 http://archive.raspberrypi.org wheezy Release.gpg [490 B]
Get:2 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
Get:3 http://archive.raspberrypi.org wheezy Release [10.2 kB]
...
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
 bash-doc
The following packages will be upgraded:
 bash
1 upgraded, 0 newly installed, 0 to remove and 54 not upgraded.
Need to get 1,443 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main bash armhf 4.2+dfsg-0.1+deb7u3 [1,443 kB]
Fetched 1,443 kB in 1s (1,386 kB/s)
(Reading database ... 29754 files and directories currently installed.)
Preparing to replace bash 4.2+dfsg-0.1 (using .../bash_4.2+dfsg-0.1+deb7u3_armhf.deb) ...
Unpacking replacement bash ...
Processing triggers for man-db ...
Setting up bash (4.2+dfsg-0.1+deb7u3) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
root@raspi1:~#

The installed version of bash is now +deb7u3

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1+deb7u3
root@raspi-2:~#

The short test script above also returns nothing:

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;
root@raspi-2:~#

You could of course also just do an “apt-get upgrade” to upgrade all packages on your Raspi, would take a bit longer but will work just as well.
Also, if you are not logged in as root you need to do a “sudo apt-get update”, of course.

Raspberry Pi won’t boot – only red power light comes on – SD card corrupt? Not so fast…

After having problems with SD cards failing after a few months in a Raspi that was supposed to be always-on, it was time to look for options.

The IPE distribution seemed like a perfect match – it effectively makes the Raspi only use a ramdisk, except possibly during boot. When needed the SD card file system can be made writeable, meaning that apt-get etc can be used as usual to install apps.

This worked great for ca 3 weeks, then this setup ALSO failed, with the same symptoms as before: at boot only the red power light would come on – nothing else. A fresh SD card with a fresh copy of IPE worked fine in the same Raspi hardware, thus not the Raspi itself that had fried (the cabinet where it lives is kind of warm, nothing too crazy though).

Now the weirdness starts for real. The failing SD card works perfectly fine when inserted in both an iMac and a Windows laptop. I spent hours and hours reformatting the card with various low-level tools, then writing the standard Raspian image to the card. Just for reference I did the same to a third SD card too, that card was identical to the failing one.

Still the same issue: that one card would still prevent the Raspi from booting.

The card in question is a Kingston 16 GB microSDHC card marked SDC4/16GB 081. It comes with an adapter that makes it usable also in large SD card connectors.

Photo on 11-09-14 at 06.52 #2

Finally, and I of course should have thought of this sooner, I tried swapping the two different microSD to SD adaptors. And of course… the solution was simple. It was not the SD card that had failed, it was the adapter. For some reason (heat? just poor quality?) the adapter had a small crack in its plastic housing, and as a result most likely some poor connection inside, between the microSD card itself and the surrounding adapter. When inserted into a proper computer, there was probably enough pressure on the adapter to squeeze it against the actual microSD card, while the SD card holder on the Raspi is kind of flimsy, and did not provide the needed pressure. When using a working adapter all three microSD cards work flawlessly in the Raspi.

Note to self: Use full sized SD cards in Rasperry Pis….

 

 

 

 

ReadyNAS RN312 + 8GB RAM = FAIL

My RN312 has worked flawlessly since the upgrade from the standard 2 GB RAM to 4 GB ditto. I would however like to run some memory intensive applications on the NAS, so an upgrade to 8GB would be nice. Turns out this is not as easy – might not even be possible.

I have tried both a Kingston KVR1333D3S9/8G, and a DDR3 1600 from my iMac – no luck. Guess the RN312 just does not support 8GB – too bad.

By the way, the 4GB SODIMM that does work is a Hynix HMT351S6BFR8C.

Burning ISOs to USB sticks on Mac / OS X

For some reason i cannot get the easy-to-use tools out there for burning ISOs to work… Command line to the rescue:

First, make sure Homebrew is installed. It is strictly not needed for the burning-to-thumb-drive process, but will enable the progress indicators, which are quite nice to have for long running tasks. Now install Pipe Viewer from Homebrew:

[code language=”bash”]

$ brew install pv

[/code]

Now we need to figure out the device name of our USB drive. In a terminal window (you are using iTerm2 – right? Infinitely better than OS X built in Terminal app):

[code language=”bash”]

$ diskutil list

#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 250.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *320.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS SSD backup 180.0 GB disk1s2
3: Apple_HFS Temp 139.6 GB disk1s3
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Macken_Ext Backup 999.9 GB disk2s2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *8.0 GB disk3
1: DOS_FAT_32 WHEEZY 8.0 GB disk3s1
$

[/code]

/dev/disk3 is the USB thumb drive. I previously had another Wheezy image on it, thus its name.

Now unmount it:

[code language=”bash”]

$ diskutil unmountDisk /dev/disk3
Unmount of all volumes on disk3 was successful
$

[/code]

Nice. Now let’s write the ISO to the drive:

[code language=”bash”]

$ pv -petr ~/Desktop/debian-7.2.0-amd64-DVD-1.iso | sudo dd of=/dev/disk3 bs=128k
Password:
0:00:38 [4.94MiB/s] [====>                  ] 3% ETA 0:16:55

[/code]

Now let’s wait. Looks like it will take approximately another 17 minutes..

When done, just eject the thumb drive as usual, remove it and you have a bootable Debian install drive. Mission accomplished.