What happens when a user changes their SSID password down the road?

I’m very interested in deploying BerryLan with some Pi hardware that we want to ship to customers. At first our process was going to be to ask the user for their SSID and password and hardcode into wpa_supplicant, however there are a lot of issues with that. BerryLan would solve this!

One question I have is if the user changes their SSID or SSID password down the road, can they just open the app and go through the process again?

Hi! Thanks for your interest in Berrylan :slight_smile:

Berrylan is actually just a small abstract from our product portfolio and was always meant to help with the initial setup without any further requirements.
In order to make this whole wireless setup really secure and nice to use, a push button would solve your problem. We have in our stack a version which starts the Bluetooth server only if you press a button for 3 seconds (so it requires physical access for the person who wants to bring the device online). In this way the setup can be started at any time and allows to reconfigure the network, start an access point or connect to a different wireless network. Since we don’t have a button on a plan Raspberry Pi, we implemented different modes, in which the daemon can be started:

  • always: the Bluetooth server runs the whole time, this is very insecure since someone could force the device to connect into a different network. This mode exists only for debug purposes
  • once: this mode starts the Bluetooth only until you have a configured a network. Afterwards the Bluetooth server does not start ever again.
  • offline: this mode starts the Bluetooth server whenever the device is not connected to any network (LAN or WLAN). This is the default mode for Berrylan.
  • start: this mode starts the Bluetooth server after booting for 3 min. Restart the device and you have 3 min to configure your network.

You can configure these modes with the -m parameter of the nymea-networkmanager. You can configure the mode in the systemd service file which can be found in /lib/systemd/system/nymea-networkmanager.service. Detailed description can also be found in the help section: nymea-networkmanager --help.

If you are interested in version which supports the push button control, please let us know, maybe we can help you out.


Oh, I forgot to mention: you can also change the mode in the /etc/nymea/nymea-networkmanager.conf file, which keeps the settings even if you update the package. This is the way how you should configure the behavior.

As to the initial question, if the device was previously associated to an SSID/PSW that was no longer available (it was changed by the router owner), would the device attempt to connect to the previously known SSID, fail and then restart the BT server listening (assuming mode==offline)? In this case, would BerryLan detect and allow another SSID to be associated in the list of wifis?

Hi casahome2000! The nymea-networkmanager is basically a DBus client to the original network-manager.
In the offline mode, the nymea-networkmanager checks if the host is connected to any wired or wireless network, if no connection is available, the Bluetooth server starts.
If, for example, your device was previously connected to a wifi A, then switched to a new network B, and the new network B goes down, the network-manager would pick theoretically the other known network and tries to connect to it. If successfully connected, the nymea-networkmanager would not start the bluetooth server in offline mode, since you are not offline any more. You can check the available connection with the nmcli connection command. I hope this helps :slight_smile:

Got it.
Additionally is there a way to remove previously known wifi networks? For example, connected up to SSID1 and now would like to remove reference/traces of SSID1 from wifi connection manager.

Similar to
$wpa_cli remove_network 0

You can use nmcli for that. First list your known connections

nmcli connection 
NAME                      UUID                                  TYPE      DEVICE 
foo                       5cbe0765-b5fe-4448-90da-15826b2b1e4f  wifi      wlp3s0 

Then you can remove a connection using

nmcli connection delete foo
Connection 'foo' (5cbe0765-b5fe-4448-90da-15826b2b1e4f) successfully deleted.


1 Like

I would like to have the functionality for physical button. please advise.

The button mode in the nymea-networkmanager allows you to start the Bluetooth server advertisement by pressing (long-pressing) a physical button connected to a GPIO. FOr this you need the hardware button, a resistor and you have to know the sysfs GPIO number from the pin where the button is connected to.

Here you can find an example how to connect a button to a GPIO.

Once you have wired the button, you can configure the nymea-networkmanager with the button mode. This can be done by updating the nymea-networkmanager configuration file in /etc/nymea-nymea-networkmanager.conf. The default file looks like this:

Change Mode=button
Set your GPIO sysfs number of the button i.e. ButtonGpio=14

Restart the nymea-networkmanager systemctl restart nymea-networkmanager.service

Now the bluetooth server will only advertise, if you press this button for a few seconds. If you don’t connect within the configured timeout, the server will shut down again.
If you connect and drop the connection, the server will not automatically restart advertisment, you need to press the button again for having the service.

Hope this hepls :slight_smile:

wow this is great. I was using this code for now…

o="$(nmcli connection | tail -n +2)"
IFS=$’ ’
while IFS= read -r line
nmcli connection delete ${tmp[0]}
done < <(printf ‘%s\n’ “$o”)

in your approach, if there is NO wifi connection, do I still need to hold the button? or by default it will turn on the server anyways for default installation?

If Mode is set to button in the config file it will always require a push button press in order to activate the Bluetooth service, even when there is no network connection at all.

I tried this approach and for testing, i set the MODE to “Always”. it works after i restart the service, however if I reboot my raspberry pi zero w, then it does not pick up the “Always” settings, i need to REBOOT the service again manually for this to work.

why would “Always” not work after reboot?

command i am using is “sudo reboot”

What value (ohms) resistor should be used for the GPIO button approach? Is 1000 ohms correct, as suggested by this page?


The resistor should just protect the pin from getting to much current, so yes, 1kΩ (1000Ω) should be fine, if the resistor would be too high, the pin can not recognize the high/low edges any more, but you find exaples up to 120kΩ all over the internet, so everything between those values should be good :slight_smile:

1 Like

Is there a way to permanently change mode=start so that it will keep the Bluetooth server up for a duration different than 3 minutes?

Hi Austin,

yes, you can change the default behavior in /etc/nymea/nymea-networkmanager.conf. Simply change the Mode to Mode=start and restart nymea-networkmanager. This way it should be permanent.

Sorry, I think I may not have been clear. I’d like the mode=start to have a time DIFFERENT than 3 minutes (say, for example, 20 minutes). My understanding from the documentation was that the timeout line is only for offline mode w/ button functionality. Altogether, that means that start mode is automatically set to 3 minutes regardless of the timeout value. Is that the case, or does the timeout line also change the behavior for mode=start?

Again, apologies if I wasn’t clear and thanks for the help!

Oh, rereading your post I could have understood the question correctly, sorry :smiley:

Since I wrote this quiet some time ago I had to to check and noticed, that the start mode actually uses the advertisement timeout as parameter, which should solve your issue:

So the Timeout parameter [seconds] in the configuration file should theoretically specify how log the server is running in the start mode. You can also override that parameter if you start the application with -t <timeout>. Let me know if it worked, so I can update the docs.


Yes, that worked! Apologies for the late response and thanks for the help!