diff --git a/Gemfile b/Gemfile index e40b8611dad..a86b44a7678 100644 --- a/Gemfile +++ b/Gemfile @@ -10,6 +10,8 @@ group :development do gem 'stringex', '2.8.6' # > 2.1.0 causes slowdowns https://github.com/sass/sassc-ruby/issues/189 gem 'sassc', '2.1.0' + # 1.80.5 breaks the build + gem 'sass-embedded', '1.80.4' gem 'rubocop', '1.67.0' gem 'ruby-lsp', '0.20.1' gem 'rackup', '2.1.0' diff --git a/Gemfile.lock b/Gemfile.lock index 8a29f3d2b18..606ef79e7da 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -178,6 +178,7 @@ DEPENDENCIES rake (= 13.2.1) rubocop (= 1.67.0) ruby-lsp (= 0.20.1) + sass-embedded (= 1.80.4) sass-globbing (= 1.1.5) sassc (= 2.1.0) sinatra (= 4.0.0) diff --git a/source/_integrations/cambridge_audio.markdown b/source/_integrations/cambridge_audio.markdown index 83248f68dd1..c40391323e0 100644 --- a/source/_integrations/cambridge_audio.markdown +++ b/source/_integrations/cambridge_audio.markdown @@ -57,7 +57,8 @@ The integration provides a few entities to configure the device settings. The fo - Display brightness - Pre-Amp -- Early Update +- Early update +- Audio output (Speaker select) ## Playing media diff --git a/source/_integrations/lg_thinq.markdown b/source/_integrations/lg_thinq.markdown index 642f9e69f04..1fac8705476 100644 --- a/source/_integrations/lg_thinq.markdown +++ b/source/_integrations/lg_thinq.markdown @@ -3,7 +3,7 @@ title: LG ThinQ description: Setup for LG ThinQ Integration. ha_category: - Hub -ha_release: "2024.10" +ha_release: "2024.11" ha_iot_class: Cloud Push ha_code_owners: - '@LG-ThinQ-Integration' diff --git a/source/_integrations/music_assistant.markdown b/source/_integrations/music_assistant.markdown new file mode 100644 index 00000000000..548ff4acd27 --- /dev/null +++ b/source/_integrations/music_assistant.markdown @@ -0,0 +1,38 @@ +--- +title: Music Assistant +description: Instructions on how to integrate Music Assistant into Home Assistant. +ha_category: + - Media player +ha_release: 2024.11 +ha_iot_class: Local Push +ha_config_flow: true +ha_codeowners: + - '@music_assistant' +ha_domain: music_assistant +ha_platforms: + - media_player +ha_zeroconf: true +ha_integration_type: integration +--- + +The **Music Assistant**(MA) {% term integrations %} allows you to connect Home Assistant to a [Music Assistant Server](https://music-assistant.io/). Once configured, all [MA Players](https://music-assistant.io/player-support/) show up as Home Assistant [media player entities](/integrations/media_player/). Media players will allow you to control media playback and see the currently playing item. + +There is currently support for the following Home Assistant Platforms: + +- [Media player](#media-player) + +All of the Home Assistant [Media Player Control Actions](https://www.home-assistant.io/integrations/media_player/#media-control-actions) are supported. + +{% include integrations/config_flow.md %} + +### Manual configuration + +Under normal circumstances, Home Assistant automatically discovers your running Music Assistant Server. If something special about the HA or MA setup (for example, the MA server is running as a remote Docker container) or discovery is not working, you can manually specify the URL to your Music Assistant server. + +## Media player + +The Music Assistant media player creates media player entities for all players available in MA including those imported from Home Assistant. This is needed to provide the full functionality Music Assistant has to offer. These entities will display media information, playback progress, and playback controls. + +## Notes + +- Any Home Assistant players added to Music Assistant will appear duplicated as the MA version of the player is created. The original HA player can be hidden if desired. diff --git a/source/_integrations/prometheus.markdown b/source/_integrations/prometheus.markdown index 8fa1bb1287f..9558608a81a 100644 --- a/source/_integrations/prometheus.markdown +++ b/source/_integrations/prometheus.markdown @@ -189,22 +189,27 @@ When looking into the metrics on the Prometheus side, there will be: - All Home Assistant domains, which can be easily found through the common **namespace** prefix, if defined. - The [client library](https://github.com/prometheus/client_python) provided metrics, which are a bunch of **process_\*** and also a single pseudo-metric **python_info** which contains (not as value but as labels) information about the Python version of the client, i.e., the Home Assistant Python interpreter. - + Typically, you will only be interested in the first set of metrics. ## Metrics in unavailable or unknown states -When the Prometheus exporter starts (typically when Home Assistant starts), all non-excluded entities in an unavailable or unknown state are not be exported until they are available again. If the entity goes into state unavailable or unknown again, the value exported will always be the latest known one. +When the Prometheus exporter starts (typically when Home Assistant starts), all non-excluded entities in an unavailable or unknown state are not exported until they are available and known. -While an entity is in those states, the `entity_available` corresponding metric is set to 0. This metric can be used to filter out values while the entity is unavailable or in an unknown state thanks to a [recording rule](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/). +If an available entity goes into state unavailable or unknown, then it will automatically be unexported and return again automatically when available and known. -For example: +{% note %} + +To filter out these stale values, `entity_available` could be used in a query or recording rule. For example: ```yaml - record: "known_temperature_c" expr: "temperature_c unless entity_available == 0" ``` +This use of `unless` (which can be slow to compute) is no longer necessary, but will continue to work. +{% endnote %} + ## Supported metrics Metrics are exported only for the following domains: diff --git a/source/_integrations/reolink.markdown b/source/_integrations/reolink.markdown index 475d3bb204c..ed52d463615 100644 --- a/source/_integrations/reolink.markdown +++ b/source/_integrations/reolink.markdown @@ -76,11 +76,9 @@ Depending on the supported features of the camera, binary sensors are added for: - AI package detection+ - Sleep status -\+ These sensors receive events using 3 methods in order: ONVIF push, ONVIF long polling or fast polling (every 5 seconds). -The latency for receiving the events is the best for ONVIF push and the worst for fast polling, the fastest available method that is detected to work will be used, and slower methods will not be used. +\+ These sensors receive events using the following 4 methods (in order): TCP push, ONVIF push, ONVIF long polling or fast polling (every 5 seconds). +The latency for receiving the events is the best for TCP push and the worst for fast polling, the fastest available method that is detected to work will be used, and slower methods will not be used. For redundancy, these sensors are polled every 60 seconds together with the update of all other entities. -Not all camera models generate ONVIF push events for all event types, some binary sensors might, therefore, only be polled. -For list of Reolink products that support ONVIF see the [Reolink Support Site](https://support.reolink.com/hc/en-us/articles/900000617826). To ensure you have the best latency possible, refer to the [Reducing latency of motion events](#reducing-latency-of-motion-events) section. ## Number entities @@ -400,11 +398,11 @@ Set up the Reolink integration in Home Assistant using the credentials you set i ### Reducing latency of motion events -ONVIF push will result in slightly faster state changes of the binary motion/AI event sensors than ONVIF long polling. -Moreover, ONVIF push is less demanding for the camera than ONVIF long polling or fast polling, resulting in potentially less connection issues. -However, ONVIF push has some additional network configuration requirements: +TCP push and ONVIF push will result in slightly faster state changes of the binary motion/AI event sensors than ONVIF long polling. +Moreover, TCP push and ONVIF push are less demanding for the camera than ONVIF long polling or fast polling, resulting in potentially less connection issues. +TCP push does not have any particular requirements. However, ONVIF push has some additional network configuration requirements: -- Reolink products can not push motion events to an HTTPS address (SSL). +- Reolink products can not push ONVIF motion events to an HTTPS address (SSL). Therefore, make sure a (local) HTTP address at which HA is reachable is configured under **Home Assistant URL** in the {% my network title="network settings" %}. A valid address could, for example, be `http://192.168.1.10:8123` where `192.168.1.10` is the IP of the Home Assistant device. @@ -412,4 +410,4 @@ A valid address could, for example, be `http://192.168.1.10:8123` where `192.168 Therefore, ensure no Global SSL certificate is configured in the [`configuration.yaml` under HTTP](/integrations/http/#ssl_certificate). An SSL certificate can still be enforced for external connections, by, for instance, using the [NGINX add-on](https://github.com/home-assistant/addons/tree/master/nginx_proxy) or [NGINX Proxy Manager add-on](https://github.com/hassio-addons/addon-nginx-proxy-manager) instead of a globally enforced SSL certificate. -To see if a Reolink integration is currently using `ONVIF push`, `ONVIF long polling` or `Fast polling`, [download the diagnostics text file](/docs/configuration/troubleshooting/#download-diagnostics) and find the `"event connection": "ONVIF push"\"ONVIF long polling"\"Fast polling"` in the txt file. +To see if a Reolink integration is currently using `TCP push`, `ONVIF push`, `ONVIF long polling` or `Fast polling`, [download the diagnostics text file](/docs/configuration/troubleshooting/#download-diagnostics) and find the `"event connection": "TCP push"\"ONVIF push"\"ONVIF long polling"\"Fast polling"` in the txt file. diff --git a/source/_integrations/spotify.markdown b/source/_integrations/spotify.markdown index 76a81b2ef63..af686b8ea09 100644 --- a/source/_integrations/spotify.markdown +++ b/source/_integrations/spotify.markdown @@ -154,3 +154,19 @@ The `media_content_id` value can be obtained from the Spotify desktop app by cli ## Unsupported devices - **Sonos**: Although Sonos is a Spotify Connect device, it is not supported by the official Spotify API. + +## Sensors + +Spotify provides sensors that display information about the song that is currently being played. The following sensors are available: + +- **Song acousticness**: Indicates how much the sound is free from electronic modification. 100% indicates it not electronically modified. +- **Song danceability**. In percent. Describes how suitable a track is for dancing based on a combination of musical elements including tempo, rhythm stability, beat strength, and overall regularity. The higher the value, the more danceable. +- **Song energy**. In percent. A measure of intensity and activity. Typically, energetic tracks feel fast, loud, and noisy. For example, death metal has high energy, while a Bach prelude scores low on the scale. Perceptual features contributing to this attribute include dynamic range, perceived loudness, timbre, onset rate, and general entropy. A higher number means more energetic. +- **Song instrumentalness**: In percent. Describes whether a track contains no vocals. “Ooh” and “aah” sounds are treated as instrumental in this context. Rap or spoken word tracks are clearly “vocal”. The higher the value the more instrumental the song is. +- **Song key**: The estimated overall key of the track. If no key was detected, the value is unknown. For example, C sharp or E flat. +- **Song liveness**: In percent. Describes the presence of an audience in the recording. Higher liveness values represent an increased probability that the track was performed live. +- **Song mode**: The modality (major or minor) of a song. +- **Song speechiness**: In percent. Describes the presence of spoken words in a song. The more exclusively speech-like the recording (for example, talk show, audio book, poetry), the higher the value. +- **Song tempo**: The speed of the piece of music that is currently playing, in beats per minute (bpm). +- **Song time signature**: The time signature (meter) is a notational convention to specify how many beats are in each bar (or measure). For example: 4/4, 6/8. +- **Song valence**. In percent. Tracks with high valence sound more positive (happy, cheerful, euphoric), while tracks with low valence sound more negative (sad, depressed, angry). \ No newline at end of file diff --git a/source/_integrations/switchbot_cloud.markdown b/source/_integrations/switchbot_cloud.markdown index 9f4a1186a1b..bd5015944e5 100644 --- a/source/_integrations/switchbot_cloud.markdown +++ b/source/_integrations/switchbot_cloud.markdown @@ -6,6 +6,7 @@ ha_category: - Plug - Remote - Sensor + - Lock - Switch - Vacuum ha_release: '2023.10' @@ -42,6 +43,7 @@ Please note, device names configured in the SwitchBot app are transferred into H - IR appliances exposed through the different hubs: - ON/OFF for all appliance types excepted "Others" - Air Conditioner +- Lock - Meter - MeterPlus - Outdoor Meter