Announcement

Collapse
No announcement yet.

Thermostat support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Thermostat support

    Is there a list somewhere of the various thermostats supported by mcsmqtt?

    #2
    Didn't even know there was a thermostat that supported MQTT.
    "if I have seen further [than others], it is by standing on the shoulders of giants." --Sir Isaac Newton (1675)

    Comment


      #3
      I don't think they are native mqtt, mcsmqtt supports a wide range of protocols and there are several thermostat that work with it, just trying to see what all there are

      Comment


        #4
        Got it. I'll be interested to see what you find that works.
        "if I have seen further [than others], it is by standing on the shoulders of giants." --Sir Isaac Newton (1675)

        Comment


          #5
          There are two classes of thermostats. One is via the Cloud and one is Local.

          For the cloud the NuHeat, American Standard, Trane and Nexia have been supported.

          For local control all that employ the WMP protocol, a set of Daikin models of mini-splits and some others that are so simple that a basic URL interface is used such as the Venstar. There may be several that fall into this category that I am not aware as support requests are not needed.

          In this generic case it looks to the user as a widget that uses MQTT protocol even though REST is actually being used behind the scenes. The user selects which thermostat features they want to see in HS and the features they want to control. Graphics are the user responsibility in this case. Note that the mcsMQTT Edit tab provides the ability for the user the select the DeviceAPI so the thermostat type API can be selected for other things such as HSTouch that may be expecting them to be available for it's use.

          Going forward others can be implemented with use of the simple URL vs. plugin-specific-logic will depend upon the needs of the thermostat and the desired presentation. At times there are dependencies between one feature and the next and this is usually most easily handled within the plugin. When done within the plugin then the user is dependent upon me to make an update as the thermostat changes. When generic then then the user can handle the change themselves.

          The mcsMQTT architecture is to present to the user a table of decoded data from a widget and let the user decide what part of the available data is desirable to be seen in HS. It does not matter if the widget supports MQTT, REST, Telnet, Serial or other lower level protocols. The user interface is the same with the primary point of view being the Association table and augmented with Edit popup when detailed customization is desired.

          It is quite often the case that there is some nodejs or python hack of an unpublished API. I will try to implement this hack as .NET within the plugin when a user need exists. If there is a published API then this is usually easier to implement as there is real documentation of what is to be expected and needed. There are also cases where no published API exists and no hack has been implemented. I do not get involved with these products except for those that I may own.

          Comment

          Working...
          X