You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: