Grid of lighting scenarios as default for Orbiter

[chrisbirkinshaw]

I was thinking it would be useful to have a grid of lighting scenarios as an option for the default screen of some orbiters. For example I have an orbiter in my hallway which is assigned to a dummy room called "Automation" which has about 20 lighting scenarios attached, but it is annoying that I only get the top line and have to press More to view the rest.

Anyone got any thoughts on this?

[tschak909]

you can do this for any orbiter.

Go into the LinuxMCE web admin... Wizard > Orbiters ... find the orbiter you wish to change, and select its advanced button...

scroll to the bottom of the resulting screen.. you'll see a device data entry for PK_Screen. This is the default screen that will be used when starting up.

The screen you wish to use can be gleaned by looking at the Screen table:

Code: [Select]

mysql> select PK_Screen, Description FROM Screen LIMIT 17;
+-----------+----------------------+
| PK_Screen | Description          |
+-----------+----------------------+
|         1 | Main                 |
|         2 | Lights               |
|         3 | Media                |
|         4 | Climate              |
|         5 | Security             |
|         6 | Telephony            |
|         7 | Misc                 |
|         8 | UserStatus           |
|         9 | MakeCallPhonebook    |
|        10 | MakeCallFavorites    |
|        11 | MakeCallDialNumber   |
|        12 | MakeCallPlutoUser    |
|        13 | SecurityPanel        |
|        14 | SecurityStatusReport |
|        15 | SingleCameraViewOnly |
|        16 | Intercom             |
|        17 | QuadViewCameras      |
+-----------+----------------------+
17 rows in set (0.00 sec)

 I've only shown the first 17 screens or so, as those are the most useful for this.. you can of course look at the rest of the table.

If you want to know more, such as how to modify the UI, etc.. you may want to watch my Designer screencasts.

[chrisbirkinshaw]

Thanks for this info, sounds promising. I did this but then the orbiter is locked to this screen and the Home button has no effect.

Chris

[tschak909]

then you need to seriously think of what you want to do.. you may need to make a new skin based on Basic to get what you want.

think every UI interaction through.

-Thom

[Marie.O]

chris,

another idea is, to "recycle" the other button groups on the main menu. Instead of having climate scenarios there, put some lighting scenarios in there. Same with media.

Nice duct-tape solution

rgds
Oliver

[tschak909]

ewwwwwww


grrrrrr...

-Thom

[chrisbirkinshaw]

I suppose some could class as media or lighting. For example I have a scenario which turns on all MDs in the house and sets mood lighting, and turns on my audio racks.

[tschak909]

*shake-head*

you should cut down on the number of commands, and use events and sensors for things like that. You can create commandgroups that do not belong to any of the main types (hidden) and call them with a DCE Router Execute Command Group command.

You only have precious few buttons available on the main screen, understand this, and don't make it where you wind up pressing several things to set a scene, because you want to mix and match things... This overcomplicates your system...

but hey, what do I know? I've only been doing this for ....ever... how could I possibly know what makes things easier?

-Thom

[bulek]

Hi,

I also tend to setup too many scenarios and then my wife and kids keep asking what are they doing....

Then I try to remember that "there's something wrong if menu system has more than X choices on each level"... I usually try to use rooms not just in physical, but also in logical meaning (for instance I have an House Audio room, and all things regarding our house audio channel are there)....

Anyway, we're all probably now in phase where we get all possible commands at our hands on Orbiters... Next stage (far away) would be to make system more intelligent, so majority of actions are taken automatically - that scares some people, but when it will come, it will be usable....

Regards,

Bulek.

[chrisbirkinshaw]

I'm not sure how I could use events and sensors for my scenario which turns all my MDs on and sets mood lighting. I could set mood lighting to come on whenever I switch on my MDs at night but then I wouldn't be able to have another scenario which turns on MDs and doesn't touch lights (I use this when testing etc) at night. I can see how creating command groups helps with DRY when making scenarios, but I can't see how it would keep my orbiters less cluttered.

BTW, if i set an event trigger as When a Device is Turned On, and choose the MD, it does not work. To turn my audio kit on in the bedroom I actually use an init script which fires a message to the core. If this should work then let me know and I'll mantis it.

[Marie.O]

chris,

the audio kit will not get turned on, when you turn on the MD. The audio kit should get automatically turned on, when you need the audio output. If you have your AV gear correctly related to your MD that should happen automagically (and it does do for me ).

This is the beauty of LinuxMCE.

rgds
Oliver

[chrisbirkinshaw]

My AV kit is turned on by an X10 appliance module. I can't see any way to do that automatically, or have I missed something?

[totallymaxed]

My AV kit is turned on by an X10 appliance module. I can't see any way to do that automatically, or have I missed something?

Sure... as posde says the controlled AV equipment will be automagically turned on and its input selected when you select media playback in the Orbiter. you need to use IR blasting or RS232 control to make this happen though.

Andrew

[chrisbirkinshaw]

I know, but I'm using X10, not IR to turn my amps on and off. So no solution for this? Would be great if you could specify an X10 device as the power switch for your amps!

[bulek]

I know, but I'm using X10, not IR to turn my amps on and off. So no solution for this? Would be great if you could specify an X10 device as the power switch for your amps!

Hi,

the way the things were probably meant under LMCE is giving another suggestion:
- you could connect your X10 device to audio pipe going from your device - like in real situation... Then when your device receives on command it should be propagated to your X-10 device. Currently there is probably a problem, cause only certain types of devices can be receivers of commands through pipes...

I'd kindly ask if someone from developers gives more insight view on this matter... Actually automation on/off devices could also be reciepients of pipe commands... Not sure what is proper way to do this under current LMCE...

HTH,

regards,

Bulek.