Changes to VSCP types ‘ALL_LAMPS*’ of class CONTROL=30 (0x1E)

[michpro]

I would like to propose renaming these types to ‘ALL_DEVICES*’, or adding such a type to the CONTROL class specification.

Why I propose this:
Currently, we intuitively understand this event as a group control for lighting, but the user may also want to use this event, for example, to group open/close blinds throughout the house when changing the ‘arming’ of the alarm system, or to start/shut down equipment in the laboratory.

[grodansparadis]

I think the problem here is the specific types (lamp/blinds etc), it was a mistake to add them in the first place. It is far better to use the more abstract types because we can add and add and add different types and there will always be one missing.

zone and subzone allows for grouping of nodes as well as wildcards for all nodes.

[michpro]

Hence my proposal to change ALL_LAMPS -> ALL_DEVICES,... would be more generic.

[grodansparadis]

Agree. Will add (not change).

[michpro]

If this is going to be a new event type added, I think it could have a ‘device type’ field. We can define the length of this additional field as :

• 1 byte, then we define a dictionary (lamps, roller shutters, etc. - several types could be standardised)
• 2 bytes, which we decode as a bit field, this in turn will allow us to send a single event, and the reaction will occur in several types of nodes, e.g. we send a command to blinds, or to blinds and lamps at the same time. I think that two bytes will be more than enough (we will code 16 types of devices this way)
• we also have a third option: the first byte is a dictionary and e.g. a value of 0xFF means that we will send 2 more bytes of the bit field, with groups of devices to be controlled

[grodansparadis]

Is the only way to have a device type? Maybe... But the problem with each list of devices is that for almost everyone, the device one is about to use is missing. There are a lot of them already, and this is a problem for everyone except for me (who can add a new type when I want) :). But maybe it is impossible to come up with a solution without them. I don't know.

For the extra bytes, I think zone/subzone should be used.

[michpro]

I would intuitively treat zone/subzone more as a place (zone: house, garden, garage,...)(subzone is for example living room, bedroom,...). With an extra bit field, I can send a single event that turns off the lights and lowers the blinds in, for example, the south part of the house. These two extra bytes (which I may or may not use [option 3]) ‘cost me’ far less communication overhead than sending two or more ‘full’ events. Therefore, I would define part of the dictionary as an imposed standard, part I would leave to be extended as ‘reserved’ and part I would give to the user's own implementations. This would give interoperability between devices created by different authors (as far as the dictionary is concerned) and leave it easy to extend to specific devices that nobody now even thinks of :) I would leave the optional bit field entirely at the user's disposal, so as not to introduce restrictions, but at the cost of potentially ‘misunderstanding’ a message sent by a foreign device.

[grodansparadis]

Yes, zone/subzone can be thought of as rooms but also as parts of a machine or whatever. It is the only way to "address" things in VSCP except for events in class=0,512 and 1024. I want it to stay in that way. The "S" in VSCP is hard to protect anyway.

But all devices on/off was the original question. To be consistent with the other control commands "index" in the first byte is available. That means index, zone and subzone can identify devices that should be turned on/off. Replies from affected devices work the way they are today,

[michpro]

OK, this could also be the right way: We use the index as the device(s) identifier and the zone/subzone tells us where they are located

[grodansparadis]

Is "all off" and "all on" enough for you?

VERY good that you raised this one. Device specific events are "wrong" and should not be in the spec. I know that Matter/HomeAssistant etc concentrate on different types of devices more than what they output and what they expect as black boxes. I firmly believe that VSCP should concentrate on the black box view of the world in that respect. When we fail, I hope we have sharp eyes like yours that find such cases.

When it comes to device types, I have added registers in the standard register space that can be used. The thought is that devices from different vendors have a common set of registers and input/output so that they are interchangeable. Look at family code/device type. Not used at the moment, but have some potential for the future. But the bloody list is here also... ;.)

I added your name to the contributors list. I hope that is OK?

[michpro]

Yes ‘all off’ and ‘all on’ will be sufficient, although you could add, another event with an on/off switch, as in the ‘ALL_LAMPS’ event.

Thank you for adding me to the contributors, although my contribution is very tiny.

[grodansparadis]

I fix that.

Don't underestimate your contributions. Very valuable. Especially now, when there are just a fraction of the discussions from the past. Keeps me going...

[grodansparadis]

Fixed in 1.15.5