Unfortunately I don’t have any further log-entries except from events.log:
2020-01-24 15:51:33.625 [ome.event.ItemCommandEvent] - Item 'VELUX_Office' received command DOWN
2020-01-24 15:51:33.631 [nt.ItemStatePredictedEvent] - VELUX_Office predicted to become NULL
anyone else having that problem with non-moving rollershutters? 1.14.0.201903161709 is working fine, but I can’t get 2.5.1.202001051139 to work - tried in several variations.
The binding reads data from the KLF200 successfully (bridge status, SW version, …).
Any ideas @gs4711? Otherwise I’d need to roll-back.
many thanks for reply. The textual configs are the same - sitemap is displaying the whole group (gVelux).
I tried with different element-names (.things and .items) and different environments with OH stable (Debian9+Zulu8, Debian9+JDK11, Debian10+Zulu8, Debian10+JDK11, Debian10+JDK13) - in no combination I could get the rollershutters moving, but in every combination I was able to read data from the KLF200 (like bridge status, etc.).
When I use the old .jar (1.14.0.201903161709) everything is working fine (with old textual configs of course).
I get no errors, whatsoever. Also, when I “find products” via the KLF interface, the rollershutters are moving so I can safely say that my problem is somewhere within the OH environment.
please find attached a current screenshot from that sitemap. VELUX_Office is in that group (=“Büro Velux”), I didn’t post it because I wanted to show only relevant declarations.
yes, of course - as of my initial post in events.log:
2020-01-24 15:51:33.625 [ome.event.ItemCommandEvent] - Item 'VELUX_Office' received command DOWN
2020-01-24 15:51:33.631 [nt.ItemStatePredictedEvent] - VELUX_Office predicted to become NULL
… that’s (unfortunately) it. Nothing “faulty” to be found in openhab.log at all.
Thats odd… Your items receives the command fine, but it doesnt send it to the Velux binding… Its like there is a communication issue with the KLF200. (I know you said other things works fine).
When you added the new binindg, did you clear cache/tmp and restarted OH ?
Yes, it seems that way. I also thought the same, but I can read data from it (to be seen in my screenshot).
In my latest approach I removed the “old” .jar, renamed the old textual configs to e.g. .items-OLD (so that they’re not loaded), service-restarted OH, put in the “new” .jar, nano-ed the new textual configs and rebooted again.
The connection is successul (shortened) but I cant get anything moving;
2020-01-24 15:48:43.276 [INFO ] [.internal.handler.VeluxBridgeHandler] - Found velux actuators:
[...]
Product "Office" / SLIDER_SHUTTER (bridgeIndex=3,serial=56:32:14:26:0F:0C:00:B1,position=0000)
[...]
2020-01-24 15:48:43.788 [INFO ] [.internal.handler.VeluxBridgeHandler] - velux Bridge is online with 0 scenes and 6 actuators, now.
Could you elaborate what you mean with clearing cache/tmp?
Last thing that comes to my mind: is there a chance to clear OHs’ internal db to actually force it to reload everything from scratch?
Search for clear cache here on the forum.
In short - Go into your OH setup using SSH (Putty etc).
Login
Use this command: sudo openhab-cli clean-cache (enter)
Press Y on the promt.
