[BTicino/OpenWebNet] New openHAB2 binding ready for testing

Did you read the readme?
Either you installed the wrong binding or you are posting on the wrong thread…

In the First post of this thread you find the instructions for the installation:

Thank you

1 Like


Hi, Remember that when were testing I found that just one dimmer on a F429 DALI gateway never gets discovered but I can operate it OK when I add it manually into items and things.

Now I’ve noticed that if the same dimmer is commanded to go OFF using a BTicino group command then the binding doesn’t detect it even though it has actually turned off.

To test further… In the dimmer config I swapped the problem light address in module 2 of the dimmer to another module and found that the problem stays with the module and not the address. Module 2 of the dimmer always has a problem with the binding discovery and group commands.

I don’t see any clues in the logs for the group command but I do see the OWN commands for the light with ON, OFF ,dimming etc
eg after sending group OFF via CEN Isee most lights go off but not address 9.2 in module 2 of the DALI dimmer. The others connected to the DALI dimmer do turn off. See addreses 9.x below

2020-02-07 17:29:48.792 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*91##

2020-02-07 17:29:48.831 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*15##

2020-02-07 17:29:48.862 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*26##

2020-02-07 17:29:48.902 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*96##

2020-02-07 17:29:48.949 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*16##

2020-02-07 17:29:48.988 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*97##

2020-02-07 17:29:49.027 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*17##

2020-02-07 17:29:49.066 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*93##

2020-02-07 17:29:49.105 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*94##

2020-02-07 17:29:49.137 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*#1##

2020-02-07 17:29:49.153 [INFO ] [org.openwebnet.OpenGatewayBus$a     ] - MON RECEIVED  <<<<<<<<<<< *1*0*18##

HI community,

Thanks for all the explanation and support in this thread, I successfully managed to get my Bticino integration working.
One question:

How do I integrate wind and rain control (including rules) for my markise steered by a normal rollershutter F411U2?

I’ve found this thread, but all samples and rules are missing… I have no plan, could someone help me please?

Thanks, Christian

I am using the same sensors as in the thread you posted. Eltako wind, rain , light sensor with the matching relay. If its mission critical eg storm protection, then I would not use openHAB rules to drive the blinds in these situations but I would do it with a BUS scenario controller or point to point. openHAB is great but it is actively developed and problems can arise. Sometimes it’s not even openHAB’s fault eg SD card fail.

In the thread you linked to they are using a z wave component to link the weather sensors to openHAB but as you have a BUS system you could link them directly to the BUS; if you can run a cable from the relays to the nearest bus cable.

If you do decide to connect the Eltako sensors to the BTicino BUS you additionally need for the interaction with the BUS a contact sensor eg F428 for din rail mounting, there is a smaller in wall version too. The contact sensor communicates the state of the Eltako relay, open/closed, via the BUS. Then there is no need for the z wave component unless its a must due to BUS connection being too difficult. I have one cable to the weather sensors for both power and the sensor communication to the relay and this connects to my rack where the BUS, Eltako relay and power supply, and house electrics are all located.

With BUS contact sensors you can then choose either to use openHAB rules, point to point, or BUS scenario controller as the means to operate the blinds.

Also, nice to have are independent weather sensors for checking the eltako calibration, backup and for monitoring local weather trends for generating email warnings etc via openHAB. The eltako sensors are good but are just limit switches and so there is no warning if it’s getting windy. The rain sensor is very reactive and can, although rarely, false alarm, eg condensation from mist, very light rain, bird poop. It doesn’t tell you how much rain fell either.

Where I live thunderstorms are common and can come suddenly with a very strong wind front. I also have the advantage that I can see the storm fronts approaching from my office.

So, I also use cheap mobile-alerts sensors integrated into openHAB. I then get warnings if it’s getting blustery before the eltako reaches its limit. I can then decide to remotely retract the blinds instead of waiting for the wind limit switch to kick in. See this thread for more details; especially later in the thread as I developed some ideas.

The wind sensor can be too late for sudden squalls but the rain sensor can additionally be used to retract blinds before the wind arrives. I don’t have the blinds down if it’s raining anyway and there is usually some rain around before a wind front hits. In these situations it’s useful to have the light sensor to decide if protection from sun is still necessary or not.

I use the light sensor to automatically drive the blinds down in the evening and open up in the morning; also as wake up call depending on the sunrise times. I added an override option for the days outside the usually workday routine.

With openHAB you can derrive a third light sensor state. DULL = not dark and also not bright. Together with internal temperature sensors the ‘system’ decides if the blinds should close or if the sun energy would be a useful supplement to the heating. The degree of blind closing is also variable depending on the conditions.

My main aim for blind control utilising weather and temperature sensors is to keep the blinds open as long as possible for energy saving while protecting the house from overheating, protecting the blinds from high winds, hail, and very importantly to keep me and my many indoor plants happy by aiming for a bright and cheerful house ambience and not a dark and gloomy cave dwelling. I now have almost no interaction the blinds on regular days. Its fully automatic. Only on days off do I choose to take over anything and that’s because I want to decide how long I want to lie in :grinning:

Sorry for the long wordy post. I just wanted to convey some ideas and I have don’t have many openHAB rules to post as I did it most of the critical control via mh202 BUS scenario controller.

Ps if you have patio blinds don’t forget some form of lock out to stop the blinds unexpectedly coming down while you are on the patio. Also, I implemented a master override which stops all routines running. This is for safety when cleaning or working on the blinds. You could cut the power too I suppose but its not as easy as a button push in the openHAB phone app :grin:

Pps… with openHAB you can add voice announcements to inform the occupants why the blinds suddenly moved :grin::grin::grin::grin:

Ppps… even relatively low wind speeds can bend blind blades over a long period of time. Bent blades means poor light seal.

Pppps… all of the above depends somewhat on your blind type… shutters with no blade control, blinds with blade control etc.

Hi Mark,

Thank you for your explanation, and the time you spent for this.
Initially I had a GSW2 from Schalk with a Mistral V2 18A009 wind sensor.
The GSW2 sind the impulse to a Legrand 047042 Time Module, to be able to set a time out time, not triggering the F428 (I’m already using it), activating every few minutes the 3 F411U2 for the Markise (on a windy day or night).

I thought it would be more modern to implement such actions and rules thru openhab2, but propably your’re right - keep it short and simple, avoiding additional system failures as it can be critical if something fails.

I’ve just deactivated this setup, as I was not satisfied with the positioning of the wind sensor, but this was another story, we have some upwinds, I’m living in the mountains, which are not correctly detected by the wind sensor, the 3 12sqm Markise will be endanger in such a case.

You’re welcome.

As usual for me when writing I am also aware there is a wider, silent audience. So, I write for those too also knowing that I can point back to that long post if needed :wink:

I am also in the mountains with a very steep, forest covered, glacial morain behind my house. I am in Sth Austria. The steep forest mostly protects me from winds but sometimes also increases the wind effect. It depends on the direction of the wind. Another reason it’s useful to plot the wind speeds in Grafana is in order to understand the local effects. You don’t want to frequently over react but it must react when necessary. So, limit settings are key but with as little trial and error type adjustment as possible.

The simplest approach would be point to point control. I do not do this Next would be scenario control but without ‘only if’ conditions. This is the control method I use. Last would be openHAB.

openHAB is very good for monitoring events and actions, generating warnings and with Influx persistence it’s great for making charts for a long term statistical view of the trigger and BUS response. Then you can easilly check how the system is performing and if the warnings are timely you will get a chance to monitor live what happens during a critical event and manually intervene if necessary, or if your nerves get the better of you :grinning:

Just had my gateway (screen10) go offline for some uknown reason. A reboot of openHAB didn’t help but a reboot of the screen10 did. The screen 10 seemed to functioning normally.

I think its been asked before but couldn’t find it. Is there a way to set fall back, secondary, server in case primary one goes of line? I have a MH202 scenario controller that could also act as a gateway.

Also, would be nice of someone to post an example rule to send out notifications when a gateway goes offline. :slight_smile:

edit… I improved my code. Now it detects Offline gateway, sends an email alert and restarts the binding automatically.
See this post:

<<<<<<<<<< Old code removed >>>>>>>>>>

The first real offline event and notification

email received

I’m searching for an alarm system.
I would like to link to openhab 7 window magnetic contact (wired and already installed): there is any hardware linkable to openhab or bticino hardware like F482 or 3480 or Contact interfaces: F428 and 3477?

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

1 Like

I changed all my item definitions now so that I can easilly toggle from screen10 to MH202 by editing just the bridge definition.
Was using screen10 but now currently on MH202 as gateway and now I see these messages

2020-02-20 07:01:16.682 [WARN ] [penwebnet.message.OpenMessageFactory] - ##openwebnet## INVALID FRAME: *13*26##

2020-02-20 07:06:33.565 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*98*#13*0*100*12*0##> for thing openwebnet:bus_dimmer:gateway:98

2020-02-20 07:06:33.568 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*98*#4*100*12##> for thing openwebnet:bus_dimmer:gateway:98

2020-02-20 07:06:33.607 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*98*13*0*100**0##> for thing openwebnet:bus_dimmer:gateway:98

2020-02-20 07:06:33.611 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*98*4*100*0##> for thing openwebnet:bus_dimmer:gateway:98

2020-02-20 07:06:33.646 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*98*4*100*12##> for thing openwebnet:bus_dimmer:gateway:98

2020-02-20 07:06:33.664 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*98*13*0*150*12*0##> for thing openwebnet:bus_dimmer:gateway:98

2020-02-20 07:07:35.210 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*0414*#13*0*100*11*0##> for thing openwebnet:bus_dimmer:gateway:0414

2020-02-20 07:07:35.213 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*0414*#4*100*11##> for thing openwebnet:bus_dimmer:gateway:0414

2020-02-20 07:07:35.248 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*0414*4*100*11##> for thing openwebnet:bus_dimmer:gateway:0414

2020-02-20 07:07:35.257 [WARN ] [et.handler.OpenWebNetLightingHandler] - ==OWN:LightingHandler== updateLightBrightnessState() Cannot handle message <*#1*0414*13*0*200*11*0##> for thing openwebnet:bus_dimmer:gateway:0414

but no ‘gateway unreachable’ messages which i got sporadically with the screen10 as gateway.

The error above seems to have been an isolated event. Operating the affected lights doesn’t cause any issues now. I would do more testing of MH202 vs Screen10 as gateway but there is little point if Massimo is not around anymore. So I wait.

I am using both contact interfaces F428 and 3477 with BTicino MH202 and openHAB for detecting open/closed relays. Or are you asking for something else instead?

It’s detect magnetic contact like BTICINO 3510?

are used for an alarm central or is installed individually and configured on openhab?
can you describe your configuration please? I would like to buy an interface and control my main door in openhab and then in Alexa

I am not using them for the alarm contacts. I just use them for output relays. I keep my alarm and door actuators seperate from openHAB. I don’t want openHAB or Alexa to be able to control my security stuff.

I agree, I would to test it and only use alexa to say “Hello” for example…not for security alarm

Can you explain me your relay use?