Best Practices for LEVEL Feedback - Chime In

GasHed

So here's another one of my "What's the best practice for doing x in NetLinx" questions. In a multi-touchpanel, multi-source project, statically linking device volume levels with touchpanel levels become unattractive because you have to create a seperate volume bar/button for each and every volume device and then DEFINE_CONNECT_LEVEL for each touchpanel level to each device level. This situation becomes impossible when you start dealing with a house with 20 or so thermostats each with levels for heat set point, humidity set point, outside temp, inside temp, etc.

The 2 options I see are thus:

1) Dynamically combine and uncombine levels as the user switched between thermostats or volume controls.

DEVLEV vdvTP1VOL = [32000:1:0,1]
DEVLEV vdvTUNER1 = [32001:1:0,1]
DEVLEV vdvTUNER2 = [32002:1:0,1]
...
COMBINE_LEVELS vdvTPVOL, {vdvTUNER1}
...
UNCOMBINE_LEVELS vdvTPVOL
COMBINE_LEVELS vdvTPVOL, {vdvTUNER2}

2) Use variables to track the value of each level and update the display at points you desire

LEVEL_EVENT[vdvTUNER1]
{
    volTUNER1 = LEVEL.VALUE
    CALL 'UPDATE_TPs' ()    // Update touch panels displaying that level at the moment
}

The first option seems really nice to me since the update is taken care of, but I haven't been able to get it to work. The second works good, but doesn't seem very elegant to me. It requires extra memory and I have to worry about when to send the touchpanel level updates.

What do you think? 1, 2, or option not presented here?

DHawthorne

I've had this exact situation with thermostats. A total of 18 stats, and 20 panels that could call up any of them, or a girid with data from them all.

The way I dealt with it didn't really fit with either of your examples, but was probably closer to your #2. First of all, I had the thermostats running in their own module, which kept track of all the pertinent data for each stat: temp, humidity, setbacks, timer values. All these values were written to a set of arrays; I would have much preferred structures, but I wanted to use persistent variables, and I wanted it to be modular enough to transport to other projects, so I had to settle for seperate arrays grouped by data type. One of the arrays tracked which thermostat was currently displayed (if any) in each panel. When a different thermostat was selected, or the thermostat page was not displayed, I updated this array accordingly. Then, in the feedback section, I would run through each panel, check what data was appropriate to update, and send that data to that panel. That way, only one leve was needed, for example, for a temperature display, for each panel, but I sent different data appropriate to what was being looked at. No combines necessary, just a timeline to refresh the data and make sure it was appropriate. My timeline ran once a second, more than frequently enough for thermostats.

Is this the "best" way? I don't know about that, but it seemed appropriate to the devices. If it were volume controls, I would be more inclined to send all my data to a virtual device with all the levels and such, then dynamically combine the virtual to the panel when selected. I tend to decide these things on a case-by-case basis. Thermostats are relativatly slow devices. You aren't likely to get a huge change in data in a short time (and if you do, you might be thinking about running away rather than examining it on the touch panel ). Something like a volume control, on the other hand, can make fast jumps in a short space of time, and you may want the more responsive feedback you would get from a combined device and level.

GSLogic

I use DEV arrays and GET_LAST() as each panel can view any room in the home. When a panel presses volume up, I update that panel and on release I loop through the other panels to see if any of them are viewing the same room, if so I update them with the new volume.

I use a PERSISTENT STRUCTURE to store all the volume/treble/bass/source/etc for each room. The panels are updated as they enter to view the selected room.