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

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

Hi Inga, Michał,

On Wed, 2019-09-25 at 19:02 +0000, Stotland, Inga wrote:
> Hi Michal,
> 
> On Wed, 2019-09-18 at 10:52 +0200, Michał Lowas-Rzechonek wrote:
> > 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
> 
> Okay, this is a good argument for exposing the subscription address in
> MessageReceived().
> It's better to separate the method into two, e.g. MessageReceived() and
> MessageReceivedVirtual().

I wonder if we could still do this with a single method.  I can think
of 2 methodologies:

1. A simple way that just uses the U16 DST field instead of
the "subscription" boolean (not a 100% reliable differentiator
for Virtuals, but may be sufficient for the use cases given).

2. Replacing the subscription boolean with a u32 "Subscription ID".
A subscription ID value of 0x000000000 would indicate that the
message was received with the Unicast address, and values from
1 - 0xFFFFFFFF mean a Subscription that can be queried for. This
would be accompanied by a new daemon method which could look up
the details of the subscription:

	{dict subcription}  LookupSubscription(u32 Sub_ID)

Both of these methodologies would allow an App to be simpler,
with no added D-Bus Methods required.

With the 2nd methodology, the subscription only needs to be
looked up once (or not at all) to 100% differentiate between
discrete subscriptions.

I *really* do not want an additional mandatory App Method. Most
Apps will be simpler than that, and truely not care to
differentiate between subscriptions...   Particularily Client
based Apps.

> 
> Then it makes sense to add model subscription array as a dictionary
> entry in the UpdateModelConfiguration() as well as for the node
> configuration returned when calling Attach() method.
> Probably will have to have separate keys: "Groups" and "Virtuals".
> 
> Regards,
> Inga