Add support for separate input and output blocks

[skazi0]

To avoid "proxy" items in openhab, it would be good if user can specify separate input and output blocks in one item.

[skazi0]

Some proposal was defined here: https://community.openhab.org/t/integrate-siemens-logo-plclogo-in-openhab-2/24272/72

[lsibilla]

I just pushed an update on branch feature/plclogo that fixes this issue. Still lacking documentation but it basically works this way :
Thing MyThing [ block="Q8", input="VB5.7", pulse=50 ]

input and pulse are facultative. If they are not present, it works the same way as before.

If input is present, write operation are made on this address instead of the block itself.

If pulse and input is present, write operation are made of pulse instead of writing the actual value.

[falkena]

Just pushed refactored version of @lsibilla PR. New thing "pulse" was introduced. Documentation can be found below. New prebuilt version can be found here: https://github.com/falkena/binaries
The configuration pattern for pulse things is:

Thing pulse <ThingId>  "Label" @ "Location" [ block="<name>", monitor=<name>, pulse=<number>" ]

Parameter	Type	Required	Default	Description
block	String	Yes		Block name
monitor	String	No		Block name to monitor for a change
pulse	Integer	No	100	Length of pulse to send in milleseconds

If parameter monitor is not set or set equal block, simply pulse with length pulse will be send to block.
If parameter monitor is set and differ from block, binding will wait for value change on monitor and
send then a pulse with length pulse to block. Please note, update rate for change detection depends on
bridge refresh value.

Follow block names are allowed for pulse things:

Type	0BA7	0BA8
Marker	M[1-27]	M[1-64]
Memory	VB[0-850].[0-7]	VB[0-850].[0-7]

Follow monitor block names are allowed for pulse things:

Type	0BA7	0BA8
Input	I[1-24]	I[1-24]
Output	Q[1-16]	Q[1-20]
Marker	M[1-27]	M[1-64]
Network input		NI[1-64]
Network output		NQ[1-64]
Memory	VB[0-850].[0-7]	VB[0-850].[0-7]

[skazi0]

@falkena I'm confused... shouldn't the block be used only for user inputs if monitor is specified? Your description suggests that there is a feedback loop between monitor and pulse. What kind of circuit do you use with this?

EDIT: I re-read @lsibilla comment above and I liked this logic better (maybe except naming): if input is specified block is used only for reading (status changes) and input (which should be output from openhab perspective) is used for sending pulses after receiving commands from user.

[falkena]

@skazi0 Some background for this logic: There are network input blocks for Logo8. Follow situation: NI1 is mapped to VB0.0 in LogoSoft Comfort. I define follow thing: Thing pulse SendPulse [ block="VB0.0", monitor="NI1", pulse=100 ] Assuming NI1/VB0.0 are false. Now i send true to VB0.0. Thing polls now for change on block NI1, i.e data was transferred to Logo!. The polling rate is refresh time. Now timer will with duration pulse milliseconds will start. If timer was expired, false is send again. This way i get network latency "killed". It's not possible with @lsibilla's logic, at least as far i've understood his code. His logic can be implemented by set parameter monitor the same value as block or leaving it: Thing pulse SendPulse [ block="VB0.0", pulse=100 ] or Thing pulse SendPulse [ block="VB0.0", monitor="VB0.0", pulse=100 ]. Next point is "thing consistency": block is always "working". Just the same like in another things. I can change the behaviour, that monitor is always need for sending a pulse. If monitor is not set, then we have digital "read-only" thing with reduced number of available blocks.

EDIT: Setting of NI-Blocks will be ignored by Logo:-( That's why i must go via VB-Memory blocks...

[skazi0]

@falkena hmmm... I still don't see how you want to use it. I was thinking about a following circuit:

With @lsibilla logic I would model it as following thing: Thing pulse SendPulse [ block="Q1" output="VB0.2" pulse=100]. This way the network "button" NI2 (mapped to VB0.2) is working the same way as physical button I6 and state of Q1 is always correct in openHab.
Does it make sense or do I miss/misunderstand something? How can you get similar behavior with your implementation?

[falkena]

@skazi0 I think about the same circuit :-) You can do the same with "my" logic: Thing pulse SendPulse [ block="VB0.2", monitor="Q1", pulse=100 ]. Additionally it's possible to do Thing pulse SendPulse [ block="VB0.2", monitor="NI2", pulse=100 ]. I made it this way, since another things controls block parameter. It's no problem to change the definition "your" way. Moreover: You can write Thing pulse SendPulse [ block="VB0.2", monitor="VB0.2", pulse=100 ] or simply Thing pulse SendPulse [ block="VB0.2", pulse=100 ]. This will simply send 100 milliseconds pulse to VB0.2 without waiting on any Logo response.

[skazi0]

@falkena your first thing definition (Thing pulse SendPulse [ block="VB0.2", monitor="Q1", pulse=100 ]) doesn't work correctly for this circuit (at least for me). I see following behaviors (I start with LOGO in sync with openHab):

• I click item in UI it pulses VB0.2 and causes Q1 to switch to ON.
• Change of Q1 is seen by the binding and it triggers another pulse to VB0.2 which turns Q1 off.
• I get similar behavior when clicking physical button I6 (it blinks the output)
• Sometimes with quick sequence of clicks of physical button I get the output to "stick" in ON position. I cannot undo it with physical button but I can with UI.

IMO with the logic of "separate block for writing" it would be cleaner. The item would always represent state of block. Sending commands to item should only write to the output block and leave things to autosync by itself. Even if we don't change item state when writing, it should update after another cycle as LOGO should update state of block after receiving pulse on "write" block. In theory the item state could be also updated when writing to "write" block and block change coming in following cycle should not change it but I'm not sure how this will work wrt some triggers, scripts etc.

PS. I have both pulse and refresh interval set to 100ms, I think this is the reason why I sometimes get the output to stick in ON position. What are the recommended timings in this kind of setups?

[falkena]

@skazi0 About logic "separate block for writing": I can change it this way. Should be no huge problem. But we will loose a possibility simply send an pulse. This must be done via rules this case.
About behavior: Points 1-3 sounds good for me. Is different behavior awaited? Point 4: Sounds, like there is a rule hanging on I6, that modifies VB0.2. If yes, it's possible to get Q1 always high, since binding updates his state only with refresh rate. Means, some state changes will be simply not seen by binding. Reagrding you question: I've testet with refresh 100ms and pulse 50ms. Maybe there is a data race with same values. Sadly, we work not with real-time system. Means pulse=50 says "at least 50 ms". I've seen 500ms delays on my test system due to wlan. And pulse length was sometimes longer than 50 for the same reason.

[skazi0]

I would expect Q1 to toggle state and stay on that after I click any of physical/UI buttons assigned to it. I tried with refresh=100 and pulse=50 and still doesn't behave as I expect.

[falkena]

Simulated your circle in LogoSoftComfort. I took 2 simple input blocks instead of netwotk one. Pulse on I1 toggles Q1 high -> Since pulse thing monitors Q1 and Q1 changed it state from 'low' to 'high', block VB2.0 (in my simulation I2) will get 'high' for 50 ms and then 'low' -> Q1 will go off. Seems to be ok for me. To get behavior you describe, i use "normal" RS-Trigger and not "pulsed" one.

[skazi0]

But with normal RS I need another button to turn Q2 off. This is supposed to be for light control so click buttons on the walls and alternative one in software which should work in similar way but also represent current state of Q1.
My idea was that software should send data to LOGO only when triggered directly via openHAB and update item state based on data received from LOGO.
What kind of use case do you have in mind for your current implementation?

[falkena]

Then use Thing pulse SendPulse [ block="VB0.2", monitor="VB0.2", pulse=100 ] or simply Thing pulse SendPulse [ block="VB0.2", pulse=100 ]. Additionally you will need Thing digital Lamp [ block="Q1" ] to monitor the lamp. May be we need something like "lamp" - thing to implement your behavior.

Pulse thing has the same behavior like "Digital input as Closer-Button" in LogoSoft Comfort.
Currently, i use pulse-thing to control my rollershutter. Early i've implemented a lot of proxy items to send a pulse. Now they got obsolete. I start a pulse after change on Logo side, means if Logo got new value transferred. My thing definition is Thing pulse ShutterUp [ block="VB0.2", monitor="NI2", pulse=50 ]. Small compare "early" and now" for one button:
Early:
Thing digital VB0_0 [ block="VB0.0" ]
Thing digital NI1 [ block="NI1" ]

Switch LogoUp {channel="plclogo:digital:Logo1:VB0_0:state"}
Contact LogoIsUp {channel="plclogo:digital:Logo1:NI1:state"}

rule "LogoIsUpChanged"
when
Item LogoIsUp changed to CLOSED
then
createTimer(now.plusMillis(50), [|LogoUp.sendCommand(OFF)])
end

Now:
Thing pulse VB0_0 [ block="VB0.0", monitor="NI1", pulse=50 ]
Switch LogoUp {channel="plclogo:digital:Logo1:VB0_0:state"}

[skazi0]

Yeah, using Thing pulse SendPulse [ block="VB0.2", monitor="VB0.2", pulse=100 ] would require additional item which will represent status of the lamp and the switch connected to pulse would need to be changed to push-button in openhub. This I was able to do without the latest changes to the binding by resetting the flag on LOGO side. Something like this:

I haven't got to the rollershutters yet :) Probably you're right that this logic works better for this case. And I'm pretty sure you're also right that we need another thing type to handle lamps :D

[falkena]

Now you can simplify your Logo Program :-) And it seems, we need a lot of different stuff :-) Currently, i write common things as far my time allows me :-) And currently i try to implement things mimics same as in LogoSoft Comfort.

[petosak]

Hi @falkena,
thank you for your improvement. I just trying to use pulse, but it dousn't works.
2017-09-02 11:56:20.321 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate command 'ON' for item 'Switch_start_zavlah' to handler for channel 'plclogo:digital:Logo1:VB_Start_zavlah:state', because no thing with the UID 'plclogo:digital:Logo1:VB_Start_zavlah' could be found. 2017-09-02 11:56:20.329 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update 'ON' for item 'Switch_start_zavlah' to handler for channel 'plclogo:digital:Logo1:VB_Start_zavlah:state', because no thing with the UID 'plclogo:digital:Logo1:VB_Start_zavlah' could be found. 2017-09-02 11:56:23.840 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate command 'OFF' for item 'Switch_start_zavlah' to handler for channel 'plclogo:digital:Logo1:VB_Start_zavlah:state', because no thing with the UID 'plclogo:digital:Logo1:VB_Start_zavlah' could be found. 2017-09-02 11:56:23.848 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update 'OFF' for item 'Switch_start_zavlah' to handler for channel 'plclogo:digital:Logo1:VB_Start_zavlah:state', because no thing with the UID 'plclogo:digital:Logo1:VB_Start_zavlah' could be found.

Thing pulse VB_Start_zavlah [ block="VB103.0" ]

Switch Switch_start_zavlah "Spuštění zavlažování" <switch> (gLogo, gSwitch) {channel="plclogo:digital:Logo1:VB_Start_zavlah:state"}

Where is problem?
BR
Petr

[falkena]

Hi @petosak,
your Switch definition seems to be wrong.

Please, try
Switch Switch_start_zavlah "Spuštění zavlažování" <switch> (gLogo, gSwitch){channel="plclogo:pulse:Logo1:VB_Start_zavlah:state"}
instead of
Switch Switch_start_zavlah "Spuštění zavlažování" <switch> (gLogo, gSwitch){channel="plclogo:digital:Logo1:VB_Start_zavlah:state"}

Kind reagards,

Alexander

[petosak]

Hi @falkena ,
ok. i made change in items file and it works now. But there is problem with using. When i use switch control (in sitemap) for pulse, sometimes stay open. Semetimes aftes couple of seconds close.
Best Regards
Petr