Announcement

Collapse
No announcement yet.

Questions about plugin handling of various modes

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

  • claude
    replied
    Originally posted by nfrobertson View Post
    I think I found the issue with using the home page polling button and getting the "unexpected device type" message. It was on the humidity devices. There was a bug in which field was being compared which resulted in that error.

    I just posted 3.0.3.9 which can be pulled down using the updater override method for testing. I also added a CAPI Poll button to the root/parent (program) device for each thermostat to make it easier to poll just that one thermostat.

    I'd like to get some feedback before posting it to the general updater.

    http://www.kazteel.com/HomeSeer3/dev...r_override.txt
    I installed 3.0.3.9 and 3.0.4.0 (hard to keep you with you ) and polling either from the device management page or from the plugin's thermostat tab is clean. On the other hand, my initial post on this issue indicates that the error popped in the log unexpectedly, not necessarily after me initiating a poll. I'll wait for a few (hardware) thermostat mode changes and will report back. Thanks.

    Leave a comment:


  • nfrobertson
    replied
    I think I found the issue with using the home page polling button and getting the "unexpected device type" message. It was on the humidity devices. There was a bug in which field was being compared which resulted in that error.

    I just posted 3.0.3.9 which can be pulled down using the updater override method for testing. I also added a CAPI Poll button to the root/parent (program) device for each thermostat to make it easier to poll just that one thermostat.

    I'd like to get some feedback before posting it to the general updater.

    http://www.kazteel.com/HomeSeer3/dev...r_override.txt

    Leave a comment:


  • nfrobertson
    replied
    I know I've seen that "Unexpected device for polling" while developing but it was more of a nit so I didn't get back to it yet. I have some testing to do for Rene next week so I'll put this on this list to research as well.

    Nathan

    Leave a comment:


  • claude
    replied
    Originally posted by nfrobertson View Post
    That "Unexpected device type requested for polling" happens when you push the "Poll devices for status" icon on the HS3 home page. I think one of the HS3 devices for my plugin needs to be excluded from polling ...
    No big deal, but just to get to the bottom of that "Unexpected device type requested for polling" thing, I tried both an HS poll and the plugin's Thermostat tab poll action: no errors. Maybe one of those twilight glitches?

    Leave a comment:


  • nfrobertson
    replied
    Originally posted by claude View Post
    Nov-09 23:55:03 Insteon Thermostat 2441TH Mode = Auto
    Nov-09 23:55:12 Insteon Thermostat 2441TH Temp = 21
    Nov-09 23:55:15 Insteon Thermostat Error 2441TH - Unexpected device type requested for polling.


    At around 23:45, the 2441TH's hardware program changes to 'sleep' which introduces a new heating set point. Other log entries before and after have no incidence on the thermostat. And then there's that "... Unexpected device type requested for polling ..." message at 23:55:15.

    Nathan: can you help explain how the mode went from Program to Auto?
    That "Unexpected device type requested for polling" happens when you push the "Poll devices for status" icon on the HS3 home page. I think one of the HS3 devices for my plugin needs to be excluded from polling. Perhaps you have an event action that polls your system generally for status? If so, it must contact my plugin and poll the thermostat.

    Per my previous post above, it appears we have an issue with the 2441th when polled and in Mode=Program it reports back Mode=Auto but the thermostat itself doesn't actually change. Again, more research needed to see if this is a protocol/firmware issue or if it's something I can work around.

    Nathan

    Leave a comment:


  • nfrobertson
    replied
    Originally posted by claude View Post
    Nov-09 12:57:17 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [6B] [02]

    Strangely, device '2441TH Mode' on the device management page has a 'Last change' time stamp that coincides with the poll time, but the status still shows Auto instead of Program.

    I couldn't find any other way to retrieve Mode and Fan state. Any chance of including this added poll functionality in a future release? Unless I missed this in the actual version.
    The [6B] [02] is the poll Mode command and I believe that returns a value that indicates both the mode and fan. So, I ran a test to see if I could get a mixed state between my 2441th and the plugin and sure enough I did. I manually set the 2441th to Mode=Program and verified in HS3 it showed that. First log below confirms it. I then issued the Config->Poll and look at the last log statment coming back, it says Mode=Auto! Looking at the 2441th it is still in Mode=Program. I can experiment with this more but it seems like a possible protocol issue? The thermostat itself reported Mode=Auto but the display still confirms it is in Mode=Program.

    Code:
    11/10/2015 3:32:18 PM ~ Insteon Thermostat ~ INFO ~ sh2441th [04] Mode=Program Fan=Auto
    11/10/2015 3:33:11 PM ~ Insteon Thermostat ~ DEBUG ~ TransmitInsteon: [sh2441th] [0F] [0D] [00]
    11/10/2015 3:33:11 PM ~ Insteon Thermostat ~ DEBUG ~ TransmitInsteon: [sh2441th] [0F] [10] [00]
    11/10/2015 3:33:12 PM ~ Insteon Thermostat ~ ALWAYS ~ sh2441th protocol = 2
    11/10/2015 3:33:12 PM ~ Insteon Thermostat ~ ALWAYS ~ sh2441th devcat = 050B
    11/10/2015 3:33:12 PM ~ Insteon Thermostat ~ ALWAYS ~ sh2441th version = D
    11/10/2015 3:33:12 PM ~ Insteon Thermostat ~ DEBUG ~ TransmitInsteon: [sh2441th] [0F] [6B] [02]
    11/10/2015 3:33:14 PM ~ Insteon Thermostat ~ DEBUG ~ TransmitInsteon: [sh2441th] [0F] [6A] [60]
    11/10/2015 3:33:16 PM ~ Insteon Thermostat ~ DEBUG ~ TransmitInsteon: [sh2441th] [0F] [6B] [03]
    11/10/2015 3:33:18 PM ~ Insteon Thermostat ~ DEBUG ~ TransmitInsteon: [sh2441th] [0F] [6A] [20]
    11/10/2015 3:33:20 PM ~ Insteon Thermostat ~ INFO ~ sh2441th Mode = Auto

    Leave a comment:


  • claude
    replied
    The following log entries show that the 2441TH's mode suddenly turns to Auto, while it's been Program all day long.

    Nov-09 23:44:12 Insteon Thermostat 2441TH Heat SetPoint = 18
    Nov-09 23:46:39 Device Control Device: 2 [2:S. TV] A-Plafonnier escalier vers 2 to Off (0) by/from: CAPI Control Handler
    Nov-09 23:46:40 Device Control Device: 2 [2:S. TV] Plafonnier to Off (0) by/from: CAPI Control Handler
    Nov-09 23:46:40 Device Control Device: 2 [2:S. TV] A-Plafonnier escalier vers 2 to On (100) by/from: CAPI Control Handler
    Nov-09 23:46:40 Device Control Device: 2 [2:S. TV] Plafonnier to Dim (value)% (60) by/from: CAPI Control Handler
    Nov-09 23:46:47 Device Control Device: 2 [2:S. TV] A-Plafonnier escalier vers 2 to Off (0) by/from: CAPI Control Handler
    Nov-09 23:46:47 Device Control Device: 2 [2:S. TV] Plafonnier to Off (0) by/from: CAPI Control Handler
    Nov-09 23:51:14 Event Event Trigger "DemoPad TV_lights_Dim_then_Off"
    Nov-09 23:51:14 Device Control Device: 2 [2:S. TV] A-Plafonnier escalier vers 2 to On (100)
    Nov-09 23:51:14 Device Control Device: 2 [2:S. TV] Plafonnier to Dim 40% (40)
    Nov-09 23:51:44 Event Event Trigger "Delayed Actions Plafonnier (Delayed Action)"
    Nov-09 23:51:44 Device Control Device: 2 [2:S. TV] A-Plafonnier escalier vers 2 to Off (0)
    Nov-09 23:51:44 Device Control Device: 2 [2:S. TV] Plafonnier to Off (0)
    Nov-09 23:51:44 Event Deleting event after run: "Delayed Actions Plafonnier (Delayed Action)"
    Nov-09 23:51:44 Event Event Trigger "Delayed Actions V_TV_LED (Delayed Action)"
    Nov-09 23:51:44 Device Control Device: 2 [2:S. TV] V_TV_LED to Off (0)
    Nov-09 23:51:44 Event Deleting event after run: "Delayed Actions V_TV_LED (Delayed Action)"
    Nov-09 23:51:44 Event Event Trigger "Event triggers - TV LED Off"

    Nov-09 23:55:03 Insteon Thermostat 2441TH Mode = Auto
    Nov-09 23:55:12 Insteon Thermostat 2441TH Temp = 21
    Nov-09 23:55:15 Insteon Thermostat Error 2441TH - Unexpected device type requested for polling.




    At around 23:45, the 2441TH's hardware program changes to 'sleep' which introduces a new heating set point. Other log entries before and after have no incidence on the thermostat. And then there's that "... Unexpected device type requested for polling ..." message at 23:55:15.

    Nathan: can you help explain how the mode went from Program to Auto?

    Leave a comment:


  • claude
    replied
    Question: does polling the thermostat retrieve the mode?

    When looking at the plugin status page, I noticed it showed Mode = Auto; in reality, the 2441TH was in Mode = Program. So I did a Config / Thermostat / Poll.

    As per the log, it retrieved Protocol, Devcat, version and the current temperature (probably also humidity for which I disabled logging).

    Nov-09 12:57:15 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [0D] [00]
    Nov-09 12:57:15 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [10] [00]
    Nov-09 12:57:16 Insteon Thermostat 2441TH protocol = 2
    Nov-09 12:57:17 Insteon Thermostat 2441TH devcat = 050B
    Nov-09 12:57:17 Insteon Thermostat 2441TH version = D
    Nov-09 12:57:17 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [6B] [02]
    Nov-09 12:57:19 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [6A] [60]
    Nov-09 12:57:21 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [6B] [03]
    Nov-09 12:57:23 Insteon Thermostat TransmitInsteon: [2441TH] [0F] [6A] [20]
    Nov-09 12:57:25 Insteon Thermostat 2441TH Temp = 20


    I was expecting it to also retrieve Mode and Fan state, so HS would be in sync with the actual 2441TH.

    Strangely, device '2441TH Mode' on the device management page has a 'Last change' time stamp that coincides with the poll time, but the status still shows Auto instead of Program.

    I couldn't find any other way to retrieve Mode and Fan state. Any chance of including this added poll functionality in a future release? Unless I missed this in the actual version.

    Leave a comment:


  • nfrobertson
    replied
    Yes, it does seem strange. I'll have to look into this and also compare with other thermostat types (venstar etc.) to see if they act similarly or if this is just a 2441th thing.

    Leave a comment:


  • claude
    replied
    Originally posted by nfrobertson View Post
    ... This 3.0.3.7 version overrides the normal skipping logic and forces the commands to be sent so if you switch to your Eco program and that includes a Fan On setting, then it will send the Fan On after the Mode command ...
    Activating a virtual program defined with Mode = Auto and Fan = On while the 2441TH mode is on Program still turns off the fan (briefly), but the next sub-command of the virtual program to turn on the fan effectively works. The net result is what I expected. Thanks.

    Strange though that a controller sending a sub-command to switch the 2441TH from Program to Auto would trigger the 2441TH to turn off the fan... firmware glitch?

    Leave a comment:


  • nfrobertson
    replied
    Sorry Claude. Copy/paste issue. Glad you found the correct link.

    http://www.kazteel.com/HomeSeer3/dev...r_override.txt

    Leave a comment:


  • claude
    replied
    Hi Nathan,

    Can't get to http://www.kazteel.com/HomeSeer3/dev...r_override.txt

    EDIT As I found in another thread, it should be http://www.kazteel.com/HomeSeer3/dev/updater_override.txt
    Last edited by claude; November 8, 2015, 03:40 PM.

    Leave a comment:


  • nfrobertson
    replied
    Excellent testing Claude. I also tested with my 2441th and found that indeed if the thermostat is in Program Mode with FanOn and the Mode is changed by the plugin, then the fan is defaulting back to Auto. I compared this to using the 2441th manually and Program/FanOn switching the mode does not turn the fan off.

    I have posted plugin 3.0.3.7 but it's not in the regular updater stream yet. You can install to your HS3 directory an updater_override.txt which you can get at the link below. This will allow you to use the Manage page to download 3.0.3.7. Be sure to remove or rename the updater_override.txt afterwards so it doesn't block other updates for you.

    http://www.kazteel.com/HomeSeer3/dev...r_override.txt

    This 3.0.3.7 version overrides the normal skipping logic and forces the commands to be sent so if you switch to your Eco program and that includes a Fan On setting, then it will send the Fan On after the Mode command. Let's see if this helps with what you are trying to do

    Nathan

    Leave a comment:


  • claude
    replied
    Follow up on previous post

    Hi Nathan,

    I'm using a combination of 2441TH hardware programs and a Plugin virtual program.

    I defined within the plugin a program, 'Eco', with these characteristics:
    Mode = auto
    Fan = On

    After more testing, here's what I have found.

    Case 1
    Previous 2441TH hardware state: mode = auto, fan = On
    Action: within the plugin, set program to 'Eco'
    2441TH hardware resulting state: mode = auto, fan = On

    Case 2
    Previous 2441TH hardware state: mode = program, fan = On
    Action: within the plugin, set program to 'Eco'
    2441TH hardware resulting state: mode = auto, fan = Off

    It seems that when the plugin changes the mode of the 2441TH, a side effect is that the fan is reset to Auto even though the plugin program is set to Fan = On. No such issue if the 2441TH is already in Mode = auto.

    I tried compensating for this behavior by adding to the event a 'set fan ON', even with a delay of 10 seconds, but the log shows that the plugin ignores that command because it thinks the fan is still On.

    I also realize that the plugin breaks down the event command into individual 2441TH commands sent to the 2441TH at 3 seconds intervals. It appears that only after all those 'sub-commands' are sent does the plugin receive, or is made aware of, the actual 2441TH state.

    Nov-07 14:53:21 Insteon Thermostat SetFanOn: 2441TH Fan = On no change so skipping device update
    Nov-07 14:53:21 Insteon Thermostat 2441TH [03] Mode=Auto Fan=Auto


    So, two anomalies from my perspective:
    1- Changing the 2441TH mode (program to auto) should not affect the fan's mode
    2- Knowing the actual state of the 2441TH only after processing all 'sub-commands'

    What do you think?

    Leave a comment:


  • claude
    replied
    I've got pretty well everything under control, except the fan.

    Nov-05 16:01:30 Event Event [NOT USED] CVtests CVtest Tstat - All away: set Tstat on Eco triggered by the event page 'Run' button.
    Nov-05 16:01:30 Event Event Trigger "[NOT USED] CVtests CVtest Tstat - All away: set Tstat on Eco"
    Nov-05 16:01:30 Device Control Device: Thermostats Insteon 2441TH Program to Eco mode (1)
    Nov-05 16:01:30 Insteon Thermostat SetProgram: [2441TH] [Eco mode]
    Nov-05 16:01:30 Insteon Thermostat SetMode: 2441TH Mode = Auto
    Nov-05 16:01:30 Insteon Thermostat TransmitInsteon: [2441TH] [1F] [6B] [06] ((([00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [8F])))
    Nov-05 16:01:33 Insteon Thermostat SetFanOn: 2441TH Fan = On no change so skipping device update
    Nov-05 16:01:36 Insteon Thermostat SetHeatSetpoint: 2441TH set heat setpoint to 18 Current heat setpoint = 16 Current cool setpoint = 23
    Nov-05 16:01:36 Insteon Thermostat SetHeatSetpoint: 2441TH Heat SetPoint = 18
    Nov-05 16:01:36 Insteon Thermostat TransmitInsteon: [2441TH] [1F] [6D] [24] ((([00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [6F])))
    Nov-05 16:01:39 Insteon Thermostat SetCoolSetpoint: 2441TH set cool setpoint to 25 Current cool setpoint = 23 Current heat setpoint = 18
    Nov-05 16:01:39 Insteon Thermostat SetCoolSetpoint: 2441TH Cool SetPoint = 25
    Nov-05 16:01:39 Insteon Thermostat TransmitInsteon: [2441TH] [1F] [6C] [32] ((([00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [62])))
    Nov-05 16:01:42 Insteon Thermostat 2441TH [03] Mode=Auto Fan=Auto


    As soon as I manually initiated event "All away: set Tstat on Eco", the fan actually stops. The debug logs eventually confirms that.

    Any thoughts?
    Attached Files

    Leave a comment:

Working...
X