phenotypic / homebridge-web-thermostat

Homebridge plugin for a web-based thermostat
MIT License
18 stars 15 forks source link

checkupDelay does not update #24

Closed basvdploeg closed 2 years ago

basvdploeg commented 2 years ago

I happily made the plugin work with my thermostat, but there is one problem I discovered. The targetHeatingCoolingState and currentHeatingCoolingState are not updating after setting a HeatingCoolingState.

The default should be set to 2000 (ms), but it doesn't seem to do anything. I also tried adjusting the delay to a different number (5000) and unfortunately that makes no difference.

Is this a known issue or am I doing something wrong?

phenotypic commented 2 years ago

Hi there, thanks for opening this issue. Unfortunately I was unable to replicate your issue. checkupDelay seems to be working as expected.

Here is the example config.json I used for the accessory:

{
       "accessory": "Thermostat",
       "name": "Thermostat",
       "apiroute": "http://[::]:8080",
       "checkupDelay": 5000
}

Then when I run homebridge in debug mode (homebridge -D), I get the following when I setting the HeatingCoolingState:

Starting to advertise 'Homebridge AA92' using bonjour-hap backend!
[11/01/2022, 12:14:52] Homebridge v1.3.4 (Homebridge) is running on port 51826.
[11/01/2022, 12:14:52] [Thermostat] Device response: {
    "targetHeatingCoolingState": 0,
    "targetTemperature": 22,
    "currentHeatingCoolingState": 0,
    "currentTemperature": 20.5
}
[11/01/2022, 12:14:52] [Thermostat] Updated TargetTemperature to: 22
[11/01/2022, 12:14:52] [Thermostat] Updated CurrentTemperature to: 20.5
[11/01/2022, 12:14:52] [Thermostat] Updated TargetHeatingCoolingState to: 0
[11/01/2022, 12:14:52] [Thermostat] Updated CurrentHeatingCoolingState to: 0
[11/01/2022, 12:15:22] [Thermostat] Setting targetHeatingCoolingState: http://[::]:8080/targetHeatingCoolingState?value=1
[11/01/2022, 12:15:22] [Thermostat] Set targetHeatingCoolingState to: 1
[11/01/2022, 12:15:27] [Thermostat] Getting status: http://[::]:8080/status
[11/01/2022, 12:15:27] [Thermostat] Device response: {
    "targetHeatingCoolingState": 1,
    "targetTemperature": 22,
    "currentHeatingCoolingState": 1,
    "currentTemperature": 20.5
}
[11/01/2022, 12:15:27] [Thermostat] Updated TargetTemperature to: 22
[11/01/2022, 12:15:27] [Thermostat] Updated CurrentTemperature to: 20.5
[11/01/2022, 12:15:27] [Thermostat] Updated TargetHeatingCoolingState to: 1
[11/01/2022, 12:15:27] [Thermostat] Updated CurrentHeatingCoolingState to: 1

As you can see, exactly 5 seconds after I set a new HeatingCoolingState, both currentHeatingCoolingState and targetHeatingCoolingState are updated. This is also reflected in the app.

Since you are experiencing this problem with your own fork of the plugin, I'd suggest reviewing any changes you have made. Feel free to include your config.json and homebridge debug log to see if the error can be spotted.

basvdploeg commented 2 years ago

Thank you for the response! Just to be clear; I'm not using a forked version, just the latest version on Github.

I enabled debugging mode and don't see anything weird:

[1/11/2022, 3:44:12 PM] [Remeha eTwist] Setting targetTemperature: http://[::]/targetTemperature?value=20.5
[1/11/2022, 3:44:14 PM] [Remeha eTwist] Set targetTemperature to: 20.5

It just doesn't seems to get to the "Getting status" part like in your example.

This is my configuration:

{
    "accessory": "Thermostat",
    "name": "Remeha eTwist",
    "apiroute": "http://[::]",
    "minTemp": 5,
    "maxTemp": 25,
    "model": "eTwist",
    "manufacturer": "Remeha",
    "serial": "20380289",
    "firmware": "1.93.12",
    "checkupDelay": 5000,
    "validStates": [
        0,
        1
    ]
}

Oh, and the pollInterval seems to work fine, because I get the polling messages after the default interval time:

[1/11/2022, 3:58:02 PM] [Remeha eTwist] Getting status: http://[::]/status
[1/11/2022, 3:58:03 PM] [Remeha eTwist] Device response: {"targetHeatingCoolingState": 1,"targetTemperature": 20.5,"currentHeatingCoolingState": 0,"currentTemperature": 20.5}
[1/11/2022, 3:58:03 PM] [Remeha eTwist] Updated TargetTemperature to: 20.5
[1/11/2022, 3:58:03 PM] [Remeha eTwist] Updated CurrentTemperature to: 20.5
[1/11/2022, 3:58:03 PM] [Remeha eTwist] Updated TargetHeatingCoolingState to: 1
[1/11/2022, 3:58:03 PM] [Remeha eTwist] Updated CurrentHeatingCoolingState to: 0
phenotypic commented 2 years ago

Thanks for getting back to me with your config.json and debug log.

Everything seems to be set up properly in the config.json (validStates can fit on one line, e.g. "validStates": [0, 1]).

As you point out, there seem to be no errors in the debug log, although your instance doesn't seem to get to the Getting status part after the checkupDelay.

Unfortunately I have not been able to replicate this error on my machine so it is difficult for me to work out what the problem is. I'd recommend updating homebridge to the latest version and then uninstalling and reinstalling homebridge-web-thermostat if you haven't already.

checkupDelay was only introduced in v1.3.8 so please verify on homebridge startup that the version you are running is equal or higher to that.

basvdploeg commented 2 years ago

Both Homebridge v1.3.9 and the plugin v1.4.2 are up to date, so that's not te problem either.

It's not an incredibly big problem of course, but it would be nice to not have to wait for the next pollInterval after setting the temperature.

As you said it's not really easy to debug, since there are no errors in the log. So weird, your setup seems totally the same.

phenotypic commented 2 years ago

Hi again, I've just noticed that in the log file above where you note that your instance doesn't seem to reach the Getting status stage, you are setting the targetTemperature not the targetHeatingCoolingState.

targetTemperature does not make use of checkupDelay. Please could you run in debug mode again and post the log after changing the targetHeatingCoolingState to verify your issue.

If the the issue still persists, please could you perform a crude debug by adding this.log('CALLING GET STATUS') before the this._getStatus(function () {}) function call on line 168. Thanks.

basvdploeg commented 2 years ago

Oh, I feel kinda dumb now. You're totally right. I mistakenly figured that checkupDelay would also be applied when setting the targetTemperature. Is there a specific reason why it won't be applied to the targetTemperature updates?

phenotypic commented 2 years ago

No worries, could you confirm that checkupDelay is working as expected when you change targetHeatingCoolingState?

checkupDelay is not applied when setting the targetTemperature because the temperature updates in the app no problem once you have set it.

On the other hand, once you set targetHeatingCoolingState, the accessory will be marked as Idle until it has been confirmed that the device has correctly received/set the HeatingCoolingState.