Technical Details



First we need to clarify some of the terms we will be using.

A device is what you want to control : a TV, blu-ray player. It can also be more complex : a home cinema system, or even a complete domotics system.

An extender is used to extend your smartphone's capabilities. A smartphone can normally only use network traffic. An extender allows you to translate this network traffic into other types of signal, such as infrared, serial, … GlobalCaché is one such type, but there exist other types as well, such as iTrans. MyURemote can currently only communicate with a GlobalCaché extender.

A protocol defines how we need to communicate with a device to send commands. Examples of protocols are

  • ir : the device is controlled using infrared signals to a sensor. This is the case for most devices delivered with an infrared remote control.
  • serial : the device has a serial communication (RS232). E.g. a Bose Lifestyle system can be controlled through its serial port.
  • rest : the device has a local web server and can accept rest-like http requests. This is the case for Philips devices (TV, blu-ray, …)
  • own : Open Web Net, a protocol used by bTicino MyHome and in extension by other systems of the Legrand group.

Some devices support multiple protocols, e.g. the Philips line of devices support both ir and rest protocols.

It is important to know the protocol, because the commands you need to send will be totally different !

The Front End

The front end is a web page, containing buttons, input fields, and whatever kind of widgets you like. The web page is displayed inside a browser (on PC) or a web view component (on Android and iOS devices). You interact with the web page through clicks or by touching the screen. These events are handled by javascript functions.

In our view, these javascript functions still belong to the presentation layer. However, they make calls to the underlying MyURemote javascript library.

Web page components

Different devices have different needs, although these needs are sometimes comparable. For example, most of the devices will need a keypad, a navigation component, a play component (play, pause, stop, …), a power button, menu items, info buttons, color buttons, …

But often, there will be slight differences, e.g. the ok button in a navigation component may be missing, or 2 additional buttons can be used next to the “0” of a keypad, …

This lends itself well to a widget like approach. For each device: specify which widgets need to be shown. This approach is used (in a perhaps poor way), in the demo site.

In the demo site, almost all devices use the same standard.html pagelet. This pagelet contains multiple versions of the same component (e.g. a keypad with 10 buttons, a keypad with 12 buttons, …). Lets call these widgets or components. Each widget gets a unique name.

In the configuration, we can specify which widgets or component need to be displayed. All non-specified widgets are hidden.

The components to show are defined as an array of component names in the client_config javascript object. See Client Configuration.


Different devices may have different command names for the same or a comparable action. If you want to use the same layout (e.g. using widgets), the event handler should not rely too much on the name of the commands. Thereto I have defined aliases. The web page defines event handlers, and these event handlers use generic command names. By using aliases in the client configuration, these generic commands can be linked to specific commands for a device.

The aliases are defined as a parameter for a device in the client_config javascript object. See Client Configuration. As an example, the same power button (or the same widget) may be used for the following devices. Between parentheses the corresponding command name

  • Squeezebox : SLEEP
  • Philips TV : STANDBY
  • Panasonic Blu-ray : ONOFF

In the widget, the command fired when the event is triggered, is OO_1. In the client_config, this OO_1 is defined as alias for SLEEP, STANDBY, ONOFF respectively.

The MyURemote Javascript library

The MyURemote Javascript consists of a number of classes that know how to communicate with the MyURemote app on your smartphone or PC. The type of communication depends on the protocol that is supported by your devices (TV, blu-ray player, home cinema system).

Base classes

The Javascript library consists of

  • a myuremote.js file and corresponding class $.myuremote. This class keeps track of the current context, and provides a generic interface to execute actions on your devices.
  • a gc.js file, and the class gc. This class handles communication with a Global Caché extender.
  • a rest.js file, and the class rest. This class handles communication with devices that have a built-in web server, and can accept rest requests

rest requests are http requests where the command is in the request path, and the request parameters are put in the body of a POST http request. An example is the “key” command for a Philips TV. A Home key press command can be simulated by sending the json object { “key”:“Home” } to the url http://ip-address:1925/1/input/key

  • a file own.js, and the class own. This class handles communication with a domotics system supporting the Open Web Net protocol, such as a bTicino MyHome system.

Device definitions

The object devices (in file devices.js) contains the command definitions for all known devices. The devices object is a map of objects, in the format :

var devices = {
  		"deviceName" : {
  			// a list of technologies, either "ir", "serial", "rest"
  			// each technology is optional. In some cases, only one technology will be available
  			"ir" : {
  				// a list of command names and command strings for ir communication
  				// the commandString is the String that needs to be sent to the device
  			"serial" : {
  				// a list of command names and command strings for serial communication
  				// the commandString is the String that needs to be sent to the device
  			"rest" : {
  				"methods" : {
					"method_name" : {	
						"type" : "<http type>", // POST or GET
						"path" : "<the request path>",
						"parameters" : <array of parameter names> 
  				// a list of command names and command parameters for rest communication using the post method
  				"method" : { "method" : "<method_name>", "parameters" : <array of parameter values>},   				

Note that the structure for rest commands is slightly different than the structure for ir or serial commands.

Here are some examples (the complete file can be downloaded from ../js/devices.js

  • ir
var devices = {
	"Panasonic BDT-DMP110" : {
		"ir" : {
  • serial
var devices = {
	"BOSE Main" : {
		"serial" : {
  • rest
var devices = {
	"Philips 2k11" : {
		"rest" : {
			"methods" : {
				"input" : {	
					"type" : "POST",
					"path" : "/1/input/key",
					"parameters" : ["key"] 
			"STANDBY" : { "method" : "input", "parameters" : ["Standby"] },
			"BACK" : { "method" : "input", "parameters" : ["Back"] },
			"FIND" : { "method" : "input", "parameters" : ["Find"] },

Client Configuration

The devices contain the commands for a particular device. These commands are generic, independent of the configuration. In practice, a configuration must be defined. This configuration lists the devices for a particular client (or end-user), and the parameters for each device in this configuration, i.e.

  • the extenders in use
  • the ip-addresses and ports of the extenders
  • the devices, and how they are connected to the extenders
  • information about how the device should be displayed in the web page (here we are touching the presentation layer !)
    • aliases for commands (possibly to be displayed as text on buttons)
    • widgets to be used for these devices

The client configuration is available in the file client_config.js, and defines the following variables and objects :

  • The gateway url, i.e. the url of the local http server
var gatewayUrl = "http://localhost:9090/myuremote";
  • The extenders object, is a map of extender instances by name :
 * The extenders object is a map of extender names and the corresponding extender instances
 * Syntax : 
 * var extenders = {
 * 	"name" : extender
 * }
 * where extender is an instance of a specific extender type
 * extender = new extenderConstructor({parameters})
var extenders = {
	"gc1" : new gc({
				ip : "",
				port : 4998
	"rest1" : new rest({
				"ip" : "",
				"port" : 1925
	"own1" : new own({
				"ip" : "",
				"port" : "20000"

You can specify multiple extenders for the same type. This can also occur in practice : you could have 2 Global Caché components, or a Philips TV and a Philips Blu-Ray player, each accessible through the rest protocol.

  • the client_devices object.

This is an object containing the parameters of the devices as found in your real setup. For each device (meaninglessly named as device_i), we define

  • label : the name that has to be displayed in the web page
  • type : the device type, as found in the devices object
  • extender : the name of the extender as defined in the extenders object
  • extenderParams : specific parameters for this device when connected to the extender, e.g. the ir module to which the device's ir sender is connected in a Global Caché extender.
  • components : see web page components
  • aliases : see aliases

Below is an example.

/* * The definition of the devices in the user's configuration. * For each device, we specify * label : a name to display in the web page * type : the device type as defined in the devices object * extender : the name of the extender (in the extenders object) that is used to communicate with the device * extenderParams : specific parameters to pass to the extender when executing a command * components : visual components that should be displayed in the web page. Corresponds to the name of a widget in a widget based web page * aliases : map of aliases for the different commands. This means that the command can be triggered through its name or through its alias. This is used because different devices may have different names for the same action. */ var client_devices = {

device_1 : {
	label : "Tv",
	type : "Philips 2k11",
	extender : "rest1",
 	extenderParams : {
		callback: false
	components : [
	aliases : {
		"OO_1"		: "STANDBY",
		"N_HOME"	: "HOME",
device_2 : {
	label : "Blu-Ray",
	type : "Panasonic BDT-DMP110",
	extender : "gc1",
	extenderParams : {
		module : "ir2",
		callback: true
	components : [
	aliases : {
	    		"OO_1"		: "OPENCLOSE",
	    		"OO_2"		: "ONOFF",

The MyURemote App

The MyURemote App is used for two purposes :

  • It starts the web page that allows you to control your devices
  • It acts as a local http server that takes the http requests, opens a socket to the provided ip address and port, and sends the command over this socket.

The app is only necessary for devices or extenders that are accessed through sockets. For devices supporting the rest protocol, or another http-based protocol, the communication occurs directly between the web page (the javascript library) and the device.

The app allows to set the following parameters :

  • url : the url to load when the app is started. By default, this will be
  • port : the port at which the local http server is listening. By default, the port is 9090, but this can be adjusted if there is already another server running on this port. See the gatewayUrl variable in clientconfig.js
  • default extender ip : if no ip address is provided in the http request, this ip address is used as default
  • default extender port : if no port is provided in the http request, this port is used as default

If you change the server port, be sure that the port is updated in the javascript configuration as well.

A http request to the MyURemote local server is formed as follows :

http://localhost:<local server port>/myuremote?ip=<extender ip address>&port=<extender port>&command=<command>&callback=<callbackName>

The syntax is taken care of by the corresponding base class. Note the port : normally, the local http server is running on port 9090. If your local http server is running on a different port, the url must be adjusted.

The command parameter is mandatory, the other parameters are optional.

  • ip : the ip address of the extender. If not specified, the default extender ip is used
  • port : the port of the extender. If not specified, the default extender port is used
  • command : the full url-encoded command to be sent
  • callback : the name of the callback function. If available, the opened socket will be read for a response. If not available, the function will return immediately after sending the command.

Devices to control

The Global Caché Ethernet Gateway

The Global Caché Ethernet Gateway is a device that allows you to send commands over ip, and translate them into serial, infrared or relay signals.


Global Caché is manufacturer of several types of devices

Philips Devices

We support Philips Televisions through the Jointspace protocol, version 2k11. The list of supported devices is available at the Jointspace website. See Sample 4 to test your television.

Panasonic Devices

Supported Panasonic Devices

  • Panasonic Viera tv's
  • Panasonic Blu-Ray players (DMP-BDTxxx) - See Sample 7.
  • other types of devices not verified

Samsung SmartTv

  • supported, but no details known. See Sample 8 to test your device.

Bose LifeStyle

There are 2 protocols. One is for older systems (like Lifestyle 48,38,28,V30,V20). The other is for newer systems. Communication uses the serial port of a GlobalCaché GC-100 or iTach device.

bTicino MyHome

See bTicino Configuration for details.

Other devices

Other devices can be controlled through infrared, if used together with a GlobalCaché ethernet gateway (GC-100 or iTach with ir ports). Native protocols will be added in the future.