configflow fails if not using name "ltibber"

[mpw96]

curl http://admin:XXXX-XXXX@192.168.96.188/data.json?node_id=1 works from HA host,
curl http://admin:XXXX-XXXX@mpw_tibber_host/data.json?node_id=1 works from HA host,

I'm on latest home assistant and I'm installing 2025.11.1 of this integration, preparation procedure was successful.

I failed to install with ipaddress/hostname and polling/websocket (all four possibilities) with name "local_tibber". This is always the error:

This error originated from a custom integration.

Logger: custom_components.tibber_local.config_flow
Source: custom_components/tibber_local/config_flow.py:188
integration: Tibber Pulse Local (push) (documentation, issues)
First occurred: 19:10:01 (3 occurrences)
Last logged: 19:13:29

Could not connect to Tibber Pulse Bridge at 192.168.96.188, check host ip address
Could not connect to Tibber Pulse Bridge at mpw_tibber_host, check host ip address

As soon as I used "ltibber" (the default value) the configflow succeeded. That was the final desperate try before activating debug log (which I don't have now obviously). That's why I'm filing this as Q&A item and not as an issue.

[marq24]

mhhh I am a bit confused - ltibber is not the default host/IP - it's the default name - this Name have no relation to the destination where the requests will be sent.

But from the messages you have tried to use

• 192.168.96.188
• mpw_tibber_host

as host - the reason why these attempts are failing is unknown - only the activated debug log would show more details... For curiousity it would help - but I expect something like host not reachable...

When you run HA in a docker-container, then using CURL from the host itself is not telling you much - you must run/execute the command from inside of the container... 'docker exec -it YOUR-HA-DOCKER-NAME sh' - but that's a different story.

[mpw96]

Yes, I know ltibber only the name and completely unrelated to the hostname/ip address of the bridge.. But that's the only thing I did differently. And now the integration works.

BTW I'm indeed running HA in a container (using the host network).

I just wanted to inform you about this observation in case someone else has a similar problem. We can as well close this discussion.

[marq24]

Here is my assumption, what could had happen (but of course without the debug-log it's not possible to prove it)...

When setting up the integration, the initial calls that will be made are plain http get requests... Unfortunately the bridge 'sometimes' does not respond with a full dataset (byte sequence) - then the response can't be parsed and then the Integration assume, that there is no valid bridge at the specified host.

This 'sometimes' can be really quite frequent - since it looks like, that the bridge only have a single static byte[] in which the data will be stored - and once the bridge is receiving data from reading-head this byte[] is in an inconsistent state (at least that's my explanation). So when the integration request data (via http get) while the bridge read new data from the reading-head you get this type of invalid data... This is of course not the case, when the websocket is used - since there the bridge decides when there is the right moment to provide new data.

Often rotating the head few degrees can make a major difference in this case - so my current assumption is, that using ltibber is totally unrelated to your overall (=bad) setup experience.

... and also OFFTOPIC: Why so late? [did you just became Tibber customer lately?] And I must also ask, You have a go-eCharger too right?