Du siehst:  OBD-Adapter-BRIDGE Paket V2.1  ·  Stand 12. April 2026
Paket V2.1 · ESP32 · NimBLE 1.4.x · LoRa · OBD-II · HTTP · ESP32 WROOM · MCP2515

OBD-Adapter BLE
Bridge Paket V2.1 · Heltec WiFi LoRa 32 (V3) · SX1262 · NimBLE 1.4.x · ESP32 WROOM · MCP2515

Verbindet sich per Bluetooth Low Energy mit einem OBD-BLE-Dongle, liest OBD-II-PIDs aus und stellt alle Werte gleichzeitig auf einem OLED, per TCP/WLAN und per LoRa bereit. Kein Smartphone, keine App, kein Abo.

Paket V2.1 Heltec LoRa V3 SX1262 NimBLE 1.4.x 43 PIDs 868 MHz DE/EU TCP Port 1234 HTTP Port 80 SF7 · BW125 SSD1306 OLED Python GUI Open Source ESP32 WROOM · MCP2515
LIVE-DEMO — simulierte OBD-Werte DEMO
Drehzahl 2340 1/min
Speed 74 km/h
Kühlmittel 88 °C
Motorlast 34 %
MAP 98 kPa
Spannung 13.8 V
● BLE verbunden LoRa TX: SF7 868MHz TX#0 RSSI: –
Entstehungsgeschichte

Warum dieses Projekt entstand

„Nur offene Quellen bringen uns wirklich weiter."

Angefangen hat alles mit unklarem Verhalten eines eigenen Autos — nichts Dramatisches, aber genug, um der Ursache auf den Grund zu gehen. Ich wollte einfach mal reinschauen, was das Ding so treibt: OBD-II-Daten auslesen, Kühlmitteltemperatur, Drehzahl, Motorlast — und natürlich Fehlermeldungen/Warnleuchten zurücksetzen. Bluetooth-OBD-Dongles gibt's ja schon für weniger als 10 Euro an jeder virtuellen Ecke — Hardware also kein Thema.

Die Software war das Problem. Was es so gibt (und es gibt sehr viel), konnte mich nicht wirklich überzeugen. Werbe-Banner, die zur Unzeit ausploppen und Apps, die seltsame Berechtigungen wollen — Kamera, Kontakte, Standort — als ob sie ein Fahrzeugdaten-Tool mit einer Stalker-App kreuzen wollten. Und fast immer: ohne Smartphone läuft gar nichts. AndrOBD ist zwar Open Source, aber momentan nicht grade aktuell im SpielGeschäft. Also: mal schauen, was denn da eigentlich so zwischen OBD-Dongle, Auto und Smartphone abläuft …

Die Idee dahinter war: Smartphone als Option - nicht als Pflicht — aber trotzdem alle wichtigen Werte griffbereit während der Fahrt. Drehzahl, Kühlmitteltemperatur und Co. einfach direkt auf einem kleinen Display im Auto. Und das alles so offen gebaut, dass man später noch beliebig dran rumschrauben kann. Vor allem aber: Drahtlos - keine Kabel zu OBD oder Zigarettenanzünder, die dann immer und überall im Weg hängen.

Das Ergebnis: Eine OBD-Bridge auf einem Mikrocontroller mit OLED-Display. Sie hängt sich ins Heimnetz oder bietet selbst einen Access-Point an, sucht eigenständig nach OBD-Dongles in Reichweite, verbindet sich automatisch und liest die Fahrzeugdaten aus. Per TCP kann sich dann jedes Gerät im Netz zuschalten — Terminal, Python-Dashboard, Browser (ja, Browser geht auch) — und wer es mag, auch ein Smartphone. Oder was auch immer.

Die nächste Erweiterung war dann ein Daten-Logging und auch eine LoRa-Übertragung (Long-Range, in der Theorie über mehrere Kilometer) der Daten. Ein zweiter Mikrocontroller mit OLED-Display empfängt die Daten und zeigt sie auf seinem eigenen Display an, völlig unabhängig vom WLAN. Reichweite: (wie gesagt: theoretisch und bislang in der Praxis ungetestet) mehrere Kilometer. Probefahrten also live und aus der Ferne beobachten.

Jedes Modul ist per Telnet übers WLAN oder seriell per USB erreichbar, mit einem lokalen Menü zum Konfigurieren und direkten Steuern. Kein Cloud-Zwang, keine App, kein Abo, keine Payback-Karten, keine Rabattgutscheine …

Aber um mal schnell die Erwartungen zu dämpfen: Das hier ist ein reines Hobbyprojekt — gebaut aus Neugier. Kein Startup, kein Produkt, keine Roadmap. Aber ich freue mich aufrichtig über jedes Feedback, jeden gefundenen Bug und jeden Verbesserungsvorschlag. Mailadresse gibt's im Impressum. (Schließlich sind wir in Deutschland, und da muss alles seine Ordnung haben.)

Open Source ist es deshalb, weil ich wirklich glaube: Nur offene Quellen bringen uns wirklich weiter. Wer einen Fehler findet, einen neuen PID braucht oder ein anderes Display anschließen will — der Code liegt offen.

Munter bleiben ;-)

Der Friese


Systemaufbau

Wie alles zusammenhängt

Vom OBD-Port bis zur optionalen Fernübertragung per LoRa — alle Verbindungen laufen über offene Protokolle auf Standard-Hardware. Der Simulator ermöglicht Tests ohne laufendes Fahrzeug.

Fahrzeug
OBD-II Port
BLE-OBD-Dongle
BLE / NimBLE
Bridge · MOD-01
obd_bridge
Heltec LoRa V3 · ESP32-S3
TCP · Port 1234
PC-Client · MOD-03
Python GUI
obd_gui2.py · tkinter
LoRa 868 MHz SF7
Receiver · MOD-02
LoRa-Empfänger
Heltec LoRa V3 · ESP32-S3
Simulator · MOD-04
obd_simulator
ESP32 WROOM · MCP2515 · TJA1050
CAN 500k · OBD-II
Test-Dongle
BLE-OBD-Dongle
ohne Fahrzeug

ℼ gestrichelt = optionaler Test-Pfad (Simulator ersetzt Fahrzeug)

Funktionsübersicht

Was das System leistet

Direkte BLE-Verbindung zum Dongle, simultane Ausgabe auf OLED, TCP und LoRa — ohne Smartphone-Zwang und ohne proprietäre Abhängigkeiten.

01 · BLE

Auto-Scan & Connect

Der µC sucht selbständig nach BLE-OBD-Dongles und verbindet sich automatisch. Unterstützt UUIDs 0x18F0, 0xFFE0, 0xFFF0, 0xAE30 und 0xAE3A. Bei Verbindungsverlust wird automatisch neu gescannt.

NimBLE 1.4.x · 5 Profiles
02 · DISPLAY

OLED Multi-Page + Helligkeit

5 konfigurierbare Display-Seiten. Button für kurzen/langen Druck zum Blättern und Fixieren. Helligkeit per dim 0..255 regelbar — dim 0 schaltet das Display komplett aus (SSD1306 Sleep).

SSD1306 · 128×64 · I²C · dim 0..255
03 · WLAN

TCP-Bridge · AP & STA

Verbindet sich mit dem Heimnetz (STA) oder öffnet einen eigenen Access-Point (AP, 192.168.4.1). TCP-Port 1234. Konfiguration über eine gemeinsame wifi_config.h — ein Symlink für alle drei Module.

TCP 1234 · HTTP 80 · AP-Fallback
04 · LORA

Extended-only Pakete (TLV)

Nur Extended-Paket (0x03, TLV): alle aktiven PIDs mit Scaling. Intervall wird automatisch aus echter Airtime berechnet (Semtech-Formel, 1% Duty Cycle DE/EU). Config-Paket (0x02): SF/Region/Power-Sync.

868 MHz · SF7 · SX1262 · DC-konform
05 · PID-REGISTRY

43 definierte PIDs

Gemeinsame pid_registry.h/.cpp für Bridge und Receiver — verhindert Sync-Fehler. PID-Tabelle mit Prioritäten (HIGH/MED/LOW), Gruppen und Capability-Bits. Blind-Scan automatisch.

43 PIDs · 6 Gruppen · TLV
06 · PYTHON-GUI

obd_gui2 Dashboard

Tkinter-Dashboard mit 4 Styles (F1, Sci-Fi, Aviation, Luxury). Verbindet sich direkt mit Bridge (--bridge) oder Receiver. Polling läuft auf der Bridge unabhängig von TCP-Verbindungen durch.

4 Styles · --bridge · TCP · CSV-Log
07 · WATCHDOG

Hardware-Watchdog

ESP32 Task-Watchdog mit 60s Timeout in der Bridge. Loop-Reset verhindert Einfrieren. Wird bei Button-Wartezeiten und BLE-Scan-Wartezeiten explizit zurückgesetzt.

esp_task_wdt · 60s
08 · DEMO-MODUS

Demo ohne Fahrzeug

Vollständig simulierte OBD-Werte für Test und Entwicklung ohne Fahrzeug. OLED, TCP-Live-Stream und LoRa laufen durch. Die Motor-PIDs werden realistisch simuliert.

demo · live on · LoRa TX
09 · TELNET-CLI

Einheitliches CLI

Identisches Textmenü über TCP (Port 1234) oder seriell (115200 Bd). Telnet-kompatibel (IAC-Filter). Vollständige Befehlsreferenz via help:

BLE: scan · disco · info
PID: pid list · pid status · pid scan · pid enable/disable <grp/id/all> · pid blind on/off · pid interval · pid profile fast/full/custom
DTC: dtc · cleardtc
Poll: poll <ms> · poll status
Live: live on/off
Display: next · prev · page N · pagetime N · pagelay R S · dim N · beep on/off/ack
LoRa: lora status · lora sf7..12 · lora de/int · lora pw<N>
CTRL: ctrl beep on/off/ack/pulse D N · ctrl gpio PIN [VAL] · ctrl ping
GPIO: gpio PIN · gpio PIN 0/1
System: demo · debug · version · reboot

Port 1234 · 115200 Bd · help · pid profile · live · ctrl · pagelay
10 · SIMULATOR

OBD2-Simulator

ESP32 WROOM-32 + MCP2515 (CAN-Controller) + TJA1050 (CAN-Transceiver) simulieren ein Fahrzeug-ECU via CAN-Bus. Sendet ab Boot automatisch BSC/EXT-Live-Pakete (live off zum Abschalten). Web-Interface zum manuellen Setzen aller Werte.

MCP2515 · TJA1050 · CAN 500k · Mode 01–09 · HTTP · live
11 · FLASH-TOOLING

obd_identify + obd_flash

obd_identify.sh erkennt automatisch welches Modul an welchem USB-Port hängt und gibt einen fertigen Flash-Befehl aus. obd_flash.sh kompiliert auf PC1 und flasht auf PC2 via SSH — mit Build-Zeitstempel im Binary.

obd_identify.sh · --port bridge=/dev/ttyUSB2
12 · BUILD-TIMESTAMP

Version im Binary

Jedes Binary enthält Build-Zeit und Quell-Stand als Compiler-Defines. Abrufbar via version oder im status-Output — so ist immer klar, welcher Code-Stand geflasht ist.

BUILD_TIME · SKETCH_MTIME · version
13 · BEEPER

Piezo-Beeper an Bridge

Statischer Piezo-Beeper direkt an GPIO 48 des Heltec LoRa V3 (3,3V ausreichend). Per CLI steuerbar: beep on/off (Dauerton), beep ack (Doppelpiep). Zustand im status-Output sichtbar.

GPIO 48 · beep on/off · beep ack · TCP · Serial
14 · LORA-RÜCKKANAL

Befehle Receiver → Bridge

Der Receiver kann Befehle per LoRa an die Bridge senden. Befehl wird in eine Queue geschrieben und unmittelbar nach dem nächsten empfangenen Paket gesendet — die Bridge ist dann garantiert im RX-Fenster. Pakettyp 0x04 (CMD), 4 Byte mit XOR-CRC.

0x04 · CMD-Queue · beep on/off · XOR-CRC
nc 192.168.4.1 1234 — obdBT Bridge v3.1
========================================= obdBT Bridge v3.1 bereit ----------------------------------------- WiFi : STA 'Heimnetz' Telnet: nc 192.168.1.42 1234 HTTP : http://192.168.1.42/ Befehle: help | status | scan | demo =========================================   > live on [LIVE] AN BSC RPM:2847 SPD:92 T:91 Ld:38.4 MAP:102 V:13.82 TX#1247 EXT Ansaugluft:34 TPS:22.35 Gaspedal:28.62 Zuendwinkel:12.0 Lambda:1.000 Oeltemp:82 BSC RPM:2891 SPD:93 T:91 Ld:39.2 MAP:103 V:13.80 TX#1248   >

Screenshots & Hardware

Hardware & Software

Heltec WiFi LoRa 32 (V3) im Einsatz — und das Python-Dashboard obd_gui2 mit F1-Style. Alle Screenshots vom 28. März 2026, Live-Betrieb.

obd_gui2 Python Dashboard F1-Style Live
MOD-03 · obd_gui2.py — F1-Style Live Python · tkinter · TCP · 4 Gauges · Bars
obd_bridge Serial-Monitor Terminal
MOD-01 · obd_bridge — Serial-Monitor BLE · OBD-Polling · LoRa TX · TCP
obd_lora_receiver Serial-Monitor Terminal
MOD-02 · obd_lora_receiver — Serial-Monitor LoRa RX · Extended-Decode · TCP
obd_simulator Serial-Monitor Terminal
MOD-04 · obd_simulator — Serial-Monitor CAN · MCP2515 · OBD-Response · Live-Mode
ESP32 Heltec LoRa V3 Hardware-Aufbau
Hardware · Heltec WiFi LoRa 32 (V3) ESP32 · SX1262 · SSD1306 · 868 MHz
obd_gui2 frühe Version
MOD-03 · obd_gui2.py — frühe Version (März 2026) Python · tkinter · F1-Style
Testaufbau ohne Fahrzeug

OBD-Simulator-Einheit & 3D-Stecker

Vollständiger Testaufbau mit Simulator (MOD-04), Vgate iCar Pro Dongle und 3D-gedrucktem OBD-II-Stecker — kein Fahrzeug nötig. Bridge und Receiver zeigen Live-Daten auf dem OLED.

Fliegender Aufbau mit Multimeter-Messung
Fliegender Aufbau · CAN-Bus-Diagnose Multimeter · CAN-H/L Spannungsmessung
ESP32 + MCP2515 + Dongle Testaufbau
MOD-04 · ESP32 WROOM + MCP2515 + iCar Pro Fliegender Aufbau · CAN 500 kbit/s
Simulatoreinheit mit eingestecktem Dongle
Simulatoreinheit · Dongle eingesteckt Vgate iCar Pro · 3D-gedruckter OBD-Stecker
3D-gedruckter OBD-II-Stecker mit Vgate Dongle
3D-Druck · OBD-II-Buchse + Vgate iCar Pro Design: TA1GI · Thingiverse · CC BY-SA
3D-gedruckter OBD-Stecker angelötete Kabel
3D-Druck · OBD-Stecker Detail Angelötete Kabel · Pin 4, 6, 14, 16
3D-gedruckter OBD-Stecker Rückseite Messpunkte
3D-Druck · OBD-Stecker Rückseite Messpunkte · Zugentlastung · Trägerplatte
Aktuelle Hardware-Fotos

Die echte Hardware

Erste Fotos der aktuellen Hardware — Gehäuse aus dem 3D-Drucker, noch im Prototyp-Stadium. Bessere Fotos folgen demnächst.

Bridge MOD-01 im schwarzen Gehäuse, OLED zeigt Live-Daten
MOD-01 · Bridge — Gehäuse, OLED Live RPM 2990 · 80 km/h · 75°C
Bridge MOD-01 OLED Nahaufnahme
MOD-01 · Bridge — OLED Nahaufnahme Schwarzes Strukturlack-Gehäuse · Heltec LoRa V3
Receiver MOD-02 im grauen Gehäuse mit OLED
MOD-02 · LoRa-Receiver — OLED Live RPM 1405 · 35 km/h · rbag.eu/OBD
Receiver MOD-02 Nahaufnahme OLED
MOD-02 · LoRa-Receiver — Nahaufnahme Graues Gehäuse · SSD1306 OLED · rbag.eu/OBD
Vgate iCar Pro BLE-OBD-Dongle
BLE-OBD-Dongle · Vgate iCar Pro BLE · ELM327 · OBD-II · UUID 0xAE30
MOD-04 OBD-Simulator: ESP32 WROOM + MCP2515
MOD-04 · OBD-Simulator — Aufbau ESP32 WROOM · MCP2515 (HW-184) · CAN 500k

⚠ Prototyp-Stadium — bessere Fotos folgen demnächst


PID-Registry

43 definierte OBD-PIDs

Gemeinsame Tabelle für Bridge und Receiver in pid_registry.h/.cpp. Einmalig im Flash — kein Sync-Fehler zwischen den µCs. TLV-Scaling: ×1 (int), ×10 (1 Dezimalstelle), ×100 (2 Dezimalstellen).

IDX OBD-ID Name Einheit Scale Gruppe
00010CRPM1/min×1Motor
01010DSpeedkm/h×1Motor
020105Kuehlmittel°C×10Motor
03010FAnsaugluft°C×10Motor
04010BMAPkPa×10Motor
050104Motorlast%×100Motor
060111TPS%×100Motor
08012FTankfuellstand%×100Kraftstoff
09015EVerbrauchL/h×100Kraftstoff
100110MAFg/s×100Kraftstoff
110133BarokPa×10Kraftstoff
120143AbsTPS%×100Kraftstoff
130145RelTPS%×100Kraftstoff
140149Gaspedal%×100Kraftstoff
15014CSchubventil%×100Kraftstoff
180114O2_B1S1_VV×100Abgas
190115O2_B1S2_VV×100Abgas
200116O2_B1S3_VV×100Abgas
210117O2_B1S4_VV×100Abgas
220124O2_B1S1_WBλ×100Abgas
230125O2_B1S2_WBλ×100Abgas
240144Lambdaλ×100Abgas
250146Umgebungsluft°C×10Abgas
26014BKruemmerdruckkPa×10Abgas
27010EZuendwinkelKW×10Zündung
280142ECU_SpannungV×100Zündung
29015COeltemp°C×10Zündung
30015DEinspritzdruckkPa×100Zündung
310167Kuehlmittel2°C×10Zündung
330101MIL_Status×1Fehler
340121Dist_MIL_ankm×1Fehler
350130Warmlaufzyklen×1Fehler
360131Dist_Resetkm×1Fehler
37014DZeit_MIL_anmin×1Fehler
38014EZeit_Resetmin×1Fehler
390151Kraftstofftyp×1Info
400902VINInfo
410904KalibIDInfo
42090AECU_NameInfo
Hardware-Module

Die Komponenten des Systems

Jedes Modul ist eigenständig betreibbar, über TCP (Port 1234) oder seriell konfigurierbar und auf handelsüblicher Hardware aufgebaut.

MOD-01 · obd_bridge

BLE-Bridge µC

Verbindet sich per NimBLE mit dem OBD-BT-Dongle, liest PIDs im Prioritätspoller aus, zeigt Werte auf dem OLED an, stellt alles per TCP bereit und sendet Extended-Pakete per LoRa.

  • Heltec WiFi LoRa 32 (V3), SX1262
  • NimBLE 1.4.x (BLE-Client, 5 Profile)
  • WiFi STA → AP-Fallback (192.168.4.1)
  • TCP Port 1234 · HTTP Port 80
  • LoRa 868 MHz, SF7, BW125, 14 dBm
  • 43 PIDs, 6 Gruppen, Capability-Scan
  • Hardware-Watchdog 60s
  • Demo-Modus: alle PIDs simuliert
  • DTC lesen (Mode 03) + loeschen (Mode 04)
  • Piezo-Beeper GPIO 48 — beep on/off/ack
  • LoRa-Rückkanal: CMD-Pakete (0x04) vom Receiver empfangen
MOD-02 · obd_lora_receiver

LoRa-Empfänger µC

Empfängt Extended-Pakete per LoRa, dekodiert TLV-Payload, stellt alle Werte auf dem OLED dar und gibt sie per TCP weiter. Verbindet sich als STA zum Bridge-AP falls kein Heimnetz.

  • Heltec WiFi LoRa 32 (V3), SX1262
  • 5 OLED-Pages (Page 4: Extended-PIDs scrollend)
  • Sequenznummer-Tracking, Verlust-Zaehler
  • Config-Paket-Empfang (SF/Region/Power)
  • pkt-Modus: auto / basic-only / ext-only
  • WiFi STA Heimnetz → Bridge-AP-Fallback
  • LoRa-Rückkanal: beep on/off/ack → CMD-Queue → Bridge
  • TCP Port 1234 · HTTP Port 80
MOD-03 · obd_gui2.py

Python Dashboard

Tkinter-GUI mit animierten 3D-Rundinstrumenten und Balkenanzeigen. Verbindet sich direkt mit der Bridge (--bridge) oder dem Receiver. Vier wählbare Styles per Tastenkürzel.

  • 4 Styles: F1, Sci-Fi, Aviation, Luxury
  • 6 Gauges + 3 Bars (konfigurierbar)
  • --bridge: RSSI-Balken ausgeblendet
  • live on — kein Toggle-Problem bei Multi-Client
  • Python 3, nur tkinter + optional pyserial
MOD-04 · obd_simulator

OBD2-Simulator µC

Simuliert ein Fahrzeug-ECU via CAN-Bus. Antwortet auf OBD-II-Anfragen des Dongles — für Tests ohne laufendes Fahrzeug. Web-Interface zum manuellen Setzen aller Werte.

  • ESP32 WROOM-32 + MCP2515 (TJA1050)
  • ISO 15765-4 CAN, 500 kBit/s
  • Mode 01 (19 PIDs), 03 DTC, 04 Clear, 09 VIN
  • Simulationsmodus: realistische Fahrdynamik
  • Web-Interface: alle Werte live setzbar
  • TCP Port 1234 · verbose on/off
  • WiFi STA → eigener AP (192.168.4.2)
MOD-05 · Gemeinsame Konfiguration

Shared Headers

Bridge, Receiver und Simulator teilen sich zentrale Konfigurationsdateien — ein einziger Änderungspunkt für WLAN-Zugangsdaten und PID-Definitionen.

  • pid_registry.h/.cpp: 43 PIDs, Enum, Scaling
  • wifi_config.h: SSID/Pass, AP-Credentials
  • http_server.h: HTTP-Server fuer Bridge+Receiver
  • DEVICE_BRIDGE / DEVICE_RECEIVER / DEVICE_SIMULATOR
  • Symlinks: Receiver+Simulator zeigen auf Bridge-Verz.
  • Partition Scheme: Huge APP (3 MB Flash)

Quellcode

Open Source — alles zum Herunterladen

Vollständiger Quellcode für alle Module. GPL v3 — offen bleiben, auch in Derivaten.
© 2026 Ralf Burger · ralf@RalfBurger.com

.tgz

Komplettpaket

Alle Module, Scripts und Website in einem Archiv. Enthält Bridge, Receiver, Simulator, GUI, obd_flash.sh, obd_identify.sh und wifi_config.h als gemeinsamen Symlink. Symlinks bleiben erhalten.

↓ OBD_V2.1.tgz   alle Releases ↗
.ino

obd_bridge

Bridge-Firmware: NimBLE-BLE-Client, OBD-Poller, OLED mit dim-Steuerung, WLAN-AP/STA, TCP+HTTP-Server, LoRa Extended TX, Watchdog, Demo-Modus. Heltec LoRa V3.

↓ obd_bridge.ino
.ino

obd_lora_receiver

Receiver-Firmware: LoRa-RX, Extended Decoder, TLV, OLED-Multi-Page mit dim-Steuerung, TCP+HTTP-Server, Config-Paket-Empfang. Heltec LoRa V3.

↓ obd_lora_receiver.ino
.ino

obd_simulator

OBD2-Simulator: MCP2515 CAN-Bus, antwortet auf Mode 01/03/04/09, Live-BSC/EXT-Pakete ab Boot, Web-Interface, TCP+Serial-CLI. ESP32 WROOM.

↓ obd_simulator.ino
.py

obd_gui2.py

Python-Dashboard: Tkinter, 4 Styles, Gauges, Bars, TCP-Client, --bridge-Modus, live on/off, CSV-Logging mit Sentinel-Filterung, animierte 3D-Instrumente.

↓ obd_gui2.py
.sh

Flash & Identify Scripts

obd_identify.sh: Erkennt Module an USB-Ports, gibt fertigen Flash-Befehl aus. obd_flash.sh: Kompiliert lokal, flasht via SSH mit Build-Zeitstempel, Port-Override per --port bridge=/dev/ttyUSBx.

↓ obd_identify.sh   ↓ obd_flash.sh
.h

Shared Headers

Gemeinsame Konfigurationsdateien: pid_registry.h/.cpp (43 PIDs, Enum, Scaling), wifi_config.h (SSID, AP, Port — ein Symlink für alle Module) und http_server.h.

↓ pid_registry.h   ↓ pid_registry.cpp   ↓ wifi_config.h   ↓ http_server.h
.doc

Dokumentation

Technische Volldokumentation: alle Module, CLI-Referenz, PID-Tabelle, LoRa-Paketformat, Deployment, Flash-Workflow. Als HTML (im Browser lesbar) und als Word-Dokument.

↗ doku.html   ↓ OBD_Doku.docx

Rechtliches

Impressum

Systemintegration Ralf Burger
Ralf Burger
Roenskenstr. 37
46562 Voerde
Deutschland

Kontakt
Telefon: 0700 / 12345600
E-Mail: ralf@RalfBurger.com

Umsatzsteuer-Identifikationsnummer
gem. § 27a Umsatzsteuergesetz:
DE 458604144

Berufsbezeichnung und berufsrechtliche Regelungen
Autor und Unternehmer im Ruhestand ;-) Freiberufliche Hard- und Softwareentwicklung und IT-Beratung

Inhalt dieser Website
Diese Website stellt ein privates Open-Source-Projekt vor. Alle Quelltexte stehen unter der GNU General Public License v3 (GPL v3) und koennen frei verwendet, veraendert und weitergegeben werden — unter der Bedingung, dass abgeleitete Werke ebenfalls unter GPL v3 veroeffentlicht werden.

Haftungsausschluss
Die bereitgestellten Informationen und Quelltexte wurden mit grosster Sorgfalt erstellt. Eine Haftung fuer die Richtigkeit, Vollstaendigkeit und Aktualitaet kann jedoch nicht uebernommen werden. Die Nutzung erfolgt auf eigene Gefahr.

Markenhinweis
Alle genannten Produktnamen, Marken und eingetragenen Warenzeichen sind Eigentum ihrer jeweiligen Inhaber. Die Nennung dient ausschliesslich der technischen Beschreibung.

Streitschlichtung
Die Europaeische Kommission stellt eine Plattform zur Online-Streitbeilegung (OS) bereit: https://ec.europa.eu/consumers/odr/.
Ich bin nicht bereit oder verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen. Ich hab gar keinen Bock mich zu streiten.....