Whilst it’s nice to have the computer algorithm and the heat pump working together to run efficiently, it’s important that the users are comfortable.
In my set up the users can turn on the heat pump at the flow controller in the machine room, with the vendor supplied mobile application or vendor website.
Notably this means the algorithm shouldn’t just step in an undo what the people just did. In fact, the algorithm doesn’t know what caused the change in state. I recently put a button on a dashboard in Emoncms and that can also be used to “boost” the heat pump for example.
So far I haven’t got round to reviewing the external intervention, but I am logging all the state every minute and also the actions my algorithm has performed so I’ll be able to identify at state changes that it wasn’t responsible for.
What has been interesting so far is that anecdotally I think the other users have intervened twice in five months to turn the system on. So I think the control algorithm is working OK.
It’s helped the user acceptance factor hugely by being able to say to the users “at any point you can change whatever you like”.
I used to work in an award winning green building where you could not decide when to open the windows. Despite the best intentions of the designers, it clearly wasn’t working properly and the users were incredibly frustrated that the machines were in control. On one occasion it even opened the windows during a Summer rainstorm and let the rain in on the computers and documents that were on the windowsill.
I know this doesn’t look like an “improve efficiency” tip, but as a developer it’s comforting knowing that if the efficiency algorithms go too far then the users will still be OK. It’s meant that I’ve been able to push closer to the edge of the comfort envelope and inevitably sometimes beyond it.
Of course I’m fortunate that I don’t have any vulnerable people in the building so I can experiment more wildly.