Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added new sensors for PIP8048 #90

Open
wants to merge 3 commits into
base: pip8048
Choose a base branch
from
Open

Conversation

gianfrdp
Copy link

Added some new PIP commands for Axpert Max (aka pip8048):

  • QET
  • QLT
  • QMCHGCR
  • QMUCHGCR
  • QPGS0
  • Q1
  • QBMS

@SeByDocKy
Copy link
Collaborator

SeByDocKy commented Oct 17, 2023

Hi I wonder if it does not add too much extra time in the polling sequence with such new commands ?

@gianfrdp
Copy link
Author

Didn't compare time before and after changes, sorry.

Something useful could be to find a way to execute a command only if configured, and skip if not configured.
In this way we don't need to change source code if we need to use a command.
Could add a flag for polling_command to be executed.
Flag should be FALSE by default and switch to TRUE if used some name of a polling_command, and flag should be evaluated before to execute it.

In this way we could define all possible polling_commands, but execute them only if defined a sensor/output/etc in yaml.

Just brain storming, I don't know if we can check when a parameter is used in yaml and pass a flag

@SeByDocKy
Copy link
Collaborator

SeByDocKy commented Oct 18, 2023

Didn't compare time before and after changes, sorry.

Something useful could be to find a way to execute a command only if configured, and skip if not configured. In this way we don't need to change source code if we need to use a command. Could add a flag for polling_command to be executed. Flag should be FALSE by default and switch to TRUE if used some name of a polling_command, and flag should be evaluated before to execute it.

In this way we could define all possible polling_commands, but execute them only if defined a sensor/output/etc in yaml.

Just brain storming, I don't know if we can check when a parameter is used in yaml and pass a flag

No I didn't compare coz actually I still running on my PIP8048 version but it's not hard to guess that it will be slowed down by the ratio of the new transmitted caractars of all new commands versus the the total number of caractars of all commands...

It will be great effectively to be able to choose the sequence of command sent. In a first idea, we could play with some #define options front of each element of the enum of the pipsolar.h then use (or not use these options) via the build_options in ESPhome.... I hope I am clear ....

@gio-dot
Copy link

gio-dot commented Jan 7, 2024

Didn't compare time before and after changes, sorry.

Something useful could be to find a way to execute a command only if configured, and skip if not configured. In this way we don't need to change source code if we need to use a command. Could add a flag for polling_command to be executed. Flag should be FALSE by default and switch to TRUE if used some name of a polling_command, and flag should be evaluated before to execute it.

In this way we could define all possible polling_commands, but execute them only if defined a sensor/output/etc in yaml.

Just brain storming, I don't know if we can check when a parameter is used in yaml and pass a flag

Hi, in order to exclude unneeded commands/sensors, it would be enough to comment polling_commands in file pipsolar.h or there are other software parts in the component files to modify? I mean here:

image

@SeByDocKy
Copy link
Collaborator

Didn't compare time before and after changes, sorry.
Something useful could be to find a way to execute a command only if configured, and skip if not configured. In this way we don't need to change source code if we need to use a command. Could add a flag for polling_command to be executed. Flag should be FALSE by default and switch to TRUE if used some name of a polling_command, and flag should be evaluated before to execute it.
In this way we could define all possible polling_commands, but execute them only if defined a sensor/output/etc in yaml.
Just brain storming, I don't know if we can check when a parameter is used in yaml and pass a flag

Hi, in order to exclude unneeded commands/sensors, it would be enough to comment polling_commands in file pipsolar.h or there are other software parts in the component files to modify? I mean here:

image

You can use some #ifdef option in the code and pass this option in the yaml build option

@SeByDocKy
Copy link
Collaborator

SeByDocKy commented Mar 28, 2024

For example in your cpp code, you can use some

#ifdef OPTION1
  some code
#endif 

then in your yaml

esphome:
  platformio_options:
      build_flags:
          - -DOPTION1

Hope can help you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants