Allow web_workflow to startup after deep sleep alarm wakeup #7814
Conversation
|
I did this deliberately because starting up the web workflow is slow. We don't start USB for the same reason. I'd prefer to make this a setting rather than changing the behavior for everyone. |
|
I guess the slow part is due to wifi setup. In principle I could agree with you except when you already have a app that connects to wifi at startup anyway. In order to guarantee that you can reach your device for maintenance upgrades (not OS), a reliable and robust web-workflow is required. There are a couple of other issues in this area I am working on. It seems the RPi variant is somewhat more solid than the ESP32. Perhaps due to the different "threading" models - callbacks vs polling. It may also be desirable to be able to turn it on and off from within a CP applet. I guess if after you wake from a deep-sleep, you could then do a reset to have the power-on reason change - but why jump thru hoops? |
|
I've added this to our |
|
I was thinking that for an app in "production", you wouldn't want the web workflow running, to reduce power draw or startup time, or to prevent it interfering with the app in some way. But during development, you want to test it with real sleep, and would want it to start up. |
|
Ideally, one would probably want web_workflow operational whenever an app wasn't running. When an app starts, workflow should shut down. The part about not allowing it to startup after a deep-sleep is a separate issue. Perhaps not trying to start workflow every time a script is launched (including safeboot.py & boot.py) but waiting until you find nothing to run automatically would suffice. However, using the remote serial console can have its uses during script execution. Not having a cool feature like web_workflow available when you need it makes the feature less desirable. I would like to point out here that the system load the current implementation causes is due to looping background processes (workflow and socket select threads) which can happen. It also consumes an unnecessary extra socket while accepting an inbound request. I you would like, I can post my web_workflow work as a PR for further testing and review. It has some substantial changes to socket handling and thread control. |
|
@thess We would welcome a PR for your web workflow improvements! |
That would completely defeat the purpose. There is always "an app running", it's code.py, and the workflow is to edit the code, save, and auto-reload. You don't want to block the access to the workflow when the code is running. You might want to manually turn it off "in production" when you are happy with your code. |
|
@Neradoc - agree with your use case. I was being a bit too facetious 😉 |
On ESP32 based systems, web_workflow does not restart after deep-sleep. Simple patch to allow it attached.