Frequently Asked Questions

Just run the last firmware update.

Connect a serial monitor using putty. Restart your device. The device runs in an initial setup and asks for the hardware configuration.

Enter the needed information using the information on the device's name plate. Afterwards the device will reboot.

The basic information about your device is stored in the nvs partition. If you cleaned that partition or the firmware version isn't able to load the nvs data, you will be asked to enter this data once.

Check, if your controller is connected to the same wifi like your swarm:

• wifi active?
• Correct SSID and password?
• Could you access the status page of all controllers from your PC?

Are you using the RS485 interface?

• Did you change the ftSwarm communication to RS485 on all devices?
• Check cabling: Did you connect all cables? Did you mix up A/B? Did you build a loop?
• Did you set the termination jumpers at the first an the last controller in you chain?

Some users reported this issue using Arduino IDE 2.0. Please use the latest 1.X version.

If you run a wifi ssid scan, you will see for each controller an own SSID e.g. ftSwarm4711. There is no difference between controllers running in AP and client mode.

Ignore the additional SSIDs. This is a known issue.

All ESP32 controllers us a watchdog, to identify infinity loops and to stop the execution.

while (switch->isReleased());
motor->setSpeed(200);

blocks a core until the switch is closed. The watchdog identifies this infinity loop and aborts the program. It's better to use

if (switch->ToggleUp()) motor->setSpeed(200);

in your loop function. Since the loops is restarted again and again, the if statement is executed regularly. The motor starts as well. The watchdog is fine, because the loop function terminates. Using delay keeps your watchdog healthy, too.

The webside shows the motor's state correctly (e.g. running), but the motor doesn't run.

This is a known issue, and fixed with firmware 0.4.1.

Please check your 9V power supply. To work properly, the device needs a 9V power supply. USB Power isn't sufficient.

Your Kelda is providing your swarm's SSID, all swarm members are connected correctly. After you flashed some code on your Kelda, the swarm isn't working correctly.

If you check in detail, your Kelda shows "waiting on hardware" while initializing some remote stuff. (ftSwarmControl writes an error at the OLED display, ftSwarm has blue LEDs.)

Flashing and/or rebooting your device will restart the wifi stack as well. Since your Kelda provides the SSID, all other devices in your swarm will loose their connection and are not able to reconnect. With restarting the swarm members, they will connect to the SSID again. Your Kelda's program connects now to the remote stuff and is working fine.

Since it's stupid to restart all swarm members after flashing/rebooting your Kelda, you should change the device providing the SSID. Every swarm member could provide the SSID as well. If possible use your home wifi and run all devices in client mode.

To explain the behavior, imagine a ftSwarmControl running the following code. (This behavior fits to all kind of inputs.)

void loop() {

  switch ( local_S1->getToggle() ) {
    case FTSWARM_TOGGLEDOWN:  Serial.println("S1 released."); break;
    case FTSWARM_TOGGLEUP:    Serial.println("S1 pressed."); break;
  }
  
  delay(250);

}

Running the program and pressing/releasing the button, you will get alternating S1 pressed. and S1 released. messages. But in some cases, you will get two S1 pressed. in sequences without no S1 released. message.

The swarm checks all 25ms the state of all inputs. Getting the state of S1, the firmware compares the actual state (e.g. pressed) with the last state (e.g. released.). Now the input's toggle state is set to FTSWARM_TOGGLEUP.

Keep the button pressed, max. 250ms later your loop checks the state and sends S1 pressed to the serial monitor. local_S1->getToggle() resets the input's toggle state to FTSWARM_NOTOGGLE. Next time the loop evaluates local_S1->getToggle(), there is nothing to display.

After you released the button, the toggle state switches internally to FTSWARM_TOGGLEDOWN. Your loop will send S1 released to the serial console.

But if you release and press the button during the 250ms wait time, the input's toggle state changes two times. Releasing the button to FTSWARM_TOGGLEDOWN. Pressing the button again, it will change to FTSWARM_TOGGLEUP. Now the delay time ends, the switch statement tests on the input's toggle state and sees FTSWARM_TOGGLEUP. So you get two S1 pressed. messages in sequence.