I’m currently running HAOS inside of a proxmox VM. I would like each resident’s instance to be individual to THEM and THEIR ROOM. I don’t want ANY chance of their buttons/integrations/automations to affect another resident’s room.
How would you go about this?
Zigbee? Thread/Matter?
I’m new to these protocols, and am worried about crosstalk/interference/etc.
There’s going to be a new building, and I’m interested in getting smart switches installed in the walls and networking planned ahead of time for this. I’d like to minimize cost as much as possible.
Would 160 rooms of zigbee devices work cooperatively as a mesh or just jabber on top of each other until they can’t hear anything anymore?
There will hopefully be robust wifi in MOST of the rooms, but as it’s set up now, some rooms have worse WiFi than others with the WAPs set up in the hallways outside of the rooms. Hopefully there will be ethernet drops in all of the rooms, but I believe we will be disallowed from running 160 WAPs.
Is HomeAssistant a good fit for this?
My current building has approx 130 rooms across 4 floors, so something like 31-33 rooms per floor (some floors have more /less)
I could probably set up a small server at each nursing station. I was thinking a proxmox node per floor, with a backbone connection for failover, and a conbee link or something similar attached to the server if zigbee is indeed the best option.
Has anyone here ever done a commercial deployment?
Personally, I’d think very carefully before deploying HA in an environment where there’s any expectation of stability. At the very least, you’d need to disable automatic updates. Plus, once you have a stable environment - don’t update!
IMHO HA still has too many breaking changes to be considered a “production-ready” solution.
If I standardized the equipment I feel comfortable enough coding to roll out a solution that’s just jurunning raw MQTT messages to zigbee tranceivers. I’m just completely inexperienced and don’t know which direction to start moving in. The biggest and only requirement that I have is that I can use something like Tasmota to roll out custom MCU solutions for accessibility purposes, custom sensors and buttons and the like for integrations with power wheelchairs and the like.
I would start with a formal (documented) set of functional requirements - not hardware requirements. I want to define what the system needs to do before I decide how to do it. Then I can start to focus on potential options for how to do it. Then I would pilot/test those options on a small scale to see if they meet my functional requirements before scaling up.
I try to think long term too. It’s not just about picking hardware and installing it. What are the performance requirements? The expansion requirements? Backup / recovery, disaster recovery requirements? Support requirements? Regulatory requirements? Decommissioning requirements? etc.
Yes, there are folks that have deployed HA in a commercial environment.
Excellent starting place. And those functional requirements should include something along the lines of “all user interfaces (eg buttons, switches) should work as normally expected even if the automation system is down. Eg, a light switch should continue to turn the light on and off even when the HA system is not operating.”
I would just like to echo ALL the advice given here. HA isn’t quite stable enough to be “production ready” in an environment such as you describe.
Local control should ALWAYS remain possible if the automation fails.
Defining the list of functional requirements should always come first.
Having gotten beyond all of that, your initial requirement should preclude HA from the running in the first place:
“I would like each resident’s instance to be individual to THEM and THEIR ROOM. I don’t want ANY chance of their buttons/integrations/automations to affect another resident’s room.”
The ONLY way to accomplish that would be to give each room it’s own HA server. While entirely possible with virtualization, this would make the use of things like zigbee, z-wave, or anything other than ethernet/wi-fi all but impossible. Trying to hang 30-some-odd zigbee dongles off a single server would not only be incredibly difficult, but also quite likely cost-prohibitive.
At present, there isn’t a reliable way to prevent users from traversing parts of the system they should not be in. This has been a complaint of the community for some time now, but to my knowledge, no good solution has been put in place for UAC.
As a inspection and maintenance technician for a company that implements nurse call systems. I would like to respond, but I would definitely want to follow this topic because it has tickled my interest.
I definitely think you should create a set of functional requirements like @MaxK suggested (and all his other suggestions),
I would also make sure everyone involved knows who’s responsible for the (poor) WiFi and other network-issue’s (put it in writing); it’s going to hurt your systems performance, the user experience and possibly or probably your brand/reputation.
Other then smart switches, you didn’t express exactly what your ultimate goals are? What exactly is it that you are trying to accomplish (manage)?
IMO, this is not a good application of technology if you want to control anything more then some peripheral switch’s (in this environment and scale). If you are looking for more detailed control, such as presence detection, entry control, lighting, climate,… etc, I can almost guarantee it will fail and most likely in a spectacular way.
What you need to look for is a BMS/BAS/EMS (building management system). Look at Niagara Framework (Honeywell), Yardi, MRI etc…
Agree. I neglected to mention above that functional requirements need to be associated with why you want to do this.
Regardless of the solution and because this is a commercial installation, I would want to see measurable results. I assume X dollars will be spent to achieve Y benefits (return on investment). Every functional requirement should be tied to a measurable cost AND benefit (expressed in dollars).
To echo the other comments in a more direct manner, quit while you’re ahead. HA is not quite ready for primetime applications like you vaguely described.
You’d be better off looking at available options such as Caavo
Another thing to consider on top of all the intelligent responses here, is the coverage and cost of liability. If the system glitches and the lights go out while somebody is walking and falls and hurts themself, or if something similar happens that directly or indirectly causes bodily harm to somebody - can your company survive that? Morally do you want somebody’s injury on your shoulders?
I’m not saying that it can’t be done, but you simply can not be too prepared for the unexpected when dealing with the health and welfare of others. Get a lawyer, get an insurance agent, get an accountant and spend a lot of money with all of them consulting before you ever deliver a proposal to the client.
Smart home systems do not work. Honestly. None of them. We are hobbyists and tinkerers, we get a lot of fun and personal satisfaction out of making the lights go on and off and figuring out why they didn’t, but our wives know perfectly well that it’s all nonsense.
If you try to automate care for the vulnerable someone will die.
HASS does not have RBAC - Role Based Access Control
RBAC is critical to ensure Resident 1 can’t access Resident 482’s devices, nor what could be considered PII Personally Identifiable Information. 500 instances of HASS on a VM might be possible, but would be horrid to administer.
(A robust naming convention might help, but consider the value to an attacker discovering the network. This comes up at conferences all the time after bored penetration testers find out how badly their hotel room is secured!)
All centralised technologies have issues scaling.
Industrial and building automation protocols like KNX scale better, but at least will require several controllers (one per floor?) with a central monitor (publish to a separate backbone MQTT broker?).
Many BA systems use distributed control, with sensors communicating directly to devices with central configuration only getting involved when required (e.g. lights out, temperature set point).
Separating shared infrastructure into residential units is hard.
I worked on a study for a health care provider and the issue back then was that devices assume they are on a single home LAN (broadcast domain). This means kit like a Google Chromecast uses multicast to allow ANY device on the same LAN segment to control it by default. Conversely, public WLAN typically includes device separation to prevent Mallory from attacking Alice and Bob meaning casting and air* can’t work.
This shifts the “create a home unit” problem to the WLAN management layer to map each device to a residential unit, and maintain it.
Family visitors might expect to be able to show their phone pictures on the big screen like they do at home, and those non-IT folk on the wards will get the “my iPad doesn’t work” questions.
Z-Wave has been deployed at scale in large hotel buildings using remote coordinator modules (i.e. one per 1-2 rooms despite a 240 device limit) powered by PoE and controlled centrally over Ethernet. Sadly, the protocols were never released so FOSS couldn’t try to support the hardware.
Stacey on IoT had a report on US insurance providers and condo builders looking to install home automation to reduce maintenance costs (water leak detectors) and provide revenue (monthly fees) but I don’t remember the tech being considered.
I’ve discovered this through my later research since posting this. I saw something called ‘room assistant’ that might have been neat, but seems more focused to tailoring requests to room presence instead of segmenting a ‘network’ of devices.
this post!