Dynamic tables & error logger feedback

[GeoDerp]

The functional implementation of https://github.com/davidusb-geek/emhass/issues/186 & https://github.com/davidusb-geek/emhass/issues/191

Changes:

• new actionLogs.txt is generated in datapath storing sessions app.logger info
• on successful html button press, fetch is called to get html containing latest table data
• on html button press, If app.logger ERROR is present, send action log back and present on page.

Note: As of first commit, this PR still needs refining, please wait to merge. Any suggestions appreciated.

[codecov[bot]]

Codecov Report

Attention: 56 lines in your changes are missing coverage. Please review.

Comparison is base (55feb9e) 89.90% compared to head (365370d) 87.63%. Report is 1 commits behind head on master.

Files	Patch %	Lines
src/emhass/utils.py	28.12%	23 Missing :warning:
src/emhass/retrieve_hass.py	33.33%	16 Missing :warning:
src/emhass/command_line.py	23.52%	13 Missing :warning:
src/emhass/forecast.py	20.00%	4 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #196 +/- ## ========================================== - Coverage 89.90% 87.63% -2.27% ========================================== Files 6 6 Lines 1645 1707 +62 ========================================== + Hits 1479 1496 +17 - Misses 166 211 +45 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[GeoDerp]

@davidusb-geek feel free to test this and see what you think.

[davidusb-geek]

Those are some great functionalities! Ok, will do some testing this week-end.

[GeoDerp]

I may put some more effort making it more robust. But If I do it will be in the next few days.

[davidusb-geek]

Ok no problem. Like I said I will only be able to test this week-end

[purcell-lab]

@GeoDerp you are doing some fantastic work in extending the functionality of EMHASS.

Thanks for your assistance! 🎉🎉

[GeoDerp]

Two notes on the error logs side of things:

• it only prints app.logger outputs
  • If we continue going down this route we will just need to make sure we got app.logger.error for all likely fail cases. (If there isn't already)
  • else, we can modify it to print all console log personally I like the idea to get a little info from the webpage and get the rest via the console
• it's currently set to app.logger.info but I may change to debug.

[GeoDerp]

I'm hopping that this logger implementation makes sense and can help others send informative information back to the html.

[GeoDerp]

Sorry @davidusb-geek I closed the other PR as I merged those changes into this one as they are kinda related now. Last things I added

• url and key being incorect produces logger.error
• sensor being incorect produces logger.error
• days_to_retrieve default to 2 if number is under 2. It also produces logger.warning

The commit suppression's before where based on not running optimization or model fit before other commands. These should also give logger.errors and suppress the python logs related also.

The aim is to give logger.error responses to the general issue starting users face. Hope you like it.

[GeoDerp]

@davidusb-geek I'm sorry in advance for all the testing

[GeoDerp]

Just tweaking now.

[GeoDerp]

Just a heads up @davidusb-geek. The reason why i'm setting returns on the functions (returning back to web_server), is that if there is an uncaught python error it stops the current function and runs the next in the action (or just dosn't finish the function at all). Whereas, if I return a string indicating an error has occurred in that function, I can stop that action and send back the log to the user on the website.

This is just how I would program it. Back when I did C in uni, we used to set returns on every function with 0 (fail) or 1 (pass). We could then check if that function worked every time and move to next. If not print issue.

I have only done so on the functions that needed them (ones related to request get rrrors). Hopefully this PR will give appropriate common: url,key and sensor errors.

[GeoDerp]

@davidusb-geek Im pritty happy with this PR now. It's not perfect but I don't believe there will be any problems. I'm currently looking now to see how difficult it would be to set True or Fail returns on every logger.error and end of each function.

That may not be something your interested in. I'm completely fine with that. Hopefully these few returns will suppress the python logs and give appropriate logger.error statements for the main issues people face.

[davidusb-geek]

Ok nice work! I will at this and test it during the week-end

[GeoDerp]

If you're interested; https://github.com/GeoDerp/emhass/tree/Error-Suppression-Testing is my testing branch for testing returns on all functions and if statements to make sure those functions ran without an issue. (If not, return back to webserver and the user will see the logger.errors) I literally just pasted responses and if statements everywhere without thinking about it methodically 😅. But it might be a good idea of what my concept is. 🤔