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

additional safety items #726

Open
mbu10 opened this issue Jan 1, 2025 · 0 comments
Open

additional safety items #726

mbu10 opened this issue Jan 1, 2025 · 0 comments

Comments

@mbu10
Copy link

mbu10 commented Jan 1, 2025

Improvement Idea

I’ve noticed a reliance on a single board, with the option of adding a secondary CAN bus board if isolation is required. While this approach is functional, it introduces a single point of failure. Having worked in large-scale environments, I believe there’s an opportunity to enhance reliability.

My suggestion involves using either a single or dual LilyGO boards alongside a "witness" device. The witness would not have control over operations but would monitor communication between the ESP(s) and the CAN bus. Operating in monitor mode, it would verify the data reported by the ESP(s). If there’s a discrepancy (beyond a reasonable grace period) between what the ESP(s) report and what the witness observes, the witness could issue a command to reboot the ESP(s).

This setup could also enable a robust failover system. For example:

One ESP acts as the primary (master), and the other as the secondary (slave), with both connected to the relays.
In case of a failure, such as a frozen or upgrading ESP, the secondary can take over seamlessly, ensuring uninterrupted operation.
This hot failover design would significantly reduce the risk of critical failures like overcharging, as it would require both ESPs to fail simultaneously.
The witness could also interface with the inverter via Modbus, sending direct commands to start or stop charging as needed. Additionally, this system could integrate with platforms like Home Assistant, enabling features such as timed remote charge/discharge schedules or integration with energy providers like Octopus.(this could be done like this as the witness is not time sensitive so the witness could run some more code , and only checking every min or so as its not millisecond sensitive

This approach would improve system resilience, provide better control, and open the door to future integrations and advanced features.

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

No branches or pull requests

1 participant