
# Building a RAG-Powered Blog Search with Mistral AI

This blog runs on a **fully static Next.js export** deployed to OVH shared hosting — no Node.js server, no database, no serverless functions. Despite that constraint, I added a working **Retrieval-Augmented Generation (RAG) chat widget** to the articles page, powered by **Mistral AI**.

This post explains how it works under the hood, why it is meaningfully better than classic keyword search, and what comes next.

---

## 1. The Problem with Classic Search

The existing search was powered by **js-search**, a client-side full-text search library. It works by loading a pre-built JSON index and doing fuzzy keyword matching in the browser.

It does its job well for exact queries, but has several hard limits:

| Limitation | Example |
|---|---|
| Exact token matching only | `"NMEA 2000 CAN"` finds nothing for `"CAN bus temperature telemetry"` |
| No understanding of intent | Asking `"how do I secure SSH?"` returns posts containing the word *SSH*, regardless of relevance |
| No synthesised answer | The user gets a list of links — they still have to read everything |
| No cross-article reasoning | Can't answer `"which of your projects use both Docker and LLMs?"` |

The result: a search that works for people who already know what they are looking for, but fails for exploratory or conversational queries — which is exactly what a personal technical blog attracts.

---

## 2. What RAG Adds

**Retrieval-Augmented Generation** is a pattern where a language model answers a question using a specific curated context, rather than relying solely on its training data.

The pipeline has three stages:

```
Question
  → Retrieval: find the most relevant documents from my corpus
  → Augmentation: inject those documents into the LLM prompt
  → Generation: the model synthesises a grounded, cited answer
```

Applied to this blog, it means:

- A user asks `"How do you tunnel SSH through a VPS?"`
- The system retrieves the 3 most relevant articles from my index
- Mistral generates a precise answer based on *exactly what I wrote*, with links back to the source posts

The model doesn't hallucinate from general training data — it is constrained to my actual content.

---

## 3. Architecture

The constraint of static hosting on OVH shapes the entire design. There is no Next.js API route available at runtime — only static files and a PHP runtime.

```
┌─────────────────────────────────────────────────┐
│  Browser                                        │
│                                                 │
│  1. User types question                         │
│  2. js-search retrieves top-3 blog post chunks  │  ← client-side retrieval
│     from /content/search/index.json            │
│  3. POST /chat.php  { question, context[0..2] }│
└──────────────────────────┬──────────────────────┘
                           │  HTTPS
┌──────────────────────────▼──────────────────────┐
│  OVH PHP runtime  (chat.php)                    │
│                                                 │
│  4. Validates + rate-limits (5 req/min/session) │
│  5. Builds system prompt + article snippets     │
│  6. Calls api.mistral.ai  ← API key stays here  │
│  7. Returns { answer }                          │
└──────────────────────────┬──────────────────────┘
                           │
┌──────────────────────────▼──────────────────────┐
│  Browser                                        │
│  8. Renders answer + clickable source links     │
└─────────────────────────────────────────────────┘
```

Key design decisions:

- **API key lives in PHP only** — never in a `NEXT_PUBLIC_` variable, never in the browser bundle.
- **Retrieval is client-side** — js-search runs locally on the pre-built index with no round-trip.
- **Context is capped at 3 articles** — keeps token usage predictable and cost near zero on the free tier.
- **Model: `mistral-small-latest`** — fast, cheap, accurate enough for technical Q&A over short contexts.

---

## 4. Enriching the Search Index

The original `index.json` only contained `slug`, `title`, and `description` — too little context to ground an LLM answer.

At build time (`npm run build`), `saveSearchData()` now also extracts a **600-character plain-text snippet** from the raw Markdown of each post, stripping code blocks, headings, and link syntax:

```typescript
const extractSnippet = (markdown: string, maxLength = 600): string =>
    markdown
        .replace(/```[\s\S]*?```/g, '')       // remove code blocks
        .replace(/`[^`]*`/g, '')              // remove inline code
        .replace(/^#{1,6}\s+/gm, '')          // remove headings
        .replace(/!\[.*?\]$.*?$/g, '')      // remove images
        .replace(/\[([^\]]+)\]$[^)]+$/g, '$1') // keep link text
        .replace(/[*_~]/g, '')                // remove emphasis
        .replace(/\n+/g, ' ')
        .trim()
        .substring(0, maxLength);
```

Each index entry now looks like:

```json
{
  "slug": "2026-01-18-STM32F334C8T6-CAN-NMEA2000-Implementation",
  "title": "Implementing NMEA 2000 Temperature Telemetry on STM32F334",
  "description": "Building a dual-message CAN bus system...",
  "category": "blogs",
  "snippet": "This article documents the implementation of a dual PGN NMEA 2000..."
}
```

The snippet is sent as part of the context to Mistral — it is what makes the answer grounded rather than generic.

---

## 5. The PHP Proxy

`chat.php` is the only server-side component. Its responsibilities:

**Security**
- API key is hardcoded server-side — never exposed to the browser
- CORS restricted to `https://melnyk.ovh` and `localhost:3000`
- Input length capped at 500 characters
- Context array stripped of HTML via `strip_tags`

**Rate limiting**
- PHP sessions track request timestamps per visitor
- Maximum 5 requests per 60-second window per session

**Prompt construction**
```php
$system_prompt =
    "You are a helpful assistant for Artem Melnyk's personal technical blog. " .
    "Answer questions using ONLY the blog post excerpts provided below. " .
    "If the answer cannot be found in the context, say so honestly. " .
    "Be concise and technical. Always reference the relevant post title.";

$user_message = "Blog post excerpts:\n\n{$ctx_str}\n\nQuestion: {$question}";
```

The system prompt **constrains the model to the provided context** and explicitly asks it to admit when it doesn't know — reducing hallucination risk.

---

## 6. The React Component

`BlogChat.tsx` is dynamically imported (`ssr: false`) on the blog list page so it doesn't affect static generation or server bundle size.

The flow on each user query:

1. `ContentIndexer.search(question)` — runs js-search on the local index, filters to `category: 'blogs'`, takes top 3
2. If no results — short-circuits with a UI message, no API call made
3. `POST /chat.php` with `{ question, context }` — waits for Mistral response
4. Renders the answer as pre-wrapped text, followed by source links

A client-side 3-second throttle prevents accidental double-submissions without relying on server state.

---

## 7. Classic Search vs. RAG — Side by Side

| Feature | js-search (before) | RAG with Mistral (now) |
|---|---|---|
| Query type | Keywords | Natural language |
| Answer format | List of links | Synthesised prose |
| Cross-article reasoning | No | Yes |
| Handles typos / synonyms | Partial | Yes |
| Cited sources | No | Yes (with links) |
| Works offline | Yes | No |
| API cost | Free | ~$0.002 / query |
| Latency | < 50 ms | 1–3 s |
| Hallucination risk | None | Low (grounded) |

The two approaches are complementary. The existing keyword search remains for fast exact lookups; RAG handles exploratory and conversational queries.

---

## 8. Next Steps

### Short term

- **Stream the response** — Mistral supports SSE streaming; showing tokens as they arrive would improve perceived latency
- **Expand the index** — include full article content in chunks (512 tokens each) rather than a 600-char flat snippet; improves recall on long posts
- **Add the RAG widget to individual blog pages** — ask follow-up questions while reading a post

### Medium term

- **Vector embeddings** — replace js-search retrieval with cosine similarity over `mistral-embed` vectors stored in a static JSON file; significantly better semantic recall
- **Multi-turn conversation** — maintain a message history so users can ask follow-up questions in context
- **Feedback loop** — a thumbs up/down button on answers to learn which queries the current retrieval handles poorly

### Long term

- **Hybrid retrieval** — BM25 (keyword) + embedding similarity, re-ranked by a cross-encoder; the gold standard for production RAG
- **Move to an edge runtime** — if the site ever migrates off shared hosting, a Cloudflare Worker or Vercel Edge Function would drop latency to under 200 ms globally

---

## Conclusion

A personal blog on shared static hosting is not the obvious place to deploy RAG. But the combination of a pre-built JSON index for retrieval, a PHP proxy to guard the API key, and Mistral's free tier for generation makes it entirely practical — with zero infrastructure changes and about two hours of implementation.

The result is a search experience that understands questions rather than matching tokens, and answers them with direct citations to the actual content. For a technical blog covering diverse topics from STM32 firmware to LLM platforms, that is a meaningful improvement.


How I replaced keyword search with a Retrieval-Augmented Generation pipeline using Mistral AI, a client-side search index, and a secure PHP proxy — all on static shared hosting.

Building a RAG-Powered Blog Search with Mistral AI


# Building a Structured LLM Wiki from Scientific Sources

This article documents the practical implementation of a **structured LLM knowledge ingestion workflow**.

The objective was to transform **scattered web pages and peer-reviewed articles** into a **queryable knowledge system** capable of supporting structured reasoning.

Inspired by the **LLM Wiki architecture**, the workflow focuses on building a persistent knowledge layer before querying any model.

---

# 1. Creating a Dedicated Knowledge Workspace

The first step was to initialize a **clean knowledge environment**.

## Create a New Obsidian Vault

This vault acts as the central repository for all knowledge artifacts.

Structure:

```
Vault/
 ├── Clipping/
 ├── PDFs/
 ├── Wiki/
 └── Logs/
```

This separation ensures:

- traceability  
- modular structure  
- predictable ingestion  

---

# 2. Setting Up the Agentic Environment

The ingestion workflow is executed inside an **agent-assisted development environment**.

Environment used:

- Antigravity  
- Claude Code  
- Obsidian Vault (mounted workspace)  

This enables:

- repeatable prompts  
- automated indexing  
- structured content generation  

---

# 3. Initializing the LLM Wiki Schema

The wiki structure is initialized using the **Karpathy LLM Wiki prompt**.

Reference:

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

This schema defines:

- page organization  
- indexing rules  
- linking strategy  
- maintenance logic  

Example:

```
index.md
topics/
concepts/
references/
log.md
```

This creates the **foundation of the knowledge graph**.

---

# 4. Capturing Source Material

Two categories of sources were collected:

## Web Sources

Captured using:

**Obsidian Web Clipper**

Each page was:

- reviewed  
- saved as Markdown  
- placed into:

```
Clipping/
```

---

## Scientific PDFs

Peer-reviewed, open-access papers were manually collected and stored in:

```
PDFs/
```

Source discipline included:

- publication validation  
- relevance filtering  
- topic alignment  

This ensured **high signal-to-noise ratio**.

---

# 5. Indexing the Clipping Folder

The first transformation step begins here.

Raw Markdown files are converted into structured entries.

## Prompt Used

```
Index the Markdown files in the Clipping folder
and create initial wiki entries with topics,
concepts, and references.
```

This produces:

- topic pages  
- concept definitions  
- source references  

At this stage:

**the knowledge graph begins to form.**

---

# 6. Ingesting Scientific PDF Articles

Scientific articles are processed using a structured ingestion prompt.

Reference:

https://gist.github.com/artemmelnyk-extern/e9e54d962284838d6c246a99caf04125

Each article is:

1. Renamed consistently  
2. Processed using the prompt  
3. Converted into structured wiki pages  

Expected outputs:

- structured summaries  
- extracted concepts  
- cross-links  
- references  

This step significantly expands the knowledge network.

---

# 7. Querying the Knowledge Base

After ingestion, the system becomes **queryable**.

Not searchable.

Queryable.

That distinction is fundamental.

Example interaction:

```
Query:
Explain the relationship between Topic A and Topic B
based on the ingested sources.
```

The answer now reflects:

- structured context  
- linked knowledge  
- curated sources  

Not raw text fragments.

---

# 8. Visualizing the Knowledge Graph

The Obsidian graph provides a visual confirmation of structure.

Each:

- node = structured knowledge  
- edge = contextual relationship  

This visualization confirms:

**the transformation from documents to knowledge.**

---

# Architecture Overview

```
Raw Sources
      ↓
Clipping
      ↓
Indexing
      ↓
PDF Ingestion
      ↓
Linked Wiki
      ↓
Queryable Knowledge
```

This architecture transforms:

**Information → Knowledge → Reasoning**

---

# Result

After full ingestion:

- knowledge became modular  
- relationships became visible  
- querying became meaningful  

The system evolved from:

**file storage**

to:

**knowledge infrastructure**

---

# Key Takeaways

1. Knowledge must be structured before reasoning  
2. Source quality determines reasoning quality  
3. Linking is as important as content  
4. Indexing creates the first real structure  
5. Querying is the final step — not the first  

---

# Conclusion

This workflow demonstrates how modern LLM systems benefit from **structured knowledge ingestion** rather than raw document retrieval.

The shift is not about smarter models.

It is about **better knowledge architecture**.


A practical workflow for building a structured LLM knowledge base using Obsidian, Claude Code, and curated scientific sources.

Building a Structured LLM Wiki from Scientific Sources


# Implementing NMEA 2000 Temperature Telemetry on STM32F334

This article documents the development of a **dual-message CAN bus system** implementing NMEA 2000 compliance for industrial temperature monitoring on an STM32F334C8T6 microcontroller.

## Project Evolution: v0.0.1 → v0.0.3

### v0.0.1: Initial CAN Implementation
Started with basic CAN transmission at 250 kbps, sending a simple DEADBEEF test pattern to validate hardware and toolchain.

### v0.0.2: Temperature Sensor Integration
Integrated STM32's internal ADC temperature sensor with factory calibration, combining DEADBEEF pattern and temperature data in a single message.

### v0.0.3: NMEA 2000 Compliance
Separated messages into two distinct protocols:
- **A1 Message**: High-frequency heartbeat (30 Hz)
- **T1 Message**: NMEA 2000 compliant temperature telemetry (1 Hz)

---

## NMEA 2000 Protocol Implementation

### Why NMEA 2000?
NMEA 2000 is the industry standard for marine and industrial sensor networks, providing:
- **Interoperability**: Works with standard displays and logging equipment
- **Structured data**: Well-defined Parameter Group Numbers (PGNs)
- **Robust networking**: Based on CAN bus with 29-bit Extended IDs

### PGN 130312: Temperature Standard

The T1 message implements **PGN 130312 - Temperature**, a standardized format for temperature telemetry:

```
Extended 29-bit CAN ID: 0x19FD0801

Bit Structure:
  Bits 26-28: Priority = 6 (low priority for slow-changing data)
  Bit 25:     Reserved = 0
  Bit 24:     Data Page = 1
  Bits 16-23: PDU Format = 0xFD
  Bits 8-15:  PDU Specific = 0x08
  Bits 0-7:   Source Address = 0x01 (device address)
  
PGN Calculation:
  PGN = (Data Page << 16) | (PDU Format << 8) | PDU Specific
  PGN = (1 << 16) | (0xFD << 8) | 0x08 = 130312
```

### Message Format

**T1 Data Payload (8 bytes):**
```
Byte 0: SID (Sequence ID) - Increments with each message
Byte 1: Temperature Instance (0 = single sensor)
Byte 2: Temperature Source (1 = Inside Temperature)
Byte 3-4: Temperature in Kelvin × 100 (uint16, little-endian)
Byte 5-7: Reserved (0xFF)
```

**Example CAN Message:**
```
slcan0  19FD0801  [8]  09 00 01 3B 72 FF FF FF

Decoding:
  SID: 0x09 (9)
  Instance: 0x00 (single sensor)
  Source: 0x01 (inside temperature)
  Temperature: 0x723B = 29243
    → Kelvin = 29243 / 100 = 292.43K
    → Celsius = 292.43 - 273.15 = 19.28°C
```

---

## Message Architecture

### A1 Message: High-Frequency Heartbeat
- **CAN ID**: 0x0A1 (Standard 11-bit)
- **Rate**: 30 Hz (33ms period)
- **Payload**: `DE AD BE EF 00 00 00 00`
- **Purpose**: Fast status indication and bus presence

### T1 Message: Temperature Telemetry
- **CAN ID**: 0x19FD0801 (Extended 29-bit)
- **Rate**: 1 Hz
- **Payload**: NMEA 2000 PGN 130312 format
- **Purpose**: Industrial-standard temperature reporting

---

## Implementation Details

### Temperature Sensor
STM32F334's internal temperature sensor (ADC1_IN16) with factory calibration:
```c
// Factory calibration values at 30°C and 110°C
uint16_t *TS_CAL1 = (uint16_t*)0x1FFFF7B8;
uint16_t *TS_CAL2 = (uint16_t*)0x1FFFF7C2;

// Linear interpolation
float tempCelsius = 30.0f + (rawADC - *TS_CAL1) * 
                    (110.0f - 30.0f) / (*TS_CAL2 - *TS_CAL1);
```

### Main Loop Timing
```c
while (1) {
  HAL_Delay(33U);  // 30Hz base rate
  
  // A1: Send every cycle (30 Hz)
  uint8_t a1Data[8] = {0xDE, 0xAD, 0xBE, 0xEF, 0x00, 0x00, 0x00, 0x00};
  HAL_CAN_AddTxMessage(&hcan, &txHeaderA1, a1Data, &canMailbox);
  
  // T1: Send every 30 cycles (1 Hz)
  if (++t1Counter >= 30) {
    t1Counter = 0;
    uint16_t tempKelvin = (uint16_t)((tempCelsius + 273.15f) * 100.0f);
    uint8_t t1Data[8] = {
      nmea2000_sid++,         // SID
      0x00,                   // Instance
      0x01,                   // Source (Inside)
      (uint8_t)(tempKelvin),  // Temp low byte
      (uint8_t)(tempKelvin >> 8), // Temp high byte
      0xFF, 0xFF, 0xFF        // Reserved
    };
    HAL_CAN_AddTxMessage(&hcan, &txHeaderT1, t1Data, &canMailbox);
  }
}
```

---

## Hardware Validation

Using SocketCAN on Linux with SLCAN adapter:

```bash
candump slcan0

# Output showing both messages:
slcan0  0A1   [8]  DE AD BE EF 00 00 00 00  # A1 @ 30Hz
slcan0  0A1   [8]  DE AD BE EF 00 00 00 00
...
slcan0  19FD0801  [8]  09 00 01 3B 72 FF FF FF  # T1 @ 1Hz (19.28°C)
```

---

## Design Decisions

### Priority Level 6
Chose **priority 6 (low)** for temperature data because:
- Temperature changes slowly (not time-critical)
- 1 Hz update rate is sufficient
- Higher priority reserved for critical control messages

### Source Address 0x01
Used **source address 0x01** (instead of 0x00) because:
- 0x00 can cause conflicts in multi-device networks
- Each device should have a unique address (0-251 range)
- Enables proper device identification on NMEA 2000 networks

### Temperature Source = 1 (Inside Temperature)
Best match for MCU internal temperature among NMEA 2000 options:
- Represents the internal environment of the device
- Alternative could be Source 3 (Engine Room) for electronics enclosures

---

## Toolchain

- **Microcontroller**: STM32F334C8T6 (ARM Cortex-M4, 64KB Flash)
- **Compiler**: arm-none-eabi-gcc 13.2.1
- **Debugger/Programmer**: st-flash 1.8.0 (STLink v2)
- **CAN Interface**: SLCAN adapter for testing
- **Build System**: GNU Make
- **Version Control**: Git with semantic versioning

---

## Results

Successfully implemented a production-ready dual-message CAN system:

✅ **A1 heartbeat** transmitting at 30 Hz  
✅ **T1 NMEA 2000** temperature at 1 Hz  
✅ Temperature accuracy: ±1°C (factory calibrated)  
✅ Binary size: 8,672 bytes (13% of 64KB flash)  
✅ NMEA 2000 PGN 130312 compliant  
✅ Hardware validated on CAN bus

---

## Future Enhancements

- Implement CAN receive for bidirectional communication
- Add additional NMEA 2000 PGNs (voltage, current, etc.)
- Implement address claiming for dynamic addressing
- Add error handling for CAN bus-off states
- Power consumption optimization (sleep modes)

---

## Repository

Full source code available on GitHub:  
[STM32F334C8T6-CAN](https://github.com/artemmelnyk-extern/STM32F334C8T6-CAN)

**Release**: v0.0.3 (2026-01-18)

---

## Conclusion

This project demonstrates successful integration of NMEA 2000 standards into embedded systems, providing a foundation for industrial-grade sensor telemetry. The dual-message architecture balances fast status updates with standardized data reporting, making it suitable for both diagnostic purposes and integration with commercial NMEA 2000 displays and logging equipment.

The separation of messages allows flexible system architecture where high-frequency heartbeats ensure system health monitoring while low-frequency telemetry conserves bus bandwidth and follows industry best practices.


Building a dual-message CAN bus system with NMEA 2000 PGN 130312 compliance for industrial temperature monitoring on STM32 microcontroller.

Implementing NMEA 2000 Temperature Telemetry on STM32F334


# Building a Secure Full-Stack LLM Platform on iarium.com

This article documents the full installation and configuration of a **secure Large Language Model (LLM) platform** hosted on `iarium.com`.  
The objective is to deploy a **production-grade AI stack** with:

- Hardened SSH access  
- Strict firewalling (UFW)  
- Intrusion protection (Fail2Ban)  
- Local LLM inference (Ollama)  
- Web interface (OpenWebUI in Docker)  
- HTTPS reverse-proxy with automatic certificates (Caddy)  

All steps below were executed on a Debian-based VPS.

---

## 1. Server Hardening (SSH, UFW, Fail2Ban)

### SSH Configuration

```bash
sudo nano /etc/ssh/sshd_config
```

Only specific IPs were allowed to connect to port 22.

### Install Fail2Ban

```bash
sudo apt install fail2ban
sudo reboot
```

### Firewall Reset & Reconfiguration

```bash
sudo ufw --force reset
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from YOUR_IP to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw logging on
```

### Monitoring

```bash
sudo ufw status numbered
sudo journalctl -u fail2ban.service -n 200 -o cat
```

---

## 2. Installing Ollama (LLM Backend)

### Installation

```bash
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
```

### Pulling Models

```bash
ollama pull llama3.1:8b-instruct
ollama pull llama3
ollama pull phi3
```

### Exposing the API Externally

```ini
[Service]
Environment=OLLAMA_HOST=0.0.0.0
Environment=OLLAMA_ORIGINS=*
```

Reload:

```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```

### API Test

```bash
curl http://127.0.0.1:11434/api/version
```

---

## 3. Running OpenWebUI (Front-End)

```bash
sudo docker run -d --name openwebui   -p 3000:8080   --add-host=host.docker.internal:host-gateway   -e OLLAMA_BASE_URL=http://host.docker.internal:11434   -v openwebui_data:/app/backend/data   --restart unless-stopped   ghcr.io/open-webui/open-webui:main
```

### Backend Status Check

```bash
sudo docker ps
sudo docker logs -f openwebui | grep ollama
```

---

## 4. HTTPS Reverse-Proxy Using Caddy

### Install Caddy

```bash
sudo apt install caddy
```

### Example Caddyfile

```caddy
iarium.com {
    reverse_proxy 127.0.0.1:11434
}

chat.iarium.com {
    reverse_proxy 127.0.0.1:3000
}
```

Reload:

```bash
sudo systemctl reload caddy
```

### DNS Diagnostics

```bash
dig +short chat.iarium.com
host chat.iarium.com
```

---

## 5. Final End-to-End Tests

```bash
curl -I http://127.0.0.1:11434/api/version
curl -I http://127.0.0.1:3000
curl -I https://iarium.com/api/version
curl -I https://chat.iarium.com
```

---

## 6. Result: A Fully Secure LLM Platform

Architecture:

```
                 +----------------------+
                 |      Internet        |
                 +-----------+----------+
                       HTTPS | 80/443
                             |
+------------------------------------------------------+
|                      Caddy Proxy                     |
|   iarium.com/api → 127.0.0.1:11434 (Ollama API)      |
|   chat.iarium.com → 127.0.0.1:3000 (OpenWebUI)       |
+----------------------+-------------------------------+
                       |
               +-------+--------+
               |    UFW + F2B   |
               +-------+--------+
                       |
         +-------------+-------------+
         |                           |
+--------+--------+        +---------+--------+
|    Ollama LLM    |        |   OpenWebUI     |
|  (local models)  |        |  (Docker)       |
|  11434/tcp       |        |  3000/tcp       |
+------------------+        +-----------------+
```

---

## 7. Asking 
```
curl http://5.135.138.96:11434/api/generate -d '{ "model":"llama3",  "prompt":"Explique la différence entre un serveur et un client en 3 points." }'
```  

## Conclusion

The platform deployed on `iarium.com` is now a **secure, production-grade AI stack**, capable of running modern LLMs locally with a clean web interface served over HTTPS.



Full installation guide for a hardened LLM platform using Ollama, OpenWebUI, Caddy, UFW, and Fail2Ban.

Building a Secure Full-Stack LLM Platform on iarium.com



# Raspberry Pi SSH Access via VPS - Installation Guide

## Overview
This setup creates a **reverse SSH tunnel** from your Raspberry Pi to your VPS, allowing you to SSH into your Pi from anywhere through the VPS.

## Architecture
```
[Your Computer] → [VPS:22] → [Tunnel:2222] → [Raspberry Pi:22]
```

## Step-by-Step Installation

### Step 1: VPS Setup

1. **SSH into your VPS:**
   ```bash
   ssh root@YOUR_VPS_IP
   ```

2. **Create tunnel user:**
   ```bash
   sudo useradd -m -s /bin/bash rpi-tunnel
   sudo -u rpi-tunnel mkdir -p /home/rpi-tunnel/.ssh
   sudo -u rpi-tunnel chmod 700 /home/rpi-tunnel/.ssh
   sudo -u rpi-tunnel touch /home/rpi-tunnel/.ssh/authorized_keys
   sudo -u rpi-tunnel chmod 600 /home/rpi-tunnel/.ssh/authorized_keys
   ```

3. **Configure SSH daemon:**
   ```bash
   sudo nano /etc/ssh/sshd_config
   ```
   
   Add at the end:
   ```
   Match User rpi-tunnel
       AllowTcpForwarding yes
       PermitOpen localhost:2222
       GatewayPorts no
   ```

4. **Restart SSH:**
   ```bash
   sudo systemctl restart sshd
   ```

### Step 2: Raspberry Pi Setup

1. **SSH into your Raspberry Pi:**
   ```bash
   ssh pi@RASPBERRY_PI_IP
   ```

2. **Generate SSH key (if not exists):**
   ```bash
   ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""
   ```

3. **Display public key:**
   ```bash
   cat ~/.ssh/id_rsa.pub
   ```

4. **Copy this key to VPS** (from RPi):
   ```bash
   ssh-copy-id -i ~/.ssh/id_rsa.pub rpi-tunnel@YOUR_VPS_IP
   ```
   
   Or manually: Copy the output and add it to `/home/rpi-tunnel/.ssh/authorized_keys` on VPS

5. **Test connection:**
   ```bash
   ssh rpi-tunnel@YOUR_VPS_IP
   ```
   (Should connect without password, then exit)

6. **Create tunnel script:**
   ```bash
   nano ~/rpi-tunnel.sh
   ```
   
   Paste:
   ```bash
   #!/bin/bash
   VPS_IP="YOUR_VPS_IP"
   VPS_USER="rpi-tunnel"
   REMOTE_PORT=2222
   LOCAL_PORT=22

   while true; do
       ssh -N -R ${REMOTE_PORT}:localhost:${LOCAL_PORT} \
           -o ServerAliveInterval=30 \
           -o ServerAliveCountMax=3 \
           -o ExitOnForwardFailure=yes \
           ${VPS_USER}@${VPS_IP}
       
       echo "Tunnel disconnected. Reconnecting in 10 seconds..."
       sleep 10
   done
   ```
   
   Make executable:
   ```bash
   chmod +x ~/rpi-tunnel.sh
   ```

7. **Test the tunnel:**
   ```bash
   ./rpi-tunnel.sh
   ```
   (Leave it running, open new SSH session to continue)

### Step 3: Make Tunnel Persistent (Auto-start)

1. **Create systemd service:**
   ```bash
   sudo nano /etc/systemd/system/rpi-tunnel.service
   ```
   
   Paste (replace `pi` with your username):
   ```ini
   [Unit]
   Description=Raspberry Pi Reverse SSH Tunnel
   After=network-online.target
   Wants=network-online.target

   [Service]
   Type=simple
   User=pi
   ExecStart=/home/pi/rpi-tunnel.sh
   Restart=always
   RestartSec=10

   [Install]
   WantedBy=multi-user.target
   ```

2. **Enable and start service:**
   ```bash
   sudo systemctl daemon-reload
   sudo systemctl enable rpi-tunnel
   sudo systemctl start rpi-tunnel
   ```

3. **Check status:**
   ```bash
   sudo systemctl status rpi-tunnel
   ```

### Step 4: Connect to Raspberry Pi

1. **From anywhere, SSH to your VPS:**
   ```bash
   ssh root@YOUR_VPS_IP
   ```

2. **Then connect to RPi through tunnel:**
   ```bash
   ssh -p 2222 pi@localhost
   ```

3. **Optional: Create shortcut script on VPS:**
   ```bash
   echo 'ssh -p 2222 pi@localhost' > ~/connect-rpi.sh
   chmod +x ~/connect-rpi.sh
   ```

## Troubleshooting

### Check if tunnel is active on VPS:
```bash
sudo netstat -tlnp | grep 2222
```

### View Raspberry Pi tunnel logs:
```bash
sudo journalctl -u rpi-tunnel -f
```

### Manual tunnel test from RPi:
```bash
ssh -N -R 2222:localhost:22 rpi-tunnel@YOUR_VPS_IP
```

### Reset everything:
**On VPS:**
```bash
sudo pkill -u rpi-tunnel
```

**On RPi:**
```bash
sudo systemctl stop rpi-tunnel
```

## Security Notes

- Only `localhost` connections to port 2222 are allowed on VPS
- The tunnel user has minimal privileges
- SSH keys are used instead of passwords
- Tunnel auto-reconnects if dropped

## One-Line Direct Connection (Advanced)

From your computer, connect directly:
```bash
ssh -J root@YOUR_VPS_IP -p 2222 pi@localhost
```

This uses SSH jump host to connect through VPS in one command.


 Raspberry Pi SSH Access via VPS - Installation Guide

Raspberry Pi SSH Access via VPS


# 🚀 Introducing Sensor Data Uploader: Effortless Sensor Telemetry from Edge Devices

We’re excited to announce the first public release of **Sensor Data Uploader**, a lightweight and efficient open-source tool designed to **collect, process, and transmit sensor data** from edge devices to your backend or cloud platform — reliably and securely.

---

## 🔧 What Is It?

**Sensor Data Uploader** is a C++-based command-line application designed to run on embedded Linux systems, Raspberry Pi, and industrial gateways. It reads local sensor data, formats it, and sends it over HTTP using `libcurl`. It also integrates seamlessly with **systemd**, allowing it to be managed like a proper Linux service.

---

## 💡 Why Did We Build It?

Managing sensor fleets in industrial or research environments often means:

- Dealing with fragmented data sources  
- Writing repetitive upload scripts  
- Fighting flaky Wi-Fi or limited compute

We needed something:

- **Simple** enough to configure  
- **Reliable** on low-power hardware  
- **Easy to deploy** via `.deb` packages  

So we built one!

---

## ✅ Key Features

- 📦 Lightweight binary with no runtime dependencies  
- 🌐 Configurable HTTP POST endpoint  
- 🔐 Secure and retry-capable upload logic  
- 🔁 Systemd service ready for automation  
- 🧪 Fully open-source & CI-packaged for Debian systems  

---

## 📥 How to Install

You can install it in seconds from our APT repository:

```bash
echo "deb [trusted=yes] https://melnyk.ovh/apt/binary-amd64/ ./" | sudo tee /etc/apt/sources.list.d/melnyk.list
sudo apt update
sudo apt install sensor-data-uploader
```

Then start and check logs:

```bash
sudo systemctl enable --now send-sensor-probe.service
journalctl -u send-sensor-probe.service -f
```

---

## 📡 Ready for the Field

The tool is now running in field trials and internal deployments. It’s designed to scale — plug it into your own MQTT broker, database, or cloud function.

---

## 🤝 Contributions Welcome

This is just the beginning. We're planning:

- JSON config parsing  
- MQTT and WebSocket backends  
- Optional local buffering  

If you're building an IoT project or managing edge sensors — we’d love your feedback or contributions!

---

## 🔗 Links

- **GitLab Repo:** [🔗 [link-to-repo](https://gitlab.com/didactic/cpp/send-sensor-probe#)]
- **Debian APT Repo:** [https://melnyk.ovh/apt/](https://melnyk.ovh/apt/)
- **License:** BSD License

Runs a shell command to collect sensor or system output

A modern C++17 utility that collect PC sensors data and upload as a file via HTTP POST

# The Future of Automotive Software Development: Navigating Innovation in Electric Vehicles

The automotive industry is undergoing a profound transformation, driven by the rapid adoption of electric vehicles (EVs) and the integration of advanced software systems. As an embedded software developer specializing in electric cars, I’ve witnessed firsthand how software is becoming the backbone of modern automotive innovation. In this blog post, I’ll explore key trends, challenges, and opportunities shaping the future of automotive software development.

## The Rise of Software-Defined Vehicles

Electric vehicles are no longer just about battery packs and motors. They’re increasingly software-defined, meaning that the vehicle’s functionality, from basic operations to advanced features, is determined by software. Software-defined vehicles (SDVs) allow manufacturers to:

- Update functionality over-the-air (OTA).
- Enable real-time diagnostics and predictive maintenance.
- Integrate with smart ecosystems, including IoT and renewable energy grids.

## Challenges in Embedded Automotive Software

1. **Real-Time Constraints**:
   Automotive systems demand real-time performance. For example, safety-critical systems like braking and steering must respond within milliseconds.

2. **High Reliability and Safety Standards**:
   Standards like ISO 26262 ensure functional safety, requiring rigorous testing and validation processes.

3. **Scalability and Modularity**:
   With the complexity of modern EV architectures, developers need scalable software solutions that can adapt to different vehicle platforms.

4. **Cybersecurity Threats**:
   As connectivity increases, so does the potential for cyber-attacks. Ensuring robust security measures is non-negotiable.

## Emerging Trends to Watch

### 1. Artificial Intelligence and Machine Learning

AI is transforming how vehicles perceive and interact with their environment. Applications range from autonomous driving algorithms to adaptive energy management systems. For embedded developers, this means integrating AI models efficiently within hardware constraints.

### 2. Vehicle-to-Everything (V2X) Communication

V2X technology enables vehicles to communicate with each other, infrastructure, and pedestrians. This not only improves safety but also enhances traffic management and energy efficiency in EVs.

### 3. Unified Software Platforms

Automotive giants are consolidating software development with unified platforms. These platforms streamline development, deployment, and updates, ensuring a consistent experience across different vehicle models.

### 4. Open-Source Collaboration

Open-source initiatives are gaining traction in the automotive world. By leveraging community-driven frameworks, developers can accelerate innovation while reducing costs.

## Opportunities for Developers

The shift towards software-defined vehicles presents immense opportunities for developers:

- **Collaborating on Cross-Disciplinary Teams**: Software engineers now work alongside hardware designers, data scientists, and cybersecurity experts.
- **Contributing to Sustainability**: Developing software that optimizes energy efficiency aligns with global sustainability goals.
- **Building Career-Defining Projects**: The automotive domain offers unique challenges and rewards, making it a fertile ground for career growth.

## Conclusion

As EVs continue to evolve, embedded software developers will play a pivotal role in shaping the future of mobility. By embracing innovation, addressing challenges, and leveraging emerging trends, we can drive meaningful change in the automotive landscape. The journey ahead is both exciting and demanding, but it’s undoubtedly a road worth traveling.

What are your thoughts on the future of automotive software? Let’s discuss in the comments below!



The automotive industry is undergoing a profound transformation, driven by the rapid adoption of electric vehicles (EVs) and the integration of advanced software systems.

The Future of Automotive Software Development


# Transforming Healthcare with AI: The Future of Precision Medicine

Healthcare is on the cusp of a technological revolution, with artificial intelligence (AI) at its forefront. From diagnosing diseases to personalizing treatments, AI is reshaping how we approach medicine and patient care. As a developer in this dynamic field, I’ve witnessed the transformative potential of AI-powered solutions in healthcare. This blog post delves into the current trends, challenges, and opportunities that AI brings to precision medicine.

## The Promise of AI in Healthcare

AI technologies, particularly machine learning (ML) and deep learning, are being applied across a wide spectrum of healthcare applications, including:

- **Disease Diagnosis**: AI models trained on medical images and data are achieving unprecedented accuracy in identifying conditions like cancer, heart disease, and neurological disorders.
- **Predictive Analytics**: AI algorithms analyze patient data to predict disease onset, enabling early intervention and improved outcomes.
- **Drug Discovery**: AI accelerates the drug development pipeline by identifying promising compounds and predicting their efficacy.
- **Personalized Treatment Plans**: By analyzing genetic, clinical, and lifestyle data, AI tailors treatments to individual patients, enhancing efficacy and minimizing side effects.

## Challenges in Adopting AI in Healthcare

1. **Data Privacy and Security**:
   Medical data is sensitive and highly regulated. Ensuring AI systems comply with standards like HIPAA and GDPR is crucial.

2. **Bias in AI Models**:
   AI systems can perpetuate biases present in training data, leading to unequal treatment recommendations for different patient groups.

3. **Integration with Existing Systems**:
   Healthcare institutions often rely on legacy systems. Seamlessly integrating AI solutions into these environments requires robust interoperability.

4. **Regulatory Hurdles**:
   The approval process for AI-based medical devices and software is stringent, involving rigorous testing and validation.

## Emerging Trends in AI-Driven Healthcare

### 1. Natural Language Processing (NLP) in Medical Records

NLP tools are revolutionizing how we handle unstructured medical data. From summarizing patient histories to automating administrative tasks, NLP improves efficiency and reduces burnout for healthcare professionals.

### 2. AI in Remote Patient Monitoring

With wearable devices and IoT, AI algorithms monitor patient health in real-time, enabling proactive care and reducing hospital readmissions.

### 3. Digital Twins in Medicine

Digital twin technology creates virtual replicas of patients to simulate treatments and predict outcomes, offering a glimpse into truly personalized medicine.

### 4. AI-Assisted Surgery

AI is enhancing surgical precision through robotic systems that assist surgeons in complex procedures, reducing risks and improving recovery times.

## Opportunities for Developers

The intersection of AI and healthcare opens exciting avenues for innovation:

- **Developing Ethical AI Models**: Building systems that prioritize fairness, transparency, and inclusivity.
- **Collaborating Across Disciplines**: Working with clinicians, biostatisticians, and data scientists to create impactful solutions.
- **Leveraging Big Data**: Harnessing vast healthcare datasets to uncover insights and drive discovery.
- **Fostering Accessibility**: Ensuring AI solutions are affordable and accessible to underserved populations.

## Conclusion

The integration of AI in healthcare is not just a technological shift but a paradigm shift in how we envision medicine. By addressing challenges and harnessing the power of emerging trends, developers and healthcare professionals can together pave the way for a future where precision medicine becomes the norm.

How do you see AI shaping the future of healthcare? Share your thoughts in the comments below!



Healthcare is on the cusp of a technological revolution, with artificial intelligence (AI) at its forefront.

All Blogs