Weird errors when setting up new instances

[brettonw]

Similar to the problem when a dash is in the name, but a different error:

This error originated from a custom integration.

Logger: custom_components.infinitude_beyond
Source: helpers/update_coordinator.py:312
integration: Infinitude Beyond (documentation)
First occurred: 5:04:50 PM (1 occurrences)
Last logged: 5:04:50 PM

Unexpected error fetching infinitude.local:3001 data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/infinitude_beyond/__init__.py", line 81, in _async_update_data
    await self.infinitude.update()
  File "/config/custom_components/infinitude_beyond/infinitude/api.py", line 211, in update
    await self._update_energy(energy)
  File "/config/custom_components/infinitude_beyond/infinitude/api.py", line 235, in _update_energy
    changes = self._compare_data(self._energy, energy)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/infinitude_beyond/infinitude/api.py", line 113, in _compare_data
    for key in old.keys() | new.keys():  # Union of keys
               ^^^^^^^^
AttributeError: 'float' object has no attribute 'keys'

I just set up a new docker container with infinitude and connected my thermostat to it - I have rebooted everything multiple times, but keep getting this error.

[brettonw]

The integration starts - connects, looks good, then everything goes "unavailable". And it stays that way.

[brettonw]

I've tried with three different hosts, and two different switches. I'm dead in the water here. If you have any advice about what could be going on, I'm all ears.

[brettonw]

Looking at the Infinitude source itself (https://github.com/nebulous/infinitude/blob/master/infinitude line 123)... It looks like dumb luck on my part - host names with "infinitude", "carrier", etc. are all bad inside the Infinitude server. Changing the host name to just "inf" worked just fine.

[brettonw]

Probably warrants a "readme" entry, or even an error check during config flow?

[MizterB]

I was able to recreate this - it is not due to the host name (in fact, my host is named 'infinitude' without issue). But I recreated this on a new install, and it is because Infinitude does not retrieve the energy data right away. That should normally not be a functional issue, but it was breaking the some logging logic. This will be fixed in the next release.

[MizterB]

Please re-test in 2024.8.0

[brettonw]

I'm away from home rn, but will retest next week.

[brettonw]

renamed the infinitude host to "infinitude", removed old "inf" config from HA, rebooted HA, readded components using "infinitude" as the host - all worked. Thank you!

[brettonw]

I spent some time yesterday trying to trace a problem with very slow response times, and ended up again at the hostname. Using the hostname "infinitude" for the raspberry pi that is running the containers (2 of them for 2 systems) definitely responds MUCH more slowly (sometimes minutes). It appears to trigger a code path that makes a request out to the carrier servers before it responds to the main request.

Take it as you will, but I would recommend not using these words in the hostname: /bryant|carrier|ioncomfort|infinitude/, and would suggest the integration should warn users not to do that either. I ended up with "hvac", fwiw.

From the code, it looks like you could also set PASS_REQS to 0 in the container environment, but there's a bigger skip overall if you just use a different hostname.

It's line 96 in the latest version of infinitude: https://github.com/nebulous/infinitude/blob/master/infinitude

[MizterB]

What you describe was the result of this discussion / change last year: https://github.com/nebulous/infinitude/issues/177

However, have you set PASS_REQS to 0? It makes a huge speed difference in my setup (no interest in using the Carrier app anyway). I see you could bypass more code with the hostname change, but in my case it seems negligible.