Scenes that can be edited by enduser??

jisaac

Hi All,
I am stuck at a project where the homeowner wants to be able to create custom "scenes" on the fly.
Example:
Wake up Scene--
Audio: turn on specified audio zones to specified volume levels playing specified sources.
Lights: turn on specified light load to specified light levels.

He wants to be able to edit all the specifics of the of the wake up scene on some sort of back end menu. Apparently his neighbor has control4 & it allows some sort of "scene creator" feature, no doubt where he got the idea.

I started to tackle this but found myself writing endless code that worked so-so. I took a look at !MacroManager but it dosent seem that anyone uses it & theres not much info into how it works or if it is what i am looking for here.. Any thoughts??
Thanks!!

Spire_Jeff

Well, starting from scratch is going to take a while (depending on the gear and complexity involved).

You might be able to use i!-Schedule to handle the scheduling part, then just create a couple of arrays that store parameters that get sent to the lighting processor and AV switcher when the event is activated. Then give the client an interface to change the array.

You could also just ask the client what scenes he would like and hard code them (make it so he can change the time they activate).

Jeff

TurnipTruck

I would take each controlled part of the system (lights, sound, etc) and create a module for each with the ability to create and recall presets. The user's command to save or create a preset is then sent to all modules from your main program.

DHawthorne

As long as your program can already control all the particulars individually, it's not that tough to store them in a preset. I've done several variations on it, all expansions of the simple volume preset idea where you press-and-hold to store, and just press to retrieve. So, you have them set each room the way they want, then hold one of your "preset" buttons, which stores it all in a persistent variable. If you want to get fancy, you can include button sets to include only certain rooms, or only certain settings, but my advice is keep it as simple as possible. For example, I wouldn't link lighting and audio on a single button ... too many possible variants.

ericmedley

DHawthorne wrote: »

As long as your program can already control all the particulars individually, it's not that tough to store them in a preset. I've done several variations on it, all expansions of the simple volume preset idea where you press-and-hold to store, and just press to retrieve. So, you have them set each room the way they want, then hold one of your "preset" buttons, which stores it all in a persistent variable. If you want to get fancy, you can include button sets to include only certain rooms, or only certain settings, but my advice is keep it as simple as possible. For example, I wouldn't link lighting and audio on a single button ... too many possible variants.

I did a similar thing when I was at the University. Professors could, if they chose, create a login when they walked in the classroom. Once they did so, they could take a snampshot of the system once they'd set it up they way they wanted. Then each time they logged in, it would call up everything the way they set it up.

It's just a matter of thinking it though and tracking everything. We do that kind of thing here but with some modificaitons. It's very doable.

a_riot42

jisaac wrote: »

found myself writing endless code that worked so-so.

This is always a sign of poor or fuzzy design. Always design now, code later. This shouldn't be that difficult to code if it is designed correctly.
Paul

DHawthorne

a_riot42 wrote: »

This is always a sign of poor or fuzzy design. Always design now, code later. This shouldn't be that difficult to code if it is designed correctly.
Paul

Not always ... sometimes it's a sign of bosses and management that threw changes in at the last minute and didn't budget extra time. Or a client who insisted what he got wasn't what he wanted, and you must adjust it at no charge ... and sometimes it's "uh-oh, I didn't realize that was going to happen, and now the project is due, and there is no time and no budget to fix it properly, so I have to throw a Band-Aid on it."

In an ideal world, I would design the heck out of everything, test it all thoroughly and re-write my entire program structure every time a significant enough change came along to warrant it. Unfortunately, in the real world, I am often forced to get it out the door and do whatever it takes.

ericmedley

DHawthorne wrote: »

Not always ... sometimes it's a sign of bosses and management that threw changes in at the last minute and didn't budget extra time. Or a client who insisted what he got wasn't what he wanted, and you must adjust it at no charge ... and sometimes it's "uh-oh, I didn't realize that was going to happen, and now the project is due, and there is no time and no budget to fix it properly, so I have to throw a Band-Aid on it."

In an ideal world, I would design the heck out of everything, test it all thoroughly and re-write my entire program structure every time a significant enough change came along to warrant it. Unfortunately, in the real world, I am often forced to get it out the door and do whatever it takes.

What are these 'last-minute changes' you speak of??? Surely you jest...

JohnMichnr

ericmedley wrote: »

What are these 'last-minute changes' you speak of??? Surely you jest...

Actually I think he is quite serious and please...(wait for it) don't call him Shirley.

JohnMichnr

I too have had to do scene presets for a customer.

I have not had to reto-fit a system for them however, knew up front that it was going to happen. I found that it did change the way I thought about the control of the various devices. It forced my source select and volume presets to go in one direction where I could store those adn recall them at any time.

My guess is you will have to go back an look at your source selectiona nd volume control areas to see if a preset will fit into those. Possibly re-write some portions. Then writing the structure or arrays to store the data is easy - recalling it is always teh challanging part.

AMXJeff

jisaac wrote: »

Any thoughts??

MacroManager I have used and would surely work, but there is alot of over head with that code, and since this is resi, I would think you already have alot of that.

I would sell the home owner, HomeManager. With the amount of code and TIME you are working with here it would pay for it self. You will just have to let HomeManager know about your function list, and he can use it to build macro and trigger them based on schedule.

a_riot42

DHawthorne wrote: »

In an ideal world, I would design the heck out of everything, test it all thoroughly and re-write my entire program structure every time a significant enough change came along to warrant it. Unfortunately, in the real world, I am often forced to get it out the door and do whatever it takes.

I wasn't really trying to forward the opinion that we live in some ideal world. In fact, because we don't, design is even more important. For a recent project, a client wanted to add two 5200i's in two guest rooms that had independent AV zones. Due to the way the system was designed, it was really just a matter of adding a few boring lines of code to the project, and uploading the TP files to the TPs. It took about an hour to complete. The last programmer I worked with would have taken a week to add those two zones and TPs. Good design makes last minute changes easier, so I will never scrimp on design time, I don't care what the boss says. It has paid off over and over again.
Paul

PhreaK

+1 for that. In the majority of AMX systems the coding is not overly complex. Heck, we don't even have the ability to play with higher math (well, not without writing our own libraries). The disadvantage of this is the overwhelming urge to just get straight in and write the code for a new project. I'm sure most of us have our own 'mental templates' as to the way we do things, and I know that with a few projects I've done that 5 minutes of semi-thought and 30 seconds of note jotting are all the planning that takes place. That being said, I hate myself for doing that when a couple of months later they decide to add another display that is independant of the ones that were in at install time, or they want some form of different functionality that wasn't part of the 'concrete' initial design spec. The truth is that the actual code writing should be an extremely minor part of programming - in any langauge. Programming is about logically mapping out a system and designing the interaction of both the user and logic and data flow and management.

Anyway, back the original post. If you are tracking the states of external devices within code why not give them the ability to set up the system how they want then take a 'snapshot' which they can name and store rather than have a verbose page with settings for everything. It would mean less clutter on your panel and offer the user a method of interaction that won't feel alien from the rest of the system.