Aug 252015
 

Amazon recently competed their Alexa/Echo integration with SmartThings after previously integrating a number of other home automation hubs like Wink and Hue. I jumped on it as soon as it was available in the Alexa iOS app.

Setting up SmartThings with Amazon Alexa (Echo)

As with other SmartThings integrations, the first step will request an OAUTH login to SmartThings, and allow the user to select which devices can be shared with Alexa. At this time, only switch type devices (including virtual switches) appear to be supported. Sensors, complex/multi-types like thermostats, and modes are not supported at this time. After selecting the devices to grant permission, run the discover devices command on Alexa to enables them in the app as well as Alexa voice control. Amazon Alexa also allows the grouping of different devices to make it easier to turn several switches off or on at the same time.

Amazon Alexa device groups SmartThings devices in Amazon Alexa

How well does it work?

As mentioned above, mode changes and phrases are not supported out of the box with this integration, so I’ve been using virtual switches and the “Big Switch for Hello Home Phrases” app (an example of usage here) to create switches that control the mode. So now I can say “Alexa, turn on goodnight”, which will trigger the virtual switch to run “Goodnight!” on SmartThings.

I’ve been using SmartThings with Z-wave switches to control lights and other items. The response time with Echo/Alexa has been quite good – a voice command takes effect in roughly a second. See the following video for a simple z-wave switch demo I recorded – note that Alexa seems to do well with natural speaking pace, rather than other systems which can sometimes hitch between keywords and commands.

Voice control has been a mixed bag over the last few years.  I have had mixed results from a number of different offerings.  However, I’ve been pleasantly surprised at how well Alexa does with voice commands. I’ve been yelling commands from all over the house for a couple of days and Alexa has yet to get a single command wrong. I’m very impressed so far.

Jul 022015
 

CrashPlan Issue For Synology – Fixing the 4.3.0 update

If your Synology NAS can run docker, you may want to consider an alternative to the CrashPlan package. See here: CrashPlan and CrashPlan Pro on Synology using Docker

Note, see bottom of page for information on DSM 6 and CrashPlan 4.6.0

Recently CrashPlan updated to version 1427864400430, which broke the CrashPlan package Patters had created for Synology installations again. They then (July 2nd?) released 1427864410430 as well, which means that if your CrashPlan installation on Synology broke with version 1427864400430, you will need to upgrade, wait for it to break again, and then fix with version 1427864410430. In general the fix process has been the same over the last few breaks, and I’ve outlined those steps below for the latest version.

There is one major change introduced from CrashPlan. Starting with the 1427864400430 update, a guid (think of it as a key) is needed to securely log into the headless client. Thanks to Mathew Stocks, I’ve made those instructions available as well.

The log for the failing CrashPlan package would look something like this for a failing 1427864400430 upgrade:

Upgrades available at central.crashplan.com:443
Downloading a new version of CrashPlan.
Download of upgrade complete – version 1427864400430.
Installing upgrade – version 1427864400430
Upgrade installed – version 1427864400430
CrashPlan stopped, version 4.2.0, GUID 559750658046558476

If the package was attempted to start again, it would write a line similar to the following, and then stop:

Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1427864400430.

Note that the following instructions are for the 1427864410430 upgrade, which is the latest (as of July 2nd, 2015) update. If your Synology didn’t make it to this version, run the following steps, but substitute “1427864400430” where there are any references to “1427864410430”.

Connect as root to SSH

First, connect to Synology using SSH and the root account (uses admin password).  Connecting as the admin account will give you permission failures!

In SSH, run commands to extract the update

In SSH, run unique command to cleanup the package

The next command will be different for everyone, as part of the file path is randomized.  In this case, you will need to see what your path is first by running ls, and then editing the second statement below, replacing whatevervalue with the rest of  your path:

Start CrashPlan package, check log

After the above completes, you should be able to start the CrashPlan package again in Synology and get it running once more. The log should show:

CrashPlan started, version 4.3.0 GUID 559750658046558476

Get the headless key from the .ui_info file

While connected to SSH as root, run the following command to get the headless key file. The funky formatting of this command is because the file does not contain the special newline character:

The command will output a line similar to the following (everyone’s will be different):
4243,13d436c0-230a-4242-b258-574e60e62a9f

Update .ui_info on the computer connecting to Synology

On the computer where you are connecting to CrashPlan on Synology, go to the .ui_info file under the CrashPlan directory. NOTE: I had to manually upgrade my computer’s version of CrashPlan (via https://www.code42.com/crashplan/thankyou/) in order to see the .ui_info file.

Typically on Windows, this will be found under:
C:\ProgramData\CrashPlan\.ui_info

Or on a Mac in the following location (need to have finder set to show hidden files):
/Library/Application Support/CrashPlan/.ui_info

Enter in the new key in the file, replacing the current value, and save it. You should now able able to connect to the headless client. Note that you may need to also update the values in ui.properties again if you had to upgrade CrashPlan.

CrashPlan 4.6.0

There are some tools referenced in the comments for this page which might make upgrades easier for some people. But I’ll also give the latest files & paths using the original instructions above – the following commands can be used for v4.6.0:

unzip -o /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "*.jar" -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "lang/*" -d /var/packages/CrashPlan/target/

Find latest package folder:
ls -l /var/packages/CrashPlan/target/upgrade/1435813200460_382.*

Replace the whatevervalue with the folder name:
mv /var/packages/CrashPlan/target/upgrade/1435813200460_382.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435813200460_382.whatevervalue/upgrade.sh.old

Synology DSM v6

I don’t recommend upgrading to v6 at this time (March 2016) if you do not have an Intel based CPU in your Synology NAS as there have been issues reported with the java packages in the comments here as well as on Patter’s page. If you do have an Intel based CPU you will need to use 7z commands on DSM6 instead of zip commands. Examples for CrashPlan 4.6.0:
sudo 7z e -y -o/var/packages/CrashPlan/target/lib /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "*.jar"
sudo 7z e -y -o/var/packages/CrashPlan/target/lang /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "lang/*"

May 122015
 

The latest round of updates from CrashPlan (4.3.0) has broken the CrashPlan package on Synology again. Please see http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/ for the newest instructions.

Archived information for 4.2:

After installing Synology DSM 5.2, CrashPlan recently pushed an update (4.2.0) which broke the CrashPlan package Patters had created for Synology. The log for the failing CrashPlan package would look something like this:

CrashPlan started, version 3.7.0, GUID 559750658046558476
Upgrades available at central.crashplan.com:443
Downloading a new version of CrashPlan.
Download of upgrade complete – version 1425276000420.
Installing upgrade – version 1425276000420
Upgrade installed – version 1425276000420
CrashPlan stopped, version 3.7.0, GUID 559750658046558476

If the package was attempted to start again, it would write a line similar to the following, and then stop:

Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1425276000420.

This seemed to be similar to the previous issue seen in 3.7.0, so I used the following steps to fix crashplan on my synology box: Note that this will likely be fixed by Patters soon, this is just a workaround if your CrashPlan install has stopped as a result of the 4.2.0 update.

Connect as root to SSH

First, connect to Synology using SSH and the root account (uses admin password).  Connecting as the admin account will not give you enough permissions.

In SSH, run commands to extract the update

In SSH, run unique command to cleanup the package

The next command will be different for everyone, as part of the file path is randomized.  In this case, you will need to see what your path is first by running ls, and then editing the second statement below, replacing whatevervalue with the rest of  your path:

Start CrashPlan package, check log

After the above completes, you should be able to start the CrashPlan package again in Synology and get it running once more. The log should show:

CrashPlan started, version 4.2.0 GUID 559750658046558476

Jan 102015
 

If you recently upgraded to DSM 5.2 and had CrashPlan break, this is likely due to the CrashPlan 4.2.0 update. Please see http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/

NOTE: This manual fix should no longer be needed after the 0029 update from Patters:

0029 Updated to CrashPlan version 3.7.0, improved detection of temp folder (prevent use of /var/@tmp), added support for Annapurna Alpine AL514 CPU (armhf) in DS2015xs, added support for Marvell Armada 375 CPU (armhf) in DS215j, abandoned practical efforts to try to support Code42’s upgrade scripts, abandoned inotify support (realtime backup) on PowerPC after many failed attempts with self-built and pre-built jtux and jna libraries, back-merged older libffi support for old PowerPC binaries after it was removed in 0028 re-write

Archive content:
CrashPlan recently pushed an update (3.7.0) to all clients which broke the CrashPlan package Patters had created for Synology. The log for the failing CrashPlan package would look something like this:

CrashPlan started, version 3.6.4, GUID 574956158631543214
Upgrades available at central.crashplan.com:443
Downloading a new version of CrashPlan.
Download of upgrade complete – version 1388728800370.
Installing upgrade – version 1388728800370
Upgrade installed – version 1388728800370
CrashPlan stopped, version 3.6.4, GUID 574956158631543214

If the package was attempted to start again, it would write a line similar to the following, and then stop:

Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1388728800370.

After some investigation by Stig, Casper, and Harv on the comments for the package a working solution was found to manually install the update files and disable the failing upgrade.sh file. Note that this will likely be fixed by Patters soon, this is just a workaround if your CrashPlan install has stopped as a result of the 3.7.0 update.

1. First, connect to Synology using SSH and the root account (uses admin password).  Connecting as the admin account will not give you enough permissions.
2. Run the following commands:

 
3. The next command will be different for everyone, as part of the file path is randomized.  In this case, you will need to see what your path is first by running ls, and then editing the second statement below, replacing whatevervalue with the rest of  your path:

4. After the above completes, you should be able to start the CrashPlan package again in Synology and get it running once more.