I took some Christmas holidays and hacked on my KNX stack over the last week. Among a few other things I had an LLM vibe-code a conformance test runner for my KNX stack. The tests are all available in the specification itself, so you can just implement all of them yourself. These tests are also run if you want to officially certify a device or device stack by a test lab. That means passing these tests ensures that you are 100% conformant with the spec. At least if you trust them to cover every single edge case.
Normally you are expected to buy the "EITT" from the KNX association which is the software that implements all these tests and executes them against physical devices. For that you need to be a member of the association and I heard it's not cheap, so fuck that!

It spawns my stack with a mock device and a data link layer that offers transmit and receive queues to the test runner and then executes the specified tests.

Slowly but surely we are getting close to passing all tests for the network layer and transport layer. This includes the connection state machine in the transport layer.

Boy, I am hyped! Once the last five missing transport layer tests are passing, the next task is to add more test for the application layer, management tasks and group object communication. The latter is already fully implemented and the device management partly.

I can't wait to get this thing done.

👀 ⚡

(The PA9/10 labels are not aligned with the others... already fixed.)

Made leaps of progress in my KNXnet/IP implementation today. Turns out the IP part of KNX is something like its own protocol stack that you place before your real protocol stack <insert image of Xzibit here>.

I now have basic infrastructure like a packet buffer allocator, parsing and serialization functions for the first few discovery packets and substructures contained within, infrastructure for subservers that later allow for Routing, Tunneling, Device Discovery etc., a discovery server that makes my test device already pop up in the ETS, a socket endpoint manager that takes registrations on different endpoints (Unicast, Multicast and/or Broadcasts) from subservers, deduplicates them, opens sockets and then dispatches arriving messages to the appropriate subserver that registered interest to the specific message type we just received. That is JUST the IP part! And only UDP for now, TCP will come later where applicable.

On the KNX side I already have table management and a completely working application, connectionless transport and network layer for a simple device. That means no routing in the network layer for now.

So now, I "only" need to implement a routing server and theoretically I could then read, write and update communication objects using group addresses remotely from other devices on a real KNX installation like my house. All the config like the address and association tables are completely static and need to be build by hand in a JSON file for now, because nothing that would allow device management is implemented yet.

For the whole ETS device management stuff, more is missing like the stateful connected transport layer and all the management server stuff, but that will come later.

That was A LOT of work. Especially because it's all no_std, no alloc, async Rust. I like pain. 🥵

😳

I need a Rust borrow checker version.

"Don't lecture me on jurisdiction, Lieutenant! I wrote a book about space... jurisdiction. And I am known for my dic(k)tion!"

I love everything about this. (SNW S03E04)