thinking aloud (about hvac software)
Mar. 23rd, 2023 07:04 pmSo I’ve got hardware now to give me software control over 1-4 air intakes, and I need to have some sort of way(s) to control all that.
But so far, here’s the thing: basically all of it is passive on the server side, too. Nothing happens if you don’t hit the UI frontend. That’s made good sense up until now, because there’s no real need, and they refresh themselves every two minutes on the client side, so you’re always getting data, and that’s absolutely all that’s been needed for all of this – until now.
I mean yeah, there’s a saved state (the current mode) and cacheing (for partial/temporary loss of connectivity) but for the most part, it’s nothing where you’re maintaining an operational state.
So now I need to figure out: do I want to keep it operating like that? As long as there’s at least one UI pane up, it would work fine. The display panels themselves would drive the entire system, every time there’s a refresh (every two minutes) check to see what the fresh air state should be, calculate it, and set it that way. You don’t even need to check whether it’s already set, sending a command that maintains the current state has no effect on the hardware, and it’d make up for any lost packets or power issues that caused a state reset.
But it does require that an interface panel is always online, or the state just… holds forever.
The alternative is some sort of server-side task that actively runs on its own, no external interfacing necessary to make it go. The exact form that takes could be all sorts of things, from a background daemon to just crontab calls every five minutes or something. You’d still need interface panel interaction, for manual open/close and for basic schedule setup, but then all panels could be offline and everything would still work, just on the server.
There’s whiffs of cooperative vs. pre-emptive multitasking arguments here from back in the day – kinda – with panel-driven state management taking the unfortunate role of cooperative multitasking. But given that, I don’t think the contest necessarily plays out the same.
I still dunno.
Of course, I have other questions to play with too, like how the basic schedule is going to be maintained and what kind of interface you have and whether it’s like some kind of time list or an array of time slots that can be toggled, and so on. Both have advantages and disadvantages and I don’t have a quick answer to that, either. But I’ll have to pick something, regardless.
Lots to think about. Definitely lots to think about.
Posted via Solarbird{y|z|yz}, Collected.