There is an exception when you try to access the page without configuring auth/user

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2073, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1518, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1516, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1502, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
  File "/app/homed.py", line 25, in display_home
    app.logger.info("user={user}, path=/".format(user=user["username"]))
KeyError: 'username'

Very cool project otherwise, keep up the good work!

In creation of Dark Mode (#2) I am realizing that the upgrade path will be pretty difficult because of how the image puts the used code into place. Users will need to delete their current code in order for the new code to be used.

This has to do with the image copying the initial code into the user mounted volume and likely puts too much onus on the average user to have to delete it in order to pick up updates.

Multiple things should likely be done:

1. Stop copying all of the app files and assets over to the user volume.
2. Offer a custom.css and custom.js for the user to make adjustments they'd like in. It should contain only their changes, never core-app items and be stored on the user volume (/config in the container).
3. Look at Making the HTML utilize modules of some sort is likely going to be needed.

Need to think some more on this one and how best to tackle it. Open to ideas ... it's a pickle if giving the user direct access to the HTML is going to be kept as a feature.

Bumps certifi from 2021.10.8 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

• Add service status checks
  • Disabled by default, can be turned on per service
  • Dog-ear on each service indicates status (green = up / red = down / blue = check in progress)
• Add support for user-defined drop-down menus in header
• Add sunrise/sunset to weather widget
• Periodically (every ~5m) update current weather info & radar without page refresh
• Fixed bug in refreshing of radar loop

Re: #4

For now at least, going to need to remove user access to the HTML. Custom JS and CSS files are placed in the user volume which the user can edit in order to provide customization of the UI.

This decision wasn't taken super lightly, but basically the upgrade paths for users would be quite difficult without keeping them out of the necessary code for the HTML/CSS/JS.

The way the application previously worked is it copied itself, in its entirety onto the user volume every time the container was started. Once the files were copied into place, it would not overwrite them. This meant that feature enhancements, etc. could not be easily introduced for users, and that in order to upgrade at all -- even if they had made no customizations -- the user would need to delete all the files in the user volume so that updated files could be copied into place.

So for now, at least, the application files will not be copied into the user provided volume. Instead a custom CSS and custom JS file will be placed there that will only ever house the users edits, and thus homed no longer has to worry about overwriting them but can still easily deliver feature enhancements without the user having to delete files each time. This was the best happy medium that I could come up with.

In the future, I'd like to look into modularizing things a bit more and perhaps allow for user provided modules or "widgets" that can be sections on the homepage. That's a big task though, so for now this was the overall best solution I could come up with.

Still TBD(one) --

• [x] Just realized in doing all this I pulled the configuration file out of being controllable by the user ... obviously that needs to be sorted out before merge.

Re: #2

• Stopped user-menu from being collapsed into mobile menu (now it's just a single user menu on all view ports)
• Added toggle to turn dark mode on and off. Toggle is located under user menu.
• Added config option in homed.yaml for enabling dark mode by default. This can be used to prevent it from loading in light mode first then having to switch to dark mode. The config option is dark_mode.
• Added various CSS treatments to support dark mode (background colors, changing weather alert popover, etc)