Led and Switch Access in CC100

How can you address the LEDs of the CC100 via the Led Server programmatically in C++?

There is a Run/Stop/Reset switch on the CC100, how can you read this switch programmatically in C++?

Thank you for your help.

There are some command line tools to read the USR LED and RunStop Switch. I don’t know of an API to write to the LED outside of Codesys at this point.

Thanks @WagoKurt for the tip.
I will probably postpone the control of the LED and Key in my Node-Red node until later.

Turning on/off the LEDs can be done using the linux kernel class for leds.
The individual leds can be accessed from /sys/class/leds/
For example turning on the green run-led:

echo 255 > /sys/class/leds/run-green/brightness

Write 0 to turn off.

The OP-mode switch input can also be monitored by listening on the following event:


I was doing some poking around on this event but I’m not quite sure how the data is packed. It might be something like this:

struct input_event {
    struct timeval time;
    unsigned short type;
    unsigned short code;
    unsigned int value;

You can do the following to listen on the event in terminal:

cat /dev/input/event0 | hexdump -C 

I will add the RUN and USR LEDs to the node in the next version.
But sometimes there are problems with write permissions in Docker in Node-Red.
Hardware Events in Node-Red is a tricky thing, so I’ll wait until I have more information.
Thanks @VegardS for the hint.

I also found this HowTo which might be helping you decoding the OMS.

I added the Run and User1 leds to the nodes.
Thank you @VegardS and @WagoKurt for the tips.
I will add the switch query later because the wago_oms_API.c file is missing.
Hopefully I can get the Ladder Logic Nodes online this weekend.
I also added some notes about the CC100 to my Github page:

1 Like

You’ll find my notes concerning LEDs :
LEDs can be controlled by using /sys/class/leds folder.
When calling other LEDs than user LEDs, the ledserver should be disabled.

Depending on the device LEDs are named in a different manner :


U1 pca955x:u1-[color]
U7 pca955x:u7-[color]
SYS pca955x:sys-[color]
RUN pca955x:run-[color]
IO pca955x:io-[color]
MS pca955x:ms-[color]
NS pca955x:ns-[color]


SYS (front) sys-[color]
SYS (back) pca955x:sys-[color]-back
RUN pca955x:run-[color]
H11 pca955x:h11-[color]
H12 pca955x:h12-[color]
CAN pca955x:can-[color]
Brightness - pca955x:bright-minus
Brightness + pca955x:bright-plus


USER u1-[color]
SYS sys-[color]
RUN run-[color]
MMC led-mmc

Switch ON / OFF

echo 255 > [path/to/led]/brightness 
echo 0 > [path/to/led]/brightness

Ex :

echo 255 > /sys/class/leds/pca955x:u1-green/brightness 
echo 0 > /sys/class/leds/pca955x:u1-green/brightness

BLINK (Start & Stop)

echo timer > [path/to/led]/trigger
echo none > [path/to/led]/trigger

Ex :

echo timer > /sys/class/leds/pca955x:u1-green/trigger
echo none > /sys/class/leds/pca955x:u1-green/trigger

Does anyone know how to read the reset switch position?

The control of the user and run LEDs are already implemented in the CC100 node.
Thanks for info.


@WagoKurt @iiot2k
I did some research and decoding of the events generated in /dev/input/event0, and here is my notes:

Example events
cat /dev/input/event0 | hexdump -C
Note that hexdump is swapping the bytes

         |  8 bytes system time  |type |code |   value   |
Event 1: |27 0c 41 65 9a dd 0a 00|05 00|02 00|00 00 00 00|
Event 2: |27 0c 41 65 9a dd 0a 00|00 00|00 00|00 00 00 00|
Event 3: |27 0c 41 65 2c e4 0a 00|05 00|01 00|01 00 00 00|

This matches the following structure:

struct input_event {
    struct timeval time;
    unsigned short type;
    unsigned short code;
    unsigned int value;

Event Type, in this case will be of the following types:

Type 0: EV_SYN - Used as markers to separate events.
Type 1: EV_KEY - Used to describe state changes of keyboards, buttons, or other key-like devices.
Type 5: EV_SW  - Used to describe binary state input switches.


EV_KEY is used on push buttons, like “oms drag-down reset” or the RST button.
EV_SW is used on the run and stop states of the “oms”.

Code, will be any of the following values:

0x01: Run
0x02: Stop
0x03: Reset
0x04: RST Button

Value, will be any of the following values:

0x00: Off
0x01: On
0x02: Hold (Reset and RST Buttons), event is repeated as long as button is held.

Using this information, the example events can be decoded;
First event:
The code is 0x02, which is the stop state, and the value is 0x00 (off), ie. the swich is not in stop pos.

Second event:
The type (and code) is 0x00, which is just a event separator and can thus be disregarded in this case.

Third event:
The code is 0x01, which is the run state and the value is 0x01 (on), ie. the switch is in run pos.

Concluding: the switch was moved from stop to run.

Using this information, it should be fairly simple to create a python, c/c++ program or whatever to give state on all front buttons of the PLCs for use in custom applications.

Beware that there is an “oms daemon” running in the background, causing the RST button to set fixed ip if held long enough etc …

The oms-daemon (/usr/bin/omsd) is started/stopped by /etc/rc.d/S01_omsdaemon and /etc/init.d/omsdaemon.

1 Like

Thanks for your explanations. I will integrate the key query into my node-red node. Each array element will get boolean true/false for run and stop. Should I also query reset?

1 Like

This link is a related topic, how to R/W to the CC100 IO.


1 Like

Thanks @WagoKurt for the interesting document.
The functions described are already implemented in the node @redplc/node-red-wago-cc100-io.
I’m in the process of integrating the key function into the node as @VegardS described.
I have the following problem:
If you read from /dev/input/event0, the call is blocked until a key event occurs.
Of course that would also block Node-Red.
The solution will not be easy and complex.

Im not familiar with node red plugin development, but polling for such events must be done asynchronously in order to not block the node red event loop.

I add the key read in Node-Red Node: