description:Please include output from your [troubleshooting tests](https://gethomepage.dev/more/troubleshooting/#service-widget-errors), if relevant.
description:Please include output from your [troubleshooting tests](https://gethomepage.dev/more/troubleshooting/#service-widget-errors), if relevant.
validations:
validations:
required:true
required:true
- type:markdown
attributes:
value:|
## ⚠️ STOP ⚠️
Before you submit this support request, please ensure you have entered your configuration files and actually followed the steps from the troubleshooting guide linked above, if relevant. The troubleshooting steps often help to solve the problem.
*Pleaseremember that this project is maintained by regular people **just like you**, so if you don't take the time to fill out the requested information, don't expect a reply back.*
@ -52,7 +52,7 @@ Homepage has built-in support for Docker, and can automatically discover and add
## Service Widgets
## Service Widgets
Homepage also has support for over 100 3rd party services, including all popular starr apps, and most popular self-hosted apps. Some examples include: Radarr, Sonarr, Lidarr, Bazarr, Ombi, Tautulli, Plex, Jellyfin, Emby, Transmission, qBittorrent, Deluge, Jackett, NZBGet, SABnzbd, etc. As well as service integrations, Homepage also has a number of information providers, sourcing information from a variety of external 3rdparty APIs. See the [Service](https://gethomepage.dev/widgets/) page for more information.
Homepage also has support for hundreds of 3rd-party services, including all popular \*arr apps, and most popular self-hosted apps. Some examples include: Radarr, Sonarr, Lidarr, Bazarr, Ombi, Tautulli, Plex, Jellyfin, Emby, Transmission, qBittorrent, Deluge, Jackett, NZBGet, SABnzbd, etc. As well as service integrations, Homepage also has a number of information providers, sourcing information from a variety of external 3rd-party APIs. See the [Service](https://gethomepage.dev/widgets/) page for more information.
Information widgets are widgets that provide information about your system or environment and are displayed at the top of the homepage. You can find a list of all available info widgets under the [Info Widgets](../widgets/info/index.md) section.
Info widgets are defined in the widgets.yaml
Each widget has its own configuration options, which are detailed in the widget's documentation.
## Layout
Info widgets are displayed in the order they are defined in the `widgets.yaml` file. You can change the order by moving the widgets around in the file. However, some widgets (weather, search and datetime) are aligned to the right side of the screen which can affect the layout of the widgets.
## Adding A Link
You can add a link to an info widget such as the logo or text widgets by adding an `href` option, for example:
Unless otherwise noted, URLs should not end with a `/` or other API path. Each widget will handle the path on its own.
Each service can have one widget attached to it (often matching the service type, but that's not forced).
In addition to the href of the service, you can also specify the target location in which to open that link. See [Link Target](settings.md#link-target) for more details.
Using Emby as an example, this is how you would attach the Emby service widget.
```yaml
- Emby:
icon: emby.png
href: http://emby.host.or.ip/
description: Movies & TV Shows
widget:
type: emby
url: http://emby.host.or.ip
key: apikeyapikeyapikeyapikeyapikey
```
## Field Visibility
Each widget can optionally provide a list of which fields should be visible via the `fields` widget property. If no fields are specified, then all fields will be displayed. The `fields` property must be a valid YAML array of strings. As an example, here is the entry for Sonarr showing only a couple of fields.
**In all cases a widget will work and display all fields without specifying the `fields` property.**
Each service can have widgets attached to it (often matching the service type, but that's not forced).
In addition to the href of the service, you can also specify the target location in which to open that link. See [Link Target](settings.md#link-target) for more details.
Using Emby as an example, this is how you would attach the Emby service widget.
```yaml
- Emby:
icon: emby.png
href: http://emby.host.or.ip/
description: Movies & TV Shows
widget:
type: emby
url: http://emby.host.or.ip
key: apikeyapikeyapikeyapikeyapikey
```
#### Multiple Widgets
Each service can have multiple widgets attached to it, for example:
```yaml
- Emby:
icon: emby.png
href: http://emby.host.or.ip/
description: Movies & TV Shows
widgets:
- type: emby
url: http://emby.host.or.ip
key: apikeyapikeyapikeyapikeyapikey
- type: uptimekuma
url: http://uptimekuma.host.or.ip:port
slug: statuspageslug
```
#### Field Visibility
Each widget can optionally provide a list of which fields should be visible via the `fields` widget property. If no fields are specified, then all fields will be displayed. The `fields` property must be a valid YAML array of strings. As an example, here is the entry for Sonarr showing only a couple of fields.
**In all cases a widget will work and display all fields without specifying the `fields` property.**
@ -13,6 +13,14 @@ You can customize the title of the page if you'd like.
title: My Awesome Homepage
title: My Awesome Homepage
```
```
## Description
You can customize the description of the page if you'd like.
```yaml
description: A description of my awesome homepage
```
## Start URL
## Start URL
You can customize the start_url as required for installable apps. The default is "/".
You can customize the start_url as required for installable apps. The default is "/".
@ -118,6 +126,22 @@ As an example, this would produce the following layout:
<imgwidth="1260"alt="Screenshot 2022-09-15 at 8 03 57 PM"src="https://user-images.githubusercontent.com/82196/190466646-8ca94505-0fcf-4964-9687-3a6c7cd3144f.png">
<imgwidth="1260"alt="Screenshot 2022-09-15 at 8 03 57 PM"src="https://user-images.githubusercontent.com/82196/190466646-8ca94505-0fcf-4964-9687-3a6c7cd3144f.png">
### Icons-Only Layout
You can also specify the an icon-only layout for bookmarks, either like so:
```yaml
layout:
Media:
iconsOnly: true
```
or globally:
```yaml
bookmarksStyle: icons
```
### Sorting
### Sorting
Service groups and bookmark groups can be mixed in order, **but should use different group names**. If you do not specify any bookmark groups they will all show at the bottom of the page.
Service groups and bookmark groups can be mixed in order, **but should use different group names**. If you do not specify any bookmark groups they will all show at the bottom of the page.
@ -137,6 +161,27 @@ layout:
columns: 3
columns: 3
```
```
### Nested Groups
If your services config has nested groups, you can apply settings to these groups by nesting them in the layout block
and using the same settings. For example
```yaml
layout:
Group A:
style: row
columns: 4
Group C:
style: row
columns: 2
Nested Group A:
style: row
columns: 2
Nested Group B:
style: row
columns: 2
```
### Headers
### Headers
You can hide headers for each section in the layout as well by passing `header` as false, like so:
You can hide headers for each section in the layout as well by passing `header` as false, like so:
@ -348,12 +393,12 @@ This can also be set for individual services. Note setting this at the service l
## Providers
## Providers
The `providers` section allows you to define shared API provider options and secrets. Currently this allows you to define your weather API keys in secret and is also the location of the Longhorn URL and credentials.
The `providers` section allows you to define shared API provider options and secrets.
```yaml
```yaml
providers:
providers:
openweathermap: openweathermapapikey
openweathermap: openweathermapapikey
weatherapi: weatherapiapikey
finnhub: yourfinnhubapikeyhere
longhorn:
longhorn:
url: https://longhorn.example.com
url: https://longhorn.example.com
username: admin
username: admin
@ -363,10 +408,10 @@ providers:
You can then pass `provider` instead of `apiKey` in your widget configuration.
You can then pass `provider` instead of `apiKey` in your widget configuration.
All service widgets work essentially the same, that is, homepage makes a proxied call to an API made available by that service. The majority of the time widgets don't work it is a configuration issue. Of course, sometimes things do break. Some basic steps to try:
All service widgets work essentially the same, that is, homepage makes a proxied call to an API made available by that service. The majority of the time widgets don't work it is a configuration issue. Of course, sometimes things do break. Some basic steps to try:
1. Ensure that you follow the rule mentioned on https://gethomepage.dev/configs/service-widgets/. **Unless otherwise noted, URLs should not end with a / or other API path. Each widget will handle the path on its own.**. This is very important as including a trailing slash can result in an error.
1. **URLs should not end with a / or other API path. Each widget will handle the path on its own.**. Including a trailing slash can result in an error.
2. Verify the homepage installation can connect to the IP address or host you are using for the widget `url`. This is most simply achieved by pinging the server from the homepage machine, in Docker this means _from inside the container_ itself, e.g.:
2. Verify the homepage installation can connect to the IP address or host you are using for the widget `url`. This is most simply achieved by pinging the server from the homepage machine, in Docker this means _from inside the container_ itself, e.g.:
@ -48,7 +48,7 @@ self-hosted / open-source alternative, we ask that any widgets, etc. are develop
## New Feature Guidelines
## New Feature Guidelines
- New features should usually be linked to an existing feature request. The purpose of this requirement is to avoid the addition (and maintenance) of features that might only benefit a small number of users.
- New features should be linked to an existing feature request. The purpose of this requirement is to avoid the addition (and maintenance) of features that might only benefit a small number of users.
- If you have ideas for a larger feature you may want to open a discussion first.
- If you have ideas for a larger feature you may want to open a discussion first.
@ -50,7 +50,7 @@ You can also pass API keys from the widget configuration to the proxy handler, f
### `credentialedProxyHandler`
### `credentialedProxyHandler`
A proxy handler that makes authenticated by setting request headers. Credentials are pulled from the widgets configuration.
A proxy handler that makes authenticated requests by setting request headers. Credentials are pulled from the widgets configuration.
By default the key is passed as an `X-API-Key` header. If you need to pass the key as something else, either add a case to the credentialedProxyHandler or create a new proxy handler.
By default the key is passed as an `X-API-Key` header. If you need to pass the key as something else, either add a case to the credentialedProxyHandler or create a new proxy handler.
@ -19,12 +19,17 @@ Service widgets are used to display the status of a service, often a web service
description: Watch movies and TV shows.
description: Watch movies and TV shows.
server: localhost
server: localhost
container: plex
container: plex
widget:
widgets:
type: tautulli
- type: tautulli
url: http://172.16.1.1:8181
url: http://172.16.1.1:8181
key: aabbccddeeffgghhiijjkkllmmnnoo
key: aabbccddeeffgghhiijjkkllmmnnoo
- type: uptimekuma
url: http://172.16.1.2:8080
slug: aaaaaaabbbbb
```
```
More detail on configuring service widgets can be found in the [Service Widgets Config](../configs/services.md) section.
## Info Widgets
## Info Widgets
Info widgets are used to display information in the header, often about your system or environment. Info widgets are defined your `widgets.yaml` file. Here's an example:
Info widgets are used to display information in the header, often about your system or environment. Info widgets are defined your `widgets.yaml` file. Here's an example:
@ -36,3 +41,5 @@ Info widgets are used to display information in the header, often about your sys
longitude: -117.51
longitude: -117.51
cache: 5
cache: 5
```
```
More detail on configuring info widgets can be found in the [Info Widgets Config](../configs/info-widgets.md) section.
description: Weather API Information Widget Configuration
---
**Note: this widget is considered 'deprecated' since there is no longer a free Weather API tier for new members. See the openmeteo or openweathermap widgets for alternatives.**
The free tier is all that's required, you will need to [register](https://www.weatherapi.com/signup.aspx) and grab your API key.
```yaml
- weatherapi:
label: Kyiv # optional
latitude: 50.449684
longitude: 30.525026
units: metric # or imperial
apiKey: yourweatherapikey
cache: 5 # Time in minutes to cache API responses, to stay within limits
format: # optional, Intl.NumberFormat options
maximumFractionDigits: 1
```
You can optionally not pass a `latitude` and `longitude` and the widget will use your current location (requires a secure context, eg. HTTPS).
@ -7,11 +7,16 @@ Learn more about [Beszel](https://github.com/henrygd/beszel)
The widget has two modes, a single system with detailed info if `systemId` is provided, or an overview of all systems if `systemId` is not provided.
The widget has two modes, a single system with detailed info if `systemId` is provided, or an overview of all systems if `systemId` is not provided.
The `systemID` in the `id` field on the collections page of Beszel.
The `systemID` is the `id` field on the collections page of Beszel under the PocketBase admin panel. You can also use the 'nice name' from the Beszel UI.
Allowed fields for 'overview' mode: `["systems", "up"]`
Allowed fields for 'overview' mode: `["systems", "up"]`
Allowed fields for a single system: `["name", "status", "updated", "cpu", "memory", "disk", "network"]`
Allowed fields for a single system: `["name", "status", "updated", "cpu", "memory", "disk", "network"]`
@ -51,6 +51,8 @@ The metric field in the configuration determines the type of system monitoring d
`process`: Top 5 processes based on CPU usage. Gives an overview of which processes are consuming the most resources.
`process`: Top 5 processes based on CPU usage. Gives an overview of which processes are consuming the most resources.
`containers`: Docker or Kubernetes containers list. Shows up to 5 containers running on the system and their resource usage.
`network:<interface_name>`: Network data usage for the specified interface. Replace `<interface_name>` with the name of your network interface, e.g., `network:enp0s25`, as specified in glances.
`network:<interface_name>`: Network data usage for the specified interface. Replace `<interface_name>` with the name of your network interface, e.g., `network:enp0s25`, as specified in glances.
`sensor:<sensor_id>`: Temperature of the specified sensor, typically used to monitor CPU temperature. Replace `<sensor_id>` with the name of your sensor, e.g., `sensor:Package id 0` as specified in glances.
`sensor:<sensor_id>`: Temperature of the specified sensor, typically used to monitor CPU temperature. Replace `<sensor_id>` with the name of your sensor, e.g., `sensor:Package id 0` as specified in glances.
shamoon
3 weeks ago