Homepage not respecting label, latitude, longitude, or units in openmeteo weather widget

[chenichadowitz]

Description

I believe this is a bug in using/passing the options for the widget. When I first load Homepage, it shows the 'click to allow' prompt for getting the current location, even though I've set a latitude and longitude in my widgets.yaml. If I allow it to get my location, the api call in the network tab in my browser shows the following (replaced latitude and longitude retrieved for privacy). Note the object+Object at the end.

.../api/widgets/openmeteo?latitude=xx.xxxxx&longitude=yy.yyyyy&index=4&style=%5Bobject+Object%5D

I believe this is also related to #675

homepage version

v0.8.9 (c89c488, Mar 10, 2024)

Installation method

Docker

Configuration

widgets.yaml

- openmeteo:
  label: Home
  latitude: 50.449684
  longitude: 30.525026
  timezone: America/New_York
  units: imperial
  cache: 5 # Time in minutes to cache API responses, to stay within limits
  format:
    maximumFractionDigits: 1

### Container Logs

_No response_

### Browser Logs

_No response_

### Troubleshooting

n/a

[glime-ai[bot]]

Thanks for posting a discussion about homepage here on GitHub. Homepage now uses a fancy new AI tool thanks to our friends at Glime, so the answer below is the AI bot's attempt to answer your question. If you feel it's sufficient you can mark the answer and close this post, otherwise feel free to leave it open of course!

Thanks for using Homepage! ❤️

---

Based on the information provided, it seems like there might be an issue with how the format option is being handled in the Open-Meteo widget configuration. The style=%5Bobject+Object%5D part of the URL suggests that an object is being passed as a query parameter, which is likely incorrect and should be a string representation of the formatting options instead.

To resolve this issue, please ensure that the format option in your widgets.yaml is correctly specified. If the issue persists even after verifying the configuration, it could be a bug with the widget's handling of the format option.

Since you are using Docker for installation, you can also check the Docker container logs for any error messages that might give more insight into the problem. Use the following command to view the logs:

docker logs <container_name>

Replace <container_name> with the actual name or ID of your Homepage container.

If you continue to experience issues, consider reaching out for support using the 'Ask AI' button on the documentation pages, opening a GitHub discussion, or checking the #ai-support channel on Discord as mentioned in the troubleshooting documentation.

Additionally, you can check for any updates or known issues on the Homepage GitHub repository that might be related to this problem.

This comment was generated by Glime.

[chenichadowitz]

Not bad! Unless I'm missing something, I think there's a bug in how the Open-Meteo widget handles the configuration parameters.

[shamoon]

This would imply the widget essentially does not work, which I do not think is the case. Sometimes formatting gets lost in copy and paste, but for example the formatting of the config above is not correct, I’d start there.

[shamoon]

https://www.diffchecker.com/EEzoZapn/

[chenichadowitz]

Huh, I didn't think the number of spaces would matter since the documentation indicates YAML is used and

Avoid Tabs: Stick to spaces for indentation to avoid parsing errors. 2 spaces are common.

seems to indicate 2 spaces are acceptable (and in fact the YAML validator linked indicates my YAML is valid https://codebeautify.org/yaml-validator/y2434e916).

Thanks for the pointer! Any idea why Homepage doesn't like YAMLs that use 2 space indentation (at least for the root level)?

[chenichadowitz]

Actually it seems to only be an issue at the root level as even the example that works shows an indentation of 2 spaces for the format section. I feel like if 4 spaces is required for the root level, perhaps that should show an error of some sort somehow...

[shamoon]

I believe it just needs to be consistent within the same file. It’s not that your example is invalid, homepage does detect that, it’s that the indentation changes the structure it gets parsed into

[chenichadowitz]

Interesting - I also have a search widget in the same widgets.yaml and I tried changing that to 2 space indentation

- search:
  provider: [google, duckduckgo]
  target: _blank

And this produces an error (I can provide the full error if you'd like):

Something went wrong.
TypeError: Cannot set properties of undefined (setting 'showSearchSuggestions')

But using 2 space indentation for resources doesn't show any error, but just doesn't show any resource widgets.

So, it seems like at least at the root level, widgets require 4 space indentation, and some (like search) throw an error when it isn't, but others just silently fail in some way and fall back to some set of defaults.

[github-actions[bot]]

This discussion has been automatically closed because it was marked as answered. See our contributing guidelines for more details.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.