I2C Communication with Repetier-Server?

Good Evening,
I'm using Repetier-Server on a Raspberry Pi 4 with a voron2.4 and klipper.
Works good so far!
I have attached a MCP23017 to the Raspberry Pis I2C Bus to expand some buttons and signal LEDs. I can read the buttons and switch the LEDs on and off via a python script.

How can I now communicate with repetier server to initiate actions on button press or show a specific status on the I2C connected LEDs? 
How can I execute GCodes?

In principle it should be the same as with GPIO pins action. The difference is the I2C Bus which serves the data, not a specific pin.
Any idea to implement this? Perhaps reading the content of a specific fifo?
Any help would be appreciated


  • Sending is quite easy from your script to server. Activate servers unix socket feature and just execute the function you want to trigger. See

    on how to send api commands. Example is sending a gcode to printer, but same logic can be used to send any command available in the interface as described in api documentation.
  • Thanx repetier!
    I will give that a try!
  • edited November 2023
    OK:, from the docs:
    "In this example we assume you are on a linux system and put it in your database directory"
    On a Rpi it should be /var/lib/Repetier-Server/database/, right?
    And what filename must the file have that it is read? 
    There is already a extcommands.xml in this folder.

    Sending commands uses netcat, so this seems to be clear and is easy to implement from within python.

    Parsing the answer seems to be more difficult. I have to think about...

  • No not extcommands.xml see
    for possible locations. Filename in database directory is RepetierServer.xml and if you do not have it just use that one in socket doc.

    As long as you only want to send something it is enough to send the data to socket and close it. Only when you want to minitor server with it and you need answers or events you must read the answers and match them to send commands or events.
  • OK, this is clear now. I put the following in /var/lib/Repetier-Server/database/RepetierServer.xml:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <!-- path to unix socket for socket communication - leave empty to disable feature -->
    Then I restart the Repetier-Server:
    sudo service RepetierServer restart

    And there is no /tmp/repetier-server.sock at all!

    I set the permissions for RepetierServer.xml as follows:
    -rw-r--r-- 1 repetierserver dialout 221 Nov 26 12:14 ReptierServer.xml
  • Some more tries: (Just for your info)
    Enabling the sockets via a seperate RepetierServer.xml in the path /var/lib/Repetier-Server/database/ folder does not work here. The file RepetierServer.xml seems not to be noticed.
    If I enable the unix sockets via the first configuration file (/usr/local Repetier-Server/etc/RepetierServer.xml) the socket will be generated and I can use it.
    As I understand right the disadvantage of that location is that it gets overwritten at the next update by standard configuration, right?
    Anyway, I will try now to connect my script via netcat.

  • Yes it will get overwritten. Make a copy with second name in etc so it does not get overwritten
    should that be.
  • OK, I will do as you advised.
    But this is not really unix-like. Normally if there is a config file in a less global position (like the users config file in STORAGE_DIR/database/RepetierServer.xml) this should be used instead of the global one. But anyway, not that important. It works now!

  • edited November 2023
    I found another way to communicate with the printer directly:
    Just send a command to the printer queue:
    echo G28 > /var/lib/klipper/sockets/SLUGNAME
    or with a predefined macro:
    echo LIGHTON > /var/lib/klipper/sockets/SLUGNAME

    This can be easyly integrated into a python script and no modifications in config-files are required. But only for commands to the printer, not to Repetier-Server.

  • Yes for klipper this is a shortcut, but you should note that server does not see you did a homing in this case so shown status can diverge. On new release 1.4.14 it might not be that relevant since we now use the klipper api socket to get infos like temperatures or positions when we think it is idle.
Sign In or Register to comment.