I'm not sure if this is a good idea or not as this can be easily implemented in a configuration file. There are already simple examples provided in this and the other WSM20 thread since this question has been asked several times for the WSM20:
Personally, I wouldn't expect any button to work by default except Reset. Reconfiguring the button is slightly more difficult with this approach.
I have a problem with my mesh 802.11s network, I created 2 wifi network( plus mesh network):
-home -> for pc and smathphone
-IOT -> for domotic device
Domotic device are Shelly with Tasmota firmware. My house have 2 floor and a big garage in side. I have 3 WSM20 and the Shellys are connected to the better router, but if I reboot Router 1, all devices connect to router 2. When router 1 turn on, the devices remain connected to router 2 even with low snr.
Can I set mesh network to switch ?
PS: When I move in the house with my phone, it's connect fine to the better router. I think the difference is fixed devices or mobile devices.
This is a partial brute force fix at best, but if you have a few problematic stationary clients that keep connecting to the "wrong" AP, they can be excluded from connecting to specific AP's by MAC address here:
It's a clever idea but the esiet way is create 3 AP network ( no mesh). Convert my IOT network in IOT1 (router1), IOT2 (router2), IOT3 for (router3). But I'd like mesh network.
Do you have cables between your WSM20 or can you run cables? This will always be more reliable than a wired backhaul.
The MAC address filter should also work on a 802.11s mesh configuration (what's your backend? b.a.t.m.a.n.?)
I use WiFi backhaul.
I don't use batman but a simple 802.11s
You can try Dawn.
No problem with openwrt 23.05.2
With 23.05 we have a little problem with umdns.
Zeroconfig in wlan roaming
In /etc/config/dawn you modify
network config
broadcast_ip option '192.168.x.255'
and to favor an AP /etc/config/dawn
config metric '802_11a'
rssi_center option '-70'
for example if '-50' will force the AP change if dBm > -50
Maybe, let's see. The case for including is that this button is clearly labeled 'LED' and is supposed to do exactly that, which is why I would expect that button to work as intended also with OpenWRT, out of the box. The argument that everyone can easily do that by themselves is correct (and I am happy that this is the case), but still, I expect the default configuration of OpenWRT to somehow match the expected configuration for the device, as much as possible. Also: the file is already included in the default installation anyway - it just does not contain the logic for this model yet - which is what the request now added.
At my device it is the same, but my space is full
Only Standard Image, mosqitto and tor.... how can I clean it up or extend the partition ?
You can save space by using the firmware-selector to include the required programs from the very beginning. You cannot easily extend the partition. The system is designed to replicate the stock behavior's firmware and to not overwrite anything outside its original partition. You can change that by editing the dts and creating a custom build.
Ok, so from the 128 mb announced on the techdata site. We have only 20 mb...not nice...but ok...I will look where to save space...
Yes and no: There are 128MB, that's correct. The usable size is less, but this is to be expected and the same for all devices: There is the boot loader, calibration data, factory data, firmware backup ... that all take space.
20 MiB usable space is more than most other routers have. And just to clarify it once again: It's designed and built as a router, OpenWrt cannot change that.
Additionally, this device has A/B partitions - two copies of the firmware.
Yes, that is what "firmware backup" refers to 
A custom build with mosquitto-ssl and tor is about 9.1MiB in size - you must have something else installed that is taking up space. You can post your package list (opkg list-installed) and we can have a look.
I found my problem... after clean sysupgrade + reinstall all software packages used space = 7,5 MB.
After a few minutes the space growth to 19 mb.
After the changing "mosquitto" conf to "persistance false" (before no parameter set, default should be false)...it keeps at 7,5 mb ...strange...
Well, the persistance file is most probably on the flash and fills it up. You could move it to RAM, but that doesn't really make sense. Disabling it is probably the best option.
I'm using the Multy M1 already since the beginning with OpenWRT because of the (un)stability of the stock firmware. However I keep having problems with the WDS (also tried Mesh) connection between 2 stations (I don't have the possibility to wire the the unit on the second floor so it has a wireless connection to the 1st floor unit).
The connection is still unstable. I tried a lot of things:
Speed is perfect and on 2.4 GHz / 40 MHz the signal is great as well (SNR35, HE-MCS 7). Still the connection drops after hours to days and won't come back. After restarting both interfaces the issue is gone and they can reconnect again.
Is there an issue in the open source MTK driver or should I look for some setting to fix this?
PS: Tried this on the early snapshot builds from May/June onwards and on 23.05 from RC1, but all builds seem to have this issue.
Sounds similar to my house and I have the same constraint being unable to wire between. However I have rock solid stability and great speed. Massive kudos to the devs for the solution to what I found was unusable stock firmware.
Running the 23.05.0 stable, with no additional packages. Both in AP only mode i.e. disabled DHCP etc. WPA2 psk.
On the ground floor, wired to router, i have 5GHz set to "Access Point (WDS)" mode, and have added the exact same SSID on 2.4GHz in "Access Point" mode.
On the upstairs access point, I set the 5GHz in "Client (WDS)" mode.
The WDS link status reports anywhere from about 680 to 980 Mbps at around -57 to -61 dBm.
Then added two more SSIDs in "Access point" mode, one 5 one 2.4. All the SSID strings and WPA2 keys are identical.
I then configured Fast Transition on all. It works great with seamless video call transitioning.
I changed a few things in my setup again to make the configuration more clean:
Hopefully it will be stable for a longer period of time now!
