Call for Collaboration: Home Assistant Safety, Security & Privacy

Development
1

Hi Home Assistant community,

My name is Dr. Tianzhi He, Assistant Professor at The University of Texas at San Antonio (UTSA). Together with Dr. Kyrie Zhixuan Zhou (UTSA), we are preparing a project proposal to the NSF Safety, Security, and Privacy of Open-Source Ecosystems (Safe-OSE) program focused on the Home Assistant ecosystem.

The Safe-OSE program supports projects that deliver practical, ecosystem-specific improvements to the safety, security, and privacy of mature, widely deployed open-source platforms. Home Assistant’s scale, diversity of integrations, and role in controlling real-world devices make it a particularly important ecosystem for this type of work.

At a high level, the proposed effort aims to:

  • Better understand safety, security, and privacy risks that arise in real-world Home Assistant deployments;
  • Work closely with the community to identify ecosystem-level challenges and improvement opportunities; and
  • Develop open-source, adoptable improvements that align with existing Home Assistant workflows and governance.

We are actively welcoming collaborators and community input, including maintainers, contributors, integration or add-on developers, power users, integrators, researchers, and organizations deploying Home Assistant at scale. Engagement may include sharing perspectives, participating in discussions, or collaborating on ecosystem-focused improvements if the project is funded.

If you are interested in learning more or potentially collaborating, please feel free to reach out:

:envelope_with_arrow: Email: [email protected]

Thank you for your time and for everything you do to support the Home Assistant ecosystem.

4 Likes
2

While a very noble aspiration that I entirely enthusiastically support, the term ‘herding cats’ initially sprang to mind.

How are you going to control a herd of programmers, coding with different levels of skills and experience, using different tools and languages, acting voluntarily, to solve issues they may not even be aware of? Some from non-USA background that are outside any NSF programs and controls, controlling predominantly Chinese devices with poor or no documentation, and certainly no source code to verify.

HomeAssistant is cobbled together with very few layered security controls. Bolting that on retrospectively will be a HUUGE challenge, requiring major redesign.

Forcing change by super-tariffs, import controls, and blacklists for suspect devices may be the most effective measure given the US is a major market that cannot be ignored, but fraught with danger and the hue and cry from international vendors. Easily bypassed by ‘creative labelling’.

The relentless march of progress, highly dependant on moving products out the door, regardless of quality, to maximise profit, considering security controls as an unnecessary overhead, will require a major change of mindset. The change may have to be forced by product recalls and bans and heavy fines for non-compliant devices.

You may wish to investigate the various bots that scan code prior to GitHub release to incorporate security checks and offer suggestions as a bigger project, with possible higher funding goals and collaboration with Microsoft, GitHub’s owners. Training the AI on good coding practices may be your bigger challenge, the current crop of LLMs embarrassingly hopeless at mastering Home Automation suggestions due to their algorithms sucking up outdated and faulty code from user forums that are experiencing problems, and serving up the slop as valid solutions.

By their very nature, HomeAssistant users are independent, fiercely so, seeking solutions to free them from the shackles of vendor control and cloud based data collection. This is a major selling point that forced controls will detract from, and result in splintering

Everybody has their own opinions, often wrong. Until the software industry moves from a cowboy culture to a mature art, you may be tilting at windmills. Witness the initial noble goals of Ada - where is it now? HomeAssistant has Python with all the lively spaghetti that entails. Even Matter, offering easy integration is not maturing fast enough to be a robust solution.

Best of luck.

1 Like
3

Thanks a lot for the thoughtful and candid response! we genuinely appreciate it! :raised_hands: :grinning:

You’re absolutely right that Home Assistant is, in many ways, a “herding cats” problem (I like this metaphor a lot). It’s a highly decentralized, volunteer-driven ecosystem with contributors and users spanning different languages, tools, skill levels, and regional contexts, integrating devices that are often not properly documented or opaque. From a security-engineering standpoint, the system is fragmented, and retrofitting strong, layered safeguards into a fast developing cyber-physical platform is undeniably hard.

I also want to mention that this trajectory is not unique to Home Assistant. Many successful open-source ecosystems went through a similar phase where functionality and adoption outpaced formal security design: early Linux distributions, Android’s early years, and the cloud-native ecosystems are good examples. None of these matured overnight. Progress came incrementally through better tooling, clearer threat models, improved defaults, and evolving community norms rather than centralized control.

One additional complexity, which you also pointed out, is the truly global nature of the Home Assistant community. Developers and users from the U.S., Europe, China, and many other regions often operate under different regulatory environments, threat perceptions, and usage priorities. People also bring different levels of technical literacy and different value tradeoffs: some prioritize convenience and functionality, others place more emphasis on long-term safety, security, and privacy. I personally don’t think these perspectives are “right” or “wrong”, they are simply different, and shaped by context.

Where Home Assistant is different, and where the stakes are higher, is that this is not just software. It is IoT and cyber-physical control. Misconfigurations or insecure integrations can lead to physical access risks, safety issues, and privacy leakage. The diversity of users, devices, and priorities makes these risks harder to reason about, and also makes them more important to study systematically.

We’re under no illusion that this can be “fixed” quickly or comprehensively. Heavy-handed enforcement would likely backfire and fragment the community. Our intent is far more pragmatic: to start by understanding how risks and tradeoffs actually emerge in real deployments, across regions and stakeholder groups, and then identify a small number of high-impact, ecosystem-aligned improvements that people might realistically adopt.

4

Reality is that most HomeAssistant integrations are independently developed by frustrated users, lacking proper (or non-existant) API documentation, reverse engineering vendor solutions (sometimes crudely), often by backdoors, interception of unencrypted traffic, or security defect exploits to roll their own firmware customisation, or most horridly, by following regurgitated outdated AI slop learned from analysis of buggy code reported by users in forums such as this, the very things you wish to eliminate. Others are simply screen scrapers repackaging data into the database for subsequent actions.

This is the strength of HomeAssistant, the ability to incorporate all these divergent solutions into something you can use to control your home, free from vendor control, cloud computing, and privacy data collection issues, fingers crossed, blissfully unaware of security and other IT industry best-practises.

Good luck with going along the path walked by ‘right to repair’ enthusiasts that are attempting to force manufacturers to release their intellectual property for the benefit of outsiders. While sharing IP in an educational scenario is often the norm, in commercial reality, you will face enormous barriers where it forms part of ecosystems that lock people into particular vendors and excludes all others. Ecosystems from vendors such as Tuya, Apple, Amazon, Google, Samsung, Honeywell, and the suchlike are not going to allow you intimate access to their integrations and solutions without some major incentives or threats to do so. See how fiercely John Deere has fought globally against farmers and quite smart people and others like politicians to protect their financial interests in their small sphere of agricultural equipment. You are facing global giants that make them look like small play.

Chinese/Asian vendors, used to cloning, copying firmware and hardware designs with no understanding of patents, product development, updates or ongoing support, just needing to make a barely working product on their kitchen table using children and grandparents to assemble them, to sell cheaper than the next vendor, are not going to modify their products to comply with your foreign suggestions. This will be your major barrier, as users, globally, universally, faced with a choice of two products, both functional, but one more expensive because it has a NSF certified tick, will ALWAYS choose the cheaper one, even if the difference is only one cent. That is human nature, something you will not be able to change.

5

Let me start off by saying I applaud this request. My response is not meant to downplay its usefulness.

While there certainly are a lot of security related risks involved with Home Assistant that could do with mitigation, I think that it is not realistic to assume that the improvements done with systems like Linux and Android can be of the same benefit to HA. The nature of the problem is vastly different.

Most of OS security is based on restricting access. Apps are basically sandboxed, allowing as little interaction between each other and the OS as possible. Also an attempt is made to only allow vetted apps to stores.

For Assistent is however trying to do the opposite. Its whole purpose is to allow the integrations to interact. Many integrations sole purpose is to use information from other integration and apply it to whatever else. Furthermore, the integrations are but a thin layer between systems from a myriad of vendors who will still do whatever they wish.

So indeed a lot can be done to protect Home Assistant because it is a doorway to anything connected. But at the same time I feel the dangers are also very high in the things being connected. HA can do little about that. Having devices connect using Google, Alexa or Siri is way more scary because they are company owned, closed source cloud systems.

Sandboxing is the opposite of what Home Assistant is for and vetting the thing that links them to HA (the integrations) is of less use because it is not where the risks are. They are but adapters.

Home Assistant is like a router in your home. Yes, it must be secured, but doing so will not make the computers in your network secure. And vetting integrations feels a bit like checking the ethernet cables. They are but the messenger.

If anything, Home Assistant also mitigates risks by allowing hardware to be used outside the manufacturers ecosystem, or by even taking over the firmware in devices using ESPHome.

Having said all that, it does not take away anything of the usefulness of making HA and ESPHome more secure.

Misconfigured integrations can only be a problem if the thing integrated with is publicly accessible and allowing this kind of misconfiguration. Apart from maybe door locks, HA’s weakest point is leaking information and the associated privacy risks. I’m not that scared of people messing with my light switch. HA is advocating and enabling local access, as opposed to cloud services offered by manufacturers.

Where Europe is at the forefront of trying to legislate digital services to try to protect privacy, The US government is pressuring (if not extorting) the EU to drop these laws. So even if HA security might be lax, I tend to see it as les of a problem than companies forcing is to use their cloud services and legislation letting them get away with it. Our phones are leaking way more information to the likes of Google, Meta, etc. than HA is despite the purported improved security.

To give an example, I just got a mail from Bosch, enforcing new privacy terms so they can share my data with subsidiary brands. If I do not want that, I would be forced to shut of their cloud, and in doing so lose HA control of it. They are forcing me to accepts worse terms, again after sale. If the device were to have local access, I would have kept it off cloud. Bosch does not need HA to leak my data.

Same for Bambu 3D printers. They were trying to limit local access in favour of their cloud. Turning it off means to lose access to, among others, their phone app. Limiting use after the sale. Luckily HA allowed me to in fact turn off cloud access and mimic their app, enabling me to send prints directly to the printer without Bambu cloud servers as a man in the middle.

Companies shutting down their cloud, essentially bricking devices happens more and more. Connected devices phome home more often than not. It is not HA doing it, it is HA trying to protect us from it.

Instead of sharing my detailed energy use with energy companies for the. to give me substandard information back about my own power use, I give only monthly data to them while I use high resolution energy information to control charging my car, operating the dshwasher (from Bosch, above) etc.

So maybe you should focus on trying to get the US to be on the forefront of privacy instead of its enemy. We need governments to protect us from companies, not goverments owned by companies. Home Assistant is doing its best, but it is powerless against the big companies. What we need is secure IOT devices, requirements to have local access that can provide the same level of functionality as cloud offerings.

Matter/Thread devices being able to reach the WAN is not a good thing. Zigbee/Z-wave are more secure in that sense.

TL;DR: We do not need IOT for our home, we need LOT (Lan of things.)

6

Thank you for sharing this. I think you captured something essential about the Home Assistant ecosystem.

I actually agree with you that this mix of creative users and developers is one of the platform’s biggest strengths. Many of the users who write custom integrations are exactly the same people who are experimenting, learning, and then generously sharing solutions with everyone else.

Speaking personally, when I first started using Home Assistant, I often reached the limits of what was documented officially. I learned a huge amount from other people’s posts and shared projects, GitHub repos and gists, YouTube tutorials, blog write-ups documenting how they “made it work”. Those contributions are incredibly valuable, many of us stood on that collective effort to get our own systems working.

You are also right that most of these integrations are functionality-driven rather than security-driven. People quite reasonably prioritize:

  • “Can I make this device work locally?”
  • “Can I connect X and Y the way I want?”
  • “Can I get this automation working?”
    rather than formal threat modeling, dependency audits, or secure-by-default design.

And that is exactly where our proposed project hopes to help, not by policing creativity, but by supporting it. Specifically, we aim to: (1) study how real users currently build integrations and automations, (2) identify where risks actually emerge in practice (3) understand the trade-offs users are making (functionality vs. effort vs. security & privacy). We want to work with the community to co-design improvements that don’t block creativity, don’t require rewriting the ecosystem, and fit naturally into existing workflows.

On the technical side, this likely includes approaches such as:

  • ecosystem-level threat modeling for Home Assistant use cases
  • static and dependency analysis for common integration patterns
  • supply-chain risk scanning for add-ons and custom components
  • usability studies on secure-by-default configuration options
  • developing light-weight tooling (linters, checkers, templates)
    that can warn people about high-risk patterns and suggest safer alternatives.

The intention isn’t to stop people from experimenting or hacking things together, that culture is what built Home Assistant. The goal is to make it easier to do the “safe thing” without getting in the way of creativity.

7

I agree with much of what you describe. The realities of the global IoT supply chain are exactly as you outlined: various vendors, weak security incentives, uneven regulation, and users who understandably prioritize price and convenience. That does make this space particularly challenging.

We are not assuming that manufacturers will suddenly cooperate, release their internals, or redesign devices because of an NSF project. And we are definitely not trying to “solve the global supply-chain problem” in one shot.

What we are trying to do is more modest and pragmatic: focus on the risks that Home Assistant users face today, understand how those risks actually arise in real deployments, and see where improvements can be made at the ecosystem and tooling level, even when upstream vendors do not change. In other words, not fixing everything, but reducing avoidable risk where we realistically can.

This won’t eliminate all vulnerabilities. But with a platform as widely used as Home Assistant, with control over real devices in real homes, it feels important to at least push things in a safer direction rather than do nothing simply because the full problem is large.

If you are interested in talking further or exploring collaboration ideas, I’m very happy to continue the discussion. Feel free to reach out at [email protected]

8

This is a really thoughtful take, and I think you’re right about something important: Home Assistant isn’t Android or Linux, and trying to copy-paste those security models doesn’t make sense. HA exists specifically so things can talk to each other, not be sandboxed apart or restricted to their own manufacturer’s cloud ecosystem, so the threat model is also different.
The “router” analogy fits well, and “vetting integrations feels a bit like checking the ethernet cables” honestly made me smile. It’s a great metaphor. A lot of the real risk lives upstream in devices, clouds, and vendor ecosystems, and HA doesn’t magically fix that just by being more secure itself.

At the same time, there’s a tension we can’t ignore. Yes, LoT setups like Zigbee/Z-Wave are often safer than WAN/Wi-Fi cloud device, but they’re also more expensive, require extra hubs, and take more effort to get going. Most people will pick whatever is cheaper and works out of the box with an app, even if the privacy trade-offs are worse. That reality is exactly why these conversations matter.

Where I’m coming from with this project is not “Let’s make HA more secure that will fix the whole IoT world,” because it won’t. The goal is much smaller: understand where things actually go wrong in real deployments and improve what can realistically be improved at the HA layer, defaults, guidance, guardrails, and tools, while accepting that many risks are in the devices and manufacturaer, or the government regulation themselves (which are really out of our control).

Thanks for pushing the discussion in this direction, this is exactly the kind of nuance the topic needs. Again, I’m very happy to continue the discussion. Feel free to reach out at [email protected]

1 Like
9

I live within 25 minutes of campus and just wrote you a DM. Call me.

1 Like
10

Home assistant is a hub. But unlike property hubs it doesn’t care about device manufacturer. If it have integration for device that is using some communication protocol, device will work in home assistant and you will be able to control it.
After all it is just home automation platform.
It will be secure or insecure as your own network is.
This is just a cherry on top of what you have in your home.
To make things work you should build infrastructure that will work underneath home assistant and provide it with all sorts of data.
And that is where the real work begins.
Because it is hard to build your home infrastructure.
It is up to everyone how will they do it, what protocol will they use for most of their devices and after all how will they engender their own network.
For me, i went with openwrt for routers, batman-adv for communication layer over wifi so i can have vlans and put everything i don’t want in main lan on vlans and opnsense for a gateway.
Imho openwrt with opnsense can build you a strong foundation for building things up.

11

Thank you all for your great work on HA and especially for starting this discussion! I’m quite new to HA (just few weeks) starting with implementing an electrical heating using HA/HACS on a performant OpenWrt router (several years experience here because of security and privacy concerns). I stumble about your discussion because I was required to implement a safety automation that prevents HA’s generic thermostat from burning my house
which was the result of a weak ALARP - risk analysis that I’m used to do lots of times. Please let me shortly introduce me to understand from where my experience comes and how I maybe could suggest little input to maybe go ahead?
From my experience in >15 years of developing automotive embedded safety systems I just very appreciate your request to systematically dicuss, control, regulate and reviews etc. But on base of my experience this will only work in professional safety development teams and only partly on FOSS projects like you already discussed above. Anyway there are some processes that can help us to improve HA if they aren’t already in place (I’m newbee here, sorry if I’m wrong).
1st: Wording Clarification
One thing I was triggered to write here is about mixing “security”, “safety”, “robustness” or “functional safety” as they are different sides of the same medal. This is an ongoing problem in every of my experienced safety projects and a major problem when talking with people with different skills and focuses.

I fully understand what you mean and exactly this is what I’m doing in my system when using Openwrt as OS for security and running HA mostly/only as zigbee coordinator that can communicate with non ip based sensors using UART over zigbee dongle - hope I’m right!?
But really sorry to correct you about that to be wrong if you strictly want to talk about safety - If I understand you right, you wanted to say that this maybe secure but it’s not safe!
Let me pls. give you an example about what I experienced that HA’s safety problem is that I have:

  • HA/Zigbee is not safe, as it can loose packets, often, any time (e.g. missing to switch my mains plug back to safe “off” state, which happens lots of times in urban areas like where I live. Not only this, it also happens if the “generic thermostate” systematically when its temperature is manually or automatically changed to a lower “sleeping” temperature, while the plug for the electrical heating was on. The Generic Thermostate’s safety bug is, that it never switches the heating to safely “Off”. Each of these two problems is itself a single point of failure that will sooner or later burn someones house if he is not aware about that:-(
    This is a catastrophic risk when using HA for heating control, which on base of a simple ALARP analysis must be undoubtedly highlighted when you develop any product that you wan’t to sell to any customer, but it will surely not, if customers develop homeautomation using HA on their own because its too easy to automate.
    2nd: Risk Dokumentation and Risk Process Development
    If you wan’t to address such problems systematically, it is prove of concept to first (safety first) install some simple safety processes which you maybe also can double up for security issues. Then Create a risk board (Team) where every one can easily highlight safety, security, robustness or funktional risks. A good designed risk formular (understandable for everyone) should be able to fill in risks with lowest effort (in seconds). Highlight the risk level (low medium high), show up solutions, who is involved, and how to understand the where it comes from and leads to.
    This risk board, which is a small group of security, safety, and core developers should judge about this, not one in person should be able to do it on its own! This judgment shall follow a strict process and lead to an exact mitigation strategy and priorities or shedules to follow to provide a solution for that safety or security risk mitigation.
    3rd: Risk Analysis, Review Process and Quality Management
    Here (in the risk board) we now may come to functional safety methods where we classify the risk and estimate appropriate safety levels which means we e.g. implement (low) functional safety to rule out >=70% of all risks or e.g. very high levels with e.g. 99% of all failures to be detected. All these methods are well documented as part of e.g. ISO26262 (automotive functional safety) or ISO62368 (industrial safety for office and home appliances ASFAIK)
    4th Traceability)
    This process must be ideally automatically traced (e.g. using JIRA, PTC, Doors,) and prevents, that critical issues find to a good finalization within required time.
    Maybe to be challenged here, or how can this be produced in FOSS projects?
    “Safety First”
    “There is no safety without security!”
    E.g. Security Hashed on finally approved safety solutions?
    5th: Ask for government, educational or public support?
    Here we maybe can close on of some of these rings as e.g. also goverments intend to invest public money to support this team on finalization of critical safety or security projects?

Sorry if these ideas are maybe not the direction you wanted to go with this discussion, perhaps you intended to more go into direction of security? But if there is further interest, I can offer to discuss my “electrical heating’s” safety analysis and plug blueprint/automation as an example that I already proved on 2 of five mains plugs and intend offer to free use for further improvement?
Thank you all, hope some of this maybe hopefully interesting for your discussion?
Wish you all a good and happy new year!

1 Like
12

While risk analysis should be comprehensive, low hanging fruit can be plucked first. No point in inspecting software for security compliance when the device is using cheap components of dubious source, often substituted based on cost. Fire risk beats firewall risk.

The whole supply chain needs remodelling. The cowboys need to be weeded out. This requires regulatory pressure as the industry has no financial incentive to do so, and the end user remains blissfully unaware. One arm of the government wants improved security, while another wants built-in back doors.

1 Like
13

Dear All, on base of my experience of integration my privacy focused, security hardened Openwrt hosting ZHA are neither unsolvable nor are all cheap sensors a major problem for improving any of the above discussed targets.
On the other side this discussion may never lead to any improvement if safety, security, functional safety, robustness, privacy and anonymity are mixed as it is done in this discussion. They are complete differing on base of methods and only may share similar tools if ever.
First I want to raise a question on the author of this article about the target of the request of coorperation: Do you want to 1. involve in ZHA development with respect to improvement of safety, security and privacy, or do 2. you wan’t to regulate and control the development in focus of these topics. What is the background and your honest intend to involve here?

How can we proceed ASAP?
Why do we not create a dedicated (lighthouse) project on security hardened hosting of ZHA, e.g. call it “(S)afety(H)ardened ZHA”

Focussing on security and privacy:
In my mind improving any of these topics but safety is already solved if HA supports openwrt as host system which has a big community that is spending all its effort and millions of hours on improving security, security hardening can be achived are many recipes and testing sites in the web. They (openwrt) have already addressed these topics and provided solutions for this and thus we do not have to reinvent this wheel again.
The only challenge that I see here is, that since 2025/12 HA has stopped supporting natively HA installations but its possible so far and I can help out to setup this. Privacy can be achieved by using only ZHA where all used sensors are required to strictly support the zigbee specifications. How ever the trustlevel or how bad the quality of these sensors and actors are may not be a big security or privacy concern because they will never be able to access internet if HA does not support it e.g. for providing e.g. firmware updates. They just communicate over a serial protocol providing stricly specified data and command types. But they are ASFAIK not able to do self initiated IP communications - pls. correct me if I’m wrong!?
If we would support the (Z)HA community with a strictly security hardened ZHA platform based on openwrt and HA community highlights this project we can realize an entry for better and much deeper understanding of the goals of this project and otherwise point everyone’s nose on the risks, that the “normal” system has.

Contradictions security & privacy vs. safety:
The caveat here will be, that for this hardened platform it would required in my mind, that we do not integrate any safety using HACS because it most probably would violate the security of this platform - do you agree? At the moment I can only integrate my safety goals using HACS.

Driving force and standards for safety improvements:
Back to my last somehow solved safety problem: According to the most common international safety standard, the IEC/UL ISO62368 “search for: IEC62368 S1 S2 S3 100W chart” you will find a device classification on base of Power classes P[W]<=15W<=P[W]<=100W<=P[W]. If people plug together any device into a system which provides <=15W no one cares about burning hazards. If I want to ZHA provide power for a IR-Heating panel I have e.g. 450W and have to be scared about highest fire risks. Anyway and even when the Zigbee switches that I use are providing up to 4500W I realize a system that should be designed and trusted to provide highest safety standards.
A short ALARP analysis (wikipedia ALARP) + automotive functional safety aspect “controllability”: Major Risk: Heating panel (assumed all properly/safely installed) is, that a very cheap switch does not switch of, the heating panel overheats and starts burning someones house, violating/injuring one or more people → Risk estimation catastrophic!!
Probability: Very likely (conservatively 1 fail per week)
Controllability: While sleeping - bad. If absent e.g. on holydays ->very bad.
Simplest safety measure: Secondary switch in cord to panel (good controllability with skilled personal, bad controllability with non skilled personal)
=> According to the ALARP chart you are “deeply red” here by means, that the person who implements that has the responsibility to implement safety measures to reduce the probability if the catastrophic risk can’t be further reduces.
Now I can give you a simple introduction how this can be achieved:
Power Plugs have according to my understanding of the zigbee spec a feature that is called “on_with_timed_off”. If any automation switches this mains plug to “normal” infinite on, then this command is superseeded/replaced by my ZHA by this “on_with_timed_off” by sending a cluster command to the switch (sub optimal workaround). Then it reads back the on_time attribute which holds the countdown value and if it is not counting down it shuts of the switch.
If the countdown is running, the IR heating panel is switched of after a certain duty cycle.
Ideally this duty cycle would be as short as the required Fault Tolerant Time of 5s according the IEC62368 specification but this will be a future project if we improve HA’s safety in this project.
There are several safety rules that are to respect here:
a) The so called safety timer is a “cold standby” feature and must never be part of the normal function.
b) Every safety measure has to be testet, again and again by reuse, simplification and modularization.
This means, that if the switch is turned of before timeout everything is good. If the switch is turned of by the safety timeout it is a major fault, has to be a protocolled safety issue and e.g. turns of a soft fuse.

Status of my personal safety timer project:
Safety Status:

  1. I was able to implement the safety timer.
  2. I require HACS attr_read for this which violates my security and privacy requirements
  3. I’m not able to detect the safety violation.
  4. ZHA has no entity to provide on_with_timed_off
  5. Only 2 of 7 switches have properly implemented the zigbee spec to support on_with_timed_off. Result ==> Acceptable risk reduction for some use cases / Not sufficient for all of my use cases.

What I would wish from or suggest for this discussion:
Please be strictly clear if you talk about safety, security, robustness, reliability, functional safety or privacy. They are all different topics with different methods to engineer and pls. be also aware that e.g. in german and maybe in other languages we have only on word “Sicherheit” that is the same word for safety and security:-(

Suggestions to proceed:
I would suggest to split this discussion in the above mentioned ropics under a newly create a lighthouse project.

  1. focus on requirements, configuration management and process engineering to achieve minimum IEC62368 safety requirements and publish and establish a certain risk awareness in the HA community. Invite and join the HA community and the Openwrt Community to participate in this joint venture project.
  2. focus on simplification on base of what is possible as a minimum consens (e.g. hardened openwrt platform on base of available and performant router HW and using methods of dns encryption and anonymization for privacy)
  3. Establish a common understanding and consense about safety, risk analysis, and risk mitigation processes and methods on base of simple pilot projects that can be reused for the community out of the box and independent of the use of a “hardened ZHA” or in whatever they want to use.
  4. Implement prioritized safety goals into the base ZHA-System without the need of HACS and for use in live “production” using the “hardened ZHA”.
  5. Get involved in Zigbee homologation processes, make sure, that safety goals and measures fulfil the 62368 and find into TÜV/GS Certifications, CE, UL and similar certification testing processes to get really approved for these safety applications.

Finally I think we surely do not want to evangelize the HA community because talking about these topics will annoy about 95% of the users. But if they can use it very simple, e.g. by importing blueprints they will do that and help to get a very broadband testing base for even light weight criticality use cases and low cost devices. Its everyonces freedom and responsibilty how much to invest for his own safety, security and privacy concerns.
Can someone agree to some of the above suggested ideas and thank you very much for your contentious discussions to keeping this alive!

14

This actually may be a good method to proceed. Does this already exist is some fashion?

But how to do this in fashion where data not leak or centralized? If every HA user was lighthouse you’d be able to parse a list of HA users. If hosted and controlled by nabu there’s still that middleman controlling not decentralized.

Is this wrong or off topic?

15

I’m glad to see this discussion, & expect I’ll be participating in more of it. Meanwhile, I want to insert a quick note re safety, esp. around the example issue of “turn-off-heating” never occurring. That and similar things are a real concern.

I like the suggestion of incorporating turn_on_with_timed_off , if it’s available.

Another suggestion I’d like to make, would be building automations that use the “retry” tool available from HACS. So you could for example turn on a heater, and using “retry” with turn-off, you could have better assurance that if the turn-off command got missed, the system would notice that and try again (repeatedly if necessary). Basically, check for feedback that your commands get executed.

Of course, that doesn’t cover anywhere near all the possibilities that can occur, but could provide at least some help in “hardening” the robustness of operation.

I imagine there’s a reason why industrial-quality building automation costs a wee bit more than HA.

16

Hey guys, thanks a lot for your feedback!
For a lighthouse project I’d suggest a following name (as bas for discussions) to give it all a roof where beneath all these topics find a system viewpoint and organizational level to manage this project, I’d suggest to call it “SPHARE”, “SSPHARE” or “ZPHARE”. Sphäre ist the translation for sphere and feels like a dome for a private protected shelter with no corners.
I find the following relations between the characters and our project, likewise:
S/SS ~ Z = Safe/Secure ~ Zigbee = (Z)HA
P = Privacy or Protected
HA = Home Assistant / Automation ~ Hardened
RE = Rugged / Robust / Realtime / Recreational / Relax
Environment
As the short logo for this lighthouse project i woul suggest something like e-g-(HA) that encloses HA into a protection sphere or shelter.
Like mentioned above just all an idea for dicussions?

17

Thank you for your support! Yes the SSPHA part is concept wise existing here at my home where I invested around 10 years of my holidays and making two types of mains plugs somehow safer to be a suitable platform for my electric heating, Before talking about data leak I need to mention, that safety and complexity and robustness are competing edges and targets of the safety triangle. And by the way, reliability is the fourth edge of a triangular pyramid. E.g. (spoiler warning) If you have a perfect, robust car you do not need any warning or hints for service. If you have a 100% safe car, all warning lights are on and you’re standing on a parking area. But this is not what cars are designed for. In a use case with “Safety First” goal we’d need the most simple but today already possible complexity. Otherwise we would never be able to create a “safety” lighthouse project which deserve the real double “SS” in the name. Please note “safety” here I only use as a qualification approval for a home automation system, that will highly improbably burn your house and with an e.g. universally accepted system target failure rate of 100 FIT and a diagnostic coverage of e.g. 96% to avoid most catastrophic risks. But this example estimation has to be recalculated individually and use case dependent on conservative estimations e.g. that a heating is maybe only actively heating 5% of a whole year and thus could allow to reduce the diagnostic coverage down to 70% which make things lots easier. The big challenge here will be to reduce the residual failure rate of a suitable quadcore A53 router down to below 100FIT, by means: The Openwrt ecosystem has to diagnose a factor 1/70 of own critical failures before HA even can detects one real e.g. “heating defect”.
What I wanted to explain here is, that I’d urgently suggest to start e.g. discarding any WIFI system to be controlled by HA and I’m aware that I earn a shitstorm for it? Why? Wifi is exploding the complexity of getting sensors secure and hardened. Accordingly this complexity would disqualify HA from being safety approved ot this lighthouse project will not even reach a 1.0 version and fulfills least requirements for !!every!! letter of the SSPHARE lighthouse project.

In simply words I’d suggest to start with !Z!HA and avoid any WIFI sensor, TV or similar WIFI based control, use Zigbee only and even maybe need to rule zigbee2mqtt because it needs an extra container and thus can’t be included in an openwrt ecosystem with suitable and hardened router performance. Not even using a Raspi as ZHA host I would take into account, because it more than doubles the system failure rate by adding another quadcore A53 with 2-3 billion transistors and a second fault intolerant failure rate.
Put everything on one single, actual quadcore A53 router that is supported by openwrt, search for one, that integrates an SDcard slot at a cold place in the enclosure and has at least on extra usb2.0 or better USB-A port and we will have (in my mind) the pole position to start.

18

While I appreciate the enthusiasm. Is it not better in it’s own thread- not hijacking Dr. He’s thread please? (can you start your own and continue there?) I’ve been reading the program Dr Hes request is based on and these are different things…

19

No problem, I never wanted to hijack anyone’s thread, but please help us to understand the differences and please clarify the intend of Dr. He’s program, ok?

20

all the sspa stuff. I’ll ask what I can share. It’s based on a federal government program in the US. Note I didn’t say don’t. Just t let’s keep them separate.