@falkena: min should always be “0”, but max must be variable.
Of course scaling inside the Logo would be the best, but I didn’t find how to do it.
I thought scaling inside the binding may be the best and easiest.
Edit: Another way may be to read the max-value from the logo. With my UDF this would be possible.
@BlackAlpha Hmmm. Min is not necessary 0, it can be some value. I think not only about control of rollershutter,
but may be for example water pump. If level reported by LOGO! is negative, i would map it to 0 and send alarm.
May there is a better example for.
Ok. The last thing, we should clear is zpos 
I’ll take a look on this after analyse a bug reported by @skazi.
Will make a PR, it is time for this
@BlackAlpha, @jens
EDIT: Ok took a look into UDF from Frickelzeugs: Bug reported by @skazi is a little bit harder than I assumed 
On my opinion, things should reflect more general stuff. For example with “normal” rollershutter you can control water pumps, dimmer or something else can be controlled by LOGO! AM2 AQ extension module. What do you think?
BTW: My UDF for control of rollershutter works a little bit different: I calculate a percentage of rollershutter in UDF (0 is full closed and 100 is full open) and react in openhab dependend on reported percentage value.
Yeah the bug is way more important.
Maybe we can have a little real talk about this…?
I’m totally with you. I have AM2 AQ’s too, to control dimmer’s, but have not tried to implement them yet…
Would you share your UDF for the shutter? Sounds good… maybe we can “frickel” one that fit all our need’s with someone loosing functions…
Has anyone tested this addon with FS4?
I created Item manually and I’m getting: “Can not read data from LOGO!: Data Receiving timeout…”. I thought that it might be FS4 problem but looks like there’s something else wrong with my setup.
Please, take a look into localTSAP/remoteTSAP configuration. And be sure to have 0BA8 as LOGO! type. I assume, that the network connection is alive.
@skazi
Hi I can’t help you to solve the problem with linking of items. It seems to be a bug in a PaperUI:
I tried it with openHAB 2.1.0 snapshot too: without any success Configuration via HabMin works without any problems. Cost me nearly a whole day 
@BlackAlpha, @jens, @grefix, @skazi
Today i made a little progress with the binding: Bridge have now a channel called “rtc”. This provides the value of LOGO! rtc as DateTime item. New version can be found at: https://github.com/falkena/binaries
Next thing will be provide analog channels as DateTime values I got the way how to do it
Guys, give me feedback please, if current version works. I’ll made PR.
Regards,
Alexander
@falkena I’m not sure if this is the same problem. The bug says that the REST api returns channel types correctly. In my (test) setup I see only system:* channel type in REST api. There are no other bindings installed.
@falkena changing TSAPs from 0x2000/0x3000 to 0x0200/0x0300 fixed my connection problems. Now I only get occasional “data receiving timeouts”.
OTOH, I started getting “RTC thread got exception: null” every second. I guess it’s related to your recent changes, correct?
Hi @skazi,
Yes, i read RTC in extra thread with fixed delta of 1 second. It can be, that, thread quits since no valid data comes within 1 second. Anyway, thank you:-)
EDIT: Can you send me please a 2-3 Min TRACE-Log? Please, activate trace of binding only, I can not reproduce the Problem…
Thank you very much.
Kind regards,
Alexander
Hmmm. Strange. If you call http://localhost:8080/rest/channel-types/ you should see at least
parameters
parameterGroups
description: "The value of Siemens LOGO! RTC"
label: "Siemens LOGO! RTC"
itemType: "DateTime"
kind: "STATE"
tags:
UID: "plclogo:rtc"
Is it here?
@falkena You’re right, I tried the API before updating to new version. With latest binary plclogo:rtc is there but it’s the only one from plclogo.
The trace log doesn’t seem to contain anything interesting:
plclogo.trace.log.gz.pdf (28.4 KB) (remove pdf extension).
Do I need to configure anything on LOGO side to have the RTC enabled? Maybe my configuration is causing this.
Hi @skazi,
thank you for trace I got some clue from and upload new version to https://github.com/falkena/binaries
Please try this one, if “RTC thread got exception: null” error is away now.
EDIT: Please restart openHAB. Simply to copy new version into addons folder will not work.
Kind regards,
Alexander
Hi @falkena
The error is gone from the log with the new version.
I tried to test the new rtc channel but I couldn’t make it work.
Is the rtc channel supposed to be under the bridge thing (i.e. plclogo:device:my_plc_address:rtc)?
The paper UI doesn’t show it anywhere. I also tried manual item definition but it doesn’t display anything. Any hints?
BR,
Jacek
Yes rtc is a channel under the bridge.
Manual definition should be: plclogo:device:my_plc_id:rtc
Kind regards,
Alexander