[BTicino/OpenWebNet] New openHAB2 binding ready for testing

Add-ons Bindings
, ,
951

Hi everybody,

yesterday I have updated to OH 2.5 stable. Since then I’m getting this error:

2019-12-18 13:52:54.482 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: https://github.com/mvalla/openhab2-addons/releases/download/own-2.5.0.M3/org.openhab.binding.openwebnet-2.5.0.M3.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.openwebnet [267]

  Unresolved requirement: Import-Package: gnu.io; version="[3.14.0,4.0.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]

	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

I have no connection to my OWN GateWay at the moment.
Have someone experienced the same behavior?

952

Hi again,

for some reason I focused on the message:

Unresolved requirement: Import-Package: gnu.io; version="[3.14.0,4.0.0)"

I just followed someone’s suggestion to install the Serial Binding (binding-serial1 - 1.14.0) and now it’s working.

Hope someone find this useful in case you’re in trouble :smiley:

953

You have to do these steps from the installation procedures again:

2. Activate Dependencies

After the binding has been installed, from Marketplace or manually, some features dependencies must be activated manually :

  • from Karaf console:
    • feature:install openhab-transport-serial
    • for openHAB 2.4.x:
      • feature:install esh-io-transport-upnp
    • for openHAB 2.5.x and later:
      • feature:install openhab-core-io-transport-upnp

The binding should now be installed: check in PaperUI > Configuration > Bindings .

After upgrading the binding to a new version, there is no need to activate dependencies again.

However dependencies must be activated again if you upgrade openHAB to a new version or clean its cache.

954

Hi Max!

I have done this in fact:

* feature:install openhab-transport-serial
* for openHAB 2.5.x and later:
* `feature:install openhab-core-io-transport-upnp`

But didn’t solve my problem. Only after installind the Serial Binding I got everything working… :thinking:

I have upgraded from an OH 2.4, don’t know if my setup is corrupt or not, OWN failure is just one of all problems I’m facing right now. I’ll try a clean setup these days…

955

Hi all,
i have a running setup with a openhabian on a raspberry pi 3 with the actual build openwebnet binding.

Now i have installed a second setup on a raspberry pi4 4gb also with the actual raspian and i have installed the openwebnet binding from the eclipse market. I see it in the bundle list and i see that it is installed in the addons.
think
Here is my problem :smiley:, i dont’ see the binding at Configuration -> Things -> +

Is this issue known?

BG Patrick

956

Hi,

I have voice commands now working with Alexa without need for an Alexa routine. ‘Alexa, Open, Close, Raise, Lower blind’ all work without Alexa routines or openHAB rules and proxy items. I now use the more capable v3 Alexa tagging. There was an issue with mixed language and locations like me. English language but in located Austria with .de Amazon server. However, Jeremy, the Alexa skill developer quickly fixed that bug.

The one missing command is STOP and for that I still need an openHAB work around. STOP will be added to the Alexa skill in a future update.

Here is the code with the stop work around: I will update it if needed later. It may need some polishing but it works.

items file

Group OfficeTest "Office test blind" {alexa="Endpoint.Other"}
String OfficeBlindStop "Stop office blind" (OfficeTest) {alexa="ModeController.mode" [supportedModes="STOP=STOP,UP=UP, DOWN=DOWN"]} //, expire="5s,command=STOPPED"
Rollershutter OfficeBlinds "Office blinds" (OfficeTest) {alexa="RangeController.rangeValue" [category="EXTERIOR_BLIND",supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)"], channel="openwebnet:bus_automation:Screen10:55:shutter" }

rules file

rule "STOP BLIND"
when 
    Item OfficeBlindStop changed to 'STOP'
then
    OfficeBlinds.sendCommand(STOP)
    Thread::sleep(1000)
    OfficeBlindStop.postUpdate('STOPPED')
end

Because of the work around in order to STOP a blind you must say …’ Alexa, Set office blind to stop’

I didn’t like that and so created an Alexa rule for saying…‘Alexa, Stop blind’

If @massi sees this it would be good to check the thread for the Alexa skill because the fix for the missing stop may require some collaboration, as I said in an earlier post

If you don’t need the STOP command to work or its fixed by an update, skill and or binding, then for natural blind commands to work natively you will only need one line of code like this:

Rollershutter OfficeBlinds "Office blinds" {alexa="RangeController.rangeValue" [category="EXTERIOR_BLIND",supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)"], channel="openwebnet:bus_automation:Screen10:55:shutter" }
957

Try to look under “bindings” instead of “things”

958

the same at all this points. I have it running on my Raspberry 3 and i see the difference :slight_smile:
Has anyone this setup? Raspberry pi4 and Raspian? with openhab?

959

Here are some improvements to the code I posted earlier for Alexa control of blinds:

Voice commands like…Lower, Raise, Increase, Decrease, Open, Close and others can now all work with just a single line of item code. No rule or Alexa routine is needed. If that is indeed all you need then just use item code for the Rollershutter item shown below without the group (OfficeBlind)

To get the STOP blind command to work you need more code and must say it like this for my example below…
‘Alexa, set office test to STOP’

In this case the item code will now need an additional Group item and with members comprising two controller items. Mode to capture the STOP, UP or DOWN commands and a range controller for all other commands. An openHAB rule is also needed to issue the BUS command STOP or UP, or DOWN when the mode string item is updated.

You can, if you want but its not necessary, refine it further so it also works with nicer voice command of :
‘Alexa, Stop Office test’

To do this you also need an Alexa routine for the spoken phrase
‘Alexa, Stop Office test’

The routine will then issue the actual command STOP to the Office test Rollershutter. When setting this up the app will offer the available choices for Office test. UP, DOWN, STOP.

Final code for items and rule with STOP workaround:

Group OfficeBlind "Office test" {alexa="Endpoint.EXTERIOR_BLIND"}
    String OfficeBlindCommand "Office blind command" (OfficeBlind) {alexa="ModeController.mode" [supportedModes="STOP=STOP,UP=UP,DOWN=DOWN", autoupdate="false"]} 
    Rollershutter Office_RollerShutter "Office blind [%d %%]" <blinds> (OfficeBlind,gAllBlinds) {alexa="RangeController.rangeValue" [supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)", stateMappings="Closed=100,Open=1:100"], channel="openwebnet:bus_automation:Screen10:55:shutter" }

rule "Office blind command"
when 
    Item OfficeBlindCommand received command STOP or
    Item OfficeBlindCommand received command UP or
    Item OfficeBlindCommand received command DOWN
then
    Office_RollerShutter.sendCommand(receivedCommand.toString)
end
1 Like
960

my Issue is solved. I have done a new installation and it works

961

Hi Guys,

Just to let you know that I’ve installed and configured this binding. I was able to move one of my roller shutter.

Thanks to @bastler for pointing me to this binding.

My flat is equipped with F454 bticino bus.
The following has been autodetected : 2 thermostat, 3 rollershutter, 5 Energy Central Unit, 8 switches.
(I feel it’s complete)

I’ve done this remotely (checking with a webcam that the rollershutter move when command so), I’ll complete the setup once back home.

I’m using a Docker image of OpenHab 2.5.0 (debian) running Synology (1813+);

The installation process was easy, no issue at all. (although it can be scary for some)
The bus was detected automatically, then the things as well.

I’m a bit surprised because I’m not using the default password, I would have expected to put it somewhere during the install.
(I tried before the v1 binding for bticino without success, but the bticino.cfg with ip & password was still there).

Or is it part of the UPNP ?

Where can I get notification about new release of the binding ?

Thanks,
Thomas.

962

Hi,
I noticed the blind position reporting seems inconsistent with my 19 blinds. eg After a blind open scenario has run to open all blinds I see in sitemap, BasicUI some reported as 100% and others 0% with some at 97 and 98%. The blinds open in staggered fashion and in stages to gently introduce light into the house in the morning. If I then command the fully open blinds with incorrect reported position either via wall switch of sitemap switch then they are then correctly reported. ie 0%

It seems the binding only updates at the point a BUS command is sent. Its not live or refreshed. eg If I send a down command and the position is reported as the ‘expected’ position of 100%. If I then repeat the down command before the blind is fully closed the position is reported as being the current position when the down command was sent. It doesn’t update again even when it has finally reached the fully closed position

How should it work?

963

Hi @paquerette, good that the binding works with your installation using OH 2.5.0.
Funny that you configured the rollershutter remotely! :slight_smile:

The binding tries to connect to the gateway using the default password (12345) then gives an error if it cannot connect. The fact that in your case it connected right aways has 2 explanations:

  1. you indeed have still set the default password :slight_smile:
  2. your Synology where docker and OH2.5.0 are run is in the “allowed range” of IPs for which the BTicino gateway does not require a password, you can check this in your BTicino gw configuration page.

No config is shared with the v1 binding, but just in case just delete the v1 config and restart OH.
No password is sent via UPnP, just the gw IP.

New releases of the binding will be notified here, of course.

massi

1 Like
964

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.

965

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).

966

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

967

Hi,

I figured out what is happening regarding the incorrect blind position reporting. It’s not a bug but a feature :slight_smile:

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 :slight_smile:

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 :slight_smile:

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
968

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 !!!

969

It must be the second option then :wink: I’ve change the password.
Thanks for the binding :slight_smile:

970

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.