Message Me

The display was changed to use Paw Patrol as the background.

Also, update the built-in Website.

Reorganized a few of the favorite icons so they can be sent easily from the Displays interface.

I added this line to the document ready to prevent previous messages from getting sent from the phone's browser when the site is reopened.  This removes the get parameters from the URL.

window.history.replaceState(null, null, window.location.pathname);

 My friend's granddaughter is now into Paw Patrol.  So I will probably change the background to that since I will have the device for a couple of days while I fix that bug.

I might even add a few more images to be sent.  

Oh, the top where the screen connects with screws has broken off as well.  Excited little fingers tend to push too hard.

I'm going to print another, but increase the infill and possibly open in tinkercad and add some more bracing around the screw connections.

I was using a GET request on the Build in Web form to post the message to the form, which then gets sent to the MQTT feed.

What I found is that on my phone, sending a message, then moving onto another app, if I open chrome again, it refreshes the page and resends the same message, because its contained in the URL as a get request... /message.html?msg=GoodMorning

So I either need to clear the url, or use a post.

I like the get method, because that opens the door to also send messages just by typing the url and adding the required parameters.

I found this document.

https://stackoverflow.com/questions/22753052/remove-url-parameters-without-refreshing-page

Since I already handed off the devices, I'll have to set up something similar to test on.

Since there is no RTC, I added code to update the time once a week.

I also added a watchdog timer in case it crashes.

With the addition of the time check, I have it reboot itself every 4 weeks only after 2 AM.

Hopefully, this keeps the device working flawlessly forever.

The devices have been handed over for real-world testing since everything always works correctly on my bench/network/machine, etc.

Find out why the web server chokes when serving all the static pages on the first load.

If you are on the emoji screen and receive a new message, it wont know it yet.  Maybe after sending an emoji, also check the REST service again for the number of messages.

Update the Website with a better header image for larger screens.

If no Wifi, instead of going into a reboot frenzy, maybe after X attempts.  Display a message...  "Your wifi is down, press the button to reboot and Try again."

There are two "modes" currently, add a 3rd for no wifi.

Mode 0: Standard bootup and run the publish and subscribe.

Mode 1: HOLDING down button while turning on or holding the button down for 6 seconds got into Mode 1.  It  disables publish and subscribe and be an AP for the config options.

Mode 2: NEW..  No Wifi, do something different.

Maybe add the ArduinoOTA library so I can send my friend any updates I think she should try so I can give this to her to enjoy now while I work on all the new fun.

FInished the HTML files, resized the extra Emoji icons, including some special ones that her granddaughter will love.  One of her making a funny face as well as her mom.

Got all the pages created on the NExtion.

The main, page, the Emoji page and the Setup Page.

Dumped a list of the files in a terminal window from SPIFF and created an excel formula to generate the file syntax for the 17 static files.

example: server.serveStatic("/zepto.min.js", SPIFFS, "/zepto.min.js","max-age=86400");

Change the credentials using the setup page to use my friend's io.adafruit credentials instead of mine.

Put in an invalid Wifi password to make sure I would be able to reset the credentials without reprogramming it.

Glued the MIcro USB connector and button in place. 

Put the screen on, took the screen off, put the screen on and off a few more times enjoying the cool magnetic sound.

Nonstick feet added too.

Sent lots of messages back and forth from the displays as well as the webserver pages.

No errors, seems to be ready.

The HTML file I used has %PLACEHOLDER_SENDFEED% and gets the text replaced with the details from the EEPROM before serving the page. 

This was testing using the ESPAsyncWebServer processor. 

Served several different files as static files but sometimes doing all those files at once causes the ESP32 to lockup and reboot.  Still looking into it.

Only seems to happen on initial loads.  Once the files are cached, no problems.

Setup a subscription feed to retrieve the message coming from the other device.

All files are served, tried adding a websocket connection to send the retrieved subscribe even to the open websocket.  Worked!

Looked up using a captive portal and so many other wifi managers.

Decided to just use a push button and display a simple HTML page pulling the details from EEPROM, and replacing text in a template HTML string.  Saving posts the data to EEPROM and reboots it.

I created the webserver on start.  Learned how to serve up HTML files from SPIFFS.

Used Visual Studio code to create the HTML file, with the images using the Miligram CSS file along with Zepto.js.

Setup a MQTT publish feed and send message on button click. 

Tried to use 1 function for multiple buttons but could't get the button ID from Nextion so ended up creating 6 function, 1 for each emoji button.

Setup a simple button on the Nextion display and setup the ESP32 to communicate and detect the button press.