Closed robjampar closed 1 year ago
Hi @robjampar
Thanks for this suggestion. I have just released a new version of the plugin with some form of this feature, I haven't tested it myself.
Thanks! I am testing this now and will report back here in a few days :)
Started testing this and sometimes it does not seem to turn off the TH16 even when the target temperature is reached - today my hot tub got to 55c before I realised 😂, I now think about it.... this was also happening before this targetTempThreshold was added so I think it is a unrelated issue.
I tried to look through the code to help, but I couldn't see anything obvious.
I'm thinking that maybe sendDeviceUpdate is unreliable and the newHeat/cacheHeat values might get out of sync so the plugin thinks it does not need to send the device an "off" update??!?... I think this could be what is happening because this value does not seem to be reconciled, for example if the device is turned off from an external source (e.g. the eWeLink app) nothing is reflected in HomeKit (or the plugin). This might be something useful to be implemented.
on another note this seems odd
because the the targetHeaterCoolerState is always 0 as defined here
The code references you have mentioned should be fixed in 8.12.1-beta.1... I will get back to you with explanations about the rest of the points you have mentioned... :)
Ah nice,
I can see the behaviour in that simulating a thermostat (or heater cooler or just a heater) in HomeKit means the thermostat state being on/off does not actually reflect if the switch (heat) is actually on/off... but I was suggesting maybe if a manual switch override occurs - eg the Sonoff device is turned off in app, then the HomeKit thermostat should turn off, and the same the for turning on...
but anyway I think that is a separate pattern from a sendDeviceUpdate "sync".
With the heater and cooler simulations, the plugin ignores incoming updates from the device (meaning that if you turn it on/off physically on the device or via the ewelink app, the plugin will ignore this.
The device offers two states to the plugin, ON and OFF.
A heater/cooler homekit accessory has three states, ON (HEATING), ON (INACTIVE) and OFF.
The plugin uses a cache to try and map these three states to the device's two, since it cannot determine the correct homekit state only from an incoming ON and OFF.
ON (HEATING) obviously relates to the device being ON ON (INACTIVE) relates to the device being OFF OFF also relates to the device being OFF
The plugin ignores incoming updates from the device as for example, if you turn the device OFF via the ewelink app then the plugin would not know whether the homekit heater should be in ON (INACTIVE) or OFF.
If you were to manually turn the device ON when the current temperature was higher than the target temperature, the plugin could know to turn the homekit accessory to ON (HEATING) but then would soon command the device back to OFF since the current temperature is higher than the target temperature.
Does this make sense?
I'm not saying there is potentially something wrong with these changes I have made for this feature request, but hopefully explaining why the plugin cannot take into account incoming updates from the TH device for heater and cooler simulations
sometimes it does not seem to turn off the TH16 even when the target temperature is reached - today my hot tub got to 55c before I realised
Is it possible that this issue is if there are network issues and an off command fails and the plugin is ignoring updates and using the cache so it thinks the device is off when actually it is on and does not ever try to turn it off again?
Started testing this and sometimes it does not seem to turn off the TH16 even when the target temperature is reached - today my hot tub got to 55c before I realised 😂, I now think about it.... this was also happening before this targetTempThreshold was added so I think it is a unrelated issue.
I have had a similar problem and I can only think it's with the ewelink app/device operation. I control my hot water with a TH10 fitted with a thermometer probe into the HW tank. I have set the app with: auto mode 24hours everyday If temperature >48'C, switch off. If temperature <39'C, switch on.
This works fine in Auto but as soon as you manually turn on or off via the app or HomeKit/homebridge it will continue outwith the setting parameters.
The terminology for the period between the settings is referred to as 'dead band', no action occurs. This is normally set to alleviate overshoot or continual on/off as you initially experienced
Thinking about the fix for this issue would be to toggle the "auto mode" off/on after every manual action (sledgehammer walnut).
.
Yes, I have a very similar setup and it also works fine for me using ONLY the eWeLink auto mode.
But if I turn that off and use just the home bridge plugin with the "targetTempThreshold" to do the same thing, it works mostly, but then sometimes just does not shut off.
I still think this could be the case
Is it possible that this issue is if there are network issues and an off command fails and the plugin is ignoring updates and using the cache so it thinks the device is off when actually it is on and does not ever try to turn it off again?
Hi, Closing this just as been a little overwhelmed with issues recently. If this is still an issue or a feature you would like implemented then please do re-open this ticket! Thanks for your understanding!
A configurable temperature threshold for the heater mode for the Sonoff TH10/16 would be really useful - i.e
I am using a TH16 to trigger a system that heats a hot tub, and it's inefficient to have it cycle rapidly to keep an exact temperature. I would like it to turn on when it is 2 degrees below the target temperature, and then turn off when it reaches the target.
I am sure this would be useful for other cases where rapid on/off is inefficient, or also where a range of temperatures is acceptable.
Here is how I think it can be implemented:
https://github.com/bwp91/homebridge-ewelink/blob/9ef9c2de83e7fff68960639999cdf487eb7ff15f/lib/device/simulation/th-heater.js#L298-L306
gets replaced with something like (a similar pattern can also be used in th-cooler.js)
and then to the config https://github.com/bwp91/homebridge-ewelink/blob/9ef9c2de83e7fff68960639999cdf487eb7ff15f/config.schema.json#L1120
add this