Issues Configuring 4-Channel PWM Dimmer in OBK for Home Assistant Autodiscovery

Hi there!
I'm having some issues with OBK autodiscovery related to HomeAssistant.
I suppose I'm doing something wrong... or do not actually understand how things (should) work in OBK so after quite some trial and errors I decided to start bothering here...
Hopefully it's just my wrong doing (not understanding) and not something else...

What am I trying to accomplish:
- define "functionalities" in OBK web config (define pins, pwms, buttons...)
- issue HA Autodiscovery from OBK to get the device/entities shown/configured in HomeAssistant

Some basic options seems to work OK (declaring pin as Button + declaring pin as Relay for the same button produces a "switch" in HA; declaring a pin as "dInput" also produces a "binary sensor" in HA...) so this is "ok", I suppose.

The issues start with PWM lights/dimmers.

I have a 4-channel dimmer where I would like to use each channel as a simple Dimmer - just "brightness" for four different lights.
So, configured pins 6,7,8,9 as PWM and set the relevant pins "channelType" to "Dimmer" through webApp
But... after autodiscovery I get a single "light" device in HA with the RGB, color... properties instead of 4 simple "dimmers".
I thought the problem could be that OBK is by default taking consecutive "channels" as RGB elements and so "publishes" just one light... so I configured the pins as 6,7,8,9 as PWM1, PWM10, PWM20, PWM30 hoping to get 4 separate "lights" and... it half-worked!

In the OBK HA Config the configuration is nicely shown BUT the autodiscovery in HA has NO LIGHTS whatsoever?!



Also... the channels in MQTT are "just something" (6,7,8,9) instead of 1,10,20,30 as they should be. Also, the "led_dimmer" etc is just ONE instead of for each channel (as I understand).

How can I configure the OBK device to autodiscover 4 (simple) dimmers in HA?
I know I could copy-paste the suggested HA config in config.yaml but that is ugly and requires constant edits/corrections on two places (device+config file)
The generated HA config (or manual changes) IS NOT sent to HA by "start HA autodiscovery", right? It's there just for "copy to clipboard", right?

Also... is it possible to "configure" the pins to be discovered as TRIGGERS (buttons) in HA? As the HA docs say the triggers are not allowed to be defined in the confg.yaml but (only) through autodiscovery?
Buttons should really act as triggers in HA (NOT binary sensors where you have to check transitions from on->off or off->on) - to be real triggers/events. That would greatly simplify multi-function buttons (single, double triple press, short press, long press...)

How does any "automatic behavior" linked to pins (PWM for example, acting as RGBC(W) lights by default) behave when you start to add event handlers etc in OBK? Does the "automatic behavior" stay intact? (ex publishing and listening to led_dimmer... led_brightness...)

Is there any way of using "variables" (other than channels) in PUBLISH/SUBSCRIBE commands in OBK scripts/handlers like for example, to use "short name", "full name", "mqtt base topic"? This way the script could be the same and would automatically use the correct names/topics for MQTT commands. (after making event handlers/scripts for btn presses or dimmer handling etc)

Sorry for the delay, that's a pretty long post! I will try to help you, but keep in mind that our base assumption is that the automatic HASS discovery is for simple devices, and for advanced use cases you are supposed to write YAML by hand.

mculibrk wrote:

I have a 4-channel dimmer where I would like to use each channel as a simple Dimmer - just "brightness" for four different lights.
So, configured pins 6,7,8,9 as PWM and set the relevant pins "channelType" to "Dimmer" through webApp
But... after autodiscovery I get a single "light" device in HA with the RGB, color... properties instead of 4 simple "dimmers".
I thought the problem could be that OBK is by default taking consecutive "channels" as RGB elements and so "publishes" just one light... so I configured the pins as 6,7,8,9 as PWM1, PWM10, PWM20, PWM30 hoping to get 4 separate "lights" and... it half-worked!

This is simply not supported, as I have never seen any such device in my life, and I already did a hundreds of teardowns:
https://openbekeniot.github.io/webapp/devicesList.html
I can look into adding it, but as I said, the idea is that HASS discovery is for simple devices, and for custom functionalities you can do Yaml by hand.

mculibrk wrote:

Also... the channels in MQTT are "just something" (6,7,8,9) instead of 1,10,20,30 as they should be. Also, the "led_dimmer" etc is just ONE instead of for each channel (as I understand).

The code currently takes first PWM channel and assumes the consequent channels are for the next colors.

mculibrk wrote:

How can I configure the OBK device to autodiscover 4 (simple) dimmers in HA?
I know I could copy-paste the suggested HA config in config.yaml but that is ugly and requires constant edits/corrections on two places (device+config file)

I may look into it and add that possibility if you think that may be useful.

mculibrk wrote:

The generated HA config (or manual changes) IS NOT sent to HA by "start HA autodiscovery", right? It's there just for "copy to clipboard", right?

You are correct, generated HA config is a legacy thing and it's not in the synchronization with Discovery. We may totally hide it in the future or move it to the Web App.

mculibrk wrote:

Also... is it possible to "configure" the pins to be discovered as TRIGGERS (buttons) in HA? As the HA docs say the triggers are not allowed to be defined in the confg.yaml but (only) through autodiscovery?

I do not know about TRIGGERs so far, but if you provide a sample code, I may add that to the HASS Discovery.
For buttons, I use this guide Home Assistant - how to create an event trigger button, MQTT, dashboard panel

mculibrk wrote:

How does any "automatic behavior" linked to pins (PWM for example, acting as RGBC(W) lights by default) behave when you start to add event handlers etc in OBK? Does the "automatic behavior" stay intact? (ex publishing and listening to led_dimmer... led_brightness...)

Automatic behavious always stay intact.

mculibrk wrote:

Is there any way of using "variables" (other than channels) in PUBLISH/SUBSCRIBE commands in OBK scripts/handlers like for example, to use "short name", "full name", "mqtt base topic"? This way the script could be the same and would automatically use the correct names/topics for MQTT commands. (after making event handlers/scripts for btn presses or dimmer handling etc)

If you use a publish command, it will automatically publish under given devices short MQTT name:

First of all, thanks for your response and the time!

You're right... this was a loooong post. I'll break it now in a few parts to be easier...

p.kaczmarek2 wrote:

Sorry for the delay, that's a pretty long post! I will try to help you, but keep in mind that our base assumption is that the automatic HASS discovery is for simple devices, and for advanced use cases you are supposed to write YAML by hand.

Yeah, I know that... but that's kind'a "uggly". To have to manually edit and keep thing "in-sync" is not really nice/friendly...

p.kaczmarek2 wrote:

mculibrk wrote:

I have a 4-channel dimmer where I would like to use each channel as a simple Dimmer - just "brightness" for four different lights.

This is simply not supported, as I have never seen any such device in my life, and I already did a hundreds of teardowns:
https://openbekeniot.github.io/webapp/devicesList.html

I know about all your teardowns and devices... a fantastic job by the way! Thanks for that too!
You said you never seen something like that? Well... as an example take the "Magic Home RGB CTT" https://www.elektroda.com/rtvforum/topic3889041.html#19999397 and similar devices (I have this one - will provide teardown info - https://www.aliexpress.com/item/725319185.html - which is similar but with more powerful MOSFETs)
Also, why limit yourself to the "original role" of the device if you can use/extend it to better suite your needs? (add inputs, sensors, outputs...)

So, instead of driving one RGBxx light I use it to drive 4+ different single color lights (or leds, or strips...)
that's the reason I need multiple "simple dimmers"

p.kaczmarek2 wrote:

mculibrk wrote:

Also... the channels in MQTT are "just something" (6,7,8,9) instead of 1,10,20,30 as they should be. Also, the "led_dimmer" etc is just ONE instead of for each channel (as I understand).

The code currently takes first PWM channel and assumes the consequent channels are for the next colors.

I supposed so... that's why I tried to use very "distant" channels... but, as you can see, the MQTT topics get "unreasonable/unlogical" numbering/naming

Also, as far as I can see, currently the system is not "prepared" to have more than one RGBCT/RGBxx light under control...
I suppose the "right way" would be to check if the channel type is configured as "Dimmer" and depending on that configure channel behavior as "RGB/RGBCT/DIMMER" (with coresponding HA config)

I just recently started to "dive" through the code to actually see how thing are done... so I'll need some time to grasp how thing are done...

Anyway, I think all the "custom configuration" should somehow be stored on the device and be "autodiscovered" by HA (by publishing config info).
That's much better from an administrative point (all changes in one place) and also for backuping/cloning device configuration, for example by doing a "(config) flash dump/restore" from WebApp.

Maybe this "custom (auto) config" could be stored as a kind of "template" in a file? That should be easier/faster than programming the autodiscovery for all possible variants...

I know you did some modifications to allow remote configuration via HA/MQTT by issuing commands (for (mass) provisioning) which is great... but I think the "backup-restore" would be a faster/better option, wouldn't it?
You configure your (template) device with all the settings, scripts, handlers etc etc and then just do a "config backup" which backups everyting (except MACs, maybe names? etc). Then you could perform a complete restore with just one "step" (through webapp or HA/MQTT upload command)

Added after 13 [minutes]:

p.kaczmarek2 wrote:

mculibrk wrote:

Also... is it possible to "configure" the pins to be discovered as TRIGGERS (buttons) in HA? As the HA docs say the triggers are not allowed to be defined in the confg.yaml but (only) through autodiscovery?

I do not know about TRIGGERs so far, but if you provide a sample code, I may add that to the HASS Discovery.
For buttons, I use this guide Home Assistant - how to create an event trigger button, MQTT, dashboard panel

No... the example you mention is for "buttons" in the HA UI.

Buttons as such should generate triggers or events (kind of pressed, released, short_press, long_press, double_press, triple_press...) and have no state (as relays/switches do).
On the HA side triggers shows under device and you can use them directly to trigger something (no need to check state off --> state on etc)

HA examples for definition:
https://www.home-assistant.io/integrations/device_trigger.mqtt/
https://www.home-assistant.io/integrations/event.mqtt/
https://www.home-assistant.io/integrations/event/#device-class

I currently don't have any device at hand which "publishes" trigger in the autodiscovery data to show you "a real example" but will find some and post it here for you to see

Added after 10 [minutes]:

p.kaczmarek2 wrote:

mculibrk wrote:

Is there any way of using "variables" (other than channels) in PUBLISH/SUBSCRIBE commands in OBK scripts/handlers like for example, to use "short name", "full name", "mqtt base topic"? This way the script could be the same and would automatically use the correct names/topics for MQTT commands. (after making event handlers/scripts for btn presses or dimmer handling etc)

If you use a publish command, it will automatically publish under given devices short MQTT name:

Ah, yes... I missed that part... that it by default uses the "right" base topic... that helps... BUT...
is it possible to use variables in the MQTT config "Client topic (base topic)"?
I mean, to set it to be "$ShortName" (or similar) to always track the changes of device config?
Again - to not have to check/modify the "same" thing at different places.

Any yes, to use this "baseTopic" in other places like publish custom autodiscovery? (because you have to publish discovery data under homeassistant/<type>/<name - baseTopic>/config and having to change this everywhere when you rename the device is not "nice")