New Tool: CCA Trace Compare + Major Updates for Trace Analyzer!
Hi everyone,
Iâve just rolled out some major updates to the helper tools for the Cover Control Automation (CCA) blueprint. Debugging complex automations just got a whole lot easier!
Here is whatâs new:
1. Introducing: CCA Trace Compare
I have released a brand new tool called Trace Compare. If you are tweaking your blueprint or trying to understand why an automation behaved differently today versus yesterday, this tool is for you. It allows you to load two different traces side-by-side and highlights specific differences in their execution paths and variables. This makes spotting regressions or logic changes instant.
2. External URL Support (Compare & Analyzer)
You no longer need to download trace files to your computer just to view them! Both Trace Compare and the existing Trace Analyzer now support loading traces directly from external URLs.
Pastebin, GitHub Gists, or any raw JSON URL.
This is perfect for helping others in the forum. Jst share your Pastebin link, and we can load it directly into the analyzer!
3. Direct Copy & Paste
Donât want to use a URL or save a file? No problem. You can now simply Copy & Paste the raw JSON trace code directly into the input field of both tools. It parses the JSON instantly.
Yep i fully agree, that its good to have only one sensor for up and down. And yes i need a treshold for some automations. But where do i enter the treshold values in the blueprint?
than you have to âcorrectâ the documentation! Nowhere is written that the fixed values will be used as treshold. In the blueprint its written that the values will be overwritten! So in my opinion the wouldnât be used as treshold!!
Hi!
Maybe a stupid question: If everything is working perfectly with the old version, is ist more or less save to update (just reload the blueprint) or is it necessary to update your settings? Honestly I am not quite sure, what the âBreaking Changes & Migrationâ section is telling me.
Thanks and best regards, MĂźsli
Hi,
Iâve just created your template for the dynamic sun elevation. It now shows 1.9 for UP and -1.1 for DOWN.
However, at -1.1 itâs still bright outside or just starting to get darker.
If I now use the sensors in the automation, as you wrote, they replace the values defined there.
How can I modify the template so that the DOWN sensor shows, for example, -4.0 or -4.5?
actually i have the same âproblemâ and the only way seems to change the values in the sensor itself. @Herr.Vorragend knows about that and i think he will give us a solution for that:)
On latest main branch I have another case where I think the opening of the cover is not working as one would expect.
In the opening branch there is this part:
- or: # Only once a day? # 8
- "{{ not is_status_helper_enabled }}"
- "{{ not prevent_flags.opening_multiple_times }}"
- "{{ is_status_helper_enabled and prevent_flags.opening_multiple_times and (now().day != helper_ts.open|timestamp_custom('%-d')|int) }}"
In my automation I have configured it like:
id: '1742411447075'
alias: Kantoor screen
description: ''
use_blueprint:
path: FrankTub/cover_control_automation_beta.yaml # my own version of some more tweaks but these are not relevant I think
input:
blind: cover.kantoor_screen
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_shading_enabled
- auto_sun_enabled
...
individual_config:
- prevent_shading_multiple_times
- prevent_higher_position_closing
- prevent_shading_end_if_closed
- prevent_opening_after_shading_end
- prevent_opening_multiple_times
time_up_early: '07:30:00'
cover_status_helper: input_text.kantoor_screen_helper
cover_status_options: cover_helper_enabled
...
auto_down_force: binary_sensor.kantoor_screen_moet_dicht
auto_up_force: input_boolean.ramenzemer_modus
So I donât want to open the screen multiple times, but in the background the helper is updating helper_ts.open even if the cover is not moving. So if you have a resident sensor or a force feature of some kind that normally would open your cover even though it does not really open your cover AND you have prevent_opening_multiple_times enabled then it will never open on that day.
PS: not really sure when the helper is updated, but even if sun elevation is blocking opening the cover based on time the helper might be updated and the same scenario might happen?
I explained it incorrectly here in the forum. But the description in the blueprint and in the documentation was always correct.
For optimization purposes, I have just updated the blueprint description. In its current form, it is a little clearer.
yep that sounds like it works
But one Question: To prevent creating several template sensors wouldnât it be better to use the ignored fixed values in combination with the dynamic ones? I mean the dynamic sensor is especially for my house and if i have 5 of them with different values, the range is everytime the same, only the start of the range differs in each sensor (from the values i set)! So i think the use of the fixed values in the blueprint to move the treshold to the right place would be better than th create several sesnors! Or?
how can i close my cover in the evening not by sun elevation, but by time delay?
i want to close all my covers 30 minutes after sunset every day of the year.
can i use cca for this?
Thanks
yep thats sounds nearly that i tried to explain !
And the offset in Option B can be set via the normaly âfixedâ value in CCA? Or how should CCA knows which cover is north or south?
New Tool: CCA Trace Compare + Major Updates for Trace Analyzer!
