Hello I have had a WIFI channel sensor running under the arduino framework for about 6 months (I use this to monitor if ESP devices are swapping WAPs). The code for the sensor using the arduino framework is:
Yes I would like the actual WIFI channel. I do have the BSSID but I donât find it very user friendly. I could convert the BSSID to the channel but I would prefer not to do that as if I the channels change on the routers I would need to remember to do it in the conversion.
Yesterday I spent quite sometime looking at Mahko_Mahkoâs above reference from line 314 and this would be an ideal solution that would be framework independent. Through the use of get_channel() on the WiFiAP object for a client connection.
Unfortunately it seems it is impossible to obtain the required WiFiAP object it operates on as it is protected and no function of WIFIComponent allows you to get the correct WiFiAP object. WIFIComponent does have a function get_ap() but this only returns the WiFiAP object when the controller is operating in access point mode rather than client mode. There is a second WiFiAP object in WIFIComponent that is inaccessible which is used for the client connection.
I can see only two solutions add a function to WIFIComponent that allows you to get the protected WiFiAP object, or somehow override the C++ protection (I dont know how as I am a lot happier with C than I am C++)
I think it is in principle possible to go directly to the underlying ESP-IDF framework to extract the channel, with code something like the following. but this fails to compile as I am pretty sure I need to include the framework headers and I cant work it out how to do this.
I just posted it to Discord, I have also started to read up on how to install an ESPhome development environment, I just have a lot more to take in for that option.
C files listed under âesphome: / includes:â get compiled and linked automatically. They can #include esp-idf framework header files. Also, header files listed under âesphome: / includes:â get included by the generated main.cpp and can declare functions so that they can be called from lambdas. For example, this can be placed in the esphome: section:
includes:
- idfWifi.h
- idfWifi.c
and when idfWifi.h contains this:
extern "C"
{
int idfWifiGetChannelNum (void);
}
and idfWifi.c contains this:
#include "esp_wifi.h"
int idfWifiGetChannelNum (void)
{
wifi_ap_record_t ap_info;
if (esp_wifi_sta_get_ap_info (&ap_info) != ESP_OK)
return (-1);
return (ap_info.primary);
}
then esphome yaml code can define a text_sensor using code like this:
You need to include the steps that maartenwrs wrote on Jun 26 as well as the sensor template that I wrote. (I am still using this on ESPhome version 2024.8.0 so it should still work)
I just tried this, and created the includes and added them to my config. It seems to compile, and then at the very end during linking, it errors out and says:
/config/esphome/living-room-sensor.yaml:91: undefined reference to `idfWifiGetChannelNum'
/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/living-room-sensor/src/main.cpp.o: in function `operator()':
/config/esphome/living-room-sensor.yaml:94: undefined reference to `idfWifiGetChannelNum'
/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: /config/esphome/living-room-sensor.yaml:97: undefined reference to `idfWifiGetChannelNum'
The relevant section of my config is:
text_sensor:
- platform: template
name: Living Room Sensor AP
id: living_room_sensor_ap
lambda: |-
std::string out;
if (idfWifiGetChannelNum() == 1) {
out = "Office";
}
else if (idfWifiGetChannelNum() == 6) {
out = "Porch";
}
else if (idfWifiGetChannelNum() == 11) {
out = "Living Room";
}
return out;
update_interval: 60s
It is a bit odd as it looks like it hasnât included the c file in the compile to me, hence why it cant find it at linking. I am still using this on 2025.3.1 so i expect it should still work, although I am not using 2025.3.3 yet.