Thanks! I’m currently looking at deploying that to use instead of the Home Assistant Alexa Smart Home Skill.
The Matterbridge matter.js plugin manager as an Add-on for HA is now Home-Assistant-Matter-Hub.
First issue I found with matterbridge: HA Scripts are exposed as device type Plug
with option to change to Light
. In the Skill, scripts are Scenes…
That sounds indeed like very reasonable, useful changes.
Would you be willing to share them with us, please?
Do you have any experience with changing a tunnel in the Cloudflare console that was originally created by a “local”, fully-automatic setup as per the instructions for the “Cloudflared” add-on? I don’t know what happens if/when I do so… Would the container simply re-create the original tunnel config?
Would be nice to be able to customize the ingress config to “harden” it (by some WAF rules, by tightening the TLS config, etc.).
Would be great if you could document this nicely… Both for yourself and for us…
Documenting matterbridge in a HOWTO post just like this one would indeed be very useful! I haven’t spent much time messing around with it myself as 1) Google Home functions with the process in the OP and 2) I don’t use Google Home much anyway as Homepod Minis are much easier, less unprivate (if that makes sense), and local.
I have 4 Cloudflare WAF rules:
- Block: (not ip.geoip.country in {“CA” “US” “MX”})
- Skip: (http.host in {"vaultwarden.<my_domain> and http.user_agent contains “(Android 14; SDK 34; Model SM-S9080)”)
- Skip: (http.host eq “alexa.<my_domain>” and ip.geoip.asnum in {852 14618 16509} and http.request.method in {“POST” “GET”} and http.request.uri.path in {“/api/alexa/smart_home” “/api/events/alexa_actionable_notification” “/api/states/input_text.alexa_actionable_notification” “/auth/token”}) or (http.host eq “ha.<my_domain>”)
- Block: (not cf.tls_client_auth.cert_verified)
Once I am fully committed to matterbridge
, I can remove "/api/alexa/smart_home"
from the http.request.uri.path in {}
in rule #3.
For matterbridge, I installed GitHub - t0bst4r/home-assistant-matter-hub: Publish your Home-Assistant Instance using Matter. and configured a bridge which for now I named Test Bridge. The add-on’s name in the sidebar is Matter Hub:
There are several ways of specifying entities to include. I chose to use “label” and have attached a label to the entities I want exposed to Alexa. I’ve also included the platform “reolink” to expose all of its entitties:
Final result:
I really don’t use Alexa very often for controlling specific HA entities other than scripts, two of which I use once a day every day: good_morning
and good_night
.
No idea. I’m using this config in the Cloudflared Add-on:
external_hostname: <redacted>
additional_hosts:
- hostname: vaultwarden.<redacted>
service: http://192.168.1.104:<redacted>
tunnel_name: homeassistant
tunnel_token: >-
eyJhIjoiNzZkYT<redacted>1NeCJ9
log_level: info
nginx_proxy_manager: false
run_parameters:
- "--retries=5"
am hoping someone could point out what im doing wrong…
im using the Cloudflared add on with Home Assistant and this was working fine till i messed up some settings and i ended up uninstalling and and setting it up again. the tunnel is up but i can no longer access the url when im home and on Wifi once my mobile is out of my home wifi its displaying correctly.
Many thanks for documenting this.
I’m trying to understand how exactly this integration via the Matter bridge is working. I couldn’t even find this info in the GitHub documentation for it.
The main point that makes me want to switch to this solution is that obviously you don’t have to expose your HA instance to the internet – which is great for security.
But how does Alexa then talk to your instance?
Is it that one of your local Alexa devices (which is in the same local network or at least one of several local networks) actually talks to the Matter bridge? So when you talk to any of your Alexas to say switch on a specific light, the Alexa backend would instruct one of the Alexa devices to send commands to the bridge to change the status of your smart home device?
Basically, yes. My understanding of it is…With the matter hub, the included devices are made available for alexa to discover as matter connected devices but only one echo ends up being the connection point for any one device, much like how hue, bluetooth or zigbee connected devices are made available to alexa; bluetooth are of course preconnected by the user to a selected echo device; zigbee devices would only be connected via an echo with a zigbee hub. Alexa knows which echo device is the controller for that device. When Alexa is commanded to control a device it informs the controlling echo which then informs the local matter bridge which then communicates the state change to HA. For echo connected zigbee devices, the device is controlled by the echo zigbee hub and if alexa_media is installed, those zigbee devices appear back in HA where the state change is updated on the next poll by alexa_media.
Thanks again for your response, but you got me a bit confused now… (Maybe it is because I’m only using HA since two weeks or something, or maybe your use case is different than mine?)
Why are you mentioning (IIUC) Zigbee (ZB) devices which are connected thru an Echo device that has a ZB hub built into it?
I thought the situation is:
- local in-house installation of Home Assistant (HA)
- ZB hub connected “directly” to HA (by whatever means, be it via USB locally to the HA machine, or be it via TCP in the case of a ZB gateway like the SLZB-06M I’m using)
- ZB devices attached to the above ZB hub
- HA “exposes” the devices connected to itself by the integrated Matter hub
- one (dedicated, specific?) Echo device (that doesn’t need to be ZB-capable, even a plain old “Dot 1” would do) that sits in the same LAN as the above HA-exposed Matter hub or at least can connect to it thru a router (in cases where you may have different VLANs) “connects” the Matter bridge to the Alexa network/backend, so that the Echo device could than act as the “local” arm (as an “agent”) of Alexa to query the Matter bridge and send commands to it
Is that what you are also talking about?
Sorry if I confused you by mentioning echo zigbee hub connected devices but I was simply referring to them along with bluetooth and hue as examples.
Stupid question…what is the repository url to add this? I keep getting an error message that it’s not a valid repository.
I’ve had trouble getting my Alexa Skill connect to my HA server through a CF Tunnel and I just wanted to share what I found to be the most convenient solution using Service Authentication
. Sorry if this solution is common knowledge but I couldn’t find a solution working considering that my HA runs in a docker container and I cannot use Add-Ons (the CF Tunnel also runs in a separate container).
Steps
These steps assume that you already have a tunnel, that you’ve made the required changes to your HA’s configuration.yaml
as per the official documentation and that you’ve added your trusted_proxies
if needed (in my case the IP of the docker bridge).
Create service token
- Create a new service token under
Zero Trust -> Access -> Service auth
. Make sure to copy the client id and client secret.
Add token credentials to your lambda function
- Add both client id and client secret to the environment variables of your HA Lambda function, along with your HA token and
BASE_URL
, as the docs explain. - In your lambda function, modify the Python code to read the credentials from the environment variables and send them in the request headers to have the request authenticated and be able to pass through the CF Tunnel.
I’ve forked the gist in the documentation and added the CF credentials here, in case anyone wants a c&p solution. If you use that gist, make sure to save the CF credentials as CF_ACCESS_CLIENT_ID
and CF_ACCESS_CLIENT_SECRET
.
Allow requests with service token
- Once you have the service token created, simply create your CF application for Home Assistant under
Access -> Applications
and add a policy withAction: Service Auth
andInclude
rule withSelector: Service Token
. When you click onValue
the dropdown menu will show you the token you just created. Select it and save.
And with that your Alexa Skill should be able to access your HA instance.
To quickly test if your tunnel accepts authenticated requests and your HA can be reached, you can use the following curl
command (replace with your domain and credentials:
curl -X POST https://<YOUR_DOMAIN>/api/alexa/smart_home \
-H "Authorization: Bearer <LONG_LIVED_ACCESS_TOKEN>" \
-H "CF-Access-Client-Id: <CF_ACCESS_CLIENT_ID>" \
-H "CF-Access-Client-Secret: <CF_ACCESS_CLIENT_SECRET>" \
-H "Content-Type: application/json" \
-d '{
"directive": {
"header": {
"namespace": "Alexa.Discovery",
"name": "Discover",
"payloadVersion": "3"
},
"payload": {
"scope": {
"type": "BearerToken",
"token": "<LONG_LIVED_ACCESS_TOKEN>"
}
}
}
}'
Regards,
I use cloudflare tunnel to Home Assistant with Google assistant and I use Home assistant app on phone.
Can I add some aditional protection to tunnel that wont block my phone app or Google assistant?
Or can I in some way restrict Home assistant login to Home assistant users?
Hi
I used a HACS auto create tunnel for cloudflared put in the relevant information and connected the tunnel to my home assistant serever. I also blocked certain countries in the WAF to give extra protection. The remote access works perfectly and so does alexa actionable notifications. The only issue i have is that when i am outside of the house my home assistant cloudflare addon refuses access to google push actionable notification replies to allow an automation to set alarm for example. It is also temperamental if i use persistent connection in the companion app and also severely drains my battery.
Any idea how to allow google push notification FCM replies to be allowed in to my home assistant server instance?
Many thanks
Dave
I’ve been thinking about this too. I think you run the Lets Encrypt add-in to generate certificates for your homeassistant (e.g. host.domain.net ha.you.org etc.). That will make a certificate available for HomeAssistant and then you can use https://host.domain.net:8123 when you configure the cloudflare tunnel
Can someone confirm that this does NOT bypass the “Bot Fight Mode” when enabled on the free Cloudflare subscription? (dash.cloudflare.com->go to your domain->security->bot->toggle the first one “Bot Fight Mode” )
If I turn it off, it works as you said, but if I turn it on, all requests are blocked before applying the Zero Trust configuration rules, groups, etc.
It’s a relatively new feature ().
Do you agree?