To clarify, the "HOME" mode is for wirelessly connecting the WIU to a home router / access point, not for connecting a device with the app installed. As you stated earlier, the MTH mode is for the WIU to connect to a home network via a wired connection and/or connecting devices with that app installed directly to the WIU using the wireless signal from the WIU.
I use MTH mode with my WIU which is wired to my home router and connect devices through my router's wireless network and other devices directly to the WIU using the wireless signal from the WIU.
Thanks @H1000 for your reply and tips. Yep, what you describe above is exactly my configuration - I actually ran CAT5E through the attic and down inside the wall so I could "hardwire" my WIU in the event that my connection issues could be attributed to the signal from the WIU to my AP. I keep the Samsung Galaxy connected directly to the WIU using the MTH SSID and my other devices are connected via my network. What is odd is I can see the DHCP lease for the Samsung Phone on the WIU LuCi but I still see the transient "No WIUs/TIUs Found" message in the app on that device:
It does seem to be more reliable after a few refresh attempts within the app, but I'd expect if the phone has an active DHCP lease from the WIU, it should be able to discover on the first or second try.
I have researched some of the discovery process and it appears to be a simple IP scan on a particular port. There has been some discussion in the past about how the WIU is discovered by the app. I have found it better to statically assign an IP address in the LuCi web console on the WIU vs. a static DHCP address assigned by the router.
I set the IP statically for my WIU from the LuCI but am still seeing the "No WIUs/TIUs Found" when using my Google Pixel on my home network with no ability to discover after multiple refresh attempts.
Okay, now some troubleshooting can happen directly on the WIU just by looking at the indicator lights. I have had the stuck horn issue you described and using the lights on top of the WIU I was able to diagnose the problem. In my case, when the Horn was stuck I would press the horn button on my phone app (connected to the WIU via wired) and could not see the blue light flash indicating network activity. Then I tried the horn on my tablet (connected via the WIU wireless) and saw the Wi-Fi light flash and the horn shut off. I can't recall if the TIU light also flickered to indicate that it received the command from the WIU (I think it did but will confirm that functionality this evening). It turned out to being a problem with my phone, I rebooted it, and it worked like a champ again.
Thanks for the tips regarding the LEDs - the behavior is consistent with my experience, I can "see" the WIU receiving my commands via the Blue LED and can confirm TIU connectivity is solid via the pink/purple LED. The problem is really establishing the initial connection with my preferred device (Google Pixel) to even get the Blue light to flicker :-)
Are you using more than one WIU?
Nope, just one WIU and one TIU
I think I am going to see if I can find a used DCS remote somewhere and give that a go. At the end of the day if that gives me a more reliable connection/experience, I'll just use that rather than the app. I do enjoy the "exercise" of troubleshooting the network/WIU/etc, but on the other hand sometimes I just want to run trains :-)
I will try a WireShark packet capture this weekend to see what I can find. I am interested to learn how discovery works, as it has to be leveraging some sort of multicast protocol (whether Avahi, mDNS, or something else). I do see the WIU listening on TCP 38715, which makes me think that once it is discovered, commands are sent via that port
