DEV Community: Phil Yeh

My Local RAG article went viral. The product it promoted sold 1 copy in 6 months.

Phil Yeh — Wed, 20 May 2026 12:00:00 +0000

Six months ago, I published a Dev.to article called "How I built a 100% offline Second Brain for engineering docs using Docker + Llama 3 (No OpenAI)."

It worked.

380 reads on day one
7 bookmarks, 11 reactions, the works
Top Docker Author Badge of the week 🏆
A comment thread that actually went somewhere — someone suggested docling, someone else brought up the EU AI Act

For a brand-new Dev.to account with two articles to its name, this is the kind of result that makes you think you've cracked something.

The product it linked to — a $59 Dockerized RAG toolkit on Gumroad — has sold 1 copy in the six months since.

This isn't a "how I failed" post. The article didn't fail. The product didn't really fail either — it just didn't do what the article suggested it would. The gap between those two outcomes is the entire post.

How the article went viral

Looking back, the article hit three buzzwords that the Dev.to algorithm loves stacked together: Llama 3, Docker, and "No OpenAI." Add #python, #ai, #docker, #automation as tags and you're hitting four high-traffic feeds at once.

The contrarian framing helped. "No OpenAI" isn't a neutral technical choice — it's a position. Positions get bookmarks.

The structure was clean: a relatable pain (you can't paste NDA-protected schematics into ChatGPT), a clear stack (Ollama + ChromaDB + Streamlit), a docker-compose snippet that looked copy-pasteable, and an honest section about the hard parts (PDF parsing, context window limits, Docker networking on GPU).

I'm not going to pretend the article was lucky. It was structurally good content. The reads were earned.

What I want to talk about is what I thought those reads meant.

Here's the part most "building in public" posts skip

I didn't start with a problem. I started with a market.

As an indie maker with a full-time job and two kids, I have maybe 8–12 hours a week for side projects. I needed a product that could actually sell. I noticed Local LLM tutorials were getting strong traction on Dev.to, and I made what felt like an obvious assumption:

Engineers handle sensitive datasheets every day. Privacy must be a real pain point. So a self-hosted RAG with no cloud dependency must be something they'd pay for.

That assumption felt obvious. It wasn't.

I want to be specific about what was wrong with it, because the error wasn't "Local LLM is a bad market" — it might be a fine market for someone else. The error was that I confused a problem I could imagine engineers having with a problem engineers actually pay to solve.

Those aren't the same thing.

Three signals I missed at the time

Signal 1: I wasn't using my own product

The first signal I should have noticed was the most embarrassing one. I built a Local RAG to keep engineering datasheets off the cloud. My own company has zero IT restrictions. We paste datasheets into ChatGPT every day. Nobody cares.

If I had genuinely needed the product, I would have used it for six months and refined it from real friction. I didn't. After the initial demos, the Docker stack sat there.

This is the founder version of writing a recipe you've never cooked.

Signal 2: Six months, one sale

The product launched alongside the article. Six months later: one paying customer at $59.

One.

Not "low-conversion-funnel" one. Just one.

Signal 3: The feedback from that one customer was sharper than the badge

A few months in, that customer sent me an email. Two points, paraphrased but accurate to his original frustration:

The demo video shows a Mandarin UI, but the Python product is in English. They don't match up.
"Enterprise-grade"? I assumed it included auth and permission management. It doesn't. This is just for solo / small-office use, right?

Now, here's the thing: I never literally used the word "enterprise-grade" in the title. The product is called "Local AI Knowledge Base: Dockerized RAG — Lite Edition."

But "Knowledge Base" + "Lite Edition" implies a Pro / Enterprise tier exists. He's not wrong to expect that. The naming wrote a check the product couldn't cash.

He wasn't being hostile. He was correcting me. And he was right on both counts:

A Mandarin demo video for a product sold globally on Gumroad is a localization gap I never even thought about.
"Lite Edition" implies a ladder. There was no ladder. There was just one rung labeled "Lite."

That email taught me more about my product than the Top Docker Author Badge did.

What the data actually says

Let me lay both metrics side by side, because once you see them together the lesson is hard to miss:

Metric	Result
Reads	380+ (day one), still trickling
Reactions	11 (7 bookmarks)
Top Docker Author Badge	Yes
Reading list saves	11 logged readers
Paying customers	1
That customer's price point	$59
That customer's feedback	Naming was misleading, localization was off

The first five rows measure how good the article is. The last three measure whether the product is worth paying for.

These are unrelated experiments. Bookmarks don't predict sales. Badges don't predict sales. Reading list saves don't predict sales. A great article can sit on top of a product nobody wants, and a mediocre article can promote a product people actually need.

I knew this in theory before I wrote the article. I didn't know it know it until I had six months of data showing the gap.

The cognitive trap I want to name

Here is the trap, stated plainly, so the next indie maker writing a Local LLM Dev.to article can skip it:

Content engagement validates that the article resonates. It does not validate that the product solves a problem people pay for.

What would have actually validated the product? A few things I didn't do:

Pre-sell before building. Post the landing page and a waitlist before writing a line of code. If 50 engineers from the article's traffic don't drop their email, the demand probably isn't there.
Watch for unprompted referrals. Did any of the 11 bookmarkers share the product with a colleague without me asking? No. That's the cleanest demand signal you can get, and it was silent.
Talk to the one customer who bought. I waited until he emailed me. I should have reached out the day his receipt was opened.

None of these are clever. They're standard indie-maker advice. I skipped them because the article numbers felt like enough validation. They weren't.

What I'm doing differently now

I'm not pulling the product down. The one paying customer is still using it, and the article still brings in occasional reads that send the right people to my Gumroad. It's a small, real, working channel.

But the next product won't start from "what's trending on Dev.to." It'll start from a problem I personally hit at work, often enough that I'd pay $59 to make it go away.

My latest tool, an IIoT Alarm Engine, came out of that filter. I needed real-time alerts from Modbus and MQTT devices, routed to Slack and Telegram. I built it because I was missing the feature myself, not because the tag was trending. It's too early to say whether it will sell better. But at least the assumption it's built on is one I can verify by using it.

If you take one thing from this post

Reads, bookmarks, and badges measure your writing.
Sales measure your product.

They aren't the same axis. Don't read one and feel validated about the other.

That's a six-month, one-sale lesson written down so you can have it for free.

By Phil Yeh — Senior Automation Engineer specializing in Industrial Python and developer tools. I publish post-mortems and engineering case studies on real problems shipping to factories — not the hype. If you want future post-mortems in your inbox: Phil's Industrial Notes. If you've made the same mistake, the comments are open.

Tools I've built since: IIoT Alarm Engine, J1939 Decoder GUI, Modbus Logger. Browse the rest: philyeh.gumroad.com.

I bought the most expensive cable I could—and it still died. Welcome to RS485 vs 1000V DC.

Phil Yeh — Wed, 13 May 2026 02:35:36 +0000

A Class A solar pyranometer, the original shielded cable, 10 meters. Dies every 1-2 hours. In the end, I switched to 4-20mA.

A few years ago at a solar farm site, I learned something the hard way: EMI doesn't care how expensive your cable is.

Here's what happened. We needed to bring data from an EKO MS-80S pyranometer (Class A — the kind academic labs use) into our system. The device had RS485 / Modbus RTU. The manufacturer supplied a shielded twisted pair cable. 10 meters distance, standard industrial environment. By textbook standards, this should have been a plug-and-play setup.

Reality: The first 1-2 hours worked perfectly. Then comms died. Completely died. Every poll from the software side returned timeout — not corrupted values, not CRC errors, just no response.

The weirdest part was the recovery: just unplug the RS485 connector and plug it back in, and comms returned to normal. But 1-2 hours later, it died again. Periodic, reproducible, like it was mocking me.

This is the full story of that case — including why I eventually gave up on RS485 and switched to 4-20mA. If you're also fighting industrial RS485 issues, this might help — not because I solved it, but because I'm admitting that some environments just aren't right for RS485.

First wrong guess: device failure

My first instinct was "the device is broken."

I swapped in another unit of the same model. Same symptoms — works for 1-2 hours, then permanent disconnect.

Second instinct: "the cable is bad."

Swapped in another OEM shielded cable. Still the same.

That's when I realized: the problem isn't the device or the cable. It's the environment.

Re-checking the wiring: the culprit was at the cable entry

Going back to look at the panel wiring, I noticed something I'd missed before.

The RS485 signal line and a 1000V DC line were passing through the same panel entry hole, almost touching each other. The separation was only about 10-20 cm, but at the moment they squeezed through the same metallic hole, they were practically in contact.

Worse: the 1000V DC line behind that point connected to the site's DC-DC converter — the kind of device that, in operation, produces MOSFET switching transients with dV/dt in the kV/μs range.

In the EMI world, this is called capacitive coupling at panel entry. It's the textbook case study, chapter 3.

The original contractor hadn't considered EMI routing when designing this panel — RS485 signal lines and high-voltage DC lines just shared the same entry. On the drawing they looked "separate." Physically, they were stuck together.

Why the OEM shielded cable couldn't save me

My first question after this discovery: EKO's OEM cable is shielded twisted pair. Theoretically it should resist EMI. Why is it still failing?

The answer is in the physics of EMI.

Shielded cable handles radiated EMI — external electromagnetic waves hitting the shield are diverted to ground. But the situation at the panel entry isn't radiated EMI — it's capacitive coupling:

When the 1000V DC line has high dV/dt, a strong transient electric field appears around it
The RS485 line is almost in contact with it — effectively, there's a tiny capacitor between the two lines
That capacitor couples the high-voltage side's transient voltage onto the RS485 signal
The shield can't help in this case, because the ground reference itself is being disturbed — both shield ends ground to a point that's now bouncing

In short: shielding protects against "electromagnetic waves coming from outside," but in this case the ground potential itself was jumping.

The disturbances accumulate. The RS485 transceiver IC internally latches up. After enough accumulation, it stops responding entirely. Unplugging and replugging resets the IC, so it temporarily recovers — but the physical interference is still there, and 1-2 hours later it latches up again.

Things I tried, considered, and gave up on

After understanding the cause, I tried a few approaches:

1. Improve shield grounding

Re-grounded both ends of the shield. Marginal improvement. Reason: the problem is capacitive coupling at the panel entry — improving shield grounding doesn't address that mechanism.

2. Rerun the cable away from the high-voltage line

Sounds straightforward, but the cable tray and panel entries were already installed. Rerouting meant redoing the panel entry. Not feasible under site time pressure.

3. Add an optically isolated RS485 converter

Technically viable — convert RS485 from "electrical transmission" to "optical transmission" and break the capacitive coupling path entirely. But:

Required procurement, testing, and re-wiring
The procurement timeline didn't match the site deadline

4. More aggressive software retry / heartbeat

I considered it, but the problem here wasn't "occasional errors," it was IC latch-up — software retry can't recover from a hardware latch-up.

In the end, I took the most low-tech path available: give up on RS485 and use the pyranometer's 4-20mA analog output instead.

Why 4-20mA won in the end

The EKO MS-80S has a 4-20mA analog output in addition to RS485 (standard for industrial pyranometers).

I wired it into the site PLC's Analog Input module. It never disconnected again.

Why does 4-20mA win in this environment?

Current signals are insensitive to capacitive coupling — coupling is an electric field phenomenon, and electric fields disturb voltage, but 4-20mA transmits current
AI modules have industrial-grade isolation built in, with much stronger surge immunity than RS485 transceivers
No IC latch-up risk — even if the AI module reads a momentary glitch, the next sample period returns to normal
Resolution drops from "Modbus floating-point" to "4-20mA mapped to 0-1600 W/m²" — but for a pyranometer, that's more than enough precision

What I learned

A few takeaways stuck with me after this case:

1. EMI isn't "just buy a shielded cable" simple

Shielding handles radiation. It doesn't handle capacitive coupling at weak points like panel entries. Expensive cable is necessary, not sufficient.

2. Panel entries are an underrated EMI weak point

Metal panel enclosures themselves shield well, but the entry holes are discontinuities in the metal, and that's where all the EMI concentrates. During design, signal lines and high-voltage lines have to be separated starting from the entry hole.

3. RS485 has limits in heavy EMI environments

RS485 is a veteran protocol, designed in an era when EMI standards were nothing like today. In solar farms, inverter-heavy floors, motor-dense areas, RS485 is just a fragile choice.

4. 4-20mA isn't outdated — it's the last line of immunity

Industrial 4-20mA has been around for decades for a reason. When digital comms can't solve it, analog signals are often the last resort — and they work surprisingly well.

5. EMI routing not considered at design time → nearly impossible to fix later

This case ended up solved by switching the comm type, not by fixing the wiring — because the site couldn't allow rewiring. The extra effort at design time really isn't wasted.

Checklist for other engineers

If you're debugging RS485 stability issues on an industrial site, start by checking:

[ ] Are RS485 signal lines and high-voltage lines (AC power, DC bus) "squeezed together" through the same panel entry?
[ ] Are both ends of the shield properly grounded? Is there a potential difference between the ground points?
[ ] Is the cable length within spec? Is the 120Ω termination resistor installed?
[ ] Have you considered 4-20mA / Modbus TCP / LoRa as alternatives?
[ ] Are you using a continuous monitoring tool to catch accumulating disturbance early?

That last one matters a lot — a lot of EMI problems don't "die instantly," they "die gradually." If you only use ping / occasional polling to check, you won't see the pattern.

When I debug this kind of issue, I usually use a Python tool to log comm state and raw frames over long periods, so I can review patterns afterwards. If you need something similar: Python-Modbus-Serial-Logger-GUI.

Wrap-up

RS485 is a veteran. Not an all-purpose hammer.

The biggest lesson for me: an industrial integration engineer's value isn't just in "solving problems" — it's also in "knowing which problems shouldn't be force-solved." If the environment fundamentally isn't right for RS485, switching comm type can be far more meaningful than fighting it out.

Next time RS485 acts up on you, go check the panel entry first. The culprit might just be sitting there, squeezed in next to your signal line.

If you've had a similar "RS485 dying in industrial environment" experience, drop a comment — these war stories are worth more than textbooks.

Why Your Schneider PLC's Float32 Reads 1.4e-41 Instead of 25.5 C

Phil Yeh — Tue, 05 May 2026 08:28:47 +0000

You've connected your Python script to a Schneider M221, requested a holding
register pair where you know the temperature is 25.5°C, and you get back:

1.401298464324817e-45

Not 25.5. Not even close. Some weird denormal float so small it might as
well be zero.

Welcome to the Modbus float32 byte-swap trap. It's the single most
common reason engineers think pymodbus is broken when it isn't. The fix
is 5 lines of code once you know what's happening — and that's what this
article is about.

Why this happens

The Modbus specification defines registers as 16-bit unsigned integers.
Period. That's it. The spec was written in 1979 and at the time, that's
all anyone needed.

But modern PLCs need to send floats, 32-bit integers, doubles, strings.
The "solution" the industry adopted was: just split the larger value
across multiple 16-bit registers.

The problem? The Modbus spec says nothing about the order.

Each PLC vendor decided independently whether to put the high word first
or the low word first. Whether to swap bytes within a word. Whether to
flip everything. The result is four different ways to encode the same
float, and there's no in-band way to know which one you're getting.

This is why your PLC software shows 25.5°C while your Python script reads
1.4e-41 — same bytes, different decoding order.

The 4 byte orders you'll meet

A 32-bit float 25.5 in IEEE-754 is the byte sequence:

0x41 0xCC 0x00 0x00

Now watch what happens when different PLCs put these 4 bytes into 2 Modbus
registers:

Order	Register N	Register N+1	Common in
ABCD (big-endian, no swap)	`0x41CC`	`0x0000`	Allen-Bradley, ABB, "clean" implementations
CDAB (word-swap)	`0x0000`	`0x41CC`	Schneider M221/M241, some Siemens
BADC (byte-swap)	`0xCC41`	`0x0000`	Rare — some old controllers
DCBA (byte + word swap)	`0x0000`	`0xCC41`	Mostly legacy hardware

If you decode bytes in ABCD order when the device sent CDAB, you get
a tiny denormal float (the 1.4e-41 you're seeing), or nan, or inf,
or just nonsense.

Schneider's CDAB (word-swap) is the trap that catches most people.

Code: decode all 4 orders in Python

Pure stdlib, no dependencies. Drop this into your project:

import struct

def decode_float32(reg_high: int, reg_low: int, byte_order: str = "ABCD") -> float:
    """Decode two 16-bit Modbus registers into a float32.

    byte_order:
        ABCD - big-endian, no swap (default IEEE-754)
        CDAB - word-swap (Schneider, some Siemens)
        BADC - byte-swap within each word
        DCBA - byte + word swap
    """
    # Pack the two registers into 4 bytes (big-endian)
    raw = struct.pack(">HH", reg_high, reg_low)

    if byte_order == "ABCD":
        return struct.unpack(">f", raw)[0]
    elif byte_order == "CDAB":
        # Swap the two 16-bit words
        return struct.unpack(">f", raw[2:4] + raw[0:2])[0]
    elif byte_order == "BADC":
        # Swap bytes within each word
        return struct.unpack(">f", raw[1:2] + raw[0:1] + raw[3:4] + raw[2:3])[0]
    elif byte_order == "DCBA":
        # Reverse all 4 bytes
        return struct.unpack(">f", raw[::-1])[0]
    else:
        raise ValueError(f"Unknown byte order: {byte_order}")


# Example: read a value with pymodbus and decode all 4 ways
from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient("192.168.1.10")
client.connect()

response = client.read_holding_registers(address=100, count=2)
reg_high, reg_low = response.registers[0], response.registers[1]

print(f"ABCD: {decode_float32(reg_high, reg_low, 'ABCD')}")
print(f"CDAB: {decode_float32(reg_high, reg_low, 'CDAB')}")
print(f"BADC: {decode_float32(reg_high, reg_low, 'BADC')}")
print(f"DCBA: {decode_float32(reg_high, reg_low, 'DCBA')}")

The trick: print all four when you're integrating a new device. The
one that gives a sensible value (e.g. 25.5 when you know the temperature
is 25.5) tells you the device's encoding. Lock it in for that device.

Real-world examples by vendor

Based on years of integration work, here's what I've seen most often:

Schneider M221, M241, M340 → Almost always CDAB (word-swap). This is the #1 source of "my Python script is broken" tickets.
Siemens S7-1200, S7-1500 → Depends on how the float is stored. If exposed via Modbus TCP wrapper, often CDAB too.
Allen-Bradley CompactLogix → Usually ABCD when exposed through Prosoft Modbus modules. Clean.
Mitsubishi FX series → ABCD in most configurations.
Delta DVP → ABCD.
Energy meters (Schneider PM5xxx) → CDAB typically.
VFDs (ABB ACS, Schneider Altivar) → Mixed — always test all 4.

The lesson: never assume. Even within one vendor, different product
lines pick different orders. Always do the "print all 4" test on a new
device.

Common pitfalls

1. Some libraries do the swap silently — and silently wrong

pymodbus's built-in BinaryPayloadDecoder lets you specify
byteorder=Endian.BIG, wordorder=Endian.LITTLE (which is CDAB). But
the API is confusing enough that I've seen people set both to BIG and
spend hours debugging. Decode manually with struct — it's clearer.

2. The "negative number" red flag

If your decoded value is -1.5e+38 when you expect 25.5, you've
almost certainly got the byte order wrong. Single-digit positive
temperatures don't accidentally encode as huge negative numbers under any
normal scaling.

3. int32 has the same problem

This article focuses on float32 because it's the most painful, but all
multi-register types have this issue. int32, uint32, int64, double —
they all get split across registers and they all need the byte-order
treatment.

4. Some devices store the swap setting in a register

Annoying but real: a few high-end PLCs let the user configure
endianness. Always check the device manual for any "byte order" or "word
order" parameter before running test code.

Wrapping up

The Modbus float32 byte-swap is one of those things that looks like a
bug in your code but is actually a quirk of the protocol's history. Once
you know to test all 4 orders, you can integrate any device in a few
minutes instead of a few hours.

If you're using this in production work and want a more polished version
with a CSV recorder and Modbus TCP support, I sell a commercial license
at Github.

I write about industrial Python and protocol internals at
dev.to/philyeh — new article every two
weeks. If you've got a specific PLC integration story you want to read
about, drop a comment.

From Theory to Practice: Digital Twin Core Concepts and Implementation Ideas for Engineers

Phil Yeh — Fri, 12 Dec 2025 07:19:31 +0000

🌐 The Bridge: Why Digital Twins Matter Now
Have you ever wished you could predict a machine failure before it happens, or simulate the impact of a change in your supply chain without risking real-world downtime? That's the power of the Digital Twin.

A Digital Twin is more than just a fancy 3D model. It's a live, virtual replica of a physical asset, system, or process that is constantly synchronized with real-world data. It serves as a testing ground, a crystal ball, and a diagnostic tool all rolled into one.

For engineers, understanding Digital Twins is crucial for mastering the next phase of IoT and predictive analytics in fields like manufacturing, smart cities, and energy management.

🔬 Step 1: Deconstructing the Digital Twin (The Three Core Layers)
To build a Twin, we must first understand its three fundamental components.

The Physical Asset Layer (The Source) This layer includes the real-world equipment and the infrastructure used to gather data:

Key Technologies: IoT sensors, PLCs, and Edge Computing devices.

Data Types: Real-time metrics like temperature, pressure, vibration, and energy consumption.

The Virtual Model Layer (The Brain) This is where the magic happens—the calculations, simulations, and predictions.

Behavioral Models:

Physics-Based: Uses known equations (thermodynamics, fluid dynamics) to predict behavior.

Data-Driven (ML/AI): Uses historical data to train models that predict failures or optimal settings.

Data Structure: Requires robust databases, often Time Series Databases (e.g., InfluxDB), to efficiently handle high-velocity, timestamped sensor data.

The Connection & Services Layer (The Data Flow) This is the communication pipeline that ensures the Twin is alive. It requires bi-directional data flow.

Inbound Flow (Physical to Virtual): Sensors push data to the cloud/edge (often via MQTT).

Outbound Flow (Virtual to Physical): The Twin sends control commands or optimization suggestions back to the physical asset (e.g., throttling a motor speed).

🛠️ Step 2: The Engineer's Starting Guide (A POC Blueprint)
Ready to start building your first Twin? Here is a practical, two-phase approach focusing on open-source tools.

Phase A: Data Ingestion and Basic Shadowing
Your goal here is to create a "Shadow Twin"—a basic model that mirrors the live state.

Set up MQTT Broker: Start a lightweight message broker (e.g., Mosquitto or a cloud service like AWS IoT Core).

The Python Data Emitter: Use Python to simulate or collect sensor readings and publish them to the broker.

Python

# python_emitter.py - Simulating sensor data publishing
import paho.mqtt.client as mqtt
import time
import random

broker_url = "your_mqtt_broker"
topic = "asset/motor/temperature"

client = mqtt.Client()
client.connect(broker_url, 1883, 60)

while True:
    temp = 70 + random.uniform(-2, 2)  # Simulate temp fluctuation
    client.publish(topic, f"{time.time()},{temp:.2f}")
    print(f"Published: {temp:.2f}")
    time.sleep(5)

Visualization: Use Grafana to subscribe to the MQTT topic and display the data on a dashboard. This is your first visual Twin!

Phase B: Integrating Predictive Intelligence
Now, let's add the "intelligence" to the Twin using a simple Machine Learning model.

Model Training (Hypothetical RUL Model): Assume you've trained a classification model (using Scikit-learn or similar) to predict the Remaining Useful Life (RUL) of your motor based on its temperature and vibration history.

The Prediction Service: A dedicated Python service reads the latest data and feeds it into the trained model.

Python
# prediction_service.py - The Twin's intelligence
import pandas as pd
from joblib import load
# Assume 'rul_predictor.joblib' is a trained ML model

model = load('rul_predictor.joblib')

def predict_rul(latest_data):
    # Process latest_data (e.g., features for the last 1 hour)
    features_df = pd.DataFrame([latest_data]) 
    prediction = model.predict(features_df)

    # 0 = Normal, 1 = Caution, 2 = Failure imminent
    return prediction[0]

(This service would run continuously, reading from the Time Series DB)

By connecting this prediction service to your live data stream, your Twin starts providing actionable insights (e.g., sending an alert when the RUL drops below 10 days).

🚀 Step 3: Challenges and The Future
Key Challenges in Implementation
Data Quality: Twins are only as good as the data they receive. Dealing with sensor drift, gaps, and noise is a massive engineering challenge.

Synchronization Latency: For real-time control applications (like self-driving cars), the delay between the physical event and the virtual update must be minimal.

Scalability: Managing the data synchronization and simulation load for millions of individual Twins (e.g., every turbine in a wind farm).

Looking Ahead
The future of Digital Twins is exciting:

XR Integration: Using AR/VR headsets to overlay live Twin data onto the physical asset during maintenance (e.g., seeing a projected temperature reading overlaid on the actual motor).

Edge Twins: Shifting more simulation and predictive processing to Edge devices to reduce latency and cloud costs.

📢 What’s Your Twin?
Digital Twin technology transforms maintenance from reactive to predictive.

What process or asset in your current engineering domain do you think is ripest for Digital Twin development? Share your ideas and challenges in the comments below!

The Architecture of Implicit Messaging: Implementing Raw CIP I/O in Python

Phil Yeh — Wed, 03 Dec 2025 03:26:51 +0000

The Challenge of Class 1 I/O
Ethernet/IP (EIP) is based on the Common Industrial Protocol (CIP), which defines two primary messaging types:

Explicit Messaging (TCP 44818): Request/Response—used for configuration and diagnostics.

Implicit Messaging (UDP 2222): Cyclic I/O—used for high-speed, repetitive data exchange (Class 1 Connections).

The architectural challenge lies in managing resource contention and time determinism when setting up these complex connections using raw sockets, rather than relying on commercial drivers.

🏗️ The 4-Step Connection Sequence
A robust implementation requires careful management of the TCP setup and the subsequent UDP I/O lifecycle. Our architecture follows these four steps within a cyclic process:

Register Session (TCP)
The process begins with an Explicit Message to the target device's Encapsulation Layer (TCP 44818). This step establishes a Session Handle, which identifies the connection for subsequent requests.
Forward Open (TCP)
This is the most critical step. The client sends a Forward Open command containing all parameters necessary for the Class 1 I/O connection, including:

Requested Packet Interval (RPI).

Connection Path (Assembly Instance IDs for the I/O data).

Connection Timeout parameters. The device returns the O2T (Originator to Target) and T2O (Target to Origin) Connection IDs.

Cyclic I/O Exchange (UDP)
Once the connection is established via TCP, the system shifts to high-speed UDP 2222. The client sends periodic data using the established O2T connection ID, and the device responds with the T2O data. This ensures minimal latency for cyclic data updates.
Forward Close & Teardown (TCP)
To prevent the target device from eventually timing out and reporting a fault, the client must explicitly send a Forward Close command (TCP). This gracefully releases the resources allocated by the device before the socket is closed.

💻 Architecture for Deterministic Testing
To reliably test this intricate sequence, our study kit employs a dual-application structure:

Raw Socket Client: Implements the full TCP and UDP state machine, managing the cyclic Open/Close sequence.

Mock PLC Server: A separate Python application running on localhost that listens on TCP 44818 and UDP 2222. The mock server is essential for deterministic testing, as it guarantees correct, instantaneous responses during the handshake, allowing developers to isolate logic errors from physical layer noise.

Python I/O Loop Structure
The raw socket implementation requires precise packet assembly. Below is the conceptual structure used to manage the cyclic UDP exchange:

Python

# Conceptual Structure for I/O Loop

while running:
    # 1. Open Session (TCP) & Forward Open (TCP) is performed here...

    # 2. UDP Exchange Phase:
    try:
        # Construct and send O2T packet using raw bytes
        udp_socket.sendto(o2t_packet, (target_ip, 2222))

        # Receive T2O packet (Target to Origin)
        received_data, addr = udp_socket.recvfrom(1024)

        # Log and parse the raw data...

    except socket.timeout:
        log("Warning: UDP I/O Timeout occurred.")

    # 3. Forward Close (TCP) & TCP Disconnect is performed here...

    time.sleep(RPI_WAIT_TIME)

🔒 Conclusion
Understanding the raw socket implementation of CIP is critical for developers working in industrial cybersecurity, custom SCADA integration, or embedded systems where external libraries are too large or unavailable.

We have documented the complete architecture and technical insights for this project on GitHub. If you are interested in acquiring the full, ready-to-deploy Python source code for this framework and diving into the raw packet structure for your own custom industrial solutions:

View the complete project and detailed architecture: Link

By Phil Yeh | Senior Automation Engineer

How I Fixed Python's Serial Freezing Issue: A Multi-threaded Tkinter Solution

Phil Yeh — Fri, 28 Nov 2025 01:51:40 +0000

As automation engineers, we hit a frustrating wall: writing a simple Modbus GUI tool with Tkinter, only to have the entire application freeze ("Not Responding") while waiting for the slow RS485 sensor to reply.

If you are dealing with serial I/O and real-time UI updates, the solution lies in proper threading.

🛠️ The Fix: Multi-threading for Stability

The core issue is blocking I/O. Since the main Tkinter loop handles the UI, waiting for the serial port stops the entire window from updating.

The professional solution is to use the threading module to separate the UI rendering thread from the I/O polling thread.

Core Threading Logic

We implemented a daemon thread dedicated solely to reading the Modbus device. This ensures the UI is responsive, even if the polling takes several seconds.

# The UI remains responsive because the heavy lifting runs in a separate thread.
def thread_helper(self):
    thread = threading.Thread(target=self.start_log, daemon=True)
    thread.start()
    # Tkinter mainloop continues to run smoothly

📘 Modbus Protocol Primer: Deciphering the Hex (Tutorial Value)
To effectively debug Modbus, you need to understand the structure of the command frame. The tool guides users through this structure directly on the screen:

(The default command in the tool is 01 03 00 00 00 03)

✨ Production Features (The True Value)
This project provides a robust, reusable template that is ready for industrial deployment. The source code handles all the time-consuming integration headaches:

Universal Serial Setup: Supports custom Data Bits (5-8), Parity (N, E, O), and Stop Bits (1, 1.5, 2).

Auto CRC-16: Automatically calculates and appends the Modbus checksum.

Raw Hex Logging: Logs both the raw response and parsed data to a CSV file.

📥 Get the Fully Integrated Solution
This article shares the architectural solution. If you want the complete, multi-threaded GUI source code—including the full UI logic, auto-CRC calculation, and CSV logging feature—you can acquire the packaged files here-$9.9.

By Phil Yeh | Senior Automation Engineer

Stop decoding Hex manually. I built a Python J1939 Sniffer with a GUI (No Hardware Needed)

Phil Yeh — Tue, 25 Nov 2025 00:57:06 +0000

After receiving the Top Docker Author badge last week for my Offline AI post (thanks everyone! 🙏), many of you asked about my workflow for hardware and vehicle networks.

So today, I'm switching gears from AI to Heavy Duty Vehicles.

If you work with CAN Bus or SAE J1939 (Trucks, Buses, Machinery), you know the pain:

Professional tools are expensive: A Vector CANalyzer license costs thousands of dollars.
Hex dumps are unreadable: Seeing 18FEF100 means nothing unless you memorize the J1939 spec.
Hardware dependency: You usually need a physical adapter (PCAN, Kvaser) just to test your code.

To solve this, I built a Python-based J1939 Sniffer that decodes PGNs automatically and includes a Simulation Mode for hardware-free development.

🏗️ The Challenge: Parsing 29-bit IDs

Standard CAN (11-bit) is simple. But J1939 uses 29-bit Extended Identifiers, which pack a lot of data:

Priority (3 bits)
PGN (Parameter Group Number) (18 bits) <--- The most important part
Source Address (8 bits)

If you get a raw ID like 0x18FEF100, you need to extract the PGN to know what the message actually is.

The Python Logic

Here is the core logic I used to extract the PGN and Source Address from a raw integer ID:

def parse_j1939_id(can_id):
    """
    Extract PGN and Source Address from a 29-bit CAN ID.
    Format: [Priority(3)] [Reserved(1)] [Data Page(1)] [PDU Format(8)] [PDU Specific(8)] [Source Address(8)]
    """
    # Shift right by 8 bits to drop Source Address
    # Mask with 0x3FFFF to keep only the 18-bit PGN
    pgn = (can_id >> 8) & 0x3FFFF

    # Mask with 0xFF to get the last 8 bits
    source_address = can_id & 0xFF

    # Shift right by 26 bits to get Priority
    priority = (can_id >> 26) & 0x7

    return pgn, source_address, priority

🛠️ The Solution: A GUI Sniffer
I wrapped this logic into a Tkinter GUI using the python-can library. It listens to the bus, parses the ID, and looks up the PGN in a built-in dictionary.

The Result
Instead of staring at 18FEF100, the tool tells you: 👉 CCVS - Vehicle Speed

Instead of 0CF00400, it shows: 👉 EEC1 - Engine Speed (RPM)

Features
🚛 Auto-Decode: Built-in dictionary for common PGNs (RPM, Temp, Speed, Battery).

🎮 Simulation Mode: Click "Start Demo" to generate fake J1939 traffic. Perfect for testing UI logic without sitting in a truck.

🔌 Universal Support: Works with Vector, Peak-System (PCAN), Kvaser, and slcan via python-can.

📥 Try it yourself
I have open-sourced the project structure and the J1939 parsing logic on GitHub. You can use it as a template for your own ECU tools.

🔗 GitHub Repository: Python-CAN-Bus-J1939-Sniffer-GUI

🎁 For those who want the full package: If you want the complete, production-ready source code (including the GUI, Simulation Mode, and Multi-threading), I've made it available on Gumroad.

🔥 Black Friday Deal: Use code BLACKFRIDAY for 15% OFF all my engineering tools.

👉 Get the Full Source Code(link)

Happy Hacking! 🚛

5 Python Tools I Built to Automate My Industrial IoT Workflow (Open Source)

Phil Yeh — Thu, 20 Nov 2025 10:00:43 +0000

Update: 🏷️ Black Friday Sale is ON! Use code BLACKFRIDAY for 15% OFF on the Ultimate Toolkit.

As a Senior Automation Engineer, I spend half my life debugging communication protocols. Modbus, MQTT, CAN Bus, Ethernet/IP... you name it.

The problem is, most professional tools (like Vector CANalyzer or proprietary PLC software) are:

Expensive (Thousands of dollars).
Windows-only (I love Docker/Linux).
Closed Source (I can't customize them).

So, over the past few weekends, I decided to build my own "Survival Toolkit" using Python.

Here are the 5 open-source tools I created to replace expensive software, all available on my GitHub.

1. The "Privacy-First" AI Datasheet Reader

Problem: I have hundreds of PDF datasheets to read, but I can't upload them to ChatGPT due to NDA/Privacy concerns.
Solution: A 100% offline RAG system using Docker + Llama 3.

It runs entirely on my local machine (RTX 3060). No data leaves the building.

Stack: Docker, Ollama, ChromaDB, Streamlit.
Repo: Local-AI-Knowledge-Base-Docker-Llama3

2. The J1939 & CAN Bus Sniffer

Problem: Debugging vehicle ECUs usually requires a $300+ hardware adapter just to see the data.
Solution: A Python GUI that works with cheap USB-CAN adapters (slcan) and automatically decodes J1939 PGNs.

It even has a "Demo Mode" to simulate traffic if you don't have hardware.

Stack: Python, tkinter, python-can.
Feature: Decodes Engine Speed, Temp, and other PGNs instantly.
Repo: Python-CAN-Bus-J1939-Sniffer-GUI

3. The "Anti-Freezing" Modbus Logger

Problem: Writing a simple Python script to read RS485 is easy, but the GUI always freezes (blocks) while waiting for the sensor to reply.
Solution: A multi-threaded Modbus RTU Master.

It separates the UI thread from the Serial polling thread, so the app remains responsive 100% of the time.

Stack: Python, tkinter, pyserial, threading.
Repo: Python-Modbus-Serial-Logger-GUI

4. The MQTT Data Recorder

Problem: Sometimes I just want to save MQTT sensor data to an Excel file for analysis, without setting up a database.
Solution: A lightweight MQTT Client that logs everything to CSV automatically.

Updated to support the latest Paho-MQTT v2.0 standard.

Stack: Python, paho-mqtt, csv.
Repo: Python-MQTT-Data-Logger-GUI

5. The Virtual Ethernet/IP Lab

Problem: Learning the CIP protocol (used by Rockwell/Omron PLCs) is hard without physical hardware.
Solution: A Mock PLC Server + Raw Socket Client.

It simulates the full Forward Open handshake and Implicit Messaging on your localhost.

Stack: Pure Python, socket, struct.
Repo: Python-EthernetIP-Raw-Socket-Client

🎁 Conclusion

Building your own tools is the best way to learn. Not only do you save money on licenses, but you also get full control over the source code.

I have open-sourced the documentation and basic architecture for all these projects on GitHub.

If you want the complete, production-ready source code for ALL these tools (5-in-1), I've bundled them together here:

👉 The Ultimate Senior Engineer Toolkit (Gumroad)

Happy coding!

Local RAG with Llama 3 & Docker: Build an Offline Second Brain (No OpenAI)

Phil Yeh — Tue, 18 Nov 2025 09:03:19 +0000

[UPDATE: Dec 2025] 🚀 Due to the overwhelming interest in this Local RAG setup, I’ve officially released the production-ready toolkit on Gumroad to help you save hours of configuration time!

Based on your feedback, I’ve created two versions to suit your needs:

Option 1: The "Lite" Edition ($59) – Perfect for developers! Get the full Dockerized source code, Streamlit UI, and PDF pipeline. Ideal if you want to deploy it yourself and own the code.

Option 2: The "Pro" Solution ($299) – For enterprises and busy professionals. Includes the full suite PLUS a 1-on-1 Remote Setup Service. I will personally ensure the system is perfectly tuned and running on your hardware.

Why use this?

100% Private: No data ever leaves your machine (No OpenAI/Cloud APIs).

One-Click Setup: Move from "dependency hell" to a functional RAG system in minutes using Docker.

Proven Results: Check out the new Demo Video on the product page to see it in action!

👉 Get the Local RAG Toolkit here

🎉 Update: Wow! This post was awarded the Top Docker Author Badge of the week! Thanks to everyone for the amazing support and feedback. 🙏

Stop sending your sensitive datasheets to the cloud. Here is how I deployed a private, enterprise-grade RAG system.

As a Senior Automation Engineer, I deal with hundreds of technical documents every month — datasheets, schematics, internal protocols, and legacy codebases.

We all know the power of LLMs like GPT-4. Being able to ask, “What is the maximum voltage for the RS485 module on page 42?” and getting an instant answer is a game-changer.

But there is a problem: Privacy.

I cannot paste proprietary schematics or NDA-protected specs into ChatGPT. The risk of data leakage is simply too high.

So, I set out to build a solution. I wanted a “Second Brain” that was:

100% Offline: No data leaves my local network.

Free to run: No monthly API subscriptions (bye-bye, OpenAI bills).

Dockerized: Easy to deploy without “dependency hell.”

Here is the architecture I built using Llama 3, Ollama, and Docker.

The Architecture: Why this Tech Stack?
Building a RAG (Retrieval-Augmented Generation) system locally used to be a nightmare of Python dependencies and CUDA driver issues. To solve this, I designed a containerized microservices architecture.

The Brain: Ollama + Llama 3
I chose Ollama as the inference engine because it’s lightweight and efficient. For the model, Meta’s Llama 3 (8B) is the current sweet spot — it’s surprisingly capable of reasoning through technical documentation and runs smoothly on consumer GPUs (like an RTX 3060).
The Memory: ChromaDB
For the vector database, I used ChromaDB. It runs locally, requires zero setup, and handles vector retrieval incredibly fast.
The Glue: Python & Streamlit
The backend is written in Python, handling the “Ingestion Pipeline”:

Parsing: Extracting text from PDFs.

Chunking: Breaking text into manageable pieces.

Embedding: Converting text into vectors using the mxbai-embed-large model.

UI: A clean Streamlit interface for chatting with the data.

How It Works (The “Happy Path”)
The beauty of this system is the Docker implementation. Instead of installing Python libraries manually, the entire system spins up with a single command.

The docker-compose.yml orchestrates the communication between the AI engine, the database, and the UI.

YAML

# Simplified concept of the setup
services:
  ollama:
    image: ollama/ollama:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  backend:
    build: ./app
    depends_on:
      - ollama
      - chromadb

Once running, the workflow is simple:

Drop your PDF files into the knowledge_base folder.

Click “Update Knowledge Base” in the UI.

Start chatting.

The system automatically vectorizes your documents. When you ask a question, it retrieves the most relevant paragraphs and feeds them to Llama 3 as context.

The Challenge: It’s Not Just About “Running” the Model
While the concept sounds simple, getting it to production-grade stability took me weeks of debugging.

Here is what most “Hello World” tutorials don’t tell you:

PDF Parsing is messy: Tables in engineering datasheets often break standard parsers.

Context Window limits: Llama 3 has a limit. You need a smart “Sliding Window” strategy for chunking large documents.

Docker Networking: Getting the Python container to talk to the Ollama container on the host GPU requires specific networking configurations.

I spent countless nights fixing connection timeouts, optimizing embedding models, and ensuring the UI doesn’t freeze during large file ingestions.

Want to Build Your Own?
If you are an engineer or developer who wants to own your data, I highly recommend building a local RAG system. It’s a great way to learn about GenAI architecture.

However, if you value your time and want to skip the configuration headaches, I have packaged my entire setup into a ready-to-deploy solution.

It includes:

✅ The Complete Source Code (Python/Streamlit).

✅ Production-Ready Docker Compose file.

✅ Optimized Ingestion Logic for technical docs.

✅ Setup Guide for Windows/Linux.

You can download the full package and view the detailed documentation on my GitHub.

👉 View the Project & Download Source Code on GitHub link

By Phil Yeh Senior Automation Engineer specializing in Industrial IoT and Local AI solutions.

Python MQTT Data Logger - A clean GUI to debug brokers & auto-save data to CSV.
Python CAN Bus & J1939 Sniffer - Decode vehicle data without expensive hardware.
Python Modbus Data Logger - Debug RS485 devices with a multi-threaded GUI.
Ethernet/IP Study Kit - Learn CIP protocol with a Python-based mock PLC. **** 👉 Get the Source Code for all these tools: Visit my Gumroad Store