Integrate Siemens Logo (plclogo) in OpenHAB 2

Hi @falkena,

now the pulse thing is working for me, thanks!

But now I have another problem. I’m not able to send a Value from a number item to the logo. I tried some ways. I tried to bind the Number channel to a memory thing. I tried to bind the number channel to analog network thing. But the value does not arrive the logo VM.
Reading analog value from the logo works fine.
And it works with Switch items and writing only bits to the logo VM. Both ways: digital thing or memory thing.

In my case I have a Networt Analog Input NAI1 which maps to VW140.

Here the example with the analog thing:

Thing analog Analog_Thing_1 [kind="NAI"]


Number Test_Number {channel="plclogo:analog:Logo1:Analog_Thing_1:NAI1"}



Where is the mistake? Can you help me how to proceed?


hi @nickd

You cannot write directly in analog inputs or Network (analog) inputs.
You have to write the number value into V-memory and then in logo connect NAI1 to V-word.

See table here: you have to write the number value in Word VW100 or Double Word VD100


Kind regards.

Hi @Brecht

thanks for your fast reply!
I tried it this way, too but it doesn’t work.

Here my code:

Thing memory MEM_VW140 [ block="VW140"]

Number Test_Number {channel="plclogo:memory:Logo1:MEM_VW140:value"} 



With Bits (VB) and digital thing it works.

Another hint for me?


Ok, now it seems to work.
I checked all created things in PaperUI and I saw that the memory thing was not intialized. Then I changed the name of the memory Thing…after that I saw in the log that it was initialized.
After renaming it again to the old name I got an error message like this

2019-01-16 19:34:20.971 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while disposing handler of thing 'plclogo:memory:Logo1:Mem_GZ_Jal_desV': Provider for thing plclogo:memory:Logo1:Mem_GZ_Jal_desV cannot be determined because it is not known to the registry

After restart of openHab it is working…don’t ask me for the reason of this error…no idea… I’m happy that it’s working now…:slight_smile:


Hi @tv-arnd,
Yeah. I’ve troubles from time to time controlling my rollershutters. Hope, i’ll find some time next weeks.

Kind regards,


1 Like

Hello everybody, i think it’s time to post my rollershutter solution, i’m using nearly 10 Years :slight_smile: :slight_smile:
The motor self is controlled by follow UDF:

Hier is my UDF: RolladenMotor.pdf Rename pdf to zip!

Pulse on input I_UP drives the rollo high, pulse on I_DO drives the rollo down. The time rollo must be driven, are given by UDF parameters T_UP and T_DO respectively. As far output O_UP is high, the rollo drives high. After the time T_UP is past or O_UP is high and new pulse is send to I_UP, then O_UP goes low. Output IS_UP is set high, if pulse was send to I_UP and time T_UP is past. The same story is for I_DO, O_DO and IS_DO. Additionally UDF calculates the rollo position between 0 and 100 percent, as need by openHAB. Some safety is given too: It’s not possible to set O_UP and O_DO high same time. It’s software lock only. It’s much better to lock additionally in hardware: we are talking here about 220V (life-threatening)! The circuit is simple: One relay controls the direction and another switches 220V on or off. The rest of Logo side is quite simple (cool spider, isn’t it?) :

Let’s take a look on openHAB side. First we need some things:

  Thing pulse VB2_6  [ block="VB2.6", observe="NI23", pulse=500 ]
  Thing pulse VB2_7  [ block="VB2.7", observe="NI24", pulse=500 ]
  Thing memory VW116 [ block="VW116" ]

Then some items:

Switch  RolloHi       { channel="plclogo:pulse:LogoController:VB2_6:state" }
Switch  RolloDo       { channel="plclogo:pulse:LogoController:VB2_7:state" }
Contact RolloIsHi     { channel="plclogo:pulse:LogoController:VB2_6:observed" }
Contact RolloIsDo     { channel="plclogo:pulse:LogoController:VB2_7:observed" }
Switch  RolloHiActive { channel="plclogo:digital:LogoController:Q:Q19" }
Switch  RolloDoActive { channel="plclogo:digital:LogoController:Q:Q20" }
Number  RolloPosition { channel="plclogo:memory:LogoController:VW116:value" }
Rollershutter Rollo "Rollo" <rollershutter>

And at least some rules:

val Procedures$Procedure4<Command, SwitchItem, SwitchItem, Command>
LogoRolloLogic = [ Command ReceivedCommand, SwitchItem Up, SwitchItem Down, Command Direction |
  switch(ReceivedCommand) {
    case UP: {
    case DOWN: {
    case STOP: {
      if(Direction == UP) {
      } else if (Direction == DOWN) {
      } else if (Direction != STOP) {
        logDebug("LogoRolloLogic", "Direction " + Direction + " is not supported.")

rule "RolloPosChanged"
  Item RolloPosition changed
  var Number value = RolloPosition.state as Number
  Rollo.postUpdate(Math.max(Math.min(value.intValue, 100), 0))

rule "RolloDrive"
  Item Rollo received command
  var Command dir = STOP
  if(RolloHiActive.state == OnOffType.ON) { dir = UP }
  else if (RolloDoActive.state == OnOffType.ON) { dir = DOWN }
  LogoRolloLogic.apply(receivedCommand, RolloHi, RolloDo, dir)

The theory of operation is quite simple: send pulses to properly blocks:-)

Kind regards,


Wow, @falkena thanks for sharing this.
To be honest, this made me understand the concept of pulse thing even less…
I thought you have some kind of “endstops” in your roller shutters.
How does this work with observe and block somehow pointing to the same thing (e.g. VB2.6 and NI23 in your example)?

Hi @skazi,

each roller motor has physical end points. Some of them are able to send a signal, if endpoint is reached. My motors are cheap, they can’t send such signal :slight_smile: What i’m done is really simple: I measured the time motor drives high and i measured the time my wife said: “Rollo is down enough” :slight_smile: Then, i extend the rollershutter UDF with time parameters and simply set “endpoints” via UDF.

About pulse thing: Let’s take VB2_6. I’m writing memory address 2.6 and observe NI23, mapped to address 2.6. If NI23 is 0, it follows memory address VB2.6 is 0 too. Now I write 1 to VB2.6 via openHAB sitemap or PaperUI (not really good idea). It take some time NI23 get 1 due to network latency or another reason. Sometime NI23 got 1. Now i can start timer with given pulse time, that sends 0 back to reset input to initial state. This is “normal” closer button. The same with inverse “logic” applies, if NI23 is 1 initially. This will be “normal” opener button. Open question is now: What is the initial state of NI23? The answer was simple: Ask Logo :slight_smile: That’s all: Pulse-Thing read state of NI23 and send inverse value to VB2.6 memory block. To make the thing more flexible, we can observe any digital block or memory address. Some time later i understood, that lamps can be controlled the same way. The behavior of the pulse things can be modeled via openHAB rules. There will be a lot of them, if somebody have a lot of rollershutters and or lamps.

EDIT: Just for clarification: The memory address if NI23 is NOT VB2.6. NI23 just points to. Means, if i write VB2.6, then reading of NI23 must return the same value.

Kind regards,


Hi @falkena

I know that rollershutters have endstops integrated and that most don’t expose their status. I have motors with “obstacle detection” endstops so they can stop anywhere if they detect something is on their way. This makes precise, time-based position tracking harder and I didn’t do it in my rollershutter UDF for now.

My UDF is simpler than yours and I haven’t tested it with OpenHAB yet so I’m not sure how it will work but with physical buttons it’s working pretty reliably. I also use timeout to power off the motors when they should be done with their work but I used the same time for up and down to make things simpler.

As for the pulse thing, I think you wrote it already before some time ago but now I just got the point. The main use for this in your setup is this “network latency cancelation” (which is important for precise timing for position calculations). I don’t think this is as important for things like lamps.

You mentioned some time ago that we might create another “thing” type (“lamp” maybe) to implement the behavior for controlling lamps with physical “click” buttons and NIs in parallel. Looking at recent questions in this thread, having such a thing should make a lot of people happy and save a lot of unneeded rules. I think this would be a great addition to an already great addon :o)

If you don’t have time right now, I might be able to help with that somewhere in the future but for now I don’t even have a working OpenHAB at my new place and no LOGO at my old place so things might be a little tricky before I finish with the move.


@Falkena, Tank you very much for sharing this.
This was exactly what I was looking for.:slightly_smiling_face:

How do you connect the shutter position to VW116 in your logo?
I have read that in a UDF-block it’s only possible to have 4 outputs. In your UDF you have commands UP/DOWN en state Is_Up en Is_Down. How do you get your shutter positions outside your UDF-block without the need for a 5th UDF-output?


Hi @Brecht,

UDF has an “Pos” paramter as “analog signal” . It can be mapped to any memory address via Parameter VM mapping within LogoSoftComfort.

Kind regards,


Hi @skazi,

is it possible to get your UDF? May be i can optimize my :slight_smile:

Kind regards,


Hi @falkena,

Sure, but:

  1. I have the wiring done differently with one Q for power and another one for direction instead of Q for up and down.
  2. it’s not as nice as yours (structure and formatting).


Hi @skazi,

Cool :slight_smile: Hardware lock is more safe as software one i use (see my post above). I’ll rewire relais at least 2 years. This spring it’s time to do this.

I hope, i can get the logic. I hope to get an idea, if it’s possible to have less M-Blocks.

Kind regards,


Hi @falkena

Here’s my roller-shutter-controller UDF:

By number of blocks it could look more complicated but many of these are just basic functions blocks and the logic for different wiring is also a bit hard to compare.

And this is the UDF definition file: roller-shutter-controller.lma.xml (19.9 KB) (remove the xml extension!)


Hi @skazi,

thanks :slight_smile:

Kind regards,


Hello everybody,

i hope, i’ve fixed pulse-thing. Please, find updated version in my binary repository.
If it works, i’ll open PR to main repository.

Kind regards,


Sorry, I don’t get the Pulse thing.

The updated documentation states:

If observe is not set or set equal block , simply pulse with length pulse milliseconds is send to block . If observe is set and differ from block , binding will wait for value change on observe and send then a pulse with length pulse milliseconds to block. Please note, update rate for change detection depends on bridge refresh value. For both use cases: if block was 0 then 1 is send and vice versa.

So. If the observed block does not change, the pulse is never sent?

In your rollershutter example, NI23 or NI24 can never change, because V2.6 (or V2.7) never change value, because the Binding will never send a pulse?

Do you mean that the pulse is only sent, if the observed state differs from the state of the Switch item?

@falkena maybe adding some timing diagram for the pulse thing (like this: would finally solve the confusion?

Continuing the discussion from Integrate Siemens Logo (plclogo) in OpenHAB 2:

Hello everybody,
i just tried to figure out how this works. At the moment I can’t write Network inputs on my Logo 8.
I am gonna show you my settings.

Contact PLCGarten_24V   "24V Ok" { channel="plclogo:digital:PLCGarten:NetworkOutputs:NQ1:state" }
Contact PLCGarten_I2    { channel="plclogo:digital:PLCGarten:NetworkOutputs:NQ2:state" }
Switch  PLCGarten_R1    { channel="plclogo:digital:PLCGarten:NetworkInputs:NI1" }
Switch  PLCGarten_R2    "Licht 1"   <light>  { channel="plclogo:digital:PLCGarten:NetworkInputs:NI2" }
Switch  PLCGarten_R3    "Licht 2"   <light>  { channel="plclogo:digital:PLCGarten:NetworkInputs:NI3" }
Switch  PLCGarten_R4    "Licht 3"   <light>  { channel="plclogo:digital:PLCGarten:NetworkInputs:NI4" }


Bridge plclogo:device:PLCGarten [ address="", family="0BA8", localTSAP="0x3000", remoteTSAP="0x2000", refresh=100 ]
    Thing digital   Inputs  [ kind="I"]
    Thing digital   Outputs [ kind="Q" ]
    Thing digital   NetworkOutputs  [ kind="NQ" ]
    Thing digital   NetworkInputs   [ kind="NI" ]

With this configuration my PaperUI shows me this:

I think this fine and should just work.
This ist what i programmed on my Logo:

In the Network overwiew i made an serverconnection:

Can you tell me what I am missing? Thank you for your help!