dear home assistant community,
I’ve been pointed to this discussion. I am the current maintainer of the firmware in question here.
Looking at the available documentation, I assume that we are at a bit of an impass on how Home Assistant and my firmware implement mqtt.
It seems that HA primarily uses topics to convey state and direct state changes (commands) while we implemented a json-rpc interface over mqtt, basically sending and receiving api calls.
At this point, certainly nobody expects autoconfig for those LED lights, but would it be possible for HA to generate mqtt messages like this?
{
"jsonrpc":"2.0",
"method":"hsv",
"params":
{
"h":<hue[0-360]>,
"s":<sat[0-100%]>,
"v":<val[0-100%]>
}
}
I can see that the fact that HA treats hue/sat seperately from val to be an issue but the firmware also accepts partial updates, so omitting any of the three parameters should be fine.
The real plus for using this “custom” firmware (which firmware isn’t) is that it does 10Bit pwm on ESP8266 and 50Hz “frames” and thus provides really smooth fades all the way to off, I’m not aware of any other firmware providing this on that platform.
also, we have about 1500-2000 devices running it in the fhem community alone.
I’m currently doing a major rewrite to (finally, took us a while) also support the Esp32 (xtensa and RISC-V) and extend the functionality. Since HA seems to be the current darling of people doing home automation, it would be great to achieve functional parity to what we have in fhem - I’m ok with implementing an alternative mqtt interface that is state rather than command oriented, but I want to explore if HA maybe can deal with the current format without major efforts.
best
pj