openeew / openeew-firmware Goto Github PK

https://download.openeew.com is now available as a small https server.
It runs in a container - See https://github.com/openeew/openeew-download
It only serves firmware binaries for OTA upgrades.
The firmware, if a new update is required, uses the esp_https_ota() function to download the binary.
The SPIFFS filesystem on the firmware needs to include the server certificate so that the OTA binary is downloaded from a trusted server.

If your WiFi SSID is hidden, it doesn't appear as a match in the WiFi scan. The OpenEEW ESP32 WiFiScanAndConnect() firmware function decides your stored network isn't available because it compares by SSID string name. It then drops into SmartConfig scanning mode even if you've previously used the OpenEEW mobile provisioning app and SmartConfig to connect to this network.

The solution is likely to also store the BSSID mac address of the WiFi router in NVRAM and use that to compare during the network scan.

Continue the abstraction layer work so the firmware is unaware of the MQTT broker.
To the extent possible, write a single firmware that can connect to a variety of MQTT brokers - Watson IoT, VerneMQ, Local subnet mosquitto.

All of the device and MQTT orchestration should be handled via the
https://device-mgmt.openeew.com/activation
endpoint.
With the caveat that server security certificates need to be available for the requested MQTT broker.

With a build from the version150 branch, and only ethernet the sensor doesn't always find the ethernet.

I provision the sensor xx 4D CC CC on a WiFi network and it works.

If I plug in the Ethernet it connects over this ethernet.
Then I remove the WiFI and repower it, it comes up switches to the Ethernet and uses it.
Using a Windows 10 with a powered USB hub, this is what the trace looks like:

OpenEEW Sensor Application
ESP32 WiFi interface ready
Stored networks : 1
ESP32 WiFi started
Completed scan for access points
WiFi Network scan done
8 network(s) found
1: SonicAdslSsid (-47)*
2: LazySky (-73)*
3: AzondeNetSsid (-81)*
....
ESP32 WiFi interface ready
Reading stored networks from NVM
ESP32 WiFi started
ESP32 WiFi started
Found network Arthur2004Sid , xxxxxx
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Found no matches for saved networks
Stored networks : 1
Use hardwired Ethernet connection.
WiFi MAC: A8:03:2A:4D:CC:CC
ETH  MAC: ETH Started
A8:03:2A:4D:CC:CF
A8032A4DCCCC

Waiting for time
LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.ETH Connected
ETH MAC: A8:03:2A:4D:CC:CF
ETH MAC: A8:03:2A:4D:CC:CF, IPv4: 10.66.66.113, FULL_DUPLEX, 100Mbps
LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.Time sync'd
Thu Apr 29 14:26:17 2021

Contacting the OpenEEW Device Activation Endpoint :

Then I move it to another location, where the orginal provisioned WiFi network is minimal signal strength, and different Ethernet hub, it doesn't seem to find the ethernet.
Using an Ubuntu 20.04LTS with a powered USB hub, this is what the trace looks like:

Completed scan for access points
WiFi Network scan done
10 network(s) found
1: AzondeNetSsid (-32)*
2: Lars (-80)*
3: Lars (-86)*
4: DIRECT-58-HP DeskJet 3700 series (-86)*
5: SonicAdslSsid (-86)*
6: Terri (-88)*
7: HomeBaseWifi104 (-89)*
8: Arthur2004Sid (-90)*    **<<<< provisioned Network>>>>>**
9: LazySky (-95)*
10: F089 (-96)*
ESP32 WiFi interface ready
Reading stored networks from NVM
ESP32 WiFi started
ESP32 WiFi started
Found network Arthur2004Sid , xxxxxx
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
Disconnected from WiFi access point
LED_LISTEN_WIFI - Blue
There was a problem connecting to WiFi
Got no match for network
Got no match for network
Found no matches for saved networks
Stored networks : 1
Use hardwired Ethernet connection.
WiFi MAC: A8:03:2A:4D:CC:CC
ETH  MAC: A8:03:2A:4D:CC:CF
A8032A4DCCCC
ETH Started

Waiting for time
LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.Disconnected from WiFi access point
LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.Disconnected from WiFi access point
LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow
.LED_FIRMWARE_DFU - Yellow

Repeated by re-powering the hub a number of times,
Full trace attached
ttyUSB2_2104291054.txt

The dashboard prototype allows a sensor owner to perform an earthquake alarm test on their device. The button sends a
iot-2/cmd/earthquake/fmt/json to the sensor. The message is {Alarm:true} This causes the sensor to beep for 10 seconds and flash the LEDs RED. This feature is available since v1.3.0

The dashboard prototype also allows the sensor owner to stop an earthquake alarm. This is a new feature request and does not yet exist in the firmware.

The proposed implementation would be to send an MQTT topic iot-2/cmd/earthquake/fmt/json to the sensor. The message is {Alarm:false}

This {Alarm:false} message would stop an in-progress Alarm. The buzzer would stop and the LEDs would no longer flash RED.

The firmware currently uses the official Espressif ESP32 OTA functions.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/esp_https_ota.html

The official OTA functions has some limitations. We cannot OTA upgrade the SPIFFS data partition. That might be a blocker if we need to refresh the server certificates.

There are several other open source libraries that provide OTA functionality. Investigate which is best for the OpenEEW use case.

• https://github.com/bitfocus/esp-ota#methods
• https://github.com/chrisjoyce911/esp32FOTA

The LEDs should be turned off at setup / initialization and before calibrating the ADXL355
The LEDs draw substantial power and some laptop USB ports can't provide enough power to the ESP32 to initialize WiFi / Ethernet / Accelerometer.

Turning off the LEDs (which might have been on from a previous boot) at the beginning of setup() significantly reduces the number of brownouts my device experiences (on my laptop)

Add ESP32 functions which disable the brownout detector while calibrating the ADXL355 and then enable brownout detection when calibration is complete.

The firmware only knows the unique WiFi MAC Address of the ESP32. The device does not have a "human identifiable name". This MAC address is the unique Device ID.

The firmware uses this MAC address / DeviceID as part of the MQTT Client ID when subscribing to commands / publishing data to the MQTT broker.

The MQTT ClientID follows a set of conventions defined by Watson IoT Platform.
d:orgId:deviceType:deviceId
eg d:7p7wxk:OpenEEW:A8032A4DCC99
See https://www.ibm.com/docs/en/watson-iot-platform?topic=devices-communicating-mqtt

To keep the firmware consistent across multiple MQTT brokers, we could potentially use d:vernmq:OpenEEW:A8032A4DCC99 (vernmq without the "e" to keep it to a six character orgid - the firmware is written in C and has very specific string buffer sizes)

The firmware subscribes to MQTT command topics specifically for this device. It should only receive command messages that it should act on.

When the device seismic edge processing algorithm detects acceleration exceeding the STA/LTA threshold, it starts to publish event data with its MQTT ClientID.

We need to research how the VerneMQ MQTT broker handles MQTT topic spaces.
We will want to subscribe the seismic detection python scripts to /+/ all the OpenEEW device Client IDs.

Add a MQTT topic to dynamically adjust the STA/LTA threshold.
Some sensors in noisy environments might be too sensitive and might trigger lots of false positives.
It will be important to remotely change the STA/LTA algorithm threshold to reduce the frequency of detection events.

The topic will be
iot-2/cmd/threshold/fmt/json
There will be a stringified json key/value pair passed as part of this topic.
{"thresholdoverride" : double }

Our current firmware allows an ESP32 and ADXL355 to communicate. However the ADXL355 is expensive.

The ADXL345 is readily available and very low cost. For users to get started with a very affordable sensor, perhaps simply an esp32 dev board wired to an ADXL345, we should provide an option in the firmware to replace the accelerometer.

Whilst the ADXL355 is a much better accelerometer, it shares many characteristics with the ADXL345 (FIFO size, startup routine, etc) which should make swapping it out doable.

Datasheets:

• datasheet ADXL355
• datasheet ADXL345

On plugging in my device with a Version150 it sometimes won't boot up.
It continues to try, however I have to unplug, wait a few seconds, then re-plug it in.
Sometimes I have to do this a couple of times before it boots.

The USB is plugged into either an Ubuntu 20.04LTS running through a self powered hub, or a Windows 10 through its own self powered USB hub.

rst:0x3 (SW_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
ets Jun 8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
ets Jun 8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
ets Jun 8 2016 00:22:57

Here is a sample record from the OpenData AWS dataset. You will notice the MQTT message json object.

{"country_code": "mx", "device_id": "006", "x": [-0.01,...], "y": [-0.06,...], "z": [-0.05,...], "device_t": 1617321601.697, "cloud_t": 1617321601.932, "sr": 31.25}

The current OpenEEW MQTT contains an unnecessary {"d":{}} json object.

 {"d":{"traces":[{"x":[0.015,...],"y":[-0.207,...],"z":[1.878,...]}],"device_id":"A8032A4DD5F0","device_t":1619803025}}

This github issue will remove the {"d":{}}

Idea: When doing a power up, it would be useful to list the MAC addresses in a human readable form
This could be used by anybody, or a manufacturing machine, from the terminal when the system powers up.
Currently 1.4.0 the MACs are only listed out following the configuration.
If somebody needed to find the MACs before configuration, they can't.

LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.Completed scan for access points
WiFi Network scan done
10 network(s) found
1: AzondeNetSsid (-44)*
....
ESP32 WiFi interface ready
Found no matches for saved networks
ESP32 WiFi started
ESP32 WiFi interface ready
WiFi Stopped
Waiting for SmartConfig.
LED_WIFI_OFF - White
ESP32 soft-AP stop
ESP32 soft-AP stop
ESP32 soft-AP stop
ESP32 soft-AP stop
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue

then when configured through the App

.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
ESP32 WiFi connected to AP
LED_CONNECT_WIFI - Green
LED_CONNECT_WIFI - Green
LED_CONNECT_WIFI - Green
ESP32 station got IP from connected AP
Obtained IP address: 192.168.1.172
LED_CONNECT_WIFI - Green
SmartConfig received.
Waiting for WiFi
Smart Config done, connected to: AzondeNetSsid with psswd: xxxxxx
Writing network to NVM: AzondeNetSsid,xxxx
Stored networks in NVM: 0
Device has 1 networks stored in NVM
LED_CONNECT_WIFI - Green
WiFi Connected
WiFi MAC: A8:03:2A:4D:CC:B4
ETH MAC: A8:03:2A:4D:CC:B7
A8032A4DCCB4
ETH Started

Use case:
A registered device has stored NVM ram with WiFi Network configured and WiFi OFF, and Ethernet Connected, power cycle. The device incorrectly enters SmartConfig mode.

Expected behavior: The device should MQTT connect and send accelerometer data when triggered. In buildings without WiFi, but hard wired Ethernet, the device should work.

One design goal is to force the user through the Mobile App registration / wifi / SmartConfig at least once. That process will register a owner, location, device.
The firmware accounts for the case where ETH is connected but the device is still unregistered. It correctly forces the SmartConfig loop.

What it should do is check if there is at least one stored WiFi network and ETH connected and allow for that without entering into the SmartConfig loop.

Add a MQTT topic to remotely reboot a device.
The topic will be
iot-2/cmd/forcerestart/fmt/json

With my device WiFi Max4D CC CC with downloaded code from branch version150 (in process) had some heap Corruptions.
This appears to be disconnects/connects on the physical line, there was no manual action.
The ethernet connects to a D-Link DSS16+ 16port switch. I usually use this link with a raspeberry Pi and its never had any problems.
I've posted it here, because of the heap corruptions, but it does recover with a reboot.
There may be other causes for the disconnects/connects

CORRUPT HEAP: Bad head at 0x3ffe8cac.
probably same as before .. but just in case
LED_CONNECTED - Cyan
{"d":{"traces":[{"x":[0.06,0.068,0.079,0.083,0.011,-0.049,0.008,0.075,0.023,0.03,0.091,0.06,0.117,0.038,0.049,0.068,0.102,0.109,0.072,-0.004,0.075,0.057,0.128,0.166,0.023,0.034,0.091,0.091,0.015,0.049,0.019,0.091],"y":[-0.03,0.008,0.034,-0.049,-0.079,-0.087,-0.011,0.087,-0.079,-0.094,-0.064,0.041,0.038,0.106,0.008,-0.181,-0.083,0.045,0.041,-0.117,-0.143,0.004,0.075,-0.128,-0.106,-0.109,-0.106,-0.045,0.068,-0.109,-0.147,-0.053],"z":[2.312,2.199,2.282,2.32,2.267,2.24,2.437,2.263,2.301,2.263,2.357,2.293,2.301,2.323,2.395,2.38,2.263,2.222,2.278,2.278,2.301,2.312,2.342,2.421,2.342,2.376,2.342,2.259,2.274,2.256,2.267,2.256]}],"device_id":"A8032A4DCCCC"}}
Sending 1 second of accelerometer readings in a MQTT packet of size: 656
LED_CONNECTED - Cyan
ETH Disconnected
Previously connected to Ethernet, try to switch the MQTT connection to WiFi
[E][ssl_client.cpp:36] _handle_error(): [data_to_read():287]: (-76) UNKNOWN ERROR CODE (004C)
CORRUPT HEAP: Bad head at 0x3ffe8cac. Expected 0xabba1234 got 0x3ffecfa0
abort() was called at PC 0x40086fe9 on core 1
ELF file SHA256: 0000000000000000
Backtrace: 0x40088f08:0x3ffb8f60 0x40089185:0x3ffb8f80 0x40086fe9:0x3ffb8fa0 0x40087115:0x3ffb8fd0 0x400fc643:0x3ffb8ff0 0x400f8705:0x3ffb92b0 0x400f869d:0x3ffb9300 0x4008e37d:0x3ffb9330 0x40081e46:0x3ffb9350 0x40081fb5:0x3ffb9370 0x4012f5b6:0x3ffb9390 0x4012297a:0x3ffb93b0 0x400d8d48:0x3ffb93d0 0x400d88a9:0x3ffb93f0 0x400d6115:0x3ffb9410 0x400d1d1b:0x3ffb9430 0x400d7b56:0x3ffb9470 0x400d7c60:0x3ffb9560 0x4008ac4a:0x3ffb9590
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
OpenEEW Sensor Application
ESP32 WiFi interface ready
Stored networks : 1
ESP32 WiFi started
Completed scan for access points
WiFi Network scan done
11 network(s) found
1: SonicAdslSsid (-43)*
2: Arthur2004Sid (-49)*
..

ESP32 WiFi interface ready
Reading stored networks from NVM
ESP32 WiFi started
ESP32 WiFi started
Found network Arthur2004Sid , xxxxxx
Got no match for network
LED_LISTEN_WIFI - Blue
ESP32 WiFi connected to AP
ESP32 station got IP from connected AP
Obtained IP address: 10.66.66.110
LED_LISTEN_WIFI - Blue
WiFi was successfully connected
WiFi Connected
WiFi MAC: A8:03:2A:4D:CC:CC
ETH MAC: A8:03:2A:4D:CC:CF
A8032A4DCCCC
ETH Started
Waiting for time
Time sync'd
Thu Apr 22 00:47:40 2021

Make sure NTP is as accurate as possible by using the ESPNtpClient library that could help us get to millisecond accuracy:
https://github.com/gmag11/ESPNtpClient

The ESPNtpClient library is available in PlatformIO. It might be easy to incorporate into the firmware.
I could be added to the SetTimeESP32() function.

NTP.onNTPSyncEvent ([] (NTPEvent_t event) {
        ntpEvent = event;
        syncEventTriggered = true;
    });

We'll have to study the example to see how to merge it into the firmware.

The firmware subscribes to eight MQTT cmd topics that command the firmware to do a task.
The commands are described in https://github.com/openeew/openeew-firmware/blob/main/FIRMWARE.md

The firmware publishes acceleration event data to the MQTT broker on a status topic.

These MQTT topics follow a set of conventions defined by Watson IoT Platform.
Examples:

• iot-2/cmd/earthquake/fmt/json
• iot-2/evt/status/fmt/json

VerneMQ should match these MQTT topics.
This will make moving between MQTT brokers easier.

Before hacking the firmware, write test harness scripts using mosquitto_sub / mosquitto_pub CLI commands to prove that the VerneMQ MQTT broker be configured properly.

For my sensor, I am seeing that it won't connect to the local network Arthur2004Sid that it is configured for. This happens whether it is WiFi or WiFi/Ethernet. (I haven't tested for just Ethernet no WiFi case yet)

This happens also after reboots. That is it was connected to the network, and for whatever reason it reboots, and then it won't reconnect - at least in the following 15minutes.
On power cycling - removing USB C, waiting 5 seconds, and plugging back in, it comes up successfully.

I would expect it to reconnect to a working network - within 5minutes. (Just a time I picked for testing, maybe this could be refined to 1minute)
At this stage, for a production ready hardware node, I would expect it to connect to a network 99.9% of the time.
That is if there was 2000 power cycles for the same device, it may fail 1 time, and require manual intervention.
Is 99.9% at this stage a reasonable target?.
Perhaps to phrase this another way, depending on what the failure mechanism is, it could be that if there are 2000devices, on power failure, one is likely to require a manual intervention.

This is partially a note to myself that I could start looking at it next week when I get some time.
(I am working on a somewhat similar problem, but probably different reasons for a Digi S6 WiFi device).
If this has already been figured out, I'm happy to retest next week (I'm away till the 18th)

OpenEEW Sensor Application (v1.5.0)
ESP32 WiFi interface ready
Stored networks : 1
ESP32 WiFi started
Completed scan for access points
WiFi Network scan done
9 network(s) found
1: Arthur2004Sid (-42)*
2: LazySky (-74)*
3: SonicAdslSsid (-82)*
4: AzondeNetSsid (-85)*
5: mp@home (-88)*
6: Triplets 2.4 (-89)*
7: DIRECT-57-HP OfficeJet 3830 (-89)*
8: HomeBaseWifi104 (-91)*
9: DIRECT-58-HP DeskJet 3700 series (-92)*
ESP32 WiFi interface ready
Reading stored networks from NVM
ESP32 WiFi started
ESP32 WiFi started
Found network Arthur2004Sid , xxxxxx
Disconnected from WiFi access point
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
LED_LISTEN_WIFI - Blue
There was a problem connecting to WiFi
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Got no match for network
Found no matches for saved networks
ESP32 WiFi interface ready
ESP32 WiFi started
Unhandled Network Interface event : 14
Waiting for SmartConfig.
ESP32 soft-AP stop
ESP32 soft-AP stop
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue
.LED_LISTEN_WIFI - Blue

Currently the buzzer will sound an earthquake alert sound if a shake is detected or if the device receives a MQTT message from the regional network declaring an alarm.

Not exactly "music" but we can make the sensor beep different status messages too.

Sensors might be running for many weeks / months and the time on the ESP32 might drift.
At power up, the ESP32 syncs its time. That allows it to connect to MQTT TLS.
That's great but weeks later the time might have drifted.
We should implement a periodic NTP sync. Maybe once a day?
There already is a SetTimeESP32() function that would be called.
Implementation would be an unsigned integer counter in the loop() that just counts up to 86400 and calls the SetTimeESP32() function.

https://github.com/platformio/platform-espressif32/releases
https://github.com/espressif/esp-idf/releases/tag/v4.3

Review release notes / changelog again.
Note any potential breaking changes.
Upgrade development workstation / compile firmware / test

If an Ethernet cable is connected, fully start the Ethernet interface and get an IP address before starting the WiFi.
Handle SmartConfig scenarios when previously registered devices are Ethernet connected.

Currently, when the STA/LTA algorithm detects a shake, it starts to publish the accelerometer data via MQTT.
It doesn't include a timestamp.
The detection correlation algorithm needs this timestamp for analysis.

When I try to build the source code in Main on PIO, I get the following error:

In file included from src\main.cpp:17:0:
src\secrets.h:6:19: error: initializer-string for array of chars is too long [-fpermissive]
 char network[2] = "GR";     // add 2 digit network code, eg GR
                   ^
src\secrets.h:7:19: error: initializer-string for array of chars is too long [-fpermissive]
 char station[5] = "GR002";  // add 5 digit station code, eg ST001

The firmware uses ArduinoJson and over several days/weeks might be affected by heap fragmentation

[E][ssl_client.cpp:36] _handle_error(): [data_to_read():281]: (-76) UNKNOWN ERROR CODE (004C)
CORRUPT HEAP: Bad head at 0x3ffe436c. Expected 0xabba1234 got 0x3ffed498
assertion "head != NULL" failed: file "/home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/multi_heap_poisoning.c", line 214, function: multi_heap_free
abort() was called at PC 0x40135e57 on core 1

The firmware currently blinks the LEDs with a bunch of colors depending on its status.

We should implement a different breathe pattern - some LED indication that the sensor is running the STA/LTA on the edge. Nothing interesting is happening but the ADXL355 sensor is active.

Error Logs:

src/main.cpp:16:60: fatal error: secrets.h: No such file or directory

*****************************************************************
* Looking for secrets.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:secrets.h"
* Web  > https://platformio.org/lib/search?query=header:secrets.h
*
*****************************************************************

compilation terminated.
*** [.pio\build\esp32dev\src\main.cpp.o] Error 1
============================================================ [FAILED] Took 5.57 seconds ============================================================

Trying to build on Platform IO VS Code extension on Windows 10

The dashboard will implement a "Remove your sensor from the OpenEEW network" button. It promises that your sensor will no longer contribute data.

• The dashboard could delete the Cloudant record which would wipe the uuid ownership / latitude / longitude / what regional network it belongs to.
• That would not stop the device from sending data however.... The device doesn't know - its stateless.
• The dashboard could send the MQTT command to turn off the ADXL accelerometer so it doesn't record/send data. When the device restarts, It will start sending data again.
• Create a MQTT topic to "reset to factory defaults" - It would remove all WiFi SSID/password from NVM ram. That would force the device into SmartConfig Provisioning mode.

it might be nice to have a more informative string "OpenEEW-<last 6digits MAC>
The firmware currently sets the hostname to "openeew-sensor-eth" or "openeew-sensor-wifi"
If you do an scan on your local network, you'll find the openeew-sensor device.
It would be easy to add the MAC address to the name.

This is handled in the NetworkEvent() function.

The OpenEEW device was running for many hours, silently calculating the STA/LTA algorithm. I had set the threshold very high because this is a test device. I slightly bumped the desk it was on. I noticed the device started to blink blue after it restarted and connected to the wifi network.
Running v1.5.1

Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). ExException in thread rx:

--- exit ---

As I wrote up this github issue, I restarted the board. It ran for a few minutes fine. Then I bumped the USB cable. It started sending data to the cloud. I stopped it by sending it a message to send 1 second of data. Then I set the threshold high again. Similar crash a few seconds later. This log captures the entire sequence:

Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
STA/LTA = 4.002535 = 0.332290 / 0.083020 (2)
Start sending 5 minutes of live accelerometer data
Sending 10 seconds of accelerometer readings in a MQTT packet of size: 6057
Calculating STA/LTA from 352 accelerometer readings
STA/LTA = 4.244476 = 0.360995 / 0.085051 (2)
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178285}
Sending 1 second of accelerometer readings in a MQTT packet of size: 644
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178286}
Sending 1 second of accelerometer readings in a MQTT packet of size: 647
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178287}
Sending 1 second of accelerometer readings in a MQTT packet of size: 644
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178288}
Sending 1 second of accelerometer readings in a MQTT packet of size: 649
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178289}
Sending 1 second of accelerometer readings in a MQTT packet of size: 648
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178290}
Sending 1 second of accelerometer readings in a MQTT packet of size: 640
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178291}
Sending 1 second of accelerometer readings in a MQTT packet of size: 646
Calculating STA/LTA from 352 accelerometer readings
{"traces":[],"device_id":"A8032A4DD5F0","device_t":1620178292}
Sending 1 second of accelerometer readings in a MQTT packet of size: 648
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178293}
Sending 1 second of accelerometer readings in a MQTT packet of size: 641
Message arrived [iot-2/cmd/sendacceldata/fmt/json] : {"LiveDataDuration":1}
Send live accelometer data to the cloud (secs):1
Calculating STA/LTA from 352 accelerometer readings
{"traces":[{"x":[]}],"device_id":"A8032A4DD5F0","device_t":1620178294}
Sending 1 second of accelerometer readings in a MQTT packet of size: 645
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Message arrived [iot-2/cmd/threshold/fmt/json] : {"ThresholdOverride":30}
Previous STA/LTA Shake Threshold :  4.00
Override STA/LTA Shake Threshold : 30.00
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Calculating STA/LTA from 352 accelerometer readings
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). ExException in thread rx:
Traceback (most recent call last):

As an insurance policy if download.openeew.com server certificate renewal does not work correctly, the firmware now supports a legacy OTA download site - mybluemix.net.
We will be able to put recovery firmware binaries on the Cloud Foundry mybluemix.net server.

I also saw brownouts while running the OTA function. Turned off the LED and disabled the ESP32 brownout detector.

Allows mounting of sensor on floor.

This is a suggestion:
setting up workflows on github is a really useful feature while merging huge PRs as it checks for any build errors before merging.

For eg. Some contributor like makes a PR and is a huge patch that might have mistakes in it that they might have submitted without actually building. Then github will just show build failed thus making the maintainer's job easy as they can just tell the contributor to fix the code first.