Fix issue with duplicate device_addresses over multiple backends

README.md

@@ -223,7 +223,7 @@ sysvar_scan_interval:
   description:
     Interval in seconds between system variable/program scans. The minimum value is 5.
     Intervals of less than 15s are not recommended, and put a lot of strain on slow backend systems in particular.
-    Instead, a higher interval with an on-demand call from the `homematicip_local.fetch_system_variables` service is recommended.
+    Instead, a higher interval with an on-demand call from the `homematicip_local.fetch_system_variables` action is recommended.
   type: integer
   default: 30
 enable_system_notifications:
@@ -267,7 +267,7 @@ These two options are required for _special_ network environments. If for exampl
 
 ## System variables
 
-System variables are fetched every 30 seconds from backend (CCU/Homegear) and belong to a device of type CCU. You could also click on service on the integration's overview in HA.
+System 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.
 
 System variables are initially created as **[deactivated](https://github.com/danielperna84/custom_homematic#deactivated-entities)** entity.
 
@@ -300,13 +300,13 @@ When using Homegear system variables are handled like the DEFAULT.
 Using `select`, `number`, `switch` and `text` results in the following advantages:
 
 - System variables can be changed directly in the UI without additional logic.
-- The general services for `select`, `number`, `switch` and `text` can be used.
-- The service `homematicip_local.set_variable_value` can, but no longer has to, be used to write system variables.
+- The general actions for `select`, `number`, `switch` and `text` can be used.
+- The action `homematicip_local.set_variable_value` can, but no longer has to, be used to write system variables.
 - Use of device based automations (actions) is possible.
 
-## Services
+## Actions
 
-The Homematic(IP) Local integration makes various custom services available.
+The Homematic(IP) Local integration makes various custom actions available.
 
 ### `homematicip_local.clear_cache`
 
@@ -336,13 +336,13 @@ This data can be used by the developers to add customized entities for new devic
 
 ### `homematicip_local.fetch_system_variables`
 
-Service to fetch system variables on demand from backend independent from default 30s schedule.
-Using this service too often could have a negative effect on the stability of your backend.
+action to fetch system variables on demand from backend independent from default 30s schedule.
+Using this action too often could have a negative effect on the stability of your backend.
 
 ### `homematicip_local.force_device_availability`
 
 Reactivate a device in Home Assistant that has been made unavailable by an UNREACH event from CCU.
-This service 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!
+This 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!
 
 This is not a solution for communication problems with homematic devices.
 Use this only to reactivate devices with flaky communication to gain control again.
@@ -366,6 +366,10 @@ Returns a paramset
 Call to `getParamset` for direct connections on the XML-RPC interface.
 Returns a paramset
 
+### `homematicip_local.get_schedule_profile_weekday`
+
+Returns the schedule of a climate profile for a certain weekday.
+
 ### `homematicip_local.put_paramset`
 
 Call to `putParamset` on the XML-RPC interface.
@@ -386,6 +390,27 @@ Set a device parameter via the XML-RPC interface. Preferred when using the UI. W
 
 Turn on the install mode on the provided Interface to pair new devices.
 
+### `homematicip_local.set_schedule_profile_weekday` (experimental)
+
+Sends the schedule of a climate profile for a certain weekday to a device.
+
+See the [sample](#sample-for-set_schedule_profile_weekday) below
+
+__Disclaimer: To much writing to the device could kill your device's eeprom.__
+
+Remarks:
+- Not all devices support schedules. This is currently only supported by this integration for HmIP devices.
+- Not all devices support six profiles.
+- There is currently no matching UI component or entity component in HA.
+
+Relevant rules for modifying a schedule:
+- The content of `weekday_data` looks identically to the [sample](#sample-for-set_schedule_profile_weekday) below. Only the values should be changed.
+- All slots (1-13) must be included.
+- The temperature must be in the defined temperature range of the device.
+- The time of a slot is defined in minutes from midnight.
+- The slot is defined by the end time. The start time is the end time of the previous slot or 0.
+- 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.set_schedule_profile_weekday` this might not be the case, but must be fixed before sending.
+
 ### `homematicip_local.set_variable_value`
 
 Set the value of a variable on your HomeMatic hub.
@@ -415,9 +440,9 @@ Use 0 to reset the on time.
 
 Update the value of an entity (only required for edge cases). An entity can be updated at most every 60 seconds.
 
-This service 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 service, 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).
+This 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).
 
-Attention: This service 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 service, 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.
+Attention: 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.
 
 ### `homeassistant.update_device_firmware_data`
 
@@ -512,7 +537,7 @@ We try to avoid backend calls if value/state doesn't change:
   if one of these parameter values sent is not identical to its current state.
 - Not covered by this approach:
   - platforms: lock and siren.
-  - services: `stop_cover`, `stop_cover_tilt`, `enable_away_mode_*`, `disable_away_mode`, `set_on_time_value`
+  - actions: `stop_cover`, `stop_cover_tilt`, `enable_away_mode_*`, `disable_away_mode`, `set_on_time_value`
   - system variables
 
 ### Rename of device/channel in CCU not reflected in Home Assistant
@@ -556,10 +581,10 @@ If you need the `LEVEL` parameter as number entity, then this can be done by usi
 
 ### Pressing buttons via automation
 
-It 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` service. In YAML-mode the service call to press button `3` on a CCU could look like this:
+It 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:
 
 ```yaml
-service: homematicip_local.set_device_value
+action: homematicip_local.set_device_value
 data:
   device_id: abcdefg...
   parameter: PRESS_SHORT
@@ -583,7 +608,7 @@ To receive button-press events for Homematic(IP) devices like WRC2 / WRC6 (wall
 9. When your channels are working now, you can set the program to "inactive". Don't delete the program!
 
 Hint: To deactivate the event for one channel, remove that channel from the program
-Hint: With RaspberryMatic no program is needed for buttons. Events can directly activated/deactivated within ->Settings->Devices. Click the "+" of e.g. a remote control then click directly the "button-channel". Press "activate". There is no direct feedback but a service message should appear.
+Hint: With RaspberryMatic no program is needed for buttons. Events can directly activated/deactivated within ->Settings->Devices. 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.
 
 ## Updating a device firmware
 
@@ -601,7 +626,7 @@ As soon as the firmware has been successfully transferred to the device, it can
 
 Depending 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.
 
-If shorter update cycles are desired, these can be triggered by the service `homeassistant.update_device_firmware_data`, but this might have a negative impact on you CCU!
+If 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 you CCU!
 
 ## Frequently asked questions
 
@@ -619,71 +644,125 @@ A: Before creating an issue, you should review the HA log files for `error` or `
 
 ## Examples in YAML
 
+
+### Sample for set_variable_value
 Set boolean variable to true:
 
 ```yaml
 ---
-action:
-  service: homematicip_local.set_variable_value
-  data:
-    entity_id: sesnsor.ccu2
-    name: Variablename
-    value: "3"
+action: homematicip_local.set_variable_value
+data:
+  entity_id: sesnsor.ccu2
+  name: Variablename
+  value: "3"
 ```
 
+### Sample for set_device_value
 Manually turn on a switch actor:
 
 ```yaml
 ---
-action:
-  service: homematicip_local.set_device_value
-  data:
-    device_id: abcdefg...
-    channel: 1
-    parameter: STATE
-    value: "true"
-    value_type: boolean
+action: homematicip_local.set_device_value
+data:
+  device_id: abcdefg...
+  channel: 1
+  parameter: STATE
+  value: "true"
+  value_type: boolean
 ```
 
+### Sample 2 for set_device_value
 Manually set temperature on thermostat:
 
 ```yaml
 ---
-action:
-  service: homematicip_local.set_device_value
-  data:
-    device_id: abcdefg...
-    channel: 4
-    parameter: SET_TEMPERATURE
-    value: "23.0"
-    value_type: double
+action: homematicip_local.set_device_value
+data:
+  device_id: abcdefg...
+  channel: 4
+  parameter: SET_TEMPERATURE
+  value: "23.0"
+  value_type: double
 ```
 
+### Sample for set_schedule_profile_weekday
+Send a climate profile for a certain weekday to the device:
+
+```yaml
+---
+action: homematicip_local.set_schedule_profile_weekday
+target:
+  entity_id: climate.heizkorperthermostat_db
+data:
+  profile: P3
+  weekday: SUNDAY
+  weekday_data:
+    "1":
+      ENDTIME: 600
+      TEMPERATURE: 20
+    "2":
+      ENDTIME: 1000
+      TEMPERATURE: 17
+    "3":
+      ENDTIME: 1440
+      TEMPERATURE: 20
+    "4":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "5":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "6":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "7":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "8":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "9":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "10":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "11":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "12":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+    "13":
+      ENDTIME: 1440
+      TEMPERATURE: 17
+```
+
+### Sample for put_paramset
 Set the week program of a wall thermostat:
 
 ```yaml
 ---
-action:
-  service: homematicip_local.put_paramset
-  data:
-    device_id: abcdefg...
-    paramset_key: MASTER
-    paramset:
-      WEEK_PROGRAM_POINTER: 1
+action: homematicip_local.put_paramset
+data:
+  device_id: abcdefg...
+  paramset_key: MASTER
+  paramset:
+    WEEK_PROGRAM_POINTER: 1
 ```
 
+### Sample 2 for put_paramset
 Set the week program of a wall thermostat with explicit `rx_mode` (BidCos-RF only):
 
 ```yaml
 ---
-action:
-  service: homematicip_local.put_paramset
-  data:
-    device_id: abcdefg...
-    paramset_key: MASTER
-    rx_mode: WAKEUP
-    paramset:
-      WEEK_PROGRAM_POINTER: 1
+action: homematicip_local.put_paramset
+data:
+  device_id: abcdefg...
+  paramset_key: MASTER
+  rx_mode: WAKEUP
+  paramset:
+    WEEK_PROGRAM_POINTER: 1
 ```
 
 BidCos-RF devices have an optional parameter for put_paramset which defines the way the configuration data is sent to the device.

changelog.md

@@ -17,8 +17,10 @@
 - Add action to fetch climate device schedule
 - Add action to store climate device schedule (experimental)
 - Add option to config flow/advanced to listen on all ip addresses
+- Fix issue with duplicate device addresses over multiple backends
 - Raise HomeAssistantError on service exception
 - Remove periodic master entity update
+- Rename service to action in README.md
 
 # Version 1.66.0 (2024-09-21)
 

custom_components/homematicip_local/services.py

@@ -721,6 +721,8 @@ def _asnyc_get_hm_device_by_id(hass: HomeAssistant, device_id: str) -> HmDevice
         return None
     device_address, interface_id = data
     for control_unit in _async_get_control_units(hass=hass):
-        if hm_device := control_unit.central.get_device(address=device_address):
+        if control_unit.central.has_client(interface_id=interface_id) and (
+            hm_device := control_unit.central.get_device(address=device_address)
+        ):
             return hm_device
     return None