Massive increase of DutyCycle in a connected CCU/RaspberryMatic when used in combination with custom_homematic

[jens-maus]

custom_component/hahomematic version (if applicable):
0.36.3

Home Assistant version (if applicable):
core-2022.3.3

CCU version:

• Model (CCU2/3, Raspi3/4, NUC, ProxmoxVE, ...): ProxmoxVE
• OS (Original, RaspberryMatic, debmatic/...): HomeAssistantOS 7.4
• Version:

Problem-relevant configuration:

Do you use tls?
No

Do you use callback?
No

Do you use username and password?
Yes

Which interfaces do you use?
BidCos-RF, homematicIP, homematicIP-Wired

Describe the bug
In case of a restart of HomeAssistant core or the whole HomeAssistantOS, or even in case of an update of the custom_homematicversion the queried CCU/RaspberryMatic instance receives quite a tremendous amount of device / data queries in a way that causes the CCU / RaspberryMatic device to generate real RF traffic so that the DutyCycle of the connected CCU / RaspberryMatic device is raised quite tremendously. Dependent on the actual number of RF devices connected to the CCU / RaspberryMatic device, this could easily result in a DutyCycle of 100% (e.g. here in case of two consecutive restarts of custom_homematic) so that no further RF communication is possible for that CCU / RaspberryMatic device

To Reproduce
Steps to reproduce the behavior:

1. Go to HomeAssistant -> Settings -> Devices -> HACS
2. Click on "..." and select "Reload"
3. Monitor the DutyCycle value on your connected CCU / RaspberryMatic device
4. Notice the substantial increase of DutyCycle while custom_homematic is querying all necessary device information.

Relevant HA log entries

n/a

Expected behavior
custom_homematic should use device query pathes / APIs that won't result in actual RF communication to be forced on the connected CCU / RaspberryMatic device so that the DutyCycle won't be increased at all.

Screenshots
n/a

Additional context
If wanted, I could personally have a look at the actual mechanisms which are currently used to query device information from within hahomematic and/or custom_homematic and then try to work out a solution which won't increase the DutyCycle anymore. However, for this to happen it would be great if someone (@SukramJ ?) could actually point his finger at the actual code passages in hahomematic or custom_homematic which are doing the device queries, so that alternative APIs or access pathes could be considered by me.

[SukramJ]

Ok Jens, let's see where this journey ends.

From my personal experience i cannot confirm this dramatic increase of the RMs duty cycle. My base DC is around 25% and a restart raises this value by 10-20%. I have around 120 devices connected which are in majority HMIP devices.

We use the getValue method to fetch device data. I also tested getParamset to reduce the number of api calls, but that was a major issue with bidcos and virtual devices.

On an initial startup we load all paramset descriptions with getParamsetDescription and cache them in a file, to avoid future api calls on restarts. Also the device descriptions are cached in a file.

Rooms and names are loaded by a call to the json api.

CONFIG_PENDING, ERROR, STICKY_UN_REACH/UN_REACH, UPDATE_PENDING are loaded, if in the paramset_description for every device once (values are cached). Maybe CONFIG_PENDING, ERROR and UPDATE_PENDING could be avoided on initial load.
All other values are loaded, if the HA entity is not disabled.
If a more complex entity like climate uses the parameter temperature, and there is an additional sensor for temperature then this value is also loaded only once.

Please come back, if you need more information.
Thanks for your support.

[SukramJ]

I created a version without CONFIG_PENDING, ERROR and UPDATE_PENDING.
you could test it by replacing
"requirements": ["hahomematic==0.36.3"],
by
"requirements": ["hahomematic==0.37.0b1"],

in the manifest in "HA config folder/custom_components/hahm"

[jens-maus]

From my personal experience i cannot confirm this dramatic increase of the RMs duty cycle. My base DC is around 25% and a restart raises this value by 10-20%. I have around 120 devices connected which are in majority HMIP devices.

Well, in my case I have about 200 devices with a baseline DC of about 30% and a restart of HACS/custom_integration raises the DutyCycle by about 30-35% which IMHO is quite substantial given the fact that other external applications like ioBroker or even Smartphone apps like pocketControl cause a 0% increase of DC due to how they query the current parameters.

We use the getValue method to fetch device data. I also tested getParamset to reduce the number of api calls, but that was a major issue with bidcos and virtual devices.

Well, the question here is really if hahomematic/custom_homematic should really exclusivly rely on xmlrpc communication with the CCU. The point is, that by using getValue() via xmlrpc this could actually be the main reason why there is any rf communication being forced when querying current device parameters. Without having digged into the code of hahomematic or having it compared to the methode ioBroker, etc. uses my guess is that it actually could be better to use e.g. the jsonrpc methods to query for the current values because these methods will then actually use the cached values on the CCU / RaspberryMatic rather than freshly querying them from the RF devices simply because you are asking for them using xmlrpc. But as said: haven't digged through the code yet, thus this is just my feeling here and comparing the negative effects seen in using hahomematic compared to ioBroker or other external apps querying for device parameters/values on a CCU / RaspberryMatic.

On an initial startup we load all paramset descriptions with getParamsetDescription and cache them in a file, to avoid future api calls on restarts. Also the device descriptions are cached in a file.

Rooms and names are loaded by a call to the json api.

Why don't you also try to load the current values and the paramset descriptions using the json api? As said, this should then allow to use the internally cached values rather than freshly querying them from the rf devices.

CONFIG_PENDING, ERROR, STICKY_UN_REACH/UN_REACH, UPDATE_PENDING are loaded, if in the paramset_description for every device once (values are cached). Maybe CONFIG_PENDING, ERROR and UPDATE_PENDING could be avoided on initial load. All other values are loaded, if the HA entity is not disabled. If a more complex entity like climate uses the parameter temperature, and there is an additional sensor for temperature then this value is also loaded only once.

Please come back, if you need more information. Thanks for your support.

Well, thanks for these first information. Perhaps you can point me more to the actualy code passages that are doing the xmlrpc queries and all the other different data queries during startup of hahomematic/custom_homematic. So perhaps explain the query procedure more in a step-by-step guide here with reference to the actual code so that I can review and debug them in my own test environment so that I can identify the actual query code that causes most of the DC increase. Or perhaps you already debug this and find out which queries are responsible for the DC increase. But as it stands, IMHO the current way of querying / initialising the device parameters is definitly not perfect yet, because - as said - other external applications like ioBroker, etc. are also not causing any noteable DC increase.

[SukramJ]

Ok, before writing lots of step-by-step guides, i will try using the json methods.
I wasn't aware, that these calls use cached values.

@danielperna84 Any arguments against json methods?

@jens-maus I'll come back in short.

[danielperna84]

@SukramJ

Well, it will break compatibility with Homegear, as there we only have XML-RPC. If it's reasonable to implement both mechanisms and use one or the other depending on the detected backend (like we're doing with the metadate already), then we could use JSON-RPC if it's not Homegear. I suspect Homegear installations not to be big as CCU users have them.

@jens-maus

As mentioned above, getValue via XML-RPC is required because we aim for compatibility with Homegear. And I'm 99% sure the problem is caused by calling that method. As SukramJ said, Paramsets are only fetched once initially and then stored in a cache. So I would rule out getParamsetDescription, which is the only other read-access done via XML-RPC if I'm correct.

So essentially this is what hahomematic is doing during startup:

from xmlrpc.client import ServerProxy
for host in ["http://1.2.3.4:2001", "http://1.2.3.4:2010"]:
    client = ServerProxy(host)
    devices = client.listDevices()
    for device in devices:
        for channel in device:
            for param in channel:
                if not param.blacklisted:
                    # This is the problematic read-access to the XML-RPC API
                    value = client.getValue(device + channel, param)

Note: this is not code that actually works in this form. It's just to illustrate what is happening during startup.

[SukramJ]

I created a beta release 0.37.0b1 that should address the following things for CCU/RM users:

1. Use getParamset from JSON-RPC instead of getValue from XML-RPC for initial data load. This results in zero (?) raise of duty cycle when the system starts.
2. use getParamsetDescription from JSON-RPC instead of getParamsetDescription from XML-RPC. This works, but i need an extra converter for the output. Here i see no benefit as also the XML-RPC version uses cached information from CCU.

@jens-maus I have some questions:

• Any reasons why using JSON-RPC should be prefered over XML-RPC for getParamsetDescription?
• Is the CCU Cache persistet between restarts? I guess not.

If the cache is empty after a CCU restart, and HA is restarted directly afterwards, then the values are empty for a while.

[Lemocin]

If the cache is empty after a CCU restart, and HA is restarted directly afterwards, then the values are empty for a while.

Would it be an option to use the XML-RPC method, when the JSON-RPC gives empty values at the initial load?

[jens-maus]

Would it be an option to use the XML-RPC method, when the JSON-RPC gives empty values at the initial load?

Well, this would then of course end up in the same situation as before: an increased DutyCycle because all values are directly acquired from listening RF devices. And a smart home centrale (thus CCU) is nothing that you should reguarly reboot, etc. Thus in mid/long-term you will always have valid values in the cache. So I would definitely not advice to do that, but simply do what the other external engines like ioBroker do: Avoid racing the dutycycle under all circumstances.

[jens-maus]

I created a beta release 0.37.0b1 that should address the following things for CCU/RM users:
[...]

This sounds great. I will try to test it ASAP and report back if it really improves the DC handling. Do you have any easy description on how to force an update to 0.37.0b1 in an already installed HACS/cutsom_homematic installation?

@jens-maus I have some questions:

• Any reasons why using JSON-RPC should be prefered over XML-RPC for getParamsetDescription?

Well, I am not 100% sure and would have to check it. As the getParamsetDescription function in the JSON-RPC api performs essentially the same like the getParamset, my guess would be that there the same caching would apply and thus should improve the overall handling rather than directly querying each interfaces via direct XML-RPC calls.

• Is the CCU Cache persistet between restarts? I guess not.

Not it is not.

If the cache is empty after a CCU restart, and HA is restarted directly afterwards, then the values are empty for a while.

This should be essentially the very same like having the CCU restarted and looking into the WebUI. There, also in some cases (e.g. for homematicIP devices) values have default values until a battery driven homematic devices sends an update after some cyclic time. Thus, I would not overestimate the importance of that "limitation". More important is, that the DutyCycle of a CCU/RM will not be increased just because a restart of an external engine results in massive direct XMLRPC requests that end up in massive RF communication and thus an overload. As said, a smart home central is something that you would not restart daily or even regularly and "stablizes" only in mid/long term uptime.

[SukramJ]

Do you have any easy description on how to force an update to 0.37.0b1 in an already installed HACS/cutsom_homematic installation?

If you use hacs you could click on the integration and press "erneut herunterladen". Then you could also select the beta.

[Lemocin]

And a smart home centrale (thus CCU) is nothing that you should reguarly reboot, etc

I agree, but to understand me: In the last months, power outages are happening here quite regularly. So when a reboot happens, it's not always wanted.
I don't have that many devices, so i can just trigger the devices manually, but empty values would break some of my automations.
Another dumb idea: Maybe it is possible to use a service to update an important device with empty values?

[jens-maus]

Simply buy a UPS to prevent power outages, I would suggest as a valid solution ;) Really: it is totally valid and normal that battery driven RF devices should and often cannot be actively queried. Thus, you have to make sure that your automations can deal with the default values as well until sich battery RF devices send new values with their next cycle!

[SukramJ]

I'm playing around with xmlrpc.getValue vs jsonrpc.getParamset a bit. From the point of view of data actuality after a HA restart, I don't see any differences. Also the xmlrpc.getValue method does not initially return any data. As already mentioned, I have almost exclusively HmIP devices.

[jens-maus]

Do you have any easy description on how to force an update to 0.37.0b1 in an already installed HACS/cutsom_homematic installation?

If you use hacs you could click on the integration and press "erneut herunterladen". Then you could also select the beta.

So, Now I could test the latest 0.37.0b1 beta version you referenced with my production environment at home here. While I could immediately spot an improvement in terms of raised dutycycle due to a restart of HomeAssistant or HACS or even HA core, I still spot an increase of about 15% of DutyCycle here (compared to 20-25% previously)...

So can you please perhaps elaborate on the exact API methods you are using one after another to query all the different device information on a restart of hahomematic/custom_homematic so that we can perhaps try to further optimize the data queries up to a level that would definitly not increase the DC like other external applications like ioBroker or pocketControl (smartPhone app)?

[SukramJ]

• Start XmlRPC Server and register clients a CCU with XmlRPC (init)
• First start only (No cached data) fetch all paramset descriptions with JsonRPC (Interface.getParamsetDescription) (NEW with 0.37.x)
• On every HA startup:
  • fetch all data required for active HA entities with jsonRPC (Interface.getParamset). Results are cached for reuse. One call per used channel. (NEW with 0.37.x)
  • fetch device names with JsonRPC (Device.listAllDetail). one call
  • fetch rooms with JsonRPC (Room.getAll). one call
• During HA runtime:
  • every minute alive check with XmlRPC (ping)
  • every minute load system variables with JsonRPC (SysVar.getAll)

Updates are received by XmlRPC callbacks.

[SukramJ]

I created a new beta (0.37.0b2) that should further reduce the no of api calls.

[jens-maus]

I created a new beta (0.37.0b2) that should further reduce the no of api calls.

Thx. Any of these kind of changes are appreciated. However, I still notice a DC increase of about 18-20% upon restart of the integration. So no real change compared to 0.37.0b1 but definitly better than 0.36.x

And thanks for the technical details on the API calls used. I will try to invest some time in future to look more detailed into that in trying to identify the concrete API calls that are responsible for the rest of the DC increase. My current guess is, that we might try to think about replacing some of the JSONRPC or XMLRPC calls by queries to the ReGa-Skripting API on Port 8181 as the ReGaHss is more or less the central db for all homematic devices in a CCU and it uses massive caching to reduce RF communication to a minimum.

[SukramJ]

I created a new beta (0.37.0b3) as an alternative to 0.37.0b2 with jsonrpc.getValue instead of jsonrpc.getParamset.
More api calls, but as already menioned, i had some issues with xmlrpc.getParamset.

With these json implementations i cannot see a HA restart on the DC diagram anymore.

Would is your mixture of HmIP/BidCos/Virtual devices?
A good test might be to disable interfaces to see if it is more related to HmIP, BidCos or VirtualDevices.
You could do this by clicking on "Konfigurieren" on the integration, and disable interfaces on the second page.

[jens-maus]

I created a new beta (0.37.0b3) as an alternative to 0.37.0b2 with jsonrpc.getValue instead of jsonrpc.getParamset. More api calls, but as already menioned, i had some issues with xmlrpc.getParamset.

With these json implementations i cannot see a HA restart on the DC diagram anymore.

Thx for another beta version. However, this version is again back to an increase of DC of about 30-35% compared to only 18-20% with 0.37.0b2. Thus, I would propose to revert the getValue() change as this seems to definitly increase the DC by a similar amount like the 0.36.x versions.

Would is your mixture of HmIP/BidCos/Virtual devices? A good test might be to disable interfaces to see if it is more related to HmIP, BidCos or VirtualDevices. You could do this by clicking on "Konfigurieren" on the integration, and disable interfaces on the second page.

Thanks for the hint. I will try to test this during the next days and report back as well as provide some more statistics on my device setup. But I definitly have a whole bund of BidCos-RF devices and not so much HmIP devices. So lets see where this might end up in the end when I switch of different interfaces. I will also try to log the amount of API calls to the central in some way and then try to see which API calls make the DC raising even worse. But at least 0.37.0b2 definitly performed better/nicer than 0.37.0b3, I am afraid.

[SukramJ]

0.37.0b3 was just a quick test to sort out if the problem might be related to getParamset, which it is obviously not as much as getValue.

[SukramJ]

0.37.1 adds a semaphore(1) to improve cache usage (less api calls / one api call per paramset).
The more interesting part is the additional logging for xmlrpc and jsonrpc api logging, that should cover all api calls.

Add this to configuration.yaml to enable api logging:

logger:
  default: info
  logs:
    hahomematic.json_rpc_client: debug
    hahomematic.xml_rpc_proxy: debug

[jens-maus]

Installed 0.37.0 (which comes with hahomematic 0.37.1), but noticed the same slight DC increase like 0.37.0b2. Tried your suggestion to identify the interface which actually causes the DC increase and found out that as soon as I disable the BidCos-RF interface the 18-20% DC increase vanishes and that with just HmIP and VirtualDevices enabled I also cannot see any DC increase at all. So I will need to debug this further in seeing why exactly only with the BidCos-RF interface (rfd) a DC increase is happening and why this is only happening for hahomematic and not e.g. with ioBroker.

Still my current guess is, that this could also be some slight limitation of the rfd XMLRPC interface to some extend and that we would probably need to perform some data queries with ReGa scripting instead (ioBroker is actually doing this) - which in fact we could also do with the JSONRPC interface function ReGa.runScript instead of having to perform this using the explicit rega scripting port 8181. What do you think?

And thanks for the debugging possibilities. This really helps and I was also thinking about requesting improved debugging capabilities for hahomematic :). Only thing that you might probably improve/change in this respect is to make sure that the password for Session.login will not be logged verbatim in the debug log but the password being replaced/removed for security reasons.

[SukramJ]

So I will need to debug this further in seeing why exactly only with the BidCos-RF interface (rfd) a DC increase is happening and why this is only happening for hahomematic and not e.g. with ioBroker.

From my past experience i expected the problem with the BidCos devices. I'm curious what you find

We could give ReGa scripting a try, if this is the only solution, alltought i have no clue how to do it. So it is up to you to deliver the required code pieces.
ReGa.runScript seems to be a better option than using the scripting port 8181.

Is iobroker really loading all data at startup?

[jens-maus]

So I will need to debug this further in seeing why exactly only with the BidCos-RF interface (rfd) a DC increase is happening and why this is only happening for hahomematic and not e.g. with ioBroker.

From my past experience i expected the problem with the BidCos devices. I'm curious what you find

Haven't invested a lot of time yet (more to come) I just walked through the Homematic XMLRPC documentation and stumbled on the getParamset and getValue documentation (see chapter 4.2.4). I noticed that there is an extra mode parameter for getParamset and getValue which can be used during query of the BidCos-RF interface. And now I wonder if using this parameter might make any difference or at least reveal additional information (which can be added to the debug output) which devices were actively queried and for which devices cached values were used/retrieved. Perhaps you can have a further look at that and implement/test it to some extend?

And still I don't understand yet, why only the BidCos-RF interface seems to be affected by the DutyCycle increase if getParamset or getValue is used...

We could give ReGa scripting a try, if this is the only solution, alltought i have no clue how to do it. So it is up to you to deliver the required code pieces. ReGa.runScript seems to be a better option than using the scripting port 8181.

Definitly. If we really would need rega scripting here to further reduce the DC I think I can definitly assist here by writing/providing the necessary rega scripts for the data queries.

Is iobroker really loading all data at startup?

That's actually a very good question, which I would have to find out first (this is nothing I regularly have on my table). But perhaps @foxriver76 can assist on that question or provide the necessary links to iobroker code passages of the xmlrpc or rega scripting based data queries in ioBroker.hm-rpc or ioBroker.hm-rega?

At least in a quick search I could not spot any getParamset or getValue uses within main.ts of the ioBroker.hm-rpc adapter. So a question might be, why do you need to use getParamset or getValue altogether in hahomematic when, e.g., ioBroker is not using any of those but is also able to have all current device values upon startup. Or I am misinterpreting here something because I am not completly into this topic right now.

[SukramJ]

I think i already found something interesting https://github.com/ioBroker/ioBroker.hm-rega/blob/master/regascripts/datapoints.fn

[jens-maus]

I think i already found something interesting https://github.com/ioBroker/ioBroker.hm-rega/blob/master/regascripts/datapoints.fn

Funny. This is exactly what I would have suggested next, but first wanted to share my thoughts in my last comment. :) So yes, this kind of rega code snippet is able to retrieve all current datapoint values of all devices in the rega db. So you could simply throw that kind of code into the ReGa.runScript function in the JSONRPC API function and should get all current device values after another (if this is exactly what you are actually looking for when using getParamset or getValue).

[SukramJ]

@jens-maus
you can test it, if you change the requirement in manifest.json

"requirements": ["hahomematic==0.37.1b1"],

[jens-maus]

you can test it, if you change the requirement in manifest.json

Perfect. I just did it and now there is no DutyCycle increase at all upon restart of HomeAssistant. I can also spot the ReGa.runScript executions in the debug logfile. Didn't check if it correctly set/updated the device values upon restart (how can I debug this?).

In addition, I can see that you execute that ReGa script for every interface. But AFAICS this script has to be executed only once for all interfaces and not for every interface startup again. So perhaps you can change your internal logic in some way that it will only be executed once before all interface xmlrpc registrations.

Furthermore, using this ReGa.runScript together with some dedicated script can have more potential in future. For example, you could in principle now automatically identify which interfaces are available and then register them accordingly. So there might be no need anymore to switch BidCos-RF/HmIP/VirtualDevices on/off simply because you can fetch that information via ReGa scripting using the JSONRPC API.

But seeing that using ReGa scripting seems to work and does not raise the DutyCycle anymore is really great. Thanks for that and I hope you/we can make it even more smooth until this is available to the public.

BTW: Where can I see your 0.37.1b1 code modifications in hahomematic because I can't see these changes in the hahomematic respository yet?!?!

[SukramJ]

Perfect. I just did it and now there is no DutyCycle increase at all upon restart of HomeAssistant. I can also spot the ReGa.runScript executions in the debug logfile. Didn't check if it correctly set/updated the device values upon restart (how can I debug this?).

I don't want to add the script result to the debug output, but if a device has initial data then it is from the script.

In addition, I can see that you execute that ReGa script for every interface. But AFAICS this script has to be executed only once for all interfaces and not for every interface startup again. So perhaps you can change your internal logic in some way that it will only be executed once before all interface xmlrpc registrations.

It's currently a dirty hack. It's not executed per interface. It should be executed once initially and when newDevices is called.

Furthermore, using this ReGa.runScript together with some dedicated script can have more potential in future. For example, you could in principle now automatically identify which interfaces are available and then register them accordingly. So there might be no need anymore to switch BidCos-RF/HmIP/VirtualDevices on/off simply because you can fetch that information via ReGa scripting using the JSONRPC API.

Good idea, but there might be an issue if people use different ports.

But seeing that using ReGa scripting seems to work and does not raise the DutyCycle anymore is really great. Thanks for that and I hope you/we can make it even more smooth until this is available to the public.

Thanks for pointing me in that direction.

BTW: Where can I see your 0.37.1b1 code modifications in hahomematic because I can't see these changes in the hahomematic respository yet?!?!

The code is currently a fast and dirty hack. Now i will clean it up and push it to the repo.

[SukramJ]

Code can now be seen here

[SukramJ]

Can this issue be closed?
The DutyCycle issue is solved in latest release.
For further improvement ideas we should switch to new discussions / feature requests

[Baxxy13]

Since changes for this issue i got a warning in the RM-Logs every time i use "Integration neu laden" or "Homeassistant neu starten"
It's just a warning, but was not seen before and should not be there.
Don't know if it's maybe problematic.

Mar 18 15:17:37 RM-Test-Pi3Bplus-27 local0.warn ReGaHss: WARNING: cannot clear session with id '1bWXOdzQux' [ExecSystem():iseESPexec.cpp:3764]
Mar 18 15:17:49 RM-Test-Pi3Bplus-27 user.err rfd: XmlRpc fault calling system.listMethods({"RM-Test-Pi3Bplus-27-BidCos-RF"}) on http://192.168.113.29:43959/RPC2:[faultCode:1,faultString:"<class 'TypeError'>:system_listMethods() takes 1 positional argument but 2 were given"]
Mar 18 17:51:19 RM-Test-Pi3Bplus-27 local0.warn ReGaHss: WARNING: cannot clear session with id '1FObNXZ2rw' [ExecSystem():iseESPexec.cpp:3764]
Mar 18 17:51:38 RM-Test-Pi3Bplus-27 user.err rfd: XmlRpc fault calling system.listMethods({"RM-Test-Pi3Bplus-27-BidCos-RF"}) on http://192.168.113.29:36839/RPC2:[faultCode:1,faultString:"<class 'TypeError'>:system_listMethods() takes 1 positional argument but 2 were given"]
Mar 18 17:56:05 RM-Test-Pi3Bplus-27 local0.warn ReGaHss: WARNING: cannot clear session with id 'nD1aRrKtFb' [ExecSystem():iseESPexec.cpp:3764]
Mar 18 17:56:17 RM-Test-Pi3Bplus-27 user.err rfd: XmlRpc fault calling system.listMethods({"RM-Test-Pi3Bplus-27-BidCos-RF"}) on http://192.168.113.29:32829/RPC2:[faultCode:1,faultString:"<class 'TypeError'>:system_listMethods() takes 1 positional argument but 2 were given"] 

[jens-maus]

@SukramJ

Can this issue be closed? The DutyCycle issue is solved in latest release. For further improvement ideas we should switch to new discussions / feature requests

Regarding this issue, I can indeed report that the increase of DutyCycle due to the use of xmlrpc.getParamset/jsonrpc.getParamset or xmlrpc.getValue/jsonrpc.getValue has now vanished. I even tested the latest 0.37.3 version of custom_homematic and there is no DutyCycle increase anymore. So yes, this issue can probably be closed - thanks again.

However, perhaps you can indeed have a look at what @Baxxy13 stated here regarding warning and error messages which are appearing now in the /var/log/messages file within RaspberryMatic when reloading the custom_homematic integration.

[eikowagenknecht]

I noticed that on restart of Home Assistant the Duty Cycle still goes up for me on 1.0.4.

Also I can see my HM Doorbell (HM-OU-CFM-TW) blinking red once on reboot of HA. Since it is not used in any automation or any other means in Home Assistant (spare device...) I assume it is because some command gets sent to it on HA reboot.

[jens-maus]

I noticed that on restart of Home Assistant the Duty Cycle still goes up for me on 1.0.4.

Which CCU device are you using? External or using the RaspberryMatic Addon within HA?

[eikowagenknecht]

Original CCU3 (=Raspi 3) flashed with RaspberryMatic (latest).