LinuxMCE Forums

General => Developers => Topic started by: chrisbirkinshaw on October 22, 2008, 01:09:07 am

Title: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 22, 2008, 01:09:07 am
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?
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: tschak909 on October 22, 2008, 01:47:15 am
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.
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 23, 2008, 11:31:32 pm
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
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: tschak909 on October 24, 2008, 03:10:05 am
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
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Marie.O on October 24, 2008, 11:17:40 am
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
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: tschak909 on October 24, 2008, 01:35:41 pm
ewwwwwww


grrrrrr...

-Thom
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 24, 2008, 05:17:46 pm
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.
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: tschak909 on October 24, 2008, 05:20:51 pm
*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
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: bulek on October 24, 2008, 09:32:39 pm
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.
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 25, 2008, 03:20:43 pm
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.


Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Marie.O on October 25, 2008, 03:43:19 pm
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
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 26, 2008, 03:50:51 pm
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?
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: totallymaxed on October 26, 2008, 03:59:49 pm
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
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 27, 2008, 01:23:12 am
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!
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: bulek on October 27, 2008, 08:56:13 am
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.
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Marie.O on October 27, 2008, 09:00:04 am
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!

Unfortunately, there is currently no provision to have an on/off switch in front of any of the AV devices. But we had this discussion already, it ain't an easy task though.

rgds
Oliver
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: totallymaxed on October 27, 2008, 10:47:27 am
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!

Chris... understood.

However just powering the amps up does not allow you to switch to the correct input or control the volume. X10 is never going to allow anything more than basic power up of the amp... also some amps may not enjoy being powered up this way but I guess your aware of that problem already and your amps are suitable.

All the best

Andrew
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: tschak909 on October 27, 2008, 12:37:35 pm
was about to type what totallymaxed just posted.

But basically yeah. You need to move to a signaling technique in which you can control the different a/v devices' functions.

X-10 just isn't gonna do that.

-Thom
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 27, 2008, 01:17:37 pm
I actually have only one input! ADAT from my MD to my audio PC for transfer of 5.1 sound. Audio PC runs brutefir off a memory stick (stripped down approx 5MB linux) to do digital crossovers and room correction for phase and frequency response.

I've been doing the X10 thing with two systems for about a year. One has the on/off fired by an init script on the MD as it is dedicated to that MD, and the other is controller by a scenario as I don't wish to have it turned off always when the MD shuts down, as it does some other stuff (iPod etc).
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chriss on October 27, 2008, 02:35:44 pm
I agree that only X10 (or similar systems) won't control your AV equipment, but in some use cases it might be useful to be able to do hard switching (instead of stand-by stuff over IR/RS232). What I have in mind is, e.g., active subwoofers, audiophile amplifiers that might not include a preamp  etc.

The remaining question is: can this be done as of today?

just my 2 cent
Chriss
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: totallymaxed on October 27, 2008, 03:27:29 pm
I agree that only X10 (or similar systems) won't control your AV equipment, but in some use cases it might be useful to be able to do hard switching (instead of stand-by stuff over IR/RS232). What I have in mind is, e.g., active subwoofers, audiophile amplifiers that might not include a preamp  etc.

The remaining question is: can this be done as of today?

just my 2 cent
Chriss

Well it can be done with ZWave enabled power strips... several of these are about to come onto the market from companies like POPP.eu and others. These allow you to power on/off each individual socket on the strip separately.

Alternatively you could use one of these http://catalog.bitsltd.us/power_strips/ (http://catalog.bitsltd.us/power_strips/) strips...these sense the power state of a single device like a TV (plugged into the 'blue' socket) and then power off the other devices plugged into them based on that 'devices' state. You could also have a ZWave plugin module in the Blue socket so that powering on/off would be controllable from LinuxMCE.

Or more simply you could use a basic power strip and have the ZWave module just power off the whole strip - therefore powering off any devices plugged into it.

Andrew

Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on October 27, 2008, 09:11:31 pm
I went for the single appliance module feeding a powerstrip approach in both my installs.

Another complexity of my system is that it takes 40 secs for my audio processing system to boot up. This means I can't have it set to come on when media starts playing - it actually needs powering up during the MD boot process to give it enough time.

It would be nice to have some functionality whereby if no media has been watched for XX minutes then the amps, active subs etc are turned off. This however requires a countdown timer function and a way to reset it which does not appear to exist, or at least not when I inquired about similar functionality for use in my automatic hallway and kitchen lighting.

Regards,

Chris
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Marie.O on October 28, 2008, 10:11:41 am
It would be nice to have some functionality whereby if no media has been watched for XX minutes then the amps, active subs etc are turned off.

This is part of the regular LinuxMCE setup. It happens automatically. 15 minutes after the last media is played, all my audio and video devices are turned off

rgds
Oliver
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: totallymaxed on October 28, 2008, 10:37:32 am
It would be nice to have some functionality whereby if no media has been watched for XX minutes then the amps, active subs etc are turned off.

This is part of the regular LinuxMCE setup. It happens automatically. 15 minutes after the last media is played, all my audio and video devices are turned off

rgds
Oliver

Yep... that works fine and is a standard part of our installs. But you need to control your other devices/equipment using either rs-232 or IR.

Andrew
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Marie.O on October 28, 2008, 11:14:10 am
To be nit-picking:

You need LinuxMCE to control your equipment. LinuxMCE needs to know the media devices are connected to a specific MD. And LinuxMCE needs to know how to turn on and off those devices. This can be done by using the Generic Serial Device, which, other than the name implies, can control stuff using RS-232, InfraRed, and system commands.

rgds
Oliver
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chriss on October 28, 2008, 12:59:39 pm
This can be done by using the Generic Serial Device, which, other than the name implies, can control stuff using RS-232, InfraRed, and system commands.

I guess that's the piece of information we needed to know: you can not only control your devices by IR and RS232 but also by system commands...

Posde, thanks a lot,
Chriss
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: totallymaxed on October 28, 2008, 02:18:54 pm
This can be done by using the Generic Serial Device, which, other than the name implies, can control stuff using RS-232, InfraRed, and system commands.

I guess that's the piece of information we needed to know: you can not only control your devices by IR and RS232 but also by system commands...

Posde, thanks a lot,
Chriss

Yes you can use MessageSend to send any device a command/data. However the point is that 'out of the box' there is no support for using X10 or ZWave devices in the way that you are wanting to. Its certainly not impossible at all... but it will need some work to make it happen.

Andrew
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Marie.O on October 28, 2008, 04:30:56 pm
This can be done by using the Generic Serial Device, which, other than the name implies, can control stuff using RS-232, InfraRed, and system commands.

I guess that's the piece of information we needed to know: you can not only control your devices by IR and RS232 but also by system commands...

A GSD contains Ruby code. Ruby code can do anything, including calling external programs.

rgds
Oliver
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on January 28, 2009, 09:15:18 pm
Solution:

Add the following ruby code into a new template:

Off Code
`/usr/pluto/bin/MessageSend localhost 99 99 1 193`

On Code
`/usr/pluto/bin/MessageSend localhost 99 99 1 192`


Where 99 is the device id of the X10 device you want to turn on and off.

This is greate for controlling active monitors and powered subs.
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: tschak909 on January 28, 2009, 09:35:40 pm
*YEAUGH* good god, will you guys PLEASE STOP DUCT TAPING THINGS TOGETHER?!

-Thom
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: bulek on January 29, 2009, 10:32:21 am
Hi,

I guess the proper solution would be to connect X-10 device to audio pipe with your amp... But currently I guess Media plugin sends commands to pipe connected devices only if they are of certain type (I'm talking this out of my memory - could be wrong about it)...

I see no obvious reasons, why this limitation is coded into Media plugin - am I wrong ? IMHO just any device capable of doing any related commands could be connected to pipes... It's user's responsibility what he will plug to pipes...

Regards,

Bulek.


Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: hari on January 29, 2009, 10:55:30 am
we need power pipes..
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: chrisbirkinshaw on January 29, 2009, 11:07:17 am
*YEAUGH* good god, will you guys PLEASE STOP DUCT TAPING THINGS TOGETHER?!

-Thom


Jesus, in that case how the f*ck do I do it?!

I'm not proposing submitting this solution to SVN, so what is the problem? If someone needs to do this right now then this will help them. They should not be able to do this on their own system - that's what your're saying? They should manually turn on their subs and active monitors just because you don't like it and it's not a perfect solution?! WTF?!!!

EDIT: Corrected spelling
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: hari on January 29, 2009, 11:25:45 am
we need power pipes and popcorn..
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: Zaerc on January 29, 2009, 12:56:41 pm
*YEAUGH* good god, will you guys PLEASE STOP DUCT TAPING THINGS TOGETHER?!

-Thom


Jesus, in that case how the f*ck do I do it?!

I'm not proposing submitting this solution to SVN, so what is the problem? If someone needs to do this right now then this will help them. They should not be able to do this on their own system - that's what your're saying? They should manually turn on their subs and active monitors just because you don't like it and it's not a perfect solution?! WTF?!!!

EDIT: Corrected spelling
There still is a type-o in the word "fuck".  :P

Anyway, I think Bulek has got the right idea, we should test removing that limitation.  And maybe even implement power pipes as Hari suggests.

Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: bulek on January 29, 2009, 01:58:27 pm
Hi,

if I may add further, when I encountered this problem I had an idea of generic pipe, where one could specify which commands will propagate... So audio, video pipes will be just special case of generic pipe with repdefined command set.

And important, user could be able to add whatever commands he thinks are right to be propagated through pipes...That is probably the ultimate way to solve this once for all.

Also usually similar systems have some kind of hooks in such places - so for instance you can trigger any event,scenario when something gets propagated through pipe (for instance prepend audio announcement sound prior speech announcement, etc...). Similar to events, but would trigger only on events on pipes. Maybe better idea is to have dummy GSD device that is attached  to pipe and do whatever is needed there...

Regards,

Bulek.
Title: Re: Grid of lighting scenarios as default for Orbiter
Post by: colinjones on January 29, 2009, 09:41:44 pm
presumably you would like the options for synchronous and asynchronous events? So that with a sync event, you can indicate whether the event subscription should trigger before or after, and with async it is implied that the event triggers in parallel. sounds quiet useful, actually :)