(Sorry if this is answered elsewhere. I searched for quite a while.)

I'm just trying to set a sprinkler multiplier based on the NOAA data. I've set it up as a device in Indigo 5, and it shows the "States" just fine. (Currently 103°F here.)

So all I want to do is something like:

Code: Select all

tell application "IndigoServer"
   set value of variable "sprinklerDurationMultiplier" to (("temperatureF" * 3) - 100) * 0.01
end tell


Now, I know that's not right — I tried various Applescript syntax but I'm no programmer. How do I get Indigo to get that NOAA variable (device state) to work here?

Thanks much in advance.
- Ryan

Being discussed here:

viewtopic.php?f=5&t=8467&start=15



If you look at the last few posts, you'll get a better idea of how to set it up. I'm using a Rain Gauge to determine the value of my multiplier.

Thanks, but I'm still lost. I'd seen that post before actually. I just don't see the obvious answer of where to get the "temperatureF" value for the "device" called "Weather". Seems to me I'm just missing some otherwise-obvious syntax.

Something like this should work (untested):

Code: Select all

tell application "IndigoServer"
   set curTemp to value of variable "temperatureF" as number
   set value of variable "sprinklerDurationMultiplier" to (((curTemp * 3) - 100) * 0.01) as string
end tell


The main point being that you need to get the current value of the "temperatureF" variable, convert it to a number so it can be used in a calculation, then convert the result of the calculation back to a string before assigning to to the "sprinklerDurationMultiplier".

d3h872 wrote:Thanks, but I'm still lost. I'd seen that post before actually. I just don't see the obvious answer of where to get the "temperatureF" value for the "device" called "Weather". Seems to me I'm just missing some otherwise-obvious syntax.

There are several ways to skin that cat; the information is all out there, but it's so spread out that a lot of folks aren't willing or able to dig it out. The "temperatureF" value of the NOAA device is a "State" in a plugin variable, and as such can't be seen in a number of places in Indigo. It CAN be seen in the "conditions" tab of a schedule, trigger, or action group, so if all you want is to do or not do something if it is greater than, less than, or equal to some value, you can put it there.

But if you want to do some add, subtract, multiply or divide in order to change up a time or intensity, then you have to move it into an Indigo "variable", which is visible from a lot more places (specifically scripts and Touch). And the best way to do that is to create a "MyTempreature" variable and set up a trigger which copies the value of the State to the variable every time it changes using the Action Group Plugin. Basically create a new trigger that says when device NOAA's tempreatureF State has any change, action is Plugin Action Collection Action is copy State to Vaiable. You can then use either AppleScript (Value of "MyTemperature") or Python (float(Indigo.Variables[variable ID].value)) to get it into the script as a number and diddle with it however you need to. And the code snipits that we have put out there will give you an idea of the exact syntax needed to manipulate and get the result back into the variables you need to.

Ah, yes, sorry, it's a device state. This Python script should do the trick in that case (Python has access to device states):

Code: Select all

curTemp = float(indigo.devices[DEVICEID].states["temperatureF"])
indigo.variable.updateValue(VARIABLEID, value=str(((curTemp * 3) - 100) * 0.01))

jay (support) wrote:Ah, yes, sorry, it's a device state. This Python script should do the trick in that case (Python has access to device states):

Code: Select all

curTemp = float(indigo.devices[DEVICEID].states["temperatureF"])
indigo.variable.updateValue(VARIABLEID, value=str(((curTemp * 3) - 100) * 0.01))

Two quick questions that are probably already answered elsewhere, but I'm too lazy to search for:

1) Does that work for states in Plugin type devices?
and
2) Are all device states strings (like variables are)?

Thanks! I'd never have gotten there on my own. Would be great if future versions made this easier.

I look forward to trying this when I get home.

Works great, thanks again!

Maybe this should be in a separate topic under the Python forum, but the reason for my above question goes back to some earlier efforts I made with devices. Could you give some insight into why

Code: Select all

##This works...
curTemp = float(indigo.devices[DEVICEID].states["temperatureF"])
indigo.variable.updateValue(VARIABLEID, value=str(((curTemp * 3) - 100) * 0.01))

##This DOESN'T work:
indigo.variable.updateValue(VARIABLEID, value=indigo.devices[DEVICEID].states["temperatureF"])

##But it can be made to work by changing it to
indigo.variable.updateValue(VARIABLEID, value=str(float(indigo.devices[DEVICEID].states["temperatureF"])))


It seems if you don't go through the float (or int, I suppose) followed by string conversion, the device.state property is returning something that the variable.UpdateValue method does not interpret as a string...

Can you give more details about what you see when it does not work?

Is there an error in the Event Log (copy/paste it if that is the case), or does it just not update?

matt (support) wrote:Can you give more details about what you see when it does not work?

Is there an error in the Event Log (copy/paste it if that is the case), or does it just not update?

I think I see the problem... updateValue() wants a string for the argument I believe, so you will need to cast it as a string. We might handle the conversion internally in a future version.

So, here are the specific answers to your questions:

1) Yes - this thread in fact is talking about a NOAA weather station device (I think).

2) No - states have types associated with them. There is a catch (which I guess I wasn't aware of) for plugin devices - when a plugin calls updateStateOnServer for one of it's devices, the state value will be set to whatever you pass in the value parameter, type and all. So, even though a plugin device may define a state's type to be an integer (in the Devices.xml), if you later set the value to a string then the state value will become an string. Matt and I are discussing that and we may change it in future versions of the API. I notice that the NOAA plugin does this (sloppy mistake on my part) and probably others as well.

As for this not working:

Code: Select all

 indigo.variable.updateValue(VARIABLEID, value=indigo.devices[DEVICEID].states["temperatureF"])

Matt's right - variable values are always strings so you have to cast it to a string first (something we may consider doing automatically in the future). Note, however, that that exact line should work if the device is a NOAA Weather weather station - despite the fact that I have the states defined as a number apparently I'm actually setting it as a string.

If you open the scripting shell and print a device (print indigo.devices[DEVICEID]), it will show the type for all states if you can't figure out what the value is.

jay (support) wrote:No - states have types associated with them. There is a catch (which I guess I wasn't aware of) for plugin devices - when a plugin calls updateStateOnServer for one of it's devices, the state value will be set to whatever you pass in the value parameter, type and all. So, even though a plugin device may define a state's type to be an integer (in the Devices.xml), if you later set the value to a string then the state value will become an string. Matt and I are discussing that and we may change it in future versions of the API. I notice that the NOAA plugin does this (sloppy mistake on my part) and probably others as well.

Ahhhh, got it; Plugin states are like a "box of chocolates", you never know what you're going to get. Even if it LOOKS like a number in the UI, short of being able to find and read the device.xml, run a print in a scripting editor, or have a really good plugin users guide, you don't know if you're getting a string, int, or float unless you explicitly convert it yourself. Which explains a lot of scripting failures I've had.

Right - the best thing to do if you're scripting an unknown plugin is to inspect it in the scripting shell (that will always show the type of the value as it currently stands). Either that or just cast it to what you want it to be before using it.