huh, the image started popping up in my lovelace… not sure what I did, but it works!
1 Like
Works for me too. But I dont get a Live Picture but the Picture of last Movement - Detection.
Very useful !
Maybe I’m not writing in the topic, but there is still an option for how to integrate the eufi camera into the home assistant. The camera can be integrated into the home assistant via Agent DVR. The video stream goes without delays, almost like WebRTC, you can also connect the agent dvr to deepstack and to MQTT. You can turn on the motion detector in agent dvr only for people and ignore animals, and the face recognition script will run based on the movement. Essentially having a set as an integration ioBroker.eufy-security + agent dvr + deepstack + browser_mod, I got almost full control over the camera, a good video stream + recognition and automatic opening of the camera window if someone rings the doorbell or opens the door
2 Likes
Thanks for the idea, i will give it a try. Have a question though; if i can directly connect agent dvr with eufy cameras and use agent dvr Integration with home assistant, what would be the need for iobroker?
iobroker is needed to control the camera.
Enable / disable the camera
Turn on / off the LED
Enable / disable RTSP
Enable / disable night vision
Enable / disable motion response
Enable / disable sound response
Enable / disable animal response
Restart the camera
Made a collapsible panel using custom:fold-entity-row
To understand what topics there are for getting information from the camera + topics for managing
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.
1 Like
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 API -
eufy-security-ws: the two-way websocket that allows non-JS/TS clients to interact witheufy-security-client -
eufy-security-ws-python: the Python library that manages data to/fromeufy-security-wsin a generic manner - HASS Integration (TBD): the Home Assistant integration that will utilize
eufy-security-ws-pythonand allow the user to “do things” with Eufy Security - HASS Add-On (TBD): a Home Assistant OS add-on that allows for easy installation of
eufy-security-ws
This approach will allow users of Home Assistant Core/Container and users of Home Assistant OS to run this integration:
- Home Assistant Core/Container users will need to run their own instance of
eufy-security-ws(easily done, since the project already provides a Docker image). - Home Assistant OS users can install the HASS add-on in order to achieve the same thing.
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”:
- Finish tests for
eufy-security-ws-python(not too far off; want to complete this so its behind me before anything else) - Write a base Home Assistant integration:
- UI Configuration
- Two-way communication with
eufy-security-ws - A basic piece of functionality to start (I’m thinking a sensor that shows the current mode and a service to change the mode)
- Localization
- Get up to speed on writing HASS OS add-ons
- Write v1 of the HASS OS add-on
- Publish official PRs for everything
20 Likes
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;
- phase 1 - release integration, add on is not required in this phase
- phase 2 - release add on, which will ease overall installation by end user
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.
4 Likes
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.
6 Likes
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.
3 Likes
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.
1 Like
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?
1 Like