Add Support for External Button and Web-Based Equipment Stop Functionality #506
Conversation
|
Long press is not necessarily a good idea. For this task, an emergency stop button is appropriate, which, when pressed, stays in pressed-in (locked) state until being released by a different movement (like rotating it). Eg. https://a.aliexpress.com/_ExaEPXb but of course there exist similar ones at brands, even with further safety measures like unlock only possible with key etc. With an emergency stop button, you are in stopped/emergency state while it's being pressed/locked, and can only resume to normal when released. This interferes with long-press logic. Advantage of such a button is that it mechanically stays pressed until deliberately released, which could be useful to be checked at boot too, and protect automatic run of potentially unwanted tasks in emergency situations, even when the board reboots or enters in bootloops etc. |
Very good point. what about having configurable behaviors? there could be lots of diferent kind of integrations and buttons. we can start with this 2. looks good? |
Co-authored-by: Christopher Obbard <[email protected]>
Good! |
Co-authored-by: Christopher Obbard <[email protected]>
|
I agree with @nagyrobi , most big red e-stop switches latch once you press them. This is good behaviour, which at the same time prevents the system from accidentally starting operating after a reboot (since the request for e-stop is still active). I have encountered quite a few e-stop designs over the years, and the majority work this way. Having us only look at the GPIO state for the E-stop (which needs to be a NC circuit to prevent wire break from hindering operation of the switch) also takes out the need to store the e-stop to persistent memory. Since rebooting the emulator with the e-stop engaged will result in it going straight into stopped state. The benefit of storing it into persistent memory would ofcourse be a setup where you remotely want to stop, and a physical reboot might make it go again. So maybe we should separate the two entities? Physical e-stop (which does not require persistent), and webserver e-stop (which writes a stop bit to persistent memory)? |
I agree regarding the NC button. So obvious when looking at it now... |
|
@dalathegreat and @StarkJohan , I also agree that the NC approach is safer. i can change that easy in the code. In the case of TOGGLE_SWITCH, the button is directly tied to the physical state of the button. This state is not persisted, nor can it be altered via the web interface. Regarding your suggestion to separate the web interface behavior from the physical button for the TOGGLE_SWITCH case, how would this work? For instance, if someone triggers the emergency stop via the button, but later disables it through the web interface, we would then need to ignore the physical emergency stop button. Is that the behavior we want? Alternatively, we could consider giving the physical button priority over the web interface, meaning that if the button is activated, it wouldn’t be possible to deactivate it via the web interface. What would be the best approach in the schenario of a latched button? |
|
I'm also worried about the hard exclusion of the other features on LilyGo, just because the limited amount of exposed GPIO. Is the SD card used? There are 4 more GPIOs in the SD card socket. I agree they can't be easily accessed, but one could still manage to use one of them for this, together with the other features. The GPIOs should be freely configurable without having to alter the rest of the code too heavily... |
Could be completely two different safety features. One is software stop, and the other just hardware stop. Shouldn't be related to each other. The hardware stop's status should just be shown in the web interface. One should not interfere with each other. Eg. releasing the button shouldn't release the software stop (someone physically at the device may not be aware that somebody else is remotely working and shouldn't mess the state remotely set). There only should be an OR relation between them. |
|
Shouldn’t the web interface be the final reset that would only provide reset after E-Stop have been reset locally.
From: H. Árkosi Róbert ***@***.***>
Sent: 02 October 2024 15:28
To: dalathegreat/Battery-Emulator ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [dalathegreat/Battery-Emulator] Add Support for External Equipment Stop Button and Web-Based Emergency Stop to Battery Emulator (PR #506)
Alternatively, we could consider giving the physical button priority over the web interface, meaning that if the button is activated, it wouldn’t be possible to deactivate it via the web interface. What would be the best approach in the schenario of a latched button?
Could be completely two different safety features. One is software stop, and the other just hardware stop. Shouldn't be related to each other. The hardware stop's status should just be shown in the web interface. One should not interfere with each other. Eg. releasing the button shouldn't release the software stop (someone physically at the device may not be aware that somebody else is remotely working and shouldn't mess the state remotely set).
—
Reply to this email directly, view it on GitHub <#506 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASBCYAUFUW43DYIEQL7MZGLZZP7IRAVCNFSM6AAAAABPGXYCJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBYG44TINRYGU> .
You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/ASBCYAUJ5WK3ET6QYTU6XGDZZP7IRA5CNFSM6AAAAABPGXYCJOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUOMIOT2.gif> Message ID: ***@***.*** ***@***.***> >
|
Most user will not max out the GPIO on the lilygo. Changing the configuration of the pins is very easy in the HAL. |
|
You misunderstand, I'm not saying not to implement, I'm just worried that the code automatically excludes the usage of the other features with this on LilyGo, whilst it's just all about removing the SD card cap and solder a wire to one of the free GPIOs inside. |
|
Logic has been implemented for two button behaviors, as previously mentioned. On boot, if an emergency button is configured, its state will take precedence for the emulator. This functionality can be used with both physical buttons and the web server. If no physical button is defined, the state set via the web server will persist across reboots. I believe this approach covers most of your suggestions, although it’s not possible to accommodate all opinions. I consider this a solid solution, which can always be improved or modified in the future. |
|
All configurations tested successfully on Lilly board |
|
Added equipment stop before reboot |
amarofarinha
changed the title
…r improved clarity and alignment with the feature's purpose.
Software/USER_SETTINGS.cpp
Outdated
| @@ -48,6 +48,13 @@ const char* mqtt_password = "REDACTED"; // Set NULL for no password | |||
| #endif // USE_MQTT | |||
| #endif // WIFI | |||
|
|
|||
| #ifdef EQUIPMENT_STOP_BUTTON | |||
| // Equipment stop button behavior. Use NC button for safety reasons. | |||
| //TOGGLE_SWITCH - activated while pressed, deactivated when released, button state is reflected in the emulator state | |||
There was a problem hiding this comment.
We should use simple understandable terms here, my suggestion
//LATCHING_SWITCH - Normally closed (NC), latching switch. When pressed it activates e-stop
//MOMENTARY_SWITCH - Short press to activate e-stop, long 5s press to deactivate. E-stop is persistent between reboots
However the more I think about it, I really would recommend dropping support for momentary_switch...
There was a problem hiding this comment.
i will change terms.
as for momentary swich, my preference would be to keep this functionality and let users choose whether to use it.
There was a problem hiding this comment.
change terms commited
There was a problem hiding this comment.
I don't mind the momentary switch support, it's the reset function that need to be very safe and obvious. I don't love the long press but if it's kept, it needs to be rather long.
There was a problem hiding this comment.
i forget to change the time.. 15 seconds then? shou i change it?
There was a problem hiding this comment.
@dalathegreat I understand your concerns, but the MOMENTARY_SWITCH option provides flexibility for different user preferences and safety setups. By keeping this option, we ensure that users have the freedom to choose the configuration that best suits their needs, without compromising functionality.
|
Sorry for joining this review so late, but I'd like to challenge the need to trigger e-stop via the webserver. To me it seems like we are using the equipment stop terminology wrong in the Webserver. From the Webserver, it makes sense to either "Pause", or "Open Contactors". Can we rename this in the Webserver? |
|
I am still also not sure about the benefit of handling a recovery from an "Open contactor" press. To me it makes more sense to latch this, and require a reboot to get out of it. |
|
Same goes with the storing to persistent memory. What are we trying to prevent here? Someone opens contactors via webinterface, and then accidentally restarting, and it proceeds to operate? Feels like a very niche scenario that we dont need to consider? |
To me the scenario of someone pausing/stopping and counting on this being persistent is a good reason to keep the persistence after a power outage or other accidental reboot. |
in web server it does the same as the stop button, it does not just open contactors. it changes max charge discharge, stops all CAN and open contactors. To change the label i would prefer "Pause" |
yes thats the point. the ideia is to mimic the latch physical button. no matter what happen (event a not programmed reebot) the user has to explicity resume the state. |
Rebooting triggers unnecessary disconnections from both Wi-Fi and MQTT, leading to additional time and effort for reconnections and state restoration. By handling issues gracefully without a restart, you maintain seamless connectivity and avoid the complexity of resetting everything. If recovery is possible without a reboot, why not take the smoother, more efficient route? |
What
This PR implements both an external equipment stop button and a web-based emergency stop, allowing for full system shutdown in critical situations. Both options halt charge and discharge operations, open battery contactors (if controlled by the battery), and stop all CAN communications.
Why
The idea for this enhancement originated from @StarkJohan, who provided valuable feedback and insights throughout our discussions. The primary motivation for adding these features is to introduce additional safety mechanisms to the emulator, ensuring that emergency shutdowns can be triggered swiftly via either a physical button or the web interface. These options enhance the safety and responsiveness of the system in case of a critical failure or emergency.
This PR strengthens the emulator's emergency handling capabilities by introducing redundant, user-friendly methods to stop operations in emergency scenarios.
How
Added support for an external equipment stop button connected to a GPIO pin (EQUIPMENT_STOP_PIN).
Integrated web-based emergency stop control to trigger the same shutdown functionality.
Introduced two modes for button functionality:
Activation/deactivation via the web interface is possible allowing the system to resume.
when in EQUIPMENT STOP:
On boot, if an emergency button is configured, its state will take precedence for the emulator. This functionality can be used with both physical buttons and the web server. If no physical button is defined, the state set via the web server will persist across reboots. I believe this approach covers most of your suggestions, although it’s not possible to accommodate all opinions. I consider this a solid solution, which can always be improved or modified in the future.