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
