New Weatherflow integration - Config Flow Failed

[ChirpyTurnip]

The problem

Have just uninstalled my old Weatherflow integration (which was via HACS), then I removed the HACS integration, then I restarted HA.

Now I try to add the Weatherflow integration via Services - it spins for a little bit and then it says:

Config flow could not be loaded: Unknown error

What version of Home Assistant Core has the issue?

2023.10.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Weatherflow

Link to integration documentation on our website

https://www.home-assistant.io/integrations/weatherflow

Diagnostics information

Starts with:

Please wait, starting configuration wizard for WeatherFlow Weather

Then after a short delay ends with:

Config flow could not be loaded: Unknown error

The log only shows:

2023-10-05 10:06:55.044 INFO (SyncWorker_13) [homeassistant.loader] Loaded weatherflow from homeassistant.components.weatherflow

Example YAML snippet

N/A

Anything in the logs that might be useful for us?

Not that I can find....

Additional information

No response

[home-assistant[bot]]

Hey there @natekspencer, @jeeftor, mind taking a look at this issue as it has been labeled with an integration (weatherflow) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of weatherflow can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign weatherflow Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

weatherflow documentation weatherflow source _{^{(message by IssueLinks)}}

[travissluka]

I have the same issue. Logs show the following when this happens

Logger: aiohttp.server
Source: runner.py:186
First occurred: 3:02:34 PM (3 occurrences)
Last logged: 7:19:44 PM

Error handling request

[jkaberg]

Might be related or not but I'm not seeing the new "official" integration, only the custom one with 2023.10.0

[tealc]

Might be related or not but I'm not seeing the new "official" integration, only the custom one with 2023.10.0

Same here!

[travissluka]

@tealc @jkaberg silly question, but are you sure you removed the old integration from HACs and rebooted? The new built-in integration won't show up until you do that

[joostlek]

To use the core integration, please remove weatherflow from HACS or your custom_components folder. This way you use the core integration. Keep in mind that the core integration is built off of the custom one, and that the core one doesn't support every feature the custom does.

[jkaberg]

So I deleted that from integrations page and then HACS, then from custom_components/, and restarted HASS. Then I went to setup the new integration Weatherflow and when trying that I get:

Something else that needs to be removed?

[joostlek]

Did you remove the old configuration?

[jkaberg]

Where can I find that? Nothing in configuration.yaml. I guess I used the config flow when setting up the custom integration, but unsure where config that follows that resides

[joostlek]

Don't you have it on your integrations page?

[jkaberg]

Don't you have it on your integrations page?

I do have the "official" one

So I removed the old custom integration's config from .storage/core.config_entries (shutdown HASS before doing this) - now it doesn't complain about the integration being setup but throws (Translated to "Configuration flow can't be loaded: unknown error"). No errors in the logs about this

[joostlek]

There should be errors in the logs about it tho

[joostlek]

So if there isn't we should take a look in the code why not

[jkaberg]

There should be errors in the logs about it tho

Sorry, got missed at an oversight. I get the error 2023-10-05 14:27:32.371 ERROR (MainThread) [aiohttp.server] Error handling request when it's trying to set up the integration. So same as the first 2 guys

[ChirpyTurnip]

So I'm the same - no trace of the other Weatherflow HACS integration and the Weatherflow integration in the list is the 'official' one:

Same error as @jkaberg, and same issue with nothing obvious in the logs. :-)

Glad I'm not the only one anymore....one's first reaction is always "Crap! What did I do? What did I dooooooo?" :-)

[benquan]

First I removed the old integration, then removed from HACS, I then added the new integration, but it kept saying I was using a custom component. So I erased it once again. restated home assistant, but now when I try to add the new integration [WeatherFlow] I get the following error:

And does not allow me to input the station ID or the key.

[jkaberg]

@benquan Just guessing here but the new integration uses UDP to communicate with the local hub which in turn communicates with the weather station. So there should be no need to insert station ID or key, if any I'd imagine an IP adress and port (but the hub broadcasts data? - that would mean no config I suppose)

[benquan]

Thanks @jkaberg, understood. But either way it was showing me that message, and now the message has changed to:

[jeeftor]

What platform are you on? If UDP isnt open you wont see anything?

If you have netcat you can run the following:

 nc -u -l 50222

And it should print out a packet similar to this:

{"serial_number":"HB-00068684","type":"hub_status","firmware_revision":"177","uptime":1288997,"rssi":-63,"timestamp":1696606467,"reset_flags":"BOR,PIN,POR","seq":128736,"radio_stats":[25,1,0,3,1016],"mqtt_stats":[124,40]}

If your HA machine can't receive UDP or your network is funky you might have to stick with the cloud version for now

[benquan]

It's running on a virtualbox machine running Home Assistant OS. UDP should be open. I haven't firewalled it other than the default Home Assistant OS settings.

The nc command never responds. Just hangs.

edit: Additional information, the connection from my vitual machine to the network is a bridged connection.

[XinoGitHub]

It's running on a virtualbox machine running Home Assistant OS. UDP should be open. I haven't firewalled it other than the default Home Assistant OS settings.

The nc command never responds. Just hangs.

Same here ...

[mcnutter1]

Same here, new update of HA 2023.10.1 broke the HACS version of weatherflow. The UDP version in this new build doesn't work at all, and the previous REST API one now no longer works... ALSO, FWIW, why in the world would this have switched to UDP! Some people have weatherflows in multiple locations / networks and UDP doesn't work in these scenarios.

[natekspencer]

Same here, new update of HA 2023.10.1 broke the HACS version of weatherflow. The UDP version in this new build doesn't work at all, and the previous REST API one now no longer works... ALSO, FWIW, why in the world would this have switched to UDP! Some people have weatherflows in multiple locations / networks and UDP doesn't work in these scenarios.

If the HACS version of WeatherFlow is properly installed/updated, HA 2023.10.1 should not break anything with it. If you removed the HACS version of WeatherFlow without deleting the existing configuration tied to it, then yes it will appear broken since they use different code and you will need to re-download the HACS version of WeatherFlow to get things working again. As an FYI, if you have a custom component installed that uses the same domain as a core integration, the custom component will take precedence. The UDP version does work, though only locally as you've stated. And in those scenarios, you should still use the custom HACS version. Nothing was switched to UDP, it's just that the UDP local-only version now has an official core integration.

[mcnutter1]

Both the HACS version and the Core version use the same domain, the problem is the config_flow only loads the core UI version making it impossible to configure the HACS version.

Tried re-installing the HACS version and restarting and it still loads the Core config_flow.

the CORE version doesn’t find anything because my tempest hub is on a different network.

stuck here, probably like many others.

Should have ported the REST version into the core, and made the UDP local only version optional.

[natekspencer]

Both the HACS version and the Core version use the same domain, the problem is the config_flow only loads the core UI version making it impossible to configure the HACS version.

Which HACS repo are you using? If it has a config flow file and uses the same domain, it will load appropriately. I've got it working on a machine that way myself.

Should have ported the REST version into the core, and made the UDP local only version optional.

Everyone has there preferences on which should come first, but both can exist in core. It just happens to be that the developers that worked on adding to core started with the UDP version.

[meanpandamedia]

I’m sharing this in case it helps. I had the same issues trying to add the WeatherFlow integration (same error message, same entry in the log). As it turned out my Tempest and HA Yellow were on different VLAN. Once I moved the Tempest to the same VLAN as the HA Yellow, the integration worked as expected.

[ChirpyTurnip]

My HA and tempest are definitely in separate subnets and firewalled off from each other. I would expect that the config flow will allow me specify the target IP address off the base station.... Otherwise things get crazy hard as discovery won't work well in a network which isn't a simple flat structure.

On Sun, 8 Oct 2023, at 11:06, meanpandamedia wrote:

I’m sharing this in case it helps. I had the same issues trying to add the WeatherFlow integration (same error message, same entry in the log). As it turned out my Tempest and HA Yellow were on different VLAN. Once I moved the Tempest to the same VLAN as the HA Yellow, the integration worked as expected.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/101423#issuecomment-1751828232, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUIP7ZT2VMCZHDXXKJMWI23X6HG7DAVCNFSM6AAAAAA5THTNXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJRHAZDQMRTGI. You are receiving this because you authored the thread.Message ID: @.***>

[travissluka]

I’m sharing this in case it helps. I had the same issues trying to add the WeatherFlow integration (same error message, same entry in the log). As it turned out my Tempest and HA Yellow were on different VLAN. Once I moved the Tempest to the same VLAN as the HA Yellow, the integration worked as expected.

That makes sense, though the error was of course cryptic. I'm running on a docker container so hass is on a different subnet than the tempest. I'm not sure what an easy fix would be other than having the ability to manually specify the tempest IP as @ChirpyTurnip mentions

[jkaberg]

My HA and tempest are definitely in separate subnets and firewalled off from each other. I would expect that the config flow will allow me specify the target IP address off the base station.... Otherwise things get crazy hard as discovery won't work well in a network which isn't a simple flat structure. … On Sun, 8 Oct 2023, at 11:06, meanpandamedia wrote: I’m sharing this in case it helps. I had the same issues trying to add the WeatherFlow integration (same error message, same entry in the log). As it turned out my Tempest and HA Yellow were on different VLAN. Once I moved the Tempest to the same VLAN as the HA Yellow, the integration worked as expected. — Reply to this email directly, view it on GitHub <#101423 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUIP7ZT2VMCZHDXXKJMWI23X6HG7DAVCNFSM6AAAAAA5THTNXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJRHAZDQMRTGI. You are receiving this because you authored the thread.Message ID: @.***>

This is the case for me aswell, my Tempest base station is located within an IoT vlan which firewalled tightly. Altho the vlan HASS sits in does have unrestricted access to the IoT vlan, and the router has helper services in place (igmpproxy, avhai brigde etc). HASS in my case sits in an docker with an macvlan interface which has it's own dedicated IP within said subnet.

Never had issues with UPNP/avahi/igmp etc before with this setup, so this would be the first. However seeing as the Tempest basestation does broadcasts to any IP? I can understand why this then fails. Communication from IoT vlan to "hass vlan" is for now not allowed at my place.

[meanpandamedia]

@ChirpyTurnip I agree that being able to specify an IP address during the config flow would be ideal. I also have my IoT devices on their own VLAN which is heavily locked down. I had tried allowing bi-directional communication from the Tempest to the HA Yellow and even tried allowing the Tempest to communicate with the entire VLAN that the Yellow is on and both didn’t work. The only way to get it discovered was to put it on the same VLAN as the Yellow. It’s not ideal but I can still lock down the Tempest.