Category: SmartHome

  • How to create a recursive Timer in OpenHab3’s DSL Rule

    I wanted a DSL Script to send a notification email if a door was still opened after several checks.

    There are various options to achieve this purpose.

    Click to Read More

    A simple option could have been to use a Switch Item with an Expire Property. When the door opens, set that Switch Item to ‘ON’ and initialize a Number Item to be count how many checks will be done. When the Switch Item expires, execute a script which checks if the door is still opened. If it is not, that script ends. Otherwise, it increases the Item Number. If that Item Number is lower than the maximum checks to be done (your threshold), Set back the Switch Item to ‘ON’. Otherwise, send the notification email.

    Another option (just for fun) relies on a DSL Script with a lamdba expression which creates a Timer calling itself recursively until the door is closed or your threshold is reached. That DLS Script must be called when the Door opens.

    Here after a Number Item SensorGarageDoor_Duration is used to count the number of checks: The Item SensorGarageDoor_OpenClose is the state of the Sensor on the Door.

    val int treshold = 3
    var int attempt = 0
    // Define a Lambda Expression to check if the Door is open and if not,
    // call itself after 15 minutes to check again until a treshold of calls is reached
    val Functions$Function1 Monitor = [	Functions$Function1 recursive |
    	if (SensorGarageDoor_OpenClose.state == OPEN) {
    		logInfo("default.rules", "Monitor Opened Door")
    		createTimerWithArgument(now.plusMinutes(15), recursive, [ Functions$Function1 callMonitor |
    				var int duration = (SensorGarageDoor_Duration.state as Number).intValue + 1
    				logInfo("default.rules", "Garage Opened since " + duration.toString + " cycle(s)")
    				if (duration == treshold) {
    					logInfo("default.rules", "Notify by email that Garage still Opened after " + duration.toString + " cycles")
    					val mailActions = getActions("mail", "your smtp binding")
    					val success = mailActions.sendMail("your from", "your subject", "your message")
    				} else if (duration < treshold) {
    	} else {
    		logInfo("default.rules", "Stop monitoring Door")
    if (SensorGarageDoor_Duration.state != NULL) {
    	attempt = (SensorGarageDoor_Duration.state as Number).intValue
    } else {
    	attempt = treshold
    if (attempt >= treshold) {
    	logInfo("default.rules", "Request for monitoring Opened Door")
    } else {
    	logInfo("default.rules", "New request for monitoring Opened Door ignored")

    One of the trick is to pass the Lambda Expression as parameter to the Timer (Created with createTimerWithArgument). Indeed, a Timer may not call a “Global” Lambda Expression. To get a Lambda Expression as parameter, this parameter must be defined as Functions$FunctionX (where X is the amount of parameters of the Lambda Expression). In my sample above, my Lambda as one parameter which is itself, to be passed to the Trigger (So, it is typed Functions$Function1).

    You must type explicitly the parameters as Functions$Function1 to be able to use the method “apply()”.


  • Easily Backup openHab into a Shared Folder

    I am running openHab2 on my raspberry pi 4 using openhabian and I wanted to schedule a backup of my config into a shared folder of my Synology.

    Backup as root

    Openhabian’s backup solution ‘Amanda’ didn’t convince me to automate such a backup. So I wrote my own backup script and scheduled it with a cron job.

    First, create a shared folder named “backups” on your Synology via Control Panel > Shared Folder > Create:

    Next, create a user account named “backup” via Control Panel > User > Create:

    Grant that account write access on the shared folder “backups” via Control Panel > User > backup > Edit > Read/Write

    The Synology part being ready, move now to openhabian, on the RPI, using a ssh console (E.g.: Putty) to create and schedule the backup script. Most parts will have to be done as ‘root’ (to make it simpler… but no safer), so type;

    sudo -i

    If just like me you previously tried to configure the backup with Amanda, using the command “sudo openhabian-config” and then the menu 50 > 52, a mailer daemon (exim4) was probably installed and you want now to remove it… Check if it’s running (not with the command “systemctl –type=service –state=running” but) with:

    sudo service --status-all

    If you see a + in front of exim4, disable and remove it

    sudo systemctl stop exim4
    sudo systemctl disable exim4
    sudo apt-get remove exim4 exim4-base exim4-config exim4-daemon-light
    sudo rm -r /var/log/exim4/

    You can also next uninstall and remove Amanda

    sudo apt remove amanda-client
    sudo apt remove amanda-server
    sudo rm -r /var/lib/amanda/
    sudo rm -r /etc/amanda

    Now, we can start with the preparation of the backup script. Define first a mount point on your RPI. E.g.: “/mnt/backups”:

    mkdir /mnt/backups

    Define next the shared folder of your Synology by editing the fstab file:

    sudo nano /etc/fstab 

    Add the line here under in that file and save your change with CTRL-o, Enter, CTRL-x:

    //<ip of your Synology>/backups /mnt/backups cifs username=backup,password=<password>,uid=1000,gid=1000,vers=3.0 0 0

    Attention: the network is usually not yet available when the fstab file is used to mount the drives a boot time. So this shared folder will most probably not be mounted automatically!

    Create a file:

    nano /home/openhabian/

    with the backup script here under:

    # Backup Openhab of Synology

    echo $(date) "Run openhab maintenance: $0" >> $log

    if mountpoint -q /mnt/backups
    echo $(date) "Synology's backups share is mounted." >> $log
    echo $(date) "Synology's backups share is not mounted. Try to mount as per fstab definition." >> $log
    sudo mount /mnt/backups
    sleep 3
    if mountpoint -q /mnt/backups
    echo $(date) "Synology's backups share is now successfully mounted." >> $log
    echo $(date) "Synology's backups share cannot be mounted." >> $log

    if mountpoint -q /mnt/backups
    # Keep the 10 last backups
    rm -f $(ls -1t /mnt/backups/Raspberry/openhab2-backup-* | tail -n +11)
    sudo ./runtime/bin/backup /mnt/backups/Raspberry/openhab2-backup-"$(date +"%Y_%m_%d_%I_%M").zip" >> $log
    echo $(date) "custom backups of openhab completed." >> $log
    echo "-----------------------------------------------------------------" >> $log

    Make that script executable (for all users…)

    sudo chmod a+x

    To run that script as root on a regular basis, you have to schedule it as root (using now sudo explicitly if you didn’t type sudo -i earlier) via crontab:

    sudo crontab -e

    If it’s the first time you run crontab, you will have to pick your prefered editor. I advice nano 😉

    Select an editor. To change later, run 'select-editor'.
    1. /bin/nano <---- easiest
    2. /usr/bin/vim.basic
    3. /usr/bin/mcedit
    4. /usr/bin/vim.tiny
    5. /bin/ed

    Choose 1-5 [1]: 1

    In crontab, add this at the end and ave that change with CTRL-o, Enter, CTRL-x:

    0 1 * * * /home/openhabian/

    Notice: if you want to mount the shared drives at boot, which usually fails as mentioned previously as the network is not yet available when fstab is first called, you can add this in the crontab too:

    @reboot sleep 300; mount -a

    You can now try the script with:

    sh /home/openhabian/

    If it works, it should also work when triggered by the cron job.

    Backup as openhabian

    To run scripts as root is usually not recommended. But the backup script of openhab may only be run as root… We could run it with the account ‘openhab’, but the backup files will belongs to the user ‘openhabian’, making the cleanup tricky. I you really don’t want to run and schedule my script as root, then the best option is to run it with the account “openhabian”:

    Still being is root mode (sudo -i), create the log file manually and grant access for all users:

    touch /var/log/maintenance.log
    chmod a+rw /var/log/maintenance.log


    Authorize the user “openhabian” to execute the backup script “/usr/share/openhab2/runtime/bin/backup”. To do this, you have to create a file in the /etc/sudoers.d folder. All files in that folder are used by the “sudo” command to authorize configured users to execute specified commands as root, with or without password. You MUST ABSOLUTELY edit that file with the command “visudo“. This one will check that your changes are valid. If you edit that file with another editor and it contains an error, you won’t be able to use the “sudo” command anymore (you will have to plug the SD card into a USB adapter on another raspberry to fix the issue or to simply delete the invalid file. USB device are automatically mounted under /media/usbxxx if you installed the package usbmount).

    visudo /etc/sudoers.d/openhab

    In that file, add the line here under and save your change with CTRL-o, enter, CTRL-x

    # Allow openhabian user to execute the backup script
    openhabian ALL=(ALL) NOPASSWD: /bin/mount, /usr/share/openhab2/runtime/bin/backup


    Unschedule the script from root’s crontab (remove the line added with crontab -e)

    crontab -e
    0 1 * * * /home/openhabian/


    And schedule it now within openhab’s crontab (has to be done as ‘openhabian’  user)

    sudo -u openhabian crontab -e

    And add

    0 1 * * * /home/openhabian/


    Et voilà.


    PS.: If you experience issues when mounting the remote shared folder, try to mount it interactively (using an administration account of  your Synology or an account having a password without symbols such as %, # or !)

    apt install smbclient 
    smbclient //<remote ip>/<shared folder> -U <user account>

    You can also check the latest messages from the kernel

    dmesg | tail -n10


  • Philips Hue lights Bulbs and Accessories become unreachable

    Regularly, my Philips Hue lights and accessories do not respond anymore. Looking into the Philips Hue App, they appear as “Unreachable” (no link). The solution was to avoid WiFi interference!

    Click to Read More

    In French, the message displayed by the App, for the Lights and accessories, is “impossible d’établir le lien”.

    If your Philips Hue lights aren't responding, maybe it's time to ...


    Notice that each time, a few bulbs and accessories were still connected and the App was perfectly able to connect onto the Bridge, both via Internet and via my local Network. Notice also that I have many Philips Hue Light Bulbs, Sensors and Dimmer Switches in the house (less than 50, which is the theoretical maximum for a Philips Hue Bridge) as well as a few Tradfri Bulbs in the corridors.

    I really spent hours to investigate this issue which occurred once every few months …

    • Unplug the power supply of the Philips Bridge for 30 sec.
    • Switch off all the lights for 30 sec.
    • Remove the Bulbs from their sockets.
    • Press the 4 buttons of the remotes (Philips Hue Dimmer Switch) all together for a few seconds (until the led start to blink red/green).
    • Press both the On and Off buttons of the remote to reset the Bulbs.
    • Turn on/off the lights quickly several times (and do an incantation for Apollo).
    • Delete and Re-add again the lights and accessories within the App.
    • Go through the whole FAQ of Philips Hue.
    • Drink a bottle of wine and cry alone in my sofa.
    • etc…

    I was always finally switching off all electric devices which were possibly disrupting the Zigbee signals : my routers, my wifi access points, my other Bridges (Tahoma Somfy, Z-Wave, …) … and even powering off the whole house… This extreme action was solving the problem ! But impossible to conclude what was the precise root cause.

    Today, the problem occurred again. After various unsuccessful attempts (those mentioned above),  I read on a blog that the quality of the ethernet connection between the Philips Hue Bridge and Internet matters ?!? And I realized that my Bridge was plugged into a Devolo Powerline Adapter (Ethernet via Power Sockets). I also remember that in the past, unplugging and replugging that Devolo Powerline Adapter was an action I did and which solved the problem (but I actually did this to restart the various Bridges and WiFi access points connected onto it).

    So, I moved the Philips Hue devices from that Adapter into the main Ethernet Router and boom, it worked !

    Et voilà ? Really not sure. The ethernet connection is only for the Bridge to have access on a Wifi Access Point and be able to connect with the mobile App… The bulbs and the Bridge are connected via Zigbee. So, there  must be another reason hidden behind this (fake) “solution”.

    Note that the Phillips Hue Light Bulbs, even though they are Zigbee, do not act as repeaters for anything except other Light Bulbs on the same Hue bridge if they are connected to the Hue bridge (They use actually a “Zigbee Light Link” protocol instead of the regular Zigbee).

    As I noticed that the disconnected Bulbs are often the Tradfri ones and the Philips Hue far from the Bridge, I thought that the problem was possibly more with the Tradfri light bulbs not receiving/repeating properly the signal for the Philips Hue light bulbs ? Two possible options:

    • Replace the cheap Tradfri light bulbs with expensive Philips Hue light bulbs. I will do so soon or later…
    • Investigate why receiving/repeating the ZigBee signal could fail… I can start with this.

    It’s often mentioned on the web that ZigBee can suffer for WiFi interferences. It shares the same 2.4GHz wireless band as WiFi routers and overlaps by default with the Wifi channel 11 ( And indeed, moving the Philips Hue Bridge or Turning On/Off all Wifi Devices in the house used to solve, at least temporarily, the problem.

    Ex.: Zigbee channels 21 to 24 overlaps with WiFi channel 11 as illustrated bellow. 

    A first obvious solution  is to disable the WiFi 2.4GHz band and use only the 5GHz band for the WiFi Devices at home. But not all of them support 5GHz…

    Another solution is to change the channel used by the Philips Hue Bridge  to use a ZigBee channel having less conflict with your WiFi (All lights must be powered on). Do the change via Philips Hue App’s settings > Hue Bridges > touch the “i” of the Bridge to update > ZibBee channel change > Change Channel.

    It will take about 30 seconds, but the Hue system will change the channel to another one automatically. Once done, the lights should all come back online (And indeed, this did the trick once for me too, without doing any other action). If they don’t, turn them on and off again at the main light switch/plug socket. Possible Zigbee channels are 11, 15, 20 and 25

    Philips Hue Zigbee channel

    Also you can try to move the Philips Hue Bridge to another location, not too close of the WiFi access points and in central location regarding the various ZigBee devices. This is what I did by connecting the Bridge directly on the Router (So the solution was not the improvement of the ethernet connection quality, but most probably a lower WiFi interference next to that Router).

    Notice that this won’t update the channel used by the Tradfri lights! As explained on Reddit by Erik1971, you can try, after changing the Hue System channel, to power cycle the Tradfri lights (make sure they are not powered for at least 1 minute). This should trigger the Tradfri lights to scan over the channels to join the network again. Best way to do this is to power off all Tradfri lights and keep the Hue Lights and Bridge powered and then one by one power on the Tradfri lights (to prevent that the Tradfri Lights see the other Tradfri lights on the wrong channel and rejoin on the wrong channel).

    So, for the time being, my conclusion is that bulbs and accessories became unreachable due to (many?) new devices connecting on the WiFi or WiFi Access Points changing automatically their channels (This can be checked with an App like Wifi Analyzer).


  • OpenHab: ServiceLocatorImpl has been shut down

    I found a weird error by accident in the openhab.log of my Synology. It was due to the “Localisation” not configured properly in openHab’s System.

    Click to Read More

    I found that error after stopping and starting manually openHab from a SSH console opened on my Synology to solve another issue.

    To stop openHab installed on a Synology as explained here, via a SSH console run as root (as explained here), execute:

    • cd /var/packages/openHAB/target
    • ./runtime/bin/stop

    To restart openHab later execute:

    • ./runtime/bin/start

    NB.: if you execute this command soon after the stop, it won’t work. You can simply re-execute the command a second time.

    Here are more details about the error that I found in the log (located into \\<YourNas>\SmartHome\openHAB\userdata\logs\openhab.log)

    javax.servlet.ServletException: javax.servlet.ServletException: A MultiException has 1 exceptions. They are:
    1. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_2,3,718060201) has been shut down

    at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle( ~[bundleFile:?]
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle( ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.Server.handle( ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.HttpChannel.handle( [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.HttpConnection.onFillable( [bundleFile:9.4.20.v20190813]
    at$ReadCallback.succeeded( [bundleFile:9.4.20.v20190813]
    at [bundleFile:9.4.20.v20190813]
    at$ [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask( [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce( [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce( [bundleFile:9.4.20.v20190813]
    at [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( [bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$ [bundleFile:9.4.20.v20190813]
    at [?:1.8.0_131]

    This error appears because the location is not set in OpenHAB and your browser probably didn’t have the permission to pass its own location to openhab.

    The issue can be resolved by manually via the PaperUI > Configuration > System > Regional Settings.  There, define your language, your country/region, your Time Zone and your location (with a latitude and longitude – or – by moving the openHab pin onto your location).


  • Troubleshoot Z-Wave Controller used by OpenHab

    After reinstalling openHab on a new Synology, I had some ‘Unknown’ Z-Wave devices. The only way to et rid of them was to use “Z-Wave PC Controller” from  Silabs (previously named “Zensys tool”).

    Click to Read More

    This is what was displayed in the Paper UI of openHab:

    To solve this, I had two options:

    The first option was to use the PaperUI’s features of openHab to heal, reinitialize the device or remove the device.

    The other option was to remove my Z-Wave Controller from my Synology, and plug in into a PC to clean it using Z-Wave PC Controller.

    Use PaperUI’s feature

    Select your device via the PaperUI > Configurations > Things, click on the “Edit icon” (The pen in a blue disc) and scroll to click on the “Show More” link :

    There, you have access to the various features :

    Try those two actions:

    • “Heal the device” (See here) : it can be useful when the Z-Wave mesh is messed up and nodes become ‘lost’.
    • “Reinitialise the device” : it does not hurt 😉

    Wait next for a few minutes and refresh your PaperUI to check if the device is know fully recognized. 

    Also check if there are any errors in the logs of openHab: events.log and openhab.log. If you installed openHab on your Synology as explained here, those logs are under the Shared Folder \\<YourNas>\SmartHome\openHAB\userdata\logs\

    Install Z-Wave PC Controller

    The download this software I had to find a “valid” Silabs account. Indeed, standard accounts have no access to the download section. Searching for “” on, we find easily such “valid” account.

    Once authenticated on, go to the Z-wave page here, and go to the “PC Programmer” section and click on Download Z-Wave Programmer

    On the next page, click on the Download button in the upper-right corner (If it is not accessible anymore, find the msi in the attachement section of this post).

    Unzip the archive and install the “PC Controller” (/bin/ZWaveControllerSetup.msi)

    Clean-up your Z-Wave Controller

    Now, plug your Z-Wave controller in your PC and open “PC Controller”:

    Click on the Gear icon in the upper-right corner to configure the software to use your Z-Wave Controller. You should see it in the pane “Serial Port Data Sources”. Select it and click on “Ok” at the bottom-right:

    Now, you have access to all the “data” (Z-Wave devices) configured previously on your controller. Here under, you can see that I have 13 nodes available:

    To check which nodes are not yet available, Click on the top-left tail “Network Management”. This will show you a list of all configured nodes. For each node, one by one, select it and press on “Is Failed”. If the node cannot be accessed, it will be marked in red (See the nodes 23 and 24 here under). You can then remove it by clicking on “Remove Failed”.

    For each remaining node, you could click on “Node Info”. This will collect more information than your controller did when it was connected on your Synology and managed by openHab.

    You can add new devices easily, using the “Add” button. I did it for a Fibaro Heat Controller that I couldn’t add via openHab.

    You can test your Z-Wave Switches using “Basic Set ON” and “Basic Set OFF”.

    You can look at the topology of your mesh, using the tail “IMA Network” and by clicking on “Network Health”.

    Once you have cleaned-up your controller, you can re-plug it into your NAS.

    Unplug/Re-plug a Z-Wave Controller on a Synology

    When you remove and replug such a controller, it usually gets a new “terminal” (=a “new port”). A terminal is physically represented by a file named ‘tty…’ in the /dev folder and is the communication channel between the system (your Synology) and hardwares like the USB devices. By default, the terminal for the Z-Wave controller will be /dev/ttyACM0. But when you remove and replug it, it can get /dev/ttyACM1.

    To check which terminal is used, open a SSH console on your NAS (as explained here) and type: ls -la /dev/ttyA*

    You should get something like:
    crwxrwxrwx 1 openhab dialout 166, 1 Dec 31 14:26 /dev/ttyACM0

    If there are several terminals, unplug to Z-Wave controller, execute the command again and note the remaining names. Next, replug the controller, list again the terminals and compare the list with the one noted previously.

    If the security of the terminal is not crwxrwxrwx, then (assuming the terminal is ttyACM0) execute: sudo chmod 777 /dev/ttyACM0

    If the user is not openhab, then check first that it exists via the Control Panel of your DSM: Control Panel > User.

    If it does not, you have not properly installed openHab on your Synology as explained here. The package is indeed configuring everything itself. If it exists, assuming the terminal is ttyACM0, execute: sudo chown openhab /dev/ttyACM0

    If the group is not dialout, check that it exits via the Control Panel of your DSM: Control Panel > Group. Use “Edit Members” to check that the user “openhab” is in that group. NB.: a group “uucp” must also exist and contain the user “openhab”.

    If not, you didn’t properly install openHab on your Synology as explained here. The package is indeed configuring everything itself. If it exists, assuming the terminal is ttyACM0, execute: sudo chgrp dialout /dev/ttyACM0

    Finally, to check that the right terminal is used by openHab to communicated with the Z-Wave Controller, go to its configuration via that PaperUI > Configuration > Things. Select your Z-Wave Controller and Edit it. In the “Port Configuration” part, you should see that the “Serial Port” is the terminal you found with the command ls -la /dev/ttyA*.


  • Change password of OpenHab Console on Synology

    To change the OpenHab Console password, you have to edit the /userdata/etc/ file.

    Click to Read More

    First, open a SSH console on your Synology as root (See here).

    Then, create a hashed password with the following command (replace ThisIsMyNewPassword with yours) :

    echo -n ThisIsMyNewPassword | sha256sum

    It should output someting like this :

    8fda687cf4127db96321c86907cbea99dabb0b13aa4bf7555655e1df45e41938 -

    If you installed openHab as explained here, the file to be edited is /openHAB/userdata/etc/ in the share /SmartHome of your Synology. Copy the hashed string above (without the dash and the blank) between the {CRYPT} tags:

    # This file contains the users, groups, and roles.
    # Each line has to be of the format:
    # _g_\:GROUP=ROLE1,ROLE2,...
    # All users, groups, and roles entered in this file are available after Karaf startup
    # and modifiable via the JAAS command group. These users reside in a JAAS domain
    # with the name "karaf".
    openhab = {CRYPT}8fda687cf4127db96321c86907cbea99dabb0b13aa4bf7555655e1df45e41938{CRYPT},_g_:admingroup
    _g_\:admingroup = group,admin,manager,viewer,systembundles

    To test the new password, open a SSH console on openHab. As by default it may only be accessed from the localhost, the best option is to use GateOne (See here). Once logged in GateOne on your Synology, execute :

    ssh -p 8101 openhab@localhost

    You should be prompted to enter your password and, if correct, you will see:

    Type Ctrl-D to exit the openHab console.


    NB.: instead of logging in GateOne as admin, you can directly connect on openHab using the port ‘8101’ and the login ‘openhab’ in GateOne:


  • Backup & Restore openHab 2.x on Synology

    In order to upgrade from openHab 2.4 to 2.5, I had to backup the configuration of openHab, uninstall the v2.4, install the v2.5 and restore the configuration.

    Click to Read More

    If you installed OpenHab as explained here, you can copy all the folders under /openHAB in the share /SmartHome of your Synology.

    OpenHAB 2.x currently has two different ways of setting up things:

    • Either through textual configuration (in /SmartHome/openHAB/conf folder) or
    • through the user interface which saves to a “jsonDB” database (in /SmartHome/openHAB/userdata folder).

    Both the textual configuration files and the database folders must be backuped (See here).

    OpenHab 2.x comes now with scripts to backup and restore its configuration and database. They are availabe in the folder /runtime/bin. You can access them via a SSH Console on your Synology, under /var/packages/openHAB/target/runtime/bin/ (equivalent to /volume1/@appstore/openHAB/runtime/bin)

    These scripts take care of backuping not only the files that you have manually edited in the folder /conf (items, things, scripts, …), but also everything configured via the paperUI or HABPanel and stored in the folder /userdata (habmin, jsondb,…)

    Attention, these scripts do not take care of:

    • backuping the jar files that you have installed manually. Ex.: in /addons
    • backuping the DB you would be using for, e.g., persistence, …
    • adding the openHAB user (‘openhab’) to the dialout and tty groups if you did this previously

    First, prepare your Synology

    1. Open a SSH console on your Synology as root (See here)
    2. Install the Synology Gear’s tools, required to have the command pgrep used by the restore script of openHab, typing the command :
      synogear install
    3. Modify the script ‘/runtime/bin/restore’ to replace unzip (not available anymore on Synology) by 7zip. Concretelly, replace:

    command -v unzip >/dev/null 2>&1 || {
    echo "'unzip' program was not found, please install it first." >&2
    exit 1


    command -v 7z >/dev/null 2>&1 || {
    echo "'7z' program was not found, please install it first." >&2
    exit 1


    unzip -oq "$InputFile" -d "$TempDir" || {
    echo "Unable to unzip $InputFile, Aborting..." >&2
    exit 1


    7z x -y -o"$TempDir" "$InputFile" > /dev/null || {
    echo "Unable to unzip $InputFile, Aborting..." >&2
    exit 1

    Next, use the following commands to backup your configurations:

    1. sudo -i
    2. cd /var/packages/openHAB/target
    3. synoservice –stop pkgctl-openHAB
    4. ./runtime/bin/backup
    5. synoservice –start pkgctl-openHAB

    You should see something like this as output:

    openHAB 2.x.x backup script

    Using '/volume1/@appstore/openHAB/conf' as conf folder...
    Using '/volume1/@appstore/openHAB/userdata' as userdata folder...
    Using '/volume1/@appstore/openHAB/runtime' as runtime folder...
    Using '/volume1/@appstore/openHAB/backups' as backup folder...
    Writing to '/volume1/@appstore/openHAB/backups/'...
    Making Temporary Directory if it is not already there
    Using /tmp/openhab2/backup as TempDir
    Copying configuration to temporary folder...
    Removing unnecessary files...
    Zipping folder...
    Removing temporary files...
    Success! Backup made in /volume1/@appstore/openHAB/backups/

    Before uninstalling openHab, if you intend to install a new version, copy the backup into a safe folder, like the tmp folder :

    cp /volume1/@appstore/openHAB/backups/ /tmp/

    Finally, use the following commands to restore your configurations:

    1. sudo -i
    2. cd /var/packages/openHAB/target
    3. synoservice –stop pkgctl-openHAB
    4. ./runtime/bin/restore /tmp/
    5. synoservice –start pkgctl-openHAB

    You should see an output like this:

    openHAB 2.x.x restore script

    Using '/volume1/@appstore/openHAB/conf' as conf folder...
    Using '/volume1/@appstore/openHAB/userdata' as userdata folder...
    Making Temporary Directory
    Extracting zip file to temporary folder.

    Backup Information:
    Backup Version | 2.5.0 (You are on 2.4.0)
    Backup Timestamp | 19_12_25-12_27_33
    Config belongs to user | openhab
    from group | users

    Your current configuration will become owned by openhab:users.

    Any existing files with the same name will be replaced.
    Any file without a replacement will be deleted.

    Okay to Continue? [y/N]: y
    Moving system files in userdata to temporary folder
    Deleting old userdata folder...
    Restoring system files in userdata...
    Deleting old conf folder...
    Restoring openHAB with backup configuration...
    Deleting temporary files...
    Backup successfully restored!


    If opening openHab weg page immediatly, you will see that it’s restoring the UI:

    Please stand by while UIs are being installed. This can take several minutes.

    Once done, you will have access to your PaperUI, BasicUI, HabPanel, etc…


  • Devolo DLan (CPL) + Fibaro Wall Plug = network connection issues

    I notice some incompatiblity between Devolo DLan’s and Fibaro Wall Plugs

    Click to Read More

    In order to measure the power consumption of my Devolo DLan’s (a 500 Wireless+ and a 200 AV Wireless N), I did plug them into Fibaro Wall Plugs.

    It used to work fine at the begining. But now, the devices plugged on the DLan via ethernet or Wifi can’t connext to the network anymore.

    As soon as remove the Fibaro Wall Plug, everything works fine. I tried several times, with two distinct DLan, after resetting my router and my modem, after resetting the connected devices, etc… 

    I found only two other users experiencing also issues when combining Fibaro Wall Plugs and Devolo powerline devices… 


  • Configure Hue devices in OpenHab 2

    Here is how to add the Philips Hue Bridge in OpenHab and control the Hue devices (more doc here).

    Click to Read More

    Add first the Bridge Philips Hue

    Go to Paper UI’s Configuration > Bindings and click on the blue “+” (or go directly to Configuration > Add-ons, in the tab “Bindings”) :

    In the Search box, type “Hue” to filter the “Bindings”. Click on the “Install” link on the right of the “Hue Binding” to install it :

    With the Hue Binding, you can now add a “Hue Bridge”. Go to your physical “Bridge” Philips and press the button on the top as you do to pair Hue devices with the Bridge. Go next to Configuration > Things and click on the Blue “+”. Then select “Hue Binding”. OpenHab will find the “Hue Bridge” :

    Select the “Hue Bridge” and click on “Add as Thing” :

    If everything worked fine, you should see all your Hue Devices in the “Inbox”.

    Otherwise, you will probably see the “Hue Bridge” as “Offline – Configuration_Error”. This is probably due to an issue during the pairing with the physical “Bridge” Philips. OpenHab has not been authorized to access it.

    It’s possible to set the authorization manually (See Here). First, find the IP address of your “Philips Bridge” by opening the page  

    You should see something like:  [{“id”:”001788fffeae5fd3″,”internalipaddress”:””}]

    Next, using the internalipaddress above, open the page and before pressing the button “POST”, type :

    • /api/ in the “URL”
    • “{“devicetype”:”my_hue_app#openhab”}” in the “Message Body”

    In the “Command Response”, copy the value of the “username”. Go to Configuration > Things, edit the Bridge (click on the pen) and paste the value in the field “Username”

    Configure next each Philips Hue device

    You can select any of the Philips Hue devices appearing in the Inbox. Each selected device is added as a Thing (under Configuration > Things). There, you can link them with Items that you have previously defined as described here

    Extended Color Light

    If you want to configure a Thing of type “Extented Color Light”, you can look what are its supported features in the official openHab documentation for Philips Hue (here). 

    As you can see on your Thing , it has an ID like “hue:0210:001788ae5fd3:4″

    You can search for 0210 on the documentation page to find that it supports changing the color, the color temperature and being switched on/off:
    These features can be controlled via “Channels” (See openHab’s concepts). A distinct channel is used to control each distinct feature of a Thing. Contretely, you have to link your Thing, via the various channels, onto Items. Which kind of item must be used is also described on the documentation page :

    What is not clear in the documentation of the Channels, for example with the color Channel is that you can link not only a Color Item with it, but also a Dimmer and a Switch.

    Personnaly, if I define all my Items within a file (as described here), I configure my Devices by creating Links between my Items and my Things directly within the Paper UI interface.

    For a Extended Color Light, my Items file (default.items) will contain:

    Switch GF_Office_Light "Lampe Bureau" <light>
    Dimmer GF_Office_Light_Dim "Lampe Bureau Dim" <light>
    Color GF_Office_Light_Clr "Lampe Bureau Color" <light>
    Dimmer GF_Office_Light_Temp "Lampe Bureau Temperature" <light>

    And I configure the Links between the Thing and those Items like this :

    Finally, in my Sitemap, I will use:

    sitemap default label="Olympe Home" {
      Frame label="Rooms" icon="group" {
        Text label="Bureau" icon="groundfloor" {
          Switch item=GF_Office_Light label="Switch" icon="light"
          Slider item=GF_Office_Light_Dim label="Dim" icon="slider"
          Colorpicker item=GF_Office_Light_Clr label="Color"
          Slider item=GF_Office_Light_Temp label="Temperature" icon="slider"

    And here is the outcome:


  • Configure Somfy devices in OpenHab 2

    Here is how to add the SomfyTahoma Bridge in OpenHab and control the Somfy devices (more doc here).

    Click to Read More

    Go to Paper UI’s Configuration > Bindings and click on the blue “+” (or go directly to Configuration > Add-ons, in the tab “Bindings” – indeed, “Bindings” are installed using “Add-ons” developed by the community) :

    In the Search box, type “Somfy” to filter the “Bindings” and find those available for this type of devices. Click on the “Install” link on the right of the one to be installed :

    Once the Add-on installed, you can check that the Bindings is available in the Configuration > Bindings :

    With the Somfy Binding, you can now add a “SomfyTahoma Bridge”. Go to Configuration > Things and click on the Blue “+”. Then select “SomfyTahoma Binding” and next “Somfy Tahoma Bridge” :

    You must now configure the Bridge with your Somfy account (Email Address and Password). You can also define the “location” (Room) where it is placed in your house :

    Once done, the Bridge appears as “Online” in Configuration > Things

    And the “Somfy devices” will appear in the “Inbox” :

    Each device in the “Inbox” can now be linked with an “Item” previously configured via the “Home Builder” (and saved in the file “default.items”). For example, select a Roller Shutter by clicking on the blue “V”  and click next on “Add as Thing” :

    Go to Configuration > Things were the “Roller Shutter” appears now as “Online” : 

    Click on the “Roller Shutter” to configure it (For each “Thing”, when you configure it, you see one or several blue circles. Each one can be used to configure the links with the various features of the devices) :

     In the case of a Somfy Roller Shutter, there is not a lot to configure. You can only select the “Item” to be used to control the “Roller Shutter” :

    Once selected, click on “Link” :

    Here above, I configured the link with a “Item” located in the Room “Office”. So, going to the “Basic UI” via the “Welcome page”, and opening the “Office” (member of the “Ground Floor”), you can now click on the arrows “Up” and “Down” next to the “Roller Shutter” to control it :

    You can also do it via the “HabPanel DashBoard” :