It doesn't look easily doable as far as my limited understanding of netifd goes. There is setup and teardown which take care of full modem setup/teardown and not just bearer. So in my mind even if the "watcher" script is implemented (which looks doable) the process would still go through setup/teardown which takes time with MM, so we could get automatic reconnect but it would be "slow".
There is support for implementing a topology change renew handler, but that's meant to trigger dhcp renew when bridge topology changes and I think it would be super ugly to hook into there.
I think the general problem that the bearer/connection state itself is not really tracked/visible in Linux/netifd outside of MM, and thus handling things like this, but also for example controlling a LED based on packet connection status is really difficult. An example - PPPoE interface is bound to the ethernet interface, so it's normal for the ethernet to be up while PPPoE interface can go down at any point; for QMI the interface is always up, even if you don't have a SIM card inserted, and the only way to get the bearer state is to interact with MM or uqmi etc.
It really seems to work. The only thing is that after executing the celllock command you must give a restart to the WWAN0 interface for the modem to reconnect with the main band selected.
So I locked on the main band B1 and then B7 and obtained as per the attached screens.
EDIT
Then I've disabled cell locking with this command:
I've uninstalled modemmanager because I use these apps (that conflict with modemmanager): https://github.com/4IceG
I use all of them, they work great. Many thanks to @IceG
So in the end for WAN configuration I've "uqmi" and "luci-proto-qmi"
Connection of course is configured to autoconnect (this is default uqmi settings on openwrt) then I use the watchdog monitor by @IceG, part of the apps I posted before:
I ask for further information without the package
"luci-app-lite-watchdog"
does not the uqmi module automatically reconnect
in the event of disconnection?
I would like to avoid using sources other than Openwrt ones...
Have you perhaps noticed and/or understood where the LTE module update files that you updated from version 8 to 13 are written (in which partition/device)?
The modem has its own flash storage it doesn't use the host router partitions. The OEM firmware is probably using its tmp space for manual modem upgrade. I haven't fully tested "offline" upgrade but it should be doable with picocom.
with the original Zyxel firmware no, as it presents problems of disconnections in which the only way to restore connectivity is by restarting, technical support is lacking.
regarding the hardware of the device for me it gets 10/10
I would still buy it again, as I have high hopes from the Openwrt firmware as it is customizable.