Firmware upgrade, select devices to upgrade

[Silverstar]

Well, then you could try rebooting the CCU. Maybe something hangs there.
If that does not help (after a while, like days or weeks), you could try deleting the firmware files from the CCU via SSH like here and then, after another reboot, upload the firmware file again. And I would suggest to download the file again beforehand to make sure you didn't have a corrupt file in the first try.

But still, the question is, how high your duty cycle was/is without the transmitting update, because the CCU does only continue transmitting if the DC is well below 50%, if you're always at or above 50%, no progress is made.

Here are more information regarding the HmIP update process (well, also in German but online translation services are better nowadays, like deepl.com)

[samuellazea]

Well, then you could try rebooting the CCU. Maybe something hangs there.
If that does not help (after a while, like days or weeks), you could try deleting the firmware files from the CCU via SSH like here and then, after another reboot, upload the firmware file again. And I would suggest to download the file again beforehand to make sure you didn't have a corrupt file in the first try.

But still, the question is, how high your duty cycle was/is without the transmitting update, because the CCU does only continue transmitting if the DC is well below 50%, if you're always at or above 50%, no progress is made.

Here are more information regarding the HmIP update process (well, also in German but online translation services are better nowadays, like deepl.com)

What you suggest above with reboots, delete of firmware, restart etc I already tried it few times and no success.
I however did not know about the 50% duty cycle that the firmware upgrade stops. Mine is kind of always above 50%. At this right moment is at 62% Is there a way to bring the duty cycle down? Or is there a way to reset the duty cycle to 0 once in a while?

[Silverstar]

Well that heavily depends on what causes your high DC.

Could be badly written programs, like reacting on a value on refresh, not on change, and acting on that, like switching stuff on(off) when already on(off);
Or device parameters to send updates of their state to often, like setting the number of unchanged status updates to low or even 0, or measuring equipment with low set thresholds of changing power/current/voltage.
Or like, when using scripts, using .state() instead of .value (or vice versa, I'm not sure) to check the status of a device, which, for some devices, forces the CCU to actively query the device for the current state instead of relying on the cached value.

There are more possible reasons and there is a bunch of information (in German, unfortunately for you, but online translation services like deepl.com are good these days), for example here viewtopic.php?f=26&t=53387&hilit=Duty+cycle#p532517

[samuellazea]

Well that heavily depends on what causes your high DC.

Could be badly written programs, like reacting on a value on refresh, not on change, and acting on that, like switching stuff on(off) when already on(off);
Or device parameters to send updates of their state to often, like setting the number of unchanged status updates to low or even 0, or measuring equipment with low set thresholds of changing power/current/voltage.
Or like, when using scripts, using .state() instead of .value (or vice versa, I'm not sure) to check the status of a device, which, for some devices, forces the CCU to actively query the device for the current state instead of relying on the cached value.

There are more possible reasons and there is a bunch of information (in German, unfortunately for you, but online translation services like deepl.com are good these days), for example here viewtopic.php?f=26&t=53387&hilit=Duty+cycle#p532517

@Silverstar you are a genius. Can't thank you enough. Hats off to you

I did not respond anymore cause I started to test based on the information you provided about the duty cycle and since Friday till now ( 3 days) I managed to upgrade 11 devices and I still have 2 more to go out of the WTH. Still have to do another devices but it seems it's going through.
Indeed my duty cycle was staying quite high ( see attached screenshot ). As you can see I started to monitor it to see what is going on and I managed to keep it low now. At first I stopped all "Cyclically status message" on all devices, then I turned off all my homeassistant monitoring to see the duty cycle going down. So it went down and devices started to upgrade. Then I turned back ON my homeassistant monitoring and it seems it added just a bit to the duty cycle, but not considerable. Devices kept upgrading even with the monitoring turned ON.

Now I need to still see what is this "Cyclically status message" and how to configure properly the "Number of messages that are left out" and "Number of unchanged status messages that are left out". On some devices I have set both to 0 to have all info available. I am talking about the wall plugs, so I have a detailed monitoring on the power consumption.

Another thing that I have no clue about is what is "Carrier Sense CCU3" and what is it used for? Any chance you have a clue about it?

And I am not afraid of german or any other language Google chrome automatic translation is my best friend

[cmjay]

Another thing that I have no clue about is what is "Carrier Sense CCU3" and what is it used for?

Carrier sense level is a measure of usage of the spectral window in which HM(IP) is operating. Contrary to the DC it is not only taking account of the HM(IP) devices themselves broadcasting but includes all other sources of background noise in the frequency band. That couid e.g. be devices using other communication protocols in the same band, or switching power supplies, or the neighbour's wall box, or ...
As a rule of thumb it has been established here in the forum that from a CS level in the double digits (> 10%) the communication with HmIP devices is starting to be perturbed or even impossible (while communication with HM devices is often unaffected). The reason is that HmIP implements a "listen before talk" approach and is hence not attempting to communicate if the frequency band is considered too busy. HM devices do not have this feature implemented and thus continue to communicate even in a busy environment - at the risk of some of the broadcasts being lost in transmission.

On some devices I have set both to 0 to have all info available. I am talking about the wall plugs, so I have a detailed monitoring on the power consumption.

To my knowledge cyclical status messages are unlikely to be the root cause for a high DC. However, wall plugs with wrongly configured (power/voltage/frequency) measurement settings are prime candidates causing high DC.

[Silverstar]

A (overwhelming) source of useful information is viewtopic.php?f=1&t=22801

Carrier Sense is a value "measured" by the ccu, which is the amount of noise on the frequency (868 MHz) which homematic uses. But not only homematic is using that, so there is plenty of other stuff, like remote garage door openers (although they are more common on 433 MHz afaik) and other legitimate use(r)s, but there is other noise like harmonics and other emissions of devices not intended for 868 MHz but still hitting on that frequency.
Regarding HmIP, the devices including the CCU, check the frequency if it is blocked or "free" ("listen-before-talk") which causes communication errors or delay if there is too much noise, because then, the devices do not send. So a CS value of 10 or more is bad. Should be zero or well below 5.

In the forums there are many threads about communication errors due to high CS, sometimes even a (non homematic) weather station a few houses away, sometimes only a Hm(IP) device with low battery, neighbors new e-car charger, or a new (or old and failing) PSU (not complete list).

Number of unchanged omitted messages (or something alike, I'm not using the ccu in english) is like, a WTH measuring temperature, is 23,1°, has been 23,1° before, okay, then I don't waste DC.

For power measuring equipment you have to consider what exactly you want to have and how exact the numbers have to be. Most of the time it will be power.
Voltage is basicly irrelevant, as it is floating around 230 V~ and you will rarely need it for any smart home purposes.
Current as well, as power is the product of voltage and current, and power is the main thing you need (I guess).

If you set the device to report every time voltage differs by a few V or the Current changes, when you only need power, it unnecessarily sends a new message. So set the thresholds for voltage and current quite high. It will still be transmitted from time to time. Maybe together with a message regarding power changes (I'm not sure), but at least with the next cyclic message.

For power, you have to think what your aim is. Want to know if a water kettle is on or off? Probably it will have 1000 W+ when on, and below 5 W when off. No need for a threshold of less than 100 W, rather higher, because the difference when heating, may be floating between 900-1100 W (just example numbers to make that point, if you might have like a 1kW model), and off, around 0-5 W, is way above 800 W.

For long time power consumption recording, you don't need every change in W, you want to have a guesstimate to know how much the connected device consumes but not in real time and small changes don't make a big difference in the bill.