LIP Protocol Ignores User-Configured Credentials, Uses Hardcoded Defaults

[bulent-1977]

System Health details

System Information

version	core-2026.1.0
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	aarch64
user	root
virtualenv	false
python_version	3.13.11
os_name	Linux
os_version	6.12.51-haos
arch	aarch64
timezone	America/Los_Angeles
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4969
Installed Version	2.0.5
Stage	running
Available Repositories	2551
Downloaded Repositories	32

Home Assistant Cloud

logged_in	true
subscription_expiration	November 22, 2026 at 4:00 PM
relayer_connected	true
relayer_region	us-east-1
remote_enabled	true
remote_connected	true
alexa_enabled	false
google_enabled	true
cloud_ice_servers_enabled	true
remote_server	us-east-1-2.ui.nabu.casa
certificate_status	ready
instance_id	075a8b41652543a5a48da1b839db2065
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 16.3
update_channel	stable
supervisor_version	supervisor-2026.01.0
agent_version	1.7.2
docker_version	28.3.3
disk_total	28.0 GB
disk_used	10.3 GB
nameservers	2603:8000:af00:6100::1, 192.168.0.1
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	green
supervisor_api	ok
version_api	ok
installed_addons	File editor (5.8.0), Samba share (12.5.4), Get HACS (1.3.1), Music Assistant (2.7.3), UniFi Network Application (5.0.0), Anylist (1.7.3), Advanced SSH & Web Terminal (22.0.3), Matter Server (8.1.2)

Dashboards

dashboards	8
resources	18
views	11
mode	storage

Network Configuration

adapters	lo (disabled), end0 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth417a9e4 (disabled), veth6a29fb9 (disabled), veth347b5fe (disabled), veth550ab75 (disabled), veth592493e (disabled), vetha355607 (disabled), veth6fa0afd (disabled), vethc2e7313 (disabled), veth964b577 (disabled)
ipv4_addresses	lo (127.0.0.1/8), end0 (192.168.3.176/22), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth417a9e4 (), veth6a29fb9 (), veth347b5fe (), veth550ab75 (), veth592493e (), vetha355607 (), veth6fa0afd (), vethc2e7313 (), veth964b577 ()
ipv6_addresses	lo (::1/128), end0 (2603:8000:af00:6100:e8ef:80fb:caeb:9fea/64, fe80::8f2a:85ff:e353:d616/64), hassio (fd0c:ac1e:2100::1/48, fe80::582e:64ff:febf:5d67/64), docker0 (fe80::447b:1eff:fe6a:d4d6/64), veth417a9e4 (fe80::487c:1aff:fe7b:be2b/64), veth6a29fb9 (fe80::44ed:7ff:fe59:4ceb/64), veth347b5fe (fe80::7476:2dff:fe93:8565/64), veth550ab75 (fe80::10ca:22ff:fe25:3623/64), veth592493e (fe80::e45e:aff:fe54:353f/64), vetha355607 (fe80::ccf2:9dff:fe0f:e005/64), veth6fa0afd (fe80::9cf7:51ff:fe8c:a377/64), vethc2e7313 (fe80::fcc7:34ff:fefd:7c60/64), veth964b577 (fe80::6c52:36ff:feb1:d4fe/64)
announce_addresses	192.168.3.176, 2603:8000:af00:6100:e8ef:80fb:caeb:9fea, fe80::8f2a:85ff:e353:d616

Recorder

oldest_recorder_run	December 24, 2025 at 8:18 PM
current_recorder_run	January 10, 2026 at 9:25 AM
estimated_db_size	999.74 MiB
database_engine	sqlite
database_version	3.49.2

Spotify

api_endpoint_reachable	ok

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Describe the issue

The Lutron LIP integration does not use the username and password provided during setup via the config flow. Instead, it uses hardcoded default credentials (lutron/integration) when establishing the LIP telnet connection to the controller. This causes authentication failures for any Lutron Homeworks system configured with custom credentials.

Reproduction steps

1. Install the Lutron LIP integration via HACS or manually
2. Configure the integration with custom credentials <-- Mine is a Homeworks installation with both username and password fully customized and not the default user: lutron password: integration
3. Attempt to set up the integration <--
4. Observe that the integration fails to connect

Debug logs

I am sorry. I realized that I fixed the issue on my local install and then restarted my Home Assistant before capturing the debug and diagnostic logs. The issue presented itself immediately after installing and configuring the system with an error on the integration with a error prompt "Config flow could not be loaded: 500 Internal Server Error got itself in trouble"

Diagnostics dump

Same as the debug log. Failed to capture before fixing the issue. Sorry amateur mistake.

[bulent-1977]

Root Cause Analysis

The issue spans two files:

1. aiolip/protocol.py

The LIP class has hardcoded credentials at the module level (lines 20-21):

LIP_USERNAME = "lutron"
LIP_PASSWORD = "integration"

The async_connect() method (line 194) only accepts server_addr and does not accept credential parameters:

async def async_connect(self, server_addr):

The _async_connect() method (lines 238-242) uses the hardcoded constants directly:

await self._socket.async_write_command(LIP_USERNAME)
...
await self._socket.async_write_command(LIP_PASSWORD)

2. aiolip/__init__.py

The LutronController class correctly receives and stores credentials in __init__() (lines 59-84):

def __init__(self, hass, host, user, password, ...):
    self.user = user
    self.password = password

However, the connect() method (line 111) only passes the host to the LIP class, not the credentials:

await self.lip.async_connect(self.host)

Suggested Fix

1. Modify aiolip/protocol.py
   Add instance variables to store credentials and modify async_connect() to accept them:

class LIP:
    """Async class to speak LIP."""

    def __init__(self):
        """Create the LIP class."""
        self.connection_state = LIPConnectionState.NOT_CONNECTED
        self.controller_type = None
        self._socket = None
        self._host = None
        self._username = LIP_USERNAME  # Default fallback
        self._password = LIP_PASSWORD  # Default fallback
        # ... rest of init

    async def async_connect(self, server_addr, username=None, password=None):
        """Connect to the bridge via LIP."""
        self.loop = asyncio.get_event_loop()

        if self.connection_state != LIPConnectionState.NOT_CONNECTED:
            raise LIPConnectionStateError

        # Store credentials for reconnection
        if username is not None:
            self._username = username
        if password is not None:
            self._password = password

        self._disconnect_event.clear()
        # ... rest of method

Update _async_connect() to use instance variables instead of constants:

async def _async_connect(self, server_addr):
    # ... connection setup code ...
    
    self._socket = LIPSocket(reader, writer)
    _verify_expected_response(
        await self._socket.async_readuntil(" "), LIP_PROTOCOL_LOGIN
    )
    await self._socket.async_write_command(self._username)  # Changed from LIP_USERNAME
    _verify_expected_response(
        await self._socket.async_readuntil(" "), LIP_PROTOCOL_PASSWORD
    )
    await self._socket.async_write_command(self._password)  # Changed from LIP_PASSWORD
    # ... rest of method

2. Modify aiolip/__init__.py
   Update LutronController.connect() to pass credentials:

async def connect(self):
    """Connect to the Lutron controller."""
    if self.connect_lock is None:
        self.connect_lock = asyncio.Lock()
    async with self.connect_lock:
        if not self.connected:
            await self.lip.async_connect(self.host, self.user, self.password)  # Pass credentials
            if self.connected:
                self.hass.loop.create_task(self.lip.async_run())
                self.lip.set_callback(self._dispatch_message)

Why Credentials Are Stored as Instance Variables

The credentials are stored as instance variables (self._username, self._password) rather than just passed through because the LIP class has automatic reconnection logic in _async_disconnected() (line 261). When reconnecting, it calls _async_connect() again, which needs access to the credentials. By storing them on the instance during the initial connection, subsequent reconnection attempts will use the correct credentials.

Additional Notes

The config flow correctly stores credentials in the config entry (verified in .storage/core.config_entries)
The XML database download works correctly because it uses HTTP (no authentication required for /DbXmlInfo.xml)
This issue affects both RadioRA 2 (GNET) and Homeworks (QNET) controllers when custom credentials are configured

[rzulian]

@bulent-1977 sorry for the late reply. I didn't received any update from GitHub regarding this issue.
I've fixed the issue, if you have time please test it in your setup