lbussy
commented
2 years ago Those were my additions - and there were a few reasons I did not go with Websockets:
- The index page is a minor hit, Websockets would be unnecessary work. A hammer when a scalpel is needed.
- The About page definitely creates resets on one of the models - but the fix is not avoiding AJAX but fixing whatever is crashing the device. We left it there purposefully as a way to test the work we were doing to stabilize it.
- Nobody is going to sit there on the About page, the fun is on the Index.
- AJAX was a lot easier to develop on the client-side while I was working with it.
- With Async Web Server, there should be little difference in the overhead when we finally figure out what is causing the crashes (seems to be related to BT)
So, no reason not to do it, but there was just little reason to change for change's sake.
thorrak
pletch
@thorrak, curious if you have considered evaluating use of EspAsyncWebserver websockets push functionality to replace the AJAX polling done on the about page and index pages? While playing with master to evaluate the MQTT fixes, I noticed there are still infrequent unrequested reboots that can occur when on the 'about' page.
Over the weekend, I threw together a websockets implementation using the master branch and this qualitatively seems to work pretty well, perhaps being less resource intensive once the socket connection is established. In addition, the values can be sent to multiple clients at once (though realize use case for this here is essentially non-existent) and the update frequency on the heap and uptime metrics can be increased to a few seconds with low overhead which is nice.