https://forums.adafruit.com/viewtopic.php?f=66&t=181627

Boards loaded with the tinyuf2 bootloader-only (never loaded with CircuitPython) seem to be not initially mounting the filesystem correctly.

First - what doesn't work:
- On Linux, using esptool-3.1, erase flash, write Fun House bootloader
- On Windows, confirm default demo works
- "Double-click" reset button to get into bootloader
- Copy Beta 5 WipperSnapper firmware
- Board auto-resets, presents red DotStars
- Press reset button
- Open secrets.json in Notepad++ and the file is full of garbage as per similar reports

I didn't exhaustively try to get the above to work, but taking the board after that last step to my Linux box, the file opens just fine. No clue what's going on there, but I suspect it's something in the filesystem code of the firmware, based on what I found gets me a repeatable, good result.

What works:
- On Linux, using esptool-3.1, erase flash, write Fun House bootloader
- On Windows, confirm default demo works
- "Double-click" reset button to get into bootloader
- Copy CP 6.3.0 firmware to HOUSEBOOT drive
- Confirm default CP environment loads
- "Double-click" reset button to get to bootloader
- Copy Beta 5 of WipperSnapper firmware
- Board auto-resets, but doesn't preset red DotStars - instead, presents purple DotStars
- Drive is still named CIRCUITPY, but the secrets.json and wipper_boot_out.txt files are there, along with .fseventd directory, .metadata_never_index and .Trashes files
- Editing secrets.json file works as normal (ie, not filled with garbage)
- Reset board, and IO dashboard (https://io.adafruit.com/docmollo/wippersnapper) shows my Fun House as online
- If I unplug the board and move it to my Linux box, the drive still shows up as CIRCUITPY, but things work fine and the files are there and fine
- Move the board back to my Windows box and secrets.json is still readable.

Display WiFi and MQTT connection status on a board's built-in NeoPixel

De-initialize the pin once we've connected to "free up" the pin for use with Wippersnapper.

Supported Boards:
PyPortal M4
Metro M4 AirLift

Handler for adafruit/Wippersnapper_Protobuf#19

There is no indication of the NINA FW needed, one of my board had not the official AirLift firmware and the WipperSnapper firmware was lost and locked up. The file system was visible but no file accessible, trying to open a file will completely lock things. The Serial over USB is also completely lock. The LED was stuck in Cyan but no way to tell what was going on (see dglaude-001).
Of course WS could not expect a non Wifi firmware and know how to react to it since it only drive the LED… but still there was something unexpected and no way to tell.
Since the guide does not say much about the software requirement on the ESP32 Airlift side…

• dglaude-002

Library needs "plumbing" to implement #28 RequestType CREATE and INVALID for now, handling DELETE in a separate issue.

Replication Notes:

• Create a component on WipperSnapper Web and throttle the account with it
• Device will delay for X seconds til the throttling error timeout ban is lifted
• If the component on WipperSnapper web is deleted, the device doesn't acknowledge it since it was blocking during the deletion call.
• Once the throttling error is lifted, the device attempts to resend data assuming the component is still connected.

Add device support for adafruit/Wippersnapper_Protobuf#36

Beta.5 sought to fix this issue but it's still present for the FunHouse firmware. It's not replicable on the MagTag or Metro S2, which is odd.

11:50:19.804 -> Registering Board...
11:50:19.804 -> registerBoard()
11:50:19.804 -> Encoding registration message...Encoded!
11:50:29.852 -> Publishing registration message...Published!
11:50:29.852 -> Publishing registration message...Published!
11:50:29.852 -> ERROR: Please define a network interface!
11:50:29.852 -> ERROR: Please define a network interface!
....
WDT BITE, RESET

The workflow file currently has the doxygen+deploy script disabled. This repository is currently private and the script can not deploy.

When this repository is made public, we need to re-enable this script.

Additionally, the Doxyfile should contain the following patterns. Nanopb's automatically generated code should not be modified.

EXCLUDE_PATTERNS       = pb.h
EXCLUDE_PATTERNS      += */nanopb/*
EXCLUDE_PATTERNS      += */wippersnapper/*

WS should create a secrets.txt for storing the user's network interface configuration, Adafruit IO Credentials and network settings (SSID, DHCP).

This file should be JSON-formatted.

Impl note: Only activate this on SAMD/nRF52 boards which use TinyUSB

Ref:
https://github.com/adafruit/Adafruit_TinyUSB_Arduino/tree/master/examples/MassStorage
https://github.com/adafruit/Adafruit_Arcada/blob/master/Adafruit_Arcada_Filesystem.h

After loading up Wippersnapper for the first time on a new device, it'll create a secrets.json file and attempt to connect.

We should detect the default username value of YOUR_IO_USERNAME_HERE, and blink the RGB LED yellow to indicate the file needs to be modified from its "default" state.

Broker's registration response should include a reference voltage default for the board's analog gpio, grab and save it.

Currently, TinyUSB is not supported by the ESP32-S2 platform. We may make use of the ESP32-S2's filesystem by:

• flashing the tinyuf2_combo.bin to the funhouse
• flashing Adafruit CircuitPython to the funhouse
• Uploading a secrets.json which specifies native USB (https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/blob/master/examples/secrets-examples/secrets-wifi-native.json)

Adafruit_SPIFlash may read from the CIRCUITPY volume, however, the Wippersnapper_FS class makes use of TinyUSB.

Solution: We should add a FS_ONLY define to the ESP32S2 Funhouse in _boards.h for now. This define will be checked in _FS and not include TinyUSB-related code/objects.

Currently, we fill the pin_value field, sprintf(outgoingSignalMsg->payload.pin_event.pin_value, "%f", pinVal);. This should be using the pin_value_volts field.

https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/blob/master/src/Wippersnapper_AnalogIO.cpp#L249

We aren't formatting the flash with FatFS prior to attempting to mount the USB-MSC device. We should first check if the QSPI flash is formatted/mount-able, then if empty, format w/fatfs f_mkfs() prior to initializing the volume.

Wippersnapper clients should subscribe to the Adafruit IO MQTT broker's reserved error and throttle topics.

If the throttle is activated, the client should attempt to retry re-connection via rules specified in: https://io.adafruit.com/blog/changelog/2017/06/30/throttling-update. Once re-connection to the MQTT broker is established, the Wippersnapper client should execute the Registration FSM prior to listening for commands.

If a user is banned, the client is banned and should be forcibly disconnected from IO's MQTT broker.

https://io.adafruit.com/api/docs/mqtt.html#username-errors
https://io.adafruit.com/api/docs/mqtt.html#username-throttle

Corresponding forum ticket: https://forums.adafruit.com/viewtopic.php?f=66&t=182565

unfortunately, the device never leaves an amber state and the dashboard only shows the device as offline.
note, I deleted the device and it popped back up immediately after reboot, probably a completely unnecessary step, but there you go.

serial output:
Registering Board...
18:56:10.646 -> registerBoard()
18:56:10.646 -> Encoding registration message...Encoded!
18:56:20.731 -> Publishing registration message...Published!
18:56:20.731 -> Publishing registration message...Published!
18:56:40.752 -> Publishing registration message...Published!
18:56:40.752 -> Publishing registration message...Published!
18:57:00.740 -> Publishing registration message...Published!
18:57:00.740 -> Publishing registration message...Published!
18:57:20.758 -> Publishing registration message...Published!
18:57:20.758 -> Publishing registration message...Published!
18:57:40.754 -> Publishing registration message...Published!
18:57:40.754 -> Publishing registration message...Published!
18:58:00.733 -> Publishing registration message...Published!
18:58:00.733 -> Publishing registration message...Published!
18:58:20.730 -> Publishing registration message...Published!
18:58:20.730 -> Publishing registration message...Published!
18:58:40.735 -> Publishing registration message...Published!

--- grab a drink ---

19:07:00.759 -> Publishing registration message...Published!
19:07:20.773 -> Publishing registration message...Published!
19:07:20.773 -> Publishing registration message...Published!
19:07:40.808 -> Publishing registration message...Published!

We should check if boot_out.txt exists on the FS from a CircuitPython installation, if so - nuke the filesystem so the only files on there are wipper_boot_out.txt and secrets.json

Testers who have prvsly loaded their device with CircuitPython and secrets.py seem to be getting confused, let's give them the expected filesystem instead of adding to it.

Issue is blocking on:
adafruit/Adafruit_SPIFlash#100

10:12:41.822 -> No ESP32 module detected!Please upgrade the firmware on the ESP module to the latest version.

Tracking: https://forums.adafruit.com/viewtopic.php?f=66&t=182484

A throttled device should not publish to IO until the throttle period has passed.

17:01:01.552 -> IO Throttle Error: "brubell data rate limit reached, 1 seconds until throttle released"
17:01:01.552 -> Delaying for: 1000
17:01:01.586 -> Executing state-based event on A1
17:01:01.586 -> Publishing pinEvent...Published!
17:01:01.586 -> IO Throttle Error: "brubell data rate limit reached, 2 seconds until throttle released"
17:01:01.586 -> Delaying for: 2000
17:01:01.656 -> Executing state-based event on A1
17:01:01.656 -> Publishing pinEvent...Published!
17:01:01.656 -> IO Throttle Error: "brubell data rate limit reached, 3 seconds until throttle released"
17:01:01.656 -> Delaying for: 3000
17:01:01.656 -> Executing state-based event on A1
17:01:01.656 -> Publishing pinEvent...Published!
17:01:01.692 -> IO Throttle Error: "brubell data rate limit reached, 4 seconds until throttle released"
17:01:01.692 -> Delaying for: 4000
17:01:01.692 -> Delaying...
17:01:05.727 -> Executing state-based event on A1
17:01:05.727 -> Publishing pinEvent...Published!

Describe the bug
Two users report that loading the magtag build of WipperSnapper results in a boot-loop. The WIPPER drive briefly appears, followed by the device resetting. This seems to be specific to the magtag.

Link to forum post or copy-paste from chat or email
https://forums.adafruit.com/viewtopic.php?f=66&t=181544

After replacing demoboot bin with adafruit-wippersnapper-esp32s2-magtag-1-0-0-beta.3.uf2 from bootloader mode, the first reset results in solid red indictors.
Subsequent resets result in a flash of blue/cyan followed by a reset.
The WIPPER drive appears briefly.

Same process (with proper .uf2) works fine for FunHouse.

Different ticket, via email user mwalimu

I attempted to load WipperSnapper on to my MagTag. After loading the MagTag keeps resetting....Nope, didn’t work. It boots, then resets, boots, resets, etc. Is it just me?
OS: Windows 10

Both of these reports are from the same user

Hardware: FunHouse
WipperSnapper Beta.7

I repopulated mine with Beta 7 and it keeps erasing the file. everytime I double click to get to the houseboot, it erases it. I replace it and it does it again.
https://forums.adafruit.com/viewtopic.php?f=66&t=182565&p=887200#p887200

Ok, so I loaded it and it seems to go into an endless reboot cycle. I saw this once when I fat fingered my credentials in the secrets file and it would just keep rebooting. So I double clicked the reset and the houseboot drive comes up, I drag and drop the beta 7 over and it reboots and goes into an endless reboot. I double click the reset button and when the drive comes up, there is no secrets.json file. It's not there. I try to recreate it and drag and drop it on the drive, but when I reboot, it goes into the endless reboot again. I double click the reset button and it's gone again.

The contents of wipper_boot_out.txt should be overwritten on each reboot, not appended to.

We should be able to switch between staging and production servers for quick testing.

1st Report: MagTag

Registering Board...
registerBoard()
Encoding registration message...Encoded!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
IO Throttle Error: "USER data rate limit reached, 1 seconds until throttle released"
Device is throttled for 1000ms and blocking command execution.
Device is un-throttled, resumed command execution
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
Publishing registration message...Published!
IO Throttle Error: "USER data rate limit reached, 1 seconds until throttle released"
Device is throttled for 1000ms and blocking command execution.



I've also removed all components from the device.```

Add GitHub Actions CI

Similar workflow to Adafruit IO Arduino (https://github.com/adafruit/Adafruit_IO_Arduino/actions)

https://github.com/adafruit/Wippersnapper_Protobuf/blob/master/proto/wippersnapper/description/v1/description.proto#L23

Replicated and confirmed:

I just installed beta.5 on an ESP32 Huzzah. Feather The installation went fine but I am unable to get the D13 LED component to work.

We may enhance error reporting by allowing connection/network errors to be written to wippersnapper_boot_out.txt on the filesystem. Users will be able to copy/paste this file (like a stack trace) for error reporting & feedback.

from ticket, dglaude-001:

There is no indication that a WipperSnapper firmware is installed on the device

When I tried to install, there seems to be no way to know that WipperSnapper is running… 
the INFO_UF2.TXT seems unmodified
Device appear as CIRCUITPY but the boot_out.txt contain no indication that we don’t run CircuitPython
Device appear as CIRCUITPY but is not detected as such by Mu or at least it will not talk to the serial (debug of WipperSnapper) so maybe it has another “signature” so it require another tool to see what is on the serial (I used Putty)
Only indication is the empty (zero byte) secrets.json (but that could be a file from a previous attempt)
Only other indication is the CYAN color for the LED.

analogRead() returns 10-bit resolution on this hardware by default, not 12-bit, should be shifted by 6.

Line: https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/blob/master/src/Wippersnapper_AnalogIO.cpp#L141

Display WiFi and MQTT connection status on board's built-in LED.

De-initialize the pin once we've connected to "free up" the pin for use with Wippersnapper.

Supported Boards:
Huzzah ESP32
Huzzah ESP8266

• I2C Component (bus) Initialization
• I2C Scan
• I2C Device Initialization
• I2C Device Deletion
• I2C Device Update
• I2C Device Publishing

The run() event loop doesn't block until a network connection is established:

  // Handle network connection
  checkNetworkConnection();
  // Handle MQTT connection
  checkMQTTConnection(curTime);

  // Process all incoming packets from Wippersnapper MQTT Broker
  WS._mqtt->processPackets(10);

This will cause the subsequent processX commands to fail if there is no network connectivity.

Proposal: Implement a blocking handleNetworking function to try-retry the network connection and mqtt connection until both are established. Block until then.

Add support for ESP32-S2 BSP

The max. number of available digital pin timers is currently hard-coded. This can be resolved by parsing the number of pins returned by a CreateDescriptionMessage

Related issue: adafruit/Wippersnapper_Protobuf#33

Setting up a LED component causes pin LED to turn on. Web interface shows the pin is turned OFF

proposed sln: Manually force it off after pinMode is called.

11:53:19.143 -> cbSignalMsg
11:53:19.143 -> Sub-messages found: 1
11:53:19.143 -> Signal Msg Tag: Pin Configuration
11:53:19.143 -> cbDecodePinConfigMsg
11:53:19.143 -> configPinReq()
11:53:19.143 -> Configured digital output pin on 13

During the net FSM, if a connection (network or MQTT) failure occurs, there's a status LED telling the user which event of the net FSM the hardware is currently in.

When the hardware reboots, users seem confused with "what happened"? The hardware appears to reboot for them and there's no indication where the failure was.

When there's a network connection failure prior to the WDT biting, we should write the type of failure (network connection, registration, or MQTT connection) to the filesystem's boot_out.txt. On the reboot, the user can open up the file and see the root cause of the error.

New board naming rule:

A boardName MAY ONLY contain lower case ASCII letters, numbers, and the dash character (“-”).

Switch old-style names to new boardNames:
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/blob/master/src/Wippersnapper_Boards.h