[openWebNet/BTicino] openHAB3

[scarpy (Alex)]

@massi

right now the openwebnet binding supports reading instant power but not energy values.
According to the openwebnet documentation there is the possibility to read also statistics about energy. However this is not in the immediate roadmap, need a volounteer developer.

Ciao Massimo!
I’d like to help with F522 energy values readings…

[massi (Massimo)]

@scarpy

Ciao Massimo!
I’d like to help with F522 energy values readings…

ok, good! then write me a PM so we can discuss some ideas

[Alessandro_Cofanelli (Alessandro)]

HI,
thank you for the fantastic work done with this binding.
I’ve found a strange behaviour on the alarm channel (bus_alarm_zone) that’s supposed to be a bug.
This channel should have SILENT , INTRUSION , TAMPERING or ANTI_PANIC value when the specific zone have an alarm, ‘NULL’ otherwise.
Instead it remain in the alarm status (INTRUSION for example) after the alarm has been disengaged or newly engaged.
Status can obviously be set back to NULL with an expire on the item or a rule/script but i don’t know if this is the expected behaviour.

Thank you.

[the-ninth (Robert)]

Today I have been moving from lights to shutters and imported my first two shutters into openHAB. The binding seems to work great again in that regard, I really like the auto calibration feature, it seems a lot of thought went into this.

Also it seems that - in contrast to the lights - for shutters the group commands are not an issue. Even if controlling the shutters from BTicino via group commands, openHAB shows the correct status/opening percentage. I guess in case of shutters, they provide individual status updates on the bus, even if controlled by group commands?

[the-ninth (Robert)]

@m4rk

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.

That sounds like pretty advanced Alexa-stuff.

So with the Alexa device type “Mode Controller” you can define a list of modes yourself? How are the actual voice commands that can then be used to set the mode?

@m4rk

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.

Those routines are a pure Alexa function, right? So they are setup via the Alexa app, without involvement of a configuration in openHAB?

@m4rk

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.

Not sure if I understand that, what is a group with various capabilities? Does that mean to have Points in it of different types? Or assign multiple Alexa device types?

[m4rk (Mark)]

@the-ninth

So with the Alexa device type “Mode Controller” you can define a list of modes yourself? How are the actual voice commands that can then be used to set the mode?

A ‘mode’ is any text you want to represent some action and there can be some translation done by the Alexa syntax too eg Full cycle = mode 1, ON etc. At the moment I usually set an routine to respond to the phrase I like to use but natively it should respond to some simple phrases like … Set to command or something like that.

Another approach is to capture the spoken phrase to Alexa and then use openHAB regex to decipher what was said and take the appropriate action and even speak back on the Alexa used. I do this for my garage door operations which require quite a bit of extra coding and sensors to track the door state.

@the-ninth

Those routines are a pure Alexa function, right? So they are setup via the Alexa app, without involvement of a configuration in openHAB?

Yes, routines are pure Alexa app. You can get Alexa to respond to any phrase you like and then do stuff.

@the-ninth

Not sure if I understand that, what is a group with various capabilities? Does that mean to have Points in it of different types? Or assign multiple Alexa device types?

Group is a collection of capbilities(OH items with Alexa taggging) for a device eg you could have thermostat group that has the capbalities of ‘setpoint’ and ‘current temperature’ as defined by OH items. This affects how the thermosat is displayed in the Alexa app. As group it is displayed as one device that shows the setpoint temperature and below it the current temperature. It also responds in a more natural way to voice commands as one device.

There is lot more than I have tested yet and I am in the process of fine tuning and expanding the voice control. But once you get past tipping point then voice command or queries becomes the easiest way to control things, lights, blinds, thermostats and other things that are not in OH. Testing on my 86 year old Mum who was already used to an Alexa at her house and it seems that guests to my house quickly get used to it…they don’t need to use an app or figure how to turn things on/off , which wall switch, what does what etc etc. They just ask Alexa to do it and it works; most of the time

The link below is the link to the general capabilities section of the Alexa skill but the post contains a lot more >>

openHAB Skill For Amazon Alexa

Here is an example of Alexa controling openwebnet blind

Rollershutter WestBedroomWest_RollerShutter         "Bedroom West blind [%d %%]"        <blinds>            (gAllBlinds) {
    alexa="Blind.RangeValue" [inverted=false,supportedCommands="UP=@Value.Up:@Value.Open,DOWN=@Value.Down:@Value.Close,STOP=@Value.Stop", supportedRange="0:100:1", unitOfMeasure="Percent", actionMappings="Close=DOWN,Open=UP,Lower=(+5),Raise=(-5)", stateMappings="Closed=100,Open=0:99"],
    channel="openwebnet:bus_automation:gateway:65:shutter" 

With this anyone can command a blind to close, open, stop and go to a set % position. It also allows natively requests like ‘lower’ or ‘raise’ and then the blinds will move fixed %, as set in the syntax. I set +/- 5%.

A further step to make it work more easily for everyone is Alexa room awarness. With that then the Alexa knows which room it is in and responds more intelligently to requests like ‘switch the light ON’ ie it assumes you mean the one for the room its in and there is no need to give the specific item name.

All this is just the icing on the cake for my automation to work but actually was my orginal goal >>>to make the automation work mostly without intervention but when something needs to be done it should be intuitive and no need to know my system nor be an expert in my way of doing things.

This last effort comes towards the end of a long road of integration and I am still working on it. So, I would appreciate some discussions with others on how to do it the best way etc, motivation to explore alternative methods etc. I seem to one of a very few going this way and talking about it.

edit… The Alexa room awareness feature only works fully for lights and its been that way fro a long time. It partially works for blinds. Raise and lower commands work but open and close do not. So,there is a workaround posted in the community by the Alexa skill developer and I created my own rule I specifically made to operate my openwebnet blinds which I amy expand to operate other items. It is working well for openwebnet BUS blinds

This means anyone can command a light or blind without knowing the specific Alexa names of the devices. eg guests. The Alexa in the room that receives the command ‘knows’ which are the correct lights or blinds to operate. I will post my code if anyone asks but will move discussion to the general thread

[m4rk (Mark)]

H,

I noticed that the thermo unit atLeastOneProbeManual channel detects when I set a zone to manual but doesn’t update when it is back in automode, the Item remains as ‘ON’ even though central unit doesn’t show any zones as manual.

Is that just me or anyone else?

[bastler (stefan)]

to be honest i dont understand the working of the channels atLeastOneProbeOff, atLeastOneProbeManual and atLeastOneProbeProtection as they are sometimes ON even that seems not correct for me but i could not find out how they work.

for example now i went to the cu, confirmed my standard mode programm (=automatic) but all three channes stay ON although they should all be OFF in my opinion (the red lines only appear when switched ON)

i am also still missing the possibillity to switch a zone not only to manual but then back to auto

[m4rk (Mark)]

As I understand it when one zone is in manual or off or frost protection then the relevant channel switch changes to ON. This is the same as the CU showing the symbol for those conditions.

Manual is set on the CU as a fixed temperature and not on the zone offset on the wall mounted thermosats.

Another way to get a zone into manual is to use the Alexa app and change the target temperature.

The switches are read only and although I can manually put them back to the correct state it generates an error

handleChannelCommand() Unsupported ChannelUID atLeastOneProbeManual

[the-ninth (Robert)]

@m4rk

This last effort comes towards the end of a long road of integration and I am still working on it. So, I would appreciate some discussions with others on how to do it the best way etc, motivation to explore alternative methods etc. I seem to one of a very few going this way and talking about it.

Thanks for the inspirations - I am not sure yet how far my road of integration will take me, still being at the basics. Next comes a weather station, with wind sensor for bringing up the shutters and then I’d like to integrate our car gate so I can control it from BTicino controls .

With Alexa I also have to yet see how far I want to take it - so far I only have BTicino scenarios linked with Alexa, but I’d like to start with individual lights next and see how well that goes - will for sure try to make it work with that room awareness feature that you mentioned.

[m4rk (Mark)]

I have a weather station, as well as wind, rain and sun switches setup. I use some BTicino contacts sensors, I also have my electric garage door integrated, again using contact sensors. If you want to discuss please use the general thread unless its binding specific.

[the-ninth (Robert)]

Good morning,

I am back with a question about shutters and their state.

I am now using a non-semantic group hierarchy where I put all my shutters to send them commands. All the groups have member base type Rollershutter and AVG as aggregation function.

• After I reboot openHAB, the state of all the shutters and groups is UNDEF, as expected.

• If I then send an UP command to the top level group (the “house”), its state changes to “0”, also as expected.

• However, the sub-groups stay at UNDEF, which I’d expect to be set to 0 as well.

• Then also the top level group status changes back to UNDEF after 20-30 seconds. Looks like the aggregation function kicks in and overwrites the top level status again with the UNDEF in which the sub-groups still are.

Is this a bug? Shouldn’t the UP to the top-level group also set the state of all the sub-groups to 0?

In this state I also cannot send a percentage command to the shutters, it will give me the following error, which is probably because the state is still UNDEF:

2023-01-11 05:42:05.755 [INFO ] [.handler.OpenWebNetAutomationHandler] - Command 10 cannot be executed: unknown position or shutterRun configuration params not/wrongly set (thing=openwebnet:bus_automation:22eef285a7:51)

What is the best way to bring the shutters in a defined state after a reboot of openHAB?

[the-ninth (Robert)]

@the-ninth

Then also the top level group status changes back to UNDEF after 20-30 seconds. Looks like the aggregation function kicks in and overwrites the top level status again with the UNDEF in which the sub-groups still are.

The problem seems to occur also on the level of individual shutters. If after the reboot I execute the following code, the state will first go to 0, but then after 20-30 second go back to UNDEF. Shutter_OG_AO_Roller_Shutter is a Point representing an individual shutter.

var shutters = items.getItem( "Shutter_OG_AO_Roller_Shutter" );
shutters.sendCommand( "UP" );
shutters.postUpdate( "0" );

What could be the cause of the shutter state to change back to UNDEF after some time?

[massi (Massimo)]

@the-ninth

The problem seems to occur also on the level of individual shutters.

Groups are not directly handled by the binding but by the OH core.
But if the item value goes back to UNDEF after a while in the single shutter, than something is wrong either in the configuration or in the binding.
It would be useful to see the log ( DEBUG level) when you send the UP command after a reboot, and the thing+item configurations.

[the-ninth (Robert)]

@massi

But if the item value goes back to UNDEF after a while in the single shutter, than something is wrong either in the configuration or in the binding.

I can reproduce that, so the issue seems to really happen on item level.

If I set the log to debug, there are so many entries I do not really know what to send. Is there a way to limit the debug level to the OWN binding?

Here is my Thing:

UID: openwebnet:bus_automation:22eef285a7:51
label: Rollladen OG AO
thingTypeUID: openwebnet:bus_automation
configuration:
  where: "51"
  shutterRun: "61540"
bridgeUID: openwebnet:bus_gateway:22eef285a7

And here my Item:

[massi (Massimo)]

@the-ninth

If I set the log to debug, there are so many entries I do not really know what to send. Is there a way to limit the debug level to the OWN binding?

You should set the DEBUG level just for then OpenWebNet binding.
See instructions here.
Then just copy-paste in a .txt file the log from when you sent the command to the single shutter (after a reboot), and attach the file here

[the-ninth (Robert)]

@massi

Then just copy-paste in a .txt file the log from when you sent the command to the single shutter (after a reboot), and attach the file here

Great, thanks, here is the file:

Shutter_UNDEF_Debug_Log.txt (18.8 KB)

I appended my code to add some log entries that show where the problem occurs, the log starts with:

*** ShutterTest: Sending UP ***

And ends when the state changes back to UNDEF:

*** ShutterTest: State now UNDEF ***

Here is the code I used:

console.info( "*** ShutterTest: Sending UP *** ")
var shutters = items.getItem( "Shutter_OG_AO_Roller_Shutter" );
shutters.sendCommand( "UP" );
shutters.postUpdate( "0" );

java.lang.Thread.sleep(5000);

while( shutters.state == 0 )
  {
    java.lang.Thread.sleep(1000);
    console.info( "*** ShutterTest: State still 0 *** ")
  }

console.info( "*** ShutterTest: State now " + shutters.state + " *** ")

What seems to happen before the state goes back to UNDEF is this:

2023-01-11 07:15:43.605 [INFO ] [nhab.automation.script.ui.1d9969a35d] - *** ShutterTest: State still 0 *** 
2023-01-11 07:15:44.022 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 07:15:44.022 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 07:15:44.023 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - handleMessage(<*2*0*51##>) for thing: openwebnet:bus_automation:22eef285a7:51
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - updateAutomationState() - msg=<*2*0*51##> what=STOP
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # current positionEstimation=-1 movedTime=60943
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movedSteps: 99 UP(-)
2023-01-11 07:15:44.024 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movingState=0 positionEstimation=-1 - calibrating=-1 shutterRun=61540
2023-01-11 07:15:44.041 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 07:15:44.042 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 07:15:44.042 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 07:15:44.043 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownId=2.51 has NO DEVICE associated, ignoring it
2023-01-11 07:15:44.606 [INFO ] [nhab.automation.script.ui.1d9969a35d] - *** ShutterTest: State still 0 *** 
2023-01-11 07:15:44.607 [INFO ] [nhab.automation.script.ui.1d9969a35d] - *** ShutterTest: State now UNDEF *** 

However, since there is another of my entries showing the state as 0 before it goes to UNDEF, I am not sure if the OWN log entries before that are really the cause or unrelated.

[the-ninth (Robert)]

@the-ninth

However, since there is another of my entries showing the state as 0 before it goes to UNDEF, I am not sure if the OWN log entries before that are really the cause or unrelated.

One more thing: what solves the issue is when I bring the shutters down first, wait for them to physically go down, and then bring them up. After that, the state does not change to UNDEF but stays at 0, or sometimes at 1, which I put down to calibration issues.

This would be the code for that:

var shutters = items.getItem( "Shutter_OG_AO_Roller_Shutter" );
shutters.sendCommand( "DOWN" );
java.lang.Thread.sleep(120000);
shutters.sendCommand( "UP" );

[m4rk (Mark)]

Sorry to butt in but if I rember correctly the actuator sends out a stop command after a fixed time set in the actuator config. Make sure that is a sensible time. Not sure if helps anway.

[the-ninth (Robert)]

@m4rk

Sorry to butt in but if I rember correctly the actuator sends out a stop command after a fixed time set in the actuator config. Make sure that is a sensible time. Not sure if helps anway.

That is a very good point, that STOP message (20*51##) seems what I am seeing in the log just before the state of the Item goes back to UNDEF. It comes about 60 seconds after the original UP command sent from openHAB, which seems sensible. My actuator is an old one, I can only use virtual configuration and it does not have any configuration parameter for that time.

But the STOP message should not put the openHAB Item in an UNDEF state, or should it?

Edit: and it seems to do that only if the state was UNDEF before. If I bring the shutters completely down and then up again after the reboot, then after that the script works fine.