Open gianfrdp opened 8 months ago
Hi I wonder if it does not add too much extra time in the polling sequence with such new commands ?
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
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 ....
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:
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:
You can use some #ifdef option in the code and pass this option in the yaml build option
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
Added some new PIP commands for Axpert Max (aka pip8048):