I am very new to openhab2 and trying to configure my Siemens Logo 0BA8 FS4 by examples and searching for documentation. I installed the latest plc binding (2.3.0.201801051407) and according to karaf it is active.
My problem:
I would like to configure things for input and output:
“I” blocks are physical inputs, you can’t change their state using software. Take a look at my examples just ~4 posts above. You have to use “NI” blocks with “VB” addresses assigned and access them via “VB” blocks in openhab.
Thanks a lot for your binding! Too bad I wasted all the ours writing my own “binding” with the help of snap7 and the exec-binding. I wish I had discovered this earlier! This latest snapshot works great from me with a LOGO8!
Is there a change that Rollershutter items will be supported in the future for pulse channels?
Is there a good reason why this binding is not officialy supported as an openHAB binding?
We need extension for pulse - things to support rollershutters. Reason: There are at least 2 pulses need. One for “Up” and one for “Down”. But the most “problem” i have is Percent: Have no idea, how to implement it properly.
Details are here: https://docs.openhab.org/configuration/items.html If i get idea how to model “percent” properly and find time, i’ll implement it. About reason: I have open PR in openhab2-addons repository. I think, it’s only the question of time, when it will be merged.
Yes, the problem here is that there is no longer a possibility to assign a channel (or someting similar) to an UP, STOP, or DOWN command. This was possible in openHAB 1.x but this functionality was not reimplemented. So even if the plclogo binding would understand “UP” and “DOWN”, it still would need to know where it comes from.
It is possible to assign 2 or more channels to an item. Maybe a way is to dedicate one channel with an additional keyword e.g. acceptcmd=“UP”. All other command will be ignored. If the keyword is not used, only “ON” and “OFF” will be accepted (as before).
The “observed” is not a must to be supported in this case in my opinion, since the return-channel can be easier implemented than the command-channel in combination with rollershutters (item). And the status value which you get from the PLC will unlikely be shown in percent. Thus it will always be necessary to write a rule to aquire the status information.
For the pulse-thing, a percent command is prett much useless, since you just want to change a bit…
I have an issue getting aconnection between OH2 (stable release 2.2.0) and an Logo 0ba8.
I installed the latest version (org.openhab.binding.plclogo-2.3.0-SNAPSHOT) of falkena’s binding (by downloading the *.jar from the “binaries” folder on github, and copying this to the */addons folder).
The binding is displayed as “running” in karaf console.
The log file shows continous warnings, and it seems to affect OH2’s performance (experienced delayed response on sitemaps). No action on the Logo! at all.
2018-02-11 14:58:11.100 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: Data Receiving timeout.
2018-02-11 14:58:13.230 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: Data Receiving timeout.
2018-02-11 14:58:15.362 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Giving up reading from 192.168.0.21 after 10 retries.
2018-02-11 14:58:15.363 [WARN ] [ding.plclogo.handler.PLCPulseHandler] - Can not read data from LOGO!: Data Receiving timeout…
BTW: I had an older version of Falkenas binding (i think it was called V2.1. - October/November 2017) running on unstable releas OH2.2.x but thought it would be a good idea going to the stable release and latest version of this binding.
any idea what I’m doing wrong?
Thank you in advance!
I am running the same plclogo binding on this openHAB-2.2.0.010 version.
If you are able to ping your Logo, then it shouldn’t be far from being able to connect - except correct configuration.
I use this on 2 setups:
openHAB running on Windows (for development)
openHAB on a Synology NAS (final target)
Both are running fine.
I would recommend to comment out all things and see if this has any effects.
Also, if you used ealier version, there might be a disturbing *.cfg file in the “services” folder.
i have an issue, similar to the one “Dreamar” submitted earlier in this topic.
"2018-02-25 13:50:03.073 [hingStatusInfoChangedEvent] - ‘plclogo:analog:Logo:AM1’ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING)
RTC is working and connection to Logo seems to be fine. I tried many workarounds in the last days but nothing helped
logo.things
Bridge plclogo:device:Logo [ address=“192.168.2.203”, family=“0BA8”, localTSAP=“0x0300”, remoteTSAP=“0x0200”, refresh=100 ]
{
Thing digital VB0_0 [ block=“VB0.0” ]
Thing digital VB0_1 [ block=“VB0.1” ]
Thing digital NI1 [ block=“NI1” ]
Thing digital NI2 [ block=“NI2” ]
Thing analog AM1 [ block=“AM1” ]
}
logo.items
// NI1 is mapped to VB0.0 address in LOGO!Soft Comfort
// NI2 is mapped to VB0.1 address in LOGO!Soft Comfort
Switch LogoUp {channel=“plclogo:digital:Logo:VB0_0:state”}
Switch LogoDown {channel=“plclogo:digital:Logo:VB0_1:state”}
Contact LogoIsUp {channel=“plclogo:digital:Logo:NI1:state”}
Contact LogoIsDown {channel=“plclogo:digital:Logo:NI2:state”}
Number AM1Merker {channel=“plclogo:analog:Logo:AM1:value”}
A hint to a general issue:
Recently I moved to another identical (Linux based) platform, an a configuration which was running perfectly before didn’t on the new platform. The interesting thing was that it didn’t just work at all, but apprx. half of my inputs on the Logo didn’t work randomly.
Once again it turned out to be a file permission issue - due to the new openHAB installation which I installed sightly different than on the first identical platform. After fixing the permissios, everything was fine.
dependend on binding version, your configuration may be wrong. Thing configuration was changed in the last version: Openhab failed to initialize many things properly. Please, take a look into documentation:
Please, check local/remote TSAP was set in LogoSoftComfort and bridge configuration. Communication will not work, if they are not set properly. I assume, that Logo can be ping’d.
EDIT: Took the look into commit history: Your configuration is supported by last binding version only. I performed huge refactoring, that was done on 18.01.2018. So, yes, it is good idea to update the binding.
hm… i just connected with LogoSoftComfort again. I’m pretty sure that the TSAP settings are done there. (20.00 and 30.00)
anyway the Log is flooded with
2018-03-10 17:05:25.872 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
2018-03-10 17:05:37.968 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: Data Receiving timeout.
2018-03-10 17:05:42.974 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
2018-03-10 17:05:47.980 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
2018-03-10 17:05:52.986 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
2018-03-10 17:05:57.989 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
2018-03-10 17:06:02.995 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
2018-03-10 17:06:23.353 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: Data Receiving timeout.
2018-03-10 17:06:28.355 [WARN ] [nding.plclogo.internal.PLCLogoClient] - Reconnect during read from 192.168.0.21: TCP Sending error.
The interesting thing regarding ping: as soon as the Binding is started, Logo doesn’t respond to ping properely anymore. (~75% loss, or 3 out of 4 tries).
If not connected, its response time is 5ms avg (connected via power-line adapter).
One more thing. I was able to send one command (pulse output) one times. Light was going off. Could not be reproduced so far.
any idea?
PS:
I’m trying at a minimum config now - still without success:
*.things
very strange. Please, try follow: Remove all pulse things/items and create one digital thing. Q-Kind will be fine. Additionally connect DateTime item to RTC channel. RTC will be updated by Logo8 nearly one time a second. Work this configuration properly?
just a quick update. Sorry @falkena, I had no time yet to trying out your proposals, but I will give it a try as soon as I find a convenient time slot. Thanks for taking care of my issues!
Since there is another issue on stability of my KNX-communication, my recent suspect has been my hardware/virtualization environment (Hardware: 16GB Ram, Intel i5 3rd generation, SSD Harddrive, Software: VMWare ESXi, Ubuntu 16.x LTS, as well as some Windows/Linux VMs; no high load in the average, according to VMWares onboard performance monitor)
Thus I shortly decided to changing-over to a raspberry Pi, using the official OH2 image.
I basically powered up the system, and transferred all *.items, *.rules, *.things, *.sitemap onto the raspberry (the old system was stopped of course!)
I also placed the PLC-Logo binding in the according folder. After reboot, it appeared immediately as an installed binding in the PaperUI.
What I noticed after creating Logo-Items, was really alarming to me. Not only that the same flood of errors in the log could be noticed right after the activation of the PLC-Logo binding; This seemed to be blocking the entire Ethernet-network.
i.e.: I’m doing all the setup by the use of virtual machine, and working connected via remote desktop connection. As soon as the PLC-Logo binding starts flooding the Log with errors, there is an extreeem lag on the remote-desktop connection.
It seems that after x retries, the plcLogo binding gives up, and remote-desktop is immediately working flawless again. Also as soon as I disconnect the Raspberry from Ethernet, network is up and running flawless immediately again.
Next step for me: Wireshark
