core: New Weatherflow integration - Config Flow Failed

It’s just bad practice to move devices around the network in order to make them work. I have everything banged up in an IoT LAN and the old HACS-based integration worked fine with this set up. Sometimes I think the easiest solution is to also treat HA as hostile and condemn it to the IoT LAN as well…

Still, for any integration I don’t think it is unreasonable to expect the ability to specify the target IP rather than relying on auto-discovery. Furthermore, using a target IP is also much quicker as there is no need to scan for the end devices or to sit there waiting for some broadcast traffic to appear…

On Mon, 9 Oct 2023, at 04:15, meanpandamedia wrote:

@ChirpyTurnip https://github.com/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.

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

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: @.***>

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.

In the beginning I also had UDP errors because the WeatherFlow2MQTT AddOn was still running. After removing the AddOn the Weatherflow core integration is working fine.

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.

Does this mean that there are plans to integrate the REST version into core? It would really be ideal to have the choice of which to use. I’m another one of the many using an IoT VLAN, and would love to be able to keep my Tempest on that VLAN and not have to mess with UDP forwarding in pfSense. Thank you for your work on this!

I figured it out. After some research, I discovered that the updated weatherflow uses UDP to communicate and my tempest was on my IoT network and therefore not routable to communicate. After moving the weather station to the same LAN as my Home Assistant, it connected immediately.

@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.

@jeeftor sorry for the delayed response (also, hope you feel better) you are 100% correct. I was able to figure this one out.

When you click the integration in the HA UI, it spawns an AIOHTTP server, and I mistakenly assumed that my HA instance was receiving the UDP packets. I ran a command line Tempest UDP Listener utility and realized it was not. Once I got the UDP Broadcast working again, the conflig flow worked perfectly.

tldr; for anyone reading this in the future, if you see “Config flow could not be loaded: Unknown error” for the WeatherFlow integration in the HA UI, triple check you’re reciving the UDP Packets or it will fail with this error.

I’m happy to modify error messages in any way people think could be useful. I’m open to suggestions. Generally the devs like to keep them simple for translation support but obviously it seems a lot of people are getting suck on subnet / vlan broadcast issues

Yes - useful. To make this work I’ll need to set up a “UDP Broadcast Relay” package/addon on my firewall…then I can snaffle traffic UDP traffic destined for UDP 50222 and forward it to the HA vLAN/Subnet.

Such addons are available for OPNsense, pfSense, and presumably other FWs…though many will not have this option.

It’s a pain, but at the same time it opens the door to letting Sonos speakers (and other such devices) work across vLANs too…so not necessarily all bad.

On Fri, 13 Oct 2023, at 01:09, Jeef wrote:

image https://user-images.githubusercontent.com/6491743/274593686-60401368-4cc8-4ec1-b536-622e8b387c89.png

Is this helpful to add to the docs?

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

Is this helpful to add to the docs?

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.

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

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.

@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