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@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
