Captive Portal up but already on network?

I am confused. On some devices I end up getting this (image below), which I assume is the captive portal. Or is it?

The problem is this device is already on the selected network at the selected IP. I am getting this display from what should be the web server, NOT the captive portal. It’s not in AP mode, it has associated as a station.

Just to make this a bit more weird, I changed the web-server to port 8080, and did an update via this form. After a reboot I could access this same UI via 8080 not 80, but still cannot get to the normal, correct web-server. Somehow the captive portal is overlaying the regular web server.

If I disable the captive web portal entirely then it works fine, connects to API, normal web server comes up. Except of course if I actually need the captive portal, so I am hesitant to remove it.

This is only one one sort of device (novostellar 20w flood light). And does not happen all the time.

Is there something I could be doing incorrectly? The setup is about as simple as you could expect:

api:

ota:
  password: "xxxxxxxxx"

#captive_portal:

web_server:
  port: 80
  include_internal: true

wifi:
  reboot_timeout: 10min
  domain: .xxxxxx.com
  power_save_mode: none
  manual_ip:
    static_ip: ${ipaddr}
    gateway: 192.168.130.1
    subnet: 255.255.255.0
  networks: 
  - ssid: "Reboot"
    password: "xxxxxxxxxx"

  ap:
    ssid: "${friendly_name} Fallback"
    password: "xxxxxxxx"

Note the reason for the “networks” plural is I have occasionally put in multiple with priorities, but they are not present now. MQTT is not used, just api.

Some bug in all the code that flows into this device (all that is magic to me).

Linwood

Define one dummy template sensor and see if that makes a difference (straw clutching I know).

Thank you, but could you elaborate? I do not know what a “dummy template server” would look like?

Sorry was a typo - which I have fixed. Just create a sensor of some kind and see whether that changes anything.

There are several sensors already defined. And they appear normally in the web display when this failure mode does not occur, which is most of the time. But sometimes it does, seemingly more on one or two of the devices (I have eight).

For example, that same one now (captive portal is disabled) appears thusly:

Hmm - maybe time to logon issue on GitHub:

Well, maybe, except I’m not sure where to put it. So far this SEEMS to only happen with one type of device. It is not easily reproducible, it strikes at random, so I am not certain of that. The device is a Novostellar flood which uses the relatively newly integrated libretiny_pwm platform. I wish I knew whether the real problem lies there, or in the core esphome captive portal code.

I did just turn it back on and this one floodlight immediately reproduced the problem though. I’m not at all sure what to do with that to find the root cause so I can submit an issue (the HA folks are not all that tolerant of mis-placed git postings). Any insight into how to get some kind of debug info to help? The core problem is I cannot connect a USB (it’s a sealed unit) and of course no logging when it goes into this mode.

Postscript: There’s a separate git issue for libretiny and it has a lot of wifi issues, so maybe that is the place. I put one there. https://github.com/libretiny-eu/libretiny/issues/204

Did you ever find a fix for this? I have a sonifi plug that had been running ESPHome, after an update it ran into issues/fell off the network. It’s back on but I still just get the captive portal (and it is broadcasting a fallback hotspot as well.)

No, but I moved and no longer use those floodlights, so I have not worked on it further.