>> Several questions - You said you were using RFX9600 for serial. >> In your startup script is it only 1-way serial or do you need 2 way?
I need 2 way. My processor and projector are connected via RS232 to my RFX9600 so I can check their state.
>> buzz: I also keep track of a unit's power status (when practical) >> because there is no point in waiting 60 seconds for a projector >> if it is already warmed up.
Same here. If the projector is already on, I don't do any waits. The RS232 queries allows me to use the same function regardless of whether they are powered on or not. The timings of how long the processor and projector take to start don't change (unless I buy new equipment), so instead of re-polling their power status after initially querying their status and starting them, I've already accounted for how long they take to start, and have coded the script with appropriate "please wait" times. Also, depending upon the device, just because its RS232 says it has already "powered on", doesn't necessarily mean it's ready to accept new commands (such as switching inputs). Hence, an additional delay after the device says it has powered on state may still be needed.
I really only need the "please wait" displayed in the scenario where the projector needs to be powered on, given how long it takes. I like to have a friendly "please wait" dialog box for users so they can see the percent complete, so they know there is progress and they don't think the Pronto has hung.
>> Do you have any raspberry pi's in your setup?
Yes. (Aside: I have a pi connected to an APC UPS via USB. The pi runs apcupsd, which the Pronto queries via getHTTP so it can display UPS data). I use the RFX9600 for both IR and RS232. Using a Pi for my Pronto seems interesting, but may be more than what I want to tackle at this time.
>> ...use scheduleAfter and an array of objects that >> serve as your task queue.
I tried searching for "task queue" in this forum, but I didn't see particularly relevant hits. I'll need to look more.
Anyway, based on my testing, it looks like getHTTP() calls are not processed at the time they are called. They are processed after the calling function/script has finished/returned. I decided to simplify things. Rather than calling multiple getHTTP() calls inside my HTSystemOn() function, I consolidated all the light control commands into one HomeSeer event (automation task). My plan was to have one HomeSeer event do all the turning on and turning off of all my lights with the necessary delays in between. It would be HomeSeer's problem rather than Pronto's. All Pronto needs to do is call one HomeSeer event and the HomeSeer event will handle the light show while Pronto worries about turning on components.
Previously, HTWatch() called the HomeSeer events to turn on/off the lights, while turning on the processor, projector, displaying "Please Wait", etc. I changed HTWatch() to remove all the getHTTP() calls that send commands to HomeSeer, so I changed the above Button script to:
// use runEvent() function which uses 1 getHTTP() call to invoke a // HomeSeer event to do the light show: runEvent("Pronto", "Pronto - Lights - HT Startup"); if (HTWatch("Shield") == true) { this.scheduleActions(); // Jump to Nvidia Shield device's activity }
From my testing, the getHTTP() call that runEvent() invokes does NOT run until after HTWatch() finishes. So, the HomeSeer event isn't called until AFTER a minute after runEvent() is called, and the projector has fully started.
I guess this is just how the Pronto engine (or at least getHTTP) works? Seems that Pronto just puts any getHTTP calls in a queue and invokes them only after the calling script has finished?
Any easy solution to this? Using executeActions(), scheduleActions() or scheduleAfter() in order to run the runEvent() function BEFORE HTWatch() doesn't help. Or maybe I should use scheduleAfter() to invoke HTWatch() instead, so that runEvents()'s getHTTP() is called BEFORE HTWatch() is processed?
I have a couple of other options if I don't have luck with this...:
1. I have a relay that flips when my processor turns on. A sensor is connected to the relay, which HomeSeer monitors. If HomeSeer senses that they relay has flipped, I can have HomeSeer run the HomeSeer event to do the light show... Only disadvantage is if I'm just doing maintenance (turning things on and off manually), I may not want a light show.
2. Upgrade my bulb-based projector to a new laser projector... The new laser projectors start much faster... Oh, that's too expensive a solution for this problem :-).
