Still Getting Errors With 924

Tue Mar 1 11:29:32 EST 2016

Good morning James,

RE: "if you comment out that turnoff command there does the script then run from the scheduled event? or does the problem then move to the next unit?"

It still works manually, but I get the same error when trying to run it as a scheduled event.

RE: "These things were originally developed in the script editor and then pasted into XTension? Is that why it has an on run {} handler and all the XTEnsion stuff is wrapped in tell blocks? I don’t THINK that can cause any trouble, it should be OK, but once placed into XTension you can remove the on run{} block as it’s not necessary, and all the tell xtension stuff is extra too.”

Yes, you are correct, and even if both those sets of commands are commented out, it still works manually, but not as a scheduled event. However, by commenting out those two sets of lines of code, the error message has now changed to a set value error. David will be back by lunch, but has been receiving copies of everyone’s comments, and hasn’t seen this, but has already commented that he likes Phillipp’s idea, and is worth trying. 

3/1/16 9:59:30 AM Upper Level Value 34.0 —This was when the script was run manually
3/1/16 9:59:30 AM Lower Level Value 37.0
3/1/16 9:59:30 AM The latest new average temperature is: 35.5
3/1/16 9:59:30 AM Setting value of Current Temp Ave to 35.5

3/1/16 9:59:40 AM Scheduled Event: Send Temp Ave To David
3/1/16 9:59:40 AM Executing global script: Send Average Temperature to David #6
3/1/16 9:59:40 AM Send Average Temperature to David #6OSAError -1708: XTension got an error: "Current Temp Ave" doesn’t understand the “set value” message.

3/1/16 9:59:46 AM Scheduled Event: Send Temp Ave To David
3/1/16 9:59:46 AM Executing global script: Send Average Temperature to David #6
3/1/16 9:59:46 AM Send Average Temperature to David #6OSAError -1708: XTension got an error: "Current Temp Ave" doesn’t understand the “set value” message.
3/1/16 9:59:53 AM Received OFF for Kitchen LEDs North Ceiling PIR A12 (Basement East Weeder Boards)
3/1/16 9:59:53 AM Received ON for Library PIR Facing West G13 (w) (Center Hall W800)

> RE: "I have never tried such a thing and tested it and was not able to make that generate any errors, but I would still comment out the tell block as well as it just adds uncertainty to what I’m seeing, I’m not sure if that would cause strange things to happen under some circumstances or not."

For the record, it’s been working fine for us for months.

RE: “There are a couple of places where you’ve commented out a log line but left in the tell xtension block like:
> 
> 			tell application "XTension"
> 				--write log "Communication channel open to remote computer" -- For testing
> 			end tell"

I tried this too, and there were several places in the script to comment out. I thought you must be on to something, but now the script errors in another location.

3/1/16 10:10:07 AM Turning ON Bad Communications With Mini #1
3/1/16 10:10:07 AM Network communications problem. Bad Communications with Mini #1 4
3/1/16 10:10:07 AM Turning ON Bad Communications With Mini #1
3/1/16 10:10:07 AM Network communications problem. Bad Communications with Mini #1 4
3/1/16 10:10:08 AM Turning ON Bad Communications With Mini #1
3/1/16 10:10:08 AM Network communications problem. Bad Communications with Mini #1 4

RE: "Instead of using all those tell app XTension blocks, I would wrap the entire method or handler in a
> 
> using terms from application “XTension”
> 
> end using terms”

Yes Sir, that is in the process of being changed, and I’ll report back whether that made the difference 

Oh… something new to report. David also can’t duplicate my error, so it may be something germaine to my setup now. :-(

Thanks, and I’ll keep everyone informed as we continue tearing this down. I sure appreciate your, Phillippe's and Tom’s suggestions, as this one is really odd.

George

> On Mar 1, 2016, at 9:33 AM, James Sentman <james at sentman.com> wrote:
> 
> Firstly I’ve duplicated the part of the script that is causing the error and I cannot duplicate it here with a new unit by the same name.
> 
> the error is "Bad Communications with Mini #1" doesn’t understand the “turnoff” message.
> 
> so it’s an error in controlling the unit “Bad Communications with MIni #1”
> 
> The only turnoff commands in your script are in the initializeXTensionFlags() handler
> 
> on initializeXTensionFlags()
> 	tell application "XTension"
> 		turnoff "Bad Communications with Mini #1" -- Init this to off
> 		turnoff "Bad Communications with WeatherTracker" -- Init this to off
> 	end tell
> end initializeXTensionFlags
> 
> 
> if you comment out that turnoff command there does the script then run from the scheduled event? or does the problem then move to the next unit?
> 
> These things were originally developed in the script editor and then pasted into XTension? Is that why it has an on run {} handler and all the XTEnsion stuff is wrapped in tell blocks? I don’t THINK that can cause any trouble, it should be OK, but once placed into XTension you can remove the on run{} block as it’s not necessary, and all the tell xtension stuff is extra too.
> 
> There are a couple of places where you’ve commented out a log line but left in the tell xtension block like:
> 
> 			tell application "XTension"
> 				--write log "Communication channel open to remote computer" -- For testing
> 			end tell
> 
> 
> I have never tried such a thing and tested it and was not able to make that generate any errors, but I would still comment out the tell block as well as it just adds uncertainty to what I’m seeing, I’m not sure if that would cause strange things to happen under some circumstances or not.
> 
> Instead of using all those tell app XTension blocks, I would wrap the entire method or handler in a
> 
> using terms from application “XTension”
> 
> end using terms
> 
> block. That will let it continue to compile in the script editor but removes the necessity of all the rest when running inside XTension itself.
> 
> The other danger with tell blocks is that they try to find an instance of the app and sometimes can even startup extra instances of XTension if there are other versions laying around. 
> 
> It IS possible that you’re hitting some other bug in the turnoff handling that I’m not catching. I’ll do a special version with more error logging for you shortly to rule that out. But first please try commenting out the calls to turn off those units and see if the script runs OK or if the error just moves elsewhere.
> 
> 
> 
>> On Mar 1, 2016, at 9:51 AM, George Handley <ghandley at kc.rr.com <mailto:ghandley at kc.rr.com>> wrote:
>> 
>> Good morning Rich, and thank you for the idea. This is a different kind of bug to me in that this fairly complicated script works fine manually inside XTension and fine on a previous version of XTension, but will not automatically as a scheduled event in 924. I could better understand better if it didn’t work at all! :-)
>> 
>> Also, as usual, no one else has complained about this, so I’ve again painted myself into what appears to be a corner with a problem that must be unique to me systems. 
>> 
>> We’ll get it… we always do, but since this seems to only be something happening with James' newest build, I’m hoping he can easily see what is happening, and point me in the right direction for correction. It’s got to be something small and simple.
>> 
>> I’m going to answer Tom’s question next, and maybe with enough questions, a light bulb will come on here for us to understand what is different.
>> 
> 
> Thanks,
>  James
> 
> 
> James Sentman                       http://www.PlanetaryGear.org <http://www.planetarygear.org/>		http://MacHomeAutomation.com <http://machomeautomation.com/>
> 
> 
> 
> _______________________________________________
> XTensionList mailing list
> XTensionList at machomeautomation.com
> http://mail.machomeautomation.com/mailman/listinfo/xtensionlist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.machomeautomation.com/pipermail/xtensionlist/attachments/20160301/1fccb787/attachment.html>