diff --git a/Gemfile b/Gemfile index 534a57a1da9..ea45aad866f 100644 --- a/Gemfile +++ b/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 diff --git a/Gemfile.lock b/Gemfile.lock index 1cea45399dd..14bd16b2d79 100644 --- a/Gemfile.lock +++ b/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) diff --git a/sass/homeassistant/base/_global.scss b/sass/homeassistant/base/_global.scss index 7e65b7d48aa..9b0a0b63d06 100644 --- a/sass/homeassistant/base/_global.scss +++ b/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%; diff --git a/source/_integrations/jvc_projector.markdown b/source/_integrations/jvc_projector.markdown index 15370d3e8f0..9cd1ee2d931 100644 --- a/source/_integrations/jvc_projector.markdown +++ b/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 %} diff --git a/source/_integrations/knx.markdown b/source/_integrations/knx.markdown index 9c9bd288873..7803330654f 100644 --- a/source/_integrations/knx.markdown +++ b/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" -``` + +{% 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. + + +{% 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 diff --git a/source/_integrations/rest.markdown b/source/_integrations/rest.markdown index 1ceb59b5bcc..416253f78a6 100644 --- a/source/_integrations/rest.markdown +++ b/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 diff --git a/source/_integrations/template.markdown b/source/_integrations/template.markdown index 85e077e52ea..b052c69eed8 100644 --- a/source/_integrations/template.markdown +++ b/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 diff --git a/source/_integrations/threshold.markdown b/source/_integrations/threshold.markdown index 10fd2092f39..28d12c9a9b0 100644 --- a/source/_integrations/threshold.markdown +++ b/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 diff --git a/source/_integrations/zha.markdown b/source/_integrations/zha.markdown index 01836a034a5..c1488aa8229 100644 --- a/source/_integrations/zha.markdown +++ b/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) diff --git a/source/_posts/2024-09-24-we-are-joining-the-z-wave-alliance-board.markdown b/source/_posts/2024-09-24-we-are-joining-the-z-wave-alliance-board.markdown new file mode 100644 index 00000000000..086c9dc5e38 --- /dev/null +++ b/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 +--- + +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. + + + +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/). diff --git a/source/images/blog/2024-09-zwave-board/art.jpg b/source/images/blog/2024-09-zwave-board/art.jpg new file mode 100644 index 00000000000..34872a6b76f Binary files /dev/null and b/source/images/blog/2024-09-zwave-board/art.jpg differ