Thermostat API calls -- when invoked?

[Rick Tinker]

Rick, I'll admit that I was left wondering that myself after your post. In my case at least, it's more a case of not 100% understanding the HS SDK. I didn't know if your last post meant the thermostat API was going away or if you just meant there was a better way to accomplish the task. I understand now what you meant. I'll be modifying my thermostat plugin to incorporate function-based devices now. Thank you for the guidance.

What started this was the confusion of the ancient (e.g. HomeSeer 1.5) method of having a single HomeSeer device represent a thermostat, which through device types had a script associated with it which did all of the work of responding to changes and updating status. That has had more and more of it removed with each subsequent point release of HomeSeer and it finally dies completely in HS3.

The Thermostat API is not going away. The thermostat API does nothing to represent what you do with devices. There are thermostat plug-ins out there that do not create a single device and only use the triggers and actions UIs, and custom web pages, to do everything.

[cadillackid]

got it thats all good.. I just dont like to see the thermostat API in discussion.. as when the RCS serial plugin was redeveloped by HST.. lots of functions were left out that pertain to advanced zone controlling.. in the name of 'they arent in the API' but were put back in by user demand.. I just dont want to end up in that situation again knowing that the RCS-serial plugin has many extra functions in it esp relating to zone controllers that were never in the documented T-stat API..
I agree that devices themselves are used very little for Tstat control itself.. the plugins either use their own web pages or a front end like HSTouch or mainlobby is used..
-Christopher

[Rick Tinker]

got it thats all good.. I just dont like to see the thermostat API in discussion.. as when the RCS serial plugin was redeveloped by HST.. lots of functions were left out that pertain to advanced zone controlling.. in the name of 'they arent in the API' but were put back in by user demand.. I just dont want to end up in that situation again knowing that the RCS-serial plugin has many extra functions in it esp relating to zone controllers that were never in the documented T-stat API..
I agree that devices themselves are used very little for Tstat control itself.. the plugins either use their own web pages or a front end like HSTouch or mainlobby is used..
-Christopher

I have NO idea what you are referring to with the RCS Serial T-Stat plug-in. The fact that something does not exist in the thermostat API has no bearing at all in other features the plug-in can have. The thermostat API definitely has a way of handling multiple zones as well. I think the big issue with that plug-in was that it has always had weak developmental interest - you have been the one constant championing it the most. We paid a developer to write the original and everything was fine, then some new products came out and interest grew for more of the zone stuff and related products, but by then all of the development was by volunteers because we no longer had the hardware. As you are aware, your professional life does not always leave time to work on it either. It has become too hacked up by having a variety of people working on it.

If you are still able to work on it, then when we get the changes to the SDK finalized for HS3, perhaps you and I can collaborate and get it fixed up proper - I would like to see some of the more confusing aspects of it - namely the way it stores the zone data - fixed up.

[AllanMar]

That is correct, but we are already looking at that functionality for HS3 amongst some other new capabilities. However, not having the text box is only an issue when you do not know the thermostat and the range of values. Some thermostats accept decimal points, some do not, and all have a fixed range of high and low values that they can have. Therefore, you can add value/status pairs (as a range) to a device and that will result in the temperature selection appearing as a drop-down list of values to choose from, which reduces the chance of error on the entry and the amount of data validation that your plug-in will have to perform.

The other option available to you is to have the current temperature and the current temperature setpoint(s) displayed in a device, but leave the temperature setting to either a plug-in created event action or a custom web page created by the plug-in.


Thermostat DEVICES are not referenced in the plug-in SDK except in the copy of the device MISC bit settings provided in Appendix A. They still work in HS2, but there is much more to them than setting that bit. I would describe it in detail except that as I mentioned, it is being completely removed in HS3. The other advantage to not using a thermostat device is that it required that ONE device to show everything about the thermostat and it allowed all forms of control to the thermostat on a single device. It is much more practical to create a device for each functional area of thermostat - e.g. a thermostat mode device, a thermostat setpoint device, a thermostat fan mode device, and then devices that hold status information only such as operating mode and current temperature. This is what we are going to be doing in HS3 w/r/t Z-Wave thermostats - the Z-Wave thermostat plug-in will be going away in HS3.

Thanks for the clarifications Rick. For whatever personal preference I like the text box, but I agree with your comments on it (I currently have a drop down). I have individual devices, but for whatever reason once again I also like the idea of the one main device.

That said, I look forward to these sort of cleanups/modifications to the SDK in HS3.

[cadillackid]

I have NO idea what you are referring to with the RCS Serial T-Stat plug-in. The fact that something does not exist in the thermostat API has no bearing at all in other features the plug-in can have. The thermostat API definitely has a way of handling multiple zones as well. I think the big issue with that plug-in was that it has always had weak developmental interest - you have been the one constant championing it the most. We paid a developer to write the original and everything was fine, then some new products came out and interest grew for more of the zone stuff and related products, but by then all of the development was by volunteers because we no longer had the hardware. As you are aware, your professional life does not always leave time to work on it either. It has become too hacked up by having a variety of people working on it.

If you are still able to work on it, then when we get the changes to the SDK finalized for HS3, perhaps you and I can collaborate and get it fixed up proper - I would like to see some of the more confusing aspects of it - namely the way it stores the zone data - fixed up.

the current RCS serial plugin is the .NET version that was produced by HST.. the old COM plugin was the one that I added zone capabilities to mainly for my own House.. then it ended up in the field with others using it... to keep things on the straight and narrow I converted over to the HST .NET RCS serial plugin and then wrote a program that runs alongside of it and homeseer via "remoting" that controls the advanced aspects of my HVAC.. (zone averaging, static pressure control, gas valve and blower as well as damper modulating)... the current iteration of that plugin hasnt given me any issues.. i know we all complained about the single device per thermostat at first but of course that was easily rectified by a simple script to split up the devices like the old plugin did.. im currently working towards my whole HVAC system ending up on microcontrollers.... at that time Homeseer will just be there to do what it does best handle events, setpoints, etc.. Homeseer never was meant to be a commercial HVAC controller I dont believe(which is basically what my HVAC is... im sure ive put way more effort into HVAC than was ever needed or required...)... the idea of Homeseer in the future running on Linux is intruiging.. as at that point the idea of running it on a true embedded system becomes a possibility.. im just not all excited about embedded windows.. I work in a world that I still reset locked up windows machines 10-fold over resetting locked up linux or embedded machines... reality is you guys could totally rack the API and id probably still program in it because ive been with Homeseer long enough that I see it being in my system for quite a while yet... I played with lots of stuff when i was planning my house to be built in 2003.. and came upon homeseer in early 2004.. Homeseer was up and running in my new house when i moved in late 2004....
-Christopher