Merge branch 'current' into next

Gemfile

@@ -11,7 +11,7 @@ group :development do
   # > 2.1.0 causes slowdowns https://github.com/sass/sassc-ruby/issues/189
   gem 'sassc', '2.1.0'
   gem 'rubocop', '1.66.1'
-  gem 'ruby-lsp', '0.18.2'
+  gem 'ruby-lsp', '0.18.3'
   gem 'rackup', '2.1.0'
 end
 

Gemfile.lock

@@ -125,7 +125,7 @@ GEM
       unicode-display_width (>= 2.4.0, < 3.0)
     rubocop-ast (1.32.3)
       parser (>= 3.3.1.0)
-    ruby-lsp (0.18.2)
+    ruby-lsp (0.18.3)
       language_server-protocol (~> 3.17.0)
       prism (~> 1.0)
       rbs (>= 3, < 4)
@@ -177,7 +177,7 @@ DEPENDENCIES
   rackup (= 2.1.0)
   rake (= 13.2.1)
   rubocop (= 1.66.1)
-  ruby-lsp (= 0.18.2)
+  ruby-lsp (= 0.18.3)
   sass-globbing (= 1.1.5)
   sassc (= 2.1.0)
   sinatra (= 4.0.0)

sass/homeassistant/base/_global.scss

@@ -12,7 +12,7 @@ body, html {
 
 .page-content {
   display: inline-block;
-  height: 100%;
+  min-height: 100%;
   margin-top: 0;
   padding-top: 88px;
   width: 100%;

source/_integrations/jvc_projector.markdown

@@ -22,7 +22,17 @@ The JVC Projector integration allows for the automation of [JVC Projectors](http
 
 ## Supported models
 
-This integration is intended for the automation of any modern JVC Projector with a LAN network port.
+This integration is intended for the automation of any modern JVC Projector with a network port.
+
+## Prerequisites
+
+JVC is requiring newer 2024+ models to use a user-generated password to access the network port for security reasons.
+
+To set up these models:
+
+1. Set a password on the projector's network setup page.
+2. Use this password when adding the JVC Projector integration in Home Assistant.
+
 
 {% include integrations/config_flow.md %}
 

source/_integrations/knx.markdown

@@ -348,6 +348,33 @@ response:
   default: false
 {% endconfiguration %}
 
+{% raw %}
+
+```yaml
+# Example script to send a fixed value and the state of an entity
+alias: My Script
+sequence:
+  - action: knx.send
+    data:
+      address: 1/1/1
+      type: percent
+      payload: 50
+      response: false
+  - action: knx.send
+    data:
+      address: 1/1/1
+      payload: [128]  # 50 % as 1-byte raw value
+      response: false
+  - action: knx.send
+    data:
+      address: 3/3/3
+      type: temperature
+      payload: "{{ states('sensor.dew_point') }}"
+      response: false
+```
+
+{% endraw %}
+
 ### Read
 
 You can use the `homeassistant.update_entity` action call to issue GroupValueRead requests for all `*state_address` of an entity.
@@ -1264,15 +1291,10 @@ The KNX light integration is used as an interface to control KNX actuators for l
 - LED controllers
 - DALI gateways
 
-To use your KNX light in your installation, add the following lines to your top level [KNX Integration](/integrations/knx) configuration key in `configuration.yaml`:
+Light entities can be created from the frontend in the KNX panel or via YAML.
 
-```yaml
-# Example configuration.yaml entry
-knx:
-  light:
-    - name: "Kitchen"
-      address: "1/0/9"
-```
+<a name="configuration-light-yaml"></a>
+{% details "Configuration of KNX light entities via YAML" %}
 
 {% configuration %}
 address:
@@ -1405,11 +1427,9 @@ entity_category:
 
 Many KNX devices can change their state internally without a message to the switch address on the KNX bus, e.g., if you configure a scene or a timer on a channel. The optional `state_address` can be used to inform Home Assistant about these state changes. If a KNX message is seen on the bus addressed to the given `state_address` (in most cases from the light actuator), it will overwrite the state of the object.
 
-For switching/light actuators that are only controlled by a single group address and don't have dedicated state group objects you can set `state_address` to the same value as `address`.
+For switching/light actuators that are only controlled by a single group address and don't have dedicated state group objects you can set `state_address` to the same value as `address` if it is readable from the bus.
 
-*Note on tunable white:* Home Assistant uses Mireds as the unit for color temperature, whereas KNX typically uses Kelvin. The Kelvin/Mireds relationship is reciprocal, not linear, therefore the color temperature pickers (sliders) in Home Assistant may not align with ones of KNX visualizations. This is the expected behavior.
-
-### Extended configuration examples
+### YAML configuration examples
 
 ```yaml
 knx:
@@ -1495,6 +1515,8 @@ knx:
       state_address: "1/0/5"
 ```
 
+{% enddetails %}
+
 ## Notify
 
 The KNX notify platform allows you to send notifications to [KNX](https://www.knx.org/) devices as DPT16 strings.
@@ -2011,6 +2033,14 @@ knx:
 
 The KNX switch platform is used as an interface to switching actuators.
 
+Switch entities can be created from the frontend in the KNX panel or via YAML.
+
+Switch entities without a `state_address` will restore their last known state after Home Assistant was restarted.
+Switches that have a `state_address` configured request their current state from the KNX bus.
+
+<a name="configuration-switch-yaml"></a>
+{% details "Configuration of KNX switch entities via YAML" %}
+
 ```yaml
 knx:
   switch:
@@ -2055,8 +2085,7 @@ device_class:
 
 The optional `state_address` can be used to inform Home Assistant about state changes not triggered by a telegram to the `address` e.g., if you configure a timer on a channel. If a KNX message is seen on the bus addressed to the given state address, this will overwrite the state of the switch object.
 
-Switch entities without a `state_address` will restore their last known state after Home Assistant was restarted.
-Switches that have a `state_address` configured request their current state from the KNX bus.
+{% enddetails %}
 
 ## Text
 

source/_integrations/rest.markdown

@@ -128,21 +128,21 @@ payload:
   required: false
   type: string
 payload_template:
-  description: The payload to send with a POST request with template support. Depends on the service, but usually formed as JSON.
+  description: The payload to send with a POST request, with template support. Depends on the service, but usually formed as JSON.
   required: false
   type: template
 verify_ssl:
-  description: Verify the SSL certificate of the endpoint.
+  description: Whether to verify the SSL certificate of the endpoint.
   required: false
   type: boolean
   default: True
 ssl_cipher_list:
-  description: Define the list of SSL ciphers to be accepted from this endpoint. `python_default` (_default_), `modern` or `intermediate` (_inspired by [Mozilla Security/Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)_).
+  description: The list of SSL ciphers to be accepted from this endpoint. `python_default` (_default_), `modern` or `intermediate` (_inspired by [Mozilla Security/Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)_).
   required: false
   type: string
   default: default
 timeout:
-  description: Defines max time to wait data from the endpoint.
+  description: The maximum time in seconds to wait for data from the endpoint. If the timeout is reached, the sensor will become `unavailable`.
   required: false
   type: integer
   default: 10
@@ -167,7 +167,7 @@ params:
   required: false
   type: [list, template]
 scan_interval:
-  description: Define the refrequency to call the REST endpoint in seconds.
+  description: The frequency in seconds to call the REST endpoint.
   required: false
   type: integer
   default: 30

source/_integrations/template.markdown

@@ -156,7 +156,7 @@ sensor:
       type: string
       default: None
     state_class:
-      description: "The [state_class](https://developers.home-assistant.io/docs/core/entity/sensor#available-state-classes) of the sensor. This will also display the value based on the user profile Number Format setting and influence the graphical presentation in the history visualization as a continuous value."
+      description: "The [state_class](https://developers.home-assistant.io/docs/core/entity/sensor#available-state-classes) of the sensor. This will also display the value based on the user profile Number Format setting and influence the graphical presentation in the history visualization as a continuous value. If you desire to include the sensor in long-term statistics, include this key and assign it the appropriate value"
       required: false
       type: string
       default: None

source/_integrations/threshold.markdown

@@ -76,6 +76,24 @@ name:
   default: Threshold
 {% endconfiguration %}
 
+## Matrix of state change behavior
+
+### Sensor value rising
+
+| Set           | Turns on when           | Turns off when          |
+| ------------- | ----------------------- | ----------------------- |
+| only upper    | sensor > (upper + hyst) | never                   |
+| only lower    | never                   | sensor > (lower + hyst) |
+| upper & lower | sensor > (lower + hyst) | sensor > (upper + hyst) |
+
+### Sensor value falling
+
+| Set           | Turns on when           | Turns off when          |
+| ------------- | ----------------------- | ----------------------- |
+| only upper    | never                   | sensor < (upper - hyst) |
+| only lower    | sensor < (lower - hyst) | never                   |
+| upper & lower | sensor < (upper - hyst) | sensor < (lower - hyst) |
+
 ## Examples
 
 ### Is the temperature rising or falling

source/_integrations/zha.markdown

@@ -104,8 +104,6 @@ Some other Zigbee coordinator hardware may not support a firmware that is capabl
   - [XZG - Universal Firmware for Zigbee Gateway](https://xzg.xyzroe.cc/)
 - dresden elektronik deCONZ based Zigbee radios (via the [zigpy-deconz](https://github.com/zigpy/zigpy-deconz) library for zigpy)
   - [ConBee III (a.k.a. ConBee 3) USB adapter from dresden elektronik](https://phoscon.de/conbee3)
-  - [ConBee II (a.k.a. ConBee 2) USB adapter from dresden elektronik](https://phoscon.de/conbee2)
-  - [RaspBee II (a.k.a. RaspBee 2) Raspberry Pi Shield from dresden elektronik](https://phoscon.de/raspbee2)
 
 ### Other supported but not recommended Zigbee radio adapters or modules
 
@@ -120,6 +118,8 @@ Some other Zigbee coordinator hardware may not support a firmware that is capabl
   - [CC2538 USB stick, module, or dev board hardware flashed with Z-Stack coordinator firmware](https://www.zigbee2mqtt.io/information/supported_adapters) (no longer recommended as only got deprecated old end-of-life firmware)
   - [CC2530/CC2531 USB stick, module, or dev board hardware flashed with Z-Stack coordinator firmware](https://www.zigbee2mqtt.io/information/supported_adapters) (no longer recommended as uses deprecated hardware and very old end-of-life firmware, plus will not work properly at all if the whole Zigbee network has more than 15-20 devices)
 - dresden elektronik deCONZ based Zigbee radios using legacy hardware (via the [zigpy-deconz](https://github.com/zigpy/zigpy-deconz) library for zigpy)
+  - [ConBee II (a.k.a. ConBee 2) USB adapter from dresden elektronik](https://phoscon.de/conbee2)
+  - [RaspBee II (a.k.a. RaspBee 2) Raspberry Pi Shield from dresden elektronik](https://phoscon.de/raspbee2)
   - [ConBee USB adapter from dresden elektronik](https://phoscon.de/conbee)
   - [RaspBee Raspberry Pi Shield from dresden elektronik](https://phoscon.de/raspbee)
 - Digi XBee Zigbee based radios (via the [zigpy-xbee](https://github.com/zigpy/zigpy-xbee) library for zigpy)

source/_posts/2024-09-24-we-are-joining-the-z-wave-alliance-board.markdown

@@ -0,0 +1,29 @@
+---
+layout: post
+title: "We are joining the Z-Wave Alliance Board"
+description: "We will help represent Home Assistant users and the Open Home Foundation values on this board, defining the future of Z-Wave."
+date: 2024-09-24 00:00:01
+date_formatted: "September 24, 2024"
+author: Paulus Schoutsen
+comments: true
+categories: Announcements
+og_image: /images/blog/2024-09-zwave-board/art.jpg
+---
+
+<img src='/images/blog/2024-09-zwave-board/art.jpg' style='border: 0;box-shadow: none;' alt="Paulus Schoutsen is joining the Z-Wave Alliance Board">
+
+Today there has been an important announcement, I (Paulus, founder of Home Assistant) will be taking a seat on the Z-Wave Alliance Board of Directors, representing Nabu Casa. This is a significant piece of recognition for the work we have put into our support of open standards, and the importance of open source projects in keeping standards successful and thriving.
+
+Being part of this board allows us to play a bigger role in shaping Z-Wave's future. As a [Standards Development Organization (SDO)](https://z-wavealliance.org/z-wave-alliance-formalizes-standards-development-organization-and-announces-founding-members/) the Alliance is shaped by its members, and they brought us in for our connection to our community and expertise in open source. We will be giving a voice to Home Assistant users, open source development, and Open Home Foundation values.
+
+<!--more-->
+
+A tenth of households with Home Assistant are using Z-Wave today, accounting for an estimated 1.7 million Z-Wave devices. We've seen a growing interest in Z-Wave in the Home Assistant community. This is why we have been driving forward the development of the open source [Z-Wave JS](https://github.com/zwave-js) stack, while also developing our own [Z-Wave connectivity hardware](https://www.home-assistant.io/blog/2024/05/08/zwave-is-not-dead/#range-testing-our-z-wave-stick-prototype).
+
+As you might be well aware, we're very keen on open standards and are continuing to put a lot of work into supporting Zigbee, Matter, Thread, and Z-Wave. These standards are important for a number of reasons that align with our [Open Home mission](https://www.openhomefoundation.org/about/).
+
+These standards enable greater choice, giving our users access to decades of smart home devices to add to their homes. These standards are locally controlled and don't rely on the cloud, meaning when devices are connected through Home Assistant they provide privacy out-of-the-box. Finally, there are a lot of these devices already in use in our homes, along with second-hand devices ready for a new home. Keeping a standard alive, keeps these devices alive and using what already exists is always the most sustainable option.
+
+This is not the only example of our work being recognized by these standards organizations. Recently, the Thread Group selected Nabu Casa for an [Innovation Enabler Award](https://www.linkedin.com/posts/thread-group_threadgroup-internetofthings-smarthome-activity-7226619123235971072-8kHn), which is only awarded to two companies a year, and recognizes the "creative potential of [our] ideas and the use of Thread technology".
+
+[We believe in Z-Wave](/blog/2024/05/08/zwave-is-not-dead/) and we will continually push it to align with the Open Home, so it can bring better choice, privacy, and sustainability to the home. If you want to learn more about the Z-Wave Alliance Board, read the [appointment announcement here](https://z-wavealliance.org/news_p/home-assistant-founder-joins-z-wave-alliance-board-of-directors/).