I2C OLED display steals PWM output in Home Assistant

[ChestersGarage]

Hello All,

This was logged as a bug in HA and they just completely ignored it.

I am using an I2C OLED display and setting up Tasmota as a dimmer for a heater element, using PWM, Zero-Cross detection and a Triac dimmer. But when Home Assistant detects the Tasmota device, it assigns the PWM output to the display instead of the PWM(1) used for the heater.

In my template, I have assigned SDA/SCL to the display ONLY. There are no pins for display backlight at all. And I have assigned a rotary encoder with button to the PWM output for the heater element. All assignments are consistently on "1". I tried putting them on 2, so that the display might take position 1. But that didn't change anything in HA.

But here's what I get in HA:

For some reason the dimmer function is being assigned to the OLED instead of the heater PWM as expected. I have tried adding other PWMs and reassigning numbers, but it never assigns things correctly. As it stands, I can get the functionality I want at the device, using rules (for which I have made a separate post). But in HA, I have no way to change the dimmer value of the heater element. And the dimmer slider that is attached to the display in HA throws an error in Tasmota.

11:49:00.168 MQT: stat/tasmota_218C64/RESULT = {"Command":"Error","Input":"CHANNEL2 74"}

Expected, of course, because there is no Channel2 dimmer, at least as far as the Tasmota config is concerned. If I try to get the status of Channel2, it says:

12:01:48.692 CMD: Channel2
12:01:48.694 MQT: stat/tasmota_218C64/RESULT = {"Command":"Error","Input":"CHANNEL2"}
12:01:56.762 CMD: Channel1
12:01:56.764 MQT: stat/tasmota_218C64/RESULT = {"Channel1":18}

Switch elements in HA are assigned correctly. Just the dimmer is assigned to the display instead of the heater's PWM.

This feels like a bug in Tasmota or HA, but I wanted to make sure I wasn't doing something dumb myself before logging a bug. (And I'm not sure yet which project has the bug.)

Thanks!

[sfromis]

The display does inherently have a "dimmer" function, as visible in output from the command Display. And yes, it does nothing with those simply displays. Not involving any backlight pin, configured or not.

You did not mention how you configured your PWM, like settings for SetOption15 and SetOption68, which can make a significant difference to how Tasmota reports configuration discovery data. SetOption30 might also make a difference, not sure if it would in your config.

The tasmota/discovery/<mac>/config MQTT payload is where the discovery data is reported, you can see that if booting with Weblog 4

Not using HA, I'm not sure of the mechanism why HA even saw something about a display, but maybe your discovery payload would indicate that.

[ChestersGarage]

OK, got a few different issues going on at once, and many revisions of things to try floating around in my head... ;)

As of this post on my other thread, I have applied those SetOptions and got great results ONLY IF the display was disabled by removing Option A3. Everything works great without the display involved. As soon as I introduce Option A3, Tasmota fails to map/associate/assign/whatever resources correctly, and things don't work well in Home Assistant.

Anecdotally, the problem appears to be that the display is not creating a PWM object for itself, and thus it is stealing the configured PWM object I set up for the dimmer. In Home Assistant, the dimmer dialog tries to adjust a non-existent Channel2.

This very much feels like a bug in Tasmota, in particular with the Universal Display driver. I have tried a mind-numbing number of different approaches and configurations, all of which have the same result: the PWM controler for the dimmer gets assigned to the display instead.

I ran it through Github Copilot, and it suggested the slop below, which did not work for me (but I don't know the first thing about C++). Maybe it will offer a hint on how it should be fixed. Root cause analysis is probably more useful than the suggested edits.

Me (in VSCode with Github Copilot extension):

I have encountered a bug in the code.  The bug is that when a display is used with a PWM-controlled light, the PWM is incorrectly associated with the display backlight dimmer instead of the light. Find this bug and propose how the code should be modified to properly associate the PWM channel with the light.  Review all necessary code within the workspace to find the issue.

GitHub Copilot:

Bug: calling ApplyDisplayDimmer during display init steals/allocates PWM channels early (for the display backlight) before the light subsystem initializes, so a PWM-controlled light can end up using the backlight PWM channel.

Root cause location:

* Init_uDisplay in xdsp_17_universal.ino calls ApplyDisplayDimmer immediately: ApplyDisplayDimmer

Fix: do not call ApplyDisplayDimmer synchronously from Init_uDisplay. Instead, set the request flag so the framework applies the dimmer later (after lights and PWM channels are initialized). This prevents the display from grabbing PWM channels intended for lights.

Edits:

Change in xdsp_17_universal.ino — replace the block after renderer->invertDisplay(iniinv) with a single extern + set:

// ...existing code...
    renderer->invertDisplay(iniinv);

-    // Defer applying the display dimmer so PWM channels are allocated after lights init
-    extern bool disp_apply_display_dimmer_request;
-    // Add global request flag for deferred display dimmer application
-    bool disp_apply_display_dimmer_request = false;
-
-    static void ProcessPendingDisplayDimmerRequest(void) {
-      if (!disp_apply_display_dimmer_request) return;
-      ApplyDisplayDimmer(GetDisplayDimmer());
-      disp_apply_display_dimmer_request = false;
-    }
-
-    bool Xdrv13(uint32_t function) {
-      // ensure pending display dimmer request is handled on driver tick
-      ProcessPendingDisplayDimmerRequest();
-    }
+    // Defer applying the display dimmer so PWM channels are allocated after lights init
+    extern bool disp_apply_display_dimmer_request;
+    disp_apply_display_dimmer_request = true;
    
#ifdef SHOW_SPLASH
// ...existing code...

Add to the display driver file xdrv_13_display.ino (top-level, not inside any function): define the flag, the processor, and call it from Xdrv13:

// ...existing code...

// Request flag for deferred display dimmer application
bool disp_apply_display_dimmer_request = false;

static void ProcessPendingDisplayDimmerRequest(void) {
  if (!disp_apply_display_dimmer_request) return;
  ApplyDisplayDimmer(GetDisplayDimmer());
  disp_apply_display_dimmer_request = false;
}

// ...existing code...

bool Xdrv13(uint32_t function) {
  // ...existing code...
  // handle deferred display dimmer request on driver tick
  ProcessPendingDisplayDimmerRequest();
  // ...existing code...
}

I can write up a real bug report if necessary. Let me know.