Aprilaire Feature Request

[gbdesai]

Nevermind, take a look at the attachment, I modified for a single tstat.

I removed the function call and put it all in main, just run the script with no advanced options.

You need to change two things first you need to put your tstats device code in near the top, I have a comment showing you where, replace $1 with whatever your code is.

Secondly, I set it up for t1-t8, you can change those device codes to suit your needs near the bottom of the script. I put a comment there for that too. Didn't test it but it should run fine.

Let me know if you have issues...

G

[gbdesai]

Sorry I didn't notice your code is tstat device code is #1, so just find where I have $1 and change it to #1. And then change the device codes if you need to from t1 through t8 to whatever 8 different codes you want to use.

[Jerry S]

Thank you for the script, G. It works great!

When you call the original script you posted, what advanced parameters do you specify in the event? I'd really like to figure this out, as I'll be installing an additional Aprilaire in a couple of weeks, for the other AC unit.
Thanks,

Jerry

[gbdesai]

In the original script you have to run it through an event as usual but you must call it by manually sending the tstat device code, you do that by:

1. Create an event that has an action of Run Script
2. Click on switch to advanced view
3. Select the script from the Existing Script dropdown box
4. In Optional parameters (function,param) type "setVariables","#1" for your first tstat or "setVariables","#2" for second and so on.
5. You must create new variables to support the new status variables, I found it easier to create t11-t18, t21-t28, etc. since this is easy to deal with in code than a simple linear code like t1-t16.
6. Finally, you must go into the original script and chance the select case statement to fix it to deal with the various potential tstats.

Hoep that makes sense.

G

[Jerry S]

That makes perfect sense, G. I think I might be able to get this script working for my setup. I haven't attempted to script using a function before, and really appreciate you explaining this.

Thanks,
Jerry

[gbdesai]

I just wish the plug-in architecture supported the great hs.ControlThermostat interface, with that and the scripts you could do things like hs.ControlThermostat("#1","GetTemp",0) and have it return the temp. Or set values and such.

As far as I can tell, without any more detailed documentation, you have to create events that can be called from a script to do even simply things like bump the setpoints up or down one degree at at a time or even to change modes.

Some direct control of the plugin would be welcome, and more efficient to boot.

Finally as I mentioned in a post somewhere, the ability to sense a change in any element of a particular tstat (change in temp or a local change in setpoint or whatever) should be available to trigger an event. As far as I can tell you can't do that the way the plug-in is currently designed. We have to run the script I posted blindly in a recurring fashion to get the status only variables to be updated with changes to the tstats.

G

[RJ]

Hi G, I beleive I have some answers for you.

I just wish the plug-in architecture supported the great hs.ControlThermostat interface, with that and the scripts you could do things like hs.ControlThermostat("#1","GetTemp",0) and have it return the temp. Or set values and such.

This can be accomplished using hs.Plugin("Aprilaire Thermostats").[Plugin Procedure], where [Plugin Procedure] Represents the Thermostat API call you are making to set or get a value. These functions are detailed in the Thermostat API, part of the HomeSeer Developer Kit.

As far as I can tell, without any more detailed documentation, you have to create events that can be called from a script to do even simply things like bump the setpoints up or down one degree at at a time or even to change modes.

I can add this functionality, but it will be a bit. None of what you mentioned is very hard, it just takes some time to program and test.

Some direct control of the plugin would be welcome, and more efficient to boot.

Is the Aprilaire status page not enough? I'm not sure I understand what you mean by "Direct Control" here, but if you mean something other than the Aprilaire status page then please let me know.

Finally as I mentioned in a post somewhere, the ability to sense a change in any element of a particular tstat (change in temp or a local change in setpoint or whatever) should be available to trigger an event. As far as I can tell you can't do that the way the plug-in is currently designed. We have to run the script I posted blindly in a recurring fashion to get the status only variables to be updated with changes to the tstats.

G

Right now, you can only trigger on a change to a specific value, and I see your point. I will do my best to add this functionality along with the Increment/Decrement feature request above.

Any other questions/comments, please let me know. I will try to post a new build later today, and hopefully have one for the updater this evening.

[gbdesai]

RJ,

Thanks for the info. The most intriguing is hs.Plugin("Aprilaire Thermostats").[Plugin Procedure] I have to go find that, it may accomplish most of what I want to do.

As far as the status page, it is great. I meant programatic control, but I think the piece above may help or solve that problem.

The only change I'd like to see on the status page (but no rush at all) is that the cool thing you added for me recently to show "(Off)" or "(On)" after the mode on the Aprilaire Status and control page be mirrored on the basic HS2 Device Status page. In reality I have everything on the display and status side working in MainLobby with the script I did. I just need to be able to programatically control the tstats.

Thanks again for your ongoing support!

G

[gbdesai]

RJ,

Your instructions helped me device a much more robust script.

All functions are passed a tstats device code and perform a variety of fairly self-explanatory functions. Here is a list of currently supported functions:

setVariables - Callable seperately and also by other internal routines to update 8 virtual status only devices per tstat
incrementHeatSetPoint - Increases Heat Setpoint by 1 degree
decrementHeatSetPoint - Reduce Heat Setpoint by 1 degree
incrementCoolSetPoint - Increases Cool Setpoint by 1 degree
decrementCoolSetPoint - Reduce Cool Setpoint by 1 degree
setModeOff - Turns off Tstat
setModeHeat - Sets Heat mode
setModeCool - Sets Cool mode
setModeAuto - Sets Auto mode
setFanAuto - Puts Fan in Auto mode
setFanOn - Turns Fan on
setFanToggle - Toggles Fan mode
setHoldOff - Turns Hold Off
setHoldOn - Turns Hold on
setHoldToggle - Toggles Hold mode
getPrefix - Private function for code reuse
getTstatNum - Private function for code reuse

The code in general is more streamlined from the crazy parsing I did in my previous script. One question I have regarding the SDK info is the getOperating function. I expected it to return the boolean running status of the tstat (i.e. True if either running Cool or Heat at the time, and False if the tstat was idle) but the function ALWAYS returns TRUE regardless of real operating state.

If you review the code you will see that I did not simplify code, rather I opted for simplicity of use and created a bunch of discrete functions rather than a few "monster" functions. For example I have separate calls for Mode setting (e.g. setModeAuto, setModeCool, etc.) rather than a SetMode with extra parameters. I may change this later, but I just wanted to make sure it all works. And it appears to. I can now use this for MainLobby very effectively.

Thanks for pointing out what I overlooked earlier RJ.

G

[Jerry S]

Thanks for the updated script, G. It works great (and I'm picking up a bit of education with VB.net scripting!)

What I still can't figure out, is how to call these commands directly from a ML button. For example, HS needs to receive a command in the following format:

hs.Plugin("Aprilaire Thermostats").CmdSetCool(1, 75)

What do you enter in the MLServeCmd box to send this command to HS?

I've tried:

MLServeCmd.MLHSPlugin|hs_Plugin("Aprilaire Thermostats")_CmdSetCool(1, 75)

and

MLServeCmd.MLHSPlugin|hs_Plugin("Aprilaire Thermostats")_CmdSetCool:1~75

but with no luck.

I don't see any specific instructions in the MLHS docs that address sending a plugin command.

Any ideas?

[gbdesai]

I just hooked up all my tstats through the script and mainlobby. You can call the script through commands like:

MLServeCMD.MLHSPLugin|HS_RUNEX:Emotive - Thermostat Functions.vb~setModeCool~$2

After RUNEX the first param is script name, second is function name, third is parameters.

The command above turns on the cool mode on my second thermostat (first floor).

Here is a screenshot of the setup, if you have ML Library 14 I can send you the MLS file. It will work best if you also have upgraded to ML3 and have Library 19 as well.

[RJ]

Hello All,

Attached is the latest (and I hope final!) build of the Aprilaire plugin. Here's what's new:

• Status page(HomeSeer) Now displays current operating state, i.e. Cool (Off)
• Triggers added: HeatSet or CoolSet can now be set to trigger an event on an increase or decrease
• Actions added: HeatSet or CoolSet can now be incremented or decremented by 1 to 10 degrees.

I hope this takes care of the added functionality, but if there are still missing items/problems, let me know and I will try to work on it today.

[gbdesai]

Wow. Thanks. I just installed and everything looks to be working ok. Only one thing I posted a few messages ago that I just wanted clarification on was:

"One question I have regarding the SDK info is the getOperating function. I expected it to return the boolean running status of the tstat (i.e. True if either running Cool or Heat at the time, and False if the tstat was idle) but the function ALWAYS returns TRUE regardless of real operating state."

Is getOperating supposed to return true if the current running state for either cool or heat is on (i.e. Cool (On) or Heat (On))? If so, I don't think it is working right since you always get true regardless of the actual state. I can still get the data I need by parsing the relay values (or the newly added "On" or "Off" data in the device string. But just wanted to check.

G

[RJ]

G-

You are correct, and this change has been implemented in this build. If the status page displays "(on)", GetOperating will return true. If it is in Auto and either heating or cooling, it will also return true. Otherwise, this returns false.

If I am misinterpreting you and this latest build does not fix this problem, then I will take another look at it, but I am almost certain this has been taken care of.

[gbdesai]

That's exactly what I was asking, I should have tested before I asked. I'll put my original script code back in and test this. Beats parsing strings any day. Thanks!