[openWebNet/BTicino] openHAB3

read this and let me know
https://www.openhab.org/addons/bindings/openwebnet/#scenario-channels

Thanks, that works. I was originally also thinking about using CEN+ messages, but tried the A/PL route first, because I thought that would handle the general/area/group commands. Since I know now that those are not processed by the openHAB binding anyway that point is moot and CEN+ messages are probably a good way to implement it.

One more question about this:

For now I have tied the CEN+ thing in openHAB to a switch item with rules, so I need to create two rules for each device, one for ON and one for OFF - is there a more efficient way to tie the switch to the CEN+ messages?

And now to the next topic:

Also I am trying to find a way to model the general/area commands in openHAB and wanted to ask for advice on that as well.

I created a BTicino switch thing with WHERE=7 for area 7, and from that a switch item (“Lights Area 7 Switch”). That works fine, even in both directions. If press the BTicino switch for area 7 on/off, the item in openHAB is updated, and if I change the state of the switch in OH, an OWN message is generated and switches the lights in BTicino.

Then I created a group structure in openHAB, reflecting the General/Area groups:

Screenshot - 26_12_2022 , 11_39_33

And at last a rule, which should update the group if the switch changes its state:

However that rule does not work as I want it to. In BTicino I can trigger the area 7 OFF many times in a row. If lights have been turned off in the meantime, they will obviously be turned off. However, once the Lights_Area_7 Switch in openHAB is set to OFF, and receives another OFF command, it will not trigger the rule, not even with the “was updated” trigger.

Might that be a limitation/implementation issue with the binding again?

Do you have any better suggestion on how to implement this?

I thought about using the MH202 and CEN+ messages again, but then found that the MH202 can a) not use general/area/group messages as start objects and b) can only send CEN messages, not CEN+ messages. I might find workarounds for that, but would prefer to solve this in openHAB only and not have to program the MH202 as well.

i believe you need to start reading about other automation script in order to achieve step one why not try blocky ?? then for the other problem of updating a group i don’t quite get it. if all you want is that the group reflect the items inside of it read thishttps://www.openhab.org/docs/configuration/items.html#derive-group-state-from-member-items

Thanks, yes, I‘ll take a close look at blocky!

So, in our BTicino system we are using general, area and group commands but the openHAB binding does not process those and therefore the status of items in openHAB gets out of sync with BTicino.

So I wanted to catch the general/area/group commands in openHAB and then update all affected items.

This works to some extend, I can create things and items with e.g. WHERE=0 for general and WHERE=7 for area 7 and they work as long as I alternatively switch them ON and OFF in BTicino.

But a normal use case would be to use only OFF in BTicino. There is no point in switching ON all lights in the house, but it is useful to switch them all OFF. But here the binding/OpenHAB side does not seem to pass on the second, third or subsequent OFFs. If the status of the item/thing is already OFF, the rules based on the status do not trigger, regardless of what trigger I try (see my screenshot).

I guess I can move it to CEN/CEN+ but wanted to see first if I can find a solution that supports the native BTicino general/area/group commands. Our house is old and we still have some controls that do not support CEN/CEN+.

I have now also created an issue in GitHub to follow-up on this topic, I hope that is OK:

I gave up with openHAB controlled general and area commands a long time ago as the binding didn’t support it. I get openHAB to trigger MH202 scenarios which then trigger the BUS groups. I do use an all ON and all OFF. All ON is for when there is problem eg fire, burgler alarm. Then all lights, inside and out, can be commanded on via voice, phone or panel etc.

Info: I have just been adding some new buttons to my screen 10 touch screen and now see that I used scheduled scenarios CENplus to trigger rules in openHAB

Also, I read you found some odd, inconsistent behaviour with specific BUS addresses. I think this was similiar to what I found when using virtual addresses ie no physical switch. I capture the BUS command in openHAB for use as flags. I found certain address ranges worked and others didn’t. If I remember correctly area 7 didn’t work

1 Like

I have now also moved the group commands to CEN commands. I did not want to use CEN+, since some of our older physical controls and the MH202 cannot issue CEN+ commands.

Also I am done with integrating the new Shelly wireless actuators and controls with our BTicino system, again using CEN commands because of the issues with A/PL addresses that do not have a physical actuator.

And I even had the time to write another blog post about it. Hope it may be useful to some and appreciate any kind of comments and suggestions:

Good morning, continuing with my openHAB/BTicino integration quest, I would now like to trigger scenarios in BTicino from openHAB. As far as I can see the CEN/CEN+ Scenario Control things only go one way, receiving CEN/CEN+ messages and triggering an action in openHAB.

Is there also a way to send CEN/CEN+ messages from openHAB?

Edit: already found it in the documentation and will give it a try: OpenWebNet (BTicino/Legrand) - Bindings | openHAB

I am a bit stuck with that, maybe someone here can help?

The code in the link above looks like this:

    val actions = getActions("openwebnet","openwebnet:bus_cenplus_scenario_control:mybridge:212")
    actions.virtualPress("SHORT_PRESS", 5)

However, I am not sure how to get this to work. I am trying to run this in the Javascript-Addon environment (“application/javascript;version=ECMAScript-2021”).

Does the getActions() refer to an existing Thing, or should this work without a Thing? It seems the getActions() function does not exist on its own but Things do have a method getActions(). However, the actions I get from one of the CEN-Things does not have a method virtualPress().

Is anyone using CEN messages from scripting and can enlighten me on how to get this to work? :slight_smile:

what is the “212” in your code? i think there you should write the thing that you associated to the cen command

an example from an old dsl-rule that i no longer use, but i hope it works:

things-file:

bus_cen_scenario_control      Cen_MorgenFeiertag          "Cen_MorgenFeiertag"            @ "Cen/CenPlus" [ where="10#4#01", buttons="1,2" ]

rules-file

rule "send cen"
    when
        Item ivi received command

    then
        logInfo("send cen", "proxy item received command")
        val cenActions = getActions("openwebnet","openwebnet:bus_cen_scenario_control:bticino:Cen_MorgenFeiertag")
        switch (ivi.state){
            case ON:{
                cenActions.virtualPress("START_PRESS", 1)    // send "START_PRESS" to button 1
            }
            case OFF:{
                cenActions.virtualPress("START_PRESS", 2)    // send "START_PRESS" to button 2
            }
        }
    end

you should pass as second parameter to getActions an existing Thing of type CEN/CEN+, like in the example (openwebnet:bus_cenplus_scenario_control:mybridge:212 is a bus_cenplus_scenario thing).
The virtualPress() method should be available for both CEN and CEN+.

@massi , @bastler thanks for your response!

OK, understand. But I fail already at getActions(), the function does not seem to be available in my environment:

2022-12-31 11:54:03.234 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: "getActions" is not defined

Do I need to include any libraries or something to get it?

OK, got it already, in Javascript I need to go via the actions object. This code works for me:

var cen = actions.get("openwebnet", "<thing_uid>");
cen.virtualPress("START_PRESS", 2);

And now thanks to this, Alexa is able to call up my scenarios from the MH202. I am really amazed how easy all of this comes together. :partying_face:

cool :sunglasses:
how to you connect the Alexa command to the activation of your script that in turn activates the MH202 CEN scenario via virtualPress ?

Basically I have non-semantic Items that are connected to Alexa by adding the Alexa metadata and rules that react to commands sent to those items. I am using either Items of type Switch with the Alexa device type Light, or Items of type String with the Alexa device type Scene, both works fine.

Also of course you can switch single lights, group of lights or other devices by just adding the Alexa metadata to them in openHAB.

I think I will write another blog article about it anyway. :grinning:

2 Likes

Done:

As always, any thoughts and comments are appreciated!

2 Likes

Hi Robert,

Thanks for your contributions. :+1: I added your two latest blogs to the list of useful links.

I have voice control but have a more general approach. Note: I always use text files for configuration.

I set an Alexa tag as mode control on a proxy item. Then you can command Alexa to set the proxy item to any ‘mode’ you want. The change of mode for a proxy item can then trigger and openHAB rule and even detect what mode was requested.

Group NorthLights                                   "North lights"                                                                              {alexa="Endpoint.LIGHT"}
    String NorthLights_Command                      "North lights command [%s]"                                     (NorthLights)               {alexa="ModeController.mode" [supportedModes="ON=ON,OFF=OFF,CONSTANT=CONSTANT"], expire="4h,command=NORMAL"}
    Switch NorthLights_Switch                       "North lights switch"                       <light>             (NorthLights, gAllLights)   {alexa="PowerController.powerState", channel="openwebnet:bus_on_off_switch:gateway:22:switch"}

To make voice commands more natural I also create an Alexa routine that translates a nice phrase or multiple phrases to the ‘mode’ . This also means you can create nice Alexa voice responses to your command for a mode to be set and direct the response to different Alexas. A further refinement is to create an Alexa openHAB device as a group with various capabilities. Then when setting up the routine you are presented the capbilities and the options for the grouped device.

You get Alexa to run any device or scenario this way using more natural phrases

If like me you have various ways to trigger the openHAB rule then the following is useful to log which item triggered the rule

import org.openhab.core.model.script.ScriptServiceUtil

rule "Outside north lights"
when
    Channel "openwebnet:bus_cenplus_scenario_control:gateway:CENPLUS10:button#25" triggered //Screen10 SHORT_PRESS
    or Item NorthLights4hrs_CENplus_proxy received command 'PRESSED' //Sitemap
    or Item NorthLights_Command received command 'CONSTANT' //Alexa command
then

    val list = ScriptServiceUtil.getItemRegistry.getItems(triggeringItemName)
    val triggering_item = list.get(0)	
    logInfo('Lights', 'Triggering item = ' + triggering_item.label.toString )
    if (receivedCommand == "CONSTANT") {
        logInfo("Alexa" , 'North lights voice command received: '+  receivedCommand)
    }
    logInfo("Lights" , 'Outside north lights constant mode started')


.............do stuff...............

Log for voice command

2023-01-01 12:23:02.126 [INFO ] [org.openhab.core.model.script.Lights] - Triggering item = North lights command

2023-01-01 12:23:02.128 [INFO ] [org.openhab.core.model.script.Alexa ] - North lights voice command received: CONSTANT

2023-01-01 12:23:02.129 [INFO ] [org.openhab.core.model.script.Lights] - Outside north lights constant mode started
1 Like

I can investigate further, but I think the current behavior is correct and coherent: if you switch OFF an address on the BUS, and it changes state ON → OFF, and then switch it again to OFF since the state is not changed on the hardware side, this will not generate any state update on the switch channel and therefore on any associated item (or fire an updated trigger on any rule associated to the item)

Yes, what you are saying makes sense for normal addresses with an actuator. But what I have been trying is to process group commands (e.g. WHERE=0 for general or WHERE=7 for area 7), and for those there is no state, and an OFF can be followed by another OFF, which still would need some processing.