Problem with the data receiving

Hello! My problem is that I have to make a server via Python, that receives and prints out the data constantly, which is sent by an Arduino Nano. Now, when I run my program, it prints it once and then prints empty messages.

Here is the program:

import socket
import time
def start_server():
    host = '' 
    port = 5000

    server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_socket.bind((host, port))

    client_socket, client_address = server_socket.accept()
    return client_socket

def receive_data(client_socket):
    with open("/home/Me/Desktop/data.txt", "w") as file:
        while True:
            data = client_socket.recv(1024).decode().strip()

def main():
    client_socket = start_server()
if __name__ == "__main__":

This set up has to deal with networking protocols, and Arduino code, and low level hardware, and whatever operating system provided/shared or peripheral’s internet connection the Arduino’s connected to. So there are not only a lot of failure points, there’re almost no end of potential problems in the loop, most of which have nothing to do with any Python code.

Keep it as simple as possible, start by communicating over the serial port, and work up from there. I found the PySerial library to be great. Just make sure you’re not running the Python code at the same time the Arduino IDE is reflashing over the same serial connection.

Other than that, getting data on and off of Arduinos and other devices is a solved problem, with many solutions. There are hundreds of libraries and examples out there to use, without writing having to write code that manages anything at the level of socket. The Arduino forums are very helpful indeed.

Also look into MQTT and the Paho library.

1 Like


curious if your code needs a handshake. That is, does it need to transmit a message back to the Arduino Nano stating that it has received the message correctly. In C, when working with HW, I know that there is usually a checksum. Is there an analog here? Could that be missing in the code?

Maybe the Arduino is waiting for that confirmation before sending additional packets/messages?

General principle: After a socket has been closed by the other end, recv() will return an empty string. So it’s possible you’re running into a problem at the Arduino end.

Can I send you the Arduino code too? So you can look at it

Paul via Discussions on <> ezt írta (időpont: 2024. febr. 26., H 20:00):

I have never worked with an Arduino before. This is something that you will have to look up in the Arduino Nano documentation in the communication section. From a practical standpoint, at least for me, it is just a pc board with a pre-selected microcontroller that has been predesigned for the consumer for convenience.

I have worked on a communication protocol using C. There, when we communicated between receiver and transmitter, for every packet received, we had to perform a checksum to validate that the correct information was received. I am not saying that that is what is required here - maybe Python already takes care of it in the background (? verify ?). What I am suggesting is to look into it to see if that is what is missing or not before going on a wild goose chase. There is a probability that it is not required and just as much that it is.

A good thing to think of, but in this case, communication is being done over TCP, so everything to do with transmission reliability is handled at a lower level.

Lower level implies C. So, this is something that the developer (@Beluga) will have to mitigate prior to Python code in their Arduino application (I am making the assumption of C, here)? Is this what you mean?

Well, I meant lower level in the protocol stack. Application logic usually only concerns itself with the top layer or two of the OSI model, and in this case, TCP is guaranteeing transmission reliability at layer four. So long as you’re using TCP sockets, all of that is taken care of.

1 Like

Thank you for clearing that up.

@Beluga - well, based on @Rosuav response, this is one less potential issue that you have to worry about. :wink: