Integration reports everything as 'unknown' after upgrading to 2024.7.0 (beta)

[Ndrinta]

Just a heads up. Not sure if the devs are aware but I've tried upgrading to 2024.7.0b02 and later to b04 and in both instances the integration wasn't functional anymore.
Maybe this has been resolved already but worth mentioning 🙂
Keep up the good work! 💪

[canton7]

Thanks for the heads up! Anything in the logs indicating what the problem is? What does the Connection Status entity say?

[FozzieUK]

confirmed, these are the logs from startup

2024-07-01 11:00:46.787 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up foxess_modbus platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in _async_setup_platform
await asyncio.shield(awaitable)
File "/config/custom_components/foxess_modbus/sensor.py", line 26, in async_setup_entry
async_add_devices(create_entities(SensorEntity, controller))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/foxess_modbus/inverter_profiles.py", line 330, in create_entities
return inverter_connection_type_profile_from_config(controller.inverter_details).create_entities(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/foxess_modbus/inverter_profiles.py", line 95, in create_entities
entity = entity_factory.create_entity_if_supported(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/foxess_modbus/entities/modbus_integration_sensor.py", line 53, in create_entity_if_supported
return ModbusIntegrationSensor(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/foxess_modbus/entities/modbus_integration_sensor.py", line 84, in init
IntegrationSensor.init(
TypeError: IntegrationSensor.init() missing 1 required keyword-only argument: 'max_sub_interval'

[Ndrinta]

You beat me.

[canton7]

Argh, ok thanks! Irritatingly I won't be able to fix this for another week or so

[Ndrinta]

No need to! Take it easy, no-one's life depends on it, we'll simply delay updating. 🙂

[FozzieUK]

I'm running a slightly older version of the integration v1.11.0 but these are the lines it is referring to -

[bbrks]

If you've upgraded to 2024.7.0 and want to temporarily fix this integration without downgrading, you can:

1. Add from datetime import timedelta near the top of the file.
2. Add max_sub_interval=timedelta(minutes=5), to the IntegrationSensor.__init__ as shown below.

Do it via the file editor and restart HA after you've done this.

[Twilek-de]

The problem is not waiting with an update. The problem is that there is almost no way before updating to check wether some custom integrations might break or not (it was 2 for me in this release). If you have a lot of custom stuff it is not feasible to check each and every repository wether there are issues or discussions. Especially with the break-neck speed of the release cycle of HA. Don´t get me wrong. I am not blaming anyone here, on the contrary I want to thank you for the quick repsonse to the problem and the awesome work you are doing with this integration (almost 20% of my automations depend on it). I was just wondering wether maybe something could be included in HACS that users can mark releases as working for each integration or something of that sort so that there is a quick way to check if clicking the update button is safe.

[canton7]

I think just staying a week or two behind the cutting edge release is a reasonably good way of staying stable! I tend to sit a month or two behind the latest.

[bbrks]

I apply this pretty religiously in my professional life. I've never had a bad experience waiting for a follow-up .1 or .2 release :)

[AndaleR]

Thanks. I have added those lines and the errors seems to be fixed.

Need to wait some time to get data into the energy-dashboard - but it seems to work.

Need to type a note: Wait for the next HA-update and install it some weeks later. But it was the first time in my small setup, so nothing was wrong until yesterday.

[canton7]

The max_sub_interval documentation seems inaccurate, in both that it's required and not optional, but also None is not a suitable default.

Interestingly, using max_sub_interval=None should work, reading the source code. It just reverts back to the old behaviour.

And, indeed, I'm seeing it working fine locally.

[canton7]

Fixed in 1.12.1.