Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 4 Sep 2019 21:48:08 +0200
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     linux-bluetooth@vger.kernel.org, Brian Gix <brian.gix@intel.com>,
        Inga Stotland <inga.stotland@intel.com>,
        Szymon =?utf-8?Q?S=C5=82upik?= <simon@silvair.com>
Subject: Re: mesh: org.bluez.mesh.Element.MessageReceived method does not
 provide destination address
Message-ID: <20190904194808.nu2cy4vp6uh64m4z@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org,
        Brian Gix <brian.gix@intel.com>,
        Inga Stotland <inga.stotland@intel.com>,
        Szymon =?utf-8?Q?S=C5=82upik?= <simon@silvair.com>
References: <20190830184301.zd3zaqrw7mv6r252@kynes>
 <20190904192525.2dqyihabxmigb54m@kynes>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190904192525.2dqyihabxmigb54m@kynes>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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