Reverse connection (make the secondary HA-instances connect to the primary)

[sveip]

I read through the original PR for this component, where balloob made a suggestion to reverse the logic/flow so that the secondary instances connects to the primary.

I have a use-case where this is needed (secondary instances are behind Carrier grade NAT, so not accessible from the outside.

Any suggestions to how this can me done, either with balloob's suggestion or some other reverse-method would be highly appreciated.

[vanarebane]

I second that need. I have master with proper DDNS address and SSL certificate and it's much harder to make the same setup for slave that is in another network. Also to deploy multiple slaves is simpler, just define one master for all.

[sveip]

I'm willing to help on the dev. if I can get some pointers what to start on, as this seems like a nice feature, and also a necessity to get it into hass eventually.

tor. 4. mar. 2021 kl. 10:37 skrev vanarebane [email protected]:

I second that need. I have master with proper DDNS address and SSL certificate and it's much harder to make the same setup for slave that is in another network. Also to deploy multiple slaves is simpler, just define one master for all.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/custom-components/remote_homeassistant/issues/104#issuecomment-790475399, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLR4L554UBO7YBYI2GKBELTB5IHDANCNFSM4WKPPU2Q .

[sveip]

Since @postlund is the maintainer now, maybe we should check with him if he agrees that this is the way to go? Here is a link to the discussion mentioned in the initial post where balloob says this is a requirement to get it merged to hass: https://github.com/home-assistant/core/pull/13876#issuecomment-390436895

[postlund]

It's fine by me if you want to add bi-directional support 👍 I guess it shouldn't be that hard if done properly. My suggestion is to add a config option used to configure how things propagate, I.e. from main to remote, from remote to main or fully bi-directional. We should also change the nomenclature and call it main, rather than master IMHO.

Don't care too much about the initial discussions about this component. We do a lot of shady stuff (mainly in the config flow) that would never make it in core anyways. So let's just do what we need to do.

[sveip]

Sounds good to me. Do you have any poinster where to start with adding it?

tor. 4. mar. 2021 kl. 12:40 skrev Pierre Ståhl [email protected]:

It's fine by me if you want to add bi-directional support 👍 I guess it shouldn't be that hard if done properly. My suggestion is to add a config option used to configure how things propagate, I.e. from main to remote, from remote to main or fully bi-directional. We should also change the nomenclature and call it main, rather than master IMHO.

Don't care too much about the initial discussions about this component. We do a lot of shady stuff (mainly in the config flow) that would never make it in core anyways. So let's just do what we need to do.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/custom-components/remote_homeassistant/issues/104#issuecomment-790552136, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLR4LYGVQCMDDLTPLCHYO3TB5WRHANCNFSM4WKPPU2Q .

[lukas-hetzenecker]

Totally agree, bi-directional would definitely be a support addition.

Just not sure if it really "shouldn't be that hard" ;-) - I originally used this "pull from main" approach, as with the Websocket API it is only possible to fetch states/data, but you cannot set states via websocket (or, at least, it was not possible back then). So I think this would also require changes to the Home-Assistant Core itself?

So I think with going the "push to main" way, there would probably be not much shared code. If that's the case, maybe the development should happen in a new component. But let's decide about that, when we've found a way to actually implement it :)

[jaym25]

I am using it bi-bidirectionally with SSL, where the endpoints are on separate networks (across town), by just installing it and configuring the component on both ends... if that helps. p.s. I do have DDNS or static IP, and port forwarding set up on both ends.

[postlund]

Totally agree, bi-directional would definitely be a support addition.

Just not sure if it really "shouldn't be that hard" ;-) - I originally used this "pull from main" approach, as with the Websocket API it is only possible to fetch states/data, but you cannot set states via websocket (or, at least, it was not possible back then). So I think this would also require changes to the Home-Assistant Core itself?

So I think with going the "push to main" way, there would probably be not much shared code. If that's the case, maybe the development should happen in a new component. But let's decide about that, when we've found a way to actually implement it :)

Hmm, you are right, it's a bit tricky. We most likely would require the remote instance to have this component installed as well. But if we can live with that, the logic should be more or less what we already have. Question is however how we set up the integration on the other end once a connection is established. Preferably it should not be necessary to configure the remote server in any way (except for installing the component).

One thought I have... Let's say that we extract all the state related code from RemoteConnection into its own class. Let's call it BananMonkey until I come with something better. BananMonkey maintains a list of websocket connections. A connection can be added or removed (e.g. when disconnecting) dynamically. When a connection is added, it calls get_states and subscribe to events (e.g. forwards state changes and service calls). When using BananaMonkey with current main-remote concept, we just connect to the remote instance and add the connection to a newly created instance of BananaMonkey. So far this is just refactoring.

Beware, the next part is not for the faint of heart. Written under mild influence.

Now... I want to create an instance of BananaMonkey as part of the component, that is not bound to any particular service. If you have this integration installed, that instance shall be created. We then create our own websocket command that allows an incoming websocket connection to register with that instance. This basically means that the remote instance will get a websocket connection to the main instance added, thus reflecting the state of the main instance on the remote instance. Take huge breath and let that sink in.

One caveat here is that a component can not run arbitrary code as it will not load unless there's either a config entry or YAML that makes it load. So unless homeassistant_remote: is added or a server is added, we can't do this. A workaround is to make this an opt-in feature so that the user must perform this step to allow reverse connections like this (I find that to be fine). We can add a special alternative in the config flow that creates a config entry which does not connect to a server, but only set ups the local BananMonkey instance and add the websocket command.

I'm not sure if anyone understands what I have written, feel free to ask if you don't understand.

[jaym25]

So it would basically be an HA_remote_loopback_client that gets installed with homeassistant_remote and is only activated if a predefined config parameter is added? Would it be able to effectively recover from network and power interruptions?

[apedance]

Any progress on this?

[sveip]

Unfortunately not from my side, at least. I ended up with independent instances to minimize data usage on my remote location.

On Sat, Mar 18, 2023, 19:57 apedance @.***> wrote:

Any progress on this?

— Reply to this email directly, view it on GitHub https://github.com/custom-components/remote_homeassistant/issues/104#issuecomment-1474955669, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLR4L4LRNSBTCTANPVAECLW4YATNANCNFSM4WKPPU2Q . You are receiving this because you authored the thread.Message ID: @.***>