September 2020 is coming soon. There will be a new binding?
2 Likes
i try the new bidding from openhab [2.5.8] the gateway is online but all the items stay unkwow ? what i’m doing wrong ? back to the M3.jar and all is fine
2.5.8 ??? Where did you get that? I am just guessing but I think Massimo’s new binding with new library is soon/now available as part of the official openhab… but I don’t think it was working for everything yet. We have to wait for Massimo to explain what the options are and his plans for the binding.
from community and from ssh openhabian-config update stable
the link : https://community.openhab.org/t/openhab-2-5-8-release-discussion/104045
obviously whe need to wait … 
I guessed correclty 
Congratulations. I know it was a lot of work for you.
but only lighting is supported!!!
@massi, what are the plans for the old binding when it expires?
ps you have it supporting lightning 
… 
should be lighting 
with this release none (even light) work except the gateway F454…
so…on my setup…yes is true, i can’t tell for other ?
I don’t think there has been much user testing so far but I could be wrong. Again, we need Massi to explain his plans. Massi asked me not to post on the topic. I am not supposed to be saying much, sorry Massi but the silence is deafening.
ok i read nothing … and i know…nothing
1 Like
I think Massimo will be replying soon
Hallo
I am happy to announce that the openwebnet binding has been included in the official OH distribution starting from OpenHAB version 2.5.8, released by Kai yesterday.
This has been possibile after the long testing phase and with the support from all who helped testing.
It also required me to fully dedicate “all available OH time” to this goal:
- the underlying lib that enables communication with BTicino gateways has been rewritten from scratch and released as a new open source standalone project called “openwebnet4j”. This was the main time drain (=many many evenings dedicated to this project)
- the careful OH review process also required many changes to the binding code to reach the very high code quality required to be part of the official distribution
This is why the just released binding has only support for lighting (WHO=1): to simplify the submission and review process.
Here is the plan for the near future:
- as announced by Kai, there will be new 2.5.9 and 2.5.10 patch releases. The plan is to use these two releases to fix any bug with the binding and add Automation (WHO=2) before the end of the of year, and before OpenHAB 3.0 is released
- the openwebnet binding will be then ported to OH 3.0, contributing to the future of OpenHAB
- I will release a final version of the old testing binding that will “expire” by the end of the year. Please note that in any case the final testing binding will not be compatible with OH 3.0 and will not be further improved/maintained
Later on new features and WHOs will be added to the official binding according to: available time, contributions from other developers (always welcome! please show up, with real intentions!) and interest/commitment by users.
For those interested to test the official binding: just upgrade to OH 2.5.8, remove the old opewebnet binding from the addons folder (or (de)install it from marketplace), then install the new official binding.
Dependencies should be resolved automatically now, including the new needed Openwebnet4j lib.
All text configuration should remain the same (at least for the BUS systems).
In case things where added from PaperUI instead, I suggest you delete them and discover them again.
As said: only lights/dimmers will be discovered and controllable for now.
Bye
MASSIMO
7 Likes
if i understand right if i add item from PaperUi i need to recreate from PaperUi ? it is ?
in reality i don’t even know how to add item directly from things file, but is more portable…
Well!!!
Nice, thank you for the hard work!
Great news and congrats Massi!
I could surely provide help with some testing for different WHO (Lightning, Termo, Multimedia, Alarm-Burglar, etc.) and maybe as a contributor.
I have to wait to remove completely the beta binding, since the official one lacks a couple of needed WHO.
Marco
Same for me. I actually need to go on with the beta version, but I can test most of new WHOs you will support, expecially BurglarAlarm that is actually unsupported and I hope will be soon supported via AUX commands.
Thanks for your great job!
hello all,
of course it is not easy to check the new binging, but if everyone waits until all works - the developer will never get necessary feedback for the binding. i think it is a good idea to do it step by step - and it would be great if somebody would honorize the work of the developer and try to help at least with testing.
so i added the binding-openwebnet - 2.5.8 and detected following:
after installing, the autodiscovery found my mh200n, my f454 and my myhome-screen (mh4893) and added all to inbox.
then i created a things-file with f454 as bridge and some lights and dimmers the file contends:
Bridge openwebnet:bus_gateway:BticinoGateway [
host=my-ip,
passwd=my-pw,
discoveryByActivation=true
// discoveryByActivation=false
]{
Thing bus_dimmer EGFlur_Li "EGFlur_Li" @ "Lichter" [ where="45#4#01" ]
Thing bus_on_off_switch EGFlur_Dekolampe "EGFlur_Dekolampe" @ "Lichter" [ where="43#4#01" ]
next i switched EGFlur_Dekolampe on a physical switch on and off again. then i got this log:
2020-09-05 11:05:45.095 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Exception parsing WHAT of frame *1*34*03#4#01##: Unsupported WHAT: 34
2020-09-05 11:05:45.137 [INFO ] [ery.OpenWebNetDeviceDiscoveryService] - newDiscoveryResult() WHERE=w:03#4#01, deviceType=SCS_DIMMER_SWITCH
==> /var/log/openhab2/events.log <==
2020-09-05 11:05:45.220 [home.event.InboxAddedEvent] - Discovery Result with UID 'openwebnet:bus_dimmer:BticinoGateway:03h4h01' has been added.
==> /var/log/openhab2/openhab.log <==
2020-09-05 11:05:45.232 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'openwebnet:bus_dimmer:BticinoGateway:03h4h01' to inbox.
==> /var/log/openhab2/events.log <==
2020-09-05 11:05:45.599 [hingStatusInfoChangedEvent] - 'openwebnet:bus_on_off_switch:BticinoGateway:EGFlur_Dekolampe' changed from UNKNOWN: waiting state update... to ONLINE
what is strange: the where is “43#4#01” but in the inbox it was added as where=“03#4#01” - as you can also see in the logfile here
next i switched EGFlur_Li on a physical switch on and off again. then i got this log:
2020-09-05 11:12:47.454 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Exception parsing WHAT of frame *1*34*03#4#01##: Unsupported WHAT: 34
2020-09-05 11:12:47.472 [INFO ] [ery.OpenWebNetDeviceDiscoveryService] - newDiscoveryResult() WHERE=w:03#4#01, deviceType=SCS_DIMMER_SWITCH
==> /var/log/openhab2/events.log <==
2020-09-05 11:12:52.055 [hingStatusInfoChangedEvent] - 'openwebnet:bus_dimmer:BticinoGateway:EGFlur_Li' changed from UNKNOWN: waiting state update... to ONLINE
==> /var/log/openhab2/openhab.log <==
2020-09-05 11:12:52.364 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Exception parsing DIM of frame *#1*45#4#01*4*140*1##: Unsupported DIM: 4
2020-09-05 11:12:52.380 [WARN ] [et.handler.OpenWebNetLightingHandler] - updateLightBrightnessState() Cannot handle message <*#1*45#4#01*4*140*1##> for thing openwebnet:bus_dimmer:BticinoGateway:EGFlur_Li
2020-09-05 11:12:54.618 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Exception parsing DIM of frame *#1*45#4#01*4*100*1##: Unsupported DIM: 4
2020-09-05 11:12:54.630 [WARN ] [et.handler.OpenWebNetLightingHandler] - updateLightBrightnessState() Cannot handle message <*#1*45#4#01*4*100*1##> for thing openwebnet:bus_dimmer:BticinoGateway:EGFlur_Li
2020-09-05 11:12:55.476 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Exception parsing WHAT of frame *1*34*03#4#01##: Unsupported WHAT: 34
2020-09-05 11:12:55.499 [INFO ] [ery.OpenWebNetDeviceDiscoveryService] - newDiscoveryResult() WHERE=w:03#4#01, deviceType=SCS_DIMMER_SWITCH
and now i have only a dimmer (where=03#4#01) in the inbox
next i added a items-file and then i played around in paperui. i realized that when i slide the dimmer to a value not step10 then i always cuts the one position, for example when selecting 57 it doesn´t round but jumps to 50, no problem i think.
but when i slide the dimmer to a value below 20, it always jups back to 20;
2020-09-05 11:30:58.876 [ome.event.ItemCommandEvent] - Item 'iBuero_Li' received command 5
2020-09-05 11:30:59.001 [nt.ItemStatePredictedEvent] - iBuero_Li predicted to become 5
2020-09-05 11:30:59.129 [vent.ItemStateChangedEvent] - iBuero_Li changed from 70 to 5
2020-09-05 11:30:59.387 [vent.ItemStateChangedEvent] - iBuero_Li changed from 5 to 20
that i my first impressions, please let me know if i can do any other tests.
1 Like