Announcement

Collapse
No announcement yet.

Temperature DeviceAction Status Device

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

    #16
    Hi,

    I have encountered this problem a few times since that post, but I know what causes it each time now...

    If I shutdown homeseer, when I restart it, it remembers the on/off conditon of the thermostat devices. If it was "active" when I shut down then it displays "active" when I restart it. I don't know if this really reflects whether the associated temperature action is active or not?

    Anyway - if I try to turn off the control device either directly using the "off" button of the thermostat device, or an "off" event - it does not turn off. Or at least it still reports that it is "active". If I try to turn it off again it still doesn't go off - what I have to do is click "ON" and then click "OFF" for it to correctly display "inactive".

    Now I don't know what is going on "behind the scenes" - I am just going on what the devices are reporting.

    Had the problem just a couple of hours ago - I had restarted homeseer earlier today when the day thermostat was active. It was still reported as active after the restart. Come sunset and I had both day and night thermostats reporting "active" - cured it by turning the day one "on" (even though it was already "on") and then "off"...

    I can work around it now I know what to do... just a minor inconvenience.

    Cheers,

    Steve

    Comment


      #17
      I never could reproduce the problem, but I did see where the controls were being defined after the logic to turn them off at startup. What I did do is defined them first and I also set the DeviceString to null and let the control logic rebuild it at startup. That way we know it was just not a leftover that did not complete init.

      I also made the manual control actions all event driver so any change in either the status device or device being controlled will be reflected immediately. This does require a lockout period which is now set to 5 seconds from when a automated control occurs to when a manual action of the controlled device will disable the control. For example
      Heater (B1) turns ON at 9:00:00. If B1 is manually turned OFF before 9:00:05 then it will turn the heater off, but it will not disable the automatic control of the heater. If it is manually turned OFF after 9:00:06 then it will turn both the heater and the control of the heater OFF. I had to do this because of the limitations on HS's callback logic.

      The startup logic was intentional so that no special action is needed between shutting down HS and restarting it. This feature was added when the status device was added.

      Update is posted V4.38.5

      Comment


        #18
        Originally posted by Michael McSharry
        I never could reproduce the problem, but I did see where the controls were being defined after the logic to turn them off at startup. What I did do is defined them first and I also set the DeviceString to null and let the control logic rebuild it at startup. That way we know it was just not a leftover that did not complete init.

        I also made the manual control actions all event driver so any change in either the status device or device being controlled will be reflected immediately. This does require a lockout period which is now set to 5 seconds from when a automated control occurs to when a manual action of the controlled device will disable the control. For example
        Heater (B1) turns ON at 9:00:00. If B1 is manually turned OFF before 9:00:05 then it will turn the heater off, but it will not disable the automatic control of the heater. If it is manually turned OFF after 9:00:06 then it will turn both the heater and the control of the heater OFF. I had to do this because of the limitations on HS's callback logic.

        The startup logic was intentional so that no special action is needed between shutting down HS and restarting it. This feature was added when the status device was added.

        Update is posted V4.38.5
        Strange you cannot reproduce it as it does it on my system every time, although I am running v2 and a myriad other things on my server...

        Installed the update but shall refrain from making any rash observations as to it working or not for a day or two

        Cheers,

        Steve

        Comment


          #19
          I'm afraid this last update isn't working (for me at least) anymore...

          Last night I noticed that the DeviceAction Status device "Now" temp was not updating at all from when I first manually turned it on... left it running though as I assumed it would be working in the background...

          However, come this morning the daytime thermostat has not started. The event triggered as normal, it is even in the log as being turned on... Unfortunately I didn't get a chance to check until almost 11am... both Status devices report "inactive", the day heater has been turned on, but it has been on non-stop allowing the temp to rise way past my UL...

          Here's an extract from the log - in case you can glean anything from it:

          <TABLE cellSpacing=2 cellPadding=0 width="100%" border=0><TBODY><TR><TD class=LOGDateTime0 noWrap align=left>28/09/2005 06:42:00 </TD><TD class=LOGType0 align=left colSpan=3>Info </TD><TD class=LOGEntry0 align=left colSpan=8>Event Trigger "Heater Off Night"</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>28/09/2005 06:42:00 </TD><TD class=LOGType1 align=left colSpan=3>Info </TD><TD class=LOGEntry1 align=left colSpan=8>Device: Greenhouse Night Thermostat (]38) OFF</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>28/09/2005 06:42:00 </TD><TD class=LOGType0 align=left colSpan=3>Info </TD><TD class=LOGEntry0 align=left colSpan=8>Device: Greenhouse Heater Night (G3) OFF</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>28/09/2005 06:43:00 </TD><TD class=LOGType1 align=left colSpan=3>Info </TD><TD class=LOGEntry1 align=left colSpan=8>Event Trigger "Camera Dawn Activation"</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>28/09/2005 06:43:00 </TD><TD class=LOGType0 align=left colSpan=3>Info </TD><TD class=LOGEntry0 align=left colSpan=8>Device: Greenhouse Camera (G6) ON</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>28/09/2005 06:43:09 </TD><TD class=LOGType1 align=left colSpan=3>DooNetwork Info </TD><TD class=LOGEntry1 align=left colSpan=8>Greenhouse Camera is connected</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>28/09/2005 06:44:00 </TD><TD class=LOGType0 align=left colSpan=3>Info </TD><TD class=LOGEntry0 align=left colSpan=8>Event Trigger "Heater On Day"</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>28/09/2005 06:44:00 </TD><TD class=LOGType1 align=left colSpan=3>Info </TD><TD class=LOGEntry1 align=left colSpan=8>Device: Greenhouse Day Thermostat (]37) ON</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>28/09/2005 06:44:00 </TD><TD class=LOGType0 align=left colSpan=3>Info </TD><TD class=LOGEntry0 align=left colSpan=8>Event Trigger "Day Thermostat"</TD></TR></TBODY></TABLE>

          I have no idea what is wrong - I changed nothing, apart from shutting down, installing update and re-starting again???

          New observation added @ 3.55PM: Manually turned on status device - it turned on OK and displayed "Active". It (not me) also turned on the heater (which is correct as the temp was below my LL). It did not, however, update the status devices's display to say it had turned that device on - it still said "off"... However, lo and behold - a few minutes later when I checked, the status device displayed "inactive", leaving the heater it had turned on, "on". Will have to go back to old version for tonight...

          Cheers,

          Steve
          Last edited by steve-l; September 28, 2005, 09:48 AM. Reason: adding a new observation.

          Comment


            #20
            I will remove the immediate update of the status device when the control device changes. I originally did not do it because of the timing issues of the callbacks and thought 5 seconds would be an adequate time, but it just is not worth the risk of it doing the wrong thing.

            Comment


              #21
              I posted V4.38.6 with the following changes
              1. Removed the event-based update of the Status Device to prevent it from turning off when the controlled device is changed
              2. Added background check of consistency between the status and control with a message to log and update of the status device. Not expecting this to ever happen, but if it does we know something unexpected happend and the status will always reflect what is under the hood
              3. Added elapsed time the controlled device has been at the current state as part of the status device string. It will update every minute so there is feedback that the control is actually enabled
              3. Added HTML formatting to the Status Device which is selected as other HTML formatting from the setup page Display tab
              4. Added Control.gif as the HTML icon, but did not include a file. If you have an appropriate GIF file then put it in \HTML\images\sensors\control.gif

              Comment


                #22
                New version installed. I know its only cosmetic, but I love the new ability to add an icon

                Will see how we fare with this one!

                Thanks Michael,

                Steve

                Comment


                  #23
                  Update

                  Hi,


                  Just thought I would post an update - still having trouble with the status device. When homeseer is shut down with a thermostat device "active", when it restarts it "appears" to remember the state in that the status device still displays as "active" - but in reality, it isn't. The display remains frozen - the "now" temp stays fixed at the level it was when HS shut down and the "on/off for:" timer no longer updates. This is not just cosmetic - if the temp falls outside the LL/UL the heater isn't turned on or off.

                  If it helps, I have found that the following fixes this for me, it guarantees that the device will be ON after the fourth action:


                  Weird, but works!

                  Now running HS2 v1992.

                  Cheers,

                  Steve

                  Comment


                    #24
                    I know I have a ticket vs HS2 that demonstrates that during plugin init the HS device init has not yet completed so the plugin initializes to a wrong value. With your manual action of forcing an initialization of the device you have overcome this. I dont know for certain this is the cause, but when I return next week I will investigate.

                    Comment


                      #25
                      I dont know if the my ticket was worked as part of build 1997, but could you let me know if you are still seeing problems with this latest HS2 build?

                      Comment


                        #26
                        Originally posted by Michael McSharry
                        I dont know if the my ticket was worked as part of build 1997, but could you let me know if you are still seeing problems with this latest HS2 build?
                        Yes, the problem is still there with 1997 I'm afraid.

                        Cheers,

                        Steve

                        Comment


                          #27
                          2 little problem and status devices to go on rampage (cpu usage 100%, device gui refresh 1 sec etc..)
                          TriggerEventAction line 740 :Subscript out of range
                          DeviceExistByEventName 320 : Object variable or with block variable not set

                          Comment


                            #28
                            I see the line 320 was caused by iterating trough the list of devices and the hs.GetDevice did not return a device. I put a check to make certain an object is returned, but I know that I do this may places and make no checks for the validity of the object returned by HS.

                            I cannot find the line 740 error. The name "TriggerEventAction" does not match and some variants of it also dont. It seems like a name I would use, but I do not see it in mcsTemperature V4.40.3. Can you double check on the name?

                            Comment

                            Working...
                            X