Proxies, Interactors, Observers... Just an Idea

[Baael]

🪤 Context

This is a very interesting project!
I came across this while searching for information on entity proxies and encountered some challenges. The term "proxy" doesn’t seem to fully align with their intended function—names like "observer" or "interactor" might better describe their role.

What I expected from a proxy was something that allows duplicating an entity, utilizing its methods, and automatically forwarding changes to the original. Developing such a solution could greatly simplify capturing user-driven events in contrast to automation-triggered ones.

For instance, having methods like:

• onUpdate – triggered when the instance state changes,
• onInput – triggered when the instance is directly modified by user, such as via a dashboard,

would enable the automatic creation of objects like:
light.office and light.office_proxy.

The light.office_proxy object could act as a tool for analysis and adaptation, aiding in machine learning of user behaviors. This would make it easier to capture user preferences in various environmental contexts (e.g., weather station data, time of day, season, or activity levels at home).

📬 Caveats

Currently, I’m relying on an outdated and barely functional script to achieve similar functionality. While it works to some extent, it lacks flexibility and scalability for more complex scenarios. Integrating a dedicated solution could vastly improve the ability to adapt automations based on user interactions.

🩻 Additional details

Such a system would bridge the gap between user-driven changes and automation, allowing smoother transitions and more personalized behavior. For example, it could adapt lighting preferences dynamically based on user interaction patterns and environmental conditions, reducing the need for manual adjustments.

[zoe-codez]

I'm not 100% following, but I believe what you're looking for isn't directly possible via a library like this one. The hass library only has access to what comes over the socket / is available via the rest api, don't have full control over the Python internals.

Maybe you can share details about how your script works if I am wrong?

---

The synapse library builds on top of this, pairing with a custom integration to create virtual entities which allow you to have much more control over the interactions.

You would be able to create a second entity to match the setup of another real world device. It will allow you to tap directly into the service calls being issued to that entity, and implement your own logic for how it responds to that. That could include forwarding that service call to another real world device, kicking off background logic, and mirroring state / attributes from that.

It should be possible to build on top of that to create a general purpose library to set up the paired entity interactions you're looking for

---

Synapse mostly supports helper entities right now (inputs, sensors, switches, etc), but support for virtual lights / climate / etc entities are coming later this year as time (or other people's contributions) permits. That'll likely be after I get the integration directly into the Home Assistant core tho.

WIP pr on that