s7-gateway: an HTTP and Prometheus layer over python-snap7

[Poseidonas]

I kept writing the same snap7 script at work — open a client, read a handful of DB offsets, hand the numbers to something else — and eventually wrote it once properly instead. It's an HTTP layer over python-snap7 where the addresses live in a YAML file rather than in a script:

https://github.com/Poseidonas/s7-gateway

$ curl localhost:8080/plcs/line1/tags/motor_temp
{"plc":"line1","tag":"motor_temp","value":72.5,"type":"real","unit":"°C"}

plcs:
  line1:
    host: 192.168.0.10
    tags:
      motor_temp: {db: 10, offset: 0, type: real, unit: "°C"}
      line_speed: {db: 10, offset: 4, type: int, writable: true}
      running:    {db: 10, offset: 8, type: bool, bit: 0}

Read or write one tag, read them all in one request, write several at once, ask the CPU what it is, and a /metrics endpoint in the Prometheus text format so a plant can point Grafana at a PLC without anyone writing Python. Nothing is writable unless the config says so, and it binds to loopback by default.

Two things it refuses on purpose, both of which snap7 will happily accept and convert:

• 1.5 into an int tag, which would be written as 1
• "off" into a bool, which would be written as true, because bool("off") is True — that one would start a motor someone meant to stop

On the testing, since it's your library underneath

All 81 tests run against a real snap7.server on localhost over the actual protocol. There's no mocking of snap7 anywhere — one test injects a failure, and only because the server can't be made to fail on demand. That includes 200 concurrent bit writes into the same byte to check the read-modify-write doesn't lose a neighbour, and recovery after the server disappears mid-run.

Writing it that way turned up something in the native server that I've written up in #578: a read from an unregistered data block returns fabricated bytes instead of an error, which decodes as a very believable 127.53555297851562. Your own caller, docstring and write path all already expect None there, so it looks like a slip rather than a decision — details and measurements are in that thread.

What it isn't

First public version, and it has only ever talked to snap7.server on localhost — no physical CPU yet. The protocol work is all yours and well travelled; what's new is the thin layer above it, and that's the part that needs someone's actual plant to find the rest of. If anyone here points it at real hardware I'd be glad to hear what breaks.

MIT, Python 3.11 to 3.14, and it inherits the no-C-library install from python-snap7 3.1+, which is a nice thing to be able to write in a README.