Unit property variable reported as undefined or having 0 value

Rob Lewis rob at whidbey.com
Sat Oct 8 12:54:00 EDT 2016


Thanks. To clarify a few points: 

1. "show unit properties" reports the type as Number and the value as 40,
as expected. (That's the first thing I checked.) 

2. Yes, the timestamp is just the normal one that begins every log line. 

3. Note that the suspect "%" is in the _unit_ name, not the property name.
(In the past I've had quite a few issues with odd characters in scripts but
I think you've fixed all that?) 

4. There is no code that sets the unit property's value, therefore no typo.
I set it manually. I only read it in my scripts. I do this with lots of
other properties, with no issues I'm aware of. 

5. Not that it should have any bearing on this, but my internal hard drive
died a few days ago and I'm temporarily running the system off an external
USB drive that was cloned from my Time Machine backup (This is actually a
convenient feature accessible by booting in "restore" mode (hold Cmd-R
during boot). I'd never tried it before but it went smoothly. Except for
the failed and now unused drive, other drives have passed multiple
diagnostic tests.) 

Does this suggest anything? 

P.S. Off-topic rant: The mini's internal drive was a new Seagate 1TB that
died after only 13 months. It has a 3-year warranty, so that's covered, but
of course nothing covers the "hassle factor" of removing the drive, sending
it back, and waiting for the replacement (which is likely to be a refurb of
unknown life expectancy). As I constantly tell anyone who will listen,
users don't want drives with long warranties. _We want drives that don't
break!_ And if you pay more for an "enterprise class" drive, I don't think
you get a more reliable mechanism—you just get a longer warranty. If
you're a big server farm, you have hot spares available and you employ a
staff to find and replace dead drives—it's just a cost of doing business.
But if you're a poor, lonely user like me, a dead drive can ruin your whole
day, or even several days! Thanks for listening. 

> ----- Original Message -----
> 
> From: "XTension Discussion List" <xtensionlist at machomeautomation.com>
> 
> To:"XTension Discussion List" <xtensionlist at machomeautomation.com>
> 
> Cc:
> 
> Sent:Sat, 8 Oct 2016 11:47:46 -0400
> 
> Subject:Re: Unit property variable reported as undefined or having 0
> value
> 
> Do a show unit properties and see what it reports as the variable type. 
> 
> Is the timestamp you’re seeing the one the log always places at the
> beginning of every line? Or is it really turning the number into a
> timestamp? What I see from your logs is that you’re just getting the
> regular log line timestamp and then nothing after it. When you do “as
> number” I see the log line timestamp and then the 0 so that makes
> sense.
> 
> the names of the properties are just strings, no processing is done on
> their format or content at all, they are just hashed into a key that is
> used to lookup the value in a table. So yes, you have to put them in
> quotes (or use an applescript variable that contains the right string,
> thats fine too, but they are not programming constants or record keys
> that you can just write as if they were applescript code, you have to put
> them in quotes) So the percent shouldn’t matter.
> 
> The most likely answer is that there is just a typo in the code that sets
> the variable and so it actually has a different name and so when you go
> to get it it just returns an empty string. It really should return an
> applescript error instead of an empty string… But it’s never done
> that and I don’t want to break peoples code. I’ll have to think about
> that. 
> 
> The other possibility is that the code that is setting the variable is
> somehow sending a different text encoded name for the variable. I
> recently fixed some things in the vera interface that could set unit
> properties with the wrong encoding. They look exactly the same in the
> unit properties but you can’t then access them with regular applescript
> because while they draw the same they don’t hash to the same key value
> under the hood. If you’ve found another way to make that happen then
> I’ll want to fix that for sure. If both the setting and the getting are
> done from applescripts then this is unlikely though as applescript always
> uses the same encoding. It’s not impossible that there are ways to make
> it happen though that I’ve never seen.
> 
> So open the unit properties dialog for that unit and see what is actually
> in there.
> 
>> On Oct 7, 2016, at 5:54 PM, Rob Lewis <rob at whidbey.com> wrote:
>> 
>> Back to just the timestamp. What's going on here? 
>> 
>> My only guess is that maybe there's something about having a percent
>> sign in the unit's name.
> 
> Thanks,
> James
> 
> James Sentman http://www.PlanetaryGear.org [1]
> http://MacHomeAutomation.com [2]
 

Links:
------
[1] http://www.PlanetaryGear.org
[2] http://MacHomeAutomation.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.machomeautomation.com/pipermail/xtensionlist/attachments/20161008/36fff428/attachment.html>


More information about the XTensionList mailing list