[BTicino/OpenWebNet] New openHAB2 binding ready for testing

Hi Massi
it works!
I’ve removed all the old things clicking two times!

Thanks a lot!

Giuseppe

1 Like

I updated my openhab to the latest snapshot and then tried to reinstall the dependencies:

  • feature:install openhab-transport-serial
  • feature:install esh-io-transport-upnp

but I receive this error:
Error executing command: No matching features for esh-io-transport-upnp/0

so I am not able to see the binding anymore :pensive:
everything is UNINITIALIZED

Any suggestion?

is possible that feature esh-io-transport-upnp is not anymore correct and available il 2.5.0.SNAPSHOT.
I’ll have to check this. Meanwhile I suggest yo go back to OH 2.4.0 stable.

I was already on 2.5.0 snapshot (I suppose a different build)

I tried downgrading to a previous release and to 2.4 but I get and error: FAILED (apt)

I also tried the old “workaround” of installing the Modbus Binding but this time it’s not working :sob:

EDIT: l was able to restore an OH2 backup I made before the update, but I still get the same error when using * feature:install esh-io-transport-upnp

Try cleaning the cache, then return the two commands to karaf.
All your configuration is on file?

I cleared the cache with:
openhab-cli clean-cache

then restarted, reinstalled the binding and then and sent again both:

  • feature:install openhab-transport-serial
  • feature:install esh-io-transport-upnp

but still the same error

Just in case it happens to someone else, I solved by:
rolling back to 2.5.0 M1
cleared cache
reinstalled the binding 2.5.0 M2-1
installed the modbus binding
I had to go through Modbus installation because I got these errors using command lines:

openhab> feature:install openhab-transport-serial
Error executing command: Error restarting bundles:
        Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.eclipse.smarthome.io.rest.sse.
openhab> feature:install esh-io-transport-upnp
Error executing command: Error restarting bundles:
        Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.eclipse.smarthome.io.rest.sse.

Hi,

I was at ISE2019 and this year they wil be adding Alexa, Google Home and Homekit to the MHserver1

Did they announce what will be supported? Just Lights and Automation or all features (scenarios, thermo, energy, etc)?

I am happy that this binding will help all others that do not have a MyHOMEServer1 but still will be able to integrate assistants thanks to openHAB !
Massi

1 Like

Hi @massi,

I have a question regarding Netatmo devices (relay/valve). As you may know, Netatmo has been bought by Legrand and they have developed together (!) the new Living Now series. However, it seems that the integration with Myhome_up is not on their top list.

I own a set of Netatmo valves+relay. Alexa is present, also. My idea was to use OH (on a raspberry) as the supervisor of the whole home automation system. Thanks to the OWN Bticino binding I succeeded to integrate the Bticino system in openhab. I am using the OpenHab skill of Alexa to add voice control to OH. My Netatmo system is controlled via its own app and by Alexa (with Netatmo energy skill).

The Netatmo valve/relay system is suitable for apartments that have a central heating system where the user cannot control the daily and weekly heating schedule. Each valve works separately, reads room temperature and opens if its own scheduled temperature setting requires room heating.

Even if you do not have control on central heating you may want to stop heating in a room (or in the whole house) if you are not at home, and this system allows for it. You can superimpose your own daily and weekly time schedule (room by room) on the central one. The contrary (heat when the central heating system is off) is obviously not possible.
However, you don’t want to heat your home when no one (except the cat) is there and this can lead to some saving, too.

It is a bit strange to be able to control each valve from app or from alexa and not be able to do it from openhab. Indeed, a Netatmo binding is under development which connects to the Netatmo API, but it is at an early development stage (and the maintainer is looking for testers and developers)

Do you think there are chances to include Netatmo support in the OWN binding? Besides, will it be possible or it is better to work on a separate binding?

I do not see the reason for that given that 1) it’s another commercial system (even if the two companies are together now) , and 2) there is already another binding ongoing for Netatmo system.
Actually the roadmap should be to have the Netatmo binding maybe merged into a more general “works with Legrand” binding, if this is allowed from a legal/licence point of view.

Remember the openwebnet binding is about… “OpenWebNet” integration of gateways/devices that support OpenWebNet language. Integrating other APIs is the job of other bindings.

Massi

No no further details, i suppose lights, shutters and the latest thermostat (not the 99 zones).
It should be a firmware upgrade.

Of course your binding wil still be usefull for everyone! enven those with MHserver1.

1 Like

Massimo you’re right.
And your idea of a “works with Legrand” binding is very good, but this for later on i think.

To me it’s look that Legrand/Bticino is following the market in the easy way: they have a great domotic system with my home and Openwebnet, not with the KNX potential but not so expensive and quite easy to manage.
Instead of better integrating this bus system to the other worlds (Alexa ecc ecc) they tried other ways, more simple and commercial but not so powerfull and more similar to solutions already on the market (e.g.: Zwave based systems)
With Openhab and the Massimo binding we achived the powerfull of KNX with almost no costs, with no clouds connections if you want( so better security), with a lot of integrations of other connected things, with the strength of a bus system and with the only limit of yr fantasy thanks to OH.
Even with Alexa and GH integration the limit of myhomeserver1 will be always the same.

1 Like

You are right, the only downside is the reliability, i have regular disconection to the openhab cloud, so Alexa stops working. only solution i found restart the Rpi completely.
On my Myhome installation i never had any crash, bug, or had to restart anything.
Bu ti don’t think it’s related to the plugin.

Better to wait for the release of OH 2.5.0.M2, we talk about at least 2/3 months

Hi,

Some items that are specified in my items file still appear in the PaperUI inBox

eg

In Box looks like this:
image

but in items file I have :

Dimmer KitchenSpots_Brightness "Kitchen spots [%d %%]" <DimmableLight> (gAllLights) ["Lighting"] {channel="openwebnet:bus_dimmer:Screen10:94:brightness"}

The above is a light dimmer connected to F429 DALI with addresses 9.1 to 9.8. Oddly all the lights connected to that dimmer show in the inBox except one, 9.2, which is never found but works as its specified in the items file. @massi this is the infamous light 92 you already know about :slight_smile:

Its the same issue with these items for dimmer modules F417U2, F418U2
InBox:

image

Items file

F417U2 addresses 4.11, 4.12

Dimmer Chandelier_Brightness "Chandelier [%d %%]" <DimmableLight> (gAllLights) ["Lighting"] {channel="openwebnet:bus_dimmer:Screen10:0411:brightness"}

F418U2 addresses 4.13, 4.14

Dimmer GalleryLights_Brightness "Gallery lights [%d %%]" <DimmableLight> (gAllLights) ["Lighting"] {channel="openwebnet:bus_dimmer:Screen10:0413:brightness"}

Hello,

  • enter the parameter discoveryByActivation = “true” in your .things file, look README
Bridge openwebnet:bus_gateway:mybridge [ host="192.168.1.XX", port=20000, passwd="XXXX", discoveryByActivation="true" ] {
 }
  • Inbox deletes the things discovered WHERE = 91 and WHERE = 92.
  • Press the WHERE = 91
  • Press the WHERE = 92
  • See if they were created in Inbox
  • Attach the Screenshot Inbox
  • Attach the log in debug mode

Hi Mark, this is already identified as an issue and already solved in the next release.

Hi Massimo,

I think Mark identified two problems:

  1. That Issue # 30
  2. Incorrect and undiscovered discovery of dimmers