Hi @gabriele.rendina,
I do not see any wrong part in your file configuration. Try to see what the logs say and try to configure in the .items and .things file one device, then 2 etc. Start with just the bridge and 1 thing/1 item and see if it works.
the current version of the binding (2.5.0.M3) is compatible with OH 2.5.0 release (of course you have to follow the install instructions in the README_beta).
Hi @m4rk! You seem to report several things, and from your description I cannot follow exactly what you are doing, what you are expecting, and what the systems does instead and you think is wrong.
I suggest you start with few rollershutter (eg. only 2) and try to achieve what you want.
Maybe even use a new thread here in the forum…
The expected behaviour is just straightforward: for each well configured blind (=where auto calibration has been done or shutterRun parameter has been set, see README as always!) when you send a % command from OH (either PaperUI/BasicUI or from a rule) the shutter should move and its % position is updated at the end of the movement, when it stops.
It’s not possible from the basic BUS messages to update the %position live while the shutter is moving.
Given the position is estimated, there might be an error of ±2%. If gw connection is lost, estimation is lost and a full open or full close should be sent.
See README.
When you operate the shutter from other BUS control point (e.g. physical button, other mobile app not related to OH, or other interface like BTicino touch panel), the shutter should move and its % position on OH/PaperUI should be updated accordingly.
I do not have 19 blinds to test, but using a simulated MyHOME system, I managed to control correctly 30 blinds, and all responded well.
When you send a new command while the shutter is already moving, the current %position reached is valued. When it stops (in any way) again, the new final position should be updated as well. Basically position is updated each time a STOP event is detected, and each time a new command from OH is received.
If this is not the actual behavior in your system, go ahead and open a new issue on GitHub and explain VERY WELL your situation (answer to the questions in the issue template!)
Massi
Hi,
I figured out what is happening regarding the incorrect blind position reporting. It’s not a bug but a feature 
For openHAB initiated commands:
UP/DOWN sets a predicted 0%/100% position and blinds move to that position unless interrupted. Interruption by sending STOP/UP/DOWN commands causes the position to updated and movement stopped or changed with new predicted position. OK
For non openHAB commands e.g. Wall switch, Scenario command:
UP/DOWN command short press of wall switch >>> the blinds move a short distance and the position updated. OK
UP/DOWN with long press on wall switch or UP/DOWN command from MH202 >>>> equivalent to openHAB UP/DOWN command but without the predicted position update.
For my actuators F411/4 set as Automation actuator.
There is STOP time setting. After this time an automatic STOP command is sent causing a position update in openHAB.
However, for timely position reporting this STOP time needs to be close to the actual shutter run time as possible. My blinds will stop anyway regardless of this setting
The STOP time can only be set in 1 sec increments up to 60 sec. After that there are only 1 min increments with a max of 10 min.
Problem 1. Some long blinds have run times of just over 60 secs and the actuator STOP time has to be set to 2 min. This meant the blind positions are not updated for up to a minute after the blind had reached its end position.
Problem 2. I have some wireless connected shutter actuators and there are no settings to remote configure. ie no automatic STOP time can be set.
Partial fixes for the problem blinds:
Add additional STOP commands in the MH202 scenarios to force blind position update. This can be done several ways. Use a Group command or addressable command .
Group command with address type General sends a STOP to all the blinds but the binding doesn’t update the blind positions.
Group command with address type Group sends a STOP to actuators in the group and the binding does update the blind positions.
Group for WiFi connected actuators wasn’t possible for me as these have to be in Group 1 and that was already being used for another purpose. For these I added extra STOP commands in the MH202 scenarios.
Two problems remain for a Long press of a wall switch:
1 For shutter runs greater than 60 secs the position is not updated until up to 1 minute later.
2 For WiFi actuators the position its not updated until the switch is short pressed again and this may not happen.
If the binding could set a predicted position for wall switch long press, like it does for UP/DOWN openHAB command, then the problem would be resolved.
GitHub feature request >>>
M
1 Like
Hi everyone, I’m new to this forum. First of all I apologize for English, I use the google translator.
before writing I searched desperately everywhere without success!
I installed OH2 (at the latest version 2.5 because I can’t find 2.4 anymore)
i installed eclipse market, bticino binding and openwebnet. I am writing to you because they do not appear in the inbox, please help me !!!
p.s.I am using OH2 on an s.o. OSMC
until a month ago I had OH2.4 and everything worked fine, then the sd broke and I had to reinstall everything (I preferred to put OSMC so as to fully use the Rpi3)
Thanks again for the help !!!
It must be the second option then 
I’ve change the password.
Thanks for the binding 
Hi Marco,
as I installed the binding I found following error
“… Unresolved requirement: Import-Package: gnu.io; version=”[3.14.0,4.0.0)"
in the log.
This can be resolved by “feature:install openhab-transport-serial” at the Karat Console.
After this installed, the binding comes up and is working as expected.
Hi Reinhard,
I actually solved it with an old installation of openhab 2.4 and the binding works well!
Now, however, I have a problem with the 4-zone thermoregulation … in OH2 it is present and works perfectly, in the cloud too, but in google home it does not find it … do you have any suggestions? thanks in advance for your help!
One for the documentation. IR remote controller and IR receiver HD4654
I have a BTicino BUS IR receiver (HD4654) for use with IR remote controllers eg BTicino remote 3529
I actually use it with a Logitech Harmony One universal remote to automatically trigger lighting scenes when pressing play for DVD/BD, playing music etc. I also use the Harmony remote controller to turn BUS lights on/off, control blinds etc and any action that could be done by a scenario
In MyHomeSuite the scenario trigger looks like this:
The example above also appears to work like a std CEN with address 75 button 1. I created a corresponding button in sitemap for this and it triggers the scenario just like the remote controller does.
So, its possible to map all the remote controller buttons 1-16 by just following the Thing and Item definition as already used for CEN short press. You could then replicate the entire remote in Sitemap or Hab panel. There are a few threads with ideas on how to do this.
M
1 Like
Hello everyone… Yesterday I updated my raspberry because for some strange reason it stopped working…
I upgraded OH to version 2.5 and downloaded addons of MASSIMO the M3 version
and followed step by step the configuration as described by Massimo for installation, I joined PAER UI
for the research of my plant and here I noticed some diversity… immediately I was found the gateway bticino
and immediately after the devices, but instead of being immediately ONLINE as I found before, I found them ALL disconnected
Fixed everything and made sure that in paper ui they worked I connected with Google Assistant,
unfortunately without success because he did not find any device automatically as he did before
I tried to perform a manual configuration (as an attachment) and Google sees the devices but unfortunately not
he manages to command them
I hope there can be a solution… Thank you
Hello Riccardo
I am in the process of moving openHAB v2.4 RPi3 to openHABv2.5 RPi4 via openHabian. I have a few issues but the openWebNet binding isn’t one of them so far. It seems to be working very well.
Good evening,
i’m trying to setting up the roller with Percent. Reading on GitHub if I set them on AUTO ( as default if I leave it empty ) the roller does a “cycle” to set the time. Is it correct? I haven’t seen on mine rollers.
Could someone explain the correct setup?
From the README:
For Percent commands and position feedback to work correctly, the
shutterRunThing config parameter must be configured equal to the time (in ms) to go from full UP to full DOWN. It’s possible to enter a value manually or setshutterRun=AUTO(default) to calibrate shutterRun parameter automatically the first time a Percent command is sent to the shutter: a UP >> DOWN >> Position% cycle will be performed automatically.
1 Like
Thanks @massi for the reply. I’ve put the shutterRun=AUTO on the .things file but it comes out the error:
Configuration model 'biticino.things' has errors, therefore ignoring it: [26,94]: Number expected.
Sorry to bother you
Copy here line 26 of the file (use code fences)
bus_automation Tp_Scale "Tapparella Scale" [ where="55",shutterRun=AUTO]
Try adding double quotes, like this:
shutterRun="AUTO"
it looks that works qwith this conf, the only problem is that my actuator for the rollers send the “stop” signal for Full up and Full down after very long time and this seems to set a wrong timing ( after the Auto cycle). Could be this the problem?
Yes, that may cause wrong auto configuration.
In your case I would just set the shutterRun to the right rollershutter time , for example using a stopwatch