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;
From:   "=?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek" 
        <michal.lowas-rzechonek@silvair.com>
Date:   Fri, 30 Aug 2019 20:43:01 +0200
To:     linux-bluetooth@vger.kernel.org
Subject: mesh: org.bluez.mesh.Element.MessageReceived method does not provide
 destination address
Message-ID: <20190830184301.zd3zaqrw7mv6r252@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

When trying to use subscriptions in meshd, I've noticed that
MessageReceived API does not provide the application with destination
address of the deceived message - instead, it only sends a boolean flag
saying if the message was part of a model subscription, or not.

I think this is problematic. There are use cases where a model is
interested in the destination address of a group subscription. For
example:

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*.

Moreover, at the moment the application can't receive the label of a
virtual address the message is targeted to.


I'd like to discuss the API change, from the current:

	void MessageReceived(uint16 source, uint16 key_index,
					boolean subscription, array{byte} data)

to something like:

	void MessageReceived(uint16 source, uint16 destination,
                    uint16 key_index, array{byte} data)

	void VirtMessageReceived(uint16 source, array{byte}[16] label,
                    uint16 key_index, array{byte} data)

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