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, 18 Sep 2019 10:52:39 +0200
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     Brian Gix <brian.gix@intel.com>,
        Inga Stotland <inga.stotland@intel.com>,
        linux-bluetooth@vger.kernel.org,
        Piotr Winiarczyk <piotr.winiarczyk@silvair.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: <20190918085239.xhahxoeqjkcrk3bl@mlowasrzechonek2133>
Mail-Followup-To: Brian Gix <brian.gix@intel.com>,
        Inga Stotland <inga.stotland@intel.com>,
        linux-bluetooth@vger.kernel.org,
        Piotr Winiarczyk <piotr.winiarczyk@silvair.com>,
        Szymon =?utf-8?Q?S=C5=82upik?= <simon@silvair.com>
References: <20190830184301.zd3zaqrw7mv6r252@kynes>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190830184301.zd3zaqrw7mv6r252@kynes>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

> Imagine a dot-matrix, where each pixel is a mesh node.
> 
> Each of these pixels implements two models:
>     on element 0, a GenericOnOffServer controlling the light output
>     on element 1, a Blinkenlights Server model
> 
> Blinkenlights Server extends GenericOnOff Server and GenericOnOff
> Client, and on top of that contains a translation table mapping group
> address to either 'ON' or 'OFF'.
> 
> Now, when Blinkenlights Server receives a GenericOnOff Set message, it
> looks up the destination address at the translation table, and sends a
> *different* GenericOnOff Set to *its own* element 0, with target value
> determined by the translation entry.
> 
> This allows users to configure each node in such a way, that sending a
> *single* message to a group address causes all pixels to switch to a
> preconfigured pattern *at the same time*.

Per conversation with Piotr, I'd like to revisit the discussion and
provide more details about our use case for models knowing the
destination address.

Please see a diagram at http://ujeb.se/BmTIW.

The main reason we map scenes using destination addresses is that such a
setup consumes much less unicast addresses.

Assuming that:
 S - number of switches
 B - number of buttons (elements) on a switch
 N - nunber of lamps

With a 'regular' case, number of consumed unicast addresses is
    S*B + N*(B+1)

With the destination mapping, it becomes
    S*B + N*2

Since we typically use 4 button switches (B=4), without translation we
consume unicast address space at a *much* faster rate.

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