☀️ Cover Control Automation (CCA) - a comprehensive and highly configurable roller blind blueprint

Herr.Vorragend · January 27, 2024, 8:12pm

Hello everyone, I would like to introduce you to my roller shutter blueprint:

Cover Control Automation (CCA)

My GitHub Project | Full Changelog on Github

Current version: 2025.08.15

If you would like to support me or say thank you, please click here:
PayPal Donation | Buy me a coffee

FEATURES

Opening and Closing: Automatically opens and closes roller shutters based on brightness, sun elevation, and within specified time windows.
Ventilation Feature: Supports two-way sensors for ventilation, allowing for partial opening to ventilate the room.
Resident Feature: Keeps the cover closed if a resident is detected as asleep, ensuring comfort and privacy.
Drive Delay: Offers both fixed and random delays for driving the covers, providing flexibility in operation.
Trigger Waiting Time: Configurable waiting time for triggers to avoid rapid, unnecessary movements.
Position Tolerance: Adjustable tolerance for cover positions to account for minor discrepancies in cover movement.
Dynamic Conditions: Features can be activated or deactivated based on dynamic conditions such as:
- Vacation Mode: Keeps covers closed during vacations.
- Party Mode: Prevents covers from closing during parties.
- Shading Boolean: Controls shading activation and deactivation.
- Maintenance Mode: Suspends cover control during maintenance or cleaning.
Manual Override Detection: Detects manual overrides and adjusts automation to prevent conflicts.
Time-Based Control: Configures cover control based on workdays and non-workdays, allowing different schedules.
Sun Elevation-Based Control: Adjusts cover positions based on the sun’s elevation to optimize natural light and heat.
Brightness-Based Control: Uses ambient brightness levels to manage cover positions, enhancing energy efficiency.
Position Management: Manages multiple positions for different states such as open, close, ventilate, and shading. Added the option to save the current status in a helper. This has the advantage that the roller blind can also be in other positions and the automation can still be executed. And manual interventions are not constantly overridden with every trigger.
Sun Shading / Sun Protection: Extensive automatic sun shading with many different setting options: Sun azimuth, Sun elevation, Solar irradiation/Light intensity/Illuminance, Weather Conditions, Temperature sensors (compare thresholds for indoor and/or outdoor sensors), weather forecast comparison

FAQ

General Questions

What are the minimum requirements for using the CCA Blueprint?
- The cover/shutter must have a current_position attribute.
- Shutters need to be properly integrated into Home Assistant.
- The sun.sun entity must be enabled and working correctly.
- Minimum required version of Home Assistant: 2024.6.0

Configuration Questions

How do I set up the basic position settings?
- Set open_position (typically 100).
- Set close_position (typically 0).
- Configure drive_time (default 90 seconds).
What are the important configuration rules?
- Ensure time settings follow logical order (early times before late times).
- Position values should be hierarchical: open_position > ventilate_position > close_position.

Feature Questions

How does the ventilation feature work?
- Supports two-way sensors for partial opening to ventilate the room.
- Or use the sensors for lock-out protection
What is the resident feature?
- Keeps the cover closed if a resident is detected as asleep.
How can I detect manual overrides?
- The blueprint includes a feature to detect manual overrides and adjust automation accordingly.
How do the shading start conditions work?
- If multiple criteria (e.g. temperature sensors and/or azimuth and/or elevation) are defined, shading will not occur until all criteria are met.
How can I use additional conditions like vacation mode or party mode?
- Activate vacation mode to keep covers closed during vacations.
- Use party mode to prevent covers from closing during parties.

Advanced Questions

Can I configure the blueprint based on sun elevation and brightness?
- Yes, the blueprint allows adjustments based on sun elevation and ambient brightness levels.
How do I manage multiple positions for different states?
- The blueprint supports managing positions for open, close, ventilate, and shading.

SCREENSHOTS

CHANGELOG

_{(Full Changelog on Github)}

Some recent changes

2025.05.27

Updated: Revised information text for configuring the position configuration
Added: The schedule helper state has been added as a variable. This is just for debugging purposes. #214
Fixed: The problems with the start of shading have been corrected. #212 #211
If the shading conditions were not still fulfilled after the end of the waiting time, the sun protection was sometimes not activated correctly.
Now we have a new feature and we can select the following options:
- If the conditions were not permanently fulfilled, we can wait for another trigger to be executed. The previous pending status is now successfully reset.
- And much better: CCA can be configured so that we can periodically check the shading during the day. The system then checks again and again until the conditions are valid again.

2025.05.20

Fixed: Wrong default value for shading_forecast_temp

2025.05.14

Added: Falling below shading_elevation_max now also triggers Shading Start #193
Fixed: When detecting manual position changes, values greater than Ventilation were incorrectly assumed to be Open. This was too wide-ranging.

2025.05.13

Fixed: The nightly shading reset has changed the timestamp and therefore a new shading with active ‘prevent_shading_multiple_times’ can never be executed.

2025.05.12:

Fixed: Multiple triggering of a detected shading has skipped the waiting time until execution #206

2025.05.11:

Fixed: Fixed bug that the cover can be opened again by the time-up-late-trigger despite existing shading.

2025.05.07:

Fixed: Shading is now also recognized and temporarily stored in the helper if the resident sensor contains the value true. #131
Added: Tilt Reposition Feature (Thanks for the pull request, Astado) #196
Update: Better textual clarification of what the result of the additional condition should look like #204
Update: Only shade the cover when it is not in the shading position. Purely as a precautionary measure in case the target state and actual state do not match.

2025.05.04:

Added: Allow immediate ending of shading if the sun is out of the defined azimuth or elevation range #202 (thank you, jpawlowski)
Added: Option to close cover instead of opening when shading ends (ideal for awnings) #203 (thank you, jpawlowski)
Updated: Note that the weather sensor specification is optional #198

2025.05.02-02:

Fixed: A bug has been fixed that caused the shading to be recognized but not executed. But only if shading was only allowed to be executed once a day.

2025.05.02-01:

Fixed: Also take into account for shading that a door contact only needs to be tested when ventilation mode is switched on #197
Fixed: Removed protocol error that occurs during manual execution.
Added: Catching an incorrect weather configuration
Added: Ability to specify an existing sensor if it already provides daily maximum temperature forecast instead of weather entity #199
Added: Add hysteresis for temperature sensor based shading #189

2025.04.18:

Updated: Just to be more bulletproof, the tilt position control can now be specifically switched on or off. Please activate if necessary. #163
Updated: There is no default value for “Sun Shading Forecast Temperature” here now. To not compare the forecast temperature, leave this field empty. #179
Added: Allow entities of the switch domain as resident sensor or with the force entities #167
Added: New additional actions: Commands can now be executed before opening, closing, shading and ventilation #166
Fixed: Fixed problems resetting manual override #184
Fixed: Make sure that the reset of the manual override is only executed once #178
Fixed: Problems with lockout protection and partial ventilation solved #181
Fixed: There was no latest time for closing the cover when the scheduler was used with sun/brightness #170
Added: Added Sun elevation examples into the description #175
Added: New feature ‘Allow opening the cover when resident is still present’ #192
Breaking change: Please reconfigure “Allow sun protection when resident is still present” (‘resident_shading_enabled’ was renamed)

2025.06.07

Added: Resident check for ventilation #216 (Thanks for the pull request, Astado)
Added: Better description for shading_forecast_sensor (Thanks you, Eimeel)
Fixed: Solve Issue with sun shading end if Tilt Position Control is enabled #216 (Thanks for the pull request, Astado)
Fixed: Shades are being opened or closed even if they are already #219
Fixed:
When the “End Sun Shading Immediately When Out Of Range” mode was activated, the shading of the cover was not canceled.
This was because the new waiting time was set to 0 seconds and CCA could not trigger itself in the same second via a helper.
Updated: Extensive code refactoring
Updated:
Automation mode changed to ‘single’ as a test, because otherwise new triggers in the delay would interfere with processing.
In the worst case, I will have to work with {{ state_attr(‘automation.cca_automation’, ‘current’) > 0 }} as before to be able
to intercept the reciprocal triggers.

2025.06.10

Fixed: The detection of weekdays and weekends is working again.

2025.06.11

Fixed: Error fixed if the Workday Tomorrow sensor was not specified

2025.06.12

Fixed: Increased the delay to 20 seconds for the “End Sun Shading Immediately When Out Of Range” feature. This change aims to ensure the new trigger executes reliably, as Home Assistant appears to ignore shorter delay values.
Updated: Refactored helper_state_json to include a more robust fallback mechanism.
Improved: Shading end triggers have been restructured to activate only when shading is currently active.
Refactored: Codebase has been restructured to use YAML anchors, improving maintainability and reducing redundancy.

2025.06.13-02

Fixed incorrect use of is_state() with potentially invalid inputs
Improved robustness using states() with type checks
Handled optional workday sensor inputs gracefully

2025.06.19:

Fixed: Tilt Delay added again
Fixed: Even though no shading was explicitly applied, the shading has ended for a closed cover #226
Added: Add sun shading minimum tilt position (Thank you for the pull request, julianwachholz) #230

2025.07.10:

Fixed an issue where shading could not be activated while tilt mode was active
Fixed a bug where shading would start unexpectedly even though the sun was on the opposite side of the building (#244)
Fixed a failure in the lockout protection mechanism (#225)
Fixed an issue where forced tilt reset was not skipped when changing tilt positions (#241)
Fixed a bug where shading end conditions were not properly checked (#229)
Added: Option to additionally allow temperature+forecast-only shading (#238)
Added: Configuration option to compare forecast temperature with Sensor 2 (#238)
Memo: Slight adjustment to the calculation of is_helper_shaded: pending shading end is no longer considered.

2025.07.30:

Fixed: Shading not ending when condition changed in previous waiting time #258
Fixed: Shading not ending because of general conditions #257
Fix only tilt open is not ending shading #255

2025.08.07:

Fixed a bug where shading was not disabled when the weather sensor or optional weather conditions were not set #258

2025.08.10:

Minor updates

2025.08.15:

Fixed: In rare cases, global conditions prevented the helper from being pre-filled #270

I hope you have lots of fun with this version.
And please don’t forget the little heart here. Thank you.

Herr.Vorragend · January 27, 2024, 8:14pm

Troubleshooting Questions

The CCA blueprint is powerful but requires precise configuration. Below are typical errors users encounter:

Incomplete or Invalid Configuration

Time ranges must be logically ordered (e.g., time_up_early < time_up_late).
Azimuth values (e.g., shading_azimuth_start and shading_azimuth_end) must form a valid range.
Missing required fields can cause the automation to fail silently.

👁️ More important configuration notes

time_up_early should be earlier than time_up_late
time_up_early_non_workday should be earlier than time_up_late
time_down_early should be earlier than time_down_late
shading_azimuth_start should be lower than shading_azimuth_end
shading_elevation_min should be lower than shading_elevation_max
shading_sun_brightness_start should be higher than shading_sun_brightness_end
open_position should be higher than closed_position
open_position should be higher than ventilate_position
closed_position should be lower than ventilate_position
shading_cover_position should be higher than closed_position
shading_cover_position should be lower than open_position
resident is only allowed to be on/off/true/false
cover must have a current_position attribute

Why is my trigger sequence not executed even though all conditions are met?

This is often because the blueprint is configured so that certain actions can only be executed once a day. Particularly in the initial phase, you try out a lot and so an action could theoretically have already been noted as executed.

What should I do if the cover positions are not working correctly?

Verify your cover reports current_position correctly.
Ensure position values don’t conflict with each other.
Check if manual control is working properly.
Improper position values (e.g., open_position should be greater than closed_position). And the shading_position must be unique; i.e. it must not match any other values.

Trying to Trigger the Automation Manually

This blueprint is not designed for manual triggering.
Manually clicking “Run” will not produce the expected behavior.

Missing or Invalid Entities

Required entities like sun.sun, sensors, and weather data must be available and return valid values.
If entities return unknown, unavailable, or are missing, actions may be skipped.

Using an Outdated Blueprint Version

The blueprint is frequently updated.
Re-import and review after updates.
Check changelogs for new options or breaking changes.

Common Issues with Sun Protection / Sunshade Control

Inaccurate Weather Forecast Blocking Activation

If you’re using a weather forecast sensor (e.g., OpenWeatherMap), inaccurate “cloudy” or “partlycloudy” predictions may prevent sun shading, even when it’s actually sunny.

Tip: Use the action weather.get_forecasts in the developer console and see what response your weather integration gives.

Incorrect Azimuth or Elevation Settings

Improper configuration of the sun’s azimuth or elevation ranges may prevent activation:

shading_azimuth_start must be less than shading_azimuth_end.
shading_elevation_min should reflect realistic sun elevation levels in your region and time of year.

Activation Delay (`shading_wait`)

The shading_waitingtime_start parameter defines a wait time (in seconds) between all shading conditions being met and the actual activation.

This often causes users to think shading isn’t working, especially when the sun conditions change quickly.

Manual Control Preventing Automation

If blinds are manually moved, the automation may stop responding unless you properly reset the manual override. Or has the automation been modified in the meantime or has Home Assistant even been restarted?

Grouped Covers Causing Conflicts

Grouping multiple blinds into one cover entity can lead to issues. If one blind in the group is manually closed, it may prevent the automation from moving any of them.

Missing or Misconfigured Sensors

Missing required entities like:

sun.sun (for sun position)
Brightness sensors
No definition of necessary helper (e.g. cover_status_helper)

…can cause the sun shading logic to silently fail.

Time Window Misconfiguration

Shading will not activate outside the specified time range, even if all sun conditions are satisfied.

Check: time_up_early and time_down_late settings to ensure they include your intended shading hours.

Problem with ending the shading

Check if the conditions for ending shading (e.g., sun elevation dropping below shading_elevation_min) are correctly configured.

Why Are My Numeric Triggers Not Firing?

How does the threshold concept apply to the Cover Control Automation?

In the CCA Automation, a threshold defines the specific brightness level at which your covers (e.g., blinds or shades) are expected to react. For example, if the threshold is set to 75, the automation will only trigger actions (such as opening or closing the covers) when the brightness value crosses that point - either by rising above or falling below it.

Can you provide an example of how thresholds work in the CCA?

Let’s say the brightness sensor currently reads 50, and your CCA Automation is configured to close the covers at a threshold of 75. If the brightness increases to 60 or even 74, the automation will not fire. It only triggers once the value crosses the threshold—such as reaching 76. Similarly, the same logic applies when the brightness is dropping below a set lower threshold.

Why might the CCA Automation not trigger, even though I expect it to?

If your CCA Automation isn’t firing, it could be because the brightness value hasn’t actually crossed the threshold - only approaching it isn’t enough. Automations using numeric state triggers in Home Assistant only activate when the value transitions from one side of the threshold to the other.

What should I check if my CCA Automation isn’t working as expected?

Start by confirming the current brightness level and compare it to your defined threshold values. Ensure that the values are actually moving across the threshold. Next, review your automation conditions to verify that all necessary criteria are being met (e.g., time of day, sun position, presence status, etc.). Lastly, consider checking the automation’s trace or logs in Home Assistant to see if and when the trigger conditions are evaluated.

How to Use Traces Effectively

Traces allow you to inspect exactly what happened when an automation was run.

Increase Stored Traces (Optional)

To store more traces, add this to the automation YAML:

trace:
  stored_traces: 20

_{See also: Troubleshooting automations - Home Assistant}

Providing the traces

Go to Settings → Automations & Scenes.
Click on the relevant CCA automation.
Select the Traces tab to view execution steps.
Use the arrow symbols to switch back and forth between the traces and search for the trigger (see trigger table) that should actually trigger something.
Please note that traces for the trigger “t_manual_x” are not relevant for debugging. Traces are only required in very rare cases. Then I would also point this out. These triggers are reactions to manual position changes or the attempt to recognize previous actions from the blueprint. If there are problems, then rarely with this trigger, but with the trigger directly before it.
Download the trace and make the file available in the thread via filehosters such as Pastebin.

Uploading the JSON File

Since the forum does not support uploading .json files directly, please use one of the following services to host your file and share the link in your post:

Service	Link	Account Required?
Pastebin	For “Unlisted” pastes	Supports syntax highlighting for JSON.
GitHub Gist	Optional GitHub account	Ideal for structured files; public or secret.
Hastebin	No	Fast & simple; may expire over time.
0bin	No	End-to-end encrypted; privacy-focused.
file.io	No	File auto-deletes after one download.

Pastebin Example

Go to https://pastebin.com.
Paste your entire JSON content.
Set Syntax Highlighting to json.
Set Paste Exposure to Unlisted.
Click “Create New Paste”.
Copy the generated link and include it in your forum reply.

By providing the trace in this format, it’s much easier to identify bugs, unexpected behavior, or misconfigurations in your automation setup. Thank you!

Tips for Creating Helpful Support Requests

When asking for help on the forum, include:

Your automation YAML configuration (exported instance).
The exported trace (especially of failed runs).
Expected behavior vs Actual result.
Tip: Please do not summarize so many independent problems in one post. It makes support easier for me if we could focus on one possible error per post.

Summary

Set up the CCA blueprint carefully with correct values and entity references.
Do not trigger it manually.
Keep the blueprint up to date.
Use Traces to debug and provide structured support requests.

Trigger overview

Trigger	Function	Description
`t_open_1 - 6`	Cover Opening	Trigger for opening
`t_close_1 - 6`	Cover Closing	Trigger for closing
`t_contact_tilted_on` / `t_contact_opened_on`	Ventilation	Responds to the status of the window contact
`t_shading_start_pending_1 - 5`	Shading Pending	Checks relevant conditions (azimuth, elevation, temperature)
`t_shading_start_execution`	Shading Executed	Activated when conditions are met
`t_manual_1 - 3`	Manual Position Detection	Monitors manual changes and resets status

Cover Status Helper - Contents

The Cover Status Helper is the central control element in the latest version of the Cover Control Automation (CCA). It tracks the current state of the roller blinds.

Structure and Meaning of the Individual States

Each of these states is an object with at least two key values:

State	Description	a (active)	t (timestamp)
`open`	Cover is open or was last opened	`0` / `1`	Time the open occurred
`close`	Cover is closed or was last closed	`0` / `1`	Time the close occurred
`shading`	Cover is in shading mode	`0` / `1`	Time shading activated
`shading.p`	Shading detected, not yet started (Pending)	`0` / `1`	End of the waiting time (for trigger)
`shading.q`	Time shading was actually executed (Executed)	`0` / `1`	Time executed
`vpart`	Partly open for ventilation (window tilted)	`0` / `1`	Time activated
`vfull`	Fully open for maximum ventilation (lock-out protection)	`0` / `1`	Time intervention
`manual`	Manual operation detected (UI, switch, etc.)	`0` / `1`	Time intervention
`v`	Version of the status format	–	–
`t`	Timestamp of last global status change	–	Unix time

Cover Status Helper - State Overview

This table provides an overview of the different states used in the Cover Status Helper for Home Assistant Blueprints. Each row represents a specific scenario with corresponding binary values for each state variable.

Scenario Description	`open`	`close`	`shading`	`vpart`	`vfull`
Cover is open	1	0	0	0	0
Cover is closed	0	1	0	0	0
Shading active, then returns to open	1	0	1	0	0
Cover is still closed, then moves to shading instead of fully opening	0	1	1	0	0
Lockout protection active when closing	0	1	0	0	1
Window tilted – no lockout, cover moves to ventilation position instead of closing	0	1	0	1	0

Common Errors with the Cover Status Helper

Helper length too short?

Yes, the default input_text max length (usually 100) is too short. CCA stores status in JSON; make sure to set max: 254.

Can I use 255 characters?

Yes, CCA accepts 254 or 255. Just avoid anything less than 254 to ensure proper functionality.

Why is my helper empty even after deploying CCA and executing the first triggers?

If created with wrong length, CCA can’t read/write to it. Fix the length and let CCA run on the next trigger to refill it.

Can I reuse one helper for multiple roller blinds?

No, each cover automation must have its own unique input_text helper. Sharing will break functionality.

crandler · January 28, 2024, 9:48am

nice, thank you!

Loi · January 28, 2024, 4:20pm

Happy Release Day
Thanks again for all the work you put in.As a shift worker, I am very happy about the resident mode. But what I’m missing is an additional block that doesn’t open the blinds, for example during school holidays or weekends.

Herr.Vorragend · January 28, 2024, 4:52pm

Hi Loi, you can control all of this via the conditions.

Eimeel · January 29, 2024, 2:51pm

But you should be able to achive this by using the resident mode, shouldn’t you?
As it’s an input_boolean is just for this, you can create an automation and define however you want.
Or am I missing your point?

Loi · January 29, 2024, 3:05pm

You’re right about resident mode. But I only have one presence detector in the bedroom and if it doesn’t recognize me or my wife, the shutters open. It is easier not to open the shutters on certain days. @Herr.Vorragend gave me the tip about the Additional Conditions For Opening The Cover and I’m going to test that now

Eimeel · January 29, 2024, 3:24pm

I see. But still I would prefer to use this with resident mode. Create a new input_boolean and set to true on all days you don’t want the shutters to open.
Guess it’s easier than dealing with additional conditions.

Loi · January 29, 2024, 3:28pm

Oh dear… you’re so right. I didn’t even think about this possibility. Thank you.

snoekieboe · January 29, 2024, 3:44pm

I just started to use this blueprint but luck is not yet on my side.
in my application i want to use the blueprint just for shading in combination with screens i have installed in my home.

Regardless of what i try i cannot make this blueprint control my screens for shading alone.

I made sure to:

Configure a cover to control
selected the shading option (6) as only enabled option)
under the shading option i’ve set the:
start and end azimuth (65/220)
the start and end elevation (6/90)
i’ve set 0% as the setting to close the screen for shading (this is when my screens are fully closed)
i’m using the default weather forecast conditions and made sure the forecast entity exists

triggering the automation manually or wait for sun elevation and azimuth to become true, no dice.

Must be something obvious i am doing wrong but i cannot seem to find out what.

HELP!

Eimeel · January 29, 2024, 4:28pm

You need to post your configuration.
And - as stated in the documentation - it’s NOT possible to manually trigger this blueprint.

gyle · January 29, 2024, 5:01pm

i’ve testet the blueprint with the following config:

it went down at 17:00 pm although i set sun_elevation_down: -10.2 wich should have been after 5pm!?

anything i’m doing wrong or a bug?

alias: "Rolladen: Isabella Tür"
description: >-
  fährt nach Sonnenauf- /untergangszeiten, aber nur innerhalb des Fensters (7-9
  Uhr)

  Beschattung ab 18 Grad
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    shading_forecast_sensor: weather.openweathermap
    blind: cover.rolladen_bella_tur
    time_up_early: "07:00:00"
    time_up_early_non_workday: "08:00:00"
    time_up_late: "09:00:00"
    auto_brightness_options: auto_brightness_disabled
    sun_elevation_up: 0
    time_down_early: "17:00:00"
    sun_elevation_down: -10.2
    drive_delay_fix: 5
    drive_delay_random: 0
    position_tolerance: 5
    shading_azimuth_start: 158
    shading_azimuth_end: 258
    shading_forecast_temp: 18
    workday_sensor: binary_sensor.workday_sensor

Eimeel · January 29, 2024, 5:25pm

Could be a bug. Stay tuned.
@Herr.Vorragend see PN

Btw: “fährt nach Sonnenauf- /untergangszeiten, aber nur innerhalb des Fensters (7-9 Uhr)” ist not completely right. It’s opening between 7-9 but closing 17-22.

gyle · January 29, 2024, 5:41pm

yeah i know, my description is not yet final, as the blueprint ist still under evaluation

Herr.Vorragend · January 29, 2024, 6:11pm

Could you please check whether “sun.sun” and the elevation attribute even exist? If not, a default value is assumed which makes the condition apply.

Herr.Vorragend · January 29, 2024, 6:20pm

I hadn’t even thought of such an application. But from the code it should even be possible.
So I need your config to get an impression.

In the worst case, we need a screenshot of the trace.

snoekieboe · January 29, 2024, 6:42pm

alias: SCREENS - Woonkamer groot
description: ""
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    blind: cover.woonkamer_groot
    auto_options:
      - auto_shading_enabled
    auto_global_condition:
      - condition: state
        entity_id: input_boolean.screen_automation_bypass_woonkamer_groot
        state: "on"
    shading_cover_position: 0
    shading_azimuth_start: 65
    shading_azimuth_end: 220
    shading_elevation_min: 6

This is my current configuration. Thanks in advance for wanting to look at this

gyle · January 29, 2024, 6:46pm

yes, it exists:

Herr.Vorragend · January 29, 2024, 6:47pm

One short question:
Could you please show me the state of: input_boolean.screen_automation_bypass_woonkamer_groot?

If automation should work, the conditions must be true or empty. These are conditions and not blockers.

snoekieboe · January 29, 2024, 6:49pm