Wago PLC with modbus

sorry for that, but new users can only add one photo per post:

ModbusDATA Thing:

ModbusPoller Thing:

In My wago PLC I detect change of Modbus_OUT varrible which is writable (at 32768 coil) and use internal PLC logic to create puleses that triger digital outputs (lights). Poller reads first coil at 0 modbus address (Modbus_IN variable).

Quite possible, I will check it later. For now I saw that on papaer UI I can only change from default to follow, which is “destroing” the behavior of the switching logic. How can I use: rawbutton-toggle-switch in Paper UI?

Change your Item option “enforce autoupdate”, that is the last thing you want.
As per binding docs, you most likely want to inhibit autoupdate, veto it.

Then show us another events.log and try to explain what happens, and what you would like to happen instead.

Veto auto updates changed only that I do not need quickly double click to change state of the lighit after switching on the wall. So logs looks the same:

here I switched off by openhab:

2020-10-09 11:24:23.299 [ome.event.ItemCommandEvent] - Item ‘Stan_swiatla’ received command OFF
2020-10-09 11:24:23.401 [vent.ItemStateChangedEvent] - Stan_swiatla changed from ON to OFF

Switched on by OH:

2020-10-09 11:24:23.724 [ome.event.ItemCommandEvent] - Item ‘Stan_swiatla’ received command ON
2020-10-09 11:24:23.847 [vent.ItemStateChangedEvent] - Stan_swiatla changed from OFF to ON

here I used wall swtich to off (lights went off)

2020-10-09 11:24:37.240 [vent.ItemStateChangedEvent] - Stan_swiatla changed from ON to OFF

here i tried to switch lights to on in OH, but lights stayed off.

2020-10-09 11:25:01.071 [ome.event.ItemCommandEvent] - Item ‘Stan_swiatla’ received command ON

Another switch in OH changed state of the light to ON (command was off, but soon after OH reads the change of the state in Wago).

2020-10-09 11:25:28.065 [ome.event.ItemCommandEvent] - Item ‘Stan_swiatla’ received command OFF
2020-10-09 11:25:28.165 [vent.ItemStateChangedEvent] - Stan_swiatla changed from OFF to ON

PLC reacts on rising edge of the signal, so I have a script generating pulses when modbus write coli changes state.

Impuls_swiatlo(IN:=xModbus_OUT, PT:=T#200MS);
Impuls_swiatlo_2(IN:=NOT xModbus_OUT, PT:=T#200MS);

Well, openHAB sends 0 for OFF or 1 for ON over Modbus. Your lights want a toggle i.e. a pulse for ON, a pulse for OFF?

You could use a writeTransform on your modbus to send 1 for any command.

Yes, But I already do it in PLC. When modbus receive 1 I generate short pulse, and when it comes 0, I generate another pulse. This works, otherwise it wouldn’t switch lights at all.

No, you don’t, I think. When your WAGO register changes from 0 to 1, you make a pulse. If the WAGO end is 1 and openHAB sends another 1 … nothing happens?

When wago register is 1 and openhab sends 1 nothing happens, but that would mean OH wants to turn the light on when it is already on.

Can you tell me how can I force OH to alwayes generate 1 for any command? That would solve a problem maybe.

Do you think the coil that openHAB sends to actually reflects the on/off state of the light? The actual state is read from a different register.

Yes, use writeTransform and a little javascript that just returns 1. This will not help you unless you change your WAGO script as well.

Yes I know, but if I have read and write in one Item I thought it is connected. Openhab reads the state of the output perfectly from read register which is reflecting state of PLC output. And thought, that when I switch light in the wall, OH will not try to switch it again, when it knows it changed the status.

I don’t know what that means.

If you command your openHAB Item ON, the linked modbus channel will send a 1.
That’s it. It doesn’t matter what state your Item is in, it doesn’t matter what state the target WAGO register is already in.

A UI widget might limit things - a slider for instance cannot be slid to ON to generate a command if already in ON position.

Hi, I think I found a problem in this topic:

There is a chapter: Set coil to true on any command

(inspired by [Modbus] Coil reset only after item update to ON (OFF excepted) #4745 )
Reads from index 0, writes to index 1. All writes (no matter what command) are converted to 1.
Number NumberItem “Number [%.1f]” {modbus="<[slave1:0],>[slave1:1:transformation=ON]"}

I just need to achive this behavior. How to add "transformation=ON". Can you tell me if I can do it in Paper UI or do I have to move everything to files? I will do it anyway, but now I just want to know if this works for me.

That old post is talking about a completely different binding version.

Did already address this

Just put ON or 1 in the writeTransform box of your channel in PaperUI.
I’ve never used it that way, but I think that will work actually having a transformation script.

1 Like

Thanks a lot, I got to the bottom of my problem, but I have another hurdle in fornt of me. Just to help others who are tring to use Wago PFC 200 (8202) PLC contorller with openhab and modbus I will tell that you cant use graphical modbus configurator tool in eCockpit. It works, but you can’t make make real read/wite variable. You can write by modbus to PLC, but you can’t overwrite that variable from PLC itself. To achive such behavior you should use wago modbus library and setup standalone modbus slave server. Rember to turn off modbus service in WBM or setup new one on different port.

That’s said, I am back with another problem. Until now I was using Papuer UI to test everything and it works quite well. But now I want to move everything to files and start using proper UI for my smart home.

I created sitemap and other files with Home Builder tool, it looks nice, but I have no communication between OH interface and PLC. When I slide the switch nothing happens. In logs I can see that modbus is correctly polling modbus coils representing state of the Light, when I change it by wall switch, but slider in Openhab doesn’t change position.

So I put my files here:


Switch FF_Office_Light_2 “Światło Główne” (FF_Office, gLight) [“Lighting”, “Switchable”] {channel=“modbus:tcp:wagoMB:coils:SwiatloGabinet:switch”, autoupdate=“false”}


Bridge modbus:tcp:wagoMB [ host=“”, port=502, id=1 ] {
Bridge poller coils [ start=0, length=2, refresh=1000, type=“coil” ] {
// Note the zero based indexing: first coil is index 0.
Thing data SwiatloGabinet [ readStart=“1”, readValueType=“bit”, writeStart=“0”, writeValueType=“bit”, writeType=“coil” ]


sitemap dom label=“Stokrotki” {
Frame label=“Parter” icon=“groundfloor” {
Group item=GF_LivingRoom
Group item=GF_Dining
Group item=GF_Boiler
Group item=GF_Garage
Group item=GF_Bathroom
Group item=GF_Entryway
Group item=GF_Corridor

Frame label="Pierwsze Piętro" icon="firstfloor" {
    Group item=FF_MasterBedroom
    Group item=FF_Office
    Group item=FF_KidsRoom
    Group item=FF_GuestRoom
    Group item=FF_Wardrobe
    Group item=FF_Bathroom
    Group item=FF_Kanciapa

Frame label="Poddasze" icon="attic" {
    Group item=AT_StorageRoom

Frame label="Posesja" icon="garden" {
    Group item=OU_Backyard

Frame {
    Text label="Światło" icon="light" {
        Default item=GF_LivingRoom_Light label="Pokój Dzienny"
        Default item=GF_Dining_Light label="Jadalnia"
        Default item=GF_Entryway_Light label="Wejście"
        Default item=GF_Corridor_Light label="Korytarz"
        Default item=FF_MasterBedroom_Light label="Główna Sypialnia"
        Default item=FF_Office_Light label="Biuro"
        Default item=FF_KidsRoom_Light label="Pokój Dziecięcy"
        Default item=FF_GuestRoom_Light label="Pokój gościnny"
        Default item=FF_Wardrobe_Light label="Garderoba"
        Default item=FF_Bathroom_Light label="Łazienka"
        Default item=FF_Kanciapa_Light label="Kanciapa"
        Default item=AT_StorageRoom_Light label="Przechowalnia"
        Default item=OU_Backyard_Light label="Ogród"


I tried to compare everything with Paper UI config and it seems almost match. The only difference is that when I list Things in Paper UI I dont se linked Items (when using fles config). I don’t now. So it looks like I don’t have linked items and don’t know how to linked them in files config.

and modbus logs:

2020-10-26 17:29:49.909 [DEBUG] [rt.modbus.internal.ModbusManagerImpl] - Executing scheduled (1000ms) poll task BasicPollTask@70c1b4[request=ModbusReadRequestBlueprint@a87cd8[slaveId=1,functionCode=READ_COILS,start=0,length=2,maxTries=3],endpoint=ModbusTCPSlaveEndpoint@c5f714[address=,port=502],resultCallback=org.openhab.binding.modbus.handler.ModbusPollerThingHandler$ReadCallbackDelegator@4beb4b,failureCallback=org.openhab.binding.modbus.handler.ModbusPollerThingHandler$ReadCallbackDelegator@4beb4b]. Current millis: 1603733389908
2020-10-26 17:29:49.910 [DEBUG] [wimpi.modbus.net.TCPMasterConnection] - connect()
2020-10-26 17:29:50.007 [DEBUG] [bus.handler.ModbusPollerThingHandler] - Thing modbus:poller:wagoMB:coils received response PollResult(result=AsyncModbusReadResult(request = ModbusReadRequestBlueprint@a87cd8[slaveId=1,functionCode=READ_COILS,start=0,length=2,maxTries=3], bits = BitArray(bits=00)))
2020-10-26 17:29:50.009 [DEBUG] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:wagoMB:coils:SwiatloGabinet channels updated: {}. readValueType=bit, readIndex=Optional[1] -> numeric value 0 and boolValue=false. Bits BitArray(bits=00) for request ModbusReadRequestBlueprint@a87cd8[slaveId=1,functionCode=READ_COILS,start=0,length=2,maxTries=3]
2020-10-26 17:29:50.056 [DEBUG] [rt.modbus.internal.ModbusManagerImpl] - Modbus operation ended, timing info: {total: 146 ms, connection: 48, transaction=93, callback=5} [operation ID 1d0667ce-bd81-48b7-83f5-871d826e216d]

The simplest way to get this stuff correct is to copy/paste the channel UID visible in PaperUI.
From your screenshot, that’s more like
modbus:data:wago … etc.

Thanks rossko57. You’re great. I hate these typos. Works like a dream.

The logic behind figuring out workable UIDs is all rather opaque. Using PaperUI as a “reader” is really the way to go.

In this case, when you think about it, your data channel has no need to know anything about tcp or serial - that’s the business of the Bridge Things higher up in the hierarchy.