Quibbles with light bulb autogenerated HA YAML

[dwildstr]

I'm glad the feature to autogenerate YAML is working (it used to just have a blank configuration), but I noticed some discrepancies between what it generates and what I've been using on an RGBCW light ---- some of that's certainly down to personal preference in configuration, but there were a few things which seemed like they were mistakes. This is all in lines 1351–1367 of httpserver/http_fns.c, although similar issues seem to be in the RGB-only code in 1381–1391.

• all the lines past name are indented too far, with 7 spaces instead of 4.
• The key brightness_value_template seems unnecessary; purely numeric data shouldn't need processing to be intelligible to the MQTT light platform. The same is true of the color_temp_value_template key, which is already commented out.
• There's no rgb_value_template key, which seems like it should be necessary, since OpenBeken reports colors as hex values instead of comma-separated triples (which are what Home Assistant likes to get). I use rgb_value_template: "{{ value[1:3] | int(base=16) }},{{ value[3:5] | int(base=16) }},{{ value[5:7] | int(base=16) }}" in my configuration to convert it.

[dwildstr]

An addendum: The state_topic key as currently written causes the bulbs to have their state reported as "unknown" in Home Assistant; removing it seems to make them mostly work (sometimes being a bit out of sync if HA or the bulbs have been rebooted). I can't figure out why this would be the case. The bulbs do indeed seem to be publishing their state on MQTT correctly. This may be related to some HA issues, see https://github.com/home-assistant/core/issues/67545 and https://github.com/home-assistant/core/issues/74019, but until that's fixed, it might be safer to remove the state_topic line from autoconfig.

[openshwprojects]

Hmmm I didn't think that indent affects anything, but ok. The {{ value }} stuff was just to be sure that no strange default setting breaks things. Anyway, I have applied your suggestions and I will try to check it now when I get some free time: https://github.com/openshwprojects/OpenBK7231T_App/commit/585f633de568538ced3b56238e85e9d2ae30dc78 Can you recheck?

Also... "or the bulbs have been rebooted)." - I think there is a flag for bulb to broadcast it's state after reboot, but obviously, if you disable receiving the state then HA won't know what changed.... Maybe using the flag for saving RGB CW states for reboot can help

[openshwprojects]

Wait.... shouldn't the rgb_value_template be: rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}" ?

[iprak]

The state_topic seems to work fine for RGB. This could be because the device does not publish the state unless some change was made or Flag 2 was set. With Flag 2, the bulb state syncs up within the next 30 seconds. I realized this while working on #247.

The generarted yaml seems to have been fixed and the other hass issue had long been closed.

[openshwprojects]

@iprak @dwildstr why do you think that _rgb_value_template: "{{ value[1:3] | int(base=16) }},{{ value[3:5] | int(base=16) }},{{ value[5:7] | int(base=16) }}" _ is correct? The published value has no # prefix, so it should be rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}" ?

[iprak]

Currently, I am not seeing any issues with RGB operation.

[dwildstr]

@openshwprojects I think you're correct about the indexing in the rgb_value_template being off by one. HASS had the right RGB info for me, but I think it had it in spite of, not because of, that line.

I still can't get my bulbs to work when state_topic is present; they show up as "Unknown". But I'll keep tinkering.

[iprak]

@dwildstr Can you paste your device yaml? And what HomeAssistant version?

[dwildstr]

It looks like turning on Flag 7 (retain all MQTT publications) makes it work better. I'm guessing Home Assistant was somehow not "seeing" stale led_enableAll data or something. But weirdly it didn't help much to force toggle the lights through the web interface. Anyways, I've got it sort of working now, but here's the relevant YAML (HASS version 2022.10.1):

mqtt:
  light:
  - name: "Jake's bedside"
    unique_id: "jakes-bed"
    availability_topic: "obk-jake-bedside/connected"
    brightness_command_topic: "cmnd/obk-jake-bedside/led_dimmer"
    brightness_scale: 100
    brightness_state_topic: "obk-jake-bedside/led_dimmer/get"
    color_temp_command_topic: "cmnd/obk-jake-bedside/led_temperature"
    color_temp_state_topic: "obk-jake-bedside/led_temperature/get"
    command_topic: "cmnd/obk-jake-bedside/led_enableAll"
    rgb_command_template: "{{ '#%02x%02x%02x' | format(red, green, blue)}}"
    rgb_command_topic: "cmnd/obk-jake-bedside/led_basecolor_rgb"
    rgb_state_topic: "obk-jake-bedside/led_basecolor_rgb/get"
    rgb_value_template: "{{ value[0:2] | int(base=16) }},{{ value[2:4] | int(base=16) }},{{ value[4:6] | int(base=16) }}"
    state_topic: "obk-jake-bedside/led_enableAll/get"
    payload_off: 0
    payload_on: 1

[iprak]

Yes usually changing something in webApp syncs up the values.

I am assuming that the MQTT server is working fine and that you don't have Flag 2 set. The yaml matches what I had. I will double check the operation at my end.

[iprak]

I do see unknown state after adding a device. This just seems to be because no status has been sent from the device.

Manually picking bightness and color sent messages on w600Test/led_basecolor_rgb/get and w600Test/led_dimmer/get .. what was missing was the message w600Test/led_enableAll/get. Toggling the light updated the state in hass.

I tend to enable Flag=2 which automatically sends out the status every 60 seconds, so didn't notice this.

For the case where device is added via discovery, it can handle this by sending out one time status.