Currently we have an immutable "First On Time" counter that lives in EEPROM and is set at first boot. Since the clock will be inaccurate on first boot, this will cause this counter to be inaccurate.

Lets use the first time the esps-uploader script sets the RTC clock to set the counter and an immutable flag

To make it so you do not have to hard code the WiFi settings have the device initially boot up as an Access Point with a semi random SSID like "ESParaSite-1273" and no password. Use the sign in requirement of the AP force you to the config page. There have it ask for the proper SSID and Password. Once set the device resets and attempts to log into that AP. If it fails it goes back to the initial config state. If it succeeds it goes into standard operation mode.

The request came in as a result of a Photonster hitting a bug in the board firmware. Due to this bug, the printer was rendered powered on and somewhat operational for an extended window, while the cooling fan(s) had been shut off due to said bug. This resulted in potential damage to the LCD, LED and Mainboard components due to potential overheating.

This feature can be built to operate in two mode, selectable by the user via a config checkbox and trivial wiring change (move 1 wire from the N.O. to the N.C. screw terminal ( or visa-versa on the relay board)

Safety shutdown mode

Safety Shutdown Mode puts a Normally Closed relay in line with the 12V power leads as they enter the chassis.

The ESParaSite can then open the relay (shutting down power to the Printer Mainboard).

Advantages

• The ESParaSite is only responsible for opening the relay (cutting the power).
• Printing can be aborted in case of over temperature conditions being reached.
• allows us to control the printer power remotely

Disadvantages

• less features
• If used for remote power on/off, the "off state" becomes dependent on the ESParaSite.

Soft Power Mode

Soft Power mode puts a Normally Open relay in line with the 12V power leads as they enter the chassis.

Advantages

• allows us to control the printer power remotely
• reduces eeprom corruption risk by allowing us to make clean writes and enter sleep mode rather than being at the mercy of when the user turns off the switch.
• allows us to cut power to the unit in case of over temperature conditions being reached.
• Could implement wake on LAN/Wifi and other handy features

Disadvantages

• Relying on ESParaSite adds additional points of failure and complexity
• Successful prints completely depend on ESParaSite stability

There is a slight chance that the Printer in which an ESParaSite is installed may be powered off while a EEPROM Write is in progress (there are 2x 50ms periods per minute in which an EEPROM update is occurring giving us a maximum risk of 100ms/60000ms. (1/100) While this value accounts for the maximum write latency of the AT24Cxx EEPROM chip, it is likely that we would have incorrect or corrupt values.

In order to avoid this, we would need to calculate and store a checksum value on each write. All of the EEPROM values are read at boot and loaded into variables. If this checksum fails during the read:

• we would then fall back to the previous segment of Flash (and continue to fall back until a good value is found)
• we would log an error message for each fallback
• If no good segment is found, we will format the lifetime logging segments of the EEPROM
• Potentially we will add a permanent flag that will be used to declare the EEPROM "bad" and cease logging lifetime counters until the RTC board is replaced.

Potential library
https://github.com/bakercp/CRC32

Controlling a relay via I2C seems to be difficult so this would only be available for "Advanced" boards (NodeMCU/ MiniNodeMCU/ ESP32) or potentially with a mod to an ESP-01s style board

We would use the Chamber temperature sensor and a relay to control the Heater, rather than the heater having its own controls.

Problem: RTC time is set at first on, using a macro inside of the compiler. When distributing binaries, this will no longer provide proper results.

Solution: Add NTP query to esps-uploader.py script and POST feed to ESParaSite to set RTC clock.

the MS1100 is an analog sensor for sensing VoCs.
MS1100-ETC.pdf

This will facilitate GUI updates by allowing us to upload .tar packages of the css, HTML, graphics and JS files. Then we can untar them into the LittleFS.

ESParaSite should have a cohesive UI and therefore we need HTML/CSS templates to wrap our data.

Status page should show

Network Box:
Wifi status and signal strength
IP config
mDNS status

Other Status:
Eeprom last write timestamp
Printer life seconds
FEP life seconds
LCD life seconds
LED Life Seconds
Case Temperature

This page will be used to dump all data we know about the printer in a tabular format.

Add a simple serial console that allows to connect to printers with serial ports like the photon and send and recieve commands via the ESParaSite web UI

Idea Examples;

https://github.com/jeelabs/esp-link

https://www.st.com/en/imaging-and-photonics-solutions/vl53l0x.html
https://www.adafruit.com/product/3317

Vinicius pointed out this family of narrow beam ToF sensors that may be the key to creating a resin level sensor so we can notify when we are low on resin!

This is a Niceto, but I do not know a good method to do this as of now.

Load Cell?
Strain Gauge?
Ultrasonic?

(High cost, High Effort, Low yield)

Problem: Currently getFSInfo(3) relies on a DynamicJsonDocument of size 4096. This will overflow after ~48 files.

Challenge: Due to memory limitations, we cannot operate on data larger than 4k.

We need to rework this function to parse the FS with a counter to 32 files and send the HTTP data in chunks.

see:
https://gist.github.com/spacehuhn/6c89594ad0edbdb0aad60541b72b2388

mDNS will allow us to access ESParaSite via an address like http://esparasite.local or similar.

Reference
https://tttapa.github.io/ESP8266/Chap08%20-%20mDNS.html

GUI page to enable configuring wifi network

Implement untarring of website package when uploaded in tar format.

Current implementation leverages autoconnect, which uses a cached credential set during the WifiManager setup process.

Either copy autoconnect credentials or allow manual entry of the values stored in config.json for fallback.

SPIFFS allows us to treat the flash rom on the ESP8266 as a filesystem.

This will be a key milestone to allow:
Wifi config
logging over time
Fancy Web UI

For ESP8266 devices with >1MB Flash, we will implement historical logging.

Ideally we should be able to detect the type of board in use and adapt the available features based on the board's resources

• ESP01-S has 1MB or 512kB
• ESP12 has 4MB

Initial thoughts
512k model to ONLY do outbound feeds (MQTT/JSON)
1MB model do outbound feeds and data logging
ESP12E/F to do both plus in place upgrades

Advanced Feature. May require 2MB or 4MB board