SWRemote 'private' variables

yaccri · Post by **yaccri** » Mon Oct 31, 2005 6:27 am

I want to be able to set properties that belong to the SWRemote rather than to HB.

The SWRemotes should be competely independent of each other.

Usage example: Select an area in the house and then run a task that changes the radio channel only in that area, without affecting (or being affected by) changes made by other SWRemotes.

Is there any way of keeping private properies for each SWRemote, or alternatively to determine which remote made a certain change?

Circe640 · Post by **Circe640** » Sat Nov 05, 2005 1:33 am

The only way I can think of this is to create separate themes for each SWREMOTE. Each SWRemote theme would use properties that are only used by that theme. Aternately you could have a common theme but the first panel would represent a menu that would then diverge into different sets of subsequent panels where the panels would be location specific and have their own distinct HB properties

Circe640 · Post by **Circe640** » Sat Nov 05, 2005 1:35 am

It would not olnly require unique properties by theme/panel but also unique tasks by theme/panel

yaccri · Post by **yaccri** » Sat Nov 05, 2005 5:01 am

I want to avoid duplicating themes.

It would be much better if each SWRemote would *automatically* use a different set of variables.

Maybe it's possible to use the main panel to run a task at logon. I'll give it a try.

dlmorgan999 · Post by **dlmorgan999** » Sat Nov 05, 2005 7:35 am

I have a fairly extensive configuration and the only way I could get to work was by using separate themes (I have six of them!). The main difference between these themes is which zone of my audio/video distribution system is affected for things like volume change and source selection. If you figure out a better/different way I'd love to hear about it.

-- Dave

Post by **ScottBot** » Sat Apr 29, 2006 7:05 pm

I'm trying to get an understanding of how you would want this to work. Please let me know:

How would the private variables get set? By a button press, or panel init/exit list?
How would this be leveraged to send the variables to the server? Would you just use a variable as the value of a property in an Property Value change action?

dlmorgan999 · Post by **dlmorgan999** » Sun Apr 30, 2006 12:29 am

What would really help my situation is to be able to determine which software remote (maybe by theme name or something) triggered a script or task. This would reduce the number of scripts I need to support my DVD changers from 30 to about 6.

I'm not exactly sure what's possible but it would be nice (for example) if you could pass the theme name (or remote name or something that uniquely identifies the remote) as a parameter to the script (does VBscript allow passing parameters to a sub?).

To answer your questions though, it seems to me that it would be most logical to set private variables via panel init/exit. Trying to figure out how to pass it back to the server is the tricky part.

I have one idea to throw out but I have no idea how hard this would be. Since you are already tracking the active software remotes, would it be possible to add the ability to store private variables there?

The "elegant" solution would be to have something like "Remote Name.Property Name" (similar to devices/properties). You might even be able to support enumerating the list of active remotes and also enumerating the available properties for a given remote (GetRemoteList and GetPropertyListForRemote?).

A structure like this might also accomodate being able to open a named panel on a specific remote (possibly you could overload the OpenRemotePanel function to add a second parameter for remote name?). This is another feature that a number of people (myself included) have wished for in the past.

-- Dave

Post by **Richard Naninck** » Sun Apr 30, 2006 4:21 am

I guess just 1 script could do it all.
If you create a NULL Device and some multistate buttons like used for the Onkyo receivers input source, you could select the DVD player you want to address using the multistate buttons. If you select one source, you deselect the other so only source can be active. Now 1 null device property holds a text label of which DVD player should be addressed. Pressing a DVD IR button command should not send out the IR code directly, but should put a IR text code into another null device property. Create a running script, or a task that sets the script to running if the IR text property is changed. The script then reads the source null device property and the IR text property and handles it from there. This is the way I have set up most of my scripts and it works very nice.

The source buttons should work like this:
Just create normal property change buttons putting the right source into the null device and have a multistate indicator set the selected state.

DVD Living room: Button -> IR Source = DVD Living Room, Image States: = DVD living room -> image 1, != DVD Living Room -> image 2

DVD Cinema room: Button -> IR Source = DVD Cinema Room, Image States: = DVD Cinema Room -> image 1, != DVD Cinema Room -> image 2

DVD Bed room: Button -> IR Source = DVD Bed Room, Image States: = DVD Bed Room -> image 1, != DVD Bed Room -> image 2

This way the indicators track the selected source and the null device holds the source so the script can determine which UIRT led to address or which code to send. I know that this would mean lots of work, but it is a way to get around this!

yaccri · Post by **yaccri** » Sun Apr 30, 2006 7:06 am

Richard,
That's the work-around that I'm already using, but its far from perfect when more than one SWRemote is running.
When a SWRemote client selects a source, it affects the other clients and makes that source the active one for ALL users.
The user needs to pay attention to the source before pressing the action button.
I would like for example to have one button in the main panel to control all the A/Cs in the house. Each room has its own A/C and in a different panel.
Entering a panel can trigger the source' change. However, if another session of SWRemote is running, it will affect these 'global variables'.
That is the reason for having 'local' or 'private' variables.

I think that every SWRemote should have a unique name that HB can identify.
Then maybe create a device for each SWRemote (with SWRemote name and number as identifiers). The programmer will be able to add 'private' properties to this device. It would be ideal to be able to define scripts that are 'SWRemote aware', without having to duplicate scripts or lines of code.
For example, I would like to be able to define something like:
If property1 was changed by either 'SWRemote devices', run a script or a task.
Also, The script or task that is being called should be aware of the activatnig SWRemote, and be able to retrieve properties from that device.

Not a simple request, I know. But now that Scott is back, everything is possible :)

Post by **Richard Naninck** » Sun Apr 30, 2006 7:41 am

yaccri,

You are right, that would be the preferred option. I am still in the Meedio era where nothing was possible and all there would ever be were workarounds. That has changed now! I could think of many ways to use this. Multiroom audio, temperature control etc etc. Nice suggestion!

yaccri · Post by **yaccri** » Sun Apr 30, 2006 8:05 am

The Meedio ice age is over!
You are welcome to review the feedback forum that relates to the times before Meedio, to realize how supoprt used to be.
Even when Scott states that he is busy with other things, the support he gave only in the last week is a lot more than the 2 years support of Meedio.

Post by **Richard Naninck** » Sun Apr 30, 2006 8:22 am

I know. Scott fixed three long standing bugs this weekend that were bugging me, but had worked around because of the lack of support:

- SWRemote status hang up -> more than 29 status properties on same panel
- IR Code Number Received -> allow same value BUG
- Script Device memory leak -> Running large scripts over and over consumed memory

I couldn't be more happy that Meedio is out of the loop and things are done the way they are now without having to wait for unanswered support tickets.

dlmorgan999 · Post by **dlmorgan999** » Sun Apr 30, 2006 10:15 am

Originally I was doing something very similar to what Richard suggested but then I discovered the same issue that yaccri described. I often times have "movie parties" at my house and I have two main viewing areas. I didn't want changes made in one area to affect the other area. That's why I would love to be able to know which remote made a request.

There's also another reason I have more script for DVD control per zone. I don't actually directly select which DVD changer I want to use. Instead I have a DVD selection form that is database driven. Once a particular zone selects a DVD a script runs that automatically selects the correct input in that zone for the required DVD changer (the changer number comes from the database). I currently have separate scripts for each zone but these could easily made into one "mega-script" as long as I could determine which running remote called the script.

By the way, I most definitely agree with your comments regarding Scott's support. Even though Scott is the only person doing support AND he's very busy playing catch-up AND this isn't his "regular" job he's STILL done more in two weeks than Meedio did in two years! In case people don't realize this most (all?) of the updates in the only HouseBot release that Meedio ever made were done by Scott.

Post by **Richard Naninck** » Sun Apr 30, 2006 12:04 pm

Wasn't the HB / Meedio connector written by Alan?
Well that doesn't really count as an update;)