Die Open-Source-Plattform openHAB öffnet sich in Version 5.2 für LLMs und Agentic AI. Die Plattform zur Smart-Home-Steuerung bringt eine Anbindung an Sprachmodelle und führt den openHAB MCP Server ein.

LLM-Chat statt Regelwerk für die Steuerung

Das UI von openHAB bringt ein neues Chat-Interface, das sich direkt an die einzelnen Geräte der Plattform anbinden lässt. Für Aufgaben zur Gerätesteuerung zeigt das Chat-Interface das zugehörige Widget an.

openHAB bietet Tools, um die einzelnen Geräte an das LLM anzubinden, um den Status abzurufen oder Steuerbefehle zu senden.

Die User entscheiden, welche Geräte für das Chat-Interface ansprechbar sind. Der Parameter permission in den voiceSystem-Metadaten der einzelnen Items (die Smart-Home-Einheiten in openHAB) kennt drei Einstellungen: NO_ACCESS, READ_ONLY und READ_WRITE.

Gedächtnis und Tools für das LLM

Die Plattform speichert den Verlauf des Chats und kann ihn dem LLM bei weiteren Aufrufen mitgeben. Wie weit sich openHAB den Chatverlauf merkt und ihn weitergibt, lässt sich in den Einstellungen festlegen. Der System-Prompt für das LLM ist ebenfalls anpassbar.

Ein Tooling-Framework öffnet den LLMs den Zugang zu den Geräten und weiteren Informationen. Drei Tools bringt Version 5.2 von Haus aus mit: get-date-time gibt die Zeit und das Datum bezogen auf die aktuelle Zeitzone zurück, item-get-state ruft den Status eines Items ab und item-send-command schickt einen Befehl an ein Item.

openHAB ist zwar an kein bestimmtes LLM gebunden, bietet zum Start allerdings zunächst nur eine Anbindung an Google Gemini. Bindings für OpenAI und dazu kompatible Modelle sind in Kürze geplant.

Agentic AI mit dem openHAB MCP Server

Einen Schritt weiter als die LLM-Anbindung geht der openHAB MCP Server, der die Plattform für Agentic AI öffnet. Die KI-Agenten können die Geräte steuern und verwalten.

Außerdem lassen sich die KI-Agenten nutzen, um eigene Regeln für openHAB zu erstellen. Dabei hat man die Wahl zwischen Regeln für wiederkehrende Aufgaben und einmaligen Regeln. Letztere löscht der Agent nach der Ausführung selbsttätig.

Die Agenten können wahlweise direkt über das Netzwerk, über die openHAB-Cloud oder eine Node.js-Bridge mit openHAB kommunizieren. Damit die Agenten mit der Plattform interagieren können, benötigen sie ein openHAB-API-Token. Weitere Informationen zur Anbindung und Authentifizierung finden sich in der Dokumentation zum openHAB MCP Server.

Funktionen jenseits von KI

Neben der LLM- und Agentic-AI-Anbindung bringt openHAB 5.2 zahlreiche weitere Ergänzungen. Unter anderem lassen sich Komponenten für das UI neuerdings in YAML erstellen. Außerdem hat das openHAB-Team die DSL (Domain Specific Language) zum Erstellen von Regeln erweitert.

Weitere Neuerungen wie die dauerhaft angezeigte Log-Konsole und die erweiterten Charts lassen sich dem openHAB-Blog entnehmen. Die vollständige Liste der Neuerungen findet sich in den Release Notes.

(rme)

Das Node.js-Team diskutiert derzeit darüber, den Workflow für die Flut an eingereichten, LLM-generierten Sicherheitsmeldungen zu ändern. Ideen sind, die Meldungen öffentlich zu bearbeiten und mit künstlicher Intelligenz vorzusortieren.

Das Team hat das Problem jetzt auf die Agenda des nächsten Treffens der Security Working Group am 7. Juli gesetzt. Der Initiator Rafael Gonzaga schreibt, dass alle bisherigen Maßnahmen nicht geholfen haben: „Wir sind nach wie vor überlastet.“

Daher schlägt er vor, die eingereichten Meldungen zu veröffentlichen und als Pull Requests (PR) abzuarbeiten. Bei den Einreichungen handelt es sich oft nur um Bugs, die auch gefixt gehören, aber weniger um wirkliche sicherheitsrelevante Lücken. Außerdem kommen so viele gleichartige Meldungen an, die quasi jeder mit LLM erzeugen kann: „Diese Funde sind praktisch eh schon öffentlich.“ Als PR kann sich die Community darum kümmern und das Kernteam ist entlastet.

Eine Vorsortierung durch KI könnte nur die wirklich ernsthaften Lücken erkennen und nicht öffentlich an das Sicherheitsteam zur Bearbeitung weiterleiten.

Gegenstimmen geben zu bedenken, dass der Vorschlag die Masse an Sicherheitsreports durch eine Masse an PRs ersetzt, die auch vom Kernteam geprüft werden müssen. Außerdem könnten die veröffentlichten Lücken Hacker anziehen, „als kostenlose Quelle für Ideen für automatisierte Attacken.“ Daher schlagen andere Maintainer vor, nicht die komplette Öffentlichkeit einzubeziehen, aber den Kreis auf alle Mitarbeitenden (collaborators) zu erweitern.

Kampf gegen den AI-Slop

Wie viele andere Projekte kämpft Node.js mit AI Slop und hat im April bereits das Bug-Bounty-Programm zur Belohnung von Warnungen gestrichen. Auch zu solchen Maßnahmen waren andere Projekte bereits gezwungen. Das hat laut Gonzaga aber keine Erleichterung gebracht, da es den Einreichenden eher um den Ruhm als Autor auf einer offiziellen CVE-Warnmeldung zu erscheinen geht, als um Geld.

Auch andere Maßnahmen führten nicht zum Erfolg: höhere Hürden bei der Reporting-Plattform HackerOne, engere Relevanzkriterien und automatisiertes Schließen von Reports minderer Qualität. Letzteres hat sogar dazu geführt, dass mehr Meldungen bei der Mutter OpenJS landeten. „Bald wird auch dieses Team überlastet sein“, schließt Gonzaga.

(who)

Die freie Embedded-Datenbank LMDB (Lightning Memory-Mapped Database) hat Version 1.0 erreicht. Mit dem ersten Major-Release dokumentieren die Entwickler die API und das Verhalten der Bibliothek neu und stellen eine aktualisierte Dokumentation bereit. Für bestehende Anwendungen gibt es einen eigenen Migrationsleitfaden von der 0.9-Serie.

LMDB ist eine in Anwendungen eingebettete Key/Value-Datenbankbibliothek für lokale Datenhaltung. Sie richtet sich an Entwickler, die eine transaktionssichere Datenbank ohne separaten Serverprozess benötigen, etwa für Verzeichnisdienste, Caches oder Metadaten. Anders als klassische Datenbanksysteme lädt LMDB Daten nicht in einen eigenen Puffer-Cache, sondern bildet die komplette Datenbank per Memory Mapping in den virtuellen Adressraum des Prozesses ab. Lesezugriffe erfolgen dadurch direkt auf die gemappten Speicherbereiche, ohne zusätzliche Speicherallokationen oder Kopieroperationen.

Memory Mapping statt Datenbank-Cache

Das Grundprinzip von LMDB bleibt auch mit Version 1.0 unverändert. Die Bibliothek verwendet einen B-Baum als Datenstruktur und überlässt das Caching vollständig dem Betriebssystem. Da Datensätze direkt aus dem Speicherabbild gelesen werden, entfallen Zwischenschritte wie malloc() oder memcpy() beim Auslesen von Daten. Das reduziert den Verwaltungsaufwand und kann insbesondere bei leseintensiven Workloads die Leistung steigern. Grundlage dafür ist die Memory-Mapping-Funktion des Betriebssystems, bei der Dateiinhalte transparent in den virtuellen Speicher eingeblendet werden.

Auch das Transaktionsmodell bleibt erhalten. LMDB bietet ACID-Eigenschaften und setzt auf Multi-Version Concurrency Control (MVCC). Neue Daten werden per Copy-on-Write geschrieben, sodass bereits vorhandene Seiten niemals überschrieben werden. Ein Leser sieht dadurch stets einen konsistenten Datenbestand, während Schreibvorgänge parallel vorbereitet werden können. Ein typisches Beispiel ist ein Dienst, der kontinuierlich Konfigurationsdaten ausliest, während ein Verwaltungswerkzeug Änderungen schreibt: Leser arbeiten ohne Sperren weiter und werden durch den Schreibvorgang nicht blockiert.

Ein Schreiber, viele Leser

Das Nebenläufigkeitsmodell von LMDB unterscheidet sich von vielen anderen Datenbanken. Beliebig viele Prozesse oder Threads können gleichzeitig lesen, Schreibtransaktionen werden dagegen vollständig serialisiert. Zu jedem Zeitpunkt darf nur eine Schreibtransaktion aktiv sein. Dadurch schließt das System Deadlocks zwischen konkurrierenden Schreibern aus. Leser blockieren Schreiber nicht, ebenso wenig müssen Leser auf laufende Schreibvorgänge warten.

Die Entwickler verzichten außerdem bewusst auf ein Write-Ahead-Log oder ein Append-only-Protokoll. Statt regelmäßig Logdateien zusammenzuführen oder Datenbanken zu komprimieren, verwaltet LMDB freie Seiten innerhalb der Datenbank selbst und verwendet sie für spätere Schreibvorgänge erneut. Dadurch wächst die Datenbank im Normalbetrieb nicht unbegrenzt an, wie es bei logbasierten Verfahren ohne Wartung passieren kann.

Hinweise für den Betrieb

Die Release-Notes auf GitHub sowie die Dokumentation weisen auf einige Einschränkungen hin: Lange laufende Lesetransaktionen können verhindern, dass bereits freigegebene Seiten wiederverwendet werden. Dadurch kann die Datenbankdatei unnötig anwachsen. Entwickler sollten deshalb lang andauernde Transaktionen vermeiden und abgebrochene Prozesse regelmäßig auf verwaiste Reader-Einträge prüfen. Dafür stehen unter anderem die Funktion mdb_reader_check sowie das Werkzeug mdb_stat zur Verfügung.

Nicht empfohlen wird außerdem der Einsatz auf Netzwerkdateisystemen. Da LMDB auf Memory Mapping sowie Dateisperren des Betriebssystems setzt, können dort Synchronisationsprobleme auftreten. Auch das gleichzeitige mehrfache Öffnen derselben Datenbank innerhalb eines Prozesses gilt laut Dokumentation als problematisch.

(fo)