OpenWebNet: group commands [WHERE=#n ?]

[llegovich (Luciano)]

Hi,
I’m using OpenWebNet binding b7 provided by @massi with OH2 on a Raspberry PI 3.
I have succesfully tested it with lights, rollershutters and thermostats and with MyHomeServer1 gateway. It works really well but I have an issue with group buttons.
I have a physical rollershutter group button (to open or close all rollershutters) and a physical All lights ON/OFF button. When I press those physiscal buttons, the lights and/or rollershutters items state is not updated in OH2.

I guess they are sending on the SCS bus a group command which is not recognized by the binding, and the involved items that changed state are not updated.

Do I have to define additional configurations to work with such group commands?

thanks.
ciao

[vzorglub (Vincent Regaud)]

Can you post your items, sitemaps and relevant logs with comments, please?

[massi (Massimo)]

hi @llegovich
your analysis is correct: group commands are not supported by the binding.
The idea is that groups can be defined in OH2, but since there are physical buttons that control a group of devices, this should be supported as feedback status updates by the binding.

I suggest you set log level to DEBUG (see README for info)
and post a new issue copying the relevant log lines and explaining the expected behavior.

Bye
Massi

[massi (Massimo)]

@gozilla01, @llegovich:
some logs are needed to see which messages are received when a group button is used.
When a command like:
*1*0*0* (switch OFF all lights) is sent, on the BUS should be seen a status update event for each light in the system, and the binding should then use these events to update each light status.
Provide some log here:

Issue: Support for group addresses (WHERE=#n)

[gozilla01 (Michele)]

Massimo,
Tomorrow I rehearse and I’ll attach logs to better understand what’s on the bus and OH2

[gozilla01 (Michele)]

@massi

*1*0*0* (switch OFF all lights) is sent, on the BUS should be seen a status update event for each light in the system, and the binding should then use these events to update each light status.

Massimo,
I performed tests with GEN and AMB(2).
On the bus there is no status updates, see image

GEN

AMB=2

To implement the management, in addition to the existing where, the AMB(single) and GR(matrix) parameters must also be added to the lights with manual entry or via .things.
For example, like the parameter button with CEN +.

Thing bus_on_off_switch   mylig_sala "Luce Sala"	@ "Sala"	[ where="23", Amb="2", Gr ="1,2,3" ]
 

To send from paperui to the bus you could use the same as CEN + with ON e OFF

Upon receipt of AMB or GR the binding must update the respective lights.

[massi (Massimo)]

The test result is VERY strange.
In fact the OWN specs say that every time a light changes state, an event is also sent on the BUS, this is why the binding is listening to events, not to commands.

@llegovich can you also do the test that @gozilla01 did?

• connect with OWN official client and activate Event session
• turn some lights on. Make sure these lights are not on separate buses (WHERE should be simple, like WHERE=52, and not like WHERE=12#4#02)
• send a “all OFF” command (*1*0*0##) and check the lights are actually switched off
• copy the log here

bye
Massi

[llegovich (Luciano)]

@massi

@llegovich can you also do the test that @gozilla01 did?

Yes!

1. opened event
2. swtiched on the WHERE=25 light via a *1*1*25## software command and switched off all lights via *1*0*0## software command. Here is the event log:

then I did it using physical buttons rather than software commands and here is the log:

I don’t understand why there aer a number of switch-off commands sent to some lights (see where = 0015,01,12,03, etc…), in particular because they are only a subset of all the lights I have.
I have digged a bit into it and it seems that those actuators are configured as “Master PUL” (within the bticino/legrand MyHome suite software), which would mean “ignore ambient and general commands”, but somehow the system is sending them the command anyway.
I think that for the purpose of this topic we could ignore those commands sent to the bus.

I think that my logs confirm there is no status update for the single lights which have been switched off, that makes the issue hard to resolve I guess.

[massi (Massimo)]

@llegovich

I think that my logs confirm there is no status update for the single lights which have been switched off

Then what are all those messages *1*0*xx## you have in the logs???
In fact they are the confirmation of lights being switched off!

My interpretation of your log is that as soon as the “all-off” command is sent *1*0*0##, all lights that are configured to respond to GEN/AREA will switch off, and an event message is sento correctly on the BUS for each light.
Same happens if the all-off command is sent from a physical switch (second log).

My analysis is therefore that the biding is already working correctly: lights that are set to respond to GEN/AREA commands, will switch off and this event will appear on the bus: this will be reflected in the OH2 items.

Massi

[massi (Massimo)]

@gozilla01

To implement the management, in addition to the existing where, the AMB( single ) and GR( matrix ) parameters must also be added to the lights with manual entry or via .things.

For AMB (you mean: area) this is not necessary: form the WHERE address of a light you can already detect its A (area) and PL (light-point).
Read the OWN specs for lights WHO=1, WHERE table, page 7.

For groups I would need an example that shows what happens when one sends a GROUP command (for example: *1*0*#G## , where G is the GRroup number [1-255], also indicating which are the lights that belong to the group.

Massimo

[llegovich (Luciano)]

@massi

My interpretation of your log is that as soon as the “all-off” command is sent *1*0*0## , all lights that are configured to respond to GEN/AREA will switch off, and an event message is sento correctly on the BUS for each light.

Hi Massi, I’m afraifd I didn’t explain it well.
No one of those lights in the log is actually attached to any physical bulb. They are unused.
Light 25 (which instead is in use) is switched off when I send the all-lights-off command, but you can’t find the relative event update un the bus.
So this means that the lights are being switched off by the all-lights-off command but no status update is sent on the bus.

[k0nti (Patrick)]

System Openhab 2.5 Snapshot - Bticino Binding org.openhab.binding.openwebnet-2.4.0-b9-2
So i have i physical switch at the entrance to switch all lights off.
When i look at this my issue is an of topic :)?

21:01:10.762 [DEBUG] [ebnet.handler.OpenWebNetBridgeHandler] - ==OWN== ownId=1.0
21:01:10.787 [DEBUG] [ebnet.handler.OpenWebNetBridgeHandler] - ==OWN== ownId=1.0 has NO DEVICE associated, ignoring it

this happens when i press the button.

[gozilla01 (Michele)]

Patrick,
Use OpenWebClient and post the log, all messages on the bus after pressing your physical GR key.
Massimo needs the log.

[gozilla01 (Michele)]

@massi

For AMB (you mean: area) this is not necessary: form the WHERE address of a light you can already detect its A (area) and PL (light-point).
Read the OWN specs for lights WHO=1, WHERE table, page 7.

AMB = A can be extrapolated from the WHERE,it is not necessary to send the status request on the bus.
No additional parameters are required

@massi

For groups I would need an example that shows what happens when one sends a GROUP command (for example: *1*0*#G## , where G is the GRroup number [1-255], also indicating which are the lights that belong to the group.

GR Light

Light (WHO=1) with WHERE = 11, 0110 , 13 , 14 associated GR = 1
GR = 1 OFF
*[WHO]*0*#[GR]##
*1*0*#1## (frame sent by OpenWebNet Client)

GR = 1 ON
*[WHO]*1*#[GR]##
*1*1*#1## (frame sent by OpenWebNet Client)

GR
As you can see from the log, everything is simpler.
The WHERE changes come out on the bus, so the status update on OH already works and does not need any further parameters.
I have not tried a test on GR of the automation WHO=2

AREA Light

frame inviato dal client OpenWebNet

All ON A=2
*1*1*2##
*[WHO]*1*[A]##
All OFF A=2
*1*0*2##
*[WHO]*0*[A]##

No light update frames on the bus, such as GEN

GEN / AREA

For AMB / Area it would be better not to update states directly inside OH, but to make a status request on the bus with a delay esemple the 500ms

Light WHO=1
Status request for all A
*#1*0##
Status request for all A = 2
*#1*2##
*#1*[A]##

If you want I’ll do the implementation, give me the specifications.
Clearly you have to prepare the .lib, so you can move on to bigger and more important things

[k0nti (Patrick)]

So when i push the button i receive

[gozilla01 (Michele)]

Test GR Automation

*2*0*#[GR]## STOP
*2*1*#[GR]## UP
*2*2*#[GR]## DOWN

[gozilla01 (Michele)]

Test AMB = A Automation

*2*0*[A]## STOP
*2*1*[A]## UP
*2*2*[A]## DOWN

[gozilla01 (Michele)]

I grouped all the commands

Summary

Edit 13.02.19
I posted an example of how to use GR and GEN with OH
With “A” I did not run tests, but I do not see any problem.

Openwebnet: Working Examples

Use of buttons to manage groups and general from OH In the example there are two ways to manage the blinds, of your choice. [GR-GEN] file .items Group:Switch:OR(ON, OFF) G_Generale "General" <light> Group:Switch:OR(ON, OFF) C_Giorno "Group day" <light> (G_Generale) Group:Switch:OR(ON, OFF) C_Notte "Group night" <light> (G_Generale) Group:Rollershutter:AVG C_T_Giorno "Group blinds" <rollershutter> (P_PianoTerreno) Rollershutte…

[bastler (stefan)]

i can also do tests

[gozilla01 (Michele)]

Hi everyone,
I need some tests Ambient with roller shutters.
Change the number 9 according to the number of your roller shutter environment

*2*2*9## 
*2*0*9## 
*2*1*9##

or for those with the subsystem

*2*2*9#4#01## 
*2*0*9#4#01## 
*2*1*9#4#01##

These commands are used for UP or DOWN or STOP all shutters in the room

The information I need is:

• Sending the OWN command with the openweb client and posting the image.
• What kind of gateway do you use.

I’m looking at the implementation of the command groups and I need some tests
Thank you all