<p dir="ltr">Nest is a business built on (1) shiny and (2) creating setpoint schedules based on nudges up and down.</p>
<p dir="ltr">They've managed it for people who run like clockwork but are too lazy/stupid to set a clock.</p>
<p dir="ltr">It fails hard if there's the slightest variability in lifestyle or comfort criteria though.</p>
<p dir="ltr">Hard problem. Luckily (1) shiny is most important. </p>
<p dir="ltr">More codified fudge factors based on weather (cloud cover for solar gain, windspeed for draughts) to influence actual setpoint vs perceived setpoint; and ramp rate/setpoint influence that depends whether you're heating up to a setpoint from sleep mode/out mode/or as a bake/freeze request; sound more promising to me. </p>
<div class="gmail_quote">On 13 Jul 2016 10:36 a.m., "Damon Hart-Davis" <<a href="mailto:dhd@exnet.com">dhd@exnet.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
A very interesting thread thank you.<br>
<br>
> On 12 Jul 2016, at 16:15, Lisa Ann Pasquale <<a href="mailto:lisa.pasquale@six-cylinder.co.uk">lisa.pasquale@six-cylinder.co.uk</a>> wrote:<br>
><br>
> Humidity is a metric which is more relevant for controlling ventilation than heating. When the humidity rises, you need to ventilate to remove the moisture. Increasing the temperature only disperses it and adjusts the dewpoint - it doesn't remove the moisture, which is a risk of condensation and mould problems within the home - regardless of comfort. Tweaking the temperature is unlikely to alleviate discomfort caused by high or low humidity levels as efficiently or effectively as ventilation.<br>
<br>
The only effect humidity has on our temperature setpoint currently is to raise the frost protection temperature if RH is high to try to prevent condensation.<br>
<br>
We could provide more subtle tweaks to the set point (principally I’d be interested in opportunities to turn down the set point to save energy if the user wouldn’t notice), but I suspect that they’d be lost in the noise.<br>
<br>
Note that the rather nice humidity and temperature sensor that we use (SHT21) is more expensive than and larger than and has tougher power supply requirements the temperature-only device that we otherwise use (TMP112).  There is a significant cost implication of using RH (maybe even a fiver at retail) so it needs to pay its way.<br>
<br>
> There's been some good research on fuzzy logic controls, in the past, which most closely relates to how we control our comfort from an adaptive comfort perspective. One of the main tenants of adaptive comfort is that we 'adapt' when we feel DIScomfort. It's not a means of maintaining comfort so much as a means of continually eliminating discomfort. Might sound like two sides of the same coin, but the distinction is actually very important in control logics. Some fuzzy logic controllers even take into account the likelihood of window opening, as it may relate to outdoor noise levels, etc.<br>
><br>
> personally, I'd be very interested to see a controller which allows people to adjust the thermostat based on "I'm too hot", "I'm too cold" commands to boost temperatures for short periods of time. That way, when an individual might be wearing heavier clothes than normal (like, when I'm cooking in a hoodie), I can just tell the controller "I'm too hot" and it adjusts the temperature accordingly. Or when I'm walking around barefoot (for whatever reason), I can say "I'm too cold" and the temperature bumps up for an hour or two. That responds to my immediate needs for comfort, and also gives me a chance to either peel off a layer, or put on some slippers once the discomfort has been alleviated (which, again is "adaptive"...).<br>
<br>
Our ‘bake’/‘boost’ mode is intended to be a “I’m too cold” or “make me warm” temporary override.<br>
<br>
> The learning/programming part would need to consider how often someone calls out they're too hot or too cold at specific times of day, and at give set points. It would need to learn a safe "base" behaviour, and then be able to identify 'outlier" requests which can be excluded from being averaged into the base behaviour.<br>
<br>
Yes, indeed.  I’m keen on the ‘median filtering’ type of approach.  We already apply filtering to some stats records.<br>
<br>
Thank you.<br>
<br>
Rgds<br>
<br>
Damon<br>
<br>
_______________________________________________<br>
OpenTRV-interest mailing list<br>
<a href="mailto:OpenTRV-interest@lists.opentrv.org.uk">OpenTRV-interest@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-interest" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-interest</a><br>
</blockquote></div>