TouchKIO: Scaling Factors For URLs After Reboot

Dec 4, 2025 by Alex Johnson 48 views

TouchKIO: Configuring Scaling Factors for Preconfigured URLs After Reboot

Have you ever set up a fantastic wall display using TouchKIO, meticulously configuring scaling factors for each URL, only to have those settings reset after a reboot? You're not alone! Many users find themselves in this situation, especially when using TouchKIO for wall displays controlled via Home Assistant. This article dives into the issue of scaling factors resetting after a reboot in TouchKIO and explores potential solutions and workarounds.

Understanding the Scaling Issue in TouchKIO

When using TouchKIO for wall displays, particularly those integrated with Home Assistant, the ability to set different scaling factors for various URLs is crucial. Imagine having multiple web servers, each displaying content that requires a unique zoom level for optimal viewing on your display. TouchKIO's flexibility in preconfiguring URLs via the Arguments.json file is a huge advantage. You can seamlessly switch between these URLs using Home Assistant, creating a dynamic and informative display.

However, the problem arises after a reboot. Despite diligently setting scaling factors for each URL within the Home Assistant dashboard, these settings often revert to the default value of 1.25 after the Raspberry Pi (or whichever device TouchKIO is running on) restarts. This can be frustrating, requiring you to manually reconfigure the scaling each time the system is rebooted. The fact that restarting Home Assistant or refreshing the HA dashboard doesn't reset the scaling indicates that these factors are managed locally within the TouchKIO browser itself. This local handling, while beneficial in some scenarios, creates the challenge of persistence across reboots.

The core issue is the lack of a mechanism to save and restore these URL-specific scaling factors across system restarts. TouchKIO, in its current state, doesn't inherently store this configuration data in a persistent manner. This means that each time the system boots up, it loads the default scaling settings, overriding any previously customized values. This behavior can be particularly problematic for deployments where the display needs to operate autonomously, without manual intervention after a power outage or scheduled reboot.

Why is Persistent Scaling Important?

Configuring persistent scaling in TouchKIO is paramount for several reasons, especially in professional or automated display environments. Imagine a scenario where a digital signage display in a retail store needs to show different web pages for advertising, product information, and news feeds. Each of these pages might be optimized for a specific resolution or layout, necessitating different scaling factors to ensure they are displayed correctly on the wall-mounted screen.

If the scaling factors are not persistent, any unexpected reboot – whether due to a power outage, a software update, or a system crash – will result in the display reverting to its default scaling. This can lead to a distorted or unreadable display, negatively impacting the user experience and potentially conveying the wrong information. In a retail setting, for example, a mis-scaled advertisement could appear unprofessional and deter customers.

Furthermore, the need to manually reconfigure scaling after each reboot introduces significant operational overhead. For deployments involving multiple displays or remotely located devices, this manual intervention becomes impractical and costly. A system that automatically restores the correct scaling factors after a reboot ensures a consistent and reliable display experience, minimizing downtime and reducing the need for on-site support.

Beyond retail, consider applications in industrial control rooms, transportation hubs, or public information kiosks. In these environments, displays often present critical real-time data, and consistent scaling is essential for accurate information delivery. A failure to maintain proper scaling could lead to misinterpretations of data, potentially causing errors or delays. Therefore, implementing persistent scaling in TouchKIO is not merely a convenience; it’s a crucial requirement for ensuring the reliability and effectiveness of these display systems.

Potential Solutions and Workarounds for TouchKIO Scaling Reset

Addressing the issue of scaling factors resetting in TouchKIO requires exploring potential solutions and workarounds. Since TouchKIO doesn't currently offer a built-in mechanism for persistent scaling, we need to consider alternative approaches to achieve the desired behavior.

1. Modifying the `Arguments.json` File

One potential solution involves directly modifying the Arguments.json file to include the desired scaling factors for each preconfigured URL. This approach would require some scripting or manual editing of the file, but it could provide a persistent configuration that survives reboots. The idea is to add a custom parameter to each URL entry in the Arguments.json file, specifying the scaling factor. TouchKIO would then need to be modified to read and apply these custom scaling factors during startup.

This approach would involve the following steps:

Identify the relevant section in the Arguments.json file: Locate the array of URL configurations.

Add a scalingFactor parameter to each URL entry: For example:

{
  "url": "http://example.com/page1",
  "scalingFactor": 1.5
},
{
  "url": "http://example.com/page2",
  "scalingFactor": 0.8
}

Modify TouchKIO's code to read and apply the scalingFactor: This would likely involve changes to the browser's initialization or URL loading logic.

While this method offers a direct solution, it requires familiarity with JSON syntax and potentially some programming skills to modify the TouchKIO codebase. Additionally, it's important to note that modifying TouchKIO's core files might make future updates more challenging.

2. Using a Script to Set Scaling After Boot

Another workaround involves creating a script that runs automatically after the Raspberry Pi boots up. This script would use the TouchKIO API or command-line interface (if available) to set the scaling factors for each URL. The script could read the scaling factors from a separate configuration file or even from Home Assistant via its API.

This approach offers greater flexibility as it doesn't require modifying TouchKIO's core code. The script can be easily adapted to different configurations and can be updated without affecting TouchKIO itself. The steps involved would be:

Create a configuration file: This file would store the URL-to-scaling-factor mappings (e.g., in JSON or YAML format).
Write a script (e.g., in Python or Bash): The script would:
- Read the configuration file.
- Use the TouchKIO API or command-line interface to set the scaling factors for each URL.
Configure the script to run on boot: This can be achieved using systemd services, cron jobs, or other startup mechanisms.

This method is more complex to set up initially but offers a more maintainable and flexible solution in the long run.

3. Leveraging Home Assistant Automations

If you're already using Home Assistant to control TouchKIO, you can leverage its automation capabilities to set the scaling factors after a reboot. This approach involves creating an automation that triggers upon system startup and sends the appropriate commands to TouchKIO to configure the scaling.

The process would involve:

Creating Home Assistant entities for each scaling factor: These entities would store the desired scaling values for each URL.
Creating an automation: The automation would:
- Trigger on system startup (e.g., using the homeassistant.start event).
- Read the values from the scaling factor entities.
- Use the TouchKIO integration (if available) or the Home Assistant REST API to send commands to TouchKIO to set the scaling factors.

This method offers the advantage of centralizing the configuration within Home Assistant, making it easier to manage and monitor. However, it relies on a reliable connection between Home Assistant and TouchKIO and requires familiarity with Home Assistant automations.

4. Requesting a Feature from TouchKIO Developers

Ultimately, the most robust solution would be for TouchKIO to natively support persistent scaling factors. Consider reaching out to the TouchKIO developers and requesting this feature. Providing them with detailed use cases and explaining the benefits of this functionality can help prioritize its implementation in future releases.

Implementing a Script-Based Solution: A Step-by-Step Guide

Let's delve deeper into implementing a script-based solution, as it offers a good balance between flexibility and maintainability. We'll use Python for this example, but the concepts can be adapted to other scripting languages.

Step 1: Create a Configuration File

First, create a configuration file (e.g., scaling_config.json) to store the URL-to-scaling-factor mappings. This file will be read by the script to determine the desired scaling for each URL. Here's an example:

{
  "http://example.com/page1": 1.5,
  "http://example.com/page2": 0.8,
  "http://example.com/page3": 1.2
}

Step 2: Write the Python Script

Next, write a Python script that reads the configuration file and uses the TouchKIO API (assuming one exists) or command-line interface to set the scaling factors. If TouchKIO doesn't have a formal API, you might need to use a library like requests to send HTTP requests to TouchKIO's web interface or a library like subprocess to execute command-line commands.

Here's a simplified example assuming a hypothetical TouchKIO API:

import json
import requests

def set_touchkio_scaling(url, scaling_factor):
    # Replace with the actual TouchKIO API endpoint and authentication details
    api_url = "http://touchkio.local/api/scaling"
    headers = {"Content-Type": "application/json"}
    data = {"url": url, "scaling_factor": scaling_factor}
    try:
        response = requests.post(api_url, headers=headers, json=data)
        response.raise_for_status()  # Raise HTTPError for bad responses (4xx or 5xx)
        print(f"Scaling factor for {url} set to {scaling_factor}")
    except requests.exceptions.RequestException as e:
        print(f"Error setting scaling factor for {url}: {e}")

def main():
    try:
        with open("scaling_config.json", "r") as f:
            config = json.load(f)
    except FileNotFoundError:
        print("Error: scaling_config.json not found.")
        return
    except json.JSONDecodeError:
        print("Error: Invalid JSON in scaling_config.json.")
        return

    for url, scaling_factor in config.items():
        set_touchkio_scaling(url, scaling_factor)

if __name__ == "__main__":
    main()

Important: This is a simplified example. You'll need to adapt it to TouchKIO's actual API or command-line interface. You'll also need to handle authentication and error conditions appropriately.

Step 3: Configure the Script to Run on Boot

Finally, configure the script to run automatically when the Raspberry Pi (or other device) boots up. One common way to do this is using systemd services.

Create a systemd service file: Create a file named touchkio-scaling.service in /etc/systemd/system/ with the following content (adjust paths as needed):

[Unit]
Description=Set TouchKIO Scaling Factors
After=network.target

[Service]
User=pi  # Replace with the appropriate user
WorkingDirectory=/home/pi/scripts  # Replace with the script's directory
ExecStart=/usr/bin/python3 /home/pi/scripts/set_scaling.py  # Replace with the script's path
Restart=on-failure

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl enable touchkio-scaling.service
sudo systemctl start touchkio-scaling.service

This will ensure that the script runs automatically after each boot, setting the scaling factors for your URLs.

Conclusion

Dealing with scaling resets in TouchKIO after a reboot can be frustrating, but hopefully, this article has provided you with a solid understanding of the issue and several potential solutions. While TouchKIO doesn't currently offer a built-in way to persist scaling factors, workarounds like modifying the Arguments.json file, using a startup script, or leveraging Home Assistant automations can help you achieve the desired behavior. Remember to choose the solution that best fits your technical skills and the complexity of your setup. And, most importantly, consider requesting this feature from the TouchKIO developers to potentially see native support in future releases. By taking these steps, you can ensure that your TouchKIO wall display maintains the correct scaling and delivers a consistent and professional experience.

For further information on TouchKIO and related topics, you can visit the official TouchKIO Website.