I have spent over ten years (Mostly a few hours a week or less, it's pretty much done except when I want a new feature) developing a haunted house and room escape tech stack...
It's mostly the same as general home automation, except with a lot more need for audio, digital signage, DMX lighting, and media features.
And things have to be reliable on a budget. A raspi on an SD card is what you get, anything more takes away from much more important things.
Plus, live programmability, observability and diagnostics, and things like that are critical. Stuff might go wrong and you only have five minutes to fix it. This might involve actually changing game logic. It shouldn't, but it might anyway.
If you can't, you need to at least be able to take manual override control.
And you have to be able to show others how to use it extremely quickly, possibly over the phone.
Nobody dies if it goes wrong, so you can afford more complexity than industrial SCADA, but you still want much higher reliability than people expect from consumer tech.
There's a lot of automated testing, and thinking about edge cases, but not as much low level first principles work, although the firmware on remote embedded controllers has a bit more of that.
You can live with the 99.9999% (or whatever the case may be, I highly doubt anyone has real numbers for a lot of this stuff) reliability of an average complex framework, but something that can't handle a USB getting unplugged and replugged in a different port is unacceptable.
It's quite cool honestly, well done to the developer. It works, so it's de facto a good solution.
> The hard parts weren’t the architectural pattern - they were embedded systems constraints. Tuning buffer sizes and designing components shallow enough to fit in 512 bytes required iteration.
I am a bit confused by the choice to use HATEOAS for this. Given the hardware constraints of the controllers I wouldn't have figured that doing handlebars style html templating is a good use of resources, rather than just sending raw data to the client and having it handle the presentation. I probably would have returned a blob of data from the servers and handled everything on the client, but I also am a UI guy first and foremost...
"I probably would have returned a blob of data from the servers"
That would certainly work, but adding new functionality to the rooms would require changes on the controllers (implementing the new JSON API) and on the client (calling, handling, and rendering the new feature). I wanted to minimize development time for myself now and make it possible to add new features using only C++ later.
Having the server declare the supported actions (not all rooms support the same features) and how to invoke them accomplished that. This independent evolution was a big reason why I leaned into HATEOAS.
"wouldn't have figured that doing handlebars style html templating is a good use of resources"
I didn't do a size comparison between the HTML fragment and a JSON response. Next time I'm at the house I'll come up with some measurements and add it to the article - I think it's interesting. That said, the performance was more than enough for the business and each of the controllers still had plenty or RAM and Flash Memory available, I didn't need to optimize this area. If I was going to, I'd want to avoid going through the buffer so many times.
That said, the simplicity and robustness of the HATEOAS approach were the main goals. I wouldn't use it for something like high-frequency trading where every byte matters.
I can’t stand this acronym. Why would you ever create an acronym where the first 4 letters are “HATE”? All I ever hear in my head when I read that is “HateOS”
edit: ALSO, whoever made went particularly out of their way to make it so — typically words like “as” and “the” aren’t included in acronyms. Arrgghh it grinds my gears so much!
I actually can't find a source for the acronym's origin. The full phrase comes from Roy Fielding's PhD Thesis, "Architectural Styles and the Design of Network-based Software Architectures":
https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dis...
I'd love a source on the acronym if someone has it.
11 comments
[ 1.6 ms ] story [ 38.6 ms ] threadIt's mostly the same as general home automation, except with a lot more need for audio, digital signage, DMX lighting, and media features.
And things have to be reliable on a budget. A raspi on an SD card is what you get, anything more takes away from much more important things.
Plus, live programmability, observability and diagnostics, and things like that are critical. Stuff might go wrong and you only have five minutes to fix it. This might involve actually changing game logic. It shouldn't, but it might anyway.
If you can't, you need to at least be able to take manual override control.
And you have to be able to show others how to use it extremely quickly, possibly over the phone.
Nobody dies if it goes wrong, so you can afford more complexity than industrial SCADA, but you still want much higher reliability than people expect from consumer tech.
There's a lot of automated testing, and thinking about edge cases, but not as much low level first principles work, although the firmware on remote embedded controllers has a bit more of that.
You can live with the 99.9999% (or whatever the case may be, I highly doubt anyone has real numbers for a lot of this stuff) reliability of an average complex framework, but something that can't handle a USB getting unplugged and replugged in a different port is unacceptable.
https://github.com/EternityForest/KaithemAutomation/tree/mas...
> The hard parts weren’t the architectural pattern - they were embedded systems constraints. Tuning buffer sizes and designing components shallow enough to fit in 512 bytes required iteration.
I am a bit confused by the choice to use HATEOAS for this. Given the hardware constraints of the controllers I wouldn't have figured that doing handlebars style html templating is a good use of resources, rather than just sending raw data to the client and having it handle the presentation. I probably would have returned a blob of data from the servers and handled everything on the client, but I also am a UI guy first and foremost...
"I probably would have returned a blob of data from the servers" That would certainly work, but adding new functionality to the rooms would require changes on the controllers (implementing the new JSON API) and on the client (calling, handling, and rendering the new feature). I wanted to minimize development time for myself now and make it possible to add new features using only C++ later.
Having the server declare the supported actions (not all rooms support the same features) and how to invoke them accomplished that. This independent evolution was a big reason why I leaned into HATEOAS.
"wouldn't have figured that doing handlebars style html templating is a good use of resources" I didn't do a size comparison between the HTML fragment and a JSON response. Next time I'm at the house I'll come up with some measurements and add it to the article - I think it's interesting. That said, the performance was more than enough for the business and each of the controllers still had plenty or RAM and Flash Memory available, I didn't need to optimize this area. If I was going to, I'd want to avoid going through the buffer so many times.
That said, the simplicity and robustness of the HATEOAS approach were the main goals. I wouldn't use it for something like high-frequency trading where every byte matters.
edit: ALSO, whoever made went particularly out of their way to make it so — typically words like “as” and “the” aren’t included in acronyms. Arrgghh it grinds my gears so much!
I'd love a source on the acronym if someone has it.