Vielen Dank für Deine Anmeldung! Du bekommst nun eine Email mit einem Aktivierungslink.

username already taken
Du hast bereits einen Account? .


Passwort vergessen?
Du hast noch keinen Account? Registrieren um den UI-Designer und das Forum zu benutzen oder eigene Projekte anzulegen.



Angehängte UI-Designer Konfigurationen
Tinkerforge Demo (iPhone)
Tinkerforge Demo (Nexus 7)
Tinkerforge is a platform of stackable microcontroller building blocks. The hardware can be controlled by external programs written in various programming languages over a USB, Wi-Fi or Ethernet connection. This demo project shows how to use NetIO to interact with Tinkerforge hardware.


Tinkerforge uses a binary TCP/IP protocol for the communication between the external program and the hardware. API bindings are provided for various programming languages that handle the details of the TCP/IP protocol and offer an easy-to-use and high-level interface for the user.

NetIO supports sending binary commands and could speak the TCP/IP protocol directly, but this would be difficult to use. Instead the Shell bindings can be used, as they offer a text based interface and can receive text commands from the command line and over a TCP/IP connection.

Tinkerforge Side

As first step you should download the Shell bindings from the download section and test them. You'll also need the Brick Daemon if your Tinkerforge hardware is connected to USB.

Command Format

The Shell bindings can handle commands given on the command line or send over a TCP/IP connection. The command format is almost the same in both cases. For example, this command line:

$ tinkerforge call ambient-light-bricklet gxe get-illuminance
has to be send over a TCP/IP connection as:

call ambient-light-bricklet gxe get-illuminance\n
Basically, strip tinkerforge from the front and append \n as command terminator. NetIO has a commandTermination attribute with \n as default value, so NetIO will take care of appending the final \n to the commands for you.

The output sent over a TCP/IP connection is also terminated by \n:

If the output contains multiple values then those are printed one value per line on the command line:

$ tinkerforge call dual-relay-bricklet fAa get-state
If they are send over a TCP/IP connection then \t is used as separator:

Listen Command

The text protocol proxy is started by the listen command of the Shell bindings:

$ tinkerforge listen
By default this will connect to the Brick Daemon on localhost. If you're running brickd on a different computer or want to connect to a WIFI or Ethernet Extension then you can use the –host and –port option:

$ tinkerforge --host different-computer --port 5000 listen
By default the listen command binds to port 4217. You can use the other –port option of the listen command to change this:

$ tinkerforge --host different-computer --port 5000 listen --port 6000
This will connect to different-computer on port 5000 and listen for incoming connections on port 6000.

NetIO Side

The attached demo UI configs show how to read the values of a Temperature Bricklet and an Ambient Light Bricklet and how to switch a Dual Relay Bricklet. See the Tinkerforge API documentation for a complete command reference.

Both demos use advanced output formatting and require that you start the tinkerforge listen command with the –enable-execute option. More details about this in the section below.

Before you can use the demo UI configs you need to configure the connection according to your setup. At least you need to change the host attribute to the IP address or hostname of the computer on which you started the tinkerforge listen –enable-execute command.

The Shell bindings require a connection with format set to string and protocol set to socket. But those are the default values anyway.

As second step you need to figure out the UIDs of the Bricks and Bricklets you want to interact with. You can use the enumerate command of the Shell bindings for this, or you can use the Brick Viewer instead.

Reading Values

To read out the temperature value of a Temperature Bricklet with UID dHd you can just use a Label and set its reads attribute to:

call temperature-bricklet dHd get-temperature
This will show temperature=2168 as text in the Label. The parseResponse attribute can be used to just get the number part. Here's an example using a positive lookbehind assertion for this:

This regular expression matches all characters between temperature= and the next \n.

A simpler but less robust way to do this would be to just use \d+ to match a number at any position in the response.

The formatResponse attribute can be used to append a unit to the output:

{0} °C/100
This will show 2168 °C/100 as text in the Label now. This reads a bit clumsy due to the fact that the Temperature Bricklet reports its value in °C/100 units.

The Shell bindings have the ability to fed the output of a command to an arbitrary shell command line that can then take care of formatting the output as desired. The –execute option is used for this. See the output formatting section of the Shell bindings for more details. Because the –execute option can be used to execute arbitrary shell command lines it is disabled by default in listen mode. You have to enable it with the –enable-execute option:

tinkerforge listen --enable-execute
To display the temperature in °C instead of °C/100 the value needs to be divided by 100. This can be done with the bc command:

echo "scale=2; 2168/100" | bc
This command line prints 21.68 and requires a decent shell as typically available on Linux and Mac OS X, but not on Windows. So to do output formating like this requires to run tinkerforge listen on Linux or Mac OS X. Windows will work too, but you have to work around the limitations of its command prompt.

Setting the reads attribute of the Label to:

call temperature-bricklet dHd get-temperature --execute "echo scale=2\; {temperature}/100 | bc"
the parseResponse attribute to .* and formatResponse to {0} °C then results in the desired text of 21.68 °C in the Label.

Triggering Actions

Beside reading sensor values you can also trigger actions such as switching a Dual Relay Bricklet (its UID for this example is fAa).

A simple way to do this is using two Buttons. One to switch it on and the other one to switch it off. The sends attribute of the On Button is set to:

call dual-relay-bricklet fAa set-selected-state 1 true
and the sends attribute of the Off Button:

call dual-relay-bricklet fAa set-selected-state 1 false
This will control relay 1 on the Dual Relay Bricklet. To control relay 2 replace 1 with 2 in the commands.

Another way to do this is using a Switch element. That element has two sends attributes and also has a reads attribute to read back the current status of the relay and display it. There are several attributes that needs to be set to make the Switch element work (in <attribute>: <value> format):

onSend: call dual-relay-bricklet fAa set-selected-state 1 true
offSend: call dual-relay-bricklet fAa set-selected-state 1 false
reads: call dual-relay-bricklet fAa get-state
parseResponse: (?<=relay1=)[^\t]+
formatResponse: {0}
onValue: true
interval: 2000
The onSend and offSend attributes use the same commands as in the two Button example above. The reads attribute is used to read back the current state of the relay. The response looks like this:

The parseResponse and formatResponse attributes are used to get the state of relay 1 from the response, which is either true or false. Finally the Switch element compares the result to its onValue attribute to decide in which state it should display itself. This process is repeated in an interval of 2 seconds.

To make this work for relay 2 replace 1 with 2 in the onSend and offSend commands and change the parseResponse attribute to:

The demo UI configs contain two Switch elements that work this way.