CM3-Home openHAB edition

CM3-Home is a Raspberry Pi Compute Module 3 application board designed to join the most common Home Automation software available on Raspberry Pi platform with a rich set of reliable hardware interfaces.

Product description

Two versions of CM3-Home openHAB edition kits are available:

A full edition with a complete set of peripherals

Full edition (code CM3-OH-F):


Buy

A basic edition with a minimal set of peripherals

Basic edition (code CM3-OH-B)


Buy

Acme Systems srl is a member of openHAB foundation

What is openHAB ?

The open Home Automation Bus (openHAB, pronounced ˈəʊpənˈhæb) is an open source, technology agnostic home automation platform which runs as the center of your smart home !

The CM3-Home openHAB edition is a ready-to-use kit with all you need to getting started into openHAB avoiding the effort to understand how to create a microSD with the openHABian distribution for the Raspberry Pi compute module 3.

On this page we provide all the info you need to use all the hardware interfaces available on the CM3-Home board to get results in the shortest time possible.

Getting started guide

This article explains how to get started with the CM3-Home openHAB edition kit

CM3-Home openHAB edition catalog

EUR 345.00


CM3-OH-F - CM3-Home openHAB full edition

The CM3-Home openHAB edition is a ready-to-use kit with all you need to getting started into openHAB avoiding the effort to understand how to create a microSD with the openHABian distribution for the Raspberry Pi compute module 3.

This kit includes:

  • a CM3-Home board basic
  • a 16 GB microSD with openHABian installed
  • a CM3-CASE enclosure for DIN rail montage
  • a Raspberry PI Compute Module 3
  • a WiFi PCB antenna

Please note that in this kit is not included:

  • a Yarm RF antenna
  • a power supply
  • an USB to serial converter for debug purposes
| Product description |

EUR 190.00


CM3-OH-B - CM3-Home openHAB basic edition

The CM3-Home openHAB edition is a ready-to-use kit with all you need to getting started into openHAB avoiding the effort to understand how to create a microSD with the openHABian distribution for the Raspberry Pi compute module 3.

This kit includes:

  • a CM3-Home board basic
  • a 16 GB microSD with openHABian installed
  • a CM3-CASE enclosure for DIN rail montage
  • a Raspberry PI Compute Module 3

The basic edition does not include: TP-BUS, LIGHT-BUS, WiFi, RS485 (one instead of two), Yarm 868 MHz radio module

| Product description |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

EUR 12.00


YARM-ANT-01 - Antenna with cable

Antenna stick for YARM-DEV with uFL to SMA cable

| Yarm radio module |

EUR 8.00


USB-3V-SER - USB to 3V3 serial converter

USB to 3V3 serial converter ad 3.3 volt with separated pin plugs

| Product description |

Audio OUT

An example about how the audio OUT can be used, directly driving the sounds or linking them to different events.

The items configured can be displayed as buttons on:

Classic UI

Basic UI

Or in the Habpanel

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

OpenHAB audio

how to use the audio output to play alarm and signaling sounds

Assign the items to link with the sounds

Switch AirHorn "AirHorn"   (audio) 
Switch ALARMBUS "ALARMBUS"   (audio)
Switch alarmClock "alarmClock"   (audio)
Switch barking "barking"   (audio)
Switch BikeHorn "BikeHorn"   (audio)
Switch dixieHorn "dixieHorn"   (audio)
Switch doorbell "doorbell"   (audio)
Switch trainWhistle "trainWhistle"   (audio)

The sound files must be in the sounds folder

Add the rules to execute when the switches are actuated

rule "AirHorn"
when
    Item AirHorn changed
then
    playSound("AirHorn.mp3")
end

rule "ALARMBUS"
when
    Item ALARMBUS changed
then
    playSound("ALARMBUS.mp3")
end

rule "alarmClock"
when
    Item alarmClock changed
then
    playSound("alarmClock.mp3")
end
......

Setup the buttons to use them in ClassicUI, BasicUI or App

sitemaps/cm3home.sitemap

 Frame label="Audio"
    {
        Text label="Sound" icon=player
        {
            Switch item=AirHorn
            Switch item=ALARMBUS
            Switch item=barking
            Switch item=BikeHorn
            Switch item=dixieHorn
            Switch item=doorbell
            Switch item=trainWhistle
        }
    }

Tips

The internal java player is less flexible than an external mp3-player, omxplayer could be used instead that offers many more features, first off all a better audio volume management.

Install omxplayer

sudo apt-get install omxplayer

Using OpenHAB executeCommandLine in some rules, the external player can be driven:

rules/audio.rules

rule "AirHorn"
when
    Item AirHorn changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/AirHorn.mp3",5000)
    logInfo("Exec",results)
end

rule "ALARMBUS"
when
    Item ALARMBUS changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/ALARMBUS.mp3",5000)
    logInfo("Exec",results)
end


rule "alarmClock"
when
    Item alarmClock changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/alarmClock.mp3",5000)
    logInfo("Exec",results)
end

rule "barking"
when
    Item barking changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/barking.mp3",5000)
    logInfo("Exec",results)
end

rule "BikeHorn"
when
    Item BikeHorn changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/BikeHorn.mp3",5000)
    logInfo("Exec",results)
end

rule "dixieHorn"
when
    Item dixieHorn changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/dixieHorn.mp3",5000)
    logInfo("Exec",results)
end

rule "doorbell"
when
    Item doorbell changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/doorbell.mp3",5000)
    logInfo("Exec",results)
end

rule "trainWhistle"
when
    Item trainWhistle changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/trainWhistle.mp3",5000)
    logInfo("Exec",results)
end

Because the program is executed with sudo, the openhabian user must be added to the sudoers as explained in OpenHAB executeCommandLine

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

OpenHAB KNX binding

This article illustrates how to use the OpenHAB KNX binding on the TP-BUS hardware implemented on the CM3-Home board.

Please note:
The CM3-Home board IS NOT a certified KNX device but implements just a hardware circuitry based on a Siemens TP-UART-2. Acme Systems doesn't provide any warranty about its functionality with the KNX devices.

The TP-UART-2 circuitry is powered up by the external bus so in order to guarantee the correct operation provide the power supply to the bus before turning on the CM3-Home.

Example: a KNX relay PLANA 1453 made by Vimar wired as shown below. The relay address was already configured with a valid KNX group address.

The Classic UI and the HabPanel supplied show some examples of lights and roller shutters, driven individually or in a group. They are organized as a separated frame in the UI and in a separate panel in the Habpanel.

The orange buttons drive all the devices in one shot.

Editing the items/knx.items file it's possible to assign the relation between the name displayed and the KNX address of your devices.

Group:Switch:OR(ON, OFF) Gday       "All Lights [(%d)]"

Switch          L_Laboratorio       "Lab"                           (Gday)       { knx="1/6/25" }
Switch          L_SalAbatjour       "Living room Abatjour"          (Gday)       { knx="1/6/105" }
Switch          L_SalDX             "Living room DX"                (Gday)       { knx="1/5/217" }
Switch          L_SalSX             "Living room SX"                (Gday)       { knx="1/5/209" }
Switch          L_CucExt            "Kitchen Outside"               (Gday)       { knx="1/5/225" }
Switch          L_Cuc               "Kitchen"                       (Gday)       { knx="1/5/233" }
Switch          L_CucPens           "Kitchen Top"                   (Gday)       { knx="1/5/241" }
Switch          L_BagnoG            "Bathroom"                      (Gday)       { knx="1/6/97" }
Switch          L_Ingr              "Entrance"                      (Gday)       { knx="1/6/81" }
Switch          L_CorridG           "Corridor"                      (Gday)       { knx="1/6/33" }
Switch          L_TV                "TV set"                       (Grele)      { knx="1/6/113" }

Group:Rollershutter:OR(UP, DOWN) Shutter    "Roller Shutter [(%d)]"

Group:Rollershutter:OR(UP, DOWN) ShutterDay  "Roller Shutters ALL [(%d)]"

Rollershutter   T_Salone            "Living Room"                       (Shutter, ShutterDay) { knx="1/5/202, 1/5/201" }
Rollershutter   T_Laboratorio       "Lab"                               (Shutter, ShutterDay) { knx="1/5/250, 1/5/249" }
Rollershutter   T_BagnoG            "Bathroom"                          (Shutter, ShutterDay) { knx="1/6/122, 1/6/121" }
Rollershutter   T_CucinaP           "Kitchen Door"                      (Shutter, ShutterDay) { knx="1/5/186, 1/5/185" }
Rollershutter   T_CucinaF           "Kitchen Win."                      (Shutter, ShutterDay) { knx="1/5/194, 1/5/193" }

Please note that the rollershutters have two different addresses, one for UP and one for DOWN commands.

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

KNX integration via TPUART

How to create an OpenHAB interface on a KNX based home-automation system through a TPUART physical interface. Practical information about interfacing the CM3-Home to a TP KNX bus.

Please note:
The CM3-Home board IS NOT a certified KNX device but implements just a hardware circuitry based on a Siemens TP-UART-2. Acme Systems doesn't provide any warranty about its functionality with the KNX devices.

The TP-UART-2 circuitry is powered up by the external bus so in order to guarantee the correct operation provide the power supply to the bus before turning on the CM3-Home.

This is the classic KNX communication layer stack:

Interfacing standard home-automation systems

OpenHAB is designed to be interfaced also with more or less open commercial systems derived from EIB, like KNX and SCS. The KNX is an open protocol used by many different manufacturer. Vimar, for example, in the ByMe domestic system uses a version of the protocol compatible with the others but with a proprietary system to assign the devices addresses. Their devices are not included in the knx.org database and cannot be configured with the ETS software like Siemens, Gewiss and others. The addressing is realized with a sort of DHCP system through a dedicated console. The BTicino SCS is based on concepts very similar to KNX but with some differences even of the first communication stack layers.

Interfacing EIB with OpenHAB requires hardware devices physically attached to the twisted pair on a side and USB or ethernet on the other side. There are many devices for this purpose. Depending on the complexity of the gateway the data can be read already decoded or in raw mode, in this case requiring additional drivers to be used in OpenHAB environment.

Below some links for different physical interfaces:

TPUART

Connecting the KNX bus requires a hardware that meets the physical layer specifications. The CM3-Home uses the Siemens official chip TPUART-2. This is an example of a development board using TPUART-1. The new TPUART-2 is smaller, cheaper and with some more features while maintaining compatibility with the previous version. As evidenced in the stack diagram, TPUART manages the lower layers of the protocol exchanging the already decoded datagrams on a 19.2kbps serial interface.

KNX demon

knxd is a program that can be started as a service and creates a gateway towards practically all the KNX bus interfacing systems. The installation on the CM3-Home board is eased a lot by some ready-made scripts, even if it can be compiled for the majority of Linux distributions. The github wiki describes all the available interfaces: serial, USB or IP. The demon must run on the same machine were the TP bus is physically connected. This computer publishes on the network a service that can be used by OpenHAB or other programs like knxtools available on github, in order to manage all the field bus operations. Even ETS, the devices management software officially distributed by the KNX consortium, can interface the bus through knxd and CM3-Home TPUART. The ttyAMA0 CM3-Home port is used to interface TPUART, therefore it must be freed up from the operating system console service.

The default configuration proposed by the installation scripts is good:

openhabian@RasPIguiott:~$ nano /etc/default/knxd
KNXD_OPTIONS="--eibaddr=1.1.128 --client-addrs=1.1.129:1 -d -D -T -R -S -i --listen-local=/tmp/knx -b tpuarts:/dev/ttyAMA0"

ATTENTION

Starting from knxd version 0.14.22, the openhabian-config script (option 20 | Install optional add-ons of openhabian-config) still adds -d parameters in the KNXD_OPTIONS row of the configuration file used by systemd to launch the service at startup (/etc/default/knxd). This parameter, as well explained in the knxd wiki, is used to start the program as a demon when launched via the cli. Used with systemctl does not allow the program to start correctly. So, the line must be corrected manually in:

openhabian@RasPIguiott:~$ nano /etc/default/knxd
KNXD_OPTIONS="--eibaddr=1.1.128 --client-addrs=1.1.129:1 -D -T -R -S -i --listen-local=/tmp/knx -b tpuarts:/dev/ttyAMA0"

The installation script overrides this configuration if re-launched, therefore the correction must be repeated if knxd is installed again or upgraded.

Check if the file /lib/systemd/system/knxd.service looks like this:

[Unit]
Description=KNX Daemon
After=network.target

[Service]
EnvironmentFile=/etc/default/knxd
# Wait for all interfaces, systemd-networkd-wait-online.service must be enabled
#ExecStartPre=/lib/systemd/systemd-networkd-wait-online --timeout=60
# Wait for a specific interface
#ExecStartPre=/lib/systemd/systemd-networkd-wait-online --timeout=60 --interface=eth0
ExecStart=/usr/local/bin/knxd -p /run/knxd/knxd.pid $KNXD_OPTIONS
#Type=forking
Type=simple
PIDFile=/run/knxd/knxd.pid
User=knxd
Group=knxd
#TimeoutStartSec=60

[Install]
WantedBy=multi-user.target network-online.target

To check the correct operation, the knxtool program can be used. It is installed together with knxd by the script.

E.g.: monitor datagrams on KNX bus:

openhabian@RasPIguiott:~$ knxtool busmonitor1 ip:localhost
LPDU: B4 11 F0 0D D1 E1 00 81 16 :L_Data urgent from 1.1.240 to 1/5/209 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01 
LPDU: B4 :Unknown LPDU: B4 
LPDU: B4 11 F0 0D D1 E1 00 80 17 :L_Data urgent from 1.1.240 to 1/5/209 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00 
LPDU: B4 :Unknown LPDU: B4 
LPDU: B4 11 F0 0E 69 E1 00 81 AD :L_Data urgent from 1.1.240 to 1/6/105 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01 
LPDU: B4 :Unknown LPDU: B4 
LPDU: B4 11 F0 0E 69 E1 00 80 AC :L_Data urgent from 1.1.240 to 1/6/105 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00 
LPDU: B4 :Unknown LPDU: B4 

Control KNX devices:

[13:00:36] openhabian@RasPIguiott:~$ knxtool on ip:localhost 1/6/105
Send request
[13:02:25] openhabian@RasPIguiott:~$ knxtool off ip:localhost 1/6/105
Send request
[13:02:34] openhabian@RasPIguiott:~$ 

Installation

In order to have an OpenHabian2 environment correctly configured it is advisable to start from the official distribution distributed as an SD card image and follow all the instructions. At the first login the system starts the installation of all the needed add-ons. This could last even for an hour.

Once the installation is complete, use openhabian-config (the raspbian raspi-config equivalent in Openhabian environment) to install any additional software and configure the board.

openhabian@RasPIguiott:~$ sudo openhabian-config

Before installing knxd, it is necessary to free-up the ttyAMA0 serial port from the console service

* 30 | System Settings      A range of system and hardware related configuration steps ►
    * 35 | Serial Port                           Prepare serial ports for peripherals like R
        * [*] 1  (RPi) Disable serial console           (Razberry, SCC, Enocean)
        * [*] 2  (RPi3) Disable Bluetooth module        (Razberry)           
        * [*] 3  Add common serial ports to openHAB JVM (Razberry, Enocean)  

install knxd follow the menu item 20 -> 27

* 20 | Optional Components  Choose from a set of optional software components ►
    * 27 | knxd       KNX specific, the KNX router/gateway daemon knxd 

Openhabian

To install KNX binding, open the Openhabian interface at URL "http://your-cm3-home-address:8080". Using paper UI add the KNX binding

Attach the KNX binding to knxd service

openhabian@RasPIguiott:~$ nano /etc/openhab2/services/knx.cfg

The default configuration needs to be changed in two rows:

type=ROUTER
localIp=localhost

An alternative configuration, using tunnel mode:

ip=localhost
busaddr=1.1.129
ignorelocalevents=true
type=TUNNEL
port=3671
localIp=localhost

Using TUNNEL mode, the binding is connected in transparent mode to the KNX bus. In this way every event on the bus is captured and the corresponding items updated, allowing also the use if rules like this one:

rule "L_Laboratorio ON"
    when 
        Item L_Laboratorio received command ON
    then
        val results = executeCommandLine(Cmd+"@@"+254+"@@"+254+"@@"+254,5000)
        logInfo("Exec",results)
end

rule "L_Laboratorio OFF"
    when 
        Item L_Laboratorio received command OFF
    then        
        val results = executeCommandLine(Cmd+"@@"+0+"@@"+0+"@@"+0,5000)
        logInfo("Exec",results)
end

To manage, for example, a DALI light through a KNX switch

To check the configuration, use the karaf console

[12:44:08] openhabian@RasPIguiott:~$ ssh -p 8101 openhab@localhost
Password authentication
Password: 

                          __  _____    ____      
  ____  ____  ___  ____  / / / /   |  / __ )     
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  | 
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /      
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/     
    /_/                        2.1.0
                               - release build -   

Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown openHAB.

openhab> config:list "(service.pid=org.openhab.knx)"
----------------------------------------------------------------
Pid:            org.openhab.knx
BundleLocation: mvn:org.openhab.binding/org.openhab.binding.knx/1.10.0
Properties:
   localIp = localhost
   service.pid = org.openhab.knx
   type = ROUTER
openhab> 

In case of any problem, it can be useful to increase the debug level to verify possible configuration errors:

openhab> log:set debug tuwien.auto.calimero

or enable the trace

log:set TRACE org.openhab.binding.knx
log:set TRACE tuwien.auto.calimero

It is advisable to disable them at the end of the debug:

log:set DEFAULT org.openhab.binding.knx
log:set DEFAULT tuwien.auto.calimero

All the useful information can be find in:

/var/log/openhab2/event
/var/log/openhab2/openhab.log

Or with the command log:tail in karaf console

Or with the browser at: http://cm3home.local:9001/

The configuration is dynamically loaded as soon as the cfg file is saved (/etc/openhab2/services/knx.cfg in the example). It could happen that the previous configurations are cached even at service restart. In that case clean up the cache before restarting the service:

openhab> config:delete org.openhab.knx

openhabian@RasPIguiott:~$ sudo systemctl restart openhab2

Devices configuration

All the configuration files are in /etc/openhab2

[13:02:34] openhabian@RasPIguiott:~$ cd /etc/openhab2/
[13:08:30] openhabian@RasPIguiott:/etc/openhab2$ ll
total 52K
drwxrwxr-x+ 13 openhab openhabian 4.0K Aug 10 19:25 ./
drwxr-xr-x  92 root    root       4.0K Aug 12 16:44 ../
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 html/
drwxrwxr-x+  3 openhab openhabian 4.0K Aug 10 19:25 icons/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 12 17:06 items/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 persistence/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 rules/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 scripts/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 12 21:25 services/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 12 17:19 sitemaps/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 sounds/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 things/
drwxrwxr-x+  2 openhab openhabian 4.0K Aug 10 19:25 transform/
[13:08:31] openhabian@RasPIguiott:/etc/openhab2$ 

Once the environment is ready, you can create the items on OpenHAB, connect them to the binding...

openhabian@RasPIguiott:~$ nano /etc/openhab2/items/knx.items

Group Grele
Switch          L_Laboratorio       "Laboratorio"                   (Grele)       { knx="1/6/25" }
Switch          L_SalAbatjour       "Salone Abatjour"               (Grele)       { knx="1/6/105" }
Switch          L_SalDX             "Salone DX"                     (Grele)       { knx="1/5/217" }
Switch          L_SalSX             "Salone SX"                     (Grele)       { knx="1/5/209" }
Switch          L_CucExt            "Cucina Esterno"                (Grele)       { knx="1/5/225" }
Switch          L_Cuc               "Cucina"                        (Grele)       { knx="1/5/233" }
Switch          L_CucPens           "Cucina Pensili"                (Grele)       { knx="1/5/241" }
Switch          L_BagnoG            "Bagno Giorno"                  (Grele)       { knx="1/6/97" }
Switch          L_Ingr              "Ingresso"                      (Grele)       { knx="1/6/81" }
Switch          L_CorridG           "Corridoio Giorno"              (Grele)       { knx="1/6/33" }
Switch          L_TV                "Mobile TV"                     (Grele)       { knx="1/6/113" }

Switch          L_CamMat1           "Camera Matrimoniale 1"         (Grele)       { knx="1/6/41" }
Switch          L_CamMat2           "Camera Matrimoniale 2"         (Grele)       { knx="1/6/49" }
Switch          L_Testata           "Testata Letto Matr"            (Grele)       { knx="1/6/129" }
Switch          L_Camera1           "Camera 1"                      (Grele)       { knx="1/6/57" }
Switch          L_Camera2           "Camera 2"                      (Grele)       { knx="1/6/65" }
Switch          L_BagnoN            "Bagno Notte"                   (Grele)       { knx="1/6/73" }
Switch          L_CorridN           "Corridoio Notte"               (Grele)       { knx="1/6/89" }

Switch          S_LuciOff           "Luci OFF"                      (Grele)       { knx="1/3/3" }
Switch          S_TvOff             "TV OFF"                        (Grele)       { knx="1/3/4" }
Switch          S_TvOn              "TV ON"                         (Grele)       { knx="1/3/5" }
Switch          S_TapGiu            "Tapparelle GIU"                (Grele)       { knx="1/3/1" }
Switch          S_TapSu             "Tapparelle SU"                 (Grele)       { knx="1/3/2" }

Group Tapparelle
Rollershutter   T_Salone            "Salone"                            (Tapparelle) { knx="1/5/202, 1/5/201" }
Rollershutter   T_Laboratorio       "Laboratorio"                       (Tapparelle) { knx="1/5/250, 1/5/249" }
Rollershutter   T_BagnoG            "Bagno Giorno"                      (Tapparelle) { knx="1/6/122, 1/6/121" }
Rollershutter   T_CucinaP           "Cucina Porta"                      (Tapparelle) { knx="1/5/186, 1/5/185" }
Rollershutter   T_CucinaF           "Cucina Fin."                       (Tapparelle) { knx="1/5/194, 1/5/193" }
Rollershutter   T_Camera            "Camera"                            (Tapparelle) { knx="1/6/18, 1/6/17" }
Rollershutter   T_CameraMat         "Camera Mat."                       (Tapparelle) { knx="1/6/10, 1/6/9" }
Rollershutter   T_BagnoN            "Bagno Notte"                       (Tapparelle) { knx="1/6/2, 1/6/1" }

... and assign them to the switches on the graphic UI:

openhabian@RasPIguiott:~$ nano /etc/openhab2/sitemaps/knx.sitemap

sitemap knx label="GUIOTT home" 
{
    Frame label="Zona Giorno"
        {
              Switch item=L_Laboratorio
              Switch item=L_SalAbatjour
              Switch item=L_SalSX
              Switch item=L_SalDX
              Switch item=L_CucExt
              Switch item=L_Cuc
              Switch item=L_CucPens
              Switch item=L_BagnoG
              Switch item=L_Ingr
              Switch item=L_CorridG
              Switch item=L_TV
        }   
        
    Frame label="Zona Notte"
        {
              Switch item=L_CamMat1
              Switch item=L_CamMat2
              Switch item=L_Testata
              Switch item=L_Camera1
              Switch item=L_Camera2
              Switch item=L_BagnoN
              Switch item=L_CorridN
        }    
    
    Frame label="Tapparelle"
        {
              Switch item=T_Salone
              Switch item=T_Laboratorio
              Switch item=T_BagnoG
              Switch item=T_CucinaP
              Switch item=T_CucinaF
              Switch item=T_Camera
              Switch item=T_CameraMat
              Switch item=T_BagnoN
        }
            
    Frame label="Scenari"
        {
              Switch item=S_LuciOff
              Switch item=S_TvOff
              Switch item=S_TvOn
              Switch item=S_TapGiu
              Switch item=S_TapSu
        }       
        
}

An example of the result for this configuration at "http://your-cm3-home-address:8080/classicui/app"

Openhab 2.x version

Starting from OpenHAB 2.3 the KNX binding has been upgraded to the "OH2.x style". No more services but things. In this way it can be configured using PaperUI, knx.things file and all the other new tools introduced with OH2.0.

As well as any other 2.x binding the KNX one is composed by two main parts: the gateway, a sort of bridge that directly interfaces the physical KNX bridge to the OpenHAB world, and the device, the wrapper that contains all the single channels.

The bridge configuration UI presents an easier configuration of the same parameters already discussed.

Then a device "container" has to be created to include all the channels.

And all of the single channels (physical KNX devices) have to be added in the container.

Connecting Visual Studio Code to the CM3-Home via the rest API, it helps a lot on the configuration of the items.

Mobile App

To use all the CM3-Home OpenHAB features on mobile devices even when not in the same domestic network, it can be used the open cloud service offered by openhab and the corresponding app available for both iOS and Android

After installing the openHAB Cloud Connector

the following files will be available:

/var/lib/openhab2/uuid
/var/lib/openhab2/openhabcloud/secret

The files content is needed to setup the cloud service. A complete tutorial about installation and configuration is available on Youtube.

The same functions available on local UI can be used also on mobile device once connected with the cloud service.

Links

Credits

Many thanks to Massimiliano Casini for his contribute to this article

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Infrared remote control

This article illustrates how to use the 38 kHz infrared receiver available on the CM3-Home

The example supplied with the SD card uses the first 6 keys of a simple remote control

As a demo it switches on the RGB LEDs with the first row keys and switches them off with the second row.

Changing the items driven by the rules many other functions can be performed:

rules/ir.rules

rule "IR_0-ON"
    when 
        Item Ir_0 received command ON
    then
        sendCommand(LedR, OFF)
end

rule "IR_0-OFF"
    when 
        Item Ir_0 received command OFF
    then
        sendCommand(LedR, ON)
end

rule "IR_1-ON"
    when 
        Item Ir_1 received command ON
    then
        sendCommand(LedG, OFF)
end

rule "IR_1-OFF"
    when 
        Item Ir_1 received command OFF
    then
        sendCommand(LedG, ON)
end

rule "IR_2-ON"
    when 
        Item Ir_2 received command ON
    then
        sendCommand(LedB, OFF)
end

rule "IR_2-OFF"
    when 
        Item Ir_2 received command OFF
    then
        sendCommand(LedB, ON)
end

For example activating the internal relays, KNX or RS485 switches, playing sounds or anyone of the many items defined, or even system actions as restarting the board itself.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

How to set the CM3-Home internal IR receiver

This configuration is valid for Raspbian Stretch with LIRC 0.9.4

Install LIRC:

sudo apt-get install lirc

Modify:

/etc/lirc/lirc_options.conf

updating lines from

driver = devinput
device = auto

to

driver = default
device = /dev/lirc0

Reboot

To test the installation:

sudo systemctl stop lircd.service
sudo systemctl stop lircd.socket

then

mode2 -d /dev/lirc0

Pushing a remote control key, something like this should be displayed if the installation is ok and the remote control modulation frequency matches the receiver one, i.e. 38kHz:

Using driver default on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
space 10743268
pulse 243
space 19204
pulse 100
space 2521370
pulse 9126
space 4441
pulse 625
space 506
pulse 623
space 513
pulse 622
space 510

At this point it's possible to use one of the many ready to use remote controls definitions supplied by LIRC or learn your own.

To learn the remote control key codes needed:

irrecord -d /dev/lirc0 ~/lircd.conf

Follow carefully the instruction. At the end it will be available a file given_name.lirc.conf.

For example

cat remote.lircd.conf 

# Please take the time to finish this file as described in
# https://sourceforge.net/p/lirc-remotes/wiki/Checklist/
# and make it available to others by sending it to
# <lirc@bartelmus.de>
#
# This config file was automatically generated
# using lirc-0.9.4c(default) on Sat Mar 24 23:05:34 2018
# Command line used: -d /dev/lirc0 /home/openhabian/lircd.conf
# Kernel version (uname -r): 4.9.80-v7+
#
# Remote name (as of config file): remote
# Brand of remote device, the thing you hold in your hand:
# Remote device model nr:
# Remote device info url:
# Does remote device has a bundled capture device e. g., a
#     usb dongle? :
# For bundled USB devices: usb vendor id, product id
#     and device string (use dmesg or lsusb):
# Type of device controlled
#     (TV, VCR, Audio, DVD, Satellite, Cable, HTPC, ...) :
# Device(s) controlled by this remote:

begin remote

  name  remote
  bits           32
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9098  4444
  one           628  1632
  zero          628   504
  ptrail        629
  repeat       9099  2187
  gap          107733
  toggle_bit_mask 0x0
  frequency    38000

      begin codes
          KEY_0                    0x00FFA25D 0x7EF26F2C
          KEY_1                    0x00FF629D 0x7EF26F2C
          KEY_2                    0x00FFE21D 0x7EF26F2C
          KEY_3                    0x00FF22DD 0x7EF26F2C
          KEY_4                    0x00FF02FD 0x7EF26F2C
          KEY_5                    0x00FFC23D 0x7EF26F2C
      end codes

end remote

Unfortunately this is wrong for a known bug of irrecord in version 0.9.4 as documented in this blog. It looks like it doubles the code. Often deleting the second code in each row resolves the problem.

That's correct

begin remote

  name  IR
  bits           32
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9098  4447
  one           624  1636
  zero          624   508
  ptrail        625
  repeat       9102  2189
  gap          107732
  toggle_bit_mask 0x0
  frequency    38000

      begin codes
          KEY_1                    0x00FFA25D
          KEY_2                    0x00FF629D
          KEY_3                    0x00FFE21D
          KEY_4                    0x00FF22DD
          KEY_5                    0x00FF02FD
          KEY_6                    0x00FFC23D
          KEY_7                    0x00FFE01F
          KEY_8                    0x00FFA857
          KEY_9                    0x00FF906F
          KEY_0                    0x00FF6897
      end codes

end remote

Copy the file to the right path:

sudo cp remote.lircd.conf /etc/lirc/lircd.conf.d/

Restart LIRC:

sudo systemctl restart lircd

Check if the remote definition has been acknowledged by LIRC

irsend LIST "" ""

The name of the configuration (given_name) should be displayed.

With the command

irw

it's possible to test if everything's ok pushing all the defined keys

openhabian@cm3-home:~$ irw
0000000000ffa25d 00 KEY_1 IR
0000000000ff629d 00 KEY_2 IR
0000000000ffe21d 00 KEY_3 IR
0000000000ff22dd 00 KEY_4 IR
0000000000ff02fd 00 KEY_5 IR
0000000000ffc23d 00 KEY_6 IR
0000000000ffe01f 00 KEY_7 IR
0000000000ffa857 00 KEY_8 IR
0000000000ff906f 00 KEY_9 IR
0000000000ff6897 00 KEY_0 IR

LIRC is ready and knows the remote codes.

With lircrc it is possbile to trigger some actions everytime a key is pressed.

Edit

/etc/lirc/lircrc

In this way:

begin
    button = KEY_1
    prog = irexec
    config = /usr/bin/mosquitto_pub -h localhost -t openhab/out/ir/command -m key_1
    repeat = 0
end
begin
    button = KEY_2
    prog = irexec
    config = /usr/bin/mosquitto_pub -h localhost -t openhab/out/ir/command -m key_2
    repeat = 0
end
begin
    button = KEY_3
    prog = irexec
    config = /usr/bin/mosquitto_pub -h localhost -t openhab/out/ir/command -m key_3
    repeat = 0
end
begin
    button = KEY_4
    prog = irexec
    config = /usr/bin/mosquitto_pub -h localhost -t openhab/out/ir/command -m key_4
    repeat = 0
end
begin
    button = KEY_5
    prog = irexec
    config = /usr/bin/mosquitto_pub -h localhost -t openhab/out/ir/command -m key_5
    repeat = 0
end
begin
    button = KEY_6
    prog = irexec
    config = /usr/bin/mosquitto_pub -h localhost -t openhab/out/ir/command -m key_6
    repeat = 0
end

To publish an MQTT topic each time a defined code is received by LIRC.

Launching irexec it's possible to check the published topics with an MQTT spy as, for example, MQTTlens

To start irexec as a demon at startup, add this row to /etc/rc.local

/usr/bin/irexec -d &

At this point the topic key_# will be published in the openhab/out/ir/command queue of the localhost broker when the KEY # is pressed.

Add the items subscribing those topics:

items/ir.items

Switch Ir_0 "IR0"  {mqtt= "<[broker1:openhab/out/ir/command:command:ON:key_1], <[broker1:openhab/out/ir/command:command:OFF:key_4]", autoupdate="false"}
Switch Ir_1 "IR1"  {mqtt= "<[broker1:openhab/out/ir/command:command:ON:key_2], <[broker1:openhab/out/ir/command:command:OFF:key_5]", autoupdate="false"}
Switch Ir_2 "IR2"  {mqtt= "<[broker1:openhab/out/ir/command:command:ON:key_3], <[broker1:openhab/out/ir/command:command:OFF:key_6]", autoupdate="false"}

Use those items to perform some action using some rules. E.g.: switch on and off the RGB LED:

rules/ir.rules

rule "IR_0-ON"
    when 
        Item Ir_0 received command ON
    then
        sendCommand(LedR, OFF)
end

rule "IR_0-OFF"
    when 
        Item Ir_0 received command OFF
    then
        sendCommand(LedR, ON)
end

rule "IR_1-ON"
    when 
        Item Ir_1 received command ON
    then
        sendCommand(LedG, OFF)
end

rule "IR_1-OFF"
    when 
        Item Ir_1 received command OFF
    then
        sendCommand(LedG, ON)
end

rule "IR_2-ON"
    when 
        Item Ir_2 received command ON
    then
        sendCommand(LedB, OFF)
end

rule "IR_2-OFF"
    when 
        Item Ir_2 received command OFF
    then
        sendCommand(LedB, ON)
end

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

1-Wire interface

1-Wire is a device communications bus system designed by Dallas Semiconductor Corp. This article explains how to use it on the CM3-HOME.

What is a 1-wire bus ?

The most popular use of 1-wire bus is to use the Dallas DS18B20 temperature sensors. The image below illustrates how to wire it on the screw terminals available on the CM3-Home board. It is possible to wire more than one sensor.

As depicted on the CM3-HOME schematic, the 1-wire data line is interfaced through a dedicated buffer in order to allow a more robust bus, therefore it doesn't require a pullup.

The example supplied reads the temperature value returned by the sensor and shows it on the UI .

Habpanel

Classic UI or mobile App

Basic UI

Once defined, the item is part of the OpenHAB environment and can be used as shown in a single panel or integrated in a more complex dashboard that collects the values from other sensors, with different technologies.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

OpenHAB and 1-Wire

This article describes how to OpenHAB can read a Dallas DS18B20 temperature sensor directly attached to the dedicated socket of the CM3-Home.

To read the sensor value we are going to use the binding that allows to execute periodically a script.

Install the Exec Binding

Install and configure the sensor (1-Wire interface), note the ID of your sensor.

Scripts

Create the file

scripts/onewiretemp.sh

with the following content:

#!/bin/bash
wert=`cat /sys/bus/w1/devices/$1/w1_slave | tail -n1 | cut -d '=' -f2`
wert2=`echo "scale=3; $wert/1000" | bc`
echo $wert2

give it the execute rights:

sudo chmod +x onewiretemp.sh

test the script executing the command ./onewiretemp.sh sensorID

Things

add things to the Exec binding (Inbox > Exec Binding > Choose Thing > Configure Command) with the command:

/etc/openhab2/scripts/onewiretemp.sh sensorID



get the output thing string (Configuration > Things > Command):


Items

Create the file

items/onewire.items

add the following line using the thing definition previously got:

String Temp1Wire "Temperature [%s °C]" <temperature> {channel="exec:command:onewire:output"}

Add the sensor to the sitemaps/cm3home.sitemap to show the value on Basic, Classic and mobile App UI:

Frame label="1-wire"
{
    Text label="Temperature" icon=temperature
    {
        Text item=Temp1Wire
    }
}

To use the item value in a widget to show in an habpanel, as in Widgets management in OpenHab, it needs another step. Because the value read from the sensor is a string, it must be converted to a float value before being used in a knob widget.

Add a number item:

items/onewire.items

String Temp1Wire "1-Wire Temp [%s °C]" <temperature> {channel="exec:command:1wire:output"}
Number Temp1WireValue "1-Wire Temp [%.1f °C]" <temperature>

and create a rule to convert the string in a float:

rules/temp.rules

rule "StringToInt"
when
    Item Temp1Wire changed
then
    var Temp = Temp1Wire.state.toString
    val TempFloat = Float::parseFloat(Temp)

    Temp1WireValue.postUpdate(TempFloat)
end

When the string value changes the rule is triggered converting it in the float variable Temp1WireValue, to be used in the widget.

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Using serial port

A serial port interface at 3.3 volt is available on the CM3-Home to connect external microcontrollers like Arduino or ESP8266.

The signals are available on screw terminals as visible below and are at 3.3 volt level. The lines are not-tolerant to 5 volt.


This port is visible in Linux as /dev/ttyUSB3 device.

Example

As an example of a serial communication, a working example of data echange with an Arduino board is supplied in the SD card.

To show how informations can be exchanged between CM3-Home and Arduino board in both directions using different items, we used some devices commonly used in this environment:

  • NeoPixel Ring
  • A mini servo
  • A Cadmium Sulfide (CdS) LDR (Light Dependent Resistor) or photoresistor

The LEDs color and position and the servo angle can be set with the ready to use interfaces. The ambient light level is shown with a knob used as instrument.

Classic UI

Basic UI

Hab Panel

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Serial binding configuration

Control and Arduino board through the serial port.

Let's see the Arduino code. The serial port, configured accordingly to the Arduino board used, keeps waiting for data. When they are available, the program starts decoding them as a sequence of comma delimited BCD values. The string ends when a carriage return character is received.

The sketch uses some standard libraries:

  • Fastled library available in Arduino environment. In OpenHAB we used a Colorwheel item with 0 to 255 RGB values and the number of LEDs to light up from 1 to 16 (0 = all OFF)
  • Servo library. It receives from OpenHAB the position command from 0 to 180° to set the servo position
void ReadCommand(void)
{
    /*Read a command string from the serial port
    the string must follow this format:
    LedNum,red,green,blue,servo1Pos\r
    where:
    LedNum is the number of LEDs ON on the LED ring (clockwise), 0 (all OFF) to 16 (all ON)
    red, green blue are the RGB values for all the LEDs, 0 to 255
    Servo1Pos is the position of the servo, 0 to 180°
    all the values are in BCD no leading zeroes, i.e.:
    value = 128 means
    ASCII 49
    ASCII 50
    ASCII 56
    value = 64 means
    ASCII 54
    ASCII 52
    all the values are comma separated
    all values must be always sent, even if no change
    carriage return terminates the string
    */
    
    while (Serial1.available() > 0) 
    {
      digitalWrite(led,1);
      pixel = Serial1.parseInt();
      red = Serial1.parseInt();
      green = Serial1.parseInt();
      blue = Serial1.parseInt();
      servo1Pos = Serial1.parseInt();
      
      if (Serial1.read() == '\r') 
      {
        digitalWrite(led,0);
        pixel = constrain(pixel, 0, 16);
        red = constrain(red, 0, 255);
        green = constrain(green, 0, 255);
        blue = constrain(blue, 0, 255);
        servo1Pos = constrain(servo1Pos, 9, 180);
        
        gear(pixel, red, green, blue);
        
        servo1.write(servo1Pos);
      }
    }
}

The LED ring and the servo are driven with the received values

void gear(int Pos, byte red, byte green, byte blue)
{
  if (Pos>NUM_LEDS[0])
  {
    Pos=NUM_LEDS[0];
  }
  
  for(int i=1; i<=NUM_LEDS[0]; i++)
  {
    int j=NUM_LEDS[0]-i;
    if(i<=Pos)
    {
      setPixel(j,red,green,blue);
    }
    else
    {
      setPixel(j,0,0,0);
    }
  }
  FastLED.show();
}

The communication is performed through the Serial Binding. The port to use must be added to the java environment (in this case /dev/ttyUSB3) in /etc/defaults/openhab2


EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB2:/dev/ttyUSB3:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA0"

Then configure the items needed:

String Arduino "Light [%d]"  (arduino) {serial="/dev/ttyUSB3@9600"}

Dimmer LedRingPos "LED Ring"  (arduino)
Color LedRingColor "Color [%s]"  (arduino) 

Dimmer Servo1 "Servo"  (arduino)

String toSerialTTL "LED Ring [%s]"   {serial="/dev/ttyUSB3@9600"}
  • The 'Arduino' item is used to receive the ambient light data string from the external board.
  • The 'LedRingPos' is used to send the number of LEDs in the ring to switch on.
  • The 'LedRingColor' item is a Color type, specific to manage HSB color values.
  • The 'Servo1' item is a dimmer type to setup the servo position.
  • The 'toSerialTTL' item is not visualized, it's used to send the string to Arduino through the serial port.

To prepare the data from and to the external board, we have to use some rules.

When the colorwheel values change, the LedRingColor item status acquires the HSB variable values. Because the LED ring needs the 0 to 255 RGB values, we must use the red, green, blue (from 0 to 100) methods multiplied by 255. They must then formatted as a BCD comma delimited string and sent to the serial port.

var HSBType hsb
var RingPos = 0.0
var red = 0
var green = 0
var blue = 0
var Servo1Pos = 0.0

rule "HSBtoRGB"
    when
        Item LedRingColor changed
    then
        hsb = LedRingColor.state as HSBType
        red   = (hsb.red * 2.55).intValue
        green = (hsb.green * 2.55).intValue
        blue  = (hsb.blue * 2.55).intValue
        
        toSerialTTL.sendCommand(RingPos+","+red+","+green+","+blue+","+Servo1Pos+"\r")
end

To setup the number of lighted LEDs a dimmer item is used. It generates a 0 to 100 value. Dividing it by 6.25 we have a 0 to 16 value.

rule "Led Ring Pos"
    when
        Item LedRingPos changed
    then
        RingPos = ((LedRingPos.state as DecimalType) / 6.25).intValue
        toSerialTTL.sendCommand(RingPos+","+red+","+green+","+blue+","+Servo1Pos+"\r")
end

Similarly the Servo1 dimmer status is multiplied by 1.8 in order to have a 0 to 180 range.

rule "Servo1 Pos"
    when
        Item Servo1 changed
    then
        Servo1Pos = ((Servo1.state as DecimalType) * 1.8).intValue
        toSerialTTL.sendCommand(RingPos+","+red+","+green+","+blue+","+Servo1Pos+"\r")
end

The value received by the Arduino, i.e. the ambient light, must be converted in a numeric variable to be used. The item status must therefore be converted as a string before to have a BCD value, this can be then converted as an integer. Being a numeric variable it can be used in a rule to, for example, switch on one of the aforementioned KMTronic relays when the value of ambient light falls below an established threshold.

rule "LDR"
    when 
        Item Arduino changed
    then
        var LightStr = Arduino.state.toString
        var Light = new java.math.BigDecimal(Integer::parseInt(LightStr))
        
        if (Light > 800)
        {
            toSerial.sendCommand("\u00FF\u0001\u0001")
        }
        else
        {
            toSerial.sendCommand("\u00FF\u0001\u0000")
        }
        
end

To use those items they must be defined in our sitemap file.

  • Text item=Arduino - shows the value read from LDR (0-1024)
  • Slider item=LedRingPos - setup the number of lighted LEDs on the ring
  • Colorpicker item=LedRingColor - setup the color and the brightness of the LEDs ring
  • Slider item=Servo1 - manage the servo position
 Frame label="Serial"
    {
        Text label="Arduino" icon=sensor
        {
            Text item=Arduino
            Slider item=LedRingPos 
            Colorpicker item=LedRingColor
            Slider item=Servo1 
        }
    }

TIP

Sometime it happens that the value of an item in the UI is not dynamically updated. In this case you can see in the karaf control that the PageChangeListener.get service is closed due to an undefined sitemap reading when the file has been saved. To re-establish the normal functionality you have to restart the OpenHAB service:

sudo systemctl restart openhab2

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Light bus interface - Using the DALI bus

This bus implements a hardware interface commonly used to connect some commercial DALI devices.



Warning: CM3-Home is not a certified DALI controller !
An open hardware is implemented on it so we can't warranty the fully functionality with any DALI devices

What is the DALI bus ?

Features

  • Signals available on two screw terminals
  • Bus opto-isolated from the CPU side
  • Power supply provided on the bus for up to 16 devices without need an external power supply
  • Bus managed in bit banging mode

The bus can be powered by the internal isolated power supply closing the power jumper.

The example supplied drives a DALI controller to set the color of some LEDs strips.

Habpanel

Classic UI or mobile App

Basic UI

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Dali - Implementing the protocol in bit-banging mode

DALI, Digital Appliance Lighting Interface, is a standard wired communications protocol used for Home & Building lighting applications. The interface was originally specified to support connectivity for fluorescent light ballasts, but has also been designed to support other lighting technologies.



Warning: CM3-Home is not a certified DALI controller !
An open hardware is implemented on it so we can't warranty the fully functionality with any DALI devices

Drive DALI devices with OpenHAB

In OpenHAB there is no specific binding for DALI protocol. A simple Python test program (daly.py) can be arranged adding RGB values as input parameters:

if len(sys.argv)==4:
    RedV = int(sys.argv[1])
    GreenV = int(sys.argv[2])
    BlueV = int(sys.argv[3])
    if RedV > 254: RedV = 254
    if GreenV > 254: GreenV = 254
    if BlueV > 254: BlueV = 254
    
    if RedV < 0: RedV = 0
    if GreenV < 0: GreenV = 0
    if BlueV < 0: BlueV = 0

    send_color_red(int(sys.argv[1]))
    send_color_green(int(sys.argv[2]))
    send_color_blue(int(sys.argv[3]))

Adding the specific functions:

def send_color_red(value):
    global LED_RED
    
    print(LED_RED)
    print(value)
    send_start()
    send_short_address(LED_RED)
    send_value(value)
    send_stop()
    send_stop()
    time.sleep(0.001)
    
def send_color_green(value):
    global BIT_DELAY
    global GPIO_TX_LINE
    
    send_start()
    send_short_address(LED_GREEN)
    send_value(value)
    send_stop()
    send_stop()
    time.sleep(0.001)
    
def send_color_blue(value):
    global BIT_DELAY
    global GPIO_TX_LINE
    
    send_start()
    send_short_address(LED_BLUE)
    send_value(value)
    send_stop()
    send_stop()
    time.sleep(0.001)

Just one colorwheel item is needed

items/dali.items

Color DaliColor "Color [%s]"  (dali) 

With a rule you can read the item status that returns the HSB values of the selected color. Those HSB values can be converted in RGB and sent as parameters to the Python program in order to setup the desired color.

rules/dali.rules

var HSBType hsb
var red = 0
var green = 0
var blue = 0
var Cmd="/usr/bin/python@@/etc/openhab2/scripts/dali.py"

rule "HSBtoRGB"
    when
        Item DaliColor changed
    then
        hsb = DaliColor.state as HSBType
        red   = (hsb.red * 2.55).intValue
        green = (hsb.green * 2.55).intValue
        blue  = (hsb.blue * 2.55).intValue
        
        val results = executeCommandLine(Cmd+"@@"+red+"@@"+green+"@@"+blue,5000)
        logInfo("Exec",results)
end

sitemaps/cm3home.sitemap

Frame label="Dali"
    {
        Text label="Dali" icon=colorwheel
        {
            Colorpicker item=DaliColor
        }
    }

Bit-banging a GPIO to realize the DALI protocol

Bus and protocol

The physical interface consists of 2 wires, DALI Power and DALI Data. The DALI system consists of one DALI Control module with up to 63 DALI devices.

  • DALI Power line provides the power only for the communication protocol of a maximum 22.5V and limits the current for the system to 250mA.
  • The DALI Data line provides the half duplex communication at a data rate of 1200 bits/second using a bi-phase (Manchester) decoding.

Bi-phase decoding is accomplished with the following:

  • a logical zero consists of sending a physical low signal for 416 µs immediately followed with a physical high signal for 416 µs.
  • a logical one consists of sending firstly a physical high signal for 416 µs followed by a physical low signal.

A physical high signal on the DALI Data line is a voltage level between +9.5V and +22.5V. A physical low signal on the DALI Data line is a voltage level between -6.5V and +6.5V.

The DALI digital layer consists of 2 frames, a forward frame and a backward frame.

  • A forward frame is a frame sent from a DALI controller to a DALI ballast. It is constructed by a START bit (always logical 1), followed by 1byte Address,1byte Command and two STOP bits (a high level with no transitions).
  • A DALI ballast communicates back to the DALI control using only a 1byte backward frame consisting of a START bit,1byte,2 STOP bits.

The DALI protocol allows a master controller options to address all ballasts by either broadcast to all, Groups of ballasts, and individual addressing.

The most commonly used direct commands allow the controller to modify lighting brightness, scene settings for groups, fading capability and varying rates. Also including are Query command that request the ballast to send a backward frame with configuration data such as, power levels, scene levels, current address.

Using “extended” Configuration command the DALI controls can modify addresses of each ballast thus eliminating manual configuration of the DALI system.

The “extended” configuration command will follow immediately after a DALI controller sends an INITIALIZE ($A5) command, which informs all other DALI devices on the bus to ignore further commands until a TERMINATE command is observed or 30 s elapses in time.

Hardware

The DALI bus depends on the specific power supply, this is an example used in a development board:

With kind of schematic the voltage on the bus depends too much from the load. How is shown on the graphs Vout begins to go down before the current is half of the maximum load. The DALI specification imposes a 2mA maximum load for each device on the bus, but analyzing some of the available devices, it's evident that this limit is often exceeded. Furthermore, most of the real devices consume this current constantly. This kind of power supply would be too much limited on the maximum number of the connectable device.

Using an integrated, current limited power supply, the circuit works much better, with a much more accurate Imax regulation and, above all, a sharper knee at the current threshold. The voltage is stable until the intervention of the current limiter.

The DALI system is designed to be realized in an easy and cheap way, it's very tolerant both on voltage and on signals shape. These are the specifications:

The circuit has been designed to stay widely within specifications, in order to be able to tolerate any degradation when the bus is not perfectly realized or with strange loads.

A generator that injects a 50% duty cycle, 3.3V square wave to the TX input composes the test bench. The measurement is on the RX output. The DALI bus is in loopback by nature: TX and RX are connected on the same pair of wires. The circuit parameters have been fine tuned to have on the output a signal as close as possible to the one at the input.

The graph shows a shape well within the specifications even with a frequency double of the working one.

A the extreme, the signal is still acceptable at 10 times the working frequency.

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems
Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Using the GPIO lines

This article illustrates how to manage the Rasberry Pi input/output (GPIO) lines from openHAB. Four of these lines are available to the user in form of dry contact inputs and relays.

Dry contact input terminals

CM3-Home board has two dry-contact inputs designed to get the state of mechanical contacts like switches or push-buttons. The contacts are available on screw terminals with a return common line as shown below:

The input lines are opto-isolated from the CPU side and are in the same "electrical domain" of the RS485 ports.

The GPIOs used are:

  • GPIO 28: Left side contact #1. When closed the GPIO level is low
  • GPIO 29: Right side contact #2. When closed the GPIO level is low

Relay output terminals

Two relays are available on the screw terminals as shown below:

  • Normally-Opened and Normally-Closed contacts available on screw terminals
  • Max rated: 24 VAC/DC @ 1A
  • Snubbers already on-board to increase reliability with inductive loads

The GPIO used are:

  • RL1 (left relay) GPIO21
  • RL2 (right relay) GPIO22

Manage the input/output lines via openHAB

Some usage example of the GPIOs directly driving them with the user interface.

The devices controlled by the GPIO binding are automatically driven by some rules in certain conditions.

Through the user interfaces the automatic commands can be bypassed.

Habpanel

Classic UI or mobile App

Basic UI

Automatic usage

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

GPIO

How to use the CM3-Home GPIOs

The opto-isolated inputs, the relays and the RGB led are driven through the OpenHAB GPIO binding. The WiFi module too can be switched on and off with OpenHAB items.

This binding has be written for the OpenHAB 1, the OpenHAB 2 compatibility could create some problems, please follow the GPIO binding documentations

The devices are connected to the Compute Module 3 GPIOs as explained in CM3-Home - hardware reference

After installing the GPIO binding:


Define the items to use them in user interfaces and in rules:

items/gpio.items

Switch Rele1 "Relay"  {gpio="pin:21 activelow:no initialValue:low"}
Switch Rele2 "Relay"  {gpio="pin:22 activelow:no initialValue:low"}
Contact Pushbutton_left "Switch 1 [%s]" {gpio="pin:28 debounce:1 activelow:no"}
Contact Pushbutton_right "Switch 2 [%s]" {gpio="pin:29 debounce:1 activelow:no"}

Switch WiFi "WiFi" {gpio="pin:37 activelow:no initialValue:high"}

Switch LedR "Red LED"  {gpio="pin:36 activelow:no initialValue:high"}
Switch LedG "Green LED"  {gpio="pin:35 activelow:no initialValue:high"}
Switch LedB "Blue LED"  {gpio="pin:34 activelow:no initialValue:high"}

To show the items as defined in Classic UI, in Basic UI and in mobile APP define them in the sitemap:

sitemaps/cm3home.sitemap

Frame label="GPIO" 
    {
        Text label="Input/Output" icon=poweroutlet
        {
            Switch item=Flash 
            Switch item=Rele2
            Text item=Pushbutton_left
            Text item=Pushbutton_right
            Switch item=WiFi
            Switch item=LedR
            Switch item=LedG 
            Switch item=LedB 
        }
    }

In the distribution supplied the GPIO items are configured in some rules to be automatically activated under precise conditions.

Example 1: restart the router in case of internet connection fault (Manage the internet router)

rules/speedtest.rules

.....
rule "Router Restart"
when 
    Item RouterRestart changed
then
    sendCommand(Rele2, ON)
    set_timer = createTimer(now.plusSeconds(5))
    [
        sendCommand(Rele2, OFF)
        RouterRestart.postUpdate(ON)
        set_timer = null
    ] 
end 
.....

Example 2: blink RGB LED in different color to advise on power consumption and switch on a beeper as an alarm (OpenHab Modbus)

rules/modbus.rules

.....
else if (Power > 3000)
        {
            sendCommand(LedR, OFF)
            sendCommand(LedB, ON)
            sendCommand(LedG, ON)
            sendCommand(Rele1, ON)
            set_timer = createTimer(now.plusSeconds(0.1))
            [
               sendCommand(LedR, ON)
               set_timer = null
            ]  
            set_timer = createTimer(now.plusSeconds(1))
            [
               sendCommand(Rele1, OFF)
               set_timer = null
            ]      
        }
.....

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

RS-485 interface

The RS485 is commonly used to connect many devices (usually up to 32 unit loads) in a multidrop line in harsh environments.

What is a RS485 ? What is a DMX512 ? What is a Modbus ?

Two RS485 lines are available on CM3-Home model Full and one on the model Basic. The lines are opto-isolated from the CPU and available on screw terminals as shown below.

How to use the RS485 ports

The ports are visible by Linux on /dev/ttyUSB0 (left port) and /dev/ttyUSB2 (right port) and can be managed by software like any other serial line. The DE signals required to get the bus are managed by the hardware on FTDI FT4232 chip.

The examples supplied refer to the three main uses of the RS485 bus:

  • Generic serial devices
  • Modbus
  • DMX512

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Generic serial device

The example supplied drives a KMTronic eight channel RS485 relay controller with no protocol at all.

The CM3-Home left RS485 bus can be directly connected to one or more KMTronic or similar devices via a twisted pair. The program is configured to drive a device with the lower address with Classic UI (or mobile App):

With the Basic UI:

or with a panel:

Configuration

It uses the Serial Binding to communicate. The port to use must be added to the java environment (in this case /dev/ttyUSB2) in /etc/defaults/openhab2


EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB2:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA0"

The items/kmt.items file defines the items to be used

Switch kmt1 "KMTronic A1"  (kmtA) 
Switch kmt2 "KMTronic A2"  (kmtA) 
Switch kmt3 "KMTronic A3"  (kmtA) 
Switch kmt4 "KMTronic A4"  (kmtA) 
Switch kmt5 "KMTronic A5"  (kmtA) 
Switch kmt6 "KMTronic A6"  (kmtA) 
Switch kmt7 "KMTronic A7"  (kmtA) 
Switch kmt8 "KMTronic A8"  (kmtA) 

String toSerial "To Serial [%s]"   {serial="/dev/ttyUSB2@9600"}

Group:Switch:OR(ON, OFF) kmtA   "KMTronic"

The switch item is needed to create the push button and trigger the rules. The string item is needed to transmit serial data.

To show them in standard UI, configure the sitemaps/cm3home.sitemap:

Frame label="RS485 KMTronic"
    {
        Text label="Relays" icon=switch
        {
            Switch item=kmt1  
            Switch item=kmt2   
            Switch item=kmt3   
            Switch item=kmt4   
            Switch item=kmt5   
            Switch item=kmt6   
            Switch item=kmt7   
            Switch item=kmt8   
            Switch item=kmtA
         }                
      }

This RS485 relays controller device is driven simply by sending three ASCII characters strings

Relay commands:
OFF command : FF xx 00 (HEX) or 255 xx 0 (DEC)
ON command : FF xx 01 (HEX) or 255 xx 1 (DEC)

to be composed according to this table

KMTronic commands

java uses unicode character set. The output string must be formatted using 16 bit \u format.

in rules/kmt.rules file are defined all the rules to send the ASCII command string corresponding to the button pushed

rule "kmtA1_ON"
    when 
        Item kmt1 received command ON
    then
        toSerial.sendCommand("\u00FF\u0001\u0001")
end

rule "kmtA1_OFF"
    when 
        Item kmt1 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0001\u0000")       
end

rule "kmtA2_ON"
    when 
        Item kmt2 received command ON
    then
        toSerial.sendCommand("\u00FF\u0002\u0001")
end

rule "kmtA2_OFF"
    when 
        Item kmt2 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0002\u0000")       
end

rule "kmtA3_ON"
    when 
        Item kmt3 received command ON
    then
        toSerial.sendCommand("\u00FF\u0003\u0001")
end

rule "kmtA3_OFF"
    when 
        Item kmt3 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0003\u0000")       
end

rule "kmtA4_ON"
    when 
        Item kmt4 received command ON
    then
        toSerial.sendCommand("\u00FF\u0004\u0001")
end

rule "kmtA4_OFF"
    when 
        Item kmt4 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0004\u0000")       
end

rule "kmtA5_ON"
    when 
        Item kmt5 received command ON
    then
        toSerial.sendCommand("\u00FF\u0005\u0001")
end

rule "kmtA5_OFF"
    when 
        Item kmt5 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0005\u0000")       
end

rule "kmtA6_ON"
    when 
        Item kmt6 received command ON
    then
        toSerial.sendCommand("\u00FF\u0006\u0001")
end

rule "kmtA6_OFF"
    when 
        Item kmt6 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0006\u0000")       
end

rule "kmtA7_ON"
    when 
        Item kmt7 received command ON
    then
        toSerial.sendCommand("\u00FF\u0007\u0001")
end

rule "kmtA7_OFF"
    when 
        Item kmt7 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0007\u0000")       
end

rule "kmtA8_ON"
    when 
        Item kmt8 received command ON
    then
        toSerial.sendCommand("\u00FF\u0008\u0001")
end

rule "kmtA8_OFF"
    when 
        Item kmt8 received command OFF
    then        
        toSerial.sendCommand("\u00FF\u0008\u0000")       
end

The character set installed by default on Openhabian doesn't manage characters beyond 0x3F code. It must therefore be changed in en_US ISO-8859-1. This operation can be executed with openhabian-config, but this operation doesn't work immediately in the current version. You must delete the /etc/default/locale before using the menu item:

 30 | System Settings
    32 | Set System Locale 

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Modbus

The example supplied with the SD card is set to read an Eastron SDM120 energy meter with Modbus protocol and show the main line electric parameters.

The energy values can be displayed on:

Classic UI

Basic UI

Or in the Habpanel

The system is preconfigured to blink the RGB led with green light if the power consumption is below 2.5kWh, blue between 2.5kWh and 3.0kWh and red if the power exceeds the usual 3kWh contractual limit. In this alarm condition the left relay is activated giving the possibility to switch on a beeper, a siren or wathever for a better notification of the possible near future fault of the main power line.

The power limits can be modified editing the rules/modbus.rules file.

Configuration

Once the Modbus binding is installed, the usual three files are available .

The default configuration of the SDM120 has not been modified. The details about the configuration and the registers exposed by the device are linked below. The system device used in this example is /dev/ttyUSB0, related to the most left RS485 socket on the board.

services/modbus.cfg

#the serial object has been attached to the RS485 port through the /dev/ttyUSB0 device
#the SDM120 default speed is 2400bps
#the handshake is in RTU mode
serial.Voltage.connection=/dev/ttyUSB0:2400:8:none:1:rtu:35:1500:none:none

#this is an input device
serial.Voltage.type=input

#device ID = 1
serial.Voltage.id=1

#the starting register for the Voltage variable is 0 (device dependant)
serial.Voltage.start=0

#the variable is two 16bit world lenght (4 byte)
serial.Voltage.length=2

#it's a float32 variable
serial.Voltage.valuetype=float32

#for each other variable it needs a similar configuration set

serial.Current.connection=/dev/ttyUSB0:2400:8:none:1:rtu:35:1500:none:none
serial.Current.type=input
serial.Current.id=1
serial.Current.start=6
serial.Current.length=2
serial.Current.valuetype=float32

serial.Power.connection=/dev/ttyUSB0:2400:8:none:1:rtu:35:1500:none:none
serial.Power.type=input
serial.Power.id=1
serial.Power.start=12
serial.Power.length=2
serial.Power.valuetype=float32

serial.CosFi.connection=/dev/ttyUSB0:2400:8:none:1:rtu:35:1500:none:none
serial.CosFi.type=input
serial.CosFi.id=1
serial.CosFi.start=30
serial.CosFi.length=2
serial.CosFi.valuetype=float32

serial.Freq.connection=/dev/ttyUSB0:2400:8:none:1:rtu:35:1500:none:none
serial.Freq.type=input
serial.Freq.id=1
serial.Freq.start=70
serial.Freq.length=2
serial.Freq.valuetype=float32

serial.Ener.connection=/dev/ttyUSB0:2400:8:none:1:rtu:35:1500:none:none
serial.Ener.type=input
serial.Ener.id=1
serial.Ener.start=72
serial.Ener.length=2
serial.Ener.valuetype=float32

On this example we read the parameters for voltage, current, active power, power factor (CosFi), frequency and energy for the phase 1 from registers 0, 6, 12, 30, 70 e 72 .

Now we can associate the items to these parameters, the key is the name of the objects created in modbus.cfg. The items related to the desired variables must be formatted for the printout similarly to the printf sintax.

items/modbus.items

Number L1V "Tensione [%.1f V]" {modbus="Voltage:0"}
Number L1A "Corrente [%.1f A]" {modbus="Current:0"}
Number L1P "Potenza A [%.1f W]" {modbus="Power:0"}
Number L1C "Cos Fi [%.2f]" {modbus="CosFi:0"}
Number L1F "Frequenza [%.1f Hz]" {modbus="Freq:0"}
Number L1E "Energia A [%.1f kWh]" {modbus="Ener:0"}

To show the values on the GUI, the variables must be associated to the sitemap. The association is possible through the name of the items.

sitemaps/cm3home.sitemap

sitemap knx label="GUIOTT home" 
{
      ...
    
        Frame label="Energia"
        {   
            Text label="Energia" icon=pressure
            {
                Text item=L1V valuecolor=[>240="red",>230="orange",>220="green",<=220="orange"]
                Text item=L1A
                Text item=L1P valuecolor=[>3300="red",>3000="orange",>2500="green",<=2500="blue"]
                Text item=L1C valuecolor=[>0.8="green",<=0.8="orange"]
                Text item=L1F valuecolor=[<49="orange",>49="green",>51="orange"]
                Text item=L1E
            }
        }

}

Now the service starts polling the energy meter to collect data with the polling time configured on services.cfg file, updating the values on the various User Interfaces.

The knob widget can be used as instruments, disabling interaction:

Can also be enabled the measure range of the instrument, so the bar change its color depending on some alarm thresholds:

The values collected can be used to obtain, for example, some audible or visible alarms as in the example below:

rules/modbus.rules

var Cmd="python /etc/openhab2/scripts/led.py "
var Timer set_timer = null

rule "Led"
    when
        Time cron " 0/3 * * ? * * *"
    then   
        var Power = (L1P.state as DecimalType).intValue
         if (Power <= 2500)
         {
             //val results = executeCommandLine(Cmd+"G",5000)
             //logInfo("Exec",results)
             sendCommand(LedG, OFF)
             sendCommand(LedB, ON)
             sendCommand(LedR, ON)
             set_timer = createTimer(now.plusSeconds(0.1))
             [
                sendCommand(LedG, ON)
                set_timer = null
             ]
         }
         else if (Power > 2500 && Power <= 3000)
         {
            //val results = executeCommandLine(Cmd+"B",5000)
            //logInfo("Exec",results)
            sendCommand(LedB, OFF)
            sendCommand(LedG, ON)
            sendCommand(LedR, ON)
            set_timer = createTimer(now.plusSeconds(0.1))
            [
               sendCommand(LedB, ON)
               set_timer = null
            ]         
        }
         else if (Power > 3000)
         {
            //val results = executeCommandLine(Cmd+"R",5000)
            //logInfo("Exec",results)
            sendCommand(LedR, OFF)
            sendCommand(LedB, ON)
            sendCommand(LedG, ON)
            sendCommand(Rele1, ON)
            set_timer = createTimer(now.plusSeconds(0.1))
            [
               sendCommand(LedR, ON)
               set_timer = null
            ]  
            set_timer = createTimer(now.plusSeconds(1))
            [
               sendCommand(Rele1, OFF)
               set_timer = null
            ]      
        }
end

In this case the RGB LED blinks with different colors when some electrical power thresholds have been exceeded. Furthermore one of the two relays is used to switch a buzzer, alerting with more evidence that the contractual power threshold has been exceeded. This is one of the probably most useful function, hearing the beep one can immediately switch off the appliance in use, avoiding to go dowstairs to reset the main breaker.

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Driving a DMX-512 bus with a CM3-Home RS485 port

The DMX512, often shortned as DMX (Digital MultipleX), is a digital communication standard mainly used to control scene lighting in the entertainment industry, to control numerous lights and effects from a central console. Recently it was introduced also in the civil field for architectural lighting.

Here an example about realizing such a protocol with some Python code that can be launched by OpenHAB with an executeCommandLine instruction in a rule.

The DMX512 bus is basicly an RS485 serial comm @ 250 kbps 8N2

Python code

It opens the /dev/ttyUSB2 RS485 port and sends three commands sequences towards all the 512 possible devices addressable on a DMX512 bus. This example has been tested with a VDPL300CB device that is configured to reply to addresses from 0 to 5 (A001)

The test program lights on in sequence the Red, Green and Blue LEDs.

import serial
import time

ser = serial.Serial("/dev/ttyUSB2")
ser.baudrate = 250000
ser.bytesize = serial.EIGHTBITS
ser.parity = serial.PARITY_NONE
ser.stopbits = serial.STOPBITS_TWO
ser.xonoff = False

def sendCmd(red,green,blue):
    ser.send_break(duration=0.25)
    ser.write(chr(0))

    ser.write(chr(0))
    ser.write(chr(red))
    ser.write(chr(green))
    ser.write(chr(blue))
    ser.write(chr(0))
    ser.write(chr(0))

    for i in range(512-6):
        ser.write(chr(0))

    ser.flush()

while True:
    for red in range (0,255,50):
        sendCmd(red,0,0)

    for green in range (0,255,50):
        sendCmd(0,green,0)

    for blue in range (0,255,50):
        sendCmd(0,0,blue)

ser.close()

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

ISM radio - YARM

Example using the YARM analog input

The CM3-Home full edition includes a YARM D21 module. It gives to the CM3-Home the ability to act as a gateway between the 868MHz free communication band and all the other protocols available on the board.

As shown on the CM3-HOME schematic, four of the YARM's Microchip SAM D21 MCU GPIOs are accessible from outside. Two of them can be used as analog inputs, other two as an I2C bus additional to the one directly attached to the CM3 module.

The analog inputs are pulled-up to the 3.3V with a 3.3kΩ resistor. Therefore these ports, acting as a resistor divider, can be used to measure an external resistor.

A typical usage for this kind of interface is to control a line against tampering. A sensors line for an antitheft alarm is usually balanced, meaning that it has a specific resistance in the idle condition. This resistance changes if the line is tampered, both through shortening or cutting it. Measuring the difference from the idle condition we can know if the line has be cut, shortened or if an alarm condition occurs. The resistor used for a single balanced line is commonly imposed by the manufacturer. For double balancing lines it's a little bit more complicated and the idle value resistance is often auto-calibrated during the initial setup.

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

ISM Radio module with Cortex M0+

A Microchip ATA8510 radio transceiver in the 868 MHz band and a Microchip SAMD21 Cortex M0+ at 48 MHz are the two integrated circuits on the (Yarm) module mounted on the CM3-Home Full edition.

  • The ATA8510 is a ASK/FSK radio transceiver with high sensitivity (-122 dBm) and selectivity.
  • Tested range in open air of over 14 km at 750 bit/s and over 700m at 10kbit/s.
  • Capable to scan multiple radio channels with data link speed reaching 80 kbit/s.
  • Compatible with ISM 868MHz Energy Harvesting ACME Systems radio nodes.
  • MMCX antenna connector onboard with possibilities of external antenna or internal PCB antenna.
  • The SAMD21 is the same processor onboard the Arduino Zero: Cortex M0+ 32 bit.
  • 256 kbytes of FLASH and 32 kbytes of RAM. Completely available for user programming.
  • Compatible with Arduino sketches and bootloader.
  • 1 I2C/GPIO/serial port connected on one of the exposed Grove connectors.
  • 1 serial port connected to one of the Raspberry CM3 serial port.

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 8.90


YARM - ISM 868 MHz radio module

ISM 868 MHz RF radio module with

  • Low power Atmel SAML21 MCU (ARM Cortex M0+ @ 48MHz)
  • 32KByte of RAM memory
  • 256KByte of FLASH memory
  • Atmel ATA8510 Monolithic RF Transceiver IC for Sub-1GHz smart RF applications
| Product description || Flat price up to 999 pcs |

EUR 18.00


YARM-DEV - Evaluation board for YARM module

Carrier board for a rapid evaluation of the YARM radio module cababilities.

In includes the following parts:

  • MicroUSB port for power and data
  • ICP programmer port input
  • Double line of 14 pin pitch 2.54 mm for prototyping
| Product description || Flat price up to 999 pcs |

Test programs for YARM CM3

How to test the YARM module on the CM3-Home board.

Flash a YARM_DEV L21 processor with one of the following programs:

You can use Atmel Studio or this article to do it under Linux (EDBG): Atmel SAML21 ASF compiling and FLASH programming on Linux

Flash the YARM_DEV EEPROM of the ATA8510 with the following configuration:

You can use this article for it: ATA8510 EEPROM programming

Flash the YARM D21 processor onboard the CM3-Home with the following program:

Flash the YARM EEPROM of the ATA8510 onboard the CM3-Home with the following configuration:

At startup the YARM onboard the CM3-Home will display a greeting message with the available commands:

Test CM3-TEST - Ver 0.9                                                                                                             
YARM CM3 01 2018 Jan  3 2018 09:57:23                                                                                               
Sensor Data Packet Length = 28                                                                                                      
cpuhx = 8000000                                                                                                                     
                                                                                                                                    
YARM CM3 help                                                                                                                       
c = toggle ConsoleOn                                                                                                                
y = toggle YARM_Verbose                                                                                                             
1..0 = Period Node Tx 1=2s; 2=4s; .. 0=20s                                                                                          
a = toggle Y_SDA and read ADCs                                                                                                      
b = toggle Y_SCL and read ADCs                                                                                                      
h = print this help menu                                                                                                            

The commands 'a' and 'b' will toggle respectively the two pins of the Grove header connected to the YARM and will read the two ADC lines on the ADC connector of the CM3-Home.
Toggle Y-SDA = 0; ADC_0 4095; ADC_1 4095
Toggle Y-SCL = 0; ADC_0 4095; ADC_1 4095

  • Y-SCL is pin C of the Grove 2 connector
  • Y-SDA is pin D of the Grove 2 connector
  • ADC_0 is pin 1 of the ADC connector
  • ADC_1 is pin 3 of the ADC connector

    If a YARM_DEV is switched on with the above program running, the YARM on the CM3-HOME will receive the messages from the YARM_DEV and will transmit a command as an answer:
Rx: EA188AC04D4D4D512020204C142715FF 75010000 24070000 00008CC2 92                                                                  
Tx: 35D570454E4E4D512D0C0AFF00000000 FFFFFFFF B80B0000 000086C2 BE                                                                  

To have a descritpion of the messages exchanged you can activate the Console On option with the command 'c'

ConsoleOn = 1                                                                                                                       
                                                                                                                                    
                                                                                                                                    
---- RX from YARM Node ------------------                                                                                           
Received 29 bytes on service 0 channel 0                                                                                            
Data Received  [29]                                                                                                                 
Rx: EA188AC04D4D4D512020204C142715FF BA020000 7A070000 000087C2 FB                                                                  
Harvest1 ID: 0xC08A18EA514D4D4D4C202020FF152714                                                                                     
Num Message Received = 698 (0x000002ba)                                                                                             
Node Voltage on PA03: 0x077a (1914)                                                                                                 
RSSI Received from Node: -67.50 dBm                                                                                                 
RSSI: -64.50 dBm                                                                                                                    
RxError: 0                                                                                                                          
checksum received = 0xFB                                                                                                            
checksum calculated = 0xFB                                                                                                          
---- RX from YARM Harvest1 ------------------                                                                                       
                                                                                                                                    
                                                                                                                                    
---- Tx to YARM Node ------------------                                                                                             
Send to Node: Command = 2000 (7d0); RSSI received from Node = -64.50                                                                
Data to Send [29]                                                                                                                   
Tx: 35D570454E4E4D512D0C0AFF00000000 BA020000 D0070000 000081C2 EF                                                                  
---- Tx to YARM Node ------------------                                                                                             

Here is the description of the fields of the message received from the YARM_DEV Node:

  • Unique serial number of the YARM_DEV (16 bytes)
  • Progressive Message Number from the Start (4 bytes)
  • Voltage measured on the PA03 pin of the YARM_DEV (integer 4 bytes)
  • RSSI in dBm received on the last message coming from the CM3-HOME (float 4 bytes)

Here is the description of the fields of the message transmitted to the YARM_DEV Node:

  • Serial number of the YARM onboard the CM3-Home (16 bytes)
  • Progressive Message Number from the Start (4 bytes)
  • Command with the wanted transmission period for the YARM_DEV Node (integer 4 bytes)
  • RSSI in dBm received on the last message coming from the YARM_DEV_Node (float 4 bytes)

With the commands 0..9 it is possible to instruct the YARM_DEV Node to send messages with different periods of time from 2s (1) to 20s (0).

You can activate a more verbose description of the underlying YARM radio activities with the 'y' command:

YARM_Verbose = 1                                                                                                                    
YARM_Libs: Data Received [32]                                                                                                       
 0xEA,  0x18,  0x8A,  0xC0,  0x4D,  0x4D,  0x4D,  0x51,  0x20,  0x20,  0x20,  0                                                     
Done YARM_SetIdleMode [0x0 0x0]                                                                                                     
Rx: EA188AC04D4D4D512020204C142715FF E7030000 2C070000 000086C2 1C                                                                  
Tx: 35D570454E4E4D512D0C0AFF00000000 E4030000 B80B0000 000078C2 E1                                                                  
Done YARM_SetIdleMode [0x0 0x0]                                                                                                     
Reg. GETEVENTBYTES: 0x0, 0x0, 0x0, 0x40,                                                                                            
Done YARM_SetSystemMode TXMode [0x0 0x0]                                                                                            
Error at YARM_WriteTxPreamble, ErrorCode: 21                                                                                        
Error at YARM_WriteTxFifo, ErrorCode: 21                                                                                            
TXLoop Started                                                                                                                      
TXLoop Ended at cycle : 1 [3 ms]                                                                                                    
TX Ended on service: 0 channel: 0                                                                                                   
Reg. GETEVENTBYTES: 0x0, 0x0, 0x0, 0x40,                                                                                            
Done YARM_SetIdleMode [0x0 0x0]                                                                                                     

Ing. Roberto Asquini
Hardware designer, manufactoring engineer, firmware developer and company co-founder
asquini@acmesystems.it
Github repository: https://github.com/asquini

OpenHAB executeCommandLine

How to execute operating system commands, shell scripts, programs and more trough OpenHAB rules

It's a so called action launched inside a rule. The action parameter is the command itself.

Action "executeCommandLine"

Some of the installed examples are designed using this feature of OpenHAB.

Example 1: an external mp3-player (more flexible than the internal java player) plays a sound (OpenHAB audio):

rule "AirHorn"
when
    Item AirHorn changed
then
    val results = executeCommandLine("sudo@@/usr/bin/omxplayer@@-o@@local@@/etc/openhab2/sounds/AirHorn.mp3",5000)
    logInfo("Exec",results)
end

Example 2: There is no binding on OpenHAB to drive a DALI bus but it's easy to write a Python program for bit-banging two GPIOs in order to interface this kind of protocol (Dali - Implementing the protocol in bit-banging mode). Inside a rule we can use a standard OpenHAB slider to set an RGB value and drive the lamps accordingly:

var HSBType hsb
var red = 0
var green = 0
var blue = 0
var Cmd="/usr/bin/python@@/etc/openhab2/scripts/dali.py"

rule "HSBtoRGB"
    when
        Item DaliColor changed
    then
        hsb = DaliColor.state as HSBType
        red   = (hsb.red * 2.55).intValue
        green = (hsb.green * 2.55).intValue
        blue  = (hsb.blue * 2.55).intValue
        
        val results = executeCommandLine(Cmd+"@@"+red+"@@"+green+"@@"+blue,5000)
        logInfo("Exec",results)
end

Example 3: Launch a Python script to drive an remote control IR repeater (Controlling appliances through IR communication using Broadlink RM mini 3)

rule "AMPLI_SRC"
    when 
        Item Ampli_Src changed
    then
        switch Ampli_Src.state
        {
            case  1:
            {
                val results = executeCommandLine("/usr/bin/python@@/home/openhabian/addons/BlackBeanControl/BlackBeanControl.py@@-c@@Ampli_VOL",1000)
                logInfo("Exec VOL",results)
            }   
            case  2:
            {
                val results = executeCommandLine("/usr/bin/python@@/home/openhabian/addons/BlackBeanControl/BlackBeanControl.py@@-c@@Ampli_TUN",1000)
                logInfo("Exec TUN",results)
            }       
            case  3:
            {
                val results = executeCommandLine("/usr/bin/python@@/home/openhabian/addons/BlackBeanControl/BlackBeanControl.py@@-c@@Ampli_SAT",1000)
                logInfo("Exec SAT",results)
            }   
            case  4:
            {
                val results = executeCommandLine("/usr/bin/python@@/home/openhabian/addons/BlackBeanControl/BlackBeanControl.py@@-c@@Ampli_BOX",1000)
                logInfo("Exec BOX",results)
            }   
        }
end 

Example 4: Launch a CLI system command (Manage the internet router)

var String speedtestCliOutput = executeCommandLine("/usr/local/bin/speedtest-cli@@--simple@@--server@@395 ", 120*1000)

Some rules to keep in mind

  • Using the action as aforementioned (with a variable for the returning values) the system replies can be viewed as a standard OpenHAB log (http://cm3home.local:9001/) for a simpler debug.
  • The timeout is mandatory in order to give enough time to the operating system to get the command.
  • Take care to the blank spaces between commands and their parameters, they MUST be substituted with @ symbol.
  • As usual, because there is no console and therefore no environment variables, the full path for the command and its parameters must be specified.
  • The command is executed with openhabian user privileges. This user must be added to all the groups enabled to execute the commands.
  • To execute the command with sudo, the openhabian user must be added to the sudoers. Using 'sudo visudo', the text below must be added to the sudoers file:
openhab ALL=NOPASSWD: ALL

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-HOME schematic

The CM3-Home schematic is made by 14 sheets. This so high division is required because it is a quite complex circuit and, furthermore, to ease the comprehension and reuse of each single module.

Starting from the block diagram below, let's proceed with a quick description of the schematic diagram

The Raspberry PI Compute Module 3 component is split in A, B, C blocks.

  • B block is related to the very specific, non re-mappable peripherals like USB, SD card, Cam, HDMI, etc. The B block and the devices directly attached to it are shown in the main sheet (CM3-Home file, no suffix).
  • C block is depicted in the CM3-Home_PWR sheet, together with other circuit's power supplies.
  • A block is in the CM3-Home_IO sheet, with the list of all the re-mappable GPIOs and a brief descriptions of the attachable peripherals.

The LAN9514 device is driven by the only USB port available on CM3 and creates 4 different USB ports plus a 10/100 Mbps ethernet port. The LAN9514 component is split in three blocks as well. A and B blocks, related to power supplies and to USB ports, are depicted in the CM3-Home_USB sheet. C block is on the CM3-Home_Ethernet sheet together with protections and the RJ45 socket.

Another, quite complex, device is the FT4232. It is driven by one of the USB ports available from the LAN9514 and creates 4 different serial ports. Those are shown in the CM3-Home_Serial sheet. Two of them are configured as RS485 ports, one to connect the YARM module and the fourth one as a generic TTL serial port exposed on the external socket. The debug serial port is directly available from the CM3 miniuart peripheral. The CM3 full serial peripheral is used to connect the TPUART device.

The TPUART is on the CM3-Home_KNX sheet related to KNX bus.

The CM3-Home_1-2-Wire sheet contains the 1-wire and 2-wire interfaces components (AKA TWI and I2C).

The DALI bus is on the CM3-Home_DALI sheet. The RX and TX lines are bit-banging driven on two GPIOs. Exhanging the two 0Ω resistors you can choose to use the CM3 or the YARM's CPU to write or read the DALI signals.

In the CM3-Home_REL sheet there are the relays and the driving circuits connected to two GPIO.

In the CM3-Home_ANALOG-IN sheet there is the schematic with protections for the analog inputs designed to connect antitamper balanced line but usable in other ways as well. The analog inputs are connected to the YARM peripherals because the Raspberry PI CM3 has no analog inputs.

The CM3-Home_YARM and CM3-Home_WiFi sheets are related to those interfaces.

The CM3-Home_Audio sheets contains the audio circuits, compatible with the Raspberry PI3 board. In short, to obtain a decent quality audio output, we are using the two PWM peripherals available for the left and right channels, a digital buffer to decrease the output impedance and a low pass filter.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

CM3-Home - hardware reference

Allocation of the CM3L GPIO lines on CM3-Home

GPIO 0  - I2C0 - SDA Mipi Camera
GPIO 1  - I2C0 - SCL Mipi Camera
GPIO 2  - IO1  - Mipi Camera
GPIO 3  - IO0  - Mipi Camera

GPIO 4  - NC
GPIO 5  - NC
GPIO 6  - NC 

GPIO 7  - SPI CE1
GPIO 8  - SPI CE0
GPIO 9  - SPI MISO 
GPIO 10 - SPI MOSI
GPIO 11 - SPI SCLK

GPIO 12 - NC
GPIO 13 - NC

GPIO 14 - TXD0 TP-uart
GPIO 15 - RXD0 TP-uart

GPIO 16 - 1-Wire port

GPIO 17 - NC
GPIO 18 - Display backlight (1=On)
GPIO 19 - NC
GPIO 20 - IR receiver port

GPIO 21 - Left relay
GPIO 22 - Right relay

GPIO 23 - Display RST
GPIO 24 - Display D/C
GPIO 25 - Display IRQ
GPIO 26 - Available GPIO on J3
GPIO 27 - Available GPIO on J3

GPIO 28 - Left Input dry contact (1)
GPIO 29 - Right Input dry contact (2)

GPIO 30 - Light bus Rx
GPIO 31 - Light bus Tx

GPIO 32 - TXD1 Debug port
GPIO 33 - RXD1 Debug port

GPIO 34 - RGB led - Blue  - (0=On)
GPIO 35 - RGB led - Green - (0=On)
GPIO 36 - RGB led - Red   - (0=On)

GPIO 37 - WiFi power-on (1=ON)

GPIO 38 - Yarm reset
GPIO 39 - Yarm 

GPIO 40 - PWM0 OUT - Audio left channel
GPIO 41 - PWM1 OUT - Audio right channel
GPIO 42 - NC
GPIO 43 - NC

GPIO 44 - I2C1 SDA Groove port #1
GPIO 45 - I2C1 SCL Groove port #1

J3 (SPI) Pinout

Pinout of J3 connector

 1 - 3V3 out
 2 - 3V3 out
 3 - SPI0 CE1          - GPIO 7
 4 - Display backlight - GPIO 18 - (1=On)
 5 - SPI0 CE0          - GPIO 8
 6 - Display reset     - GPIO 23
 7 - SPI0 MOSI         - GPIO 10
 8 - Display D/C       - GPIO 24
 9 - SPI0 MISO         - GPIO 9
10 - Display IRQ       - GPIO 25
11 - Available         - GPIO 26
12 - Available         - GPIO 27
13 - GND               
14 - SPI0 SCLK         - GPIO 11
15 - GND
16 - GND

Serial port allocation

/dev/ttyUSB0 - Left RS485 port
/dev/ttyUSB1 - Yarm serial link
/dev/ttyUSB2 - Right RS485 port
/dev/ttyUSB3 - Serial port interface
/dev/ttyAMA0 - TP-Bus
/dev/ttyS0   - Debug port

Power consumption

State WiFi Lan Peripherals Consumption
Normal state after boot Off On None 250mA @ 12 volt
Normal state after boot Off Off None 225mA @ 12 volt

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

CM3-HOME Mechanical Dimensions (c) Acme Systems srl

Using a SONOFF TH10 sensor

The example supplied controls the switch of a Sonoff device, moreover reads the temperature and humidity values returned by the sensors and shows them on the UIs .

Habpanel

Classic UI or mobile App

Basic UI

Once defined, the items are part of the OpenHAB environment and can be used as shown in a single panel or integrated in a more complex dashboard that collects the values from other sensors, with different technologies.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

SONOFF devices integration

Some examples about different Sonoff devices installation in OpenHAB

To interface a Sonoff device with applications other than the original app, requires flashing a new firmware on the board and an MQTT broker. The firmware, valid for all the Sonoff family, is available on Github. An installation tutorial is available on Youtube.

Install MQTT broker as in CM3-home - OpenHABian set-up

Setup the client for connection to CM3-Home MQTT broker using the web configuration page of Sonoff-Tasmota:


Configure MQTT binding as in MQTT

Link the MQTT topics to OpenHAB items:

items/sonoff.items

Switch Sonoff1 "Sonoff SW"  (sonoff) {mqtt=">[broker1:cmnd/TH10_sensor/POWER:command:*:default],<[localbroker:stat/TH10_sensor/POWER:state:default]"}
Number Sonoff1Temp "Temp. North [%.1f °C]"  (sonoff) {mqtt="<[broker1:tele/TH10_sensor/SENSOR:state:JSONPATH($.SI7021.Temperature)]"}
Number Sonoff1Hum "Humidity North [%.1f %%]"  (sonoff) {mqtt="<[broker1:tele/TH10_sensor/SENSOR:state:JSONPATH($.SI7021.Humidity)]"}

Using either out (>) and in (<) configuration, enables the reading of the Sonoff device switch status, in order to update the OpenHAB UIs even if the power is driven by the device physical button.

The Sonoff TH10/16 device is available also with temperature and humidity sensors. Subscribing also the tele/# topic those values can be used in OpenHAB.

To use the switch with Basic or Classic UI configure sitemap:

sitemaps/cm3home.sitemap

    Frame label="Sonoff"
    {
        Text label="Sonoff" icon=switch
        {
            Switch item=Sonoff1
            Text item=Sonoff1Temp valuecolor=[>25="red",>20="green",<=20="blue"]
            Text item=Sonoff1Hum valuecolor=[>60="blue",>40="green",<=40="orange"]
        }
    }

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

IKEA Trådfri

The example supplied drives the brightness of two IKEA Trådfri lamps.

Habpanel

Classic UI or mobile App

Basic UI

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

IKEA Trådfri

First of all install and configure the TRÅDFRI gateway as explained in this video.

Once the TRÅDFRI Binding has been installed, it's able to automatically discover the gateway(s) published on the same network, prompting with the IP address of the gateway. Adding the security code printed on the bottom of the gateway the service goes  ONLINE  and it's ready to use.

At this point the available devices are shown automatically:

Clicking on the check sign they are added as things:

The things can be linked to items:

items/tradfri.items

Dimmer IkeaLight1 { channel="tradfri:0220:gwb072bf27851d:65538:brightness" }
Dimmer IkeaLight2 { channel="tradfri:0100:gwb072bf27851d:65537:brightness" }

to be used in the UIs:

sitemaps/cm3home.sitemaps

Frame label="IKEA"
    {
        Text label="Tradfri" icon=colorwheel
        {
            Slider item=IkeaLight1 label="Light1 Brightness [%.1f %%]"
            Slider item=IkeaLight2 label="Light2 Brightness [%.1f %%]"
        }
    }

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

MQTT & OpenHAB

MQTT is a so simple and widespread messaging system between applications that libraries and examples can be found in every programming language and in many devices.

The openhabian-config includes an installation script for Mosquitto, the most common broker, that allows the CM3-Home to be independent from outside on exchanging data between bindings and applications.

In this distribution it is used in several examples:

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

MQTT

Once the MQTT binding has been installed, it has to be configured with the name to use in the clients:

services/mqtt.cfg

broker1.url=tcp://localhost:1883
broker1.clientId=openhab2

Define also the event bus binding if it's needed to publish/receive all states/commmands directly on the openHAB eventbus:

service/mqtt-eventbus

broker=broker1
statePublishTopic=openhab/out/${item}/state
commandPublishTopic=openhab/out/${item}/command

stateSubscribeTopic=openhab/in/${item}/state
commandSubscribeTopic=openhab/in/${item}/command

The correct working of the system can be verified subscribing:

openhab/in/# 
openhab/out/#

with mqtt-spy or with the Google chrome App MQTTlens

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Manage the internet router

It's a common experience to have no more internet connection even if the service provider router returns no alarms. Most of the times the usual switch-off/switch-on is enough to have back the internet service again. If this occurs when nobody is using internet or when no one is present, the internet connection remain down for a long time, loosing the update of the cloud services and excluding the possibility to connect the LAN from outside via VPN or OpenHAB cloud service.

Using the example supplied the internet connection can be supervised continuosly.

Classic UI example:

Using this UI the speedtest as well as the router reset can be forced manually at any moment.

This graph example shows the historycal status of the connection also evidencing some possible downgrade:

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

Relay interface

Two relays are available on the CM3-HOME-B and CM3-HOME-F board. This article explais how to use them.

  • Normally-Opened and Normally-Closed contacts available on screw terminals
  • Max rated: 24 VAC/DC @ 1A
  • Snubbers already on-board to increase reliability with inductive loads

GPIO used

  • RL1 (left relay) GPIO21
  • RL2 (right relay) GPIO22

Python example

This example turns-on the relays alternately with a period of 1 second.

import RPi.GPIO as GPIO
import time

RELAY_LEFT=21
RELAY_RIGHT=22

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(RELAY_LEFT,GPIO.OUT)
GPIO.setup(RELAY_RIGHT,GPIO.OUT)

for i in range(5):
        GPIO.output(RELAY_LEFT,GPIO.HIGH)
        GPIO.output(RELAY_RIGHT,GPIO.LOW)
        time.sleep(1)
        GPIO.output(RELAY_LEFT,GPIO.LOW)
        GPIO.output(RELAY_RIGHT,GPIO.HIGH)
        time.sleep(1)

GPIO.output(RELAY_LEFT,GPIO.LOW)
GPIO.output(RELAY_RIGHT,GPIO.LOW)

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

Manage the internet router

The OpenHAB community is, as usual, full of suggestions. This tutorial on speedtest-cli internet up/downlink measurement is the starting point for the example.

The internet connection is tested every 5 minutes. The results are displayed as actual measure for the standard UI and stored in InfluxDB as explained in " How to plot graphs on a Habpanel " to create a historical graph.

This is the configuration:

items/speedtest.items

Group gSpeedtest <"network-icon"> (Whg)

String      SpeedtestSummary        "Speedtest [%s]"             <"speedtest_network">       (gSpeedtest)
Number      SpeedtestResultPing     "Ping [%.3f ms]"             <"speedtest_next5">         (gSpeedtest)
Number      SpeedtestResultDown     "Downlink [%.2f Mbit/s]"     <"speedtest_download">      (gSpeedtest)
Number      SpeedtestResultUp       "Uplink [%.2f Mbit/s]"       <"speedtest_upload">        (gSpeedtest)
String      SpeedtestRunning        "Speedtest running ... [%s]" <"speedtest_new">           (gSpeedtest)
Switch      SpeedtestRerun          "Start manually"             <"speedtest_reload2">       (gSpeedtest)
DateTime    SpeedtestResultDate     "Last executed [%1$td.%1$tm.%1$tY, %1$tH:%1$tM]"   <"speedtest_problem4">      (gSpeedtest)
Number      SpeedtestCountOK        "Test OK [%d times]"         <"speedtest_network">       (gSpeedtest)
Number      SpeedtestCountKO        "Test KO [%d times]"         <"speedtest_network">       (gSpeedtest)
Number      RouterRestartCount      "Restarted [%d times]"       <"speedtest_network">       (gSpeedtest)
Switch      RouterRestart           "Restart Internet Router"    <"network">                 (gSpeedtest)

Some items is used to display values, other just as a temporary variable.

rules/speedtest.rules

val String filename = "speedtest.rules"
var Number speedtestVarOK
var Number speedtestVarKO
var Number routerRestartCountVar

rule "Speedtest init"
when
    System started
then
    createTimer(now.plusSeconds(195)) [|
        if (SpeedtestRerun.state == NULL) SpeedtestRerun.postUpdate(OFF)
        if (SpeedtestRunning.state == NULL) SpeedtestRunning.postUpdate("-")
        if (SpeedtestSummary.state == NULL || SpeedtestSummary.state == "")
            SpeedtestSummary.postUpdate("⁉ (Sconosciuto)")
    ]
    speedtestVarOK = 0
    speedtestVarKO = 0
    routerRestartCount = 0
end

rule "Speedtest"
when
    //Time cron "0 0 5,13 * * ?" or
    Time cron "0 0/5 * * * ?" or
    Item SpeedtestRerun received command ON
then
    logInfo(filename, "--> speedtest executed...")
    SpeedtestRunning.postUpdate("Misura in corso...")

    // update timestamp for last execution
    SpeedtestResultDate.postUpdate(new DateTimeType())

    // execute the script, you may have to change the path depending on your system
    var String speedtestCliOutput = executeCommandLine("/usr/local/bin/speedtest-cli@@--simple@@--server@@395 ", 120*1000)

    // for debugging:
    //var String speedtestCliOutput = "Ping: 43.32 ms\nDownload: 21.64 Mbit/s\nUpload: 4.27 Mbit/s"
    //logInfo(filename, "--> speedtest output:\n" + speedtestCliOutput + "\n\n")

    SpeedtestRunning.postUpdate("Analisi dei dati...")

    // starts off with a fairly simple error check, should be enough to catch all problems I can think of
    if (speedtestCliOutput.startsWith("Ping") && speedtestCliOutput.endsWith("Mbit/s")) 
    {
        var String[] results = speedtestCliOutput.split("\\r?\\n")
        var float ping = new java.lang.Float(results.get(0).split(" ").get(1))
        var float down = new java.lang.Float(results.get(1).split(" ").get(1))
        var float up   = new java.lang.Float(results.get(2).split(" ").get(1))
        SpeedtestResultPing.postUpdate(ping)
        SpeedtestResultDown.postUpdate(down)
        SpeedtestResultUp.postUpdate(up)
        SpeedtestSummary.postUpdate(String::format("ᐁ  %.1f Mbit/s  ᐃ %.1f Mbit/s (%.0f ms)", down, up, ping))
        SpeedtestRunning.postUpdate("-")
        speedtestVarOK = speedtestVarOK + 1
        speedtestVarKO = 0
        SpeedtestCountOK.postUpdate(speedtestVarOK)
        SpeedtestCountKO.postUpdate(speedtestVarKO)
        logInfo(filename, "--> speedtest finished.")
    } 
    else 
    {
        SpeedtestResultPing.postUpdate(0)
        SpeedtestResultDown.postUpdate(0)
        SpeedtestResultUp.postUpdate(0)
        SpeedtestSummary.postUpdate("(sconosciuto)")
        SpeedtestRunning.postUpdate("Errore durante l'esecuzione")
        speedtestVarKO = speedtestVarKO + 1
        SpeedtestCountKO.postUpdate(speedtestVarKO)
        logError(filename, "--> speedtest failed. Output:\n" + speedtestCliOutput + "\n\n")
        if (speedtestVarKO > 1)
        {
            sendCommand(Rele2, ON)
            speedtestVarKO = 0
            routerRestartCountVar = routerRestartCountVar + 1
            RouterRestartCount.postUpdate(routerRestartCountVar)
            set_timer = createTimer(now.plusSeconds(5))
            [
                sendCommand(Rele2, OFF)
                RouterRestart.postUpdate(ON)
                set_timer = null
            ] 
        }
    }
    SpeedtestRerun.postUpdate(OFF)
end

rule "Router Restart"
when 
    Item RouterRestart changed
then
    sendCommand(Rele2, ON)
    set_timer = createTimer(now.plusSeconds(5))
    [
        sendCommand(Rele2, OFF)
        RouterRestart.postUpdate(ON)
        set_timer = null
    ] 
end 

The failed tests are cumulated in a variable, when the faults number is higher than a given threshold the relay is energized for 5 seconds, the NC contact opens the circuit and cut off the power supply for the router along the same time.

The internet router power plug is tied to the normally closed contact of the relay so energizing the relay the router is switched off for a while resetting the connection.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Telegram - OpenHAB integration

Using the OpenHAB available binding it's possible to send Telegram messages triggered by events.

What is Telegram ?

Telegram is a competitor of many other chat systems, but it has a plus with the BOTs that enables many automation features.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

How to integrate Telegram in OpenHAB

Assuming that the installation of the Telegram app and the registration to the service have already be done.

Create the BOT, get the token and the chatId

Create the new bot using the instructions of the BotFather bot. At the end, the TOKEN linked with this new bot will be displayed.

Search the bot given_name, E.g.: writing Openhab in the search field:

@OpenHab

and send a dummy text:

test

Write down in a browser the following URL with the TOKEN given by BotFather:

https://api.telegram.org/bot'TOKEN'>/getUpdates

In the JSON output:

{{"ok":true,"result":[{"update_id":136050211,
"message":{"message_id":120,"from":{"id":144558195,"is_bot":false,"first_name":"Guido","last_name":"Ottaviani","username":"guiott","language_code":"root"},"chat":{"id":144558195,"first_name":"Guido","last_name":"Ottaviani","username":"guiott","type":"private"},"date":1522098871,"text":"test"}}]}

Annotate the chatId returned:

144558195

Configure OpenHAB

Use the TOKEN and the ChatId to configure the Telegram ACTION

Edit

services/telegram.cfg

# Read http://www.instructables.com/id/Telegram-Bots-for-beginners/
# to see how to set up bots and find your chat ids
#

# bots=bot1,bot2

# bot1.chatId=22334455
# bot1.token=xxxxxx

# bot2.chatId=654321
# bot2.token=yyyyyyyyyyy

bots=bot1

bot1.chatId=144558195
bot1.token=12345678:ABCDEFGHIJKLMNOPQRSTUVWXYZ

More bots can be configured as shown in the commented lines.

Examples

  • Forward an SMS message received to the Telegram bot

rules/sms.rules

rule "SMS to Telegram"
when
    Item SmsMsg changed
then
    var MSG = (SmsMsg.state.toString)
    var TEL = (SmsTel.state.toString)
    logInfo("SmsRec", "SMS Received")
    sendTelegram("bot1"," " + MSG + "\r\n" + TEL)
end
  • Send a Telegram message when a dash button key is pressed

rules/dash.rules

rule "My GBC Dash Button pressed"
when
    Channel "amazondashbutton:dashbutton:040949bf:press" triggered
then
    logInfo("amazondashbutton", "GBC Dash Button has been pressed")
    L_SalDX.sendCommand(OFF)
    sendTelegram("bot1","GBC dash button")
end

rule "My NERF Dash Button pressed"
when
    Channel "amazondashbutton:dashbutton:d8d813aa:press" triggered
then
    logInfo("amazondashbutton", "NERF Dash Button has been pressed")
    L_SalDX.sendCommand(ON)
    sendTelegram("bot1","NERF dash button")
end
  • Send a Telegram message when the electric power consumption exceed a given treshold

OpenHab Modbus

rules/modbus.rules

...
else if (Power > 2500 && Power <= 3000)
    {
        //val results = executeCommandLine(Cmd+"B",5000)
        //logInfo("Exec",results)
        sendTelegram("bot1","Power = %d W", Power)
        sendCommand(LedB, OFF)
        sendCommand(LedG, ON)
        sendCommand(LedR, ON)
        set_timer = createTimer(now.plusSeconds(0.1))
        [
           sendCommand(LedB, ON)
           set_timer = null
        ]         
    }
...

Links

OpenHab Telegram Action

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Weather binding

The example supplied with the SD card uses the Weather Underground free services to get weather forecasts and the related binding to link them with OpenHAB.

Note! This example uses a Weather Underground demo API key that can stop working at any moment. Please get and install your own API key to have a stable service.

Create a free account on Weather underground, get an API key and past it to the binding configuration page together with your coordinates.

That's all, when the binding status becomes  ONLINE  the things are published and they can be linked to OH2 items in items/weather.items. To change the language, displayed items and so on, edit this file and sitemaps/cm3home.sitemap as explained here.

A more complete information panel is designed in the example supplied using also the informations coming from Astro binding.

This binding too requires the editing of the configuration inserting your coordinates.

to customize the items names, edit the items/astro.items file.

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

OpenHAB - Weather binding configuration example

Read carefully the official Weather Binding documentation.

ATTENTION! This is an OpenHAB 1 binding, it works but requires some workarounds.

With OpenWeatherMap service the forecasts do not work anymore.

On OpenWeatherMap web site they declare that with the free plan there are also the 5 days forecasts but after the registration they are set to 0.

Reading on forum you can discover that the forecasts (day by day selectable) are only the 16 days one. Switching from beta to final version the 1 day forecast is no more included in free plan.

The OpenHAB binding still uses the old APIs that are no more included.

5gg api.openweathermap.org/data/2.5/forecast?id={city ID}

16gg api.openweathermap.org/data/2.5/forecast/daily?q={city name},{country code}&cnt={cnt}

It's no more possible to specify a single day but only the full 5-day period.

After some tests with OpenWeatherMap service I switched to Wundergound service. It's easy. After creating a new account on another service provider you can find/change the new name on all items configured or comment the old one and use the same name on the new configuration without changing anything else.

In services/weather.cfg

apikey.Wunderground=xxxxxxxxxxxxxxxxx

location.roma.name=roma
location.roma.latitude=41.858804
location.roma.longitude=12.5668773
location.roma.provider=Wunderground
location.roma.language=IT
location.roma.updateInterval=15
location.roma.units=SI

Using the HTML panel example on the Weather Binding documentation requires some tricks, learned by the OpenHAB community, because in OH2 the folder used to publish web pages changed from the one of OH1.

The weather-data example explained on the example must be moved on /etc/openhab2/html (the old html content folder) and a symbolic link must be created in /var/lib/openhab2/webapps (the new path):

cd /var/lib/openhab2/webapps/
ln -s /etc/openhab2/html/weather-data/ weather-data

Some icons contained in images must be copied:

sunny.png -> clear.png
mostly-cloudy-day.png -> mostly-cloudy.png
partly-cloudy-day.png -> partly-cloudy.png

in order to be compatible with all the weather services that also provide the icon names in forecast. Some services supplies a link to their own icons instead.

To modify the log level by hand you can edit the file:

/var/lib/openhab2/etc/org.ops4j.pax.logging.cfg

To show in a single string two values, for example wind speed and direction, a rule is needed:

in weather.items

Number  Wind_Speed  " [%.2f km/h]"    (Weather)   {weather="locationId=roma, type=wind, property=speed"}
String  Wind_Direction  " [%s]"       (Weather)   {weather="locationId=roma, type=wind, property=direction"}
String  Wind    "Vento [%s]"    

A new Wind item has been created with no references. It's used to concat the two strings in a single one:

rule "concat"
when
  Item Wind_Speed received update or
  Item Wind_Direction received update
then
  Wind.postUpdate(Wind_Speed.state.toString + " km/h  " + Wind_Direction.state.toString)
end

In sitemap

Text item=Wind

Recently a new, OH2.2 compatible WeatherUnderground Binding is available. It uses the new things system and is easier to config.

Instead of using the text file editing example shown in the documentation, it's much better to leave the paper UI creating the things and use those to declare the items

ATTENTION
ONLY when the service is ONLINE you can use the things, linking them to your items. The service is ONLINE when configured with the correct API WeatherUnderground key

After linking the channels to the item as explained on the binding documentation:

String   Station            "Stazione [%s]"                                 <home>          (Weather)   {channel="weatherunderground:weather:Roma:current#location"}
Number   Temperature        "Temperatura Esterna [%.1f °C]"                 <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:current#temperature"}
Number   Temp_Min           "Temperatura min [%.1f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:current#minTemperature"}
Number   Temp_Max           "Temperatura max [%.1f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:current#maxTemperature"}

Number   Temp_Feel          "Temperatura Percepita [%.1f °C]"               <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:current#feelingTemperature"}
Number   Temp_Dewpoint      "Punto di rugiada [%.1f °C]"                    <water>         (Weather)   {channel="weatherunderground:weather:Roma:current#dewPoint"}

Number   Humidity           "Umidità [%d %%]"                               <humidity>      (Weather)   {channel="weatherunderground:weather:Roma:current#relativeHumidity"}
Number   Pressure           "Pressione [%d mBar]"                           <pressure>      (Weather)   {channel="weatherunderground:weather:Roma:current#pressure"}
Number   Visibility         "Visibilità [%.2f km]"                          <zoom>          (Weather)   {channel="weatherunderground:weather:Roma:current#visibility"}
Number   UV_Index           "Indice UV"                                     <sun>           (Weather)   {channel="weatherunderground:weather:Roma:current#UVIndex"}
Number   SolarRadiation     "Irradiazione [%.1f W/m2]"                      <sun>           (Weather)   {channel="weatherunderground:weather:Roma:current#solarRadiation"}

String   Condition          "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:current#conditions"}
String   Condition_ID       "Condition id [%s]"                             <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:current#conditions"}
DateTime ObservationTime    "Obs [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"           <time>          (Weather)   {channel="weatherunderground:weather:Roma:current#observationTime"}
Number   Rain               "Pioggia [%.2f mm/h]"                           <rain>          (Weather)   {channel="weatherunderground:weather:Roma:current#precipitationHour"}
Number   Precip_Probability "Precip % [%d %%]"                              <rain>          (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#probaPrecipitation"}
Number   Precip_Total       "Precip totali [%d mm]"                         <rain>          (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#precipitationDay"}
Number   Wind_Speed         "Velocità del vento [%.2f km/h]"                <wind>          (Weather)   {channel="weatherunderground:weather:Roma:current#windSpeed"}
String   Wind_Direction     "Direzione del vento [%s]"                      <wind>          (Weather)   {channel="weatherunderground:weather:Roma:current#windDirection"}
String   Wind               "Vento [%s]"                                    <wind>
Image    Weather_Icon                                                                       (Weather)   {channel="weatherunderground:weather:Roma:current#icon"}

DateTime ObservationTime0   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#forecastTime"}
Number   Temp_Min0          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#minTemperature"}
Number   Temp_Max0          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#maxTemperature"}
String   Condition0         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#conditions"}
String   Condition_ID0      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastToday#conditions"}

DateTime ObservationTime1   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastTomorrow#forecastTime"}
Number   Temp_Min1          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastTomorrow#minTemperature"}
Number   Temp_Max1          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastTomorrow#maxTemperature"}
String   Condition1         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastTomorrow#conditions"}
String   Condition_ID1      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastTomorrow#conditions"}

DateTime ObservationTime2   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastDay2#forecastTime"}
Number   Temp_Min2          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay2#minTemperature"}
Number   Temp_Max2          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay2#maxTemperature"}
String   Condition2         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay2#conditions"}
String   Condition_ID2      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay2#conditions"}

DateTime ObservationTime3   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastDay3#forecastTime"}
Number   Temp_Min3          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay3#minTemperature"}
Number   Temp_Max3          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay3#maxTemperature"}
String   Condition3         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay3#conditions"}
String   Condition_ID3      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay3#conditions"}

DateTime ObservationTime4   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastDay4#forecastTime"}
Number   Temp_Min4          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay4#minTemperature"}
Number   Temp_Max4          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay4#maxTemperature"}
String   Condition4         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay4#conditions"}
String   Condition_ID4      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay4#conditions"}

DateTime ObservationTime5   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastDay5#forecastTime"}
Number   Temp_Min5          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay5#minTemperature"}
Number   Temp_Max5          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay5#maxTemperature"}
String   Condition5         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay5#conditions"}
String   Condition_ID5      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay5#conditions"}

DateTime ObservationTime6   "Previsioni [(%1$tA)]"                          <time>          (Weather)   {channel="weatherunderground:weather:Roma:forecastDay6#forecastTime"}
Number   Temp_Min6          "Temperatura min [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay6#minTemperature"}
Number   Temp_Max6          "Temperatura max [%.2f °C]"                     <temperature>   (Weather)   {channel="weatherunderground:weather:Roma:forecastDay6#maxTemperature"}
String   Condition6         "Condizioni [%s]"                               <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay6#conditions"}
String   Condition_ID6      "Condizioni id [%s]"                            <sun_clouds>    (Weather)   {channel="weatherunderground:weather:Roma:forecastDay6#conditions"}

You can use the items defining them in sitemap to be displayed on a Basic UI:

or Classic UI, as well on the mobile app:

The data can of course be integrated with local measurement, as explained in this article and displayed on an habpanel as in this article

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

OpenHAB Netatmo

How to use the Netatmo weather station with OpenHAB.

Examples:

Classic UI or Mobile App


Basic UI


on an habpanel as explained on OpenHAB - Weather binding configuration example


or in a graph view as explained on How to plot graphs on a Habpanel



Note the graph above on the CO2 part. It's in a bedroom and the line starts after a night of sleeping. The CO2 concentration was in the alert zone. Opening the door the concentration decreases slowly in a safer zone. Then the windows have been open ventilating the room and the air quality became very healthy so quickly.

Considerations about measurements

On the Netatmo installation manual it's well explained how to arrange the sensors in order to have reliable measures. For the outdoor device it's strongly recommended to put it inside a dedicated protecting cap like, for example, this one. They are cheap, protect your device from weather and improve a lot the quality of the measures.



Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

OpenHAB Netatmo

This article will describe how to connect a NETATMO personal weather station with OpenHAB.

Configuration

The OpenHAB Netatmo binding tutorial is good enough but, as usual, some precaution must be followed to allow an up-and-running configuration without wasting too much time.

First of all the main unit needs to be connected to the Netatmo cloud. After creating the personal account on Netatmo web site the app to configure the main device and the additional stations can be downloaded:


Connecting the main unit to the computer through the supplied USB cable and starting the wizard, the devices will be registered, named and configured. As explained on the binding tutorial it needs to create an app in order to open the available API for the device. This allows to get the Client ID and the Client secret needed to configure the Netatmo API bridge (automatically created after the binding installation). It's interesting to take a look at the API available and how many applications can be done with just a small coding. A lot of examples are proposed both in python and javascript.

Connect the Netatmo bridge.


When the Netatmo API bridge is  ONLINE  (and ONLY when it's  ONLINE ) the things related to the devices can be added. It could be possible that it needs a reboot to be connected.

Note! These configuration examples show fake IDs. The configurations supplied must be updated with the correct IDs after registration.



If the Netatmo API bridge is correctly installed and connected, the main and the outdoor devices parameters, configured on the Netatmo cloud, will be linked automatically to the things exposed by the binding, with the correct IDs and shown in the inbox ready to be confirmed.

On the contrary on what the binding tutorial teaches, it's better to use all the Paper UI automatic discovery features instead of writing down the things configuration files. This because the things parameters will be displayed only when all it's correctly configured, step by step, and they will be correct for sure.

In this case there are the things for API, outdoor and indoor units as parts of the standard weather station:

The name of each thing is shown in the device things list


E.g.:

netatmo:NAModule1:bd02ddba:0200002b4bde:Temperature

Configure:

items/netatmo.items

Number Netatmo_Indoor_Temperature         "Temperature in [%.1f °C]"                { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Temperature" }
Number Netatmo_Indoor_Humidity            "Humidity in [%d %%]"                        { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Humidity" }
Number Netatmo_Indoor_Humidex             "Humidex in [%.1f °C]"                { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Humidex" }
Number Netatmo_Indoor_HeatIndex           "Heat Index in [%.1f °C]"             { channel = "netatmo:NAMain:bd02ddba:70ee502af646:HeatIndex" }
Number Netatmo_Indoor_Dewpoint            "Dewpoint in [%.1f °C]"              { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Dewpoint" }
Number Netatmo_Indoor_DewpointDepression  "Dew point Depression in [%.1f °C]"  { channel = "netatmo:NAMain:bd02ddba:70ee502af646:DewpointDepression" }
Number Netatmo_Indoor_Co2                 "Co2 [%.0f ppm]"                          { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Co2" }
Number Netatmo_Indoor_Pressure            "Pressure [%.1f mbar]"                         { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Pressure" }
Number Netatmo_Indoor_AbsolutePressure    "Absolute Pressure [%.1f mbar]"                { channel = "netatmo:NAMain:bd02ddba:70ee502af646:AbsolutePressure" }
Number Netatmo_Indoor_Noise               "Noise [%.0f db]"                           { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Noise" }
Number Netatmo_Indoor_WifiStatus          "Wifi Status [%s]"                               { channel = "netatmo:NAMain:bd02ddba:70ee502af646:WifiStatus" }
DateTime Netatmo_Indoor_TimeStamp         "Time Stamp [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"    { channel = "netatmo:NAMain:bd02ddba:70ee502af646:TimeStamp" }
Location Netatmo_Indoor_Location          "Location"                                  { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Location" }
DateTime Netatmo_Indoor_LastStatusStore   "LastStatusStore [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"    { channel = "netatmo:NAMain:bd02ddba:70ee502af646:LastStatusStore" }
Number Netatmo_Indoor_Unit                "Unit [MAP(netatmo_unit_en.map):%s]"          { channel = "netatmo:NAMain:bd02ddba:70ee502af646:Unit" }
Number Netatmo_Indoor_WindUnit            "WindUnit [MAP(netatmo_windunit.map):%s]"     { channel = "netatmo:NAMain:bd02ddba:70ee502af646:WindUnit" }
Number Netatmo_Indoor_PressureUnit        "PressureUnit [MAP(netatmo_pressureunit.map):%s]"    { channel = "netatmo:NAMain:bd02ddba:70ee502af646:PressureUnit" }

Number Netatmo_Outdoor_Temperature        "Temperature out [%.2f °C]"                  { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:Temperature" }
String Netatmo_Outdoor_TempTrend          "TempTrend [%s]"                                   { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:TempTrend" }
Number Netatmo_Outdoor_Humidity           "Humidity out [%d %%]"                        { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:Humidity" }
Number Netatmo_Outdoor_Humidex            "Humidex out [%.1f °C]"                { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:Humidex" }
Number Netatmo_Outdoor_HeatIndex          "Heat Index out [%.1f °C]"              { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:HeatIndex" }
Number Netatmo_Outdoor_Dewpoint           "Dewpoint out [%.1f °C]"              { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:Dewpoint" }
Number Netatmo_Outdoor_DewpointDepression "Dew point Depression out[%.1f °C]"    { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:DewpointDepression" }
Number Netatmo_Outdoor_RfStatus           "Rf Status [%.0f / 5]"                       { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:RfStatus" }
Switch Netatmo_Outdoor_LowBattery         "Low Battery [%s]"                            { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:LowBattery" }
Number Netatmo_Outdoor_BatteryVP          "V Battery [%.0f %%]"                      { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:BatteryVP" }
DateTime Netatmo_Outdoor_TimeStamp        "Time Stamp [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"    { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:TimeStamp" }
DateTime Netatmo_Outdoor_LastMessage      "LastMessage [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"    { channel = "netatmo:NAModule1:bd02ddba:0200002b4bde:LastMessage" }

sitemaps/cm3home.sitemaps

Frame label="Netatmo"
{
        Text label="Indoor" icon=presence
        {
            Text    item=Netatmo_Indoor_Temperature valuecolor=[>25="red",>20="green",<=20="blue"]
            Text    item=Netatmo_Indoor_Humidex  valuecolor=[<20.1="green",<29.1="blue",<28.1="yellow",<45.1="orange",<54.1="red",>54.1="maroon"]
            Text    item=Netatmo_Indoor_Humidity valuecolor=[>60="blue",>40="green",<=40="orange"]
            Text    item=Netatmo_Indoor_Dewpoint
            Text    item=Netatmo_Indoor_Co2  valuecolor=[<800="green",<1000="orange",<1400="red",>1399="maroon"]
            Text    item=Netatmo_Indoor_Pressure
            Text    item=Netatmo_Indoor_Noise
            Text    item=Netatmo_Indoor_WifiStatus
            Text    item=Netatmo_Indoor_TimeStamp
            Text    item=Netatmo_Indoor_Location
        }
        Text label="Outdoor" icon=terrace
        {
            Text    item=Netatmo_Outdoor_Temperature
            Text    item=Netatmo_Outdoor_TempTrend
            Text    item=Netatmo_Outdoor_Humidity
            Text    item=Netatmo_Outdoor_Humidex
            Text    item=Netatmo_Outdoor_Dewpoint
            Text    item=Netatmo_Outdoor_RfStatus
            Text    item=Netatmo_Outdoor_LowBattery
            Text    item=Netatmo_Outdoor_BatteryVP  valuecolor=[>60="green",>45="orange",>36="red",>0="maroon"]
            Text    item=Netatmo_Outdoor_TimeStamp
        }
}

The data can be displayed on an Habpanel too as in OpenHAB - Weather binding configuration example. In order to personalize the panel with very local parameters, the widget explained in Widgets management in OpenHab can be modified integrating the measures from different technologies, i.e.: Sonoff, 1-Wire, etc. The example supplied with the SD card can be enhanced with more items:

<table id="weather-table">
    <tr>
        <td><img id="weather-icon" src="../static/weather-data/images/{{IconSet}}/{{statesnames[itemValue('Condition_ID')]}}.png" align="left"></td>
        <td id="weather-temp">{{'%.1f' | sprintf:itemValue('Netatmo_Outdoor_Temperature')}}</td>
        <td id="weather-temp-sign">°C <BR> ext</td>
        <td id="weather-temp">{{'%.1f' | sprintf:itemValue('TempIntValue')}}</td>
        <td id="weather-temp-sign">°C <BR> int Nord L</td>
        <td id="weather-temp">{{'%.1f' | sprintf:itemValue('Sonoff1Temp')}}</td>
        <td id="weather-temp-sign">°C <BR> int Nord S</td>
        <td id="weather-temp">{{'%.1f' | sprintf:itemValue('Netatmo_Indoor_Temperature')}}</td>
        <td id="weather-temp-sign">°C <BR> int Sud</td>
    </tr>
   
    <tr>
        <td></td>
        <td id="weather-table-details1">Umidità:  </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Netatmo_Outdoor_Humidity')}} %</td>
        <td id="weather-table-details1"> </td>
        <td id="weather-table-details2"> </td>
        <td id="weather-table-details1">Umidità:  </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Sonoff1Hum')}} %</td>
        <td id="weather-table-details1">Umidità:  </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Netatmo_Indoor_Humidity')}} %</td>
    </tr>
    <tr>
        <td></td>
        <td id="weather-table-details1">Pressione: </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Netatmo_Indoor_Pressure')}} mBar</td>
        <td id="weather-table-details1"> </td>
        <td id="weather-table-details2"> </td>
        <td id="weather-table-details1"> </td>
        <td id="weather-table-details2"> </td>
        <td id="weather-table-details1">CO2: </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Netatmo_Indoor_Co2')}} ppm</td>
    </tr>
    <tr>
        <td></td>
        <td id="weather-table-details1">Percepita: </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Netatmo_Outdoor_Humidex')}} °C</td>  
        <td id="weather-table-details1"> </td>
        <td id="weather-table-details2"> </td>
        <td id="weather-table-details1"> </td>
        <td id="weather-table-details2"> </td>
        <td id="weather-table-details1">Percepita: </td>
        <td id="weather-table-details2">{{'%.0f' | sprintf:itemValue('Netatmo_Indoor_Humidex')}} °C</td>
    </tr>

     <tr>
        <td> </td>
    </tr>
</table>

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

SHow graphs in OpenHAB

Some graphs, showing how different items change in function of the time, are pre-configred in the SD card supplied.

Using the Grafana dashboard manager at cm3-home.local:3000 the way the graph is displayed can be modified changing time period, refresh, item to show, math functions to apply and many other more:

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-Home

LAN and WiFi adapter

The CM3-HOME-B board has an ethernet port that works exactly as the standard Raspberry Pi ethernet port. Optionally it is possible to mount a 2.4GHz WiFi module.

The WIFI-2 module used is an USB 2.0 module compliant with IEEE802.11 b/g/n. It is based on a RaLink RT5370N chip and fully supported by the Raspberry Pi Linux Kernel. It can be mounted directly on a PCB and can work in managed, ad-hoc and access point mode.

Two type of antenna are available:

  • PCB antenna (Code AN-WIFI-01)
  • Rubber antenna (Code AN-WIFI-02)

Buy the WiFi adapter More info about the WiFi adapter

Turn-on the WiFi adapter

The WiFi adapter is off by default. The GPIO 37 line controls the WiFi power line. Hi=On, Low=Off.

Turn-on the WiFi adapter:

echo 37 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio37/direction                                   
echo 1 > /sys/class/gpio/gpio37/value

Turn-off the WiFi adapter:

echo 0 > /sys/class/gpio/gpio37/value

Links

eShop

EUR 130.00


CM3-HOME-B - CM3-Home board basic (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • TP-BUS, LIGHT-BUS, RS485 (one instead of two), Yarm 868 MHz radio module (available on CM3-HOME-F)
    • Wifi module (Product # WIFI-2) amd antenna (Product # AN-WIFI-01)
    • The Raspberry Compute Module 3 or 3L (Product # CM3L)
    • MicroSD (Product # MICROSD8G-E)
    • Case (Product # CM3-HOME-CASE)
| Product description || CM3-Home catalog |

EUR 290.00


CM3-HOME-F - CM3-Home board full (only mother board)

CM3-Home is a Raspberry Pi Compute Module 3 motherboard designed to provide a reliable Home Automation hardware equipped with a wide range of electrical interfaces

  • NOT INCLUDED:
    • Raspberry Compute Module 3 or 3L (Product # CM3L)
    • Yarm antenna (Product # YARM-ANT-01)
    • Case (Product # CM3-HOME-CASE)
    • MicroSD (Product # MICROSD8G-E)
  • Included:
    • WiFi module (Product # WIFI-2)
    • WiFi antenna (Product # AN-WIFI-01)

For more info please visit the product description page

| Product description || CM3-Home catalog |

EUR 7.00


WIFI-2 - WiFi USB module

OEM Small USB 2.0 IEEE 802.11 b/g/n Wi-Fi compliant module based on the RaLink RT5370N chip. It works at 3.3V and can be configured also in Access Point mode.

This model requires an external antenna model AN-WIFI-01 or AN-WIFI-02.

| Product description || Datasheet |

EUR 3.50


AN-WIFI-01 - WiFi pcb external antenna

WiFi PCB antenna with 11 cm cable and UMC 2mm connector to be plugged on WIFI-2 module.

| Antenna datasheet |

EUR 7.00


AN-WIFI-02 - WiFi external antenna with SMA cable
  • RF cable with panel mountable SMA connector and UMC 2mm connector to be plugged on a WIFI-2 module.
  • WiFi rubber antenna

| Antenna datasheet | Cable datasheet |

Sergio Tanzilli
System designer, software developer and company co-founder
tanzilli@acmesystems.it
Webpages: https://www.acmesystems.it and http://www.tanzolab.it
Github repository: https://github.com/tanzilli and https://github.com/acmesystems

How to plot graphs on a Habpanel

OpenHAB items can automatically be stored in the time series database InfluxDB. Grafana ships with very feature rich data source plugin for InfluxDB. Supporting a feature rich query editor, annotation and templating queries. For these reasons their installation scripts are included in the standard Openhabian distibution.

Both Grafana and InfluxDB can be easily installed using openhabian-config tool

  • 20 | Optional Components Choose from a set of optional software components
    • 24 | InfluxDB+Grafana A powerful persistence and graphing solution

InfluxDB

After adding DB and graphs components, the persistance service can be installed.

persistence-influxdb - 1.10.0

This is the link between OpenHAB items and InfluxDB.


Then create the table and set the InfluxDB permissions

openhabian@cm3-home:~$ influx
Connected to http://localhost:8086 version 1.5.0
InfluxDB shell version: 1.5.0
> CREATE DATABASE openhab_db
> CREATE USER admin WITH PASSWORD 'admin' WITH ALL PRIVILEGES
> CREATE USER openhab WITH PASSWORD 'openhab'
> CREATE USER grafana WITH PASSWORD 'grafana'
> GRANT ALL ON openhab_db TO openhab
> GRANT READ ON openhab_db TO grafana
> exit

Enable the authentication in the HTTP section

sudo nano /etc/influxdb/influxdb.conf

[http]
# Determines whether HTTP endpoint is enabled.
enabled = true

# The bind address used by the HTTP service.
bind-address = ":8086"

# Determines whether user authentication is enabled over HTTP/HTTPS.
auth-enabled = true

Restart InfluxDB service

sudo systemctl restart influxdb.service

GRAFANA

Grafana panel is accessible at address: cm3-home.local:3000 with default login admin:admin

Disable registration and enable anonymous users to access Grafana

sudo nano /etc/grafana/grafana.ini
[users]
# disable user signup / registration
allow_sign_up = false
...
[auth.anonymous]
# enable anonymous access
enabled = true

Link Grafana with InfuxDB

using the already defined accesses:

Link OpenHab with InfluxDB

Edit the services/influxdb.cfg file

Add the following lines:

# The database URL, e.g. http://127.0.0.1:8086 or https://127.0.0.1:8084 .
# Defaults to: http://127.0.0.1:8086
url=http://127.0.0.1:8086

# The name of the database user, e.g. openhab.
# Defaults to: openhab
user=openhab

# The password of the database user.
password=openhab

# The name of the database, e.g. openhab.
# Defaults to: openhab
db=openhab_db

# The retention policy to be used, needs to configured in InfluxDB
# Till v0.13: 'default', since v1.0: 'autogen'
retentionPolicy=autogen

Configure the item to be stored in InfluxDB and the update strategies

Edit the persistence/influxdb.persist file

Strategies 
{
    everyMinute : "0 * * * * ?"
    everyHour : "0 0 * * * ?"
    everyDay : "0 0 0 * * ?"

    default = everyChange
}

Items
{
    L1P, L1V, L1C, L1F : strategy = everyMinute, everyChange, restoreOnStartup
    Sonoff1Temp, Sonoff1Hum, Netatmo_Indoor_Co2, TempIntValue,  Netatmo_Indoor_Humidity, Netatmo_Indoor_Temperature, Netatmo_Outdoor_Temperature, Netatmo_Outdoor_Humidity, Netatmo_Indoor_Pressure : strategy = everyMinute, everyChange, restoreOnStartup
    SpeedtestResultPing, SpeedtestResultDown, SpeedtestResultUp : strategy = everyChange
}

Add the item to plot

Many different graphs can be created adding new dashboards and configuring stored items to plot

Using the sharing option it creates the link to be used in a frame widget to show the graph on the Habpanel as explained in Widgets management in OpenHab

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

OpenHAB - Suggestions on setup backup procedures

How to setup an automatic daily backup for the most important OpenHAB configurations. Here some addons to the backup tutorial.

Using the openhabian-config item:

50 | Backup/Restore       Manage backups and restore your system ?    

it is possible to install all the needed backup environment for the open-source software Amanda.

The github backup tutorial explains well enough (and it's strongly suggested to read it all before proceeding with the installation) but there are some details to take care in order to have a system working fine. There are many threads on the OpenHAB community related to installation issues (example). Most of them are related to how the backup volume is mounted, either a NAS or a USB local drive.

In this installation it's mounted an 8GB USB pen drive on one of the two USB sockets. First of all, it's better to format the volume with an EXT4 filesystem to be able to use all the Linux capability. With a FAT32 filesystem for example, it's not possible to create the symbolic links needed by Amanda to run. After the mount point is created, to have the volume mounted at startup it needs to add a line to /etc/fstab file. In this example:

dev/sda1 /media/usb ext4 defaults,noatime 0 1

Only after the backup volume is correctly configured the Amanda installation can proceed. As well as in this example can happens that the installation is not correctly executed. The script returns no errors, but exiting from openhabian-config it's possible to read the console messages. Has suggested from the script author on the aforementioned thread, it needs to manually create the symbolic links shown on the error messages to have the system working:

openhabian@cm3-home:/media/usb/backup/slots$ sudo ln -s /media/usb/backup/slots/drive0 drive0
openhabian@cm3-home:/media/usb/backup/slots$ sudo ln -s /media/usb/backup/slots/drive0 drive1

The rest of the installation script works fine creating all the virtual tapes structure on the backup volume, the configuration files and the cron entry to start the full and incremental backups in rotation every day at one o'clock in the morning.

Then check the configuration:

openhabian@cm3-home:/media/usb/backup/slots$ su backup
backup@cm3-home:/media/usb/backup/slots$ amcheck openhab-dir

Amanda Tape Server Host Check
-----------------------------
slot 1: contains an empty volume
Will write label 'openHABian-openhab-dir-001' to new volume in slot 1.
NOTE: skipping tape-writable test
NOTE: host info dir /var/lib/amanda/openhab-dir/curinfo/cm3-home does not exist
NOTE: it will be created on the next run.
NOTE: index dir /var/lib/amanda/openhab-dir/index/cm3-home does not exist
NOTE: it will be created on the next run.
Server check took 1.145 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 3.145 seconds.  0 problems found.

(brought to you by Amanda 3.3.9)

It's advisable to add to the /etc/amanda/openhab-dir/disklist configuration file some more folders to backup, in addition to the default ones, according to your own needs, binding and external programs installed. In this installation:

cm3-home  /etc/openhab2             user-tar
cm3-home  /var/lib/openhab2         user-tar
cm3-home  /usr/share/openhab2       user-tar
cm3-home  /etc/default              user-tar
cm3-home  /home/openhabian          user-tar
cm3-home  /etc/amanda/openhab-dir   user-tar

To do that the user openhab must be added to backup group

sudo adduser backup openhab

ATTENTION

Remember to save this and any other configurations somewhere, re-installing Amanda the disklist file will be replaced with the default one.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Configurations

A brief description on the OpenHAB customization tools

CM3-Home Dashboard

Links on useful documentation, configuration pages and different GUIs are available at:

cm3-home.local:8080

How to edit customization files

The most recent and easy tool to manage OpenHAB configuration is Visual Studio Code. An explaination here about how to install and configure it to work with OpenHABian.

Install Visual Studio Code

Add OpenHAB extension

configure Visual Studio Code in this way

{
"openhab.host": "cm3home.local",
"openhab.port": 8080,
"openhab.lspEnabled": true,
"openhab.username": "openhabian",
"openhab.password": "openhabian",
"openhab.karafCommand": "ssh openhab@%openhabhost% -p 8101",
"files.autoSave": "off",
"openhab.username": "openhabian",
}

Mount the samba exported OpenHAB configuration folder. On MacOSX, for example:

⌘k
smb://cm3home.local
  • user: openhabian
  • password: openhabian

and add the folder to Visual Studio Code workspace.

Remind the shortcut keys available, first of all

⇧⌘P, F1 Show Command Palette

The workspace is now ready to edit all the configuration files

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

Widgets management in OpenHab

As an example will be described here the design of an habpanel for the Weather Binding.

On the contrary to the widget described in openhab_weather, in this example we don't use the standard frame type widget. The HTML will be coded directly inside the widget itself, created as a custom widget. Because this web page is published by the OpenHAB internal web server, it is visible also through the cloud services. Using a frame widget that publishes an external web page instead, this one can be viewed only inside the same network.

The stilesheets and the icons come from the same openhab_weather widget folder using the relative path.

≤link rel="stylesheet" type="text/css" href="www_raspberry/CM3-OH_widget/../static/weather-data/layouts/example.css" /≥
≤img src="../static/weather-data/images/{{IconSet}}/{{itemValue('Condition_ID1') | lowercase }}.png"/≥

Changing the IconSet='directory' with the desired icon set name, we can change the icon style for the whole widget.

It's possible to change the language of the captions by changing the weather.cfg file. Verify the language supported by the provider used.

location.roma.language=IT

location.roma.language=EN

The language chosen affects only the binding items with the data taken from the provider. OpenHAB supports only English and German language for the rest of the text. For other languages we have to use other conversion systems like, for example, this one:

Define the conversion array:

≤div ng-init="daysnames={'Sunday': 'Domenica', 'Monday': 'Lunedì', 'Tuesday': 'Martedì', 'Wednesday': 'Mercoledì', 'Thursday': 'Giovedì', 'Friday': 'Venerdì', 'Saturday': 'Sabato'}; 

Then use the English name as the array index:

{{daysnames[(itemValue('ObservationTime1') | date:'EEEE')]}}

In order to have an automatic update of the displayed text when the values change, the system uses AngularJS. The text management and formatting must be applied using this language specific syntax.

To select automatically the icon corresponding to the weather condition we can use the Condition item modifying the name with some AngularJS code:

≤img src="../static/weather-data/images/{{IconSet}}/{{itemValue('Condition0').replace(' ','-') | lowercase }}.png"/≥

This works only if the chosen language is English. It's better to use the CommonID item, it's unique and matches the icons names:

≤img src="../static/weather-data/images/{{IconSet}}/{{itemValue('Condition_ID0')}}.png"/≥

And use instead the Condition item for the captions, it matches the chosen language:

≤p≥{{itemValue('Condition0')}}≤/p≥

To show other parameters we can use a mix of AngularJS and CSS:

≤td class="col-xs-4" style="color:red"≥{{'%.0f' | sprintf:itemValue('Temp_Max0')}} °C≤/td≥

Import this json file to install the described widget.

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott

CM3-home - OpenHABian set-up

Some advices on how to have an up and running installation of OpenHABian operating system on CM3-Home

OpenHABian Installation

For a comprehensive tutorial about OpneHABian installation please follow the instructions on the official web site

Basic installation download on RPI and compatible boards

Take a look also at Create a Raspbian Stretch microSD article.

ATTENTION all the installation procedures are really long lasting, please be patient.

Once installed OpenHABian following the instructions, you need to proceed with customizations and add-ons installation.

Many operations are eased using the OpenHABian environment equivalent to raspi-config.

sudo openhabian-config

The CM3-Home serial ports must be prepared to be used in OpenHAB, freeing them from standard use:

  • 30 | System Setting
    • 35 | Serial Port
      • [*] 1 (RPi) Disable serial console
      • [*] 2 (RPi3) Disable Bluetooth module
      • [*] 3 Add common serial ports to openHAB JVM

use menu items according to your needs

  • 30 | System Setting
    • to change password, host name, WiFi, etc.
  • 01 | Update
  • 02 | Upgrade System
  • 20 | Install optional add-ons
    • Mosquitto
    • Grafana
    • knxd

In order to verify the configuration you can use the karaf console. Let's take the knx binding as an example.

[12:44:08] openhabian@RasPIguiott:~$ ssh -p 8101 openhab@localhost
Password authentication
Password: 

                          __  _____    ____      
  ____  ____  ___  ____  / / / /   |  / __ )     
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  | 
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /      
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/     
    /_/                        2.1.0
                               - release build -   

Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown openHAB.

openhab> config:list "(service.pid=org.openhab.knx)"
----------------------------------------------------------------
Pid:            org.openhab.knx
BundleLocation: mvn:org.openhab.binding/org.openhab.binding.knx/1.10.0
Properties:
   localIp = localhost
   service.pid = org.openhab.knx
   type = ROUTER
openhab> 

In case of problems it can be useful to increase debug level to check for possible configuration errors:

openhab> log:set debug tuwien.auto.calimero

or enable the trace

log:set TRACE org.openhab.binding.knx
log:set TRACE tuwien.auto.calimero

It is advisable to disable them when the debug is over:

log:set DEFAULT org.openhab.binding.knx
log:set DEFAULT tuwien.auto.calimero

All the useful information can be read in:

/var/log/openhab2/event
/var/log/openhab2/openhab.log

Or with the console command log:tail

or in the browser: cm3home.local:9001/

The configuration is dynamically loaded as soon as the cfg file is saved (/etc/openhab2/services/knx.cfg in the example). It could happen that the previous configurations are cached even at service restart. In that case clean up the cache before restarting the service:

openhab> config:delete org.openhab.knx

openhabian@RasPIguiott:~$ sudo systemctl restart openhab2

There are some little differences between CM3-Home and Raspberry PI 3 because of the greater hardware equipment.

To use all of the available hardware you have to:

  • Assign the serial debug port (UART1) to GPIO32-GPIO33 instead of GPIO14-GPIO15
  • Assign the RGB LEDs GPIOs
  • Change the audio PWM GPIOs
  • Assign the 1-wire line
  • Assign the IR reciver port to GPIO 20
  • If needed, assign the J3 socket to SPI display
  • Set up the I2C port
  • Avoid to wait for HDMI device attached at boot (save more than 10sec at startup)

To do that, the following instructions must be added to the /boot/config.txt file:

dtoverlay=pi3-disable-bt

#Serial port to GPIO 32 and 33
force_turbo=1
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33

#CM3-Home led definition
dtoverlay=cm3-home-leds

#Enable PWM on GPIO 40 and 41 for the audio out
dtoverlay=pwm-2chan,pin=40,func=4,pin2=41,func2=4

# Enable the 1-wire bus
dtoverlay=w1-gpio,gpiopin=16

#Enable the IR Linux driver
dtoverlay=lirc-rpi,gpio_in_pin=20

dtparam=spi=on
dtoverlay=rpi-display,speed=32000000,rotate=270
#dtoverlay=ads7846,cs=0,penirq=34,speed=10000, swapxy=0, pmax=255, xohms=60, xmin=200, xmax=3900, ymin=200, ymax=3900

#I2C on Grove socket
#(https://github.com/raspberrypi/linux/blob/rpi-4.9.y/arch/arm/boot/dts/overlays/README#L783)
dtparam=i2c_arm=on
dtparam=i2c_arm_baudrate=400000
dtoverlay=i2c1-bcm2708,sda1_pin=44,scl1_pin=45,pin_func=6

#Avoid waiting for HDMI device attached at boot (save more than 10sec at startup)
hdmi_ignore_hotplug=1

To assign system functions to RGB LED you must create an overlay using the RGB led tutorial

To redirect the system console to the debug port you have to also edit the file /boot/cmdline.txt modifying ONLY the instruction related to the console, KEEPING INALTERED ALL THE REST.

Change:

console=serial0,115200 console=tty1

With:

enable_uart=1 console=serial1,115200

A dashboard with links to configuration panels and references is availbale at cm3-home.local:8080

Paper UI is the starting point for every installation and configuration.

Mobile App

To use all the CM3-Home OpenHAB features on mobile devices even when not in the same domestic network, it can be used the open cloud service offered by OpenHAB and the corresponding app available for both iOS and Android

After installing the openHAB Cloud Connector

the following files will be available:

/var/lib/openhab2/uuid
/var/lib/openhab2/openhabcloud/secret

The files content is needed to setup the cloud service. A complete tutorial about installation and configuration is available on Youtube.

The same functions available on local UI can be used also on mobile device once connected with the cloud service.

Links

Guido Ottaviani
Hardware designer, firmware developer, technical writer and robotics specialist
guido@guiott.com
Webpage: http://www.guiott.com
Github repository: https://github.com/guiott