Introduce CbGPIOSMITH module#65
Conversation
barsnick
left a comment
barsnick
left a comment
There was a problem hiding this comment.
Looks okay. One typo, one question.
| config: | ||
| gpio_line_name: | ||
| description: >- | ||
| The GPIO line name to use as 'gun'' |
There was a problem hiding this comment.
Duplicate ''.
| The GPIO line name to use as 'gun'' | |
| The GPIO line name to use as 'gun' |
FaHaGit
left a comment
FaHaGit
left a comment
There was a problem hiding this comment.
Just a few questions. Otherwise, it looks good.
| } | ||
| }); | ||
| } | ||
| // special case: no linked EVSE Managers -> we cannot see such events -> always trigger immediately |
There was a problem hiding this comment.
Shouldn't we log a warning in case an EvseManager wasn't connected by mistake? It's actually not recommended to leave the EvseManager unconnected, due to the risk of a direct shutdown.
| EVLOG_warning << "PID of systemd-journald not found"; | ||
| } | ||
|
|
||
| std::this_thread::sleep_for(std::chrono::seconds(1)); |
There was a problem hiding this comment.
Is a one-second sleep sufficient to meet the timing requirements for turning off the power?
This module triggers on contactor errors and switches a GPIO. Before, it tries to ensure that the logs are flushed and synced to disk. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
mhei
force-pushed
the
feature/CbGPIOSMITH
branch
from
b74c84e to
8ceecc2
Compare
| if (error.type == "evse_board_support/MREC17EVSEContactorFault") { | ||
| if (this->charging_started_seen) { | ||
| EVLOG_info << "Contactor Error Detected - Triggering Fallback Safety Circuit"; | ||
|
|
There was a problem hiding this comment.
I think this similar to Fabians comment: Maybe we should add a TODO, that this module informs the charging stack of the shutdown or the contactor error is translated into a shutdown notification at the first place?
|
|
||
| flush_journald_and_filesystems(); | ||
|
|
||
| this->gpio->set_value(this->gpio->offsets()[0], gpiod::line::value::ACTIVE); |
There was a problem hiding this comment.
In our case this should be fine, but maybe this is helpful for integrator to verify the GPIO value and provide a warning in case the value is unexpected.
Additional does it make to add a comment that in "good case" everything beyond set_value is "unreachable" code?
5 participants
This PR introduces a tiny module which observes for contactor errors. When some BSP module raises such an error, then this module triggers a GPIO output with the goal that the power path is turned off - this might also result in a power cut of the charger electronics itself, so the module tries to ensure that at least the logs are saved to disk before.