thinking aloud (about hvac software)

[solarbird]

So 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.

Comments

[vatine]

I would personally be tempted to make it a "scrape-centric" server-based design. This is definitely NOT purporting to be "the best design", nor a "please do it this way". It also comes from a background of "let's make something designed to be minimally operationally hassle-y, when I have N things and add one more".

When a UI panel setting is made, nothing is communicated externally, but the panel "remembers". Periodically (with cadence probably half of "I am willing to wait delta-t for a change to start propagating"), something central scrapes all the UI panels, finds the combined set point(s), and send actuating commands to all the intakes (and possibly other things), then stores the latest set of "set points" somewhere, for the "I crashed!" scenario.

UI panels periodically scrape central server and other components, and presents that (so if you change a set-point on UI panel B, that would be visible on UI panel K, within ~2-3 scrape intervals).

Although once you have a central server, it MAY make sense to actually put the "scrape info from air intakes, temperature, and air quality sensors" there, rather than out on each UI panel, mainly to keep down the amount of places to change configuration as you add, remove, or re-address sensors. That would also trivially allow set points to be gauge metrics in some sort of time series database, for future analysis and what-not.

Of course, you could put the scraping both on the central server and out on the UI panels, and simply have the UI panels grab the configuration information from the central server, when they query set-points.

[solarbird]

Well, the panels aren't doing the scraping themselves now. They're just triggering it. The panel software itself is just... any web browser post the introduction of simple CSS. It'll run just fine on a first-gen iPhone.

So it's currently the server doing all the work, but none of that work is triggered until it gets a browser hit. So the existence of clients making information request is acting kind of as a scheduler.

[vatine]

Ah, I see. That probably makes it simpler, and you could probably get a simple heartbeat merely from having curl in a crontab.

[solarbird]

I was thinking about that, but it seems like such a hack xD

(But it might be the right hack...)

[vatine]

Does it work? [1]
Does it require recurring maintenance? [2]

If you tick both box 1 and 2 it is a horrible hack. If you tick box 1, but not box 2, I'd a neat hack. If you tick neither box, eeeeh, and if you tick box 2, but not box 1, it's an unsightly bodge. :)

[solarbird]

Y'know, the more I think about it, the more I'm like "structurally, if I don't just do cron+curl, what I'd be doing is creating two stacks, or to avoid that, I'd have to re-implement the entire existing structure in the new stack for no good reason."

I think I'm doing the hack. xD

[stickmaker]

When I took Civil Engineering in college in the mid-Seventies, HVAC stood for High Voltage Alternating Current. :-)

[solarbird]

I've heard of HVDC, so it makes sense there'd be an acronym for high-voltage AC as well, though I can't say I've seen it much. HVAC for AC and AC/heating combinations goes back to the 1940s, though.