got it, overall, i was trying to avoid to setup a new layer of software as iobroker. today, i finally made up an integration between node-red and eufy-security-client web socket and I will work on a basic integration for home assistant.
Home Assistant Custom Integration will connect to eufy-security-client web socket and send commands and receive updates.
makes sense, thanks
hey @bachya , please let me know if i can help in. by the way, any specific reason to focus on HASS Add-on rather than custom integration? Not everyone is using OS based solution, which might be a limitation.
Wish to have a custom integration as well instead of an Add-on.
I’m not clear on your comparison of “HASS Add-on” and “custom integration” – let me lay out all of the pieces:
eufy-security-client: @bropat’s amazing library to communicate with the Eufy Security unofficial APIeufy-security-ws: the two-way websocket that allows non-JS/TS clients to interact with eufy-security-client
eufy-security-ws-python: the Python library that manages data to/from eufy-security-ws in a generic mannereufy-security-ws-python and allow the user to “do things” with Eufy Securityeufy-security-ws
This approach will allow users of Home Assistant Core/Container and users of Home Assistant OS to run this integration:
eufy-security-ws (easily done, since the project already provides a Docker image).Note that this is the same policy the Z-Wave JS integration employs: it gives an OS method and a Core/Container method.
Here is my current “roadmap”:
eufy-security-ws-python (not too far off; want to complete this so its behind me before anything else)eufy-security-ws
I see your point, Add On will run the eufy WS and integration will communicate with eufy ES, but they will not be tied to each other. As Core user, I will be able to enable eufy WS myself and set the integration independently. Great to hear that.
So, do you think it will be easy to manage the release if you go in phases like;
PS: thank you for your time and effort on this
I’m unsure at the moment. You are correct that these phases (as you define them) would allow for incremental releases; that said, this is the first time I’ve written an integration that requires a second piece of software to work. It may be the case that the Core team will require me to accommodate all users simultaneously…or it may be the case that if I document it well (e.g., “Home Assistant OS is not supported yet”), that’s good enough. As I get closer, I’ll have conversations with them and figure out the correct route forward.
My pleasure! I appreciate everyone’s patience given that work/life have taken the majority of my time lately; will keep this thead updated.
Nice work all, we have patience !
We know its coming, thats a good start !
Thumbs up!
To decide which phase to start with, its probably an idea to make that decision based on whats used most? core/container vs HA OS
Phase 2 depends on Phase 1 and Phase 1 can be delivered independently. @bachya had shared his roadmap earlier, so he will be starting on Phase 1 soon. Actually what he is doing is required for Phase 1 as home assistant requires external libraries to be used in integrations.
Phase 2 is about running eufy-security-ws, which is a node web socket server and integration (will be delivered on Phase 1) can communicate with this. On the other hand, you can setup node web socket yourself and just use integration without add on.
This is definitely an interesting idea. Based on today’s data, nearly 2/3 of users who have analytics enabled are using OS:
So, this would seem to indicate that OS (integration and add-on) needs to be the critical path. However, that doesn’t mean that non-OS users will be left out – I could see creating a PR for the integration, leaving it in Draft status until the add-on is completed, and that way, Core/Container users can install the PR as a custom component.
So, broad question that maybe someone can help me understand.
I run HA Supervised on a stock debian install right now. It seems the most flexible, I can use supervisor, I can use addons I can add individual docker containers either via HA addon or not.
What do i lose by going to HASSOS, cause i cant see much that i gain? I probably would lose the ability to add my own docker containers right (for example… IOBROKER)
This is a pretty good explanation: https://reddit.com/r/homeassistant/comments/kihapq/_/ggrn6v6/?context=1
From what I’ve gathered:
Home Assistant OS - available as a virtual machine image with Home Assistant preinstalled. Home Assistant itself as well as any add-ons you install will run as containers in the VM, but this all happens transparently and you don’t necessarily need to know about docker to use this method.
Home Assistant Container - Docker image of Home Assistant Core. You can’t install add-ons, but you can achieve similar functionality that add ons provide through manual set up and configuration.
Home Assistant Supervised - similar to Home Assistant OS, but you’re responsible managing the operating system and getting Home Assistant installed. While you have more control over the OS, running anything other than Debian 10 with only the required OS packages installed and only running Home Assistant will make your setup be considered “unsupported” except for help from the community forum.
As others have said, Home Assistant OS and Supervised have built in functionality for exporting your current configuration. You wouldn’t really need Docker Compose unless you were to run additional containers not installed via add-ons. I’m not 100% sure but I don’t think you can even install non-add-on containers with Home Assistant OS.
I found that Supervised gives the most flexibility, as long as your comfortable maintaining the OS and don’t care about being able to file a bug report without first bringing your setup to a fully compliant state. If you want a more out-of-the-box solution that essentially manages itself, Home Assistant OS seems to be the best way to get started.
And if you go with one of OS or Supervised and decide you want to try the other, my understanding is that you should be able to restore “snapshots” from OS to Supervised and vice versa.
thats helpful. yeah, ill stick with supervised. Im gonna proxmox it up so i can put a few other things on the NUC ha runs on, but ill have the proxmox vm be debian and keep ha as ive got it i think.
You are right about data, but delivering integration first will enable it for both OS and core users. If user can setup web socket node instance, it will be accessible to anyone over integration. As a second step, you can deliver add on to manage web socket itself. On the other hand, you are the one delivering this, totally up to you.
Do you have any estimation for delivery, maybe for each phase?
Indeed, integration serves all users.
Nope; totally dependent on when I can make the time away from work. Rest assured, it’s something I want, too, so there’s motivation. 
I finally got around to giving this a go, it’s awesome.
One thing though, does anyone have any ideas on how to stop battery drain on the 2K Battery Doorbell? As soon as I enabled MQTT on it the battery life went from lasting 90+ days to 7 days…
Any thoughts on paths to take to rectify/mitigate this?
Hi All. I am having an issue setting this up. I have installed Eufy Security in HACS but cannot find it in Configuration → Integrations.
I have tried:
I am running Home Assistant on a Pi 4 and am up to date with the latest version.
I have installed other integrations from HACS with no issues.
Any suggestions?
