Help needed: Passing DisplayBuffer, Font and more to a custom component

ESPHome
1

For a project with a 8x32 RGB Matrix i need to build a custom component to do the text scrolling as a first step.

After reading and trying i couldn’t find a solution.

I tink i have to pass the display, font, color and text_sensor to my custom component. Which doesn’t work at all. The yaml works fine, but not my selfmade code.

So here is the relevant part of my custom component:

class HAtrixComponent : public PollingComponent {

 public:
    display::DisplayBuffer cDisplay;
    TextSensor cText;
    void *cFont;
    Color cColor;

  HAtrixComponent(display::DisplayBuffer *it,TextSensor *text, Color *color, void *pfont) : PollingComponent(250) 
  {
     cDisplay = it;
     cText = text;
     cColor = color;
     cFont= pfont;
  }
  
}

and here are some of the errors:

In file included from src/main.cpp:49:0:
src/HAtrixcomponent.h:9:28: error: cannot declare field 'HAtrixComponent::cDisplay' to be of abstract type 'esphome::display::DisplayBuffer'
     display::DisplayBuffer cDisplay;


In file included from src/main.cpp:49:0:
src/HAtrixcomponent.h: In constructor 'HAtrixComponent::HAtrixComponent(esphome::display::DisplayBuffer*, esphome::text_sensor::TextSensor*, esphome::Color*, void*)':
src/HAtrixcomponent.h:16:15: error: no match for 'operator=' (operand types are 'esphome::display::DisplayBuffer' and 'esphome::display::DisplayBuffer*')
      cDisplay = it;

In file included from src/main.cpp:49:0:
src/HAtrixcomponent.h:17:12: error: no match for 'operator=' (operand types are 'esphome::text_sensor::TextSensor' and 'esphome::text_sensor::TextSensor*')
      cText = text;

Any hints for me? My goal is to create something like this this or this only in esphome.

2

They are reference/pointer types (I can’t recall which is which, my C++ is rusty) and the compiler is complaining about that. Note the pointer ‘*’ differs between what it says it needs and what it was passed. So instead…
Refer to ‘it’ in your lambda/custom C++ using the ‘id’ macro, as in:

id(whatever_id_you_gave_the_display_in_the_yaml)

and then you shouldn’t need to pass it as a param.
(If I understand at all correctly what’s going on and what’s probably surrounding these blocks of code)

1 Like
3

Very nice, it works!!!

But the yaml and the custom_componet are only loose coupled by the name.
If i have a different id for the display in the yaml nothing will work. Perhaps is there a cleaner solution.

But now, thank you i will continue to code the logic.

4

Not sure I understand what is undesirable about referencing the buffer object by name (as long as the names aren’t mutable at runtime, and they’re very likely not).
Symbols you use in the YAML are visible within lambdas.
Or, are you planning to use the same custom_component with different YAML configs? Yes, that could pose a naming challenge, or require a standard.
The id() macro dereferencer the only way I know that works and as far as I can tell is what the designer intends us to do.

5

Yes, that is what i have planned but if there is no alternative i will take the id(name) way, which is much easier and fits good to my low coding skills.

Thanx

1 Like