Integrate Siemens Logo (plclogo) in OpenHAB 2

I am still trying to build the perfect light-switch. Thanks @mcullmann (post 180 above).
Let me summarize:
example_light_switch_logo
Comfort-Switch B003 switches Q7 permanently, if pulse us longer than 500ms. A short pulse switches-on Q7 only for 20s. B033 to assure that pulse from NI1 is longer than 500m (e.g. 600ms)

Sitemap

sitemap default label="Home" {
Frame label="Light Switch" icon="attic" {
        Default item=FF_Dining_Light label="Light (switch here)"
        Text  item=Logo7_Q7 label="Debug Q7"
        Default item=Logo7_NI1 label="Debug NI1 (do not touch)"
   }
}

Things

Bridge plclogo:device:Logo7 "Logo7 PLC" [ address="192.168.xxx.yyy", family="0BA7", localTSAP="0x0200", remoteTSAP="0x0200", refresh=1000 ]
{
  Thing digital Inputs "Logo7 Inputs"    [ kind="I" ]
  Thing digital Outputs "Logo7 Outputs"  [ kind="Q" ]
  Thing pulse     VB100_0  "Logo7 NI1"  [ block="VB100.0", observe="VB100.0", pulse=200  ]
}

Items

Switch  Logo7_Q7    "Licht Essen [%s]" <light>         { channel="plclogo:digital:Logo7:Outputs:Q7" }
Switch  Logo7_NI1   "NI1"    { channel="plclogo:pulse:Logo7:VB100_0:state" }
// virtual Switch
Switch          FF_Dining_Light            "Licht"               <light>            (FF_Dining, gLight)

Rules

rule "Switch Light through Logo"
when
    Item Logo7_Q7 changed or                         // 1. light changed external
    Item FF_Dining_Light received command            // 2. light changed internal
then
    if(receivedCommand==ON || receivedCommand==OFF) { // ensure there was a received command, so second item triggered rule
        if (Logo7_Q7.state != receivedCommand) {      // only if state changed
            Logo7_NI1.sendCommand(ON)                 // send an ON
            Logo7_NI1.sendCommand(OFF)                // send an OFF ?? Is that really necessary ??
        }
    }
    else {                                             // no trigger from proxy switch, so state changed externally
        if (Logo7_Q7.state != FF_Dining_Light.state) { // if state changed really
            FF_Dining_Light.postUpdate(Logo7_Q7.state) // update the state without triggering the rule
        }
	}
end

This seems a bit shaky when toggling Light switch, esp. when toggling fast (status hicks up). Also it does not read the initial state (if logo-light was already on, and then starting up openHAB).

Can we find a simpler solution for light-switching, e.g. without rules?

For switching my lights I use wall pushbuttons.
I can’t use the pulse thing because then I don’t have the status of the output in logo.
To have the status on openhab correct I did it this way and it works great.
29

My wall pushbuttons pulse the pulse relay, the openhab-switch sets/resets the output.

Logo.things:

Bridge plclogo:device:Logo1 [ address="192.168.0.90", family="0BA8", localTSAP="0x3000", remoteTSAP="0x2000", refresh=50 ]
{
  Thing digital  Inputs  [ kind="I" ]
  Thing digital  Outputs [ kind="Q" ]
  Thing memory   VB0 [ block="VB0.0", threshold=1, force=true ] //Geen pulse item gebruiken!!

}

Logo.items

//Items
Switch Logo1_Q1 "Q1" {channel="plclogo:digital:Logo1:Outputs:Q1"}
Contact Logo1_I1    { channel="plclogo:digital:Logo1:Inputs:I1" }//Niet nodig voor lichtsturing, enkel status Q nodig
Switch Logo1_VB0_0 "VB0.0" {channel="plclogo:memory:Logo1:VB0:state"}

Logo.rules:
Update state openhab switch according to output state.
Maybe a postupdate would be better than a send command, but it works.
It sends another set or reset to the logo, but it doesn’t do anything because the output is already set or reset.

//rules
rule "update VB0.0"
when Item Logo1_Q1 received update
then
  if (Logo1_Q1.state==ON) {
    Logo1_VB0_0.sendCommand(ON)
  } else {
    Logo1_VB0_0.sendCommand(OFF)
  }
end

Home.sitemap

//sitemap
sitemap Home label="Home" {
    Switch item=Logo1_VB0_0
}

There is still a rule necessary, but its a small one.:wink:

Kind regards,
Brecht.

@Brecht take a look at my example here: Integrate Siemens Logo (plclogo) in OpenHAB 2

// things
Thing  digital Outputs [ kind="Q" ]
Thing  pulse   VB0_1   [ block="VB0.1", pulse=100 ]
// items
Switch  Relay1    "Relay#1"   (LOGO1)  { channel="plclogo:digital:PLC01:Outputs:Q2" }
Switch  PLC01_NI1 "PLC01_NI1" (LOGO1)  { channel="plclogo:pulse:PLC01:VB0_1:state" }
// rules
rule "forward Relay1 command to logo NI1"
when
    Item Relay1 received command
then
    sendCommand(PLC01_NI1, ON) // short pulse
end

This seems to work fine with following circuit:

Zrzut%20ekranu%20z%202019-01-13%2018-38-44

I then add Q2 to the habpanel. Commands sent to this item are not handled directly but “forwarded” to the NI item by the rule.

@skazi

Thank you. Your solution is even better, less code & less blocks.
I’ll implement it your way.

Do you perhaps have a solution for roller shutters too?

Kind regards.
Brecht.

Hi @Brecht,

I’m glad that you like the light solution.
I have roller shutters implemented in LOGO but I haven’t connected them to openhab just yet.

BR,
Jacek

Thanks @Brecht, @skazi, @mcullmann,
I have created a new turorial/solution topic for this - still WiP

@rlkoshak please make that a wiki.

Next should be rolloshutters.

Thren I have a challenge for Logo clocks. How to write times? Reading times works already nicely with plclogo-binding.
Android HMILogo app does that with a perfect widget (3 tabs for 3 clocks, weekday-selector, on/off-time reader + setting)
HMILogo_clock_widget

Hi @skazi, I just started to work with Openhab, and I’m looking to control my PLC Logo 8 with OPENHAB
could You please help me how to proceed??
best regards
dave

Hi @Dave_gagliostro,

Assuming you have your LOGO connected and working from LOGOComfort, I think the best place to start with OpenHAB integration is this: https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.plclogo/README.md

Reading this thread from the beginning might also give you some nice troubleshooting hints.

BR,
Jacek

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-file:

Thing analog Analog_Thing_1 [kind="NAI"]

items-file

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

rule

Test_Number.sendCommand(50)

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

BR
nickd

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

Logo
image

Kind regards.
Brecht.

Hi @Brecht

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

Here my code:

//thing
Thing memory MEM_VW140 [ block="VW140"]

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

//rule
Test_Number.sendCommand(50)

Logo
grafik

With Bits (VB) and digital thing it works.

Another hint for me?

Regards,
nickd

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:

BR
nickd

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

Kind regards,

Alexander

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?) :
grafik

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: {
      Up.sendCommand(OnOffType.ON)
    }
    case DOWN: {
      Down.sendCommand(OnOffType.ON)
    }
    case STOP: {
      if(Direction == UP) {
        Up.sendCommand(OnOffType.ON)
      } else if (Direction == DOWN) {
        Down.sendCommand(OnOffType.ON)
      } else if (Direction != STOP) {
        logDebug("LogoRolloLogic", "Direction " + Direction + " is not supported.")
      }
    }
  }
]

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

rule "RolloDrive"
when
  Item Rollo received command
then
  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)
end

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

Kind regards,

Alexander

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,

Alexander

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.

BR,
Jacek

@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?

Grtz,
Brecht.

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,

Alexander.

Hi @skazi,

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

Kind regards,

Alexander