Have you confirmed that it is the Uno that stops sending Serial or the that it is the ESP that stops posting to the server ? (probably the latter..) It is a curious little chip.. And on the receiving end you should really make provisions for the rare event that not a complete data-set has been received. Now the delay(100); makes it very unlikely but if it is just not possible, we can get rid if that. (that may be the cause of it somehow.) Also some error-check on your Serial communication is anyway required hwSerial is very reliable, but you do need to check.
Hi -
Thank you for all the advice. I assumed that as the RX/TX LED on the ESP keeps blinking on each card read, the ESP is still functioning properly but simply not receiving the prober information hence it not being published to the MQTT server.
If I disconnect ESP module and monitor on Serial monitor, will this be good indicator on whether the UNO stop pushing the test data to ESP?
Have to say, when I set delay to less than 20s, it keeps reading and posting successfully and data is perfect structure 
Regards,
friedlbasson:
I assumed that as the RX/TX LED on the ESP keeps blinking on each card read, the ESP is still functioning properly but simply not receiving the prober information hence it not being published to the MQTT server.
For instance yes, the TX send could be it saying "Publish failed"
friedlbasson:
If I disconnect ESP module and monitor on Serial monitor, will this be good indicator on whether the UNO stop pushing the test data to ESP?
that was what i was thinking as well, like that we can rule out the Uno code as a cause
friedlbasson:
Have to say, when I set delay to less than 20s, it keeps reading and posting successfully and data is perfect structure
Iwas actually referring to the delay(100); at the end of loop() this gives time for the Serial buffer to fill up, but if the program starts reading and the buffer does not have a full set of data, it will read the incomplete set (and leave the last bit for next time, where it may get added in front of the next string if another ping follows closely after)
There must be a reason for the 20s thing but i can't think of why making a ping every once in a while would make a difference. Have you tried making the ESP publish something regardless of 'fresh' data having been received ?
Deva_Rishi:
There must be a reason for the 20s thing but i can't think of why making a ping every once in a while would make a difference. Have you tried making the ESP publish something regardless of 'fresh' data having been received ?
Hi -
Yes I did. This is what is happening with the debug code I loaded. It will either read and publish a card scan, ot intermittently (every 20 seconds or what ever I set it to), publish 00 00 00 00. If the 'delay' is 20s or less, the static data and and card reads are published successfully. If however I set the 'delay' or 'wait' to more than 20s, it might post a lot of nonsense once nd then nothing, or nothing at al. Not even the static hardcoded data 00 00 00 00. This is what lead me to believe the problem occurred when there is a too long idle period for the serial comms.
I actually recall on another project where we implemented a ping every 5s to keep serial from crashing. Does seem like a work-around but I would prefer fixing the problem.
Thanks for all your help!
friedlbasson:
Yes I did. This is what is happening with the debug code I loaded. It will either read and publish a card scan, ot intermittently (every 20 seconds or what ever I set it to), publish 00 00 00 00.
Yeah i saw that but you are actually getting the Uno to 'force' a ping by sending the Serial.print, i was wondering if it could be done from within the ESP code iow, where is the snag, does the Serial port malfunction or does the client loses it's connection ? I have almost no experience with clients pinging all my ESP ever does is host a site as a server (and then the phone has to do a whole Android UI it's quite a trip...) But i do also want to know what is going on. I found out that placing yield() at strategic places within your program can be a great help, but you know about that i saw, could put one extra just before client.println(), Maybe we have to close the connection every time after use and open it up for every fresh ping, maybe that's it, the connection times-out. It feels like a guessing game to me by now (it always sort of was though)
Hi Deva -
Do you want to me create a hardcoded value to publish straight from the ESP to the server? This works flawlessly as far as I remember. I am very new to C++ so this was one of the first steps I took, setting up WiFi an MQTT Connection in ESP and then post a message to the server continuously, building the code then further. I have to say that I never used a 20s or more delay.
Let me set this up with a long delay between publish and see whether the ESP fails. To be honest, I am close to using NodeMCU instead, for various reasons. I initially used the Uno with onboard WiFi but could never het the WiFi working on this board, so turned to Uno + ESP as it was the only hardware I had on hand. I did order some NodeMCU's and Particle's which arrived today. Much smaller form factor and less wires, but not looking forward to redoing the code
Lets me try the ESP and yield() first and see. Would also like to get to the bottom of this 'problem'.
Regards,
friedlbasson:
I did order some NodeMCU's and Particle's which arrived today. Much smaller form factor and less wires, but not looking forward to redoing the code
Shouldn't be a big deal NodeMCU supports SPI which is what you need, and you have a USB-Serial for use in debugging, it is a much better solution, no more power issues (if there really were any... but you know it is about excluding possible causes) only the RFID library needs to be supported for ESP let's hope it does ! I also want to know what is the actual cause of this problem though, thinking of setting it up myself just to see if i can recreate your issue.
My only problem is that I see NodeMCU requires 5-10V preferably so I will have to get a 7V battery and I am not sure whether it will recharge the battery off the 3.3V pin unless I add a booster module.
With regards to the Arduino setup; I have two builds, one running all power off the Arduino and the other with external power supply, running the 3.3V pin to the RFID and the 5V (regulated to 3,3V) to the ESP. I doubt power can be the issue then, but please try and let me know
I think I mentioned I ran into a similar (not exactly the same) issue before with 6 UNO's communication with Mega via serial in Master/Slave configuration. I suspected cable length to be the cause but resolved it with a constant ping to the master. This time cable lengths dis not exceed even 5cm, so can most certainly not be the problem. Of course being new to C++ I suspected my code at first.
Would be great to hear if your setup does the same. I can share both my code for Uno and ESP if it will help.
Regards
friedlbasson:
My only problem is that I see NodeMCU requires 5-10V preferably so I will have to get a 7V battery and I am not sure whether it will recharge the battery off the 3.3V pin unless I add a booster module.
nodeMCU is a 3.3v module i would try and run it powered via USB and let the RFID suck from it's 3.3vpin. Or power both with 3.3v the nodeMCU on the 3.3v pin not the vIn.
Deva_Rishi:
nodeMCU is a 3.3v module i would try and run it powered via USB and let the RFID suck from it's 3.3vpin. Or power both with 3.3v the nodeMCU on the 3.3v pin not the vIn.This is strange as the base of my NodeMCU clearly indicates to preferebly power with 5-10V. I will try 3.3V and see.
So I should supply power from the battery to the 3V pin instead of VIN? I saw some of the 3.3V pins are both I/O
The NodeMCU is a 3.3v unit, it does contain a regulator between the vIn (to which the 5v USB is connected for instance) and the unit. so if you have 3.3v power just use that. Check this
Hi -
I actually did look at this exact same post
I will try the NodeMCU, but still very curious as to why the setup with UNO is failing. Struggle to let things go, want to solve it 
Regards
I also want to solve things, didn't have time to check your setup, had to do some debugging on my own code.
I have updated my code in the meantime, re-initializing SPI and other things every 20s. This seems to work but I will test more. Here my new code on Uno:
#include <SPI.h>
#include <MFRC522.h>
#define SS_PIN 10
#define RST_PIN 9
char Data [6];
int uid = 0;
String str;
MFRC522 rfid(SS_PIN, RST_PIN); // Instance of the class
MFRC522::MIFARE_Key key;
long wait_tick = 0;
byte nuidPICC[4];
void setup()
{
Serial.begin(115200);
SPI.begin(); // Init SPI bus
rfid.PCD_Init(); // Init MFRC522
for (byte i = 0; i < 6; i++) {
key.keyByte[i] = 0xFF;
}
}
void loop()
{
if ((millis() - wait_tick) > 20000)
{
//Serial.println("00 00 00 00");
SPI.begin(); // Init SPI bus
rfid.PCD_Init(); // Init MFRC522
for (byte i = 0; i < 6; i++) {
key.keyByte[i] = 0xFF;
}
wait_tick = millis();
}
// Look for new cards
if (!rfid.PICC_IsNewCardPresent())
return;
// Verify if the NUID has been read
if (!rfid.PICC_ReadCardSerial())
return;
for (byte i = 0; i < 4; i++) {
nuidPICC[i] = rfid.uid.uidByte[i];
}
printHex(rfid.uid.uidByte, rfid.uid.size);
delay(1000);
rfid.PICC_HaltA();
rfid.PCD_StopCrypto1();
wait_tick = millis();
}
void printHex(byte *buffer, byte bufferSize) {
for (byte i = 0; i < bufferSize; i++) {
Serial.print(buffer[i] < 0x10 ? " 0" : " ");
Serial.print(buffer[i], HEX);
}
}