Bug with 10.2.0 inside "cost_tracker_*.py" files leads to failure to load sensors
edwin-jones opened this issue · comments
Describe the bug
Installing the latest version of the add on (10.2.0) causes issues where sensors cannot be loaded due to a bug in some logging code. Commenting this out seems to resolve the issue.
Reproduction steps
Install the latest version of the add on (10.2.0), configure you octopus account, reload HA and check for messages, debug logs confirm the issue with errors.
Expected behaviour
There are no errors related to logging.
Tariff Code
N/A
Integration Version
10.2.0
Home Assistant Version
2024.1.3 (Docker Container)
Fresh Install?
After upgrading
Home Assistant Logs
2024-04-06 18:18:43.718 ERROR (MainThread) [homeassistant.loader] Unexpected exception importing platform custom_components.octopus_energy.sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/loader.py", line 842, in get_platform
cache[full_name] = self._import_platform(platform_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 859, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/config/custom_components/octopus_energy/sensor.py", line 48, in
from .cost_tracker.cost_tracker_month import OctopusEnergyCostTrackerMonthSensor
File "/config/custom_components/octopus_energy/cost_tracker/cost_tracker_month.py", line 139
_LOGGER.debug(f"Tracked entity for '{self.entity_id}' updated from '{self._tracked_entity_id}' to '{data["entity_id"]}'. Reloading...")
I think it's something to do with the entity id literal in the f string of the log, perhaps because we're using " " to enclose it without escaping the variable value?
Confirmation
- I confirm that I cannot find my solution within the documentation
- I confirm that I cannot find my solution within the FAQ
Hello.
I'm not personally seeing this issue on my instance and I'm on the same version of HA but using HA OS (or whatever it's called these days) instead of a docker container. Could you see if it's due to data["entity_id"] by changing
_LOGGER.debug(f"Tracked entity for '{self.entity_id}' updated from '{self._tracked_entity_id}' to '{data["entity_id"]}'. Reloading...")
to
new_entity_id = data["entity_id"]
_LOGGER.debug(f"Tracked entity for '{self.entity_id}' updated from '{self._tracked_entity_id}' to '{new_entity_id}'. Reloading...")
Thanks
Think I'm also seeing this, I've tried to downgrade but the dropdown just reverts to 10.2.0 no matter what earlier version I select.
I'm on 2024.3.3 running HA Core.
I'm afraid I can't help with debugging as travelling tomorrow, but just wanted to confirm the issue.
Update: tried the new service method of switching to a new integration version (downgrading in this case), which failed (for any version tried) with:
"Failed to call service update.install. The version 10.1.4 for this integration can not be used with HACS"
Update: tried the new service method of switching to a new integration version (downgrading in this case), which failed (for any version tried) with:
"Failed to call service update.install. The version 10.1.4 for this integration can not be used with HACS"
If you're using the update service, you need to specify v10.1.4. I believe HACS supports downgrading, but not sure.
I am failing to recreate this locally (got to love python sometimes), so I've fixed what I believe is the issue in v10.2.1
Thanks, adding the v appeared to work, though I didn't restart to test as I then realised 10.2.1 was already available, so I've updated to that - thanks for the super quick fix!
I see this has been patched in #826 - do you still need another repro? If I take the latest update it's going to remove the problem anyway.
The problem was patched blind as I couldn't recreate it locally. If it's fixed the original issue, I'll close this issue :)
Closing as I believe this is now fixed.
Tested this on 10.3.0. I can confirm the new code is there ('{new_entity_id}' instead of data["entity_id"]) and the ocotopus sensors are functioning as expected. I think we can consider it closed. Thanks again, your work is very much appreciated! 🙇