evasmolders edited this page Jan 15, 2017 · 4 revisions


KAKU/COCO (hereafter KKCC) is a line of home automation which is similar to LightwaveRF. The main websites can be found at http://www.klikaanklikuit.nl/home/ for the Netherlands, and http://www.coco-technology.com/en/home for the rest of Europe.

As with LightwaveRF, KAKU/COCO devices are "one way", in that you can issue them commands, but you cannot read their status. However, as an added bonus, you can use a LWRF controller to control a KKCC device, or vice versa - they are the same and interoperable. You may have issues controlling LWRF heating devices from a KKCC device however, as there are no KKCC heating devices and the controller firmware may well discriminate.

People on a budget can buy a KKCC device and a compatible switch to turn it on, off or (if it's a light) dim it - but those of you wanting to automate things will need the "ICS1000" controller.

The controller is wired to your network, but does use wireless signals to control the KKCC devices. The controller needs 1 x CAT5 lead and socket on your router, and 1 x power connection.

KKCC devices range from simple "on/off" relays, to dimmable lights, door locks, energy monitors and more. For the whole range, see the websites linked above.

If you have the right KKCC equipment (see below) then you can link OpenRemote with KKCC via the UDP control interface - although as mentioned, the first range of devices are one way, and cannot be queried.


To integrate OpenRemote and LightWave, we have tested the products listed in the table below.

For a basic setup, you will need:

  1. OpenRemote Controller installed on your PC, RPi, NAS, etc.
  2. OpenRemote Designer Account
  3. A web browser, Android or iOS device for control
  4. A KAKU/COCO ICS1000 (see the websites linked above)
  5. A KAKU/COCO device to control (see the websites linked above)

Beyond that, you can add any "KAKU/COCO" certified device.

##Configuration of System


  • Follow the ICS1000 setup instructions to setup your account & ICS1000
  • The IP address of the ICS1000 - we advise you set this via DHCP and make it static.

Once you can control KKCC via the KKCC website, you should be able to control it via OpenRemote.


KKCC works on the principle of Rooms and Devices. This is primarily so you can group devices to make them easier to find on the application & website, control an entire room at once (power everything down) etc.


Using the KKCC website (or app, if you've installed it) you can create rooms (up to 8). Within the application or website you can define a name for each Room, although for OpenRemote the name is not used.

These rooms can later be referenced by the letter R and the room number, with the first room being 1, so R1 for Room 1, R2 for Room 2 etc.


Similar to Rooms, each Device within a Room is addressed with the letter D and the relevant number. D2 for Device 2 for example.

Again, you can name each device in the application or website, but OpenRemote does not use the name.

##Network Control

Once your KKCC WiFi Link is setup and synced with your KKCC account, it will have access to control each Room and Device you have defined. You can also access the WiFi Link and issue commands to it, via UDP - which is where OpenRemote comes in!


####Protocol & Port

The WiFi Link uses UDP port 9760 to listen for/receive commands. It also issues responses back, but does so to the issuing device (i.e. OpenRemote) on port 9761.


The WiFi Link expects commands in a defined format, which is shown below :

001,!R2D1F1|Ceiling Lights|On

So, let's break that down...

This is an instruction number. It should start at 001 and can increase. It can be used when sending multiple instructions to the WiFi Link - but with OpenRemote, typically only one command is sent at one time.

The comma (,)and exclamation mark (!) are required. The ! instructs KKCC to send the command.

As mentioned above in Rooms and Devices, this is where you put the Room and Device address of the KKCC node you want to control with this instruction. In this example it's Room 2, Device 1.

The F part which follows R2D1 is for Function. F1 means On F0 means Off

So, in this example, we're turning Room 2, Device 1, On.

The pipe (|) symbol is required.

Ceiling Lights
This is free message text. The V1 WiFi Link has a two line LCD display. This piece of text will be displayed on the first (top) line.

This second pipe (|) symbol is required.

This is free message text. This piece of text will be displayed on the second (bottom) line of the WiFi Link LCD.

So, when you finally issue this command, the ICS1000 will (or should!) display :

Ceiling Lights On

####OpenRemote Designer Configuration (putting it all together)

Create a device within OpenRemote, and then Create a command, as follows :

KAKU-COCO - table1

Save that, assign the command to a button and give it a go!

You'll need two versions of each command, one for On and one for Off, with the only difference being the F1 and F0 parts of the string, and the last piece of free message text.

###Device State Tracking

Previously, it was noted that V1 KKCC devices are "one way" - so whilst you can control them, you can't query what state they are (other than by using a Mk 1 Eyeball). However, in the author's experience:

  • KKCC always issues commands as specified
  • KKCC devices always receive them and act on them
  • Unless you use the native application or website, you won't be out of sync
  • Even if you do use the native application or website, you'll only have to press an OR button twice to get back in sync

OpenRemote lets you create switches to toggle things on and off, or you can use image buttons with different states. The author uses a lit and unlit lightbulb for some of his lights for example.

To do this is perfectly possible, but requires a little bit more effort.

Firstly, create both your On and Off commands for your device, as per the example above. For ease of reference in this example, let's say we created our commands and named them as follows

  • Ceiling_Light_On
  • Ceiling_Light_Off

####Virtual Commands

Secondly, you'll need to create three _In-memory Virtual Command_s (IMVC). Ultimately this is a way of creating and controlling a variable (i.e. something you can assign a state to) within OpenRemote.

To do this, create a new Command as follows :

KAKU-COCO - table2

You will then need to create a further two IMVCs. They should be almost the same as the IMVC you just created, except this time set the Names and Commands as follows :

KAKU-COCO - table3+4

Ensure you keep the Address the same in all three IMVCs. If you don't, it won't work. It's also recommended you relate the IMVC address to the device you're using for ease of reference - hence R2D1togglestate in this example.

These IMVCs are now able to control an OpenRemote variable called R2D1togglestate - although on their own, they don't do anything.

Then you need to create a Sensor - so within your OpenRemote device, create a new Sensor as follows :

KAKU-COCO - table5

This gives you a Sensor, which uses the command Ceiling_Light_Get_State you created previously. This basically tells OpenRemote to monitor the IMVC you linked to that command (i.e. R2D1togglestate).

Now finally, you can create an OpenRemote switch. Within your OpenRemote device, create a new Switch as follows:

KAKU-COCO- table6

So let's recap - by now you should have :

  • Five commands
  • Two to actually issue KKCC commands to turn the KKCC device on and off
  • Three IMVCs (which are controlling a variable for the KKCC device state)
  • One sensor (to monitor the variable)
  • One switch (to use on the OpenRemote interface)

####OpenRemote Rules (getting it working)

So far, nothing is actually triggering the IMVC variables, so we need to change that....

So now you'll you need to define a little bit of code within OpenRemote. This is by no means as scary as it sounds. Within the OpenRemote designer, select the Building Modeller screen, then select Config for Controller and then click on Rules.

In the rules.editor window, you need to add the following text :

rule "Turn_Ceiling_Lights_On"
    Switch( source == "Sensor_Ceiling_Light_State", value == "on" )

rule "Turn_Fireplace_Lights_Off"
    Switch( source == "Sensor_Ceiling_Lights_State", value == "off" )

The above code creates two rules. If you follow the fairly simple code, you can see that the rules are monitoring for Switch events, coming from the source, which in this case is Sensor_Ceiling_Light_State. When the value changes to on of off they call the actual KKCC command to turn the KKCC device on or off as necessary.

So - the Switch calls the IMVC commands (_Set_On and Set_Off), which updates the value stored within R2D1togglestate. The Sensor is activated by the variable changing, and this in turn triggers the event defined in the Rules, which in turn actually run the command to turn the device on, of off.

Whilst this seems very long winded, it's the only way for OpenRemote to track if a device has been turned on, or off.

You can now create a Switch on the OpenRemote UI Designer panel and assign it your defined Switch command (Ceiling_Light_Switch) and assign graphics for the on and off states as appropriate.

As mentioned, if you also (or remotely) use the native KKCC applications to turn a device on or off, then OpenRemote will be out of sync with the device state. But don't worry, if you use OpenRemote to issue an "on" command to a device that's already on, (or off to one that's off) - nothing happens - but OpenRemote will still issue the command and update it's UI - so the worst case is you have to press a button once to get back into sync :)

##See also

Also see forum pages: https://groups.google.com/forum/#!forum/openremotecommunity

External Links:

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.