So, under the hood, we rely on current mode to find out actual mode of alarm station but it is not arriving so I fell back to guard mode. Happy to see that it is working for you and let’s see what will be broken
1 Like
Good news and bad news. You’re correct, status are working for all devices, but changing guard modes are not working on my Eufycam Solo device, I’ve got a workaround for now. Thank you anyways!
was it working before? 7.0.0 or 7.0.1?
I know this is a stupid question, but how do I send the last event as a notification to my phone now? I originally had it as an attachment in Node Red
…
“image”: “/api/camera_proxy/camera.zvonek”,
…
but now it’s Event Image in my case: image.zvonek_event_image
and I don’t know how to add it as an attachment image
No, it is not a stupid question, actually it is a miss from my side, i haven’t checked the support level for image entity. Let me think about it
After further tests, I see that the push notification is received quite fast, so automation trigger timing should not be an issue. However, the next steps take quite a long time, so that’s the reason the image stored in the selected folder is delayed (I will take into account the relevant part steps only; will disregard the Telegram part, as it has nothing to do with the eufy workflow):
You can see that the clip event is happening at :03", although the clip timestamp for the first keyframe is at :02". Anyway, for the purpose of the test, let us take the :03" timestamp as the starting poing
The above screenshot displays the automation flow which happened at the time that motion clip was created in the previous eufy app screenshot. You can see that the automation was triggered 2" later, which is actually the same timestamp that the person_detected sensor state change was registered:
- Clip created: 00"
- Push notification registered and automation triggering: +02"
- RTSP streaming start: +04"
- Service call to generate image: +03"
- Take snapshot (actual image file created): +02"
That’s 11" from the time the motion happened to the snapshot that is being taken. For security purposes, this is not useful.
I also tried to use camera.record service instead of camera.snapshot, because camera.record has the ability to look back on HLS streams. However, it seems it is not taking into account the lookback time and mp4 clip is being created with a similar delay, although the camera entity is HLS:
Any suggestion to get either a photo or a clip with a lower delay will be much appreciated. If this is not possible, it would be great to know whether it is possible to get the clips stored in the HUB, the ones that you can watch from the eufy app events tab. Actually, that would be the perfect approach. I have already opened a question issue in the addon GitHub for this specific topic, but it would be great if anyone else has any feedback on this which may help. Thanks!
Do you need camera snapshot now given that push notification content is accessible in a separate entity?
Btw, thanks for detailed write up.
1 Like
The new push notification content (I guess you mean the new Event Image entity) is not reliable. The entity update timestamp is updated sometimes only, but the image/thumbnail never is, at least in the integration I have. Actually, I am still doing tests with the standard camera entity due to that, which it still works (with the help of an automation which includes a Eufy Security: Start Live Stream over RTSP service call).
As you can see in the following screeshot, the entity change timestamp is from earlier today, despite I have been doing tests until a few minutes ago (local time now is 13:10). In addition, the photo is dated yesterday at about 08:40, before I updated to the latest release:
Thank you! Happy to provide whatever is necessary to move forward on this issue. 
Just some further feedback after performing some tests with my Synology NAS. Added a camera as RTSP in Synology’s Surveillance Station. Surveillance Station records the feed at the same moment that RTSP stream is enabled. No delay at all. Both the eufy app event history and Synology clip files has the same starting keyframe/timestamp. I will try to create a workflow for fetching such clips into HASS so I can manage them as needed. However, this will require to purchase two Surveillance Station licenses. My NAS has 2 free licenses included, but I have 4 eufy cams.
Having said that, as far as I understand and according to this test, it should be possible to replicate this with the addon/integration, for not being needed to include Synology as a workflow player, shouldn’t be? I’d rather to have in the workflow as less devices as possible. Workflow would be simpler and there would be less failure points.
You can do the same with frigate. No license required.
Can you explain the breaking change a little bit more? Currently I don’t get it.
The camera entity is now not getting event updates anymore and will show the last manually streamed picture forever? Hm, don’t know if this is what many users are using.
And the event picture entity is getting the pictures I had before and/or I have in the eufy app? O.k. This is what I used and want to see and so we have to rework the conditional cards to have what we had before: last event from image entity and the stream from camera.
I can live with all this, but where is the adventage or need?
And FYI: the image entity is on the one hand getting the last event. But as entity state the time stanp from every action of the cam, so manual stream timestamp as well. Somehow confusing.
Some people were interested to keep latest snapshot from stream and some not. Separating them should fulfill both needs.
This is a breaking change for your automations and dashboards, you need to rework them. On the other hand, i want to change image entity to camera entity because it allows easier notifications.
I am open to suggestions.
Good idea. Will try Frigate to check whether streams start at the same keyframe. If so, it should work for the purpose. In addition, this will help to keep all the workflow in the same machine, so there will not be two points of potentail failure. Thanks!
Question, I get the same still image when my doorbell rings. I never get the actual image att. It just stays/says idle. Is there anyway to get the actual image of the person ringing the doorbell.
1 Like
Update*
I restarted the rtsp and it started streaming but later it went back idle. I looked at the logs and I found this:
anyway to get it back?
Update
I figured out the live stream as it was P2P for the live stream.
Is there a way to use the “person name” as a condition if it is a person i have set to be known. so it wont notify me if it is my kids as example
alias: Doorbell Motion Activated
description: ""
trigger:
- type: motion
platform: device
device_id: f195696242e772292132a82323742c26
entity_id: 144af4dd52626943218e22a3fc5a0f4f
domain: binary_sensor
- type: motion
platform: device
device_id: f195696242e772292132a82323742c26
entity_id: f3b63e557a11089f4ff1be6614c72512
domain: binary_sensor
condition:
- condition: state
entity_id: sensor.doorbell_person_name
state: unknown
action:
- if:
- condition: sun
after: sunset
then:
- service: light.turn_on
data: {}
target:
entity_id: light.front_porch_light
- service: button.press
data: {}
target:
entity_id: button.doorbell_start_p2p_stream
- service: camera.snapshot
data:
filename: /config/www/frontdoor.jpg
target:
entity_id: camera.doorbell
- service: notify.fire_tv_mb
data:
message: There is someone at the door!
title: Front Door
data:
duration: 25
fontsize: large
color: green
position: bottom-right
file:
path: /config/www/frontdoor.jpg
- service: media_player.play_media
data:
media_content_id: /local/frontdoor.jpg
media_content_type: image/jpeg
target:
entity_id: media_player.google_nest
- service: notify.mobile_app_homeking
data:
message: There is someone at the door
title: "Doorbell "
data:
image: /local/frontdoor.jpg
entity_id: camera.doorbell
actions:
- action: URI
title: View Doorbell
uri: /mobile-app/cameras
- if:
- condition: zone
entity_id: person.precioussakura
zone: zone.home
then:
- service: notify.mobile_app_precioussakura_2
data:
message: There is someone at the door
title: "Doorbell "
data:
image: /local/frontdoor.jpg
entity_id: camera.doorbell
actions:
- action: URI
title: View Doorbell
uri: /mobile-app/cameras
mode: restart
1 Like
As said. I can live with everything and appreciate all your effort.
But I didn’t read such latest stream/snapshot that often in the past (on this thread since the beginning) and wonder, if it wouldn’t be a better idea to introduce a new picture entity of latest stream/snapshot and leave the camera as is (latest event). => No breaking change and it would work like everyone is used to have it in the eufy app as well.
1 Like
You are right from your own experience but people without correctly functioning event notifications, they used to rely on camera based snapshot capturing which was removed earlier hoping that event notifications would work for all finally.
Again, let’s hear different voices and happy to introduce further changes
I just tested with Frigate. It “works”. However, the generated clip does not start at the moment the motion is actually starting, something that Synology Surveillance Station does. Frigate is not capturing the first 7-8" of the stream, something that makes this option useless. Perhaps Frigate monitors RTSP streams recovery every n seconds. Any advise, please? Have you tried this with Eufy battery cameras as well, which are not RTSP’ing until motion is detected? Any frigate.yml parameter I could missing for the magic to happen?
I would be happy to just stick to the Synology workflow. However, a problem I have with that is that folder_watcher is not triggering upon files creation, unless the files are being created in the HASS side of the remote folder. I am asking about this specific topic here.
This has broken my automations, phone notifications and dashboard as you had suggested. Speaking of which: GitHub - fuatakgun/eufy_security: Home Assistant integration to manage Eufy Security devices as cameras, home base stations, doorbells, motion and contact sensors. ← this example conditional card probably needs updating.
For the time being I am still using v6.3.3 before the breaking changes as it seems there may still be some changes ahead. To me, unless these changes are solving a problem for a majority, I would leave frequent image updates occurring on the camera entity and have those others looking for different functionality to use the new image entity.