No way to access global variables from .cpp file in "includes"

[djwlindenaar]

The problem

with the includes directive it's possible to link .cpp files into the project. However, to be able to usefully implement code in this cpp file, it should be possible to access the global variables that are generated by ESPHome.

Example:

esphome:
  name: "${device_name}"
  includes:
    - test.h
    - test.cpp
  on_boot:
    priority: 200
    then: 
      - lambda: !lambda test();

In test.cpp:

void test()
{
  ESP_LOGD("test", "%f", id(input_fan_speed).state);
}

If ESPHome would a header file with externals to link the generated globals, this code would run.

Which version of ESPHome has the issue?

git dev branch dd. January 5th, 2023

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

N/A

What platform are you using?

ESP32

Board

nodemcu

Component causing the issue

core

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[ssieb]

You can make the external reference yourself or pass it in as a parameter from the lambda. If you're needing access to things like this, then you should be making a proper component instead.

[djwlindenaar]

@ssieb , fair enough. Using this main.h approach just allows for neat implementation of c code that would otherwise be implemented as lambda in the yaml file. With all downsides of that (e.g. no syntax hilighting in the editor). With this I can easily implement the code in a separate .cpp file. You're right that I could include all those externals as arguments in the function call. Otoh, both implementing a proper component or adding the arguments just adds manual work for me, which could be solved by generating main.h, since all information is available to the code generator anyway.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Unfocused]

You can make the external reference yourself or pass it in as a parameter from the lambda. If you're needing access to things like this, then you should be making a proper component instead.

I agree with this in general... except when it comes to display lambdas, which are inherently complex and can get quite large. Components can be too heavyweight/a poor fit, while includes suffer from this issue. It's rather awkward to pass around references of id() and it to every function that's been implemented in an include/component. Especially when using pages - a lambda for each page, but currently no good way to share code/context between them. They need some tools to allow easier refactoring into modular bits of code.

And as a general rule: anything that helps the worst case scenareos automatically helps everything else too.