Lights Control Hardware (PLC)

My approach to this has been to keep the hardware as stupid as possible, while allowing openHAB to “add the automation” on top.

My choices influenced by covering a commercial warehouse - large area, multiple “central” control boxes, avoid wireless tech - not the same as a home.

No PLCs. Simple pulse (step) relays at the central box, which allow standalone operation from multiple direct wired wall switches.
Cheap Modbus digital I/O units allow openHAB to monitor and control the relays.
Also take inputs from cheap wired PIRs.

It would have to be rather different if I needed dimmer functions though. Design choices there would be driven by what dimmer control tech was available at the right price. I suspect i would look at KNX.

1 Like

I use mostly MOSBUS devices like ADAM6050 for this. They have own logic, which I do not use, and can be controlled by OH

1 Like


I use a Schneider electric PLC to do exactly what you want.

I’m in my phone now, I can send more information later.

See this old thread:


1 Like

Not exactly what I’m looking for but still interesting.

@rossko57 can you please tell what pulse relays (vendor/model) you use? And how do you controll them?
In order to trigger state of pulse relay you need to close its control conacts for short period of time. But if pusle relay control contacs use 110V/220V then I guess you need another relay in order to triger it. :slight_smile: Is it correct?

Yes, that’s the safest way.

mains Pulse relay for DIN rail cabinet
although you could use a two-pole unit to allow signalling back to openHAB.

modbus unit, light duty relay contacts used as “pushbutton” for pulse relay

This is for a commercial site, not a home, 10A capacity is used - clonky is Good :smiley:

1 Like

Hi all

I am trying to use a set of Fatek PLC FBs with rj45 CBE modules to control my home.
I am not a ladder expert and right now i manage to perform single clicks to toggle relays for lights On/OFF and long press on pushbuttons to control blinds ( while press it operates).
I wonder if you can help me with some ladder examples on:

  • how to detect single and dual clicks from a pushbutton (to toggle lamp1 or lamp2 depending on if I perform a single click (lamp1) or a dual click (lamp2)
  • how to detect continuous click or dual click from a pushbutton to control blinds (continuous click will make blind up/down while pressing - i have separate buttons for up and down directions - dual click will trigger a timmer controlled output to completely raise or lower the blind without the need to maintain the button pressed.
    I also have a more difficult question: how to connect the plcs through ethernet cable (i imagine that it is possible to send input reactions from one plc to output actions on another plc…but don’t know how).
    Any help (ladder examples, briefs explanations , etc) would be welcomed.

Hi Rui!
Here You will find two examples of ladder, how to use Fatek with OH for lights. Second one is simplest version. It’s mono and bistable switch. Mono is physical switch, bi is for OH. I made appropriate comments in Fatek lader. Sorry now i’m lack of time, latter I will try to make more example what you ask for. It’s a little bit complicated because procedures in ladder are scattered and without comments when saved to plc.
Here is how to connect PLC to PLC
Can i ask why you want to send data between two PLCs instead of using extension modules?

Hi Rafal,

thank you very much for your assistance. I will look at the files you sent me.
Even if you have ladder examples without comments I can try to figure out the algorithm behind it.

The reason why I use several plcs is that I have different control locations inside the house. For example, I have an electrical cabinet for each floor (basement, main floor, and 1st floor), and a control cabinet attached to each electrical cabinet (so, in this case, I have 3 plcs - each one with an extension module or 2). In most cases, we could consider that the control could be independent for each floor but there are some situations where the pushbutton is on one floor and the light is in another, for example in stairs. That’s why I need to create some kind of bridge among all the plcs that are distributed along the house (in my case I have 7 different locations).

Hi Rui!
Sorry for delay, I was out. Here is a complete PLC Ladder with lights, shades, sprinkler and Modbus communications with LED dimmers.
In this ladder you can find how to 1,2 and long click
Shades are controlled by two relays. First turns on/off power, second one angle/direction.

Hi all,

i´ve a simmilar construction with adam 6052…
My boxes run in GCL-Mode and talk to eachother. I would like to use the internal Vlag like a virtual pushbutton but i´m just able to switch the internal Flag to “true” but it don´t switches of again.

Does anyone has an Idea?

Here is my config:

Box2 Rule1
Box2 Rule 2
Box2 Rule 3
Modbus adress AdamVlag

Wohnhaus01.things.txt (1.5 KB)

This doesn’t really have much to do with the rest of thread.

You do not say, but from your Things definition -

Bridge modbus:tcp:Wohnhaus01 [ host="", port=502, id=1 ] {
    Bridge poller thing [ start=304, length=1, refresh=500, type="holding" ]
        Thing data do01 [  readTransform="01.0", readStart="304", readValueType="int16", writeTransform="01.0", writeStart="304", writeValueType="int64_swap", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="false" ]

perhaps you are trying to read or write from individual bits in a register?? I can’t tell. Can you explain in simple terms what you are trying to read and write from openHAB?

This looks odd
because it will write 4 16-bit registers in one go.

The addressing 40301, 40303 in the little table you show us (from Adam docs?) suggest the Adam works in 32-bit mode.

This is unusual
what is it that you expect this to do? It will force every read poll to a value of 1

Hi rossko57,

thank you for your fast response!

Let me try to explain what i have done more precised…

My Adamboxes run in GLC mode and are networked to eachother. we have a little farm with 3 Buildings and the only connction i have had was network. I need to switch lights and other applications from all 3 buildings. I used the inputs of those boxes for my lightbuttons and send the inputs via network to the other boxes. Ihave tried to figure it a little bit more presize:

My Plan is now to make my farm a little bit smarter and i would like to begin with openHab.
I thought i could use these Vlags from the adamboxes as a “switch/button” in openHab…

You are absolutly right by saying its 32bit and thats what i´ve tried first but the result was the same…
…i can switch the Vlag on but it doesn´t switch off :frowning:

Here i did some screenshoots from a modBus-tool where i´m able to switch them on and off:

Swich Vlag1 to on:

Read status of that:

Swich Vlag1 to of:

Read status of that:

that means:

Vlag00 is 0000000000000001
Vlag01 is 0000000000000010
Vlag03 is 0000000000000100
Vlag04 is 0000000000001000
Vlag05 is 0000000000010000
Vlag06 is 0000000000100000
Vlag07 is 0000000001000000
Vlag08 is 0000000010000000
Vlag09 is 0000000100000000
Vlag10 is 0000001000000000
Vlag11 is 0000010000000000
Vlag12 is 0000100000000000
Vlag13 is 0001000000000000
Vlag14 is 0010000000000000
Vlag15 is 0100000000000000

Bear in mind I know nothing about GLC or VLAGs, but I don’t need to.
What do you want openHAB to do?
So far as I can see, you need to write individual bits in a holding register to control lighting devices.

More than one way to do that - but a crucial question is, do you need to read back the contents of that register?
If these bits represent push-on, push-off buttons, you might not care and will read the status of the lighting channels from somewhere else?
If these bits represent on-off switches, we have to more careful.


the GLC configs are fine and run in this configuration stable.
My wish is like you said that openHab can work as a button by using the internal Vlag…

I think it is not necessary to read back Status of the Vlag and my Plan was to look at the Output of the boxes if Light is on or of.

My plan has been to buid in a switch which has an auto restet like the push buttons which were discribt in several thread´s:

push button once -> high bit is sent -> reset after 50msec. -> Light is swiched on

push button twice-> high bit is sent -> reset after 50msec. -> Light is swiched off

and Light Status can be read by the digital output 1.

My .thing config writes the high bit by switching on but it doesn´t write the low bit when i swich off

Sounds good to me.
openHAB does need to know current light state or you won’t be able to exercise proper control, when other people may be switching on/off.

A side benefit is that is possible to get openHAB to detect lighting changes that it did not ask for i.e. it can know when somebody is manually switching - presence detection.

Alright, so here we only need to make write-only single bit channels. That’s really easy compared to read/write.
IMPORTANT - This is based on a big assumption about your Adam setup. Writing bit X will clear/zero every other bit in the register, even if it was only set 10mS ago. If you are automating lighting from openHAB you may well send commands to several zones in quick succession. Will Adam care if they trample on each other?
If that’s a problem, we will have to go the more complicated way.

Bridge modbus:tcp:Wohnhaus01 [ host="", port=502, id=1 ] {

    // no poller needed for write-only data Thing
    // many data Things write to same register
        // command anything to this to write "1" i.e. 00000000 00000001
    Thing data vlag01 [  writeStart="305", writeValueType="uint16", writeType="holding", writeTransform="1" ]
        // command anything to this to write "2" i.e. 00000000 00000010
    Thing data vlag02 [  writeStart="305", writeValueType="uint16", writeType="holding", writeTransform="2" ]
        // command anything to this to write "4" i.e. 00000000 00000100
    Thing data vlag03 [  writeStart="305", writeValueType="uint16", writeType="holding", writeTransform="4" ]
    Thing data vlag15 [  writeStart="305", writeValueType="uint16", writeType="holding", writeTransform="32768" ]

    // poller for any other stuff you want on this modbus slave
    Bridge poller thing [ ...

Do you need to reset these bits after a time,or is that automatic at the Adam? Is that 50mS programmed into the Adam,or done by openHAB? Would it matter if it were a couple of seconds instead?

Just for reference, why bitwise read/write is difficult -

From OH3.1 the binding will have a new profile making that easier.

Hi rossko57,

thank you so much for helping me!!!

Sounds good to me.
openHAB does need to know current light state or you won’t be able to exercise proper control, when other people may be switching on/off.

Yes, i configured the adam´s that Di0 & Vlag0 swiching the Do0.
Do0 is the feedback that light is swiched on.

IMPORTANT - This is based on a big assumption about your Adam setup. Writing bit X will clear/zero every other bit in the register, even if it was only set 10mS ago.

I think this won´t be a problem because all the Bit´s have to go back to 0 like a virtuel Button.
Okay if two Users swiching a Button at the same time the Light won´t turn on/off by one of them and the result is that the user use Button again and than it works

If you are automating lighting from openHAB you may well send commands to several zones in quick succession. Will Adam care if they trample on each other?
If that’s a problem, we will have to go the more complicated way.

The Vlags do the same like the Di´s in the Adam boxes… If i push more than 1 Button at the same time the box swiches al buttons i´ve pushed.
I think if i have to build a szenario including Vlag0, Vlag1 and Vlag 4 i have to build a Button which send´s a 1011 par example?! In theorie that would work?

Do you need to reset these bits after a time,or is that automatic at the Adam? Is that 50mS programmed into the Adam,or done by openHAB? Would it matter if it were a couple of seconds instead?

Unfortunately i´m not able to give a Vlag a setting with an auto switch of and it has to be done in openHab. In the GLC logic the adam box looking for the falling edge of the Vlag or the Di.
That means if i hold the Button no other falling edge can be detected at this time and the light can´t be swiched on or off till i release the button, the same handling by the Vlag.
That might be a problem ?!

Alright. We can construct an Item in openHAB to represent each lighting zone, that gets its state from the polled DoX, and when issued a command from UI or rule, goes through a little dance to simulate a pushbutton press then release to VlagY - but only if a change of state is needed. Do and Vlag need not be on same Adam box.
When doing this with pulse-relay controlled stuff, I’ve found the most reliable and flexible way to do this to have a second Item represent the pushbutton, and link them with a little rule.

From the viewpoint of openHAB user, it’s just another on/off light Item. (and the pushbutton Item is hidden from users)

That’s fine, we can manage “push button, wait, release” from openHAB.
OH has an ‘expire’ feature that would make this easy to implement - but it works in seconds.

Ah, so the actual switching action takes place upon button release, not button push?
Then we’ll have to use rules in openHAB to give a quick press-release, not a slow expire.
But -
That does mean we do not have to worry much about sending e.g 0010 and cutting short a 0001 that we just sent before. The simple way will work.

I would try to avoid programming this in at a low level.
If we can make all this so it reliably switches individual zones, even many in quick succession, this kind of group/scene is best done at the high level. That’s a lot easier to work with.

Before we go writing any config or rules … what version openHAB do you run?
The Modbus binding is right now getting new features that make writing to register bits easier. Info for @ssalonen who is creating this!

We can do it in OH 3.0 with rules as in that “bitwise” post that I linked to (and that would continue to work if you upgrade later), but if you can run a snapshot version OH with latest binding we could exploit new bit features that should formally arrive in OH3.1.


we have a Synology-Nas with an virtual machine windows 10 on it and i´ve installed openHab 3.0 on it.
Yes i think it won´t be a problem to use a snapshot… I had just began to explore openhab and don´t have many bindings.

I will be home in about two ours and than i could install it

Okay, it took a little more time but now i´ve switched to openHab 3.1, i installed the service for auto start and added the modBus binding

Alright, let’s have a go. One step at a time -get the reading working first.

If I understand right, you need to read the DO register 40303 for light circuit states, and we’ll eventually want to write Vlag at 40305, but we’ll need to read too for binding bitwise operations.
The 40xxx is an odd Modbus convention that tells us its holding register type.
Looking at your screenshots of your QMod utility, the Adam names register 40305 at protocol address 304 (hex 0130) so we need to be aware of the “-1 address” issue.

I advise naming Things and channels relating to the Modbus slave device e.g. DO01 and leaving Items to have the meaningful names like CowshedLights.

So, based on your original things and assuming you want to use a xxx.things file (as I would myself)

   // ADAM device 1
Bridge modbus:tcp:wohnhaus01 [ host="", port=502, id=1 ] {
         // poll regs DI,DO,GCL
    Bridge poller wh01 [ start=300, length=6, refresh=500, type="holding" ]
            // read DO as bits
        Thing data do01 [  readStart="302.0", readValueType="uint16" ]
        Thing data do02 [  readStart="302.1", readValueType="uint16" ]
        ... etc
        Thing data do16 [  readStart="302.15", readValueType="uint16" ]

            // read Vlag as register, we will write bits using profiles
        Thing data vlags [  readStart="304", readValueType="uint16", writeStart="304", writeValueType="uint16", writeType="holding" ]
    } // end of poller
} // end of device

Will you be defining Items using files, or with the UI? UI probably advisable for OH3, but I will give example in old xxx.items file mode and you should be able to see how to create it in UI
Names of your choice.

   // Item representing a lighting zone
Switch Cowshed "Cowshed lights" {channel="modbus:data:wohnhaus01:wh01:do01:switch"}
   // each zone partnered with a simulated pushbutton
Switch Cowshed_pulse "Cowshed push" { channel="modbus:data:wohnhaus01:wh01:vlags:switch" [ profile="modbus:bit", bit-index="0" ], autoupdate="false", expire="1s,command=OFF" }
   // Item representing next lighting zone
Switch Yard "Yard lights" {channel="modbus:data:wohnhaus01:wh01:do02:switch"}
   // partner pushbutton
Switch Yard_pulse "Yard push" { channel="modbus:data:wohnhaus01:wh01:vlags:switch" [ profile="modbus:bit", bit-index="1" ], autoupdate="false", expire="1s,command=OFF" }
... etc

Note that all the pulse Items are linked to the same data Thing, but using the brand new bit profile feature to select write bit. I hope the binding version enabling this feature is in the OH snapshot!

The Item names are deliberately related in zone-pulse pairs, because we’ll make use of that in rules later.

I’ve suggested disabling autoupdate on the pulse Items, so that we manage the Item state separately from any commands in rules.
Autoupdate can stay by default on the light zone Items for a quickUI response.

The 1-second expire will “un-push” the simulated pushbutton when we begin to use it. I’m pretty confident this will work satisfactorily without the short mS pulse, but we can revise later if needed (without using expire)

Try all this, see if it configures error-free, and see if you can monitor the actual lights. (there shouldn’t be much to see in pulse yet).
We’ll add rules for control when confident that we can read.