Great work! ... and you might have some competition soon!

@t0bst4r Just stopping by to say:

Congrats for the splendid idea!
Co-incidentally - you are developing precisely the thing I am developing myself (and possibly commercializing or so were my earlier plans). Mine would most likely be called LastBridge (I've even reserved the domain).

In retrospective, I should have followed the other Matter implementations more closely in the past. Which I didn't. Oh well.

Also I might realize my post might be a tad demotivating, but I guess it is still better if both of us know the other entity does - in fact - exist.

Some details on my own in-progress solution (JFYI, might be interesting to you ... and given that I now realized my thing will not be the only game in town, we should probably talk and share experience):

Based on rs-matter (the in-development Rust Matter stack), and a few projects on top, like rs-matter-stack
The home-assistant-to-rs-matter adapter (I call it materialize) is not open source yet, but in light of your development, I might open it
There's also an MQTT-to-Matter adapter in materialize, but this is a second priority for me

A few funny facts (again JFYI - just sharing my progress, no hidden agenda really):

Besides running on any OS (of course), I'm able to to fit rs-matter + rs-matter-stack + materialize on a single ESP32 WROVER chip (the thing has 16MB flash and 2x4MB SPIRAM, the first 4MB directly addressable). Only "basic" entities work (= everything which is not media streaming), but that might be good enough! Media anyway needs a special treatment and Matter 1.3 went public without Camera support; maybe in 1.4 but then who knows?... Also see below, the last bullet point
I was/am eyeing the Esp32 because I planned to commercialize the thing and sell it for a few tens of bucks. Whether folks would like to buy it just to "get rid" of the "uncertified device" warning in Google Home / Homekit is of course THE question. In the past Google did have a much larger obstacle for uncertified devices - you were supposed to register a project in their Google Cloud. Apparently, they have lifted this requirement now, which makes the case for certification weaker (though more professional setups still might want it?). The thing is, certification inevitably means (a) signed "firmware", (b) custom hardware (?) - you can't just package it all in an add-on and push it inside HA... or am I missing something? Hence my adventures with the ESP32.
There is a separate, also currently-closed-source project (miracast) I implemented which is capable of streaming any RTSP stream (think cameras) to any TV, including those of Samsung which do not have support for the Google Chromecast protocol and not all Samsungs support Apple's AirPlay either. Of course here the problem is ... Google, who do not want to support the Matter Media Device clusters that Amazon is pushing for (so that they keep their firm grip as the "streaming/casting gateway" to your TV), hence my dream of having any non-Matter TV (Samsung or not) visible in Google Home as a Matter device might never materialize. :)

@Luligu sorry for the ping, but I thought that might be interesting to you too ^^^.

Hey @ivmarkov ! Thank you for reaching out! I am thrilled to see where our journey is going. I like the idea of building performant and stable solutions and your stack capable of running on ESP is amazing!

But since I am a lot more used to node.js and python than rust, it was easiest for me to build it with @project-chip/matter.js and matterbridge. I would have liked a simple and native python implementation even more - then it could have been a custom integration instead of a HA addon / docker container. Unfortunately there was no ready-to-use python implementation usable on every OS / architecture etc. without building binaries on my own. node with docker seemed to be easier to start with.

Additionally i wanted all this to be open source, since that's the spirit of Home Assistant and Matter.

After finding matterbridge on GitHub, I thought that's a good starting point to get the product usable as soon as possible. A bit like a kick start. Even if all the other matterbridge plugins and some (Web UI) features are not very useful for my usecase.

Additionally this project is meant to build a bridge to Voice Assistants like Alexa and Google Home. It is not intended to fill gaps in protocols. If media-players will be properly supported with matter (and requested by users), this project will just proxy between the voice assistant and Home Assistant. I will NOT implement any media streaming mechanisms to map different protocols.

Short example:

User asks Alexa to start Netflix in the living room
Alexa will tell matterbridge to play [payload: netflix] on [device: my-media-player]
matterbridge-home-assistant will call the corresponding service in home assistant. E.g. "media_player.play_media" with "netflix" as a payload.

At least that is how i imagine that process in the future. I don't want to implement ANY streaming. Just proxy commands from Alexa via Matter to Home Assistant.

As we will always be chasing new features in matter i also decided to limit support for those who are requested by users (or needed by myself). I will not add new entity types if noone asks for it.

Hey @ivmarkov ! Thank you for reaching out! I am thrilled to see where our journey is going. I like the idea of building performant and stable solutions and your stack capable of running on ESP is amazing!

Thank you!

But since I am a lot more used to node.js and python than rust, it was easiest for me to build it with @project-chip/matter.js and matterbridge. I would have liked a simple and native python implementation even more - then it could have been a custom integration instead of a HA addon / docker container. Unfortunately there was no ready-to-use python implementation usable on every OS / architecture etc. without building binaries on my own. node with docker seemed to be easier to start with.

Don't get me wrong - JS, or Python are perfectly fine indeed if the end goal is to run it as an HA integration or an HA Add-On.

I'm really abusing a bit rs-matter for that purpose, as where it would really shine is MCUs (and maybe low-powered embedded Linux scenarios) where (a) RAM is tight (b) predictable operation, i.e. low or no heap usage is king (c) and at the same time and just like with JS and Python - you would value type & memory safety, as there is nothing worse than a crashing device somewhere in the wild, with no or little logs to examine.

rs-matter basically plays in the same niche as the C++ SDK does, except without the big backing of the big corps out there, for now.

Additionally this project is meant to build a bridge to Voice Assistants like Alexa and Google Home. It is not intended to fill gaps in protocols. If media-players will be properly supported with matter (and requested by users), this project will just proxy between the voice assistant and Home Assistant. I will NOT implement any media streaming mechanisms to map different protocols.

Sure. You are lowering the scope of this project which is perfectly fine for an open source project. I'm widening the scope so as to appeal to more users. :)

But with that said, the question is really what this HA-to-Matter bridge really solves?

And the answer (for me) is: bringing legacy devices to the Matter world. Those that you already have and you are unlikely to replace just because Matter exists now. Like your home security cameras from HikVision or whoever, or your alarm system, or your 4K TVs, which work just fine, except not being recognized as Matter displays.

In an ideal world, HA would've been capable of operating my Samsung TVs, but - alas - the Miracast protocol they support is too damn difficult to implement so HA does not bother. Hence it needs help. It is another topic whether this "help" belongs to a bridge like yours or mine, or to HA itself (or a separate add-on of it).

Anyway. Thank you for your feedback.

But with that said, the question is really what this HA-to-Matter bridge really solves?

And the answer (for me) is: bringing legacy devices to the Matter world. Those that you already have and you are unlikely to replace just because Matter exists now. Like your home security cameras from HikVision or whoever, or your alarm system, or your 4K TVs, which work just fine, except not being recognized as Matter displays.

In an ideal world, HA would've been capable of operating my Samsung TVs, but - alas - the Miracast protocol they support is too damn difficult to implement so HA does not bother. Hence it needs help. It is another topic whether this "help" belongs to a bridge like yours or mine, or to HA itself (or a separate add-on of it).

yes and no 😂

This project is about enabling local and fast communication between Voice Assistants like Alexa and home assistant.

Home assistant is meant to stay the main Software to control all devices. If home assistant cannot control the TV, neither can this project.

I was just annoyed by my Alexa skill to take 1-5 seconds to execute my commands. Even with large (memory and cpu) lambda functions, already been warmed up, and a static public IP to reduce DNS lookup times. It was horrible.

This project is all about proxying Home Assistnt.

Just closed this issue, since it’s not an issue. We can proceed discussing here or anywhere else 🙂

t0bst4r / matterbridge-home-assistant

Great work! ... and you might have some competition soon! #94