Show HN: Pyhoff – Connect Python ML Models to Beckhoff/WAGO IO Hardware

Show HN (score: 6)
Found: July 09, 2025
ID: 212

Description

API/SDK
Show HN: Pyhoff – Connect Python ML Models to Beckhoff/WAGO IO Hardware Built this Python package because I wanted to run hardware controlling ML stuff and other control algorithms directly connected to industrial I/O hardware without jumping into annoying PLC toolchains (Windows only, licensing hassle, no editor choice, proprietary version control - you name it). For sure its not for ms‑cycle loops, or uptime critical production stuff, but in applications with relaxed timing it allows for fast iteration on the setup - making prototyping a pleasure. Its easy to use, has no dependencies beside Python, its fully type annotated and MIT licensed. Internal it uses ModBus/TCP for hardware communication, the implementation is exposed, so it co-serves as ModBus/TCP client library.

I'd love to hear your use cases, feature ideas and PLC toolchain stories ;)

Docs: https://nonannet.github.io/pyhoff

More from Show

Show HN: Product as Code – YAML-based product management for AI coding workflows

Show HN: Product as Code – YAML-based product management for AI coding workflows I have worked with AI assistants for a while, and while I am really excited about it, there were times when I felt really frustrated. LLM would end up in a loop with no end.<p>This is when I started experimenting with creating work plans. Initially simple todo list, but it felt like &quot;product vibing&quot;, so a bit more sophisticated later on. I started seeing value in it.<p>The one day it hit me. Why not use the same GitOps principles to managing product tickets? I started playing with that and really liked the way it worked.<p>After a chat with a friend of mine, I realised that a standard or a spec would be something really useful. You could then create all sort of tooling around this.<p>I took an inspiration from the way kubernetes yaml are used, cause I find it quite neat.<p>You can view examples here: <a href="https:&#x2F;&#x2F;spec.productascode.org&#x2F;draft&#x2F;#sec-Epic-Example-YAML-" rel="nofollow">https:&#x2F;&#x2F;spec.productascode.org&#x2F;draft&#x2F;#sec-Epic-Example-YAML-</a><p>Key design decisions so far:<p>1. YAML over JSON: Human-readable, git-diff friendly, excellent tooling ecosystem 2. Hierarchical structure: Epics → Tickets → Tasks (matches development workflow) 3. Atomic tickets: Each ticket = one branch = one PR (prevents scope creep) 4. ISO 8601 timestamps&#x2F;durations: Machine-parseable time data<p>If I manage to create an epic with a bunch of tickets in backlog, then my favourite part of work is to tell Claude Code: &quot;Close the current ticket, and start another one&quot;.<p>Here is the link to the post which has links to draft spec and GitHub repository.<p>Currently working on v0.1.0 and I would love to hear your thoughts.<p><a href="https:&#x2F;&#x2F;mantcz.com&#x2F;blog&#x2F;introducing-product-as-code&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mantcz.com&#x2F;blog&#x2F;introducing-product-as-code&#x2F;</a>

Show HN: Interactive Bash tutorial that runs in the browser

Show HN: Interactive Bash tutorial that runs in the browser I wrote a tutorial on how to create Bash scripts, where the command line interface runs entirely in the browser using v86 (<a href="https:&#x2F;&#x2F;github.com&#x2F;copy&#x2F;v86">https:&#x2F;&#x2F;github.com&#x2F;copy&#x2F;v86</a>), and the code editor uses Monaco.

Show HN: Mock FedCM Integrations

Show HN: Mock FedCM Integrations MockFedCM is a free FedCM Relying Party (RP) and Identity Provider (IdP) for testing FedCM integrations. Simulate real-world authentication flows, debug your implementation, and validate user experiences—all without needing a production IdP or RP.

Show HN: Object database for LLMs that persists across chats (MCP server)

Show HN: Object database for LLMs that persists across chats (MCP server) I’d like to use LLMs for remembering all kinds of things: fitness, to-do lists, contacts, bug reports, research links, whatever. But there is no way to do that now.<p>For example, if I find a great coding tutorial in chat, or tell it how much I ran yesterday, it forgets that when I close the chat. Even if I keep the chat history, I still need to scour through lots of messages to find the data I want. Ideally, Claude would remember all this, and I’d be able to find it later with ease. This is what my team built.<p>It is a collaborative database you add to any LLM that supports MCP. (Claude Code, Desktop, and Pro for now; ChatGPT will soon). You can add, update, and search for items in the database inside chat. You can easily create your own object schemas. There is an automatically generated web UI for using the database. It generates maps, charts, calendars, tables, lists, and other UI elements. You can share or publish the database as well.<p>Over time, we want to make this database powerful enough to make our lives much simpler by letting LLMs replace a bunch of the apps and software services we use daily.

Show HN: Gore – A Doom Engine Port in Go

Show HN: Gore – A Doom Engine Port in Go Hi HN,<p>I’ve been working on Gore – a port of the classic Doom engine written in pure Go, based on a ccgo C-to-Go translation of Doom Generic. It loads original WAD files, uses a software renderer (no SDL or CGO, or Go dependencies outside the standard library). Still has a bit of unsafe code that I&#x27;m trying to get rid of, and various other caveats.<p>In the examples is a terminal-based renderer, which is entertaining, even though it&#x27;s very hard to play with terminal-style input&#x2F;output.<p>The goal is a clean, cross-platform, Go-native take on the Doom engine – fun to hack on, easy to read, and portable.<p>Code and instructions are at <a href="https:&#x2F;&#x2F;github.com&#x2F;AndreRenaud&#x2F;Gore">https:&#x2F;&#x2F;github.com&#x2F;AndreRenaud&#x2F;Gore</a><p>Would love feedback or thoughts.

Show HN: Doc81 – tech documentation tool designed in AI-native mind

Show HN: Doc81 – tech documentation tool designed in AI-native mind Hello HN!<p>As a EM, I recently asked for a &quot;good&quot; handoff doc to my engineers who&#x27;re leaving, but without proper structure, the first draft was pretty crappy. Studying and thinking hard about what readers(i.e., me) might want on header level and what would be a good representation in each section, we came up with a good template for handoff doc. The result was fantastic. I think we all can write better with a proper format and template. That is where I came up with this idea, doc81.<p>Have fun, and let me know what you think!

Show HN: MCP-123, a 2-line MCP server/client (Windows-friendly)

Show HN: MCP-123, a 2-line MCP server/client (Windows-friendly) Got tired of every MCP example being overly verbose, or needing Docker or Mac-only scripts, so I threw together MCP-123. Point it at a tools.py, run `server.run_server(...)`, and the client auto-discovers&#x2F;calls functions with OpenAI. I hope this is useful to you all.

No other tools from this source yet.