Hi there. I am writing that, just in case somebody has done it already, and can light the way a bit.
I must say I use esp-idf(Platformio) for my current project.
chatgpt said to send via WLAN per udp, make a small server for listening on pc(on udp), and then use a read-only terminal(for security/my idea) to just display utf-8 and ANSI escape codes.
If this is the best way, I can manage it myself, just asking if the general approach sounds reasonable.
Maybe someone has already done it all, and I could save some work.
mqtt might be what you need. I posted example code on your other thread.
Yes. thx I read that already, and I was in the process of answering.
Maybe you can post it here?
It maybe the solution 
thx for the code, this is a different approach. Good to know about.
I don't use stuff I don't understand fully. Pretty sure I don't need to send it half way around the world to a server and back to my pc. (Security, not the esp32, but my pc connected to it)
(This makes sense if you need to save ALL the log)
I have long term data storage via Binaryfiles and sd-card.
Just wanna log in quickly to see the monitor(logging), no need to save it all.
Here chatgpt listed Pros and Cons, reasonable?
It's ChatGPT so not totally believable but I don't have many quibbles. My setup did not use the internet, the server was a RaspberryPi 4 on the same network.
I think you mentioned security was a concern. Let me tell you a litle story.
My wife got a call from her Visa asking her if certain transactions were hers. They were not, so the agent froze her card and removed ALL the recent transactions my wife could not identify. They then sent her a new card.
I was driving down the road one day a few months later and got a similar call with the same results. What I noticed was that there was only one business that ws at the intersection of both our incidents. The company in Canada is synonymous with the telephone. I just happened to know the nae of the contractors that they employed around that time. I don;t want to get sued so I won't mention there name but it was along the line of 'A bunch of kids doing stuff'. I noted the name at the time as very unprofessional and was quite surprised to see it associated with the phone company.
Just an FYI.
If you want the possible solution in your other thread to show up here, you can post a link here back to there. I have done what I thought was needed. Just a friendly tip, you might want to learn how mqtt messaging works, it is really good for logging or debugging. I think at the moment you have blinders on and are not receptive to new ideas.
So the morale of it? it can happen anytime anyway?
That's why I asked here, to get a different perspective.
And when using mqtt which seems to be a bit more complicated, then I need to know WHY it is better than udp.
This is exactly the reason why I posted the chart by chatty gpt, to get your veto, what advantages it did not see maybe.
So why you say I am not receptive to new ideas, when in fact the whole post is about a different idea than chatgpt got,... is a mystery for me 
UDP. I know it isn't the official name, but I was taught at IBM that it means UNRELIABLE data protocol. That is the LAST thing I want for my logging since it is almost guaranteed to lose the very message I need to see.
As far as a bit more complicated, you are right. Assuming any esp32 sketch is using WiFi the extra complicating code is 2 includes, 1 global, 3 objects, i setServer in setup and changing all the Serial (except begin) statements to mqttLogger.
The way it works, if the Serial port is connected the messages go there and if the mqtt server is running a copy goes there but both can be disconnected and then the messages go in to bit bucket.
What I do NOT know but suspect is that you may be able to take advantage of the mqtt publishing to a specific topic or even a topic hierarchy and/or * match to allow selective capture on the pi or whatever server you want, I have one on my iPhone and 4 on my Mac.
They are all tools to be used as you see fit.
Good luck.
Hi @quantummagic ,
coming back to your question:
-
UDP is usually used send single messages with
- a limited number of bytes
- where a loss of data is not crucial or the applications take care to handle loss of packages and the order of messages
-
TCP is usually used to send larger messages where the TCP stack (software) takes care that all packages are received and sorted in order before they are handed over to the final application.
TCP is a "connection based" protocol where the client connects to a server.
UDP is "connectionless", so no integrated connect/disconnect functions. That would be up to the application.
MQTT usually uses TCP for the data transfer, it is an application protocol (organization of the application data) while TCP and UDP don't care about the content of the messages they transport.
This is what Wikipedia tells about the limitations of UDP:
Sources:
https://en.wikipedia.org/wiki/User_Datagram_Protocol
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
The unreliablility of UDP aims at Its missing internal mechanisms to identify loss of packages, to request missing packages from the server and to correct the order of packages. See here
So if your data length is within the limits using UDP plus an application specific acknowledge it could be safe enough ...
ec2021
P.S.: Here a link for MQTT https://en.wikipedia.org/wiki/MQTT
I use TCP (as @sonofcy also recommended) to transfer logged data from a SD via an ESP32 to a PC client. The client is written in Free Pascal (Lazarus IDE).
A nice feature is that Serial as well as the the WifIClient are Streams. So you may switch the output between Serial and TCP "online".
Here just some short code snippets
Stream* Terminal;
WiFiClient client;
void setup() {
Serial.begin(115200);
Terminal = &Serial; // This sets Terminal to the address of Serial
// ...
}
Terminal = &client; // This sets Terminal to the address of the WiFiClient
Terminal->println("This goes to the client");
Terminal = &Serial;
Terminal->println("This goes to Serial");
This way you can write the print routines once and just switch the stream to direct them either to Serial or to the WifiClient.
Thanks for showing us that approach. I will grab it and file it in my code folders somewhere. I really need to clean them up LOL.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.