Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address

["Gix, Brian" <brian.gix@intel.com>]

On Wed, 2019-09-04 at 21:48 +0200, Michał Lowas-Rzechonek wrote:
> On 09/04, Michał Lowas-Rzechonek wrote:
> > The two examples I provided are *not* violating the spec in any way.
> > For the record:
> >  - a combined server/client sitting on element 1 that receives onoff
> >    messages and, depending on the destination address, sends a different
> >    onoff messages to a "regular" onoff server sitting on element 0,
> >    allowing efficient control over switching scenes involving large
> >    number of nodes
> >  - a model that acts as a IPv6 gateway and directly maps virtual
> >    addresses to IPv6 addresses of nodes living on the other side of the
> >    gateway
> 
> Another one about virtual addresses:
> 
> In CANOpen, there is a concept of a "Protocol Data Object" [1].
> Basically, the idea is to pack many pieces of information into a
> preconfigured format (down to single bits, because CAN frames are even
> shorter than mesh ones) - this is known as "PDO Mapping Parameters" -
> then send such payloads to a well-known group address.
> 
> In static configurations, this allows to decrease the number (and size)
> of packets sent by sensor nodes.
> 
> Since PDO payloads are *not* self-describing (unlike mesh sensor
> messages), the receiving party must be aware of the mapping in order to
> parse the data.
> 
> In CANOpen, format is determined by the address - in mesh, it could very
> well be a virtual label.
> 
> [1] https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/
> 

I think that this is an interesting use of Virtual Addresses, and in addition to this, Mesh Virtual Addresses
have been suggested as a way of addressing IPv6 addressing as well...  However:

1. There is already a way something like this could be used already:  A model could be created that gets
subscribed to the Virtual Addresses that require handling by the node.

2. If such a system proves to be widely requested, daemon support could be added (perhaps under a different
DBus interface) for either or both of IPv6 and "CANOpen".

In any case the ability to create simple mesh Apps with minimal complexity remains intact, and as an added
bonus, the Open Source community (not to mention the Bluetooth Mesh Working Group and larger SIG) can weigh in
on the preferred methodologies.