Multi-System Reactor

OK, I had some time in the past couple of weeks to look into this. Build 26284 now contains some changes that should smooth out configuration and use of reverse proxies. Let's see how it goes, and if I need to do more, we can work through that. There are a couple of new configuration keys to be used when a reverse proxy will provide access to Reactor, and a couple of existing keys have small (?) changes in behavior. The keys and behavior are summarized in the documentation for Access Control in the appropriate places, but to streamline the discussion and your efforts, I'll summarize them here. These configuration keys live in the reactor section of reactor.yaml. First is trusted_proxy — this tells Reactor the host address of the LAN side of the reverse proxy. This is the address Reactor first sees opening the UI or API connection. The value of this configuration key can be an IPv4 address (e.g. 192.168.0.10). It can also be an array of addresses. I recommend surrounding the address(es) with quotes just to avoid any problems. When Reactor sees a request come in from this address, it looks to see if the request follows the HTTP/1.1 protocol for reverse proxied requests. If so, Reactor knows to track both the request source address (the inside address of the proxy) and the client address (the IP address of the client using the proxy to access Reactor, which may be inside or outside of the LAN). If those two addresses are different, Reactor knows its a proxy request. Second is proxy_baseurl. This sets the URL to be used as baseurl when the request is proxied. If Reactor needs to redirect for the UI, it will use baseurl as the base of the redirect if the request is not a proxy request, and proxy_baseurl if it is proxied. Typically, users of reverse proxies will keep baseurl set to the internal (LAN) URL used to access Reactor (e.g. http://192.168.0.66:8111), but set the proxy_baseurl to the externally-resolvable URL for accessing Reactor from outside their network (e.g. https://example.duckdns.org:8554). Proxied requests are processed a little differently by allowed_ips and ACL IP matching. When a request is proxied, the IP address matched by allowed_ips is that of the actual client, not the proxy's inside (LAN) address. Therefore, if you use allowed_ips with trusted_proxy, you must list every external/public host address (or network address in CIDR form) that is allowed to access Reactor through the proxy. By default, the proxy is not trusted by allowed_ips. That can be very inconvenient when you are a road warrior (frequent traveler to many places unknown) and want/need to access Reactor from wherever you may be. To help with this, at the expense of some security, you can tell Reactor that the proxy is trusted and all requests from the proxy should bypass allowed_ips filtering. Do this by setting pass_all_proxy: true, but if you do this, you must make sure that the proxy itself provides any and all filtering/authentication/security you might need before allowing access to Reactor. The pass_all_proxy key works only to circumvent the allow_ips list; it does not apply to ACLs. Access control ACLs now have from_proxy to provide matching to requests coming from a specific proxy host (or network). The source_ip filter always looks at the client address. An analog for pass_all_proxy in ACLs could therefore be an ACL with from_proxy and allow: true (actual implementation depends on the full set of ACLs and their sequence). Proxy configuration does not change any behavior of user access control in Reactor (i.e. Reactor user login). It is highly recommended that user login be configured and used when a reverse proxy is in use, even if the proxy provides access control in front of Reactor. If you choose not to use user login, you may be leaving your Reactor system vulnerable to external access by accidental discovery (e.g. port scans). Using user login with strong passwords provides an additional, necessary layer of deterrance to illicit access. Reactor will warn you if you are configured for proxy access without enabling and using user login. The Reactor documentation recommends that you enable/use HTTPS when using user login/auth. You can get away without HTTPS if your access is exclusively on your home network (no external requests or reverse proxies), but it's a different matter when your login requests are going to be through public networks. Therefore, it is also highly recommended that you use HTTPS to access Reactor through your proxy. At the very least, your proxy should receive SSL/TLS-encrypted HTTP requests at its public/external interface. You can keep internal access to Reactor in plain, unencrypted HTTP (including requests from the proxy to Reactor) if you trust your internal network. And for clarity, in all above where I say "highly recommended" I mean required unless you want to invite trouble. To wrap up, a checklist: Set trusted_proxy to the inside host/interface address of your reverse proxy; Set proxy_baseurl to the externally-accessible URL used to reach Reactor through your reverse proxy; Enable and configure user authentication/login in Reactor if you haven't already; Make sure your proxy's public interface uses HTTPS (encrypted); HTTPS on the inside (between proxy and Reactor) is up to you. Ref: Access Control in Reactor documentation And a disclaimer: Opening up any system to the public Internet increases risk. Because the totality of your systems, tools, and needs are unique to you, only you can assess the risks of such access, and the correct and most secure way to provide it. Proceed at your own risk, and know that it is entirely at your own risk and that you accept that risk and its consequences in so doing. I am providing tools, not solutions. How you use these tools is up to you, and the consequences for not using any tool properly can be dire. If you don't know what you are doing in this area, don't do it. You've been warned.

Here we go. Sorry for the delay, crazy days at work: { "entity_id": "fan.kitchen_seashell_hood_ventilation_fan", "state": "off", "attributes": { "preset_modes": [], "percentage": 50, "percentage_step": 25, "preset_mode": "", "friendly_name": "Seashell Hood Ventilation Fan", "supported_features": 49 }, "last_changed": "2026-09-19T04:06:16.582977+00:00", "last_reported": "2026-09-19T04:06:16.582977+00:00", "last_updated": "2026-09-19T04:06:16.582977+00:00", "context": { "id": "01M2VXFV869XHBDKVKPFSSCC21", "parent_id": null, "user_id": null }, "source": { "domain": "esphome" } } Thanks.

done. I'll test, but your logic makes sense, of course. anyway, part of the problem with complex rules is that I have a huge system and sometimes it's very, very difficult for me to find the right rule after a while. what could help me is a way to see all the rules a device is used into (triggers, constraints, actions, variables), and an advanced search, maybe, one can dream

@toggledbits Trigger OR was the problem and not identical internal condition/group ID as I suspected. AND is the fix. With the old OR setup, the problem was that the trigger had already fired, registering as "true" for a different reason (Lux), minutes earlier. So the photo captured by the trigger was outdated. Thanks again for the push in the right direction!

This is now available in build 26242. The config has changed slightly, so review the final documentation for correct usage and examples.

A while ago I got rid of my Hubitat, so I'm no longer updating this thread

No backup? Restore from backup (recommended) is the best way, of course. Beyond that, recreating it should not be difficult, but there have been key changes since that original post. Some detail beyond "did not work" is necessary here. Show your work and tell us about your environment.

@Crille, thanks. I never noticed that box. Simple fix!

@vezinpi Thank you! That worked beautifully.

Thank you for the quick fix!

@toggledbits Hey toggle! Really appreciate the build. I was unable to get back to this until today. I went ahead and updated node as you suggested and it took care of the issue. I don’t have a ton of experience with Docker but maybe I should do a little research on what it would take to migrate. Thanks, everyone, for the quick responses. Sorry I disappeared for a few….

It's all good! Many, many, many has been the time where an extra pair of eyes helped me. That's why I'm thrilled to have my son working on this project with me now. I'm glad it was something easy (no patch and build needed). Onward!!!

@toggledbits TIL... thank you!

@toggledbits Damn you lol I'd just updated Brave a couple hours ago, then sat back lying in wait. I just now went to test it and it worked normally, I was logged out with the login screen visible. I thought "huh - musta been a Brave issue, well it's fixed now" - and then I saw both this post and the version change. Thank you, sir, as always!

Thanks for the inspiration!

@Talisker said in Upgrade advice - upgrade from aarch64 to ARM64 image: What is confusing me a little is that the exemplar docker compose .yaml 'volumes:' file structure is a bit different to my current .yaml file. Will this cause a problem? The change in the newer file will be significant later, but no need to worry about it today. Make as few changes as possible. The only change you need to make here is from latest-aarch64 to latest-arm64.

@wmarcolin FWIW Home Assistant and Alexa Media Player can give you what you (and so much more) in about an hour's set up. C