you cannot flash a factory over http. It needs to be done via usb. So your partition layout is still not correct, you need to do a factory flash once. The pin usage is set for the atom s3 lite, you need to wire the correct pins.
you can only adjust the wifi by changing yaml, WiFi Component - ESPHome - Smart Home Made Simple
Are you running a board in the same batch (ordered at the same time?) as the cn105? You could have a bad one.
Your wifi strength plot was not really good tbh.
I know, did first over USB and next one OTA.
They are different boards, both ESP32-S3, had them laying around.
CNRF
CN105
Donât think itâs bad.. Device is inside hydrobox also.
-30 dBm: This is the maximum signal strength. If you have this measurement, you are likely standing right next to the access point.
-50 dBm: This is considered an excellent signal strength.
-60 dBm: This is a good signal strength.
-67 dBm: This is a reliable signal strength. This is the minimum for any online services that require a reliable connection and Wi-Fi signal strength.
-70 dBm: This is not a strong signal strength. You may be able to check your email.
-80 dBm: This is an unreliable signal strength.
Can this be done only, when compiling or this can be changed in HA also somehow?
your graph clearly shows signal strength ranging from -80 to -55
Yeah, those are erratic situations when the connection fails I think, most of the days itâs stable around -60dB.
ESP TX power issues from bad/cheap devices. Chip might be legit but flawed antenna designs are mostly the issues for that and remedy is to lower TX power. Adding additional capacitor to power input of ESP didnât help.
Found my wifi âjammerâ. It is MySensors nRF24L01 PA LNA (low TX power enabled) gateway/module on rasperri Pi that was close to router.
Just wanna inform, that Iâve bought few m5 units from official website about month ago and now there hasnât been any loss of connectivity.
CNRF on m5stack with room-1-2025-12-02.1.factory.bin
CN105 on ESP32-S3 dev board with f1p v6.5.4 + OLED customization
Wifi signal is still sometimes a mess. One disturber is likely NRF24 network (with AliExpress units) and might be also from the ESP32-S3 N16R8 dev1 board which is also from Ali.
At least currently no disconnections:
Did you try putting the atom outside the unit ?
I was also testing the asgard board and wifi seems to improve a bit. But then again I never had any disconnect issues from the atom (mines came from digikey).
You can see when I installed the new board, but differences are small.
Both of the devices are right on top of the unit.
Havenât had also in a few weeks time.
As I said before, the disconnection issue was related to the other ESP32-S3 module I bought from ALi:
Guess I spoke too soonâŚ
Today at some point Iâve noticed that m5stack was blue and HP was on curve mode which means the CNRF wasnât updating curl (Iâve made a backup mode script).
Connected serial to m5stack and this was output:
timeout was just scrolling endlessly.
Wifi signals at that time
Anyways after resetting m5 from side button, it came back online. Whatâs odd is that CN105 device lost connection to wifi about that time the m5 got online. Thatâs first time that has happened.
Had devices side by side, now Iâve moved them away from each other about half a meter. Will check wifi log later.
E: So overnight it was all good on m5, guess the one to blame is that s3 dev board on CN105, gonna replace it also with m5.
But why didnât the m5stack recover from that wifi connection issue and ran into scan timeout loop?
when It cannot connect to wifi, it falls back to hotspot so that you can reconfigure it. But we might be able to tweak something here (that it would take longer to fall back)
Didnât check for AP.
Maybe the longer delay might be annoying, is there some button triggering possible for AP mode? Or maybe change to AP mode, then again in 5-10min retry old credentials.
According to log @F1p device on CN105 seems to have recovered in about an hour long connection issue. At the same time when CN105 dropped, m5 worked. I didnât intervene there.
Only here triggered reset button on both devices:
blue LED is AP mode.
Yes I know that, but if LED is lit and something goes haywire/freezes in the code, the LED will stay lit, because WS28** needs commands to change state/colour or power loss. Thatâs why I said, that I didnât check/scanned wifi for AP mode.
If it would be pulsating, then that would give some confidence that code is running.
good point, i can change it. But if you see blue led, then its entered AP mode, it wonât recover on its own, so if you see blue pretty sure you had network issues.
Finally changed on 17th around 21-22 the CN105 esp32-s3 dev to atom m5 and switched off my nrf24 devices. On 18th around 10 Iâve turned back on NRF24 devices and slight interference started. Both atoms are on top of HP. Canât find the reason for this occasional higher/lower signal fluxuations over night. Signals wonât match with compressor and canât think of anything else disturbing it. But for now itâs a lot better than it was at first.
âESPHome 2026.1.0 delivers one of the most requested features: automatic WiFi roaming. Devices now switch to better access points after connecting, solving the problem of devices getting stuck on distant APs after power outages or AP reboots.â
Try upgrading to 2026 and see if it improves.
Hello everyone! First of all, a huge thank you to Phil for the incredible work done on reverse engineering the Daikin protocol. Iâve started sniffing and then decoding the frames exchanged between several Ecodan units and the receiver connected to the CNRF port. Iâve observed differences in the initial settings request frames. I have the impression that byte 1 (cf) doesnât correspond to a bitmask of the number of RCs. For a receiver paired with a single transmitter on channel 1, I sometimes get 00, 01, or 04. Do we now have more information on the function of this byte, or am I missing something? Thanks in advance, and sorry if Iâm posting my question in the wrong place.
Hey,
We had moved the CNRF discussion to another topic:
Letâs continue it there - but this bitmask seemed only sent on first connect
Pretty sure we saw this pattern during reversing
RCS: Main thermistor selection
0xff : 1111 1111 TH1 (this prevents current temp syncs)
0xf1 : 1111 0001 RC1 for Z1 (current temp for Z2 is not synced)
0xf2 : 1111 0010 RC2 for Z1 (current temp for Z2 is not synced)
0x21 : 0010 0001 (RC1 for Z1 and RC2 for Z2)
0x12 : 0001 0010 (RC2 for Z1 and RC1 for Z2)
What are you seeing ? Try. to set for z1 and z2 and use different RCx and see what it sends?
CNRF port was very picky, so I am interested what your setup is for snooping the comms?
Thank you for your feedback. After double-checking, I was mistaken. It is indeed a bitmask; my apologies.
My setup: an esp32 in parallel with the receiver, which reads the frames from the RX and TX ports of CNRF on RX1 and RX2 ports of the devboard.
However, Iâm observing the second padding byte as 1 instead of 0:
FC 4C 04 03 10 32 01 FF 00 01 00 00 00 00 00 00 00 00 00 00 00 6A
Have you ever observed this behavior?
