No announcement yet.

Feature Requests for mcsTemperature

  • Filter
  • Time
  • Show
Clear All
new posts

    Feature Requests for mcsTemperature


    I've made a robust attempt as setting up mcsTemperature 5.14.6. I want to thank you again for your assistance in getting me through the hard parts.

    During my setup I encountered things that I felt could be better. I know your working on a new version of Temperature, so I think my timing is good with this information. Let me know if you have any questions on this. Hope it helps.

    1. Graphing.
    a. Allow adjustment of right Y axis separate from the left Y axis.
    b. Ability to control which trace is attached to which Y axis.
    c. Min and max value.
    d. Graticule scale and number of significant digits displayed.
    e. Ability to control trace color and data point symbol.
    f. Number of data points plotted per X axis division. Currently the 72 hour time scale could use a few more data points, but the others look OK as is.
    g. All of these settings should be save-able with the Group, not global.

    2. Temperature Control Loop pages.
    a. Current layout, text, and formatting in the HS Events are very unintuitive.
    i. Documentation or balloon help needs to explain what the purpose of Trigger Limits are. This is counterintuitive to a new user. Only the action tab limits are real.
    ii. Action tab should group the two ONs and two OFFs. Use better text formatting. Put the two Enable check boxes near the conditional boxes.
    b. Interface Setup tab for Priority needs more (especially faster) options. Currently the Run at Above Normal Priority option is about 1 minute updates. Would like a 10 or 20 second update option.
    c. The Control function in the status is not linked to HomeSeer robustly. If the name is changed in the Status page it may not work correctly any longer, something gets out of sync (not sure of details).

    3. Weather display.
    a. Let the Screen and Chart Dimensions also apply to the Weather page. This will give the ability to scale the weather display, as is done with graphs.
    b. Add support for animated radar, such as the .php files used by NWS.
    c. If you click on the radar image it would be preferable to toggle to the alt radar URL instead of opening a new browser window.

    4. Sensor page.
    a. Undocumented Feature warning: Changing the device type in the Sensor page will overwrite HomeSeers device info. This can screw up devices, especially if your device is not something on the list. It changed my universal module into a switch device (closest item I found on list). After that my universal module did not work, I had to change it back to a universal module in the Status page. Can you give us user specified device capability? Would also like to choose N/A as a list option so that it does not overwrite HomeSeer’s data.

    5. General.
    a. In the interfaces page confirm the option Set Bad Reading to Zero works. Appears to me it always uses previous value, not sure.
    b. Give ability to choose what house code is used. Currently fixed at [ and \.
    c. How about using balloon help like in Sprinklers?

    6. Plug-in Installation.
    a. Confirm installation directory requirements. Be sure install dialog boxes state whatever is necessary.
    b. I had a lot of problems with default settings and data entries not “sticking”. Never really figured it out. Seems to get better as the database fills out.
    Last edited by Mr Spock; May 4, 2009, 02:10 PM. Reason: Added list item

    Thank you for your inputs to make improvements. I think some of the items in your first graphing category are available but perhaps not quite like you want them.

    Formatting within HS events took a step backward with HS2. The formatting interface was deleted in HS2. To maintain compatibily with existing user setup I did not have too many options. I think the manual also shows a HS1 layout which I think is a little more natural. It really makes more sense to make the virtual thermostat independent of the HS event and not be constrained, but this community likes to keep things under the HS hood so I tried to be responsive.

    The temperature control, by design, uses the same name as the event. To my knowledge there is no explicit provisions to deal with associating devices with events in HS so anything that would be done outside of HS such as with an .ini file would be fragile. You are correct that an uninformed user would not know about this.

    The process priority is a windows scheduling parameter. You will likely find that it only makes a differnce at the margin. A higher priority would be at the same level at CTL-ALT-DEL so one could be subjected to locking themselves out with the power button being the only recourse. The only application I allow to run at the high REAL TIME level is Guardian Angel as it is designed to be monitor and it is a very austere application so less opportunity for something to go wrong within it.

    What interface are you using that would apply to the previous values setting?

    The house code assignment is managed by HS. HS tells a plugin which house codes it can use. They all given out on a first-come, first-serve basis in the ASCII sort order. There is a utility I posted called ManageInterface or InterfaceManager that will allow you to globally change house codes. It will work fine for mcs plugins since HS holds all informatinon necessary to maintain the house codes. Many plugin authors store there house code in an ini file and that often results in conflicts where two plugins try to use the same house code.

    I had quite a bit invested in HS1 and the lesson I learned in the migration to HS2 is to no longer tightly couple to HS. When they change it has a big impact and a lot of rework. mcsTemperature is tightly coupled so it will not get a lot of user-friendly features added such as you see with mcsSprinklers. I am quite willing to make improvements and will do my best to work with the list you have provided.




        There was a version I recently put together where the control loop iteration rate is independent of the sample rate of the sensors. The user can select from 1 second to 60 seconds on the control loop. It is posted in this forum somewhere and I need to place it at the top in the sticky since there are no issues with it reported.

        For sensor sampling via 1-wire the xap application xapmcs1wire is a better product and has more user options than the capability provided by mcsTemperature. With that you can identify a sample rate on a sensor-by-sensor basis. It works with HS via the mcsXap plugin. There are many discussions on this. It does add a degree of complexity that is not needed if mcsTemperature is adequate for data collection. In general I have adopted xAP as my interface mechanism so everyting communicates via IP in a distributed architecture. This is counter to the HS paradymn where everything is centralized within HS. HS can operate as one of the distrubuted xAP nodes when using the xAP plugin so from a HS user perspective, after the setup, use of an xAP/LAN interface looks the same as any other plugin interface with a common view and control provided by HS device model.