{"id":18340572,"url":"https://github.com/SukramJ/custom_homematic","last_synced_at":"2025-08-13T03:32:35.902Z","repository":{"id":38109692,"uuid":"389120303","full_name":"SukramJ/custom_homematic","owner":"SukramJ","description":"Custom Home Assistant Component for HomeMatic","archived":false,"fork":false,"pushed_at":"2025-08-07T05:15:34.000Z","size":2172,"stargazers_count":478,"open_issues_count":0,"forks_count":39,"subscribers_count":26,"default_branch":"devel","last_synced_at":"2025-08-07T07:09:32.470Z","etag":null,"topics":["ccu","custom-integration","eq-3","home-assistant","homematic","homematicip","raspberrymatic"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/SukramJ.png","metadata":{"files":{"readme":"README.md","changelog":"changelog.md","contributing":".github/CONTRIBUTING.md","funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null},"funding":{"github":"SukramJ","patreon":null,"open_collective":null,"ko_fi":null,"tidelift":null,"community_bridge":null,"liberapay":null,"issuehunt":null,"lfx_crowdfunding":null,"polar":null,"buy_me_a_coffee":null,"thanks_dev":null,"custom":null}},"created_at":"2021-07-24T14:37:18.000Z","updated_at":"2025-08-07T05:15:37.000Z","dependencies_parsed_at":"2023-10-26T06:27:48.966Z","dependency_job_id":"9e0a240c-d183-4517-9d81-0259ca897963","html_url":"https://github.com/SukramJ/custom_homematic","commit_stats":null,"previous_names":["sukramj/custom_homematic","danielperna84/custom_homematic"],"tags_count":519,"template":false,"template_full_name":null,"purl":"pkg:github/SukramJ/custom_homematic","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SukramJ%2Fcustom_homematic","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SukramJ%2Fcustom_homematic/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SukramJ%2Fcustom_homematic/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SukramJ%2Fcustom_homematic/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/SukramJ","download_url":"https://codeload.github.com/SukramJ/custom_homematic/tar.gz/refs/heads/devel","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SukramJ%2Fcustom_homematic/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":270175825,"owners_count":24540093,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-13T02:00:09.904Z","response_time":66,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ccu","custom-integration","eq-3","home-assistant","homematic","homematicip","raspberrymatic"],"created_at":"2024-11-05T20:23:04.981Z","updated_at":"2025-08-13T03:32:35.862Z","avatar_url":"https://github.com/SukramJ.png","language":"Python","funding_links":["https://github.com/sponsors/SukramJ"],"categories":[],"sub_categories":[],"readme":"# Homematic(IP) Local\n[![releasebadge]][release] [![License][license-shield]](LICENSE.md) [![hainstall][hainstallbadge]][hainstall]\n\nHomematic(IP) [Integration for Home Assistant](https://www.home-assistant.io/getting-started/concepts-terminology/#integrations)\n\nQuick start:\n- Installation guide: https://github.com/sukramj/custom_homematic/wiki/Installation\n- Alternative installation by J. Maus (RaspberryMatic): https://github.com/jens-maus/RaspberryMatic/wiki/HomeAssistant-Integration\n- Wiki (additional information): https://github.com/sukramj/hahomematic/wiki\n- Changelog: https://github.com/sukramj/custom_homematic/blob/master/changelog.md\n- License: https://github.com/sukramj/custom_homematic/blob/master/LICENSE\n\nPlease support the community by adding more valuable information to the wiki.\n\n## At a glance\n\n- Local Home Assistant integration for HomeMatic and Homematic IP hubs (CCU2/3, RaspberryMatic, Debmatic, Homegear). No cloud required.\n- Communication: Local XML-RPC for control and push state updates; JSON-RPC for names and rooms.\n- Installation: HACS recommended; manual installation supported.\n- Auto-discovery: Supported for CCU and compatible hubs.\n- Minimum requirements: Home Assistant 2025.8.0+; for Homematic IP on CCU require at least CCU2 2.53.27 / CCU3 3.53.26.\n- Useful links: [Installation guide](https://github.com/sukramj/custom_homematic/wiki/Installation), [Wiki](https://github.com/sukramj/hahomematic/wiki), [Issues](https://github.com/sukramj/hahomematic/issues), [Discussions](https://github.com/sukramj/hahomematic/discussions), [Changelog](https://github.com/sukramj/custom_homematic/blob/master/changelog.md).\n\n## Table of contents\n- [Issues and discussions](#issues-and-discussions)\n- [Documentation](#documentation)\n- [Installation](#installation)\n- [Device support](#device-support)\n- [Requirements](#requirements)\n- [Configuration](#configuration)\n  - [Manual configuration steps](#manual-configuration-steps)\n  - [Auto-discovery](#auto-discovery)\n  - [Configuration Variables](#configuration-variables)\n- [System variables](#system-variables)\n- [Actions](#actions)\n- [Events](#events)\n- [Additional information](#additional-information)\n- [Updating a device firmware](#updating-a-device-firmware)\n- [CUxD, CCU-Jack and MQTT support](#cuxd-ccu-jack-and-mqtt-support)\n- [CUxD and CCU-Jack device support](#cuxd-and-ccu-jack-device-support)\n- [Troubleshooting](#troubleshooting)\n- [Frequently asked questions](#frequently-asked-questions)\n- [Examples in YAML](#examples-in-yaml)\n- [Available Blueprints](#available-blueprints)\n- [Support and Contributing](#support-and-contributing)\n- [License](#license)\n\n## Issues and discussions\n\nPlease report issues in [hahomematic repo](https://github.com/sukramj/hahomematic/issues).\nNew discussions can be started and found in [hahomematic repo](https://github.com/sukramj/hahomematic/discussions).\nFeature requests can be added as a discussion too.\nA good practice is to search in issues and discussions before starting a new one.\n\n## Documentation\n\nThe [HomeMatic](https://www.homematic.com/) integration provides bi-directional communication with your HomeMatic hub (CCU, Homegear etc.).\nIt uses an XML-RPC connection to set values on devices and subscribes to receive events the devices and the CCU emit.\nYou can configure this integration multiple times if you want to integrate multiple HomeMatic hubs into Home Assistant.  \nIf you are using Homegear with paired [Intertechno](https://intertechno.at/) devices, uni-directional communication is possible as well.\n\n**Please take the time to read the entire documentation before asking for help. It will answer the most common questions that come up while working with this integration.**\n\n## Installation\n\nRecommended: HACS\n- In Home Assistant, go to HACS \u003e Integrations \u003e Explore \u0026 Download Repositories.\n- Search for \"Homematic(IP) Local\" and install it.\n- Restart Home Assistant when prompted.\n- If you do not see it, add this repository as a custom repository in HACS (Category: Integration): https://github.com/SukramJ/custom_homematic, then install.\n\nManual installation\n- Copy the directory custom_components/homematicip_local from this repository to your Home Assistant config/custom_components directory.\n- Restart Home Assistant.\n\nAfter installation, proceed with configuration below via the Add Integration flow.\n\n## Device support\n\nHomeMatic and HomematicIP devices are integrated by automatically detecting the available parameters, for which suitable entities will be added to the corresponding device-object within Home Assistant.\nHowever, for more complex devices (thermostats, some cover-devices and more) we perform a custom mapping to better represent the devices features. This is an internal detail you usually don't have to care about.\nIt may become relevant though if new hardware becomes available.\nIn such a case the automatic mode will be active. Therefore f.ex. a new thermostat-model might not include the `climate` entity.\nIn such a case you may report the missing customization in the [hahomematic](https://github.com/sukramj/hahomematic) repository.\nPlease report missing devices **after** you installed the integration and ensured it is missing or faulty.\n\n### Deactivated Entities\n\nA lot of additional entities were initially created _deactivated_ and can be _activated_, if necessary, in the `advanced settings` of the entity.\n\n## Requirements\n\n### Hardware\n\nThis integration can be used with any CCU-compatible HomeMatic hub that exposes the required XML-RPC interface. This includes:\n\n- CCU2/3\n- RaspberryMatic\n- Debmatic\n- Homegear\n- Home Assistant OS / Supervised with a suitable add-on + communication device\n\nDue to a bug in previous versions of the CCU2 / CCU3, this integration requires at least the following version for usage with Homematic IP devices:\n\n- CCU2: 2.53.27\n- CCU3: 3.53.26\n\n### Firewall and required ports\n\nTo allow communication to your HomeMatic hub, a few ports on the hub have to be accessible from your Home Assistant machine. The relevant default ports are:\n\n- BidCosRF (_old_ wireless devices): `2001` / `42001` (with enabled TLS)\n- HomematicIP (wireless and wired): `2010` / `42010` (with enabled TLS)\n- HomeMatic wired (_old_ wired devices): `2000` / `42000` (with enabled TLS)\n- Virtual thermostat groups: `9292` / `49292` (with enabled TLS)\n- JSON-RPC (used to get names and rooms): `80` / `443` (with enabled TLS)\n\nAdvanced setups might consider this:\n\nThis integration starts a local XML-RPC server within HA, which automatically selects a free port or uses the optionally defined callback port.\nThis means that the CCU must be able to start a new connection to the system running HA and to the port. So check the firewall of the system running HA (host/VM) to allow communication from the CCU. This Traffic (state updates) is always unencrypted.\nIf running HA on docker it is recommended to use `network_mode: host`, or specify the callback_host and callback_port parameters (see [Configuration Variables](#configuration-variables)).\n\n### Authentication\n\nThis integration always passes credentials to the HomeMatic hub when connecting.\nFor CCU and descendants (RaspberryMatic, debmatic) it is **recommended** to enable authentication for XML-RPC communication (Settings/Control panel/Security/Authentication). JSON-RPC communication is always authenticated.\n\nThe account used for communication is **required** to have admin privileges on your HomeMatic hub.\nIt is important to note though, that special characters within your credentials may break the possibility to authenticate.\nAllowed characters for a CCU password are: `A-Z`, `a-z`, `0-9` and `.!$():;#-`.\nThe CCU WebUI also supports `ÄäÖöÜüß`, but these characters are not supported by the XML-RPC servers.\n\nIf you are using Homegear and have not set up authentication, please enter dummy-data to complete the configuration flow.\n\n# Configuration\n\nAdding Homematic(IP) Local to your Home Assistant instance can be done via the user interface, by using this My button: [ADD INTEGRATION](https://my.home-assistant.io/redirect/config_flow_start?domain=homematicip_local)\n\n## Manual configuration steps\n\n- Browse to your Home Assistant instance.\n- In the sidebar click on [Configuration](https://my.home-assistant.io/redirect/config)\n- From the configuration menu select: [Integrations](https://my.home-assistant.io/redirect/integrations)\n- In the bottom right, click on the [Add Integration](https://my.home-assistant.io/redirect/config_flow_start?domain=homematicip_local) button.\n- From the list, search and select \"Homematic(IP) Local\".\n- Follow the instructions on screen to complete the setup.\n\n## Auto-discovery\n\nThe integration supports auto-discovery for the CCU and compatible hubs like RaspberryMatic. The Home Assistant User Interface will notify you about the integration being available for setup. It will pre-fill the instance-name and IP address of your Homematic hub. If you have already set up the integration manually, you can either click the _Ignore_ button or re-configure your existing instance to let Home Assistant know the existing instance is the one it has detected. After re-configuring your instance a HA restart is required.\n\nAutodiscovery uses the last 10 digits of your rf-module's serial to uniquely identify your CCU, but there are rare cases where the CCU API and the UPNP-Message contains/returns different values. In these cases, where the auto-discovered instance does not disappear after a HA restart, just click on the _Ignore_ button.\nKnown cases are in combination with the rf-module `HM-MOD-RPI-PCB`.\n\n### Configuration Variables\n\n#### Central\n\n```yaml\ninstance_name:\n  description: Name of the HA instance. Allowed characters are a-z and 0-9.\n    If you want to connect to the same CCU instance from multiple HA installations (or to multiple CCUs) this instance_name must be unique on every HA instance.\n  type: string\nhost:\n  description: Hostname or IP address of your hub.\n  type: string\nusername:\n  description: Case sensitive. Username of a user in admin-role on your hub.\n  type: string\npassword:\n  description: Case sensitive. Password of the admin-user on your hub.\n  type: string\ntls:\n  description:\n    Enable TLS encryption. This will change the default for json_port from 80 to 443.\n    TLS must be enabled, if http to https forwarding is enabled in the CCU.\n    Traffic from CCU to HA (state updates) is always unencrypted.\n  type: boolean\n  default: false\nverify_tls:\n  description: Enable TLS verification.\n  type: boolean\n  default: false\ncallback_host:\n  description: Hostname or IP address for callback-connection (only required in special network conditions).\n  type: string\ncallback_port:\n  description: Port for callback-connection (only required in special network conditions).\n  type: integer\njson_port:\n  description: Port used the access the JSON-RPC API.\n  type: integer\n```\n\n#### Interface\n\nThis page always displays the default values, also when reconfiguring the integration.\n\n```yaml\nhmip_rf_enabled:\n  description: Enable support for HomematicIP (wireless and wired) devices.\n  type: boolean\n  default: false\nhmip_rf_port:\n  description: Port for HomematicIP (wireless and wired).\n  type: integer\n  default: 2010\nbidcos_rf_enabled:\n  description: Enable support for BidCos (HomeMatic wireless) devices.\n  type: boolean\n  default: false\nbidcos_rf_port:\n  description: Port for BidCos (HomeMatic wireless).\n  type: integer\n  default: 2001\nvirtual_devices_enabled:\n  description: Enable support for heating groups.\n  type: boolean\n  default: false\nvirtual_devices_port:\n  description: Port for heating groups.\n  type: integer\n  default: 9292\nvirtual_devices_path:\n  description: Path for heating groups\n  type: string\n  default: /groups\nhs485d_enabled:\n  description: Enable support for HomeMatic wired devices.\n  type: boolean\n  default: false\nhs485d_port:\n  description: Port for HomeMatic wired.\n  type: integer\n  default: 2000\ncuxd_enabled:\n  description: Enable support for CUxD devices.\n  type: boolean\n  default: false\nccujack_enabled:\n  description: Enable support for CCU-Jack devices.\n  type: boolean\n  default: false\n```\n\n#### Advanced (optional)\n\n```yaml\nprogram_markers:\n  description: Comma separated list of markers for system variables to enable fetching. This means that not all programs are retrieved except the internal ones.\n  type: select\nprogram_scan_enabled:\n  description: Enable program scanning.\n  type: boolean\n  default: true\nsysvar_markers:\n  description: Comma separated list of markers for system variables to enable fetching. This means that not all system variables are retrieved except the internal ones.\n  type: select\nsysvar_scan_enabled:\n  description: Enable system program scanning.\n  type: boolean\n  default: true\nsysvar_scan_interval:\n  description:\n    Interval in seconds between system variable/program scans. The minimum value is 5.\n    Intervals of less than 15s are not recommended, and put a lot of strain on slow backend systems in particular.\n    Instead, a higher interval with an on-demand call from the `homematicip_local.fetch_system_variables` action is recommended.\n  type: integer\n  default: 30\nenable_system_notifications:\n  description:\n    Control if system notification should be displayed. Affects CALLBACK and PINGPONG notifications.\n    It's not recommended to disable this option, because this would hide problems on your system.\n    A better option is to solve the communication problems in your environment.\n  type: integer\n  default: true\nlisten_on_all_ip:\n  description:\n    By default the XMLRPC server only listens to the ip address, that is used for the communication to the CCU, because, for security reasons, it's better to only listen on needed ports.\n    This works for most of the installations, but in rare cases, when double virtualization is used (Docker on Windows/Mac), this doesn't work.\n    In those cases it is necessary, that the XMLRPC server listens an all ('0.0.0.0') ip addresses.\n    If you have multiple instances running ensure that all are configured equally.\n  type: bool\n  default: false\nmqtt_enabled:\n  description:\n    Enable support for MQTT to receive events for CUxD and CCU-Jack devices. This also enables events for system variables with 'MQTT' in the description.\n  type: bool\n  default: false\nmqtt_prefix:\n  description:\n    Required, if CCU-Jack uses and MQTT-Bridge\n  type: string\n  default: '' \nun_ignore:\n  # Only visible when reconfiguring the integration\n  description: Add additional datapoints/parameters to your instance. See Unignore device parameters\n  type: select\nenable_sub_devices:\n  description: \n    Creates additional HA (sub) devices for Homematic devices with multiple channels like HmIP-DRSI4 and HmIP-DRDI3.\n    Enabling this has effect on automations that use devices, which must be updated.\n    When disabling this obsolete devices must be deleted manually.\n  type: bool\n  default: false\n```\n\n\n### JSON-RPC Port\n\nThe JSON-RPC Port is used to fetch names and room information from the CCU. The default value is `80`. But if you enable TLS the port `443` will be used. You only have to enter a custom value here if you have set up the JSON-RPC API to be available on a different port.  \nIf you are using Homegear the names are fetched using metadata available via XML-RPC. Hence the JSON-RPC port is irrelevant for Homegear users.\n**To reset the JSON-RPC Port it must be set to 0.**\n\n### callback_host and callback_port\n\nThese two options are required for _special_ network environments. If for example Home Assistant is running within a Docker container and detects its own IP to be within the Docker network, the CCU won't be able to establish the connection to Home Assistant. In this case you have to specify which address and port the CCU should connect to. This may require forwarding connections on the Docker host machine to the relevant container.\n\n**To reset the callback host it must be set to one blank character.**\n**To reset the callback port it must be set to 0.**\n\n## System variables\n\nSystem variables are fetched every 30 seconds from backend (CCU/Homegear) and belong to a device of type CCU. You could also click on action on the integration's overview in HA.\n\nSystem variables are initially created as **[deactivated](https://github.com/sukramj/custom_homematic#deactivated-entities)** entity.\n\nThe types of system variables in the CCU are:\n\n- _character string_ (Zeichenkette)\n- _list of values_ (Werteliste)\n- _number_ (Zahl)\n- _logic value_ (Logikwert)\n- _alert_ (Alarm)\n\nSystem variables have a description that can be added in the CCU's UI.\nIf you add the marker `HAHM` (before 1.76.0 it was `hahm`) to the description extended features for this system variable can be used in HA.\nThis `HAHM` marker is used to control the entity creation in HA.\nSwitching system variables from DEFAULT -\u003e EXTENDED or EXTENDED -\u003e DEFAULT requires a restart of HA or a reload of the integration.\n\nWhen using Homegear system variables are handled like the DEFAULT.\n\n### This is how entities are created from system variables:\n\n- DEFAULT: system variables that do **not** have the **marker** `HAHM` in description:\n  - _character string_, _list of values_, _number_ --\u003e `sensor` entity\n  - _alert_, _logic value_ --\u003e `binary_sensor` entity\n- EXTENDED: system variables that do have the **marker** `HAHM` in description:\n  - _list of values_ --\u003e `select` entity\n  - _number_ --\u003e `number` entity\n  - _alarm_, _logic value_ —\u003e `switch` entity\n  - _character string_ —\u003e `text` entity\n\nUsing `select`, `number`, `switch` and `text` results in the following advantages:\n\n- System variables can be changed directly in the UI without additional logic.\n- The general actions for `select`, `number`, `switch` and `text` can be used.\n- The action `homematicip_local.set_variable_value` can, but no longer has to, be used to write system variables.\n- Use of device based automations (actions) is possible.\n\n### Filtering system variables and programs\n\nBy default all system variables (incl. internals) and all program (excl. internals) are loaded and created as deactivated entity.\nTo get a more customizable result it's possible to select markers in the advanced dialog of the configuration.\n\nThese are the predefined markers that can be used for filtering:\n\n- HAHM : This marker is already used. A `HAHM` (upper case) must be added to the description to enable extended variables. This marker is now also used for filtering.\n- INTERNAL : system variables and programs can be marked as internal with a checkbox. There is no need something to the description.\n- MQTT: This is already used by CCU-Jack. Here an `MQTT` (upper case) must be added to the description.\n- HX : For all other cases you could add `HX` (upper case) to the description, if none of the above cases match.\n\nThese marked system variables and programs are created as activated in HA. The positive side effect is that activated entities can automatically be deleted by the integration.\n\n## Actions\n\nThe Homematic(IP) Local integration makes various custom actions available.\n\n### `homematicip_local.add_link`\n\nCall to `addLink` on the XML-RPC interface.\nCreates a direct connection.\n\n### `homematicip_local.clear_cache`\n\nClears the cache for a central unit from Home Assistant. Requires a restart.\n\n### `homematicip_local.create_central_links`\n\nCreates a central link from a device to the backend. This is required for rf-devices to enable button-press events.\n[See](https://github.com/sukramj/custom_homematic?tab=readme-ov-file#events-for-homematicip-devices)\n\n### `homematicip_local.copy_schedule`\n\n__Disclaimer: Too much writing to the device MASTER paramset could kill your device's storage.__\n\nCopy the schedule of a climate device to another device\n\n### `homematicip_local.copy_schedule_profile`\n\n__Disclaimer: Too much writing to the device MASTER paramset could kill your device's storage.__\n\nCopy the schedule profile of a climate device to another/the same device\n\n### `homematicip_local.disable_away_mode`\n\nDisable the away mode for `climate` devices. This only works with HomematicIP devices.\n\n### `homematicip_local.enable_away_mode_by_calendar`\n\nEnable the away mode immediately or by start date and time (e.g. 2022-09-01 10:00), and specify the end by date and time (e.g. 2022-10-01 10:00). This only works with HomematicIP devices.\n\n### `homematicip_local.enable_away_mode_by_duration`\n\nEnable the away mode immediately, and specify the end time by setting a duration (in hours). This only works with HomematicIP devices.\n\n### `homematicip_local.export_device_definition`\n\nExports a device definition (2 files) to\n\n- 'Your home-assistant config directory'/homematicip_local/export_device_descriptions/{device_type}.json\n- 'Your home-assistant config directory'/homematicip_local/export_paramset_descriptions/{device_type}.json\n\nPlease create a pull request with both files at [pydevccu](https://github.com/sukramj/pydevccu), if the device not exists, to support future development of this component.\nThis data can be used by the developers to add customized entities for new devices.\n\n### `homematicip_local.fetch_system_variables`\n\naction to fetch system variables on demand from backend independent from default 30s schedule.\nUsing this action too often could have a negative effect on the stability of your backend.\n\n### `homematicip_local.force_device_availability`\n\nReactivate a device in Home Assistant that has been made unavailable by an UNREACH event from CCU.\nThis action will only override the availability status of a device and all its dependent entities. There is no communication to the backend to enforce a reactivation!\n\nThis is not a solution for communication problems with homematic devices.\nUse this only to reactivate devices with flaky communication to gain control again.\n\n### `homematicip_local.get_device_value`\n\nGet a device parameter via the XML-RPC interface.\n\n### `homematicip_local.get_link_peers`\n\nCall to `getLinkPeers` on the XML-RPC interface.\nReturns a dict of direct connection partners\n\n### `homematicip_local.get_paramset`\n\nCall to `getParamset` on the XML-RPC interface.\nReturns a paramset\n\n### `homematicip_local.get_link_paramset`\n\nCall to `getParamset` for direct connections on the XML-RPC interface.\nReturns a paramset\n\n### `homematicip_local.get_schedule_profile`\n\nReturns the schedule of a climate profile.\n\n### `homematicip_local.get_schedule_profile_weekday`\n\nReturns the schedule of a climate profile for a certain weekday.\n\n### `homematicip_local.put_paramset`\n\n__Disclaimer: Too much writing to the device MASTER paramset could kill your device's storage.__\n\nCall to `putParamset` on the XML-RPC interface.\n\n### `homematicip_local.put_link_paramset`\n\n__Disclaimer: Too much writing to the device MASTER paramset could kill your device's storage.__\n\nCall to `putParamset` for direct connections on the XML-RPC interface.\n\n### `homematicip_local.remove_central_links`\n\nRemoves a central link from the backend. This is required to disable enable button-press events.\n\n### `homematicip_local.remove_link`\n\nCall to `removeLink` on the XML-RPC interface.\nRemoves a direct connection.\n\n### `homematicip_local.set_cover_combined_position`\n\nMove a blind to a specific position and tilt position.\n\n### `homematicip_local.set_device_value`\n\n__Disclaimer: Too much writing to the device MASTER paramset could kill your device's storage.__\n\nSet a device parameter via the XML-RPC interface. Preferred when using the UI. Works with device selection.\n\n### `homematicip_local.set_schedule_profile`\n\n__Disclaimer: Too much writing to the device could kill your device's storage.__\n\nSends the schedule of a climate profile to a device.\n\nRelevant rules for modifying a schedule:\n- All rules of `homematicip_local.set_schedule_profile_weekday` are relevant\n- The required data structure can be retrieved with `homematicip_local.get_schedule_profile`\n\n### `homematicip_local.set_schedule_profile_weekday`\n\n__Disclaimer: Too much writing to the device could kill your device's storage.__\n\nSends the schedule of a climate profile for a certain weekday to a device.\nSee the [sample](#sample-for-set_schedule_profile_weekday) below\n\nRemarks:\n- Not all devices support schedules. This is currently only supported by this integration for HmIP devices.\n- Not all devices support six profiles.\n- There is currently no matching UI component or entity component in HA.\n\nRelevant rules for modifying a schedule:\n- The content of `weekday_data` looks identically to the [sample](#sample-for-set_schedule_profile_weekday) below. Only the values should be changed.\n- All slots (1-13) must be included.\n- The temperature must be in the defined temperature range of the device.\n- The slot is defined by the end time. The start time is the end time of the previous slot or 0.\n- The time of a slot must be equal or higher then the previous slot, and must be in a range between 0 and 1440. If you have retrieved a schedule with `homematicip_local.get_schedule_profile_weekday` this might not be the case, but must be fixed before sending.\n\n### `homematicip_local.set_schedule_simple_profile`\n\n__Disclaimer: Too much writing to the device could kill your device's storage.__\n\nSends the schedule of a climate profile to a device.\nThis is a simplified version of `homematicip_local.set_schedule_profile` \n\n### `homematicip_local.set_schedule_simple_profile_weekday`\n\n__Disclaimer: Too much writing to the device could kill your device's storage.__\n\nSends the schedule of a climate profile for a certain weekday to a device.\nThis is a simplified version of `homematicip_local.set_schedule_profile_weekday` \n\n### `homematicip_local.get_variable_value`\n\nGet the value variable from your HomeMatic hub.\n\n### `homematicip_local.set_variable_value`\n\nSet the value of a variable on your HomeMatic hub.\n\nValue lists accept the 0-based list position or the value as input.\n\nFor booleans the following values can be used:\n\n- 'true', 'on', '1', 1 -\u003e True\n- 'false', 'off', '0', 0 -\u003e False\n\n### `homematicip_local.turn_on_siren`\n\nTurn siren on. Siren can be disabled by siren.turn_off. Useful helpers for siren can be found [here](https://github.com/sukramj/hahomematic/blob/devel/docs/input_select_helper.md#siren).\n\n### `homematicip_local.light_set_on_time`\n\nSet on time for a light entity. Must be followed by a `light.turn_on`.\nUse 0 to reset the on time.\n\n### `homematicip_local.switch_set_on_time`\n\nSet on time for a switch entity. Must be followed by a `switch.turn_on`.\nUse 0 to reset the on time.\n\n### `homeassistant.update_entity`\n\nUpdate the value of an entity (only required for edge cases). An entity can be updated at most every 60 seconds.\n\nThis action is not needed to update entities in general, because 99,9% of the entities and values are getting updated by this integration automatically. But with this action, you can manually update the value of an entity - **if you really need this in special cases**, e.g. if the value is not updated or not available, because of design gaps or bugs in the backend or device firmware (e.g. rssi-values of some HM-devices).\n\nAttention: This action gets the value for the entity via a 'getValue' from the backend, so the values are updated afterwards from the backend cache (for battery devices) or directly from the device (for non-battery devices). So even with using this action, the values are still not guaranteed for the battery devices and there is a negative impact on the duty cycle of the backend for non-battery devices.\n\n### `homeassistant.update_device_firmware_data`\n\nUpdate the firmware data for all devices. For more information see [updating the firmware](https://github.com/sukramj/custom_homematic#updating-the-firmware)\n\n## Events\n\nEvents fired by this integration that can be consumed by users.\n\n### `homematic.keypress`\n\nThis event type is used when a key is pressed on a device,\nand can be used with device triggers or event entities in automation, so manual event listening is not necessary.\n\nIn this context, the following must also be observed: [Events for Homematic(IP) devices](https://github.com/sukramj/custom_homematic#events-for-homematicip-devices)\n\nThe `PRESS*` parameters are evaluated for this event type in the backend.\n\n### `homematic.device_availability`\n\nThis event type is used when a device is no longer available or is available again,\nand can be used with the blueprint [Support for persistent notifications for unavailable devices](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_persistent_notification.yaml).\n\nThe `UNREACH` parameter is evaluated for this event type in the backend.\n\n### `homematic.device_error`\n\nThis event type is used when a device is in an error state.\nA sample usage is shown in the blueprint [Show device errors](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_show_device_error.yaml).\n\nThe `ERROR*` parameters are evaluated for this event type in the backend.\n\n## Additional information\n\n### How can a device be removed from Home Assistant\n\nGo to the devices page of the integration and select a device. Click the three-dot menu at the button and press Delete.\nThis will only delete the device from Home Assistant and not from the CCU.\n\n### What is the meaning of `Error fetching initial data` / `Fehler beim Abrufen der Anfangsdaten`?\n\nThis integration uses a [REGA script](https://github.com/sukramj/hahomematic/blob/devel/hahomematic/rega_scripts/fetch_all_device_data.fn) to fetch as much data in a single call as possible, to avoid multiple request to get the required initial data.\nIn rare cases the output of the script can be invalid, so a further processing is not possible, and the fallback solution is to fetch all required data with individual calls, that cause a higher duty cycle during the start phase of the integration.\n\nThis problem can be analysed by executing the [REGA script](https://github.com/sukramj/hahomematic/blob/devel/hahomematic/rega_scripts/fetch_all_device_data.fn) in the CCU. The parameter ##interface## (line 17) must be replaced with the interface mention from the poped-up issue. The expected result is a valid json. \nSearch (search for GET_ALL_DEVICE_DATA) within the issue tracker and discussion forum for related items.\n\nPlease don't create an issue, because this is not an issue with the integration. \nUse an existing discussion or start a new one, and attach the result of the executed REGA script.\n\n### What is the meaning of `XmlRPC-Server received no events` / `XmlRPC-Server empfängt keine Ereignisse`?\n\nThis integration does not fetch new updates from the backend, it **receives** state changes and new values for devices from the backend by the XmlRPC server.\n\nTherefore the integration additionally checks for the CCU, if this mechanism works:\n\nRegardless of regular device updates, HA checks the availability of the CCU with a `PING` every **15 seconds**, and expects a `PONG` event as a response on the XMLRPC server.\nThis persistent notification is only displayed in HA if the received PONG events and the device updates are missing for **10 minutes**, but it also disappears again as soon as events are received again.\n\nSo the message means there is a problem in the communication from the backend to HA that was **identified** by the integration but not **caused**.\n\n### What is the meaning of `Pending Pong mismatch on interface` / `Austehende Pong Ereignisse auf Interface`?\n\nOnly relevant for CCU.\n\nAs mentioned above, we send a PING event every 15s to check the connection and expect a corresponding PONG event from the backend.\n\nIf everything is OK the number of send PINGs matches the number of received PONGs.\n\nIf we receive less PONGs that means that there is another HA Instance with the same instance name, that has been started after this instance, that receives all events, which also includes value update of devices.\nAlso a communication or CCU problem could be the cause for this.\n\nIf we receive more PONGs that means that there is another HA Instance with the same instance name, that has been started before this instance, so this instance also receives events from the other instance.\n\nSolution:\nCheck if there are multiple instances of this integration running with the same instance name, and re-add the integration on one HA instance with a different instance name.\n\n### Noteworthy about entity states\n\nThe integration fetches the states of all devices on initially startup and on reconnect from the backend (CCU/Homegear).\nAfterwards, the state updates will be sent by the CCU as events to HA. We don't fetch states, except for system variables, after initial startup.\n\nAfter a restart of the backend (esp. CCU), the backend has initially no state information about its devices. Some devices are actively polled for updates, but many devices, esp. battery driven devices, cannot be polled, so the backend needs to wait for periodic update send by the device.\nThis could take seconds, minutes and in rare cases hours.\n\nThat's why the last state of an entity will be recovered after a HA restart.\nIf you want to know how assured the displayed value is, there is an attribute `value_state` at each entity with the following values:\n\n- `valid` the value was either loaded from the CCU or received via an event\n- `not valid` there is no value. The state of the entity is `unknown`.\n- `restored` the value has been restored from the last saved state after an HA restart\n- `uncertain` the value could not be updated from the CCU after restarting the CCU, and no events were received either.\n\nIf you want to be sure that the state of the entity is as consistent as possible, you should also check the `value_state` attribute for `valid`.\n\n### Sending state changes to backend\n\nWe try to avoid backend calls if value/state doesn't change:\n\n- If an entity (e.g. `switch`) has only **one** parameter that represents its state, then a call to the backend will be made,\n  if the parameter value sent is not identical to the current state.\n- If an entity (e.g. `cover`, `climate`, `light`) has **multiple** parameters that represent its state, then a call to the backend will be made,\n  if one of these parameter values sent is not identical to its current state.\n- Not covered by this approach:\n  - platforms: lock and siren.\n  - actions: `stop_cover`, `stop_cover_tilt`, `enable_away_mode_*`, `disable_away_mode`, `set_on_time_value`\n  - system variables\n\n### Rename of device/channel in CCU not reflected in Home Assistant\n\nOption 1: Just rename entity_id and name in HA\n\nOption 2: Reload the Integration or restart HA, that will reload the names from CCU . This will show the the new entity name, if not changed manually in HA. The entity_id will not change.\n\nOption 3: Delete the device in HA (device details). This deletes the device from all caches, and from entity/device_registry. A reload on the integration, or a restart of HA will recreate the device and entities. The new name will be reflected also in the entity_id.\n\nOption 4: Delete and reinstall the Integration. That will recreate all devices and entities with new names (Should only be used on freshly installs systems)\n\n### How rooms of the CCU are assigned to areas in HA\n\nIt is possible to assign multiple rooms to a channel in the CCU, but HA only allows one area per device.\nAreas are assigned in HA when a single room is assigned to a Homematic device or multiple channels are only assigned to the same room.\nIf a device's channels are assigned to multiple rooms or nothing is set, the area in HA remains empty\n\n### Unignore device parameters\n\nNot all parameters of a HomeMatic or HomematicIP device are created as entity. These parameters are filtered out to provide a better user experience for the majority of the users. If you need more parameters as entities have a look at [this](https://github.com/sukramj/hahomematic/blob/devel/docs/unignore.md) description. Starting with version 1.65.0 this can be configured in the reconfiguration flow under advanced options. You use this at your own risk!!!\n\nBUT remember: Some parameters are already created as entities, but are **[deactivated](https://github.com/sukramj/custom_homematic#deactivated-entities)**.\n\n### Devices with buttons\n\nDevices with buttons (e.g. HM-Sen-MDIR-WM55 and other remote controls) may not be fully visible in the UI. This is intended, as buttons don't have a persistent state. An example: The HM-Sen-MDIR-WM55 motion detector will expose entities for motion detection and brightness (among other entities), but none for the two internal buttons. To use these buttons within automations, you can select the device as the trigger-type, and then select the specific trigger (_Button \"1\" pressed_ etc.).\n\n### Fixing RSSI values\n\nSee this [explanation](https://github.com/sukramj/hahomematic/blob/devel/docs/rssi_fix.md) how the RSSI values are fixed.\n\n### Changing the default platform for some parameters\n\n#### HmIP-eTRv\\* / LEVEL, number to sensor entity\n\nThe `LEVEL` parameter of the HmIP-eTRV can be written, i.e. this parameter is created as a **number** entity and the valve can be moved to any position.\nHowever, this **manual position** is reversed shortly thereafter by the device's internal control logic, causing the valve to return to its original position almost immediately. Since the internal control logic of the device can neither be bypassed nor deactivated, manual control of the valve opening degree is not useful. The `LEVEL` parameter is therefore created as a sensor, and thus also supports long-term statistics.\n\nIf you need the `LEVEL` parameter as number entity, then this can be done by using the [unignore](https://github.com/sukramj/custom_homematic#unignore-device-parameters) feature by adding LEVEL to the file.\n\n### Pressing buttons via automation\n\nIt is possible to press buttons of devices from Home Assistant. A common usecase is to press a virtual button of your CCU, which on the CCU is configured to perform a specific action. For this you can use the `homematicip_local.set_device_value` action. In YAML-mode the action call to press button `3` on a CCU could look like this:\n\n```yaml\naction: homematicip_local.set_device_value\ndata:\n  device_id: abcdefg...\n  parameter: PRESS_SHORT\n  value: \"true\"\n  value_type: boolean\n  channel: 3\n```\n\n### Events for Homematic(IP) devices\n\nTo receive button-press events for Homematic(IP) devices like WRC2 / WRC6 (wall switch) or SPDR (passage sensor) or the KRC4 (key ring remote control) or HM-PBI-4-FM (radio button interface) you have to several options:\n\n#### Option A:\nUse the action [create_central_links](https://github.com/sukramj/custom_homematic?tab=readme-ov-file#homeassistantcreate_central_links).\nA one time execution is required to activate the events.\nTo deactivate the events the action [remove_central_links](https://github.com/sukramj/custom_homematic?tab=readme-ov-file#homeassistantremove_central_links) can be used.\n\n#### Option B:\nWith RaspberryMatic no program is needed for buttons. Events can directly activated/deactivated within -\u003eSettings-\u003eDevices. Click the \"+\" of e.g. a remote control then click directly the \"button-channel\". Press \"activate\". There is no direct feedback but a action message should appear.\n\n#### Option C:\nCreate a program in the CCU:\n\n1. In the menu of your CCU's admin panel go to `Programs and connections` \u003e `Programs \u0026 CCU connection`\n2. Go to `New` in the footer menu\n3. Click the plus icon below `Condition: If...` and press the button `Device selection`\n4. Select one of the device's channels you need (1-2 / 1-6 for WRC2 / WRC6 and 2-3 for SPDR)\n5. Select short or long key press\n6. Repeat Steps 3 - 5 to add all needed channels (the logic AND / OR is irrelevant)\n7. Save the program with the `OK` button\n8. Trigger the program by pressing the button as configured in step 5. Your device might indicate success via a green LED or similar. When you select the device in `Status and control` \u003e `Devices` on the CCU, the `Last Modified` field should no longer be empty\n9. When your channels are working now, you can set the program to \"inactive\". Don't delete the program!\n\nHint: To deactivate the event for one channel, remove that channel from the program\n\n\n## Updating a device firmware\n\nHomematic offers the possibility to update the device firmware. To do this, the firmware file must be uploaded in the CCU. The firmware is then transferred to the devices, which can take several hours or days per device. Update can then be clicked in the CCU and the device will update and reboot.\n\nTo simplify this process, this integration offers update entities per device.\n\nInitially, the firmware file must be uploaded via the CCU. A query of available firmware information from eq3 does not take place. All firmware information used is provided by the local CCU.\n\nSince the CCU does not send any events for firmware updates, the current status of firmware updates is requested via regular queries. Since device updates are usually very rare and the transmission takes a long time, the query is only made every **6 hours**.\n\nIf devices whose firmware is currently being transferred were discovered via the update, their statuses are then queried **every hour**.\n\nAs soon as the firmware has been successfully transferred to the device, it can be updated on the device by clicking on `install`. This information can be delayed up to **1 hour** in HA.\n\nDepending on whether an update command can be transmitted immediately or with a delay, either the updated firmware version is displayed after a short delay, or `in process`/`installing` is displayed again because a command transmission is being waited for. This state is now updated every **5 minutes** until the installation is finished.\n\nIf shorter update cycles are desired, these can be triggered by the action `homeassistant.update_device_firmware_data`, but this might have a negative impact on your CCU!\n\n## CUxD, CCU-Jack and MQTT support\n\nCUxD is not natively supported due to a missing Python library for BinRPC.\nThe implemented solution for CuXD utilises the JSON-RPC-API (with 15s polling) and an optional setup with MQTT (no polling needed!).\n\nTo enable the optional MQTT support the following requirements must be fulfilled:\n- Requires CCU-Jack installed on CCU.\n- Requires HA connected to CCU-Jack's MQTT Broker, and MQTT enabled in this integration. In this case no mqtt prefix must be configured in this integration.\n- Alternative MQTT setup:\n  Requires HA to be connected to an MQTT-Broker (other than CCU-Jack's) and CCU-Jack to use a MQTT-Bridge. Here the mqtt prefix (RemotePrefix) must be potentially configured in the integration.\n\nBesides from receiving events for CUxD and CCU-Jack devices, the MQTT support also enables push events for CCU system variables, if they are correctly setup for CCU-Jack support. This requires `MQTT` as additional marker in the description.\n\nImportant:\n- Please read the [MQTT integration documentation](https://www.home-assistant.io/integrations/mqtt/) to set up MQTT in Home Assistant.\n- Please read the [CCU-Jack documentation](https://github.com/mdzio/ccu-jack/wiki) on how to set up CCU-Jack and an optional [MQTT Bridge](https://github.com/mdzio/ccu-jack/wiki/MQTT-Bridge).\n- Please use an MQTT explorer to ensure there are subscribable topics and that events arrive as expected before opening an issue for this integration.\n\n## CUxD and CCU-Jack device support\n\nCUxD and CCU-Jack use Homematic (IP) device and paramset descriptions to be compatible with the CCU.\nThis fact is also used by this integration to integrate CUxD and CCU-Jack. The integration is basically done for the original devices connected to BidCos-RF/-Wired) and HmIP-(Wired), and only their functionality and behaviour is relevant.\n\nIf the implementation for CUxD or CCU-Jack differs, no further adjustments will be made in this integration!!!\nIn order to adapt the device to your own needs, HA offers extensive options via templates and customization that can be used for this purpose.\nDeviating behavior is acceptable for these devices and does not constitute a fault.\n\n## Troubleshooting\n\nIf the integration does not work as expected, try the following before opening an issue:\n- Review Home Assistant logs for entries related to this integration: homematicip_local and hahomematic. Address any errors or warnings shown.\n- Verify required ports are open and reachable between HA and your hub (CCU/RaspberryMatic/Homegear). See Firewall and required ports above.\n- Ensure the CCU user has admin privileges and that your password only contains supported characters (A-Z, a-z, 0-9 and .!$():;#-).\n- When running HA in Docker, prefer network_mode: host. Otherwise, set callback_host and callback_port in the configuration and allow inbound connections from the CCU to that port.\n- If you run multiple HA instances or connect to multiple CCUs, make instance_name unique per HA instance.\n- For persistent auto-discovery entries after setup, click Ignore or reconfigure the existing instance, then restart HA.\n- After updating CCU firmware or changing interfaces, restart Home Assistant and reload the integration.\n- For CUxD/CCU-Jack, ensure MQTT is set up correctly and verify topics/events with an MQTT Explorer before reporting issues.\n\n## Frequently asked questions\n\nQ: I can see an entity, but it is unavailable.\u003cbr\u003e\nA: Possible reason: the entity is deactivated. Go into the entity configuration and activate the entity.\n\nQ: I'm using a button on a remote control as a trigger in an automation, but the automation doesn't fire after the button is pressed.\u003cbr\u003e\nA: See [Events for Homematic(IP) devices](#events-for-homematicip-devices)\n\nQ: My device is not listed under [Events for Homematic(IP) devices](#events-for-homematicip-devices)\u003cbr\u003e\nA: It doesn't matter. These are just examples. If you can press it, it is a button and events are emitted.\n\nQ: I have a problem with the integration. What can I do?\u003cbr\u003e\nA: Before creating an issue, you should review the HA log files for `error` or `warning` entries related to this integration (`homematicip_local`, `hahomematic`) and read the corresponding messages. You can find further information about some messages in this document.\n\nQ: What is the source of OPERATING_VOLTAGE_LEVEL, APPARENT_TEMPERATURE, DEW_POINT, FROST_POINT, VAPOR_CONCENTRATION\nA: These are parameters/sensors, that are [calculated](https://github.com/SukramJ/hahomematic/blob/devel/docs/calculated_climate_sensors.md) based on existing parameters to add more information to a device.\n\n## Examples in YAML\n\n\n### Sample for set_variable_value\nSet a boolean variable to true:\n\n```yaml\n---\naction: homematicip_local.set_variable_value\ndata:\n  entity_id: sensor.ccu2\n  name: Variable name\n  value: true\n```\n\n### Sample for set_device_value\nManually turn on a switch actor:\n\n```yaml\n---\naction: homematicip_local.set_device_value\ndata:\n  device_id: abcdefg...\n  channel: 1\n  parameter: STATE\n  value: \"true\"\n  value_type: boolean\n```\n\n### Sample 2 for set_device_value\nManually set temperature on thermostat:\n\n```yaml\n---\naction: homematicip_local.set_device_value\ndata:\n  device_id: abcdefg...\n  channel: 4\n  parameter: SET_TEMPERATURE\n  value: \"23.0\"\n  value_type: double\n```\n\n### Sample for set_schedule_profile_weekday\nSend a climate profile for a certain weekday to the device:\n\n```yaml\n---\naction: homematicip_local.set_schedule_profile_weekday\ntarget:\n  entity_id: climate.heizkorperthermostat_db\ndata:\n  profile: P3\n  weekday: MONDAY\n  weekday_data:\n    \"1\":\n      ENDTIME: \"05:00\"\n      TEMPERATURE: 16\n    \"2\":\n      ENDTIME: \"06:00\"\n      TEMPERATURE: 17\n    \"3\":\n      ENDTIME: \"09:00\"\n      TEMPERATURE: 16\n    \"4\":\n      ENDTIME: \"15:00\"\n      TEMPERATURE: 17\n    \"5\":\n      ENDTIME: \"19:00\"\n      TEMPERATURE: 16\n    \"6\":\n      ENDTIME: \"22:00\"\n      TEMPERATURE: 22\n    \"7\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n    \"8\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n    \"9\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n    \"10\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n    \"11\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n    \"12\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n    \"13\":\n      ENDTIME: \"24:00\"\n      TEMPERATURE: 16\n```\n\n### Sample for set_schedule_simple_profile\nSend a simple climate profile to the device:\n\n```yaml\n---\naction: homematicip_local.set_schedule_simple_profile\ntarget:\n  entity_id: climate.heizkorperthermostat_db\ndata:\n  base_temperature: 4.5\n  profile: P1\n  simple_profile_data:\n    MONDAY:\n      - TEMPERATURE: 17\n        STARTTIME: \"05:00\"\n        ENDTIME: \"06:00\"\n      - TEMPERATURE: 22\n        STARTTIME: \"19:00\"\n        ENDTIME: \"22:00\"\n      - TEMPERATURE: 17\n        STARTTIME: \"09:00\"\n        ENDTIME: \"15:00\"\n    TUESDAY:\n      - TEMPERATURE: 17\n        STARTTIME: \"05:00\"\n        ENDTIME: \"06:00\"\n      - TEMPERATURE: 22\n        STARTTIME: \"19:00\"\n        ENDTIME: \"22:00\"\n      - TEMPERATURE: 17\n        STARTTIME: \"09:00\"\n        ENDTIME: \"15:00\"\n```\n\n### Sample for set_schedule_profile_weekday\nSend a climate profile for a certain weekday to the device:\n\n```yaml\n---\naction: homematicip_local.set_schedule_simple_profile_weekday\ntarget:\n  entity_id: climate.heizkorperthermostat_db\ndata:\n  profile: P3\n  weekday: MONDAY\n  base_temperature: 16\n  simple_weekday_list:\n    - TEMPERATURE: 17\n      STARTTIME: \"05:00\"\n      ENDTIME: \"06:00\"\n    - TEMPERATURE: 22\n      STARTTIME: \"19:00\"\n      ENDTIME: \"22:00\"\n    - TEMPERATURE: 17\n      STARTTIME: \"09:00\"\n      ENDTIME: \"15:00\"\n```\n\n### Sample for put_paramset\nSet the week program of a wall thermostat:\n\n```yaml\n---\naction: homematicip_local.put_paramset\ndata:\n  device_id: abcdefg...\n  paramset_key: MASTER\n  paramset:\n    WEEK_PROGRAM_POINTER: 1\n```\n\n### Sample 2 for put_paramset\nSet the week program of a wall thermostat with explicit `rx_mode` (BidCos-RF only):\n\n```yaml\n---\naction: homematicip_local.put_paramset\ndata:\n  device_id: abcdefg...\n  paramset_key: MASTER\n  rx_mode: WAKEUP\n  paramset:\n    WEEK_PROGRAM_POINTER: 1\n```\n\nBidCos-RF devices have an optional parameter for put_paramset which defines the way the configuration data is sent to the device.\n\n`rx_mode` `BURST`, which is the default value, will wake up every device when submitting the configuration data and hence makes all devices use some battery. It is instant, i.e. the data is sent almost immediately.\n\n`rx_mode` `WAKEUP` will send the configuration data only after a device submitted updated values to CCU, which usually happens every 3 minutes. It will not wake up every device and thus saves devices battery.\n\n## Available Blueprints\n\nThe following blueprints can be used to simplify the usage of HomeMatic and HomematicIP device:\n\n- [Support for 2-button Remotes](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local-actions-for-2-button.yaml): Support for two button remote like HmIP-WRC2.\n- [Support for 4-button Key Ring Remote Control](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local-actions-for-key_ring_remote_control.yaml): Support for four button remote like HmIP-KRCA.\n- [Support for 6-button Remotes](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local-actions-for-6-button.yaml): Support for six button remote like HmIP-WRC6.\n- [Support for 8-button Remotes](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local-actions-for-8-button.yaml): Support for eight button remote like HmIP-RC8.\n- [Support for persistent notifications for unavailable devices](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_persistent_notification.yaml): Enable persistent notifications about unavailable devices.\n- [Reactivate device by model](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_reactivate_device_by_model.yaml). Reactivate unavailable devices by device model.\n- [Reactivate every device](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_reactivate_device_full.yaml). Reactivate all unavailable devices. NOT recommended. Usage of `by device type` or `single device` should be preferred.\n- [Reactivate single device](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_reactivate_single_device.yaml) Reactivate a single unavailable device.\n- [Show device errors](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/automation/homematicip_local_show_device_error.yaml) Show all error events emitted by a device. This is an unfiltered blueprint. More filters should be added to the trigger.\n\nFeel free to contribute:\n\n- [Community blueprints](https://github.com/sukramj/custom_homematic/blob/devel/blueprints/community)\n\nI use these blueprints on my own system and share them with you, but I don't want to invest in blueprints for devices that I don't own!\nFeel free to copy, improve, or enhance these blueprints and adapt them to other devices, and if you like, create a PR with a new blueprint.\n\nJust copy these files to \"your ha-config_dir\"/blueprints/automation\n\n\n## Support and Contributing\n\n- Issues: https://github.com/sukramj/hahomematic/issues\n- Discussions: https://github.com/sukramj/hahomematic/discussions\n- Wiki contributions are welcome: https://github.com/sukramj/hahomematic/wiki\n- Pull requests are welcome in this repository. Please open an issue or discussion first if you plan larger changes.\n\n\n[license-shield]: https://img.shields.io/github/license/SukramJ/custom_homematic.svg?style=for-the-badge\n[release]: https://github.com/SukramJ/custom_homematic/releases\n[releasebadge]: https://img.shields.io/github/v/release/SukramJ/custom_homematic?style=for-the-badge\n[hainstall]: https://my.home-assistant.io/redirect/config_flow_start/?domain=homematicip_local\n[hainstallbadge]: https://img.shields.io/badge/dynamic/json?style=for-the-badge\u0026logo=home-assistant\u0026logoColor=ccc\u0026label=usage\u0026suffix=%20installs\u0026cacheSeconds=15600\u0026url=https://analytics.home-assistant.io/custom_integrations.json\u0026query=$.homematicip_local.total\n\n## License\n\nThis project is licensed under the MIT License. See LICENSE for details: https://github.com/sukramj/custom_homematic/blob/master/LICENSE\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FSukramJ%2Fcustom_homematic","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FSukramJ%2Fcustom_homematic","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FSukramJ%2Fcustom_homematic/lists"}