In Lookout, how can I make the equivalent of a "4 changes per day" set-back thermostat?

Question

Ok... I need some help here....
I have a Pot_TSP (Temperature setpoint) that uses a PLC register as its remote source. I added a night-time temperature setback feature by adding a "DAYTIME" expression as a permissive, and tying two new Pots (Pot_SP1 and Pot_SP2) to Pot_TSP's "reset value" :       NIF(Expression_Daytime, Pot_SP1, Pot_SP2). 
Client now wants this increased to 4 optional temp changes per day, just like a household 7-day programmable T-stat. Adding the additional conditions to the "reset" parameter was easy; one extra TimeOfDay timer for each temperature Setpoint change, arranged as "OR" functions. Each time the clock hits one of these TOD targets, Pot_TSP gets "reset" and the "reset value" gets written to it. Here's where I start to bog down... How do you arrange this so that when one of the 4 TOD targets goes "true", its corresponding SP value gets written to Pot_TSP? The closest I've been able to get is this: make a new Pot (Pot_X) with a min of 1 and a max of 4 and use a NCHOOSE to select which of the 4 Temp setpoint Pots Pot_X will use as the (next) SP. If I rotate Pot_X and the clock hits a TOD target, a value corresponding to the selected Pot gets written to Pot_TSP. 
So can someone please tell me how to get Pot_X to align itself with the TOD events? I can get a limping model if I slave the NCHOOSE function to a Counter object, but if the customer has Lookout turned off or disconnected long enough to miss one of the events, Pot_X will go out of sync. Same goes for incrementing the Pot object. Can't allow that...
Since the clock never stops and only hits each TOD once every 24 hours, there would never be more than one of the 4 TOD conditions true at one time... is there a way to build an expression object (or the like) to ultimately produce a numeric (the Pot_TSP value) using the following logic: If TOD1 is true, return Pot_SP_1;  If TOD2 is true, return Pot_SP_2, If TOD3 is true, return Pot_SP_3; If TOD4 is true, return Pot_SP_4   ????
Thanks guys.
G

Answer 1

Hi Ryan
Thanks again for your input! I'm more comfortable with the DataTable object (now that it's become more familiar), and thanks to you I now have a DataTable constructed for one zone (7 rows for the days-of-the-week, and 16 columns for the variables). Displaying of the cell data, cursor navigation, and reading/writing to the Pots' remote position source (in other words the actual GUI) work just fine. In order to expedite completion of the project for which this DataTable is intended, I am at a point where I am prepared to clone the DataTable 3 times to get 4 zones (that's one panel), then clone that result times the number of panels the site has....but I'd like to run this by you first:
Unless it's contrary to "best practices", should I do as above, or try to further multiplex the DataTable I already have by adding to it the other three zones? The Table I have now serves one zone; can it be expanded to serve (dare I suggest it) one panel (4 zones)? If you recall, I started out thinking I'd need one dedicated Pot for each variable in each zone (16) times 7 days = 96; using the DataTable, the cursor replaced the d-o-t-w so the number of Pots needed dropped to 16. My point: if I have to make separate DataTable objects for each zone, I also need to make 48 more Pots to serve them (which I'm obviously trying to avoid). Then I have to repeat this times the number of panels on site. I'm guessing that adding 3 more zones to the existing (one zone) DataTable is no problem since there's plenty of room left... 
But would you add them as columns (to keep the cursor consistent across the zones) or add them as rows (to keep the columns consistent across the zones)? 
If added as columns, can I avoid making those extra 48 Pots? Can I make my existing 16 Pots read/write to multiple columns, like change the Remote Source for Pot_Temp_SP_1 from "..\DataTable.B" to something like "nchoose(Pot_Zone_Selector,..\DataTable.B,..\DataTable.R)" where columns B and R contain Temperature setpoint values for Zones 1 and 2 respectively?
If added as rows, I'm guessing I don't have to make those extra 48 Pots. But what's the best way to deal with the cursor? Should I be looking at multiple cursors (one for each zone)?
I should also point out I've been using only L3 Pots since "normal" Pots won't accept an expression as a remote position source; if I change this to regular Pots coupled with SymbolicLinks, does it change the picture at all?
...and I'm using Ver 6.0.2
Thanks,
George