Rebooted and it installed! :-)
I'm still struggling to dive into Andre because of the current challenges in passing variables back and forth with any delay but confident in figuring out a soultion. I thought of a really cool feature to request. WHow about a widget that would allow the use of Andre from the desktop? I'm thinking a person would have a special widget configuration with limited regularly used buttons (volume, mute, channel, etc)...
I'd like to hear more about what you're trying to do and what's not working for you so that I can improve things better. Between the timer support and most especially the cloud push notifications there should be more than adequate support for variable exchange with virtually no delay.
Can you give me some example scenarios where you're trying to pass variables to/from Andre? I'm in the middle of cooking up some clearn Girder-oriented examples of both timers and push notifications for people which should help kickstart people's experimentation, I'll likely have something to post by mid weekend. In the meantime I'd love to help someone wade through the process once to get a feel for where things are unclear or daunting.
That's definitely a great idea, I've dreamed about the widget idea a lot, especially for essential items like volume controls. Ultimately I've ended up deferring the design several times because I wanted to make sure the architecture for the main app was fairly solid and unchanging before layering a dependency on top of it.
HTLuke,
I don't want to use the clould support for variable passing as it's very important that there are no delays. I had explained my setup in earlier post but basically my NR remote has a single set of buttons for everything. I have drop down to select a zone, I have a output button that toggles through outputs (tv, pj, amp) and input buttons that set the input (dvd, music, sat, ps3, etc). Each button then sends the girder code based on the variables (i.e. {ZONE}.{INPUT}.{OUTPUT}.action) which would show up something like "Theater.PJ.DVD.play". Although I probably can do this part with Andre as it is I need to pass variables for things like toggling the INPUT button. If I send TV then some girder code send back the next device for that zone in a variable or the same device if there is only one device. With more real estate on the screen I could probably have discrete buttons for INPUT therefore I would not need to pass the variables back and forth however girder keeps track of last input/outputs in the zones so if I switch between zones girder sets the variables for that zone based on that input and output I used in that zone. Girder also keeps track of last OUTPUT for each INPUT so let's say I push Music (INPUT) it sets the OUTPUT variable to AMP but if I push Sat it would set the OUTPUT to TV. I may however have different combinations of INPUTs and OUTPUTs so I don't want this to be static. So basically I need a way that when I push a button I can send some variables to girder, process those variables and have girder set variables in Andre instantly. I've been thinking about who I could do this with an http response. Probably wouldn't be difficult for a single variable but in many cases girder will set at least 2 variables in NR after a button push. If I had a way to parse out a string I would be easy as that is already what I don't from NR to Girder.
So for an example. I select my Theater zone from a menu in NR. It sends the zone to Girder along with the device ID. Girder looks up the device ID and ZONE then sends back to NR (INPUT = DVD and OUTPUT = PJ). If I push the Sat button girder will look up and see that in the Theater room I last used the TV with Sat and set the variables. So on my remote I be in my theater, have a PJ and TV on and with a single push on the remote (Sat or DVD) it will automatically change the OUTPUT device based on what was last set with that INPUT device.
I hope this helps explain my setup a little. I came up with this after years and years of using NR. It's very dynamic, only requires minimal buttons (mostly 1 layer) and can be expanded or modified very easy. Also gives my a lot of control on the girder side which I like. I think if Andre could talk to EventGhost on Android I would probably use EventGhost to pass the variables and I might eventually switch everything over to EventGhost cause I can't see Girder ever coming out with a native Andriod client for Girder since they refuse to make anything native for NR. Very disappointed in the direction Promixis is taking...
Thanks and keep up the great work...
Last edited by rkirmeier; June 18th, 2011 at 02:39 PM.
Thank you for the detailed explanation, it gives me a lot to consider. Let me step through your situation and think out loud, and you can confirm that I'm getting the gist of your setup.
Absolutely no criticism is intended from the questions, btw, I think your solution with NR is pretty damn cool considering it makes things "just work" for the end user without a lot of nonsense and complications you normally get from universal remotes.I'm just trying to educate myself on the details of your implementation and the decisions behind them so I can accomodate those in Andre as best I can.
Ok, this makes sense, you need synchronous variable updates because you're not updating some Girder state (e.g. your porch light turns on at dusk via a timer and you want Andre to reflect that state change, or you changed something via another remote and want it to update on all others). The cloud stuff is fast (usually within a second) but there's no guarantee, and I've seen hiccups of 10-30 seconds happen often enough (once or twice a day while testing) that you certainly wouldn't want it for this application.
Ok just for my own clarity, in your current config the remote client isn't explicitly tracking input/output state itself; there's two buttons that just says 'advance to next input/output' and that command gets sent to Girder which manipulates the current input/output variable to step to the next one? And Girder sets a variable back in NR to tell it what input/output is currently used. Similarly if you select a zone from NR, it sends that to Girder which replies with the current (last used for that zone) variables for NR to use for the buttons.
One question; do you change something on the NR screen based on the variables to reflect the current input/output, like update a text field or graphic? I ask only because if you weren't, there would seem to be no reason to pass variables back and forth, you could keep all the variables on the server and figure out what button-press does what there instead of in the client.
Why couldn't you flip to a screen that just lists inputs/outputs and then switches back to the screen when you've selected it, or use drop-downs for input/output like you do for zones?
I'm guessing the above is why you can't just have a drop-down/separate page for inputs/outputs, though you could do some very creative button manipulation triggered off the zone choice to hide/show the relevent inputs/outputs perhaps.
Definitely would make sense to do as an http response; select the zone on the remote, which posts the web service call, Girder does its thing synchronously and then returns the updated variables as the response. Regarding parsing multiple variables, you have that capability now.
In the button that would change the zone for example, just have the serviceParams Parameter stuff the response into a variable, then below that Parameter on the same Button use a script parameter to run some javascript to parse out the reply as necessary and .setVariable() to all the Andre variables you need changed.
Technically Andre is already capable of listenening to EventGhost, but (the last time I looked into it) EventGhost for Android doesn't post a variable payload in it's Android Intent calls so you can't pass data from EventGhost to Andre.
The other direction should also already be feasible because EventGhost has an HTTP plugin so you'd just make your Buttons serviceUrl and related settings point to localhost. But that's worthless until EventGhost can pass data back to apps that it launches in a way that they can be intercepted and processed.
I recently began adding UI-based interaction Parameter calls to do stuff like get text input from the user. I've totally overlooked drop-downs or select lists, which I'll add to my backlog and get implemented very soon.
I'm still waffling on the idea of opening a dedicated listener http server on the device, and someday I may just jump in and do it and see what the impact is. But for almost any use case I've heard, the combo of synchronous http response and cloud push notifications should be quite sufficient, and are more in line with Android's functional design pattern overall (e.g. Android's "deep sleep" battery-saving mode would be rendered useless with a socket being left open all the time, and Android is aggressive at memory management even with services so guaranteeing you stay running is a chore in watchdog timer threads and other bad behavior).
Oh, just letting my mind ramble through the angles on this, if ever there's a situation where one service call sets some server-side computation running but you don't want to wait for the response right then but can reasonably guarantee the results would be ready in a particular time frame (lets say 2 seconds) then another thing you could do is trigger the web service call from a Button, then below that trigger an Andre timer set for 2000ms which goes and simply fetches variable values from Girder. That way you don't have to figure out how to get the input web service call operation to return everything you need synchronously but get an essentially synchronous behavior.
Ok, that's enough pondering for one post. I'm trying to polish up a new build with bug fixes and a few new capabilities but I want to get some clear, real-world examples of the scripting and variables and push/pull notifications in place first. Maybe I'll have something late tonight.![]()
I could see using the cloud support for certain things that may bot be triggered by a button but as you can see I need to be sure I get a response in an instant.
I might have to post a picture. I think you mostly understand it but maybe a little cloudy on a few things.
So on my top of my remote I have a row a buttons. The first button is the OUTPUT button. When pushed it sends a girder request with it's current value and girder responds with the next OUTPUT device in this zone. The label on the button is the value of the variable so it may show "TV" and I push it then it shows "PJ" then I push it and it shows "AMP". The label is the OUTPUT variable which is also used on all other keys to send data to girder.
Next on the top row of buttons is the INPUT device buttons (4). These are SAT, DVD, MP3, PS3. When one of these are pushed it sets the value for the INPUT variable but also tells girder I am changing to that device. For example I push the SAT button and my INPUT variable = SAT and the button send code telling girder I am in the Theater ZONE and INPUT is SAT then girder looks up what OUTPUT device I last used in the Theater for SAT. Girder then sets the OUTPUT variable to, for exmaple, "PJ". Now the OUTPUT button shows "PJ" and the OUTPUT variable is "PJ".
This same type of history logic is used when selecting a zone. Girder will set the INPUT and OUTPUT variables to the last values they had the last time I used that ZONE. So if I am switching between zones it's a single click and I am right back to the same INPUT and OUTPUT I used last time.
Now the rest of my buttons are really very basic. The VOL+ button for example would make a call to girder using variables like for example. The code in the button would look like BUTTON({ZONE}.{OUTPUT}.{INPUT}.play) where I have a event trigger for a script on girder called "BUTTON" and the variables are sent as a payload. So on the girder side the BUTTON script would receive a payload in pld3 of, for example, "Theater.PJ.DVD.play". That one "play" button in the config that works for every zone and every device. 95% of my buttons are like this with just a couple device specific buttons. These are generally turned on my a state control via a variable.
A lot of the ideas in my design are to minimize button pushes to control things. I hate it when you need to push 2 or 3 buttons to get something done. So that is why I would not like to use another screen.
Why couldn't you flip to a screen that just lists inputs/outputs and then switches back to the screen when you've selected it, or use drop-downs for input/output like you do for zones?
There are personal and technical reasons. Could my design be altered, yes. But I really don't want to and all logic is on the girder side. All I really need is a good way to pass variables back and forth which sounds like I probably already can do this based on info below.I'm guessing the above is why you can't just have a drop-down/separate page for inputs/outputs, though you could do some very creative button manipulation triggered off the zone choice to hide/show the relevent inputs/outputs perhaps.
Interesting! I'll have to play around with this. I don't really know javascript so it might be interesting. Any chance you could build a sample button in your next config for passing a single variable back from a http response. At least that would be half the work then I could try to figure out parsing multiple variables with javascript.Definitely would make sense to do as an http response; select the zone on the remote, which posts the web service call, Girder does its thing synchronously and then returns the updated variables as the response. Regarding parsing multiple variables, you have that capability now.
In the button that would change the zone for example, just have the serviceParams Parameter stuff the response into a variable, then below that Parameter on the same Button use a script parameter to run some javascript to parse out the reply as necessary and .setVariable() to all the Andre variables you need changed.
I didn't realize these limitations. I do like the http response method better anyways and with your cloud based stuff I probably wouldn't need to deal with Eventghost at all then. Don't really want to rewrite any girder logic in event ghost anyways!Technically Andre is already capable of listenening to EventGhost, but (the last time I looked into it) EventGhost for Android doesn't post a variable payload in it's Android Intent calls so you can't pass data from EventGhost to Andre.
The other direction should also already be feasible because EventGhost has an HTTP plugin so you'd just make your Buttons serviceUrl and related settings point to localhost. But that's worthless until EventGhost can pass data back to apps that it launches in a way that they can be intercepted and processed.
Yeah, drop down in very important on my cell phone because of the limited space but on the tab I could probably just layout the zone buttons although I think I have like 8 zones now!I recently began adding UI-based interaction Parameter calls to do stuff like get text input from the user. I've totally overlooked drop-downs or select lists, which I'll add to my backlog and get implemented very soon.
Thinking of this and the widget idea I mentioned. Think how cool it would be if a person could take there entire "phone" interface and make it a widget on a tablet desktop! I don't know that I would actually even do a full tablet interface then cause that would be awesome!
I can understand that and I think http response for button presses would work great. Other variable needs should fine using cloud services.I'm still waffling on the idea of opening a dedicated listener http server on the device, and someday I may just jump in and do it and see what the impact is. But for almost any use case I've heard, the combo of synchronous http response and cloud push notifications should be quite sufficient, and are more in line with Android's functional design pattern overall (e.g. Android's "deep sleep" battery-saving mode would be rendered useless with a socket being left open all the time, and Android is aggressive at memory management even with services so guaranteeing you stay running is a chore in watchdog timer threads and other bad behavior).
[/QUOTE]
Oh, just letting my mind ramble through the angles on this, if ever there's a situation where one service call sets some server-side computation running but you don't want to wait for the response right then but can reasonably guarantee the results would be ready in a particular time frame (lets say 2 seconds) then another thing you could do is trigger the web service call from a Button, then below that trigger an Andre timer set for 2000ms which goes and simply fetches variable values from Girder. That way you don't have to figure out how to get the input web service call operation to return everything you need synchronously but get an essentially synchronous behavior.
Ok, that's enough pondering for one post. I'm trying to polish up a new build with bug fixes and a few new capabilities but I want to get some clear, real-world examples of the scripting and variables and push/pull notifications in place first. Maybe I'll have something late tonight.![]()
Thanks again!
Last edited by rkirmeier; June 18th, 2011 at 06:23 PM.
Ah, thanks for further clarification, I have a much better idea how things are working.
I'm fixing one bug right now related to the pop-up selection list (a piece of the drop-down solution I'm cooking up), and then I'll write up a clean and clear example of the service call to Girder with an http response attached and how to use it. I'll even make it return multiple variables and include a piece of javascript to parse it out into discrete Andre variables. Hopefully that won't take me too long, but I might not have it ready to post until tomorrow afternoon sometime.
That's so awesome! Thanks! My girlfriend is not going to be happy for the next week or so! Lol!
HTLuke,
Very interesting discussion. I'm still working through the Andre config, but I though I would give you some input on one way I use data transfer between my NetRemote system and Girder.
My primary NetRemote page is the one where I control my Insteon switches. I have Insteon switches all over the house plus quite a few wall plugs. All together there are about 40 Insteon devices. To use them
I have a one page floor plan where every device is a separate button. The buttons for lights show up as light bulbs, which change color based on light level. My two fountains change images if they are switched on/off.
So I can tell at a glance what lights are on all over the house and what their levels are. I use lua variables is to keep track of status of each switch, either on/off, level, and if possible whether a device is plugged in. The status
variable for each switch is updated if I make changes directly from NetRemote or if I hear from girder that a switch value was changed directly. How fast the data is updated from girder is very important if I am trying to dim
a light and don't want to overshoot. Also if I change several lights using a Insteon scene command I want all changes to show up smoothly.