No… If your items are correct in the items file then they will be already linked. Sometimes I need to refresh the browser to see the link. If its not linked check your items config is correct. Use the copy function next to the channel.That copies the details that should be in the item definition. Compare that with what you have for channel= for the item
Tip… In PaperUI items … if a trash can is shown then these are the PaperUI defined items and can be deleted. If you have accidentally duplicated PaperUI items in your items config file then you can delete a PaperUI item to reveal the hidden duplicated config defined item. Trash can disappears. This tip doesn’t work for things.
Mark very good tip, i tracked some syntax error this way, the other tip is to use logs, error are described with line and characters is the log.
It starts to work know, i have to track some other error, but switch and shutter is working, still having problems with dimmer sliders and thermostat
In like the spirit of collaboration and especially the valuable help that @m4rk, @stefan and others are giving here. The OH community is a great resource!
However we need to keep things tidy here!!
This thread is about evaluating and debugging the OpenWebNet / BTicino binding and not a general help forum for your personal items and configuration files syntax, or for Google Home integration problems : there are areas in the community for this and even Personal Messages (PM) can be used. You can always start a new thread !
Always ask yourself : are all other users in this thread interested?
Is this info already present in the OH docs?
(Some of the latest 10 questions were already well explained in the general openHAB documentation… use Google search first!!!)
So I suggest you stop this right now and use this thread exclusively for problems related to the binding configuration with bus/radio devices in your plant and configuration of BTicino gateways, and malfunctions in general.
I will mark for moderation and removal further help requests about generic item / things files syntax or Google Home wrong configurations.
Bye
Massi
Massi,
Sorry, this is mainly my fault, maybe we should start another threat about configuration of this binding.
I can assure you i did read the documentation page and others about 10 time, but for a noob it’s really not crystal clear.
Anyway i can partialy agree with you.
As i have the binding almost fully funtional now, i wil be able to evaluate and debug in the coming weeks.
regards
Hi Massi, great work on this!
I worked on a 1.9 version of the binding a while ago and I managed to get CEN+ (WHO=25) working. This is really useful for linking BTicino switches to Openhab rules. For example using a long press on a switch you can turn on music etc…
I’ve finally upgraded to Openhab 2 so it would be great if we could get CEN+ put into your binding. It is not much different from Lighting (WHO=1).
The only strange thing is that “where” appends a 2 in front of the CEN number you assign in BTicino. So in the example below the switch is CEN 49. For “what” there are 4 options short press, long press, extended press and release.
Switch shower_short_2 "Turn on Shower Lights" (gCen) {bticino="if=webserver;who=25;what=21#2;where=249"}
Switch shower_long_2 "Turn on Shower Music" (gCen){bticino="if=webserver;who=25;what=22#2;where=249"}
Switch shower_ext_2"Button 2 continued"(gCen) {bticino="if=webserver;who=25;what=23#2;where=249"}
Switch shower_short_release_2 "Button 2 released" (gCen) {bticino="if=webserver;who=25;what=24#2;where=249"}
If you need some help let me know!
Hallo Julian,
Always nice to hear about some help offer!!
(btw: I am offline from coding these weeks due to some very time consuming personal -and happy- family matter 
!)
Did you think about how to discover CEN devices? In binding v2 discovery is really important.
So first help from you would be to find a proper way to discover CEN things.
Once discovery is there, the rest is pretty straightforward to implement.
We can exchange ideas in PMs and if you really like to contribute you could self assign the related issue in github and provide a push request on the repo.
Let’s keep in touch!
Bye
Massi
first of all congratulations massimo to your family matter!
for the cen and cen-plus commands i would think there is nothing to discover. the commands are sent for example from switches, contacts or from domotica-app, they are received from a mh200n and start some action there.
i wrote many “programms” for my mh200n that are started from cen or cen-plus commands: open garage and close automatically as soon as the light-barrier is interrupted, close rollershutters as soon as outside light reaches a minimum level, let blink a light in my office as soon as my wife opens the rollershutter in the morning to tell me its time to bring her some coffe 
and many other gadgets…
so i would only need a pushbutton that i can assign a cen-command
bye, stefan
Congrats…
Regarding CEN and CEN+ Same here, I can’t activate most of my scenarios with Openhab. Some scenarios I configured to respond to dummy, unused actuators; but that’s a costly work around I use only for the important ones.
Same applies to contacts interfaces. I have several sensors, alarm and door relays. The relay state is sensed using the BUS basic contact interfaces. Scenarios can respond changes and Screen10 shows the contact states but without Openhab supoprt for these things then my Openhab use is always ‘limited’ and I have to use other apps and panels.
Ciao Mark
Congratulations Massi!
I agree with stefan that discovery it not really necessary although I guess it would be nice. I am not that good at programming I just played around with the existing OH1 binding to add the CEN+ functions.
I am currently still using the 1.9 binding which works fine with Openhab 2 and gives me CEN+ functions. It would be nice though to get everything into a single OH2 binding
If you want to use the old binding let me know…I can post it somewhere!
Sorry Massi I’m sorry if you got angry even for my request for help on google home.
My request was to understand if your binding natively supports the Google Home “tags” or not (in your documentation it’s not explained) . And eventually if it was possible to integrate them in the next releases
HI @Alberto_C, yes the correct tags for alexa/google home are included in the discovered things and auto-generated items. So in automatic mode and after the first discovery the openwebnet added devices should be visilble to google home (after completing the my openhab and google home cloud config and linking, of course).
bye
Massi
Ok, thanks. This is tested? Because I read in this forum that Google Home tags don’t work if they are added from PaperUi.
I have found a solution with @jpcolin help.
In the all items tags it’s not present [“Lighting”]
I have added this tag with REST API and now the light items are visible on Google Home
@bastler, @m4rk, @Julian_Divett
regarding the CEN integration:
the logic in the OH2 binding is that for each
1 WHERE --corresponds–> 1 Thing
1 Thing --corresponds–> N Channels
each Channel --corresponds–> 1 Item of type: Switch, Number, String, etc.
in the case of CEN we have one button --> 1 WHERE, that can generate different interactions (short press, long press, etc).
We have two options:
- have a different Switch (on/off) channel for each type of interaction (this I do not like too much), pretty much like it is now in the OH 1.x binding, if I understood correctly from Julian
- have one single String channel that can rapidly change its state and be valued “short_press”, “long_press” etc. or “no_action” if nothing is happening to the button.
Which would you see better of the 2 options?
Massi
hi massimo,
you´re great, integration of cen/cenplus will be a big improvement for
this binding, thanks in advance!
if i understand right:
-
the “switch” option would result two cen-commands, one for “on” and
one for “off” - this is often not a good thing, because many cenarios
don´t have two states needed. -
the “string” is what you already used in thermo for “mode”. do you
think it is possible to offer both variations as youd did in thermo?
one is to send only 1 action, this is good for cens that only need to be
activated. for example: open garage and close automatically when
lightbarier is interupted
the other variation is to open a list and choose a cenario. that would
be perfect for cenarios that have to be startet, stopped, send
additional commands. for example: internetradio needs 4 cen-commands:
start, stop, vol+, vol-
if not both variations are possible to realize the i would prefer the
“easier one” that sends just one cen-command.
how do the others think about that?
bye, stefan
I agree Stefan - the CEN+ functionality really requires rules for it to be useful. I think having it as a Switch would be too restrictive. The best would be to have single commands that can be attributed to the various button presses.
Massi I don’t understand what you mean by having “no_action”. According to the Openwebnet documentation these are the types of press:
Virtual short pressure (<0.5sec) *25*21
Virtual start of extended pressure (>=0.5sec) *25*22
Virtual extended pressure *25*23
Virtual release after extended pressure *25*24
In practice this means either a short or a long press
If you want to do some dimming or volume changing then picking up the Virtual extended pressure frame would be useful.
I’m not sure of a used case for the Virtual release after exended pressure?
I’m still new to Openhab 2 but I guess we are talking about channels for each of these frames?
I’m new to openhab also, so sorry if i’m wrong but do Cen and Cen+ have a state?
I sure that Bticino commands don’t reflect the stat of a CEN (light on the button does not stay on when a CEN is activated on my installation.
CEN+ just sends a frame so you need to capture that - you can’t query the state, there may be a way to store it somewhere in the bus but I’m not aware of one. That’s why you really need to use rules where you can store the state if needed.