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.
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.
https://github.com/EternityForest/KaithemAutomation/tree/mas...