kpfriedberg wrote:

support wrote:

kpfriedberg wrote:Is it possible to have some of the 'device states' be a variable? Specifically, I'd love to have the airtemp be a variable that some of my HVAC triggers rely on rather than using the NOAA weather script just because that script uses a nearest weather fetch station that is 20 miles from me.

Why does it need to be a variable? You can trigger off of device states, and Indigo 5 lets you use device states in conditionals.

That said, there is an action in the Action Collection plugin that can copy a device state into a variable value. But I'm not sure you really need to use it.

So I can say, turn on my radiant heat if the device state airtemp created by Jim's plugin is <= an integer?

Guys,
All i can find in the trigger is if Device State Changed either "Has Any Change" or "Becomes Equal/Not Equal To", I don't see a way to trigger something if, in this case, the Jandy Plugin Device "Air Temperature" is less than a value. Am I missing something?

Did you select your pool device? The popup just under the device popup and above the "Has Any Change" popup should have a list of all the states for the pool device.

jay wrote:Did you select your pool device? The popup just under the device popup and above the "Has Any Change" popup should have a list of all the states for the pool device.

Yes, there is no 'less than' option like variable changes...I assume I'll have to run the Action Collection plugin and then create a schedule to update the variable periodically so I can monitor AirTemp...

Use "Has any change" then add a device state condition to verify that the temp is less than whatever you want it to be.

Jim has the type for the temperature set incorrectly in his device states - if he specified it as a number of some type it would show "Becomes Less Than" and "Becomes Greater Than" - it's probably just a big that he can fix.

jay wrote:Use "Has any change" then add a device state condition to verify that the temp is less than whatever you want it to be.

Jim has the type for the temperature set incorrectly in his device states - if he specified it as a number of some type it would show "Becomes Less Than" and "Becomes Greater Than" - it's probably just a big that he can fix.

Can't do that. In the Condition tab only options are "equal to" and "not equal to", I checked that before

Btw. I didn't set up the airtemp device type, it was automated by Jim's script.

kpfriedberg wrote:Can't do that. In the Condition tab only options are "equal to" and "not equal to", I checked that before

Duh (I'm apparently slow tonight) - yep, the same bug that's not showing it in one place won't show it in the other.

kpfriedberg wrote:Btw. I didn't set up the airtemp device type, it was automated by Jim's script.

Exactly - that's what I'm saying. His plugin device type has a bug in the state definitions that he needs to address. When he fixes that then airTemp should show the additional comparisons.

In the meantime, you can just create a separate "Has Any Change" trigger that inserts the state value into a variable then use that variable in your original trigger rather than using device state change. It's a workaround for the bug but it should work.

jay wrote:

kpfriedberg wrote:Btw. I didn't set up the airtemp device type, it was automated by Jim's script.

In the meantime, you can just create a separate "Has Any Change" trigger that inserts the state value into a variable then use that variable in your original trigger rather than using device state change. It's a workaround for the bug but it should work.

Got it...Thanks!

jay wrote:

kpfriedberg wrote:Btw. I didn't set up the airtemp device type, it was automated by Jim's script.

Exactly - that's what I'm saying. His plugin device type has a bug in the state definitions that he needs to address. When he fixes that then airTemp should show the additional comparisons.

In the meantime, you can just create a separate "Has Any Change" trigger that inserts the state value into a variable then use that variable in your original trigger rather than using device state change. It's a workaround for the bug but it should work.

Sorry guys - busy at work the last two weeks, and hard to think about pools here in PA in Dec.

In any case, I will change all of the temperature states from string to integer, but will not be able to test it myself. I will send directly to you by e-mail (kpfriedberg) and you can test and let us know here if it works.

Jim

P.S. All of the Actions, and all of the command structure is text based, which is why I didn't set up the states as integers to start. Therefore, it may take me a while to make all the necessary changes, and will, unfortunately, be difficult to debug without my serial adaptor and pool turned on.

jay wrote:Jim has the type for the temperature set incorrectly in his device states - if he specified it as a number of some type it would show "Becomes Less Than" and "Becomes Greater Than" - it's probably just a big that he can fix.

Jay,

Actually, I set the state for the temperatures as text so that I could display them with units (remember all of the work this summer with being able to display the degree symbol for °F or °C?). If I convert the temperatures to integer, I will not be able to have units displayed, or the option to show "N/A" when a temperature cannot be displayed because of valve settings.

I guess I'll have to lose the unit display if folks want to be able to trigger on specific values.

Jim

Why not have two device sates for each. On for display purposes and one for variable purposes? Just label them accordingly.

kpfriedberg wrote:Why not have two device sates for each. On for display purposes and one for variable purposes? Just label them accordingly.

This is exactly what the NOAA plugin does (though to be honest the NOAA feed has them as two different data elements). When you get a new temp value just construct the string and update both states. Make it airTempDisplay or airTempString.

It's likely that over time more logic and UI elements will depend on state data types (and perhaps variable data types in the future) so assigning values their native types is really the right thing to do.

jay wrote:

kpfriedberg wrote:Why not have two device sates for each. On for display purposes and one for variable purposes? Just label them accordingly.

This is exactly what the NOAA plugin does (though to be honest the NOAA feed has them as two different data elements). When you get a new temp value just construct the string and update both states. Make it airTempDisplay or airTempString.

It's likely that over time more logic and UI elements will depend on state data types (and perhaps variable data types in the future) so assigning values their native types is really the right thing to do.

Jay,

It's spring again, and I'm about to get my pool opened - and am therefore able to continue work on this plugin.

One question with regard to having two versions of a device state - Once the number of states gets large, as it will for this plugin, it becomes difficult to see in the Indigo UI, so I was wondering if there is there any way to display only one, but have both available for use?

Thanks,
Jim

yergeyj wrote:One question with regard to having two versions of a device state - Once the number of states gets large, as it will for this plugin, it becomes difficult to see in the Indigo UI, so I was wondering if there is there any way to display only one, but have both available for use?

No - all states must show in the UI since we can't anticipate what states shouldn't be shown in the various UI elements (lists, popups, etc) and in what circumstances those hidden states should be used.