Announcement

Collapse
No announcement yet.

Parent/child and floor/room?

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

  • Parent/child and floor/room?

    Is the plug-in supposed to handle updating the floor and room for the child devices when the parent is changed?

    Or, let me ask, since I have four thermostats I have four sets of various values for status, mode, temp, humidity and no clear way to telling which one is which.

    How do I tell? And would I then have to manually change each one of them to a specific floor and room?

    I suppose I could punt and just delete them all and the add then back one at a time, making bulk floor/room changes as each one gets added. Is that the only way to do this?

  • #2
    How long is it supposed to take do update when you delete/re-create a device?

    Mine took over 5 minutes before it went from just the thermostat and a "Waiting to update" status device. Eventually the rest showed up. But none of them had a floor or room set for them. I had to bulk-change them.

    Is the plug-in supposed to keep the devices updated to match the parent thermostat's room/floor? It doesn't appear to do this....

    Comment


    • #3
      Originally posted by wkearney99 View Post
      How long is it supposed to take do update when you delete/re-create a device?

      Mine took over 5 minutes before it went from just the thermostat and a "Waiting to update" status device. Eventually the rest showed up. But none of them had a floor or room set for them. I had to bulk-change them.

      Are the supposed to keep themselves updated to match the parent thermostat's room/floor?
      In my display, they're all grouped together so I can always tell. I usually bulk update them once everything is in place. (The 5 minute delay would be the frequency of polling allowed by Honeywell.)

      Comment


      • #4
        I deleted all of them and re-created them one-by-one. The first one took the longest, about 5 minutes before HS3 showed the full set of devices for it. The floor and room wasn't set for it. Nor did setting those values on the parent Thermostat item update the child devices.

        I then added the rest, one at a time, and then used the device view set their floor and room. You have to use the "Not set" checkbox for the floor or room and that'll limit the device list to just the newly added unit. Use the bulk-change drop-down to set all of them to the desired room and floor.

        After one was added and it's floor/room changed, I then added the next. Repeating the floor/room changing.

        I'm still seeing four different timestamps for Outdoor Temp and Outdoor Humidity. They're all based on the same, single outdoor sensor. But the plug-in seems to think they're associated with the thermostats themselves. Which, I'm guessing, is a 'feature' of the Honeywell API, right?

        How should I go about getting the latest outdoor temp/humidity values then? Which one should I choose? Or should I set up some other kind of event that tracks those devices and stores the value in something else?

        Comment


        • #5
          Bump:
          >How should I go about getting the latest outdoor temp/humidity values then? Which one should I choose? Or should I set up some other kind of event that tracks those devices and stores the value in something else?

          Comment


          • #6
            Originally posted by wkearney99 View Post
            Bump:
            >How should I go about getting the latest outdoor temp/humidity values then? Which one should I choose? Or should I set up some other kind of event that tracks those devices and stores the value in something else?
            I'm afraid I just don't understand - perhaps you're right about it being how Honeywell does things, but based on the data provided by the plugin, Outdoor temp is one of the fields it provides on a per-thermostat basis. I have no idea where it comes from or if it's even as simple as a zip-code-based general temperature. As far as I know, there's no specific knowledge of or capabilities regarding a stand-alone temperature sensor.

            Comment


            • #7
              Originally posted by shill View Post
              I'm afraid I just don't understand - perhaps you're right about it being how Honeywell does things, but based on the data provided by the plugin, Outdoor temp is one of the fields it provides on a per-thermostat basis. I have no idea where it comes from or if it's even as simple as a zip-code-based general temperature. As far as I know, there's no specific knowledge of or capabilities regarding a stand-alone temperature sensor.
              It's being pulled from the Honeywell data, each dump shows a value. And when they're pulled near the same time it's the same. Which I've confirmed by looking at the LCD on one of the physical thermostats here (paired to it and the Redlink gateway).

              My question is if I have other activities that I want to run on HS3 how would I best go about obtaining the current temp through this plug-in?

              I've never really wrapped my head around the conditions/triggers aspect of HS and would like to have a better handle on it. So I'd at least like to know the right way to get a the current temp from this plug-in. Bearing in mind the frequency limits of the API.

              The specific example being control over a ceiling fan at night if it's hot outside. Given temp swings we have around here, this value can change over a fairly wide range.

              What I don't know is how often this plug-in would be obtaining fresh data from the API.

              I'm kind of at a loss as to where to start, but know enough to be mindful not to set something that causes trouble with the API on the server-side.

              Comment


              • #8
                The API limit has nothing to do with the HS triggers. Let the plugin do its thing and update the device values, and then when they do change and it's below your threshold (or above), your event should fire to have it do something.

                For example, if you create a new event and choose:
                "A Device's Value Is..."

                then:
                "this device had its value set and is less than"
                Attached Files

                Comment


                • #9
                  Originally posted by shill View Post
                  The API limit has nothing to do with the HS triggers. Let the plugin do its thing and update the device values, and then when they do change...
                  Ok, I'm following you here. The next question is what determines when HS is going to see the Outdoor Temp value as 'changed'?

                  I ask this because right now it's 5:42pm and my four Outdoor Temp values where updated at 4:16:07, 4:16:13, 4:16:19 and 4:16:50pm. The Outdoor Humidity values were updated more recently at 5:20:38, 5:20:42, 5:20:48 and 5:20:53pm. The actual temp & humidity at 5:42pm are 31F and 62% according to the LCD on one of the thermostats. This matches the values the plug-in shows in the device list.

                  The temperature is pretty stable right now, at 31F, so I'm not able to see a change happening. Which, of course, is inconvenient for debugging...

                  So the plug-in isn't updating the timestamp on the Outdoor Temp values if they haven't changed. Which I'm assuming is because the checkbox "Do not update device last change time if device value does not change" is checked. Correct?

                  I do see the timestamp on the Status devices for them are being updated. So clearly the plug-in is running and obtaining data (shows Success).

                  If I changed the "do not update" checkbox for the device would it then track in-step with the Status device?

                  EDIT: the temp finally dropped a degree to 30F and I see the timestamp reflecting it.
                  Last edited by wkearney99; January 15th, 2018, 06:11 PM.

                  Comment


                  • #10
                    And lest you be worried, I'm not looking to find blame or bugs in the plug-in. So, please, don't let my painfully slow learning process seem like I'm being negative. Quite the contrary, I'm pleased with how it's going... as I finally start to understand it!

                    Comment


                    • #11
                      Originally posted by wkearney99 View Post
                      And lest you be worried, I'm not looking to find blame or bugs in the plug-in. So, please, don't let my painfully slow learning process seem like I'm being negative. Quite the contrary, I'm pleased with how it's going... as I finally start to understand it!
                      I've been using HS since 1.X in 2000 or so, and I remember the switch to HS3 as being a bit daunting, so I totally understand!

                      As to your question about the timestamp, by definition it's "Last changed" and so if the value hasn't changed, the timestamp likewise won't change. If you're seeing the value change but the timestamp doesn't, that would be a bug... otherwise everything should stay static until there's a reason to change it. Think of it as "it's been 31F since 4:16 PM".

                      Comment

                      Working...
                      X