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

["Michał Lowas-Rzechonek" <michal.lowas-rzechonek@silvair.com>]

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/

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND