> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-de/faq/changelog.md).

# Änderungsprotokoll

Kilo IoT Server Änderungsprotokoll — Scale-Log-Einträge für jede Version, mit Funktionszusammenfassungen, Screenshots und Doku-Links.

<details>

<summary>Scale Log. Veröffentlichung 3.9.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-c074814b54eac6ea2f4a0c6f4f1085466a44929d%2FKilo_Scale_Log_Release_3.9.0.jpg?alt=media" alt="Kilo IoT Server 3.9.0 release banner"><figcaption></figcaption></figure>

Kilo-Regeln automatisieren, wie eine Bereitstellung auf Gerätedaten reagiert. Ein **Auslöser** ist eine gespeicherte Bedingung, die eine Regel startet, und sie hat jetzt zwei unabhängige Steuerelemente: Sie kann ein Gerät oder mehrere ausgewählte Geräte auswerten und sofort reagieren oder warten, bis die Bedingung weiterhin wahr bleibt. Vor 3.9.0 erforderte das Anwenden einer Reaktion auf 50 Geräte 50 Regeln; jetzt können ein Auslöser und eine Regel sie abdecken, während die Bedingung und der Countdown jedes Geräts getrennt bleiben. Diese Veröffentlichung bringt außerdem alle Metriken auf eine durchsuchbare Seite, fügt Rechnungszahlungen und exakte Werte auf Balkendiagrammen hinzu, erweitert den KI-Assistenten und hilft verbundenen KI-Apps, Aktionen, die Daten lesen, von Aktionen zu unterscheiden, die sie verändern. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **Eine Regel für bis zu 500 Geräte** — Früher erforderte das Anwenden derselben Regel auf 50 Geräte 50 separate Regeln. Jetzt kann ein Auslöser diese Geräte auswählen, jedes einzeln auswerten und die gemeinsame Regel für jedes Gerät starten, das die Bedingung erfüllt.
* **Warten, bevor eine Regel ausgeführt wird** — Ein Auslöser kann verlangen, dass eine Bedingung 10 Sekunden bis 30 Tage lang wahr bleibt, bevor die Regel startet. Eine Regel für eine Gefriertür kann zum Beispiel eine Tür ignorieren, die zum Beladen kurz geöffnet wurde, aber reagieren, wenn die Tür 10 Minuten lang offen bleibt.
* **Alle Metriken auf einer Seite** — Eine Metrik ist eine Art von Messwert, z. B. Temperatur oder Akkustand. Metriken, die auf drei Tabs verteilt waren, sind jetzt in einer durchsuchbaren Liste unter **Geräte → Metriken**verfügbar, wo Sie sie auch hinzufügen und bearbeiten können.
* **Per Rechnung statt per Karte bezahlen** — Geben Sie Ihre Firmendaten und, falls erforderlich, Ihre Umsatzsteuer-Identifikationsnummer ein; wählen Sie dann Banküberweisung und erhalten Sie die Rechnungsinformationen per E-Mail. Die neue **Rechnungen** Seite zeigt, welche Rechnungen offen oder bezahlt sind, und bietet den PDF-Download an.
* **Werte auf Balkendiagrammen anzeigen** — **Wert auf Balken anzeigen** druckt jeden Wert auf seinen Balken. **Metriken darunter anzeigen** fügt die aktuellen Messwerte unter dem Diagramm hinzu.
* **MIOTY-Geräte mit dem KI-Assistenten hinzufügen** — Der Assistent kann jetzt eine bestehende MIOTY-Verbindung nutzen, um Ihnen bei der Auswahl eines Gerätemodells zu helfen, seine Kennungen einzugeben und das Gerät bei Bedarf mit einem kompatiblen Blueprint zu erstellen.
* **Verwenden Sie Ihr eigenes KI-Konto** — Verbinden Sie ein OpenAI-, Anthropic-, OpenRouter-, Ollama- oder kompatibles Konto, anstatt das in Ihrem Kilo-Plan enthaltene monatliche Nachrichtenkontingent zu verwenden. Ollama-Modellnamen mit Versionsangaben werden jetzt unterstützt.
* **Verbundene KI-Apps können Lese- und Schreibaktionen unterscheiden** — Aktionen für ChatGPT, Claude, Cursor und andere verbundene KI-Apps kennzeichnen jetzt, ob sie nur Daten lesen oder etwas ändern oder löschen können.
* **Verbesserungen bei Zuverlässigkeit und Benutzeroberfläche** — Gerätefotos werden korrekt gespeichert, der Audit Trail aktualisiert sich nach Berechtigungsänderungen, Widget-Farben funktionieren wieder, die Log-Aufbewahrung richtet sich nach Ihrem Plan, und der KI-Assistent meldet abgeschlossene Aktionen zuverlässiger.

***

**Eine Regel für viele Geräte**

Eine Regel ist ein Flussdiagramm, das Kilo vorgibt, wie es auf Gerätedaten reagieren soll. Sie kann Messwerte auswerten, einen Alarm auslösen, einen Wert berechnen oder einen Befehl an Geräte wie ein Ventil oder Relais senden. Ein Auslöser definiert die Bedingung, die die Regel startet.

Vor 3.9.0 konnte eine Regel nur von einem Gerät ausgelöst werden. Wenn dieselbe Bedingung und Reaktion für 50 Geräte galt, benötigten Sie 50 separate Regeln. Eine spätere Änderung der Bedingung bedeutete, jede Kopie zu bearbeiten.

Jetzt kann ein Auslöser bis zu **500 Geräte**auswählen, und eine Regel gilt für alle. Das Hinzufügen eines weiteren Geräts bedeutet, diesen Auslöser zu aktualisieren, statt eine weitere Regel zu erstellen. Die Auswahl gehört zum Auslöser; sie ist keine wiederverwendbare Gerätegruppe an anderer Stelle in Kilo.

Die meisten Mehrgeräte-Auslöser sind einfach: Jedes ausgewählte Gerät liefert denselben Messwert und wird unabhängig überwacht. Jedes überwachte Gerät hat seinen eigenen Auslösezustand und Countdown, sodass eine offen bleibende Tür keine andere Tür beeinflusst.

Ein ausgewähltes Gerät kann statt überwacht zu werden auch einen gemeinsamen Messwert liefern. Zum Beispiel können 50 Türen jeweils ihren eigenen `door_open` Messwert liefern, während ein Gebäudesteuergerät `heating_on` für jede Türprüfung liefert. Bevor Sie speichern, **Wie dieser Auslöser ausgeführt wird** zeigt eine Zeile für jedes überwachte Gerät und kennzeichnet einen gemeinsamen Messwert in der **Verwendet** Spalte.

Ein Alarm kann auch das Gerät identifizieren, das die Regel ausgelöst hat. Fügen Sie `vars.device_name` zur Motivationsnachricht des Alarms hinzu, damit die Benachrichtigung das betroffene Gerät nennt.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-0602bd68bb6152184acc6908acffb24f21d249ad%2Ftrigger-device-group.jpg?alt=media" alt="The device picker and the How this trigger will run table, one row per watched device"><figcaption></figcaption></figure>

[→ Ein Auslöser für mehrere Geräte](/kilo-docs-de/kilo-iot-server/rules-engine/triggers/multiple-devices.md)

***

**Eine Regel vor der Ausführung warten lassen**

Vor 3.9.0 wurde eine Regel sofort ausgeführt, sobald ein Geräte-Messwert den von Ihnen festgelegten Grenzwert überschritt. Eine sofortige Reaktion ist bei dringenden Situationen wie einem Wasserleck sinnvoll, aber ein kurzer Temperatursprung oder eine offene Tür erfordert nicht immer Maßnahmen.

Ein Auslöser kann jetzt verlangen, dass die Bedingung erfüllt bleibt, bevor die Regel startet. Wählen Sie **Nur wenn es anhält**, dann legen Sie eine Dauer in Sekunden, Minuten, Stunden oder Tagen fest. Neue Auslöser beginnen bei 10 Minuten; Sie können jede Dauer von 10 Sekunden bis 30 Tagen einstellen.

Zum Beispiel:

* Ignorieren Sie eine zum Beladen kurz geöffnete Gefriertür, aber führen Sie die Regel aus, wenn sie 20 Minuten lang offen bleibt.
* In der Garage einer Wohnanlage eine kurze Anwesenheit eines Bewohners ignorieren, aber einen Sicherheitsalarm auslösen, wenn die Bewegung während des nächtlichen Regelplans 10 Minuten lang anhält.
* Einen normalen einminütigen Pumpenzyklus ignorieren, aber reagieren, wenn die Pumpe zwei Stunden lang weiterläuft.
* Einen kurzen Temperaturanstieg ignorieren, aber einen Alarm auslösen, wenn ein Raum den ganzen Nachmittag über über 25 °C bleibt.

Zwei weitere Verhaltensweisen steuern, wie der Timer funktioniert:

* **Eine Lücke zwischen Geräteberichten setzt den Countdown nicht zurück.** Ein Gerät, das alle 15 Minuten meldet, bricht eine 20-minütige Wartezeit nicht einfach ab, weil zwischen den Berichten kein neuer Messwert eingegangen ist.
* **Das Zurücksetzen des Auslösers kann eine eigene Bedingung und Verzögerung haben.** Unter **Verhalten beim Zurücksetzen**legen Sie fest, wann der Auslöser in den Normalzustand zurückkehrt und wie lange diese Rücksetzbedingung anhalten muss. So wird verhindert, dass ein einzelner normaler Messwert eine Bedingung zu früh zurücksetzt.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-ebb50a42e55112e4a2f5f8a9cce0ee26a91e9d28%2Ftrigger-time-window.jpg?alt=media" alt="The Create trigger dialog with a temperature condition and Only if it lasts set to 10 minutes"><figcaption></figcaption></figure>

[→ Auslösezeitpunkt](/kilo-docs-de/kilo-iot-server/rules-engine/triggers/trigger-timing.md)

***

**Alle Metriken auf einer Seite**

Eine Metrik definiert eine Art von Geräte-Messwert, z. B. Temperatur, Luftfeuchtigkeit, Akkustand oder ob eine Tür offen ist. Die Definition gibt Kilo den Namen, die Einheit und den Datentyp der Metrik vor, damit Messwerte verschiedener Gerätehersteller konsistent in Dashboards und Regeln verwendet werden können.

Vor 3.9.0 waren Metrikdefinitionen auf drei Tabs verteilt. Sie werden jetzt in einer Liste unter **Geräte → Metriken**verwaltet. Auf dieser Seite können Sie:

* nach Namen suchen;
* nach Einheit, Typ oder Datentyp filtern;
* mehrere Filterwerte gleichzeitig auswählen;
* nach neuestem oder ältestem sortieren;
* eine Metrik im selben Dialog hinzufügen oder bearbeiten.

Metriken gehören zur gesamten Organisation. Das Bearbeiten einer Metrik ändert sie für jedes Gerät, das sie verwendet, daher warnt Kilo jetzt vor der weiterreichenden Auswirkung und bittet vor dem Speichern um Bestätigung.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-76acbd86f0743bda783dc3f24dabc533b34252e7%2Fdevice-metrics.jpg?alt=media" alt="The Devices Metrics catalog with search, unit, type and data type filters and a sort control"><figcaption></figcaption></figure>

[→ Metriken](/kilo-docs-de/kilo-iot-server/devices/metric-templates.md)

***

**Per Rechnung statt per Karte bezahlen**

Vor 3.9.0 konnten Kilo-Abonnements nur per Karte bezahlt werden. Organisationen, die eine Firmenrechnung und Banküberweisung benötigen, hatten keine alternative Zahlungsmethode.

Sie können jetzt unter Organisationseinstellungen Ihren rechtlichen Namen, Ihre eingetragene Adresse, Ihre Rechnungs-E-Mail und Ihre Umsatzsteuer-Identifikationsnummer eingeben und dann auswählen **Per Rechnung bezahlen (Banküberweisung)** bei der Auswahl eines Plans. EU-USt-Nummern werden über das VIES-Register geprüft, und das Formular zeigt an, ob die Verifizierung aussteht oder abgeschlossen ist.

Wenn Sie per Rechnung bezahlen:

* die Rechnungsinformationen und der gehostete Rechnungslink werden an Ihre Rechnungs-E-Mail gesendet;
* die Rechnung enthält eine Zahlungsseite mit Ihrer Organisation zugeordneten Bankdaten, damit die Zahlung automatisch zugeordnet werden kann;
* die **Rechnungen** Seite zeigt offene und bezahlte Rechnungen;
* Upgrades stellen die Differenz für den verbleibenden Zeitraum in Rechnung, während Gutschriften für Downgrades auf die nächste Rechnung angewendet werden;
* Ihre Bereitstellung läuft weiter, während eine Planänderung verarbeitet wird.

Kartenzahlungen funktionieren weiterhin wie bisher.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-269dd13fb761ae8c0eb952ade4ea6942e83fabb4%2Fbilling-details.jpg?alt=media" alt="The Billing details section of Organization settings, with legal name, billing email, company address and tax ID"><figcaption></figcaption></figure>

[→ Abrechnung und Rechnungen](/kilo-docs-de/kilo-iot-server/settings/billing-and-invoices.md)

***

**Werte auf Balkendiagrammen anzeigen**

Ein Diagramm-Widget zeigt Geräte-Messwerte auf einem Dashboard an. Vor 3.9.0 mussten Werte in einem Balkendiagramm aus der Skala des Diagramms geschätzt werden.

Aktivieren Sie **Wert auf Balken anzeigen** , um den Wert direkt auf jedem Balken anzuzeigen. Diese Option ist nur für Balkendiagramme verfügbar.

Aktivieren Sie **Metriken darunter anzeigen** to add a row beneath the chart with each metric and its current reading. This can make compact dashboard widgets easier to read.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-19138019fd8eb71be00e1b109e919e4ca43d06e8%2Fchart-widget.jpg?alt=media" alt="A Kilo Bar chart with exact values printed on the bars and the current metric shown below"><figcaption></figcaption></figure>

[→ Balkendiagramm](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/chart-widget/bar-chart.md)

***

**MIOTY-Geräte mit dem KI-Assistenten hinzufügen**

MIOTY ist ein Funkprotokoll für große Standorte und Umgebungen mit erheblicher Funkstörung. Um einen Endpunkt zu registrieren, benötigt Kilo eine bestehende MIOTY-Verbindung, die EUI des Endpunkts, den Network Session Key, die Short Address und das Gerätemodell. Einige Endpunkte verwenden außerdem einen Application Key. Ein kompatibler Blueprint ist optional und wandelt die Rohdaten in benannte Messwerte um, die Kilo verwenden kann.

Vor 3.9.0 konnte der KI-Assistent zwar eine MIOTY-Verbindung erstellen, das Gerät mussten Sie aber weiterhin manuell registrieren.

Der Assistent kann jetzt gemeinsam mit Ihnen die Geräteeinrichtung abschließen. Er wird:

1. Ihnen helfen, Hersteller, Modell und eine verfügbare Blueprint-Version auszuwählen, wenn ein Decoder benötigt wird;
2. EUI, Network Session Key und Short Address erfassen und validieren, während Sie sie eingeben;
3. das Gerät erstellen und den ausgewählten Blueprint anhängen, falls vorhanden.

Der Assistent fragt nach Kennungen, die aus Ihrer Hardware- oder Herstellerdokumentation stammen müssen; er generiert sie nicht.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-94128f20051cf26495dbd82f77716ae4ecefbf67%2Fdevice-mioty-connection.jpg?alt=media" alt="The MIOTY device form, showing the End Point EUI, short address and network key that the assistant now collects and enters for you"><figcaption></figcaption></figure>

[→ Mit KI bauen](/kilo-docs-de/kilo-iot-server/ai-assistant/building-with-ai.md)

***

**Verwenden Sie Ihr eigenes KI-Konto**

Jeder Kilo-Plan enthält ein monatliches Kontingent an Nachrichten für den KI-Assistenten. Sie können stattdessen ein Konto von OpenAI, Anthropic, OpenRouter, Ollama oder einem benutzerdefinierten OpenAI-kompatiblen Anbieter verbinden. Nachrichten, die über diese Verbindung gesendet werden, verbrauchen nicht das in Ihrem Kilo-Plan enthaltene Kontingent.

Öffnen **Verbinden Sie Ihre KI** in der oberen Leiste des KI-Chats und geben Sie Anbieter, Endpunkt, API-Schlüssel und Modellnamen ein.

Vor 3.9.0 lehnte Kilo Ollama-Modellnamen ab, die nach einem Doppelpunkt eine Version enthielten, wie etwa `gpt-oss:120b`. Die vorgeschlagenen Ollama-Modelle waren auch für kostenlose Konten nicht verfügbar. Versionsangaben in Modellnamen werden jetzt akzeptiert, und die Vorschläge wurden auf Modelle aktualisiert, die mit einem kostenlosen Ollama-Konto funktionieren.

Verbindungsfehler unterscheiden jetzt zwischen:

* einem API-Schlüssel, den der Anbieter nicht erkennt;
* einem gültigen Konto, das keinen Zugriff auf das ausgewählte Modell umfasst;
* einem Modellnamen, den der Anbieter nicht anbietet.

Nach dem Verbinden zeigt das Panel weiterhin Endpunkt, ausgeblendeten Schlüssel und Modellnamen an, damit Sie bestätigen können, welche Konfiguration verwendet wird.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-2ba8ad82fa94e60cc6ec43e5d91a679c300677e7%2Fai-connect-your-model.jpg?alt=media" alt="The Connect your AI panel — provider, base URL, API key, and model ID"><figcaption></figcaption></figure>

[→ Chats und KI-Zugriff verwalten](/kilo-docs-de/kilo-iot-server/ai-assistant/managing-chats-and-ai-access.md)

***

**Verbundene KI-Apps können Lese- und Schreibaktionen unterscheiden**

Kilo kann sich mit KI-Apps wie ChatGPT, Claude und Cursor verbinden. Diese Apps können Fragen zu Ihren Geräten beantworten und mit Berechtigung Aktionen wie das Senden von Befehlen an Hardware ausführen.

Vor 3.9.0 hatten die verfügbaren Aktionen keine klaren Titel und zeigten nicht an, ob sie nur Daten lesen oder etwas verändert haben. Die KI-App konnte eine Aktion wie das Auflisten von Geräten nicht zuverlässig von einer unterscheiden, die ein Gerät löscht.

Jede Aktion kennzeichnet jetzt, ob sie Daten liest, etwas ändert oder löscht oder die Grenzen Ihrer Organisation überschreitet. Kompatible KI-Apps können diese Information nutzen, um reine Leseanfragen direkt zu beantworten und vor einer Änderung um Bestätigung zu bitten. Zusätzliche Kilo-Konfiguration ist nicht erforderlich.

Die veröffentlichte Aktionsliste wird aus denselben Definitionen erzeugt, die auch der Server verwendet. Aktionen, die aufgelistet, aber nicht implementiert waren, wurden entfernt.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-c76dbc8c4ecd947cc8440377d59be70c5367d640%2Fmcp-claude-session.jpg?alt=media" alt="A Claude session connected to Kilo, calling a tool and asking permission before continuing"><figcaption></figcaption></figure>

[→ MCP-Server](/kilo-docs-de/kilo-iot-server/api/mcp-server.md)

***

**Verbesserungen bei Zuverlässigkeit und Benutzeroberfläche**

Der KI-Assistent meldet das Ergebnis einer Aktion jetzt genauer:

* Er bestätigt eine Änderung des Meldeintervalls nur, wenn das Gerät sie akzeptiert.
* Beim erneuten Versuch der Geräteregistrierung wird der von Ihnen gewählte Name nicht mehr ersetzt.
* Die Geräteregistrierung fügt keine ungewünschte Temperaturzuordnung mehr hinzu.
* MIOTY-Verbindungen zeigen kein API-Schlüsselfeld mehr an, das sie nicht verwenden.
* Der Assistent erklärt korrekt, dass Kilo Gerätebefehle ausführen kann. Wenn eine Aktion in der Weboberfläche abgeschlossen werden muss, verweist er Sie auf den richtigen Bildschirm.
* Eine erfolgreiche Geräteregistrierung zeigt keine widersprüchliche Fehlermeldung mehr an.
* Bestätigungsnachrichten zeigen Zeilenumbrüche korrekt an.
* Antworten wiederholen dieselbe Antwort nicht mehr sowohl im Text als auch in einem Widget.
* Antworten, die auf einmal eintreffen, erscheinen sofort, ohne dass ein Neuladen der Seite erforderlich ist.
* Gerätegrenzen werden konsistent durchgesetzt, egal ob ein Gerät über den Assistenten oder über ein Formular hinzugefügt wird.

Weitere Verbesserungen in dieser Veröffentlichung umfassen:

* Gerätefotos werden korrekt gespeichert.
* Der Audit Trail aktualisiert sich nach Berechtigungsänderungen, sodass neue Einträge ohne Neuladen der Seite erscheinen.
* MIOTY-Geräte zeigen deutlich, dass sie ihre eigene Kopie eines Blueprints verwenden; das Bearbeiten der Kopie eines Geräts scheint sich nicht mehr auf andere Geräte auszuwirken.
* Werte im Widget „Letzte Daten“ ändern ihre Farbe wieder entsprechend ihren Bedingungen.
* Die Gerätediagnose verwendet die korrekte Kilo-Terminologie.
* Der Assistent kann längere Zeiträume des Geräteverlaufs abrufen.
* Geräte, die einmal täglich melden, werden nicht mehr schon nach wenigen Stunden als offline markiert, und die Warnung nennt ihre Einheiten.
* Die Aufbewahrung der Geräteprotokolle richtet sich nach dem in Ihrem Plan enthaltenen Limit.
* Im Supportformular können Sie einen Fehlerbericht, einen Funktionswunsch oder eine Integrationsanfrage auswählen.
* Emulierte Geräte versehen ihren ersten Messwert korrekt mit einem Zeitstempel und werden auf mobilen Bildschirmen korrekt angezeigt.
* Der Auslöse-Dialog passt auf mobile Bildschirme, und das KI-Chat-Symbol ist leichter zu erkennen.
* Leere Zustände sind bei Connectors, Geräten, Regeln, Regel-Artefakten und MIOTY-Basisstationen konsistent. Leere Zustände bei Geräten und Gateways verlinken außerdem zum Shop, wenn keine Hardware hinzugefügt wurde.
* Die Übersichtsseite, die Abstände in der Navigation, die Karte „App herunterladen“, die Rechnungsnavigation und die Bildschirme der Rules Engine wurden überarbeitet, und veralteter Frontend-Code wurde entfernt.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-c074814b54eac6ea2f4a0c6f4f1085466a44929d%2FKilo_Scale_Log_Release_3.9.0.jpg?alt=media" alt="Kilo IoT Server 3.9.0"><figcaption></figcaption></figure>

</details>

<details>

<summary>Scale Log. Veröffentlichung 3.8.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-ddc80c0ba40c9c0a189839bf91592db553cf6cba%2FKilo_Scale_Log_Release_3.8.0.jpg?alt=media" alt="Kilo IoT Server 3.8.0 release banner"><figcaption></figcaption></figure>

Drei große Neuheiten in 3.8.0. **Erstens brauchen Sie zum Starten keine Hardware mehr** — der **Emulator** erstellt einen kompletten Standort ganz ohne Geräte, einschließlich Dashboards, Regeln und eskalierenden Alarmen, und übergibt dieselben Geräte dann am Tag ihres Eintreffens an echte Sensoren. **Zweitens bedient der KI-Assistent jetzt Ihre Anlagen**: Er listet die Befehle auf einem Gerät auf, führt einen nach Ihrer Bestätigung aus und prüft, ob er angekommen ist. **Und drittens — die Funktion, auf die wir uns am meisten freuen — verbinden Sie ChatGPT oder Claude über MCP, und sie steuern auch Ihre Geräte.** Kein Chatbot, der Ihr Gebäude beschreibt: Ihr eigener KI-Client, der Relais schaltet und Sollwerte auf echter Hardware ändert, innerhalb Ihrer eigenen Berechtigungen, wobei jeder Befehl aufgezeichnet wird. Außerdem sagt Ihnen die Plattform jetzt, was in einem **Was ist neu** Panel ausgeliefert wurde, und MIOTY erreicht eine größere Auswahl an Basisstationen mit **BSSCI 1.1**. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **Emulator-Connector** — Erstellen und testen Sie eine Bereitstellung, bevor es überhaupt Hardware gibt: Geräte, die ihre eigene Telemetrie aus realen Geräte-Voreinstellungen erzeugen, mit manuellen Werten und „einmal senden“, und wechseln Sie dann am Go-Live-Tag zu einem echten Connector.
* **Ihre KI steuert jetzt die Anlagen** — Fragen Sie den Assistenten, was ein Gerät kann, weisen Sie es an, etwas zu tun, und es führt den Befehl aus und bestätigt die Zustellung. Die Plattform ist nicht mehr etwas, über das Sie nur Fragen stellen.
* **Steuern Sie Ihre Geräte von ChatGPT oder Claude aus** — Verbinden Sie einen beliebigen MCP-Client — ChatGPT, Claude, Cursor, Codex — und er kann auf dieselbe Weise Befehle auf Ihrer Hardware ausführen, innerhalb Ihrer eigenen Berechtigungen. Ein LLM mit Zugriff auf echte Infrastruktur.
* **KI steuert den Emulator** — Stellen Sie ein emuliertes Gerät bereit, ändern Sie seine Konfiguration, senden Sie einen Messwert und wechseln Sie es zur echten Hardware, alles im Gespräch.
* **Was ist neu im Produkt** — Ein Panel, das Ihnen anzeigt, was ausgeliefert wurde, erzeugt aus diesem Änderungsprotokoll, damit es nie von der Dokumentation abweichen kann.
* **MIOTY BSSCI 1.1** — Die Aushandlung der Protokollversion bringt neuere Basisstationen an dasselbe Service Center, und Stationskennungen werden über den gesamten vorzeichenlosen 64-Bit-EUI-Bereich akzeptiert.
* **Audit Trail repariert** — Die defekten Komponenten auf der Audit-Trail-Seite sind behoben.
* **Fehlerbehebungen und Feinschliff** — Abrechnungszeitraum des Abonnements, ein CORS-Fix, MIOTY-Zuverlässigkeit, Platzierung von Dashboard-Widgets und Oberflächenkorrekturen bei Geräten und Schwellenwerten.

***

**Der Emulator — eine Bereitstellung, die Sie erstellen können, bevor die Sensoren eintreffen**

Lieferzeiten für Sensoren werden in Wochen gemessen. Bis jetzt wartete die Konfigurationsarbeit auf sie: Sie konnten kein Dashboard-Update sehen, keine Regel auslösen sehen und nicht testen, ob eine Eskalationskette tatsächlich jemanden erreicht, weil es nichts gab, das Daten sendete. Der Emulator beseitigt diese Abhängigkeit vollständig. Fügen Sie den Connector hinzu — er hat keine Einstellungen, nichts zu konfigurieren —, erstellen Sie darauf ein Gerät, und dieses Gerät beginnt, Telemetriedaten in dem von Ihnen gewählten Intervall zu erzeugen.

Die Messwerte stammen aus **einer integrierten Liste realer Geräte-Voreinstellungen**. Wählen Sie das Modell, das Sie bestellt haben, und das emulierte Gerät meldet genau das, was dieser Sensor meldet — die richtigen Metriknamen, die richtigen Datentypen —, sodass die Dashboards und Regeln, die Sie jetzt erstellen, mit der Hardware übereinstimmen, wenn sie eintrifft. Oder definieren Sie die Schlüssel manuell, wenn Ihr Gerät nicht in der Liste ist. Auf dem Emulator-Tab des Geräts können Sie einen Wert anheften, damit das Gerät ihn beibehält — ein auf −18 °C geparkter Gefrierschrank, während Sie sehen, wie ein Alarm eskaliert —, oder **einmal senden** um einen Grenzwert auf Abruf auszulösen. Aktivieren Sie **Befehle unterstützen** und das Gerät verhält sich wie steuerbare Hardware, sodass Sie eine Regelungsschleife einüben können, bevor die Anlage existiert.

Dann der Teil, der es mehr als nur zu einer Demo macht. Wenn die Hardware eintrifft, ändern Sie den Connector des Geräts vom Emulator auf den echten. **Alles, was Sie gebaut haben, bleibt erhalten** — die Dashboards, die Regeln, die Schwellenwerte, die Eskalationsketten. Sie ersetzen die Datenquelle, nicht die Bereitstellung. Der Wechsel funktioniert in beide Richtungen, sodass Sie auch ein echtes Gerät auf den Emulator verschieben können, um ein Problem zu reproduzieren, und es dann zurückverschieben können.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-3821bbabd3b8fae17eaac44f13b63813b5e5044f%2Femulator-device-metrics.jpg?alt=media" alt="An emulated device built from a device preset, with its readings and data types filled in"><figcaption></figcaption></figure>

[→ Emulator-Connector](/kilo-docs-de/kilo-iot-server/connectors/emulator-connector.md)

***

**KI führt Gerätebefehle aus**

Das ist der große Punkt. Jeder hat schon die Demo gesehen, bei der eine Lampe mit einem Sprachmodell verkabelt und eingeschaltet wird — ein netter Trick, aber kein System. Dahinter steckt kein Gerätemodell, keine Berechtigungen, keine typisierten Parameter, kein Zustellstatus, kein Protokoll darüber, was passiert ist. Bitten Sie ein Modell, das in einem Gebäude, einer Anlage oder einer Flotte zu tun, muss es bei jedem einzelnen Aufruf Funkprotokolle, Nutzdaten und Zugriffsrichtlinien improvisieren. Deshalb verlassen solche Demos nie den Schreibtisch.

3.8.0 stellt dem Modell einen echten IoT-Server zur Seite — und öffnet ihn für den KI-Client, den Sie bereits verwenden. Der integrierte Assistent kann **die auf einem Gerät konfigurierten Befehle auflisten, einen ausführen und den Ausführungsstatus prüfen**. Das können auch **ChatGPT**. Das können auch **Claude**. Das können auch Cursor, Codex oder alles andere, das MCP spricht, über `device_command_list`, `device_command_execute` und `device_command_status`. Ändern Sie ein Meldeintervall, schalten Sie ein Relais, passen Sie einen Controller an — aus dem Fenster, das Sie bereits geöffnet haben, auf echter Hardware.

Was das sicher macht, ist, was es nicht tut. Es führt **bereits vorhandene Befehle** auf dem Gerät aus — benannte Aktionen mit typisierten Parametern, die jemand, der die Anlage kennt, bewusst definiert hat — statt einen rohen Downlink zu erzeugen. Jede Ausführung erfolgt erst nach einer ausdrücklichen Bestätigung, weil die Wirkung physisch ist. Die Zustellung erfolgt asynchron, daher wird der Status danach gemeldet, statt Erfolg anzunehmen. Und jeder Versand landet wie jeder andere im Verlauf der Befehlsausführung.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-7692a0f37a45adaf476c0a2601d8dc389485ed56%2Fai-chat-device-commands.jpg?alt=media" alt="The Kilo assistant listing what it can do with device commands and its confirmation rule"><figcaption></figcaption></figure>

[→ Physische KI-Plattform](/kilo-docs-de/kilo-iot-server/physical-ai.md) · [→ Mit KI bauen](/kilo-docs-de/kilo-iot-server/ai-assistant/building-with-ai.md)

***

**Steuern Sie Ihre Geräte von ChatGPT oder Claude aus**

Es ist nicht nur der Assistent in Kilo. Verbinden Sie den KI-Client, mit dem Ihr Team bereits arbeitet — **ChatGPT**, **Claude**, Cursor, Codex, alles, was MCP spricht — melden Sie sich mit Ihrem üblichen Kilo-Konto an, und er erhält dieselbe Gerätesteuerung über `device_command_list`, `device_command_execute` und `device_command_status`.

Die Zusicherungen gelten ebenfalls: nur vorhandene Befehlsdefinitionen, eine Bestätigung, bevor etwas Physisches geschieht, der Zustellstatus wird danach gemeldet, und jeder Versand erscheint im Verlauf der Befehlsausführung. Was sich ändert, ist, von wo aus Sie fragen.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-ddc80c0ba40c9c0a189839bf91592db553cf6cba%2FKilo_Scale_Log_Release_3.8.0.jpg?alt=media" alt="Kilo IoT Server 3.8.0 — device control from any MCP client"><figcaption></figcaption></figure>

[→ MCP-Server](/kilo-docs-de/kilo-iot-server/api/mcp-server.md)

***

**KI steuert den Emulator**

Der Assistent hat auch den Emulator gelernt. Er kann die verfügbaren Geräte-Voreinstellungen auflisten, ein emuliertes Gerät bereitstellen, dessen Konfiguration und Intervall lesen und aktualisieren, einen einmaligen Messwert senden, um eine Regel zu testen, und das Gerät bei Eintreffen der Hardware live auf eine echte LoRaWAN-Verbindung bringen. Eine Testbereitstellung aufzusetzen ist jetzt eher ein Gespräch als ein Nachmittag.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-2695eeadc51725a02749cf5f8a5ce62cb3d764fe%2Femulator-manual-value.jpg?alt=media" alt="Sending a one-off reading from an emulated device&#x27;s Emulator tab"><figcaption></figcaption></figure>

[→ Emulierte Geräte](/kilo-docs-de/kilo-iot-server/devices/emulated-devices.md)

***

**Was ist neu, innerhalb des Produkts**

Veröffentlichungen nützen nichts, wenn niemand sie bemerkt. Die Plattform zeigt jetzt ein **Was ist neu** Panel, das durch die ausgelieferten Neuerungen führt, sodass eine Änderung die Menschen erreicht, die das Produkt verwenden, statt in einem Änderungsprotokoll zu bleiben, das sie nie öffnen.

Es wird aus dieser Seite generiert. Das Änderungsprotokoll ist die Quelle, eine Pipeline wandelt es in den Release-Feed um, den das Produkt liest, und das Panel zeigt dieselben Worte, die Sie gerade lesen — sodass Produkt und Dokumentation nicht auseinanderdriften können.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-703af227b6941bc9a05665c7bbcbcd1d218351c3%2Fwhats-new-panel.jpg?alt=media" alt="The What&#x27;s New panel in the product, showing the 3.8.0 releases with a screenshot, description and a Learn more link"><figcaption></figcaption></figure>

***

**MIOTY erreicht mehr Basisstationen**

MIOTY kam in 3.7.0. Diese Veröffentlichung ist der erste Härtungsschritt für reale Bereitstellungen. Das Service Center handelt jetzt die **BSSCI-Protokollversion** aus, wenn sich jede Station verbindet, und unterstützt **BSSCI 1.1** zusammen mit früheren Revisionen, sodass eine neuere Station und eine ältere denselben Standort bedienen können und ein Firmware-Upgrade Sie die Verbindung nicht kostet. Stationskennungen werden über den **gesamten vorzeichenlosen 64-Bit-EUI-Bereich**akzeptiert, einschließlich hoher Werte, die manche Plattformen grundsätzlich ablehnen.

Im Hintergrund wurden Sitzungsfortsetzung, Zertifikatsausstellung und Downlink-Versand verbessert, und doppelte Stations- und Seitenfehler wurden behoben, ebenso die Möglichkeit, einen physischen MIOTY-Endpunkt von seinem digitalen Gerät zu lösen.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-5db5ab26668bb03d90afc4340fda8dd248b8d7c0%2Fmioty-base-stations-list.jpg?alt=media" alt="The Mioty Base Stations tab showing a registered station with its EUI, status and BSSCI address"><figcaption></figcaption></figure>

[→ MIOTY-Basisstationen](/kilo-docs-de/kilo-iot-server/gateways/mioty-base-stations.md)

***

**Audit Trail repariert**

Die Audit-Trail-Seite hatte defekte Komponenten. Das ist behoben: Der Akteursfilter, der Ereignistyp-Filter und der Datumsbereich funktionieren wieder, sodass Sie die Zugriffshistorie einer Organisation auf die Person, die Art der Änderung und den gewünschten Zeitraum eingrenzen können.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-d3980a99de88db489402525376cf74c6568d4db6%2Faudit-trail.jpg?alt=media" alt="The repaired Audit Trail page with its actor, event type and date range filters"><figcaption></figcaption></figure>

[→ Audit Trail](/kilo-docs-de/kilo-iot-server/reports/audit-trail.md)

***

**Fehlerbehebungen und Feinschliff**

Das Abonnement meldet jetzt den aktuellen Planzeitraum korrekt, und ein die Oberfläche beeinträchtigender CORS-Fehler ist behoben. Das Hinzufügen eines Widgets stört die Platzierung der bereits auf einem Dashboard vorhandenen Widgets nicht mehr. Lange MQTT-Themen laufen auf Mobilgeräten nicht mehr über ihren Container hinaus, das Schwellenwert- **Beschriftung** Feld ist breit genug, um das von Ihnen Eingetippte zu lesen, der Tooltip zur Gerätezuordnung erklärt seine Bedeutung, und der zulässige Bereich für einen MIOTY- **Short Address** wird einheitlich beschrieben. Typprüfung und eine Reihe von Härtungs-Fixes für die Zugriffskontrolle runden die Veröffentlichung ab.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-ddc80c0ba40c9c0a189839bf91592db553cf6cba%2FKilo_Scale_Log_Release_3.8.0.jpg?alt=media" alt="Kilo IoT Server 3.8.0"><figcaption></figcaption></figure>

</details>

<details>

<summary>Scale Log. Veröffentlichung 3.7.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-c68928096868784380deb08e6d0cb94283d31934%2FKilo_Scale_Log_Release_3.7.0.jpg?alt=media" alt="Kilo IoT Server 3.7.0 release banner"><figcaption></figcaption></figure>

3.7.0 erweitert, was die Kilo IoT Platform erreicht, und präzisiert, was sie Ihnen mitteilt. **MIOTY** erscheint als erstklassiges Protokoll — Basisstationen, Endpunkte und Nutzdaten-Blueprints —, sodass die Bereitstellungen im Massstab und mit hoher Störfestigkeit, für die LoRaWAN nie ausgelegt war, jetzt auf derselben Plattform, mit denselben Dashboards und denselben Regeln laufen. Dashboards lernen, das Gebäude zu verlassen: ein **Freigabelink** verwandelt jedes Dashboard in eine passwortgeschützte Adresse, die Sie einem Kunden geben oder auf einem Wand-Tablet anheften können, mit **Ansicht** oder **Steuerung** Zugriff und einem Widerruf per Klick. **Gerätediagnose** ersetzt den schlimmsten Moment jeder Bereitstellung — *es ist installiert, und es passiert nichts* — durch eine klare Antwort und den nächsten Schritt. **Key Vault** holt Gerätezugangsdaten aus Tabellenkalkulationen heraus. Und ein **MCP-Server** ermöglicht es Ihrem eigenen KI-Client, sich anzumelden und direkt mit Ihrer Bereitstellung zu arbeiten. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **MIOTY-Unterstützung** — Ein neuer Connector, eine Kategorie „Mioty-Basisstationen“ unter Gateways, MIOTY-Endpunktfelder und ein vollständiges Blueprint-System zur Entschlüsselung von Nutzdaten — mit gerätespezifischen Snapshots, damit eine Katalogänderung ein bereits produktiv eingesetztes Gerät nie beeinträchtigt.
* **Dashboard freigeben** — Veröffentlichen Sie ein Dashboard als passwortgeschützten Link mit **Ansicht** oder **Steuerung** Zugriff. Sie können es jederzeit neu generieren oder widerrufen; öffnen Sie es im Vollbild auf einem Tablet oder einer Wandanzeige.
* **Gerätediagnose** — Der Verbindungs-Tab eines Geräts meldet jetzt seinen Empfangsstatus, die Pipeline, die jede Nachricht durchläuft, sowie einen Ereignis-Feed mit einer Statuslegende — und sagt Ihnen, was zu prüfen ist, wenn etwas nicht stimmt.
* **Key Vault** — Ein verschlüsselter, zugriffsgesteuerter Speicher für Geräte-EUI und Schlüsselpaarungen, unter der neuen **Aufzeichnungen & Berichte** Gruppe, mit **In Tresor hinzufügen** direkt im Geräteformular.
* **MCP-Server** — Verbinden Sie den KI-Client, den Sie bereits verwenden — Claude Code, Claude Desktop, ChatGPT, Codex, Cursor — mit Ihrer Organisation über Ihre eigene Kontoanmeldung und setzen Sie ihn in Ihrer realen Bereitstellung ein.
* **Scannen Sie einen QR-Code** — Lesen Sie eine DevEUI oder einen AppKey mit der Kamera eines Laptops oder Telefons, statt 16 oder 32 Hex-Zeichen einzugeben.
* **Widgets duplizieren und verschieben** — Wiederholen Sie ein konfiguriertes Widget über identische Sensoren hinweg oder verschieben Sie es auf ein anderes Dashboard.
* **Fehlerbehebungen und Feinschliff** — Layout-, Mobil- und Navigationskorrekturen bei Dashboards, Gateways, Geräten und dem Audit Trail.

***

**MIOTY — ein zweites Protokoll für die Bereitstellungen, die LoRaWAN nicht tragen kann**

MIOTY ([ETSI TS 103 357](https://mioty-alliance.com)) ist die neuere der beiden LPWAN-Technologien, entwickelt am Fraunhofer-Institut und ausgelegt für Umgebungen, die die erste Generation brechen: Fabrikhallen voller Störungen, Zehntausende von Endpunkten unter einem Empfänger, Sensoren an Maschinen, die nie stillstehen. Es kodiert jede Nachricht, teilt sie in zwei Dutzend Bursts von etwa 15 Millisekunden auf und streut sie über Frequenz und Zeit — sodass die Basisstation das ganze Telegramm wieder zusammensetzt **selbst wenn die Hälfte seiner Bursts zerstört wird**. Ein Störer muss mehr als 50 % einer einzelnen Übertragung über Zeit und Frequenz hinweg ausschalten, um Ihnen einen Messwert zu kosten. Deshalb trägt eine Basisstation bis zu 110.000 Endpunkte und 3,5 Millionen Nachrichten pro Tag. In 3.7.0 wird es ein nativer Teil der Plattform statt eines parallelen Systems.

Erstellen Sie einen **Mioty-Connector** und ein **Mioty-Basisstationen** -Tab erscheint neben Ihren LoRaWAN-Gateways. Registrieren Sie eine Basisstation mit ihrer BS EUI, laden Sie ihr Zertifikatspaket herunter, kopieren Sie die BSSCI-Adresse, und sie verbindet sich über eine zertifikatsgesicherte Verbindung — ohne Packet Forwarder dazwischen. Endpunkte erhalten ihr eigenes Formular: End Point EUI, Short Address, Network Session Key und die relevanten MIOTY-Funkoptionen.

**Es gibt keine MIOTY-Infrastruktur zu betreiben.** Die Enterprise-Edition unseres Service Centers ist in Kilo Cloud integriert, sodass der Connector die gesamte Einrichtung darstellt. Genau dieser Unterschied ist der Punkt der Veröffentlichung: Ein MIOTY-Netzwerkserver transportiert Nachrichten und verwaltet Basisstationen — nützlich, aber nicht dasselbe wie die Fähigkeit, *tun* irgendetwas mit einem Messwert zu tun. Hier landen die Endpunkte auf einer vollständigen Plattform, sodass die Rules Engine, Alarme mit Eskalation, Dashboards, der Digital Building Twin und der Audit Trail auf MIOTY-Daten genauso angewendet werden wie auf alles andere, und eine Regel kann gemeinsam über einen MIOTY-Endpunkt und einen LoRaWAN-Sensor nachdenken. Wenn Sie das Netzwerk lieber selbst betreiben, bleibt die Community-Edition — Kilo Center — Open Source und selbst gehostet.

Die Nutzdaten-Decodierung ist der Punkt, an dem sich das Design bezahlt macht. Ein **Blueprint** ist eine an einen Gerätetyp gebundene Decoder-Spezifikation, organisiert als Hersteller → Modell → Version und aufgeteilt in ein **System** Katalog, den jeder verwenden kann, und einen **Benutzerdefiniert** Katalog, der Ihnen gehört. Wählen Sie einen für ein Gerät aus, und die Plattform nimmt einen *Schnappschuss* davon auf dieses Gerät. Bearbeiten oder löschen Sie die Katalogvorlage danach, ändert sich nichts bereits im Feld befindlichen — diese Geräte laufen weiter mit ihrer eigenen Kopie, bis Sie sie bewusst auf eine neue Version verschieben. Zwei Geräte desselben Modells können unterschiedliche Blueprints ausführen. Erstellen Sie einen neuen aus eingefügtem JSON und testen Sie den Decoder mit einer Beispielnutzlast, bevor Sie ihn speichern.

[→ Was ist MIOTY?](/kilo-docs-de/kilo-iot-server/connectors/mioty-connector/what-is-mioty.md) · [→ Mioty-Connector](/kilo-docs-de/kilo-iot-server/connectors/mioty-connector.md) · [→ Mioty-Basisstationen](/kilo-docs-de/kilo-iot-server/gateways/mioty-base-stations.md) · [→ Mioty-Blueprints](/kilo-docs-de/kilo-iot-server/devices/mioty-blueprints.md)

***

**Dashboard freigeben — ein Link, ein Passwort und ein Aus-Schalter**

Ein Dashboard endete früher an den Grenzen Ihrer Organisation. Jetzt nicht mehr. Öffnen Sie das Aktionsmenü eines Dashboards, wählen Sie **Dashboard freigeben**, legen Sie ein Passwort fest und erzeugen Sie einen Link, der das Dashboard im Vollbild für alle öffnet, an die Sie ihn senden — kein Konto erforderlich. Wählen Sie **Ansicht** für einen Kunden, einen Prüfer oder einen Klienten, der nur sehen soll und sonst nichts; wähle **Steuerung** für das an der Linie montierte Tablet, auf dem ein Bediener die Geräte tatsächlich steuern muss. Ändere das Passwort, wenn sich das Publikum ändert, generiere den Link neu, um den alten ungültig zu machen, oder widerrufe ihn sofort, wenn ein Vertrag endet — der Link funktioniert dann sofort nicht mehr.

[→ Dashboards teilen](/kilo-docs-de/kilo-iot-server/dashboards/sharing-dashboards.md)

***

**Gerätediagnose — eine Antwort statt Schweigen**

Die Inbetriebnahme schlägt stillschweigend fehl. Das Gerät ist montiert, der Connector ist konfiguriert, und es kommt nichts an — ohne etwas anderes zu prüfen als ein leeres Diagramm. Die Registerkarte „Verbindung“ öffnet sich jetzt mit einem **Empfangsstatus** der angibt, in welcher der tatsächlichen Situationen du dich befindest: *Empfangen & speichern*, *Daten senden — Mapping einrichten, um sie*, *Daten kommen an, aber es wird nichts gespeichert*, *Netzwerk erreicht — wartet auf Daten*oder *Hat nicht berichtet — Gerät scheint offline zu sein*. Darunter zeigt eine **Pipeline** Ansicht, wie weit jede Nachricht kommt, und ein **Ereignis-Feed** listet sie Stufe für Stufe mit einer Legende auf, die klar sagt, was Routed, Mapped, Stored, OK, Skipped und Error jeweils bedeuten — einschließlich, dass Skipped oft gar kein Fehler ist. Jeder ungesunde Zustand kommt mit einer **Was zu prüfen ist** Liste und, sofern die Lösung in der Plattform liegt, einer Schaltfläche, die dich dorthin bringt. Connectors erhalten ihre eigene Diagnose mit Quellzustand, eingehenden Nachrichten und Aktivität.

Diese Zustände sind ein Lebenszyklus, und die Doku sagt das jetzt auch — einschließlich des Schritts, der alle überrascht. Ein LPWAN-Gerät gehört immer nur zu einem Netzwerk, daher ist eine aus einer anderen Site zurückgebrachte, gebraucht gekaufte oder auf einer anderen Plattform betriebene Einheit weiterhin dort verbunden *dort*. Sie hier zu registrieren ändert nichts: Sie bleibt bei *Wartet auf erste Daten* für immer stehen, obwohl jede überprüfbare Einstellung korrekt ist. Sie muss zurückgesetzt werden, bevor sie eine neue Join-Anfrage senden kann. Diese Antwort stand zuvor nirgends in der Dokumentation, und sie macht den Unterschied zwischen einer fünfminütigen Lösung und einem Vor-Ort-Einsatz aus.

[→ Gerätediagnose](/kilo-docs-de/kilo-iot-server/devices/device-diagnostics.md)

***

**Key Vault — Geräteschlüssel dort, wo sie hingehören**

Ein DevEUI und ein AppKey stehen auf einem Aufkleber, werden bei der Inbetriebnahme einmal eingegeben und leben danach in einer Tabellenkalkulation, einem Chatverlauf oder dem Notizbuch eines Installateurs. Vier Jahre später muss ein Gerät ersetzt werden und niemand kann sie finden. Ob man den Schlüssel an diesem Punkt wieder aus der Hardware auslesen kann, ist Glückssache — manche Hersteller geben ihn über eine Kabelverbindung heraus, viele nicht, und nichts davon ist eine Arbeit, die man an einer Einheit erledigen möchte, die bereits sechs Meter hoch im Gang hängt.

**Key Vault** ist das verschlüsselte Notizbuch, das die Frage hinfällig macht: ein Speicher für diese Paare, auf deine Organisation beschränkt, durch deren eigene Seitenberechtigung geregelt, im neuen **Aufzeichnungen & Berichte** Bereich neben dem Audit Trail. Speichere ein Paar, während du ein Gerät mit **In Tresor hinzufügen**konfigurierst, oder gib es direkt ein; suche nach jedem Fragment einer EUI oder eines Schlüssels. LoRaWAN DevEUI und AppKey, MIOTY EP EUI und Network Key, an einem Ort, verschlüsselt, mit Zugriff, den du kontrollierst.

[→ Key Vault](/kilo-docs-de/kilo-iot-server/reports/key-vault.md)

***

**MCP-Server — bring deinen eigenen KI-Client mit**

3.6.0 brachte einen KI-Integrator in die Plattform. 3.7.0 öffnet dieselbe Bereitstellung für den KI-Client, den du bereits verwendest. Richte Claude Code, Claude Desktop, ChatGPT, Codex, Cursor — alles, was MCP spricht — auf den Endpunkt deiner Organisation aus, melde dich im Browser mit deinem gewohnten Kilo-Konto an, und dein Client kann Geräte auflisten, Hardware bereitstellen, Telemetrie abfragen, Regeln und Alarme prüfen, Protokolle abrufen und dein Team verwalten — alles mit genau den Berechtigungen, die dein Konto bereits hat. Kein Schlüssel zum Kopieren, kein Token zum Einfügen. Der Standardendpunkt folgt der Organisation, die du ausgewählt hast; ein Pfad mit expliziter Organisations-ID bindet ihn an diese eine und lehnt alles ab, wofür du kein Mitglied bist. Da dies der offene Standard und keine Einmalintegration ist, funktionieren Clients, die MCP später unterstützen, ohne dass wir irgendetwas ausliefern müssen.

[→ MCP-Server](/kilo-docs-de/kilo-iot-server/api/mcp-server.md) · [→ IoT-KI-Assistent](/kilo-docs-de/kilo-iot-server/ai-assistant.md)

***

**Kleinigkeiten, die echte Minuten sparen**

Das Registrieren eines Geräts bedeutet nicht mehr, einen 32-stelligen AppKey von einem Etikett abzuschreiben: **QR-Code scannen** liest ihn mit der Kamera deines Laptops oder Telefons aus. Konfigurierte Widgets können **dupliziert** werden — eine Einrichtung, wiederholt über eine Reihe identischer Sensoren hinweg — oder **auf ein anderes Dashboard verschoben** werden, wenn sie dem Ort entwachsen, an dem sie begonnen haben. Und der Standort eines Geräts kann jetzt bearbeitet oder entfernt werden, nicht nur einmal festgelegt.

[→ Geräte registrieren](/kilo-docs-de/kilo-iot-server/devices/registering-devices.md) · [→ Widgets hinzufügen](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets.md)

***

**Fehlerbehebungen und Feinschliff**

Diese Version beseitigt außerdem eine Reihe von Layout- und Navigationsproblemen: Dashboards passen sich jetzt korrekt an große Monitore an, statt ihr Layout zu zerstören, das Formular für das Gateway-Foto entspricht dem Rest der Plattform, der Datumsbereichs-Selektor im Audit Trail sitzt dort, wo er hingehört, der Ablauf zum Hinzufügen von Geräten funktioniert auf einem Telefon korrekt, und die Links zu den Nutzungsbedingungen und der Datenschutzrichtlinie funktionieren wieder.

</details>

<details>

<summary>Scale Log. Version 3.6.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-90d8ea40f91fbf534c7e8d51b015ff6232a5eb70%2FKilo_Scale_Log_Release_3.6.0.jpg?alt=media" alt="Kilo IoT Server 3.6.0 release banner"><figcaption></figcaption></figure>

3.6.0 ist die Version, in der der Kilo IoT Server **KI-first**wird. Der integrierte Assistent — **AIoT**künstliche Intelligenz der Dinge, ins Kernsystem der Plattform integriert — ist nicht mehr nur ein Fragekasten, sondern arbeitet an deiner Seite wie ein erfahrener IoT-Integrator: Frage in natürlicher Sprache, und er stellt Geräte bereit, schreibt das CEL, erstellt und deployt Regeln und richtet Alarme ein — alles mit deiner Bestätigung. Und die Rules Engine bekommt eigene Hände — ein neuer **Befehl ausführen** Knoten lässt eine Regel sofort auf ein Gerät einwirken, sobald eine Bedingung erfüllt ist, sodass ein Leck nicht mehr nur einen Alarm auslöst, sondern das Wasser abdrehen kann. Neue öffentliche Command-APIs runden eine Version ab, die die Plattform sowohl intelligenter als auch leistungsfähiger macht. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **AIoT — ein in die Plattform eingebauter KI-Integrator** — Verankert in deiner Live-Bereitstellung beantwortet der Assistent Fragen aus deinen echten Daten und erledigt die Arbeit mit dir: Geräte bereitstellen, Regeln schreiben und deployen sowie Alarme mit Eskalation aufbauen — mit Bestätigung vor jeder folgenreichen Änderung und eigener Ergebnisprüfung.
* **Befehle in der Rules Engine** — Ein neuer **Befehl ausführen** Knoten macht Automatisierung zweiseitig: Eine Regel kann bei erfüllten Bedingungen einen Befehl direkt an ein Gerät senden. Erfassen, entscheiden, handeln — durchgängig, ohne jemanden im Ablauf.
* **Öffentliche Befehl-APIs** — Die Gerätebefehl-Endpunkte sind jetzt Teil der öffentlichen REST-API, mit neuen `Befehle` Lese- und Schreibbereichen für API-Schlüssel.
* **iFrame-Dashboard-Widget** — Bette eine externe Webseite — einen BI-Bericht, eine Wetterkarte, Live-Verkehr — direkt in ein Dashboard ein, neben deinen Gerätedaten.
* **Klarere Geräteprotokolle** — Protokolle werden jetzt minutenweise gruppiert, und eine Statusanzeige im Geräte-Header zeigt die Live-Verbindung und Protokollaktivität auf einen Blick.
* **Portugiesische Benutzeroberfläche** — Die Plattformoberfläche ist jetzt auf Portugiesisch verfügbar.
* **Fehlerbehebungen und Feinschliff** — Eine Runde von Stabilitäts- und Anmeldefixes über Organisationen, Alarme und API-Schlüssel hinweg.

***

**AIoT — deine Plattform, betrieben wie von einem Integrator**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-5d360ebd1f4608addcd5f475e2028ac895951211%2Fai-chat-home.jpg?alt=media" alt="The Kilo AIoT assistant ready to provision devices, deploy rules, and set up alarms"><figcaption></figcaption></figure>

Das ist die Schlagzeile von 3.6.0, und sie verändert, was die Plattform *ist*. Wir waren unter den Ersten, die einen KI-Chat auf Gerätedaten gesetzt haben — dann haben wir pausiert und statt überstürzt zu sein, die Infrastruktur darunter ordentlich aufgebaut: eine Agentenlaufzeit auf Enterprise-Niveau, die deine Bereitstellung von Ende zu Ende kennt und darin echte Arbeit verrichtet. Öffne sie über **KI-Chat** in der Seitenleiste und gib ihr Anweisungen wie einer Kollegin.

Sie antwortet aus deinen Live-Daten, beschränkt auf deine Berechtigungen — *„welche Geräte haben sich in 24 Stunden nicht gemeldet?“* — und sie handelt: Beschreibe eine Automatisierung und sie entwirft die Regel, schreibt das [CEL](https://cel.dev), testet sie und deployt sie; bitte sie, ein Gerät an Bord zu nehmen oder einen Alarm einzurichten, und sie führt den Ablauf aus, pausiert vor jeder **Aktion bestätigen** vor etwas Folgenreichem und liest das Ergebnis zurück, um die eigene Arbeit zu prüfen.

Das ist der Anfang, nicht die Ziellinie: Die Architektur steht, und die Genauigkeit und Reichweite des Assistenten wachsen, je mehr reale IoT-Aufgaben seine Agenten erlernen. Die Laufzeit darunter heißt [Synthetic Brew](https://syntheticbrew.ai)und wurde intern als eigenständiges Produkt entwickelt, nicht als Chatbot, der um die API von jemand anderem gewickelt wurde.

[→ IoT-KI-Assistent](/kilo-docs-de/kilo-iot-server/ai-assistant.md)

***

**Befehle in der Rules Engine — Automatisierung, die handelt**

Bis jetzt konnte die Rules Engine nur beobachten und warnen; jetzt kann sie handeln. Der neue **Befehl ausführen** Knoten sendet einen Befehl in dem Moment direkt an ein Gerät, in dem die Bedingungen einer Regel erfüllt sind — und schließt damit den Kreis, den die Plattform bisher einem Menschen überließ. Ein in einem Technikraum erfasstes Leck bedeutete früher einen Alarm und einen Sprint zum Absperrventil; jetzt schließt dieselbe Regel das Ventil selbst und löst im selben Durchlauf den Alarm aus. Kühlhaus, das zu warm driftet, stößt seine eigene Sollwertkorrektur aus. Ein Tank an der oberen Füllmarke schließt seinen Zulauf. Wähle das Zielgerät und einen seiner vorhandenen Befehle, setze jeden Parameter als festen Wert oder als CEL-Ausdruck, der vom Live-Wert gesteuert wird, und die Regel erledigt den Rest — im Ausführungsverlauf des Geräts protokolliert wie jeder andere Befehl.

[→ Gerätebefehle ausführen](/kilo-docs-de/kilo-iot-server/rules-engine/running-device-commands.md) · [→ Gerätebefehle](/kilo-docs-de/kilo-iot-server/devices/commands.md)

***

**Öffentliche Befehl-APIs**

Die Gerätebefehl-Endpunkte sind jetzt über die öffentliche REST-API verfügbar, sodass externe Systeme Befehle programmatisch definieren und ausführen können. Zwei neue Bereiche — **Befehle: Lesen** und **Befehle: Schreiben** — erlauben es dir, einem Schlüssel genau den Befehlszugriff zu geben, den er braucht, und nicht mehr.

[→ Öffentliche REST-API](/kilo-docs-de/kilo-iot-server/api/public-rest-api.md) · [→ API-Schlüssel](/kilo-docs-de/kilo-iot-server/settings/api-keys.md)

***

**iFrame-Widget — externer Kontext auf dem Dashboard**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-27037678133bcff59a9bcb0b8289267783755ecd%2Fiframe-widget-dashboard.jpg?alt=media" alt="An embedded weather map in an iFrame widget on a dashboard, beside a 3D building twin and a tank-level gauge"><figcaption></figcaption></figure>

Nicht alles, was ein Betriebsteam überwacht, kommt von einem Sensor. Das neue **iFrame** Widget bettet eine live externe Webseite direkt in eine Dashboard-Kachel ein, sodass ein unternehmensweiter BI-Bericht, eine regionale Wetterkarte, eine Live-Verkehrsansicht oder die Statusseite einer Abhängigkeit neben deinen Gerätedaten sitzt statt in einem weiteren Browser-Tab. Wähle **iFrame** im Widget-Auswahlmenü und füge die Einbettungs-URL ein, die die Quelle dir unter *Teilen → Einbetten* gibt — nur den `https://` -Link, nicht das ganze `<iframe>` -Snippet — gib dem Widget einen Namen, und es rendert live, mit Aktualisierung nach dem Zeitplan der Quelle. Einbettungen sind auf eine geprüfte Liste unterstützter Dienste beschränkt, die im Auswahldialog nach Kategorien gruppiert sind, sodass ein geteiltes Dashboard nur Seiten zeigt, die die Plattform geprüft hat; wenn eine benötigte Quelle nicht aufgeführt ist, kannst du sie im selben Bereich anfordern.

[→ iFrame-Widget](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/iframe-widget.md)

***

**Klarere Geräteprotokolle**

Die Registerkarte „Geräteprotokolle“ gruppiert Einträge jetzt minutenweise, sodass eine geschäftige Minute mit mehreren Batches als eine ordentliche Gruppe statt als unübersichtlicher Strom erscheint. Eine Statusanzeige im Geräte-Header zeigt die Live-Verbindung und die Protokollaktivität an, sodass du auf einen Blick sehen kannst, ob neue Daten hereinkommen.

[→ Geräteverwaltung](/kilo-docs-de/kilo-iot-server/devices/device-management.md)

***

**Fehlerbehebungen und Feinschliff**

Diese Version beseitigt außerdem eine Reihe von Stabilitäts- und Anmeldeproblemen: zuverlässigere Organisationsauswahl nach dem Login, der Alarm-Posteingang wird beim Wechseln der Organisationen korrekt aktualisiert, die Handhabung von Tariflimits blockiert nicht mehr die Verwaltung deiner Geräte und Regeln, einheitliche Bezeichnungen für API-Schlüsselbereiche sowie diverse Fehlerkorrekturen beim Registrieren von Geräten und Erstellen von Befehlen.

</details>

<details>

<summary>Scale Log. Version 3.5.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-fc5f6550f6ec9ecf2104c5e41ade90a28b8b7e77%2FKilo_Scale_Log_Release_3.5.0.jpg?alt=media" alt="Kilo IoT Server 3.5.0 release banner"><figcaption></figcaption></figure>

Jede Version bisher machte den Kilo IoT Server zu einem schärferen Augenpaar. **3.5.0 gibt ihm Hände.** Zum ersten Mal wird die Plattform wirklich **zweiseitig**: eine komplette Familie aus sechs **Steuer-Widgets** — unterstützt von der neuen **Gerätebefehle** -Engine — lässt dich Aktionen direkt an deine Hardware zurücksenden. Ein Relais schalten, eine Leuchte dimmen und farblich anpassen, einen Sollwert vorgeben, einen Controller neu starten — über MQTT oder LoRaWAN, von einer Dashboard-Kachel oder der Geräteseite aus. Füge ein Text-Widget, einen neuen Radial Gauge und schrittweises Rule-Debugging hinzu, und dies ist der bisher leistungsfähigste Kilo IoT Server. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **Steuer-Widgets — eine Familie aus sechs** — Sechs Dashboard-Steuerungsarten — **Schalter, Taste, einfacher Schieberegler, kreisförmiger Schieberegler, vertikaler Schieberegler und Eingabe** — jeweils an einen Gerätebefehl gebunden und den Live-Zustand des Geräts widerspiegelnd, sodass du ein Gerät direkt neben den Werten bedienst, die zeigen, ob du es tun musst.
* **Gerätebefehle** — Die Engine hinter den Bedienelementen. Definiere benannte, typisierte Befehle und sende sie als Downlinks über **MQTT oder LoRaWAN**, mit Parametervalidierung, optionaler Closed-Loop-Verifikation und vollständiger Ausführungshistorie.
* **Text-Widget** — Überschriften und Notizen, um ein dichtes Betriebs-Dashboard in beschriftete Abschnitte zu gliedern.
* **Radial Gauge** — Ein sechster Last-Data-Anzeigetyp: ein kreisförmiges Instrument mit konfigurierbarem Sweep-Winkel und deinen Bedingungen als farbige Bögen dargestellt.
* **Rule-Debugging** — Arbeite eine Regel Knoten für Knoten gegen eine Test-Nutzlast durch, setze Breakpoints, prüfe Variablen und CEL-Ausdrücke und steuere, wie Nebeneffekte ausgeführt werden — bevor du in Produktion deployest.
* **Vereinfachte Upgrades** — Die Auswahl eines Tarifs führt jetzt direkt mit einem einzigen **Plan upgraden** -Vorgang zur Kasse, und Tariflimits gelten standardmäßig.

***

**Gerätebefehle — die Plattform wird zweiseitig**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-e5d148689cf5bd708377bbea23e9bbbc92f79a5c%2Fdevice-command-editor.jpg?alt=media" alt="The device command editor with routing, payload, and verification sections"><figcaption></figcaption></figure>

Das ist die Schlagzeile von 3.5.0, und sie verändert, was die Plattform *tut*. Bisher war der Kilo IoT Server eine Einbahn-Datenleitung: Telemetrie floss hinein, und darauf zu reagieren bedeutete, die Plattform zu verlassen — hin zu einer Hersteller-App, einem handgebauten MQTT-Publisher oder einem Techniker mit Laptop. Gerätebefehle schließen diesen Kreis. Die neue **Befehle & Zustände** Registerkarte macht aus „dieses Gerät steuern“ eine modellierte, wiederverwendbare und prüfbare Oberfläche.

**Einmal definieren, überall ausführen.** Ein Befehl ist eine benannte Aktion mit typisierten Parametern — ein Helligkeitswert, ein Sollwert, ein Öffnen/Schließen. Bediener führen ihn aus, ohne jemals die rohe Nutzlast, das Byte-Layout oder das Topic zu sehen. Dasselbe Befehlskonzept liefert einen **MQTT** -Downlink an eine smarte Steckdose und einen **LoRaWAN** -Downlink an einen Class-C-Controller; die Plattform übernimmt für jeden die Kodierung.

**Geschlossener Regelkreis, mit vollständigem Protokoll.** Typisierte Parameter halten Eingaben innerhalb sicherer Bereiche. Optionale Verifikation bestätigt, dass das Gerät *tatsächlich gehandelt hat* — und nicht nur, dass die Nachricht das Gebäude verlassen hat. Und jede Ausführung wird mit ihrem Ergebnis protokolliert — Ausstehend, Bestätigt, Soft Warning oder Fehlgeschlagen — und gibt Betrieb und Compliance eine vollständige Wer-hat-was-wann-geändert-Übersicht. Verfügbar für MQTT-Geräte und **Class-C** LoRaWAN-Geräte (die kontinuierlich lauschen und daher immer bereit zum Empfangen sind). Ein Gerät ist in dem Moment steuerbar, in dem ein Befehl definiert ist — was es auch für ein Steuer-Widget auswählbar macht.

[→ Gerätebefehle](/kilo-docs-de/kilo-iot-server/devices/commands.md)

***

**Steuer-Widgets — Geräte vom Dashboard aus bedienen**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-0702697efe08122656cf039c800b53448e01736f%2Fcontrol-dashboard.jpg?alt=media" alt="A dashboard of Control widgets — a switch, a dial, a slider, and an input controlling a device"><figcaption></figcaption></figure>

Wenn Device Commands die Engine ist, ist das Control Widget die Bedienoberfläche — und es ist nicht ein Widget, sondern eine **Familie aus sechs**. Jedes bindet an einen Gerätebefehl und spiegelt den Live-Zustand des Geräts wider, sodass ein Bediener ein Gerät direkt neben den Werten ändern kann, die zeigen, ob es nötig ist. Wenn ein Gerät offline ist oder eine Bindung unvollständig ist, wird die Steuerung ausgegraut, statt ins Leere zu senden.

| Steuerungsart                                                                                                            | Am besten für                                            | Sendet                                             |
| ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------- | -------------------------------------------------- |
| [Schalter](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget/switch.md)                             | Ein dauerhafter Zweizustand (ein/aus, offen/geschlossen) | Ein Ein- oder Aus-Befehl beim Umschalten           |
| [Taste](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget/button.md)                                | Eine einmalige Aktion (Reset, Öffnen, Start)             | Ein einzelner Befehl pro Druck                     |
| [Einfacher Schieberegler](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget/slider-simple.md)       | Ein numerischer Wert auf einer horizontalen Skala        | Ein Befehlsparameter beim Schieben                 |
| [Kreisförmiger Schieberegler](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget/slider-circular.md) | Ein numerischer Wert auf einem radialen Zifferblatt      | Ein Befehlsparameter beim Drehen des Reglers       |
| [Vertikaler Schieberegler](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget/slider-vertical.md)    | Ein numerischer Wert auf einer senkrechten Skala         | Ein Befehlsparameter beim Schieben                 |
| [Eingabe](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget/input.md)                               | Ein exakter typisierter Wert                             | Ein Befehlsparameter, wenn du drückst **Anwenden** |

[→ Übersicht über Steuer-Widgets](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget.md)

***

**Text- und Radial-Gauge-Widgets**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-9caec73237ddfa2556814534ff8a8103b447b536%2Flast-data-radial-gauge.jpg?alt=media" alt="A Radial Gauge display showing a single reading on a circular dial with colored condition arcs"><figcaption></figcaption></figure>

Zwei weitere Dashboard-Bausteine kommen zusammen mit den Steuerungen hinzu. Das **Text-Widget** fügt Überschriften und Notizen auf ein Board, sodass ein dichtes NOC-ähnliches Display als geordnete Abschnitte statt als undifferenzierte Kachelmatrix lesbar ist. Und das **Radial Gauge** schließt sich dem Last-Data-Widget als sechster Anzeigetyp an — ein kreisförmiges Instrument mit konfigurierbarem Sweep-Winkel und deinen Bedingungen als farbige Bögen dargestellt, ideal für eine Überschrift wie Tankfüllstand oder Auslastungsprozentsatz.

[→ Text-Widget](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/text-widget.md) · [→ Radial-Gauge-Anzeige](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/last-data-widget/radial-gauge.md)

***

**Schrittweises Rule-Debugging**

Automatisierung, der du vertrauen kannst, bedeutet, genau zu sehen, was eine Regel tut, bevor sie in echt läuft. Der visuelle Rule-Editor enthält jetzt einen interaktiven Debugger: Gib einer Regel eine Test-Nutzlast und gehe ihre Ausführung Knoten für Knoten durch, halte an Breakpoints an, beobachte, wie sich Variablen ändern, und werte jeden CEL-Ausdruck aus, sobald er ausgelöst wird. Eine Debug-Toolbar steuert die Sitzung — hineinsteppen, überspringen, ausführen, über Breakpoints hinweg ausführen und stoppen — damit du nachweisen kannst, dass eine Regel funktioniert, bevor du sie ausrollst.

[→ Regeln debuggen](/kilo-docs-de/kilo-iot-server/rules-engine/debugging-rules.md)

***

**Vereinfachte Plan-Upgrades**

Der Wechsel zu einem kostenpflichtigen Tarif ist jetzt ein einziger Schritt: Wähle eine Stufe und **Plan upgraden** führt dich direkt zur sicheren Kasse, ohne zusätzliche Bestätigungsbildschirme dazwischen. Tariflimits gelten standardmäßig.

[→ Abonnement](/kilo-docs-de/kilo-iot-server/settings/subscription.md)

</details>

<details>

<summary>Scale Log. Versionen 3.2.0, 3.3.0, 3.4.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-143992c2a3ff4efc9141b7aa5a8197538f76220a%2FKilo_Scale_Log_Release_3.4.0.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Kilo IoT Server 3.4.0 ist die Version, für die es den Sprung der Hauptversion von 3.1 auf 3.4 gibt, und sie erscheint mit der Funktion, auf die die ganze Plattform hingearbeitet hat: dem **Digital Building Twin** — ein live IoT-Digitalzwilling deiner realen Immobilie. Binde jeden Sensor deiner Bereitstellung an jedes Objekt in einem 3D-Modell im Maßstab an — eine Parkbucht auf dem Gelände, eine Schranke am Eingang, ein Eingangstor, ein Müllcontainer an der Laderampe, ein Rauchmelder im Serverraum, eine Klimaanlage auf dem Dach, ein Wassertank im Keller — und die Szene färbt sich live um, während Messwerte einfließen. Smarte Parkflächen, Perimeterschutz, Abfallmanagement, mehrstöckige Gebäudekerne: ein Modell, ein Satz Sensorbindungen, eine räumliche Oberfläche, von der aus du arbeitest. Zeichne die Immobilie in 2D und 3D oder ziehe ihre Umrisse auf eine Luftaufnahme und verankere alles an ihren echten GPS-Koordinaten. Neben dem Digital Building Twin erhalten Dashboard-Autoren zwei neue Einzelwert-Visualisierungen für das Last-Data-Widget — Tube und Gauge. Versionen 3.2.0 und 3.3.0 wurden unterwegs als kleine Wartungsversionen ausgeliefert; ihre Notizen sind in diesem Eintrag zusammengefasst. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **Digital Building Twin** — Binde jeden Sensor deiner Bereitstellung an jedes Objekt in einem live 3D-Modell deiner realen Immobilie und beobachte, wie sich die Szene mit den Messwerten umfärbt. Smarte Parkbuchten, Schranken, Eingangstore, Müllcontainer, Klimaanlagen, Rauchmelder, Wassertanks, Schreibtische — alles aus dem Katalog mit über 60 Objekten. Mehrstöckige Gebäude und Außenanlagen in einer Szene; zeichne in 2D und 3D oder über Luftbild; die gesamte Immobilie an echte GPS-Koordinaten gebunden.
* **Tube-Widget** — Neuer Anzeigetyp für das Last-Data-Widget — eine vertikal gefüllte Röhrenvisualisierung mit konfigurierbaren Markierungen und bedingter Farbgebung
* **Gauge-Widget** — Neuer Anzeigetyp für das Last-Data-Widget — ein horizontaler Skalenmesser mit Bedingungsbereichen, Positionsmarker und Metrik-Symbolen
* **Korrektur des Seitenleistenzugriffs für Connectors** — Der Eintrag „Connectors“ erscheint für Benutzer ohne Berechtigung auf der Ressource nicht mehr in der Seitenleiste
* **Übersicht zeigt Alarmaktivität** — Die Übersichtsseite listet jetzt aktive Alarme auf und verlinkt direkt zur Alarm-Anwendung
* **Zuverlässigkeit der Transportschicht** — Fail-fast-Bereitschaft des Schemas und sessionsicheres Handling beim Rolling Restart auf dem Datenaufnahme-Transport

***

**Digital Building Twin**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-4fc4a46fcd5771d2bb778130d492375f7c876fd9%2F3d_Scene_Screen.jpg?alt=media" alt="Digital Building Twin recoloring live across a facility — parking bay A123 in red (occupied), A124 in green (vacant), color-coded waste containers, and conditional sensor markers across rooms"><figcaption></figcaption></figure>

Der Digital Building Twin ist Kilos Live-IoT-Digitalzwilling einer realen Immobilie. Sensoren aus deiner Bereitstellung werden direkt an die Objekte eines 3D-Modells im Maßstab gebunden — ein Lagerhaus, ein Bürogeschoss, ein Parkplatz, ein Einzelhandelsstandort, ein Serverraum, ein Wohnblock, ein Industriegelände — und die Szene färbt sich um, während Messwerte einlaufen. Öffne ein Dashboard, füge das Digital-Building-Twin-Widget hinzu, wechsle in den Bearbeitungsmodus und fang an zu zeichnen — es gibt kein separates CAD-Programm, keine externe 3D-Engine, keine Plugin-Installation.

**Jeden Sensor an jedes reale Objekt binden**

Das ist das Herzstück. Jedes Szenelement — eine auf dem Gelände markierte Parkbucht, eine Schranke am Eingang, ein Eingangstor, ein öffentlicher Müllcontainer an der Laderampe, ein an der Decke montierter Rauchmelder, eine Klimaanlage auf dem Dach, ein Wassertank im Keller, ein Schreibtisch auf einem Stockwerk, eine Wand eines Raums, ein ganzes Stockwerk — kann an einen IoT-Sensor aus deiner Bereitstellung gebunden werden. Öffne das Sensoren-Panel, wähle eine Datenquelle, wähle die Sensormetrik und klicke dann auf das/die Szeneelement(e), die dieser Sensor steuert.

Bindungen sind dem Geist nach viele-zu-viele. Ein Sensor kann sowohl einen Parkplatz als auch dessen Beschriftung einfärben. Ein Schreibtisch kann sowohl eine Belegungsbindung als auch eine Temperaturbindung tragen. Ein Müllcontainer kann seinen Füllstand am Körper und den offenen Deckelzustand auf dem Label anzeigen. Es gibt keine künstliche Beschränkung, welche Knotentypen eine Bindung akzeptieren — binde einen Sensor an einen Raum, indem du ihn an die Wände oder die Bodenzone dieses Raums bindest, binde einen Sensor an ein Fahrzeug, indem du ihn an das geparkte Automodell bindest, binde einen Sensor an ein Gerät, indem du ihn an das Katalogobjekt bindest, das es repräsentiert.

**Bedingte Farbgebung, gesteuert durch Live-Werte**

Jede Bindung trägt einen Satz von **Bedingungsregeln** — dasselbe Bedingungsmodell, das von den Widgets Last Data, Chart und Image verwendet wird:

* **Zahlenbereiche** — färben, wenn der Wert in einen Bereich fällt (z. B. 0–25 = grün, 25–28 = amber, 28+ = rot bei einem Raumtemperatursensor; oder 0–60 % = grün, 60–85 % = amber, 85+ % = rot bei einem Füllstandssensor für Müllcontainer)
* **String-Abgleich** — färben, wenn der Wert genau einem String entspricht (z. B. `belegt` = rot, `frei` = grün bei einem Parkplatzsensor; `angehoben` = grün, `gesenkt` = rot bei einer Schranke)
* **Boolean** — färben, wenn der Wert wahr oder falsch ist (z. B. Tor offen = rot, Tor geschlossen = grün)

Bedingungen sind nach Priorität geordnet: Die erste passende Regel gewinnt. Eine Standardfarbe gilt, wenn keine Bedingung zutrifft. Während Live-Werte einlaufen, färbt sich das Modell in Echtzeit um — Bediener sehen den Anlagenzustand auf einen Blick: Jede rote Parkbucht ist belegt, jeder amberfarbene Müllcontainer füllt sich, jede rote Schranke ist unten, jeder grüne Schreibtisch ist frei, jede amberfarbene Klimaanlage läuft außerhalb ihres Sollwerts.

**Live-Werte im Modell überlagert**

Sensoren können auch **angeheftet** an einen bestimmten Punkt in der Szene werden — ein Stecknadelmarker, der den aktuellen Wert der Bindung als Beschriftung darstellt, verankert an dem Stockwerk, auf dem die Nadel gesetzt wurde. Marker können global für saubere Screenshots ein- und für den Betrieb wieder eingeschaltet werden.

**Das Modell auf zwei Arten erstellen**

Es gibt zwei Einstiegspfade in ein Immobilienmodell, und sie lassen sich frei kombinieren:

* **Von Grund auf in 2D oder 3D zeichnen** — Beginne mit einem leeren Gelände und platziere Wände, Türen, Fenster, Zäune und Strukturelemente. Der Editor bietet sowohl eine 2D-Grundrissansicht als auch eine 3D-Begehungsansicht derselben Szene, sodass du die Geometrie von oben skizzieren und dann in drei Dimensionen prüfen kannst. Rückgängig, Wiederholen und ein Szenenbaum geben dir volle redaktionelle Kontrolle.
* **Von der realen Karte nachzeichnen** — Öffne den GPS-Karten-Trace-Dialog und skizziere die Umrisse eines Gebäudes direkt auf einer Luftaufnahme. Der Editor wandelt die nachgezeichnete Kontur in Wände um und verankert das Gebäude an den GPS-Koordinaten der Spur, sodass das Modell genau dort auf dem Planeten steht, wo die reale Immobilie steht.

Eine Szene kann **mehrere Stockwerke**enthalten, umgeschaltet über den Level-Selektor — ein mehrstöckiges Lagerhaus, ein Büroturm, ein unterirdisches Parkhaus unter einem Gebäude oder eine gestaffelte Anlage ist ein Modell mit einem Satz Bindungen, die sich über Stockwerke verteilen.

**Eine Bibliothek mit über 60 Objekten, innen und außen**

Der Editor wird mit einem integrierten Katalog von mehr als 60 sofort platzierbaren 3D-Objekten ausgeliefert. Die Außen- und Infrastrukturelemente sind zentral für IoT-Anwendungsfälle — Parkplätze, Verkehrssperren, Schranken, Tore, öffentliche Mülleimer und Müllcontainer, AC-Kondensatoren (Wohnhaus und Dach), Wasserenthärtungstanks, Fahrzeuge — und die Innenobjekte machen raum- und zonenbezogene Bindungen ausdrucksstark: Rauchmelder, Klimaanlagen, Wasserboiler, Warmwasserbereiter, Wasserpumpen und Pumpstationen, Decken- und Stehlampen, Schreibtische, Stühle, Sofas, Betten, Küchen- und Badarmaturen, Pflanzen und Dekoration.

Gesamter Katalog auf einen Blick:

* **Möbel** — Sofas, Sessel, Ess- und Bürostühle, Kaffee- und Esstische, Bürotische, Betten (Einzel-, Doppel-, Etagenbett), Bücherregale, Kommoden, Schränke, Wandregale, Säulen, Teppiche, Pflanzen, Mülleimer
* **Küche** — Herd, Kühlschrank, Arbeitsplatte, Mikrowelle
* **Badezimmer** — Toilette, Badewanne, Waschbecken (Aufsatz- und Wandmontage), Wasserhähne
* **Gerät** — Deckenlampen, Boden- und Tischlampen, Fernseher, Computer, Waschmaschinen, Klimaanlagen, Rauchmelder, Wasserboiler, Gas-Warmwasserbereiter, Wasserpumpen und Pumpstationen, Wasserenthärtungstanks
* **Außenbereich** — Tannen und Büsche, Sonnenschirme, **Parkplätze**, Fahrzeuge, AC-Kondensatoren (Wohnhaus und Dach), Verkehrssperren, Tore, öffentliche Mülleimer und Müllcontainer

Jedes Objekt ist ein vermessenes, korrekt skaliertes 3D-Modell. Viele lassen sich automatisch an Wänden oder Decken befestigen. Ziehe sie aus der Katalogleiste, lege sie in der Szene ab, positioniere sie mit dem Platzierungswerkzeug.

**GPS-Verankerung — die räumliche Grundlage**

Gebäude können über GPS-Koordinaten verankert werden, indem man sie bei der Erstellung auf der realen Karte nachzeichnet, und einzelne Szene-Punkte können im Bindungs-Panel manuell an einen Breitengrad/Längengrad verankert werden. Zusammen bilden diese Anker die räumliche Grundlage für standortbewusste IoT-Workflows.

**Was das ermöglicht**

Ein kurzer Rundgang durch die Arten von Bereitstellungen, für die der Digital Building Twin gedacht ist:

* **Sichtbarkeit von Smart Parking** — Binde Belegungssensoren an einzelne Parkbuchten auf dem Gelände; ein Blick auf das Modell zeigt dir, welche Buchten belegt (rot) und welche frei (grün) sind. Binde den Zustandsensor der Einfahrtschranke an das Schrankenmodell, sodass ihre aktuelle Position dieselbe Szene einfärbt.
* **Perimeter- und Zugriffsüberwachung** — Binde Öffnen/Geschlossen-Sensoren an Eingangstore, Schranken und Türen, um den Perimeterzustand einer ganzen Anlage von einer Oberfläche aus zu sehen.
* **Füllstand von Abfallcontainern verfolgen** — Binde Füllstandssensoren an Müllcontainer und öffentliche Behälter auf dem Geländeplan; bedingte Farbgebung führt jeden Behälter von grün (leer) über amber (sich füllend) bis rot (abholbereit).
* **Zustände im Gebäudeinneren** — Binde Temperatur-, Feuchtigkeits-, CO₂- und Luftqualitätssensoren an Räume, Stockwerke und Klimaanlagen, um zu sehen, welche Zonen im Soll liegen und welche Aufmerksamkeit brauchen. Rauchmelder und Wasserleck-Sensoren leuchten in dem Moment auf, in dem sie auslösen.
* **Zustand kritischer Anlagen** — Binde Füllstandssensoren an die Wasser­tanks, Boiler und Enthärtungstanks, die bereits im Katalog vorhanden sind, sodass das Tankmodell selbst als Füllstandsanzeige auf Anlagenebene gelesen werden kann.

Der Digital Building Twin zeigt dir, was auf dem Gelände passiert. Die Rules Engine reagiert auf denselben Sensorstrom, wenn eine Aktion nötig ist — beide arbeiten mit denselben Bindungen.

**Wo du es findest**

Füge über den standardmäßigen Add-Widget-Ablauf einen Digital Building Twin zu jedem Dashboard hinzu, öffne dann den Editor des Widgets, um zu zeichnen, zu befüllen und zu binden. Wie jedes andere Widget lebt es in der Ordnerhierarchie des Dashboards, folgt der organisationsweiten Freigabe und den ABAC-Berechtigungen und passt sich dem Dashboard-Raster an.

[→ Digital Building Twin](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/digital-building-twin.md)

***

**Tube-Widget**

Das Last-Data-Widget erhält einen **Tube** Anzeigetyp — eine vertikal gefüllte Rohr-Visualisierung, die den aktuellen Messwert auf einen konfigurierten Bereich abbildet. Sie eignet sich für jede Messung, die ein Bediener sich als Pegel vorstellen kann, egal ob wichtig ist, dass der Wert steigt oder sinkt — Füllstände von Lagertanks, Kraftstoffreserven, Wassertanks, Druckanzeigen und mehr.

Tube-Widgets haben dieselbe Konfigurationsoberfläche wie der Rest der Last-Data-Widget-Familie: mehrere Datenquellen pro Kachel, bedingte Farbgebung pro Metrik, benutzerdefinierte Einheiten, konfigurierbare Markierungsdichte und eine optionale Legende. Farbbedingungen sind nach Priorität geordnet — die erste passende Regel bestimmt die Füllfarbe.

[→ Last-Data-Widget](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/last-data-widget.md)

***

**Gauge-Widget**

Ein zweiter neuer Last-Data-Anzeigetyp — **Gauge** — zeigt den aktuellen Wert auf einer horizontalen Skala an, wobei jede Bedingung als farbcodierter Bereich dargestellt wird und ein Marker zum Live-Wert gleitet. Jede Metrik trägt ein Symbol, das zur sofortigen Identifizierung neben dem Gauge erscheint.

Gauges passen zu Dashboards mit Einzelwerten, bei denen die Schwelle genauso wichtig ist wie der Messwert — Temperaturbereiche in der Kühlung, Drehzahlbereiche an Industriemaschinen, Akkustände an Feldgeräten, Kapazitätsauslastung vernetzter Maschinen und Signalstärkeanzeigen für entfernte Installationen.

Tube und Gauge werden demselben Auswahlfeld für Widget-Typen hinzugefügt, das zuvor Number, Doughnut und Pie anbot — wähle sie im standardmäßigen Konfigurationsfluss des Last-Data-Widgets aus.

[→ Last-Data-Widget](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/last-data-widget.md)

***

**Korrektur des Seitenleistenzugriffs für Connectors**

— Eine Korrektur der Zugriffskontrollregeln, die die Verwaltungskonsole steuern: Benutzer ohne Berechtigung für die Ressource „Connectors“ sehen den Eintrag „Connectors“ nicht mehr in der Seitenleiste. Die Sichtbarkeit des Eintrags entspricht jetzt der zugrunde liegenden Autorisierungsentscheidung — konsistent mit jeder anderen ABAC-geschützten Seite in der Plattform.

[→ Benutzer und Berechtigungen](/kilo-docs-de/kilo-iot-server/account/users-and-permissions.md)

***

**Übersicht zeigt Alarmaktivität**

Die Übersichtsseite erhält ein eigenes Alarm-Panel, das aktive Alarme in der aktuellen Organisation auflistet und direkt zur Alarm-Anwendung verlinkt. Bediener müssen die Startseite nicht mehr verlassen, um eingehende Warnungen zu triagieren — die aktivsten Einträge werden beim Betreten der Plattform hervorgehoben.

[→ Posteingang und Auflösung](/kilo-docs-de/kilo-iot-server/alarm/inbox-and-resolution.md)

***

**Zuverlässigkeit der Transportschicht**

Zwei gezielte Härtungsmaßnahmen für den Datenaufnahme-Transport:

* **Fail-fast-Bereitschaft des Schemas** — Der Transport startet nicht mehr in einem degradierten Zustand, wenn sein Persistenzschema beim Start nicht verfügbar ist. Schema-Bereitschaftsfehler werden nun als Startfehler mit Sofortfehlschlag und protokollierter ursprünglicher Ursache gemeldet, wodurch stille Fehler verhindert werden, die zuvor zur Laufzeit unklare Folgefehler erzeugten.
* **Sicherheit bei Rolling-Restarts** — Jede Transportinstanz beansprucht nun eine eindeutige Sitzungsidentität auf dem Messaging-Broker und löscht ihre vorherige Sitzung beim Verbinden ausdrücklich. Rolling-Restarts des Brokers — und Rolling-Redeployments des Transports selbst — laufen ohne hängen gebliebene Subscriptions oder Zurückweisungen doppelter Clients ab.

Zusammen beseitigen diese Änderungen eine Klasse von Vorfällen, bei denen nachgelagerte Dienste den Verbindungsstatus von Geräten nicht nachschlagen konnten, weil der Transport in einem degradierten Modus gestartet war, ohne die Ursache offenzulegen.

</details>

<details>

<summary>Scale Log. Veröffentlichung 3.1.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-2edf78b6fa3f4decf70fb0438ab8a2256d831193%2FKilo_Scale_Log_Release_3.1.0.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Kilo IoT Server 3.1.0 erweitert das Konnektivitätsmodell der Plattform um externe MQTT-Unterstützung und schließt damit die erste Erweiterung des Connector-Frameworks seit 3.0.0 ab. Programmgesteuerter Zugriff ist nun über ein API-Schlüssel-System mit granularer Scope-Steuerung, Rotation und Widerruf verfügbar. Die Struktur der Abonnementstufen wurde überarbeitet und über die gesamte Bandbreite neu bepreist — von der kostenlosen Evaluierungsstufe bis zum Max-Plan. Die Alarmverwaltung erhält gezielte Präzisionsverbesserungen: Einmal-Benachrichtigungssemantik, verpflichtende Validierung von Eskalationsempfängern und Sichtbarkeit des letzten Auslösers für die operative Triage. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **MQTT-Connector** — Unterstützung für externe MQTT-Broker zum Konnektivitäts-Framework hinzugefügt; verbinden Sie jedes MQTT-publizierende Gerät oder System ohne LoRaWAN-Gateway
* **Karten-Widget** — Neues Dashboard-Widget, das die aktuelle Position eines Trackers auf einer interaktiven Karte darstellt und den aktuellen Wert eines beliebigen ausgewählten Messwerts anzeigt, den das Gerät überträgt; einschließlich Live-Ansicht und historischer Routenwiedergabe
* **API-Schlüssel** — Programmgesteuerter Zugriff mit Schlüssel-Lebenszyklusverwaltung: Anmeldeinformationen für Backend-Integrationen erstellen, rotieren und widerrufen
* **Neustrukturierung der Abonnementpläne** — Überarbeitete Stufennamen, Preise und Limits für alle Pläne mit einer neuen Individual-Stufe für benutzerdefinierte Bereitstellungen
* **Präzision des Alarmsystems** — Einmalige Benachrichtigungsmodus, verpflichtende Empfängerprüfung in Eskalationsketten und Zeitstempel des letzten Auslösers in der Tabelle der Alarmdefinitionen

***

**MQTT-Connector**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-59ff88df13cfb333c0d43d07db13c3eed0b3a449%2Fmqtt-connector-type-selector.jpg?alt=media" alt="Add connector dialog showing External MQTT and Cloud MQTT options"><figcaption></figcaption></figure>

Kilo IoT 3.1.0 fügt External MQTT als dritten Connector-Typ im modularen Konnektivitäts-Framework der Plattform hinzu, zusammen mit LoRaWAN und Vehicle Tracker.

**Architektur**

Der MQTT-Connector folgt demselben dreistufigen Modell, das in 3.0.0 eingeführt wurde: **Connector** (Protokolltyp) → **Verbindung** (organisationsbezogene Instanz mit Broker-Anmeldedaten) → **Gerät** (über die Verbindung registriert mit gerätebezogenem Topic-Routing). Die Konfiguration auf Verbindungsebene hält Broker-Anmeldedaten und Authentifizierung bereit. Topic-Routing, Payload-Zuordnung und Messwertbindung werden pro Gerät konfiguriert — dieselbe normalisierte Messpipeline gilt unabhängig vom Connector-Typ.

**Externe MQTT-Unterstützung**

Betreiber verbinden den Server mit jedem beliebigen MQTT-Broker, den sie betreiben oder kontrollieren. Unterstützte Broker-URL-Schemata: `mqtt://`, `mqtts://`, `tcp://`, `ssl://`. Authentifizierungsoptionen:

* **Anonym** — Keine Anmeldedaten erforderlich
* **Benutzername / Passwort** — Standard-MQTT-Anmeldeinformationspaar
* **TLS / Zertifikat** — Gegenseitiges TLS mit CA-Zertifikat, Client-Zertifikat und Client-Schlüssel (PEM-kodiert)
* **Token** — JWT-ähnliche Token-Authentifizierung

Sensible Felder — Passwörter, Tokens, Zertifikate — werden im Ruhezustand verschlüsselt. GET- und LIST-Antworten maskieren diese Felder. Authentifizierungsdaten werden nach der ursprünglichen Erstellung nie erneut offengelegt.

**Topic-Routing pro Gerät**

Topic-Routing wird pro Gerät statt pro Verbindung konfiguriert. Das Routing-Modell unterstützt zwei Strategien zur Geräteidentifikation:

* **Topic-basierte Identifikation** — Die Gerätekennung wird aus einem positionsabhängigen Segment im MQTT-Topic mithilfe eines `{{deviceId}}` Platzhalters extrahiert. Beispiel: `factory/sensors/{{deviceId}}/data`
* **Payload-basierte Identifikation** — Die Gerätekennung wird aus einem JSON-Feld im Nachrichtentext extrahiert, angegeben durch den Pfad

Telemetrie-Topics unterstützen einen zusätzlichen `{{value}}` Platzhalter für die Extraktion eines Einzelwerts aus Topic-Segmenten. Wenn keine Telemetrie-Topics konfiguriert sind, analysiert der Server die vollständige JSON-Nutzlast anhand abgeflachter Schlüsselpfade — kompatibel mit standardmäßigen Automations-Bridge-Formaten, die flache JSON-Geräte-Nutzlasten veröffentlichen.

**Operative Auswirkungen**

Der MQTT-Connector beseitigt die Notwendigkeit einer LoRaWAN-Infrastruktur beim Verbinden IP-nativer Geräte. Gebäudemanagementsysteme, industrielle SPS, Energiemessgeräte und jedes Gerät, das bereits an einen MQTT-Broker sendet, können ohne Protokollumwandlung oder Gateway-Bereitstellung integriert werden. Dasselbe Digital-Twin-Modell, dieselbe Pipeline zur Nutzlastnormalisierung und dieselbe Bibliothek von Sensorvorlagen, die LoRaWAN-Geräte steuert, gilt ohne Änderungen auch für MQTT-Geräte.

***

**API-Schlüssel**

Kilo IoT 3.1.0 führt ein produktionsreifes API-Schlüssel-System ein, das kontrollierten programmgesteuerten Zugriff auf die Daten- und Verwaltungs-APIs des Servers ermöglicht.

**Zugriffskontrolle nach Umfang**

Jeder API-Schlüssel trägt einen explizit ausgewählten Berechtigungssatz bei der Erstellung. Scopes folgen einem Ressourcen-Aktions-Modell und decken die gesamte operative Oberfläche der Plattform ab: Verbindungen, Dashboards, Geräte, Ereignisse, Protokolle, Organisationen, Regeln, Sensoren und Benutzer — jeweils mit unabhängigen Lese- und Schreibrechten. Integrationssysteme erhalten genau den Zugriff, den sie benötigen, ohne implizite Eskalation.

**Schlüssel-Lebenszyklus**

API-Schlüssel folgen einem dreistufigen Lebenszyklus:

* **Aktiv** — Schlüssel ist gültig und authentifiziert Anfragen
* **Rotiert** — Ein Ersatzschlüssel wurde ausgestellt; dieser Schlüssel authentifiziert nicht mehr
* **Widerrufen** — Schlüssel ist dauerhaft deaktiviert; bleibt für die Prüfpfad-Kontinuität in der Tabelle sichtbar

**Rotation** erstellt einen neuen Schlüssel und macht den Vorgänger sofort ungültig. Der neue Schlüssel wird bei der Rotation einmalig angezeigt und nie wieder — konsistent mit der Erstellungserfahrung. Rotierte Schlüssel erscheinen in der Tabelle mit ihren historischen Metadaten intakt.

**Widerruf** deaktiviert einen Schlüssel dauerhaft. Widerrufene Schlüssel bleiben in der Tabelle — Löschen wird nicht unterstützt, wodurch der Audit-Datensatz jedes jemals für die Organisation ausgestellten Schlüssels erhalten bleibt.

**Schlüsselanzeigerichtlinie**

Der vollständige Schlüsselwert wird genau einmal angezeigt: unmittelbar nach der Erstellung und unmittelbar nach der Rotation. Nachdem der Dialog geschlossen wurde, bleibt in der Benutzeroberfläche nur das Schlüsselpräfix erhalten. Dies wird auf API-Ebene erzwungen — der Server speichert oder gibt den vollständigen Schlüsselwert nach der ersten Ausstellung nicht mehr zurück.

**Operative Tabelle**

Die Tabelle der API-Schlüssel zeigt den Betriebszustand jedes Schlüssels an: Name, Präfix, aktive Scopes, Lebenszyklusstatus, Erstellungsdatum, konfigurierte Ablaufzeit und Zeitstempel der letzten Authentifizierung. Die Standard-Sortierung ist neueste zuerst.

***

**Neustrukturierung der Abonnementpläne**

Kilo IoT 3.1.0 führt eine überarbeitete Struktur der Abonnementstufen mit aktualisierten Namen, Preisen und einer neuen Individual-Stufe für Bereitstellungen ein, die die Parameter des festen Plans überschreiten.

**Kilo IoT Server-Tarife**

| Stufe       | Monatlicher Preis                         |
| ----------- | ----------------------------------------- |
| Kostenlos   | —                                         |
| Starter     | 25 €                                      |
| Pro         | 145 €                                     |
| Business    | 379 €                                     |
| Max         | 659 €                                     |
| Individuell | Benutzerdefiniert — Vertrieb kontaktieren |

Die Individual-Stufe ersetzt die vorherige Bezeichnung Enterprise. Organisationen mit Anforderungen, die die Parameter des Max-Plans überschreiten — Geräteanzahl, Regelgrenzen, Aufbewahrungsdauer oder Supportbedingungen — wenden sich direkt an das Vertriebsteam für eine maßgeschneiderte Vereinbarung.

Planänderungen werden über die in Stripe integrierte Abrechnung wirksam. Upgrades werden sofort verarbeitet. Abonnenten mit Jahreslaufzeit behalten ihren Abrechnungszyklus bei einem Planwechsel.

***

**Karten-Widget**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-ca32513d1a8a22a44162211b1410ec4c7c815fe4%2Fmap-widget-configuration.jpg?alt=media" alt="Map widget configuration showing device and metric selection with live map preview"><figcaption></figcaption></figure>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-729505e0447b4787f54ac7eeb02424ad5e3f99c1%2Fmap-widget-route-history.jpg?alt=media" alt="Map widget showing historical route playback with dashed route line on the dashboard"><figcaption></figcaption></figure>

Kilo IoT 3.1.0 führt das Karten-Widget als nativen Dashboard-Widget-Typ ein und erweitert die Visualisierungsebene der Plattform über statische Diagramme und numerische Anzeigen hinaus zu standortbezogener, georäumlicher Überwachung.

**Tracker-Daten auf dem Dashboard**

Das Karten-Widget verbindet sich mit jedem als Tracker registrierten Gerät auf der Plattform und rendert dessen Position als Live-Marker auf einer interaktiven Karte. Anders als die Kartenansicht in den Gerätedetails, die auf eine einzelne Geräteseite beschränkt ist, ist das Karten-Widget eine konfigurierbare Dashboard-Kachel — es ist Teil derselben Ordnerhierarchie, desselben Modells und desselben Layoutsystems wie jedes andere Dashboard-Widget. Ein einziges Dashboard kann mehrere Karten-Widgets enthalten, die jeweils ein anderes Asset verfolgen.

**Anzeige ausgewählter Messwerte**

Der Standort allein reicht für die operative Überwachung nicht aus. Das Karten-Widget löst dies, indem es ausgewählte Gerätemesswerte neben dem Positionsmarker anzeigt. Bei der Konfiguration des Widgets wählen Bediener aus, welche vom Tracker übertragenen Felder angezeigt werden sollen — Geschwindigkeit, Batteriestand, Temperatur, Signalqualität, Füllstand oder jeden gemappten Messwert, den das Gerät sendet. Der aktuelle Wert des ausgewählten Messwerts erscheint auf dem Marker, wobei die Farbe aus den konfigurierten Bedingungen des Messwerts abgeleitet wird. Ein grüner Marker bei 42 km/h und ein roter Marker bei 0 km/h bei laufendem Motor signalisieren auf einen Blick operativ unterschiedliche Zustände.

**Konfiguration**

Das Widget wird über das standardmäßige Zwei-Tab-Panel konfiguriert:

* **Datenquellen-Tab** — Wählen Sie das Tracker-Gerät aus. Das Widget identifiziert die Breiten- und Längengrad-Messwerte des Geräts. Wählen Sie zusätzliche vom Tracker übertragene Felder aus, die neben dem Standort angezeigt werden sollen.
* **Erscheinungsbild-Tab** — Weisen Sie einen Namen, eine Beschreibung, ein Kartenthema (Hell oder Dunkel) zu und schalten Sie die Datenlegende ein oder aus.

**Historischer Routenmodus**

Das Karten-Widget unterstützt einen Verlaufmodus mit Datumsbereich, der über das Menü des Widgets aufgerufen werden kann. Durch die Auswahl eines Datumsbereichs wird die aufgezeichnete Positionshistorie des Geräts für diesen Zeitraum abgefragt und die Route als Linie dargestellt, die aufeinanderfolgende GPS-Punkte verbindet. Die Karte passt sich automatisch an die Ausdehnung der Route an. Bediener können eine Lieferroute prüfen, die Einsatzabdeckung eines Außendiensttechnikers verifizieren oder die Bewegungshistorie eines beliebigen verfolgten Assets rekonstruieren, ohne das Dashboard zu verlassen. Das Löschen des Datumsbereichs versetzt das Widget wieder in den Live-Tracking-Modus.

***

**Präzision des Alarmsystems**

Kilo IoT 3.1.0 liefert gezielte Verbesserungen beim Erstellen von Alarmdefinitionen, bei der Validierung von Eskalationsketten und bei der Sichtbarkeit für die operative Triage.

**Einmaliger Benachrichtigungsmodus**

Alarmdefinitionen unterstützen eine Einmal-Zustellungsoption: Wenn der Alarmzustand aktiv wird, wird eine einzelne Benachrichtigung versendet, ohne Wiederholung, bis der Alarm behoben und erneut ausgelöst wird. Die Formularoberfläche macht das Verhalten explizit — wenn der Einmalmodus aktiviert ist, zeigt das Formular die aktive Wiederholungsrichtlinie für die ausgewählte Schweregradstufe zusammen mit der Überschreibungssteuerung an. Betreiber sehen die Plattform-Standardvorgabe und die Überschreibung in derselben Ansicht, wodurch Unklarheit darüber beseitigt wird, welcher Takt den Alarm steuert.

**Pflichtempfänger bei Eskalationen**

Das Notify-Feld in jedem Eskalationsschritt ist jetzt als Pflichtfeld erzwungen. Alarmdefinitionen können nicht gespeichert werden, wenn ein Eskalationsschritt keine konfigurierten Empfänger hat. Dadurch wird verhindert, dass fehlerhaft konfigurierte Alarme mit stillen Eskalationsketten in den aktiven Regelbestand gelangen.

**Sichtbarkeit des letzten Auslösers**

Die Tabelle der Alarmdefinitionen zeigt jetzt eine Spalte für den Zeitstempel des letzten Auslösers an — den jüngsten Zeitpunkt, zu dem diese Alarmdefinition ausgelöst wurde. Betriebsteams können die Alarmaktivität über den gesamten Definitionsbestand hinweg bewerten, ohne in den einzelnen Verlauf der Alarmereignisse zu wechseln. Hochfrequente oder unerwartet stille Alarme sind in der Definitionsliste sofort erkennbar.

</details>

<details>

<summary>Scale Log. Veröffentlichung 3.0.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-d2c44ccf7ada0e690981c4981f4087b3307c6d43%2FKilo_Scale_Log_Release_3.0.0.jpg?alt=media" alt=""><figcaption></figcaption></figure>

Kilo IoT Server 3.0.0 liefert eine von Grund auf neu gestaltete Architektur der Kerninfrastruktur der Plattform. Die Konnektivitätsschicht wurde durch ein modulares Framework ersetzt, das die Protokollverarbeitung in steckbare Connector-Typen abstrahiert. Die Geräteverwaltung arbeitet jetzt mit einem Digital-Twin-Modell mit Inline-Nutzlastnormalisierung — wodurch das manuelle Onboarding neuer Gerätetypen entfällt. Eine auf BPMN basierende Automatisierungs-Engine bietet unternehmensreife Regeldefinition mit vollständiger Versionskontrolle, validierten Builds und Bereitstellung ohne Ausfallzeit. Die operative Alarmierung unterstützt fünf Schweregradstufen mit mehrstufigen Eskalationsrichtlinien über E-Mail, SMS und native mobile Push-Benachrichtigungen. Dashboard-Widgets sind jetzt vollständig vom Bediener konfigurierbar, mit bedingter Formatierung pro Messwert. Der Zugriff in einer Multi-Tenant-Umgebung wird durch ABAC mit vollständiger Audit-Protokollierung durchgesetzt. [kiloiot.io](https://kiloiot.io)

***

#### Was ist in dieser Veröffentlichung

* **Modulares Konnektivitäts-Framework** — Steckbare Protokolladapter mit LoRaWAN- und OBD2/CAN-Fahrzeug-Tracker-Unterstützung zum Start
* **Gerät-Lebenszyklus und Datennormalisierung** — Digital-Twin-Gerätemodell mit Inline-Payload-Zuordnung und Sensorvorlagenbibliotheken
* **Visualisierung und Überwachung** — Bedienerkonfigurierbare Widgets mit schwellenwertgesteuerter Formatierung und einem neuen Anlagenbild-Widget
* **Produktionsreife Automatisierungs-Engine** — BPMN-Workflow-Designer mit CEL-Ausdrücken, Artefaktversionierung und verwalteter Bereitstellung
* **Operative Alarmierung und Eskalation** — Schweregradbasierte Alarmweiterleitung mit Eskalationsketten und mobiler Push-Zustellung
* **Multi-Tenant-Governance und Compliance** — Organisationsisolierung mit attributbasierter Zugriffskontrolle und unveränderlichen Audit-Protokollen

***

**Modulares Konnektivitäts-Framework**

Kilo IoT 3.0.0 ersetzt das protokollspezifische Geräte-Onboarding durch ein einheitliches Konnektivitätsmodell. Jede Protokollintegration ist nun als Connector gekapselt — ein modularer Adapter, der definiert, wie eine bestimmte Geräteklasse mit dem Server kommuniziert.

**Architektur**

Das Framework arbeitet auf drei Ebenen: **Connector** (Protokolldefinition) → **Verbindung** (organisationsbezogene Instanz mit Anmeldedaten und Konfiguration) → **Gerät** (über die Verbindung registriert und an die Datenpipeline des Servers gebunden). Das Hinzufügen von Unterstützung für ein neues Protokoll erfordert nicht mehr Entwicklung auf Plattformebene — es erfordert einen neuen Connector-Typ.

**Verfügbare Connectoren**

* **LoRaWAN (integrierter LNS)** — Kilo IoT enthält einen integrierten LoRaWAN Network Server, der Geräteaktivierung, Uplink- und Downlink-Routing, Deduplizierung und Schlüsselverwaltung übernimmt. Keine externe LNS-Infrastruktur erforderlich.
* **Vehicle Tracker (OBD2/CAN)** — Speziell für Flotten- und Asset-Überwachungshardware entwickelt. Über 2.000 Fahrzeug-Tracker-Modelle sind vorkonfiguriert. Die Registrierung erzeugt einen dedizierten Ingestion-Endpunkt pro Gerät.

Verbindungen sind organisationsbezogen mit protokollspezifischer Konfiguration. LoRaWAN-Verbindungen erfordern Geräte-EUI, Anwendungsschlüssel, Frequenzband und Gerätekategorie. Tracker-Verbindungen erfordern Gerätekennung, Telefonnummer und Hardwaremodell.

**Auswirkungen auf die Skalierbarkeit**

Unter der vorherigen Architektur erforderte jedes neue Protokoll durchgängige Änderungen an der Ingestion-Pipeline des Servers. Das Connector-Modell entkoppelt die Protokollverarbeitung vom zentralen Datenpfad. Neue Geräteprotokolle werden als Connector-Definitionen eingeführt — ein Konfigurationsdatensatz und eine optionale Verwaltungsoberfläche — ohne die Transport- oder Normalisierungsschichten der Plattform zu ändern.

***

**Gerät-Lebenszyklus und Datennormalisierung**

Jedes auf dem Kilo IoT Server registrierte Gerät wird als Digital Twin dargestellt — ein persistentes, zusammengesetztes Modell, das die Identität, physische Bindung, Sensor-Konfiguration, Messhistorie und operative Metadaten des Geräts erfasst. Die bewusste Trennung des logischen Gerätemodells von der physischen Hardwarebindung schafft die Grundlage für Geräteemulation — und ermöglicht es Teams, eine vollständige Bereitstellung mit emulierten Geräten zu entwerfen und zu validieren, bevor physische Hardware schrittweise in Betrieb genommen wird.

**Strukturierte Geräteverwaltung**

Die Gerätekonfiguration folgt einem vierstufigen Workflow:

1. **Identität** — Einen Namen zuweisen und Referenzfotos für die Identifikation im Feld während Wartung oder Inbetriebnahme anhängen.
2. **Verbindungszuordnung** — Das Gerät mit einem Connector verknüpfen. Protokoll-Anmeldedaten angeben: EUI und Anwendungsschlüssel für LoRaWAN-Geräte oder Gerätekennung und Modell für Fahrzeug-Tracker.
3. **Metrikkonfiguration** — Sensorvorlagen auswählen und Roh-Payload-Felder auf normalisierte Messparameter abbilden. Die Plattform zeigt die Live-Gerätenutzlast — jeden Feldnamen, aktuellen Wert und Zeitstempel der letzten Übertragung — direkt in der Konfigurationsoberfläche an.
4. **Ereignishistorie** — Zugriff auf den vollständigen Roh-Telemetriestrom mit Datumsbereichsfilterung für Diagnose und Inbetriebnahmeverifikation.

**Inline-Nutzlastnormalisierung**

Diese Funktion beseitigt einen kritischen betrieblichen Engpass. In früheren Versionen erforderte die Integration eines Geräts von einem nicht unterstützten Hersteller eine Supportanfrage, um feldbezogene Zuordnungen auf Datenbankebene zu erstellen. Prototyp-Hardware und Geräte in aktiver Entwicklung konnten überhaupt nicht integriert werden.

Kilo IoT Server 3.0.0 stellt die Roh-Ingestion-Nutzlast in der Metrikkonfigurationsoberfläche bereit. Bediener sehen jedes vom Gerät übertragene Feld und ordnen jedes einzelne in einem strukturierten Auswahlworkflow einer Sensorvorlage zu:

1. Eine Sensorvorlage aus der Bibliothek der Organisation auswählen (z. B. „Umgebungstemperatur“, Einheit: °C, Wertetyp: FLOAT)
2. Die Vorlage mit dem Roh-Payload-Feld verknüpfen (z. B. Feld `„t“` der Umgebungstemperatur zuordnen)
3. Die Zuordnung wird sofort wirksam — normalisierte Daten fließen zu Dashboards, Automatisierungsregeln, Alarmauswertungen und historischen Abfragen

Die Funktion erstreckt sich auf jede Hardware, von der der Server Daten empfangen kann — einschließlich Geräten in der Vorproduktionsvalidierung, bei denen sich die Payload-Schemata noch weiterentwickeln, industrieller Sensoren von Nischenherstellern mit undokumentierten Telemetrieformaten und Legacy-Feldgeräten, die kodierte Kennungen statt beschreibender Feldnamen übertragen.

**Normalisierungsarchitektur**

Die Normalisierungspipeline ist als vierstufige Hierarchie strukturiert. An der Spitze, **Normalisierte Schlüssel** repräsentieren die Messdomäne — was gemessen wird (z. B. „Umgebungstemperatur“, „Versorgungsspannung“). **Sensorvorlagen** ordnen jeden Schlüssel technischen Einheiten, Wertgrenzen und Datenklassifizierung zu. **Sensoren** instanziieren Vorlagen auf bestimmten Geräten und ermöglichen so gerätespezifische Konfiguration. **Sensorzuordnungen** stellen die endgültige Verbindung zwischen einer Sensorinstanz und dem Rohfeldnamen in der Gerätenutzlast her. Diese Taxonomie ist auf Organisationsebene definiert und wird konsistent über jedes Gerät in der Bereitstellung hinweg durchgesetzt — unabhängig vom Hardwareanbieter oder der Firmware-Version.

**Zusätzliche Funktionen**

* Sensorvorlagenbibliotheken mit standardisierten Schlüsseln und Einheiten — einmal definieren, in jeder Bereitstellung anwenden
* Inline-Payload-Zuordnung — keine Support-Tickets, keine blockierenden Abhängigkeiten für die Bereitstellung
* Hardwarebindung und -umbindung — physische Geräte austauschen, ohne Konfiguration oder Telemetriehistorie zu verlieren
* Gerätefotos — Referenzbilder für Außendienstteams und Asset-Management anhängen
* Bediener-Metadaten — bereitstellungsspezifische Attribute für Filterung, Gruppierung und Berichterstattung hinzufügen
* Markierte Geräte — häufig aufgerufene Geräte für die schnelle Navigation anheften

***

**Visualisierung und Überwachung**

Kilo IoT 3.0.0 liefert ein vollständig vom Bediener konfigurierbares Dashboardsystem. Organisieren Sie Überwachungsansichten in Ordnerhierarchien — nach Standort, Gebäude, Abteilung oder jeder beliebigen operativen Taxonomie. Jedes Widget unterstützt mehrere Datenquellen, benutzerdefinierte Messwertauswahl und bedingte visuelle Formatierung, die durch vom Bediener definierte Regeln gesteuert wird.

**Bedingte Formatierung, gesteuert durch Schwellenwerte**

Widgets zeigen Daten nicht mehr mit statischem Styling an. Bediener definieren an Messwerte gebundene Anzeigebedingungen, die sich an den operativen Kontext anpassen. Derselbe Temperatursensor kann je nach Einsatzort unterschiedliche visuelle Indikatoren auslösen:

* In einem Wareneingangsbereich eines Lagers: 20 °C werden mit einem Standardindikator dargestellt (innerhalb der Spezifikation)
* In einer Kühlzelle: 20 °C werden mit einem kritischen Indikator dargestellt (Compliance-Verstoß)

Bedingungen unterstützen numerische Bereiche, Zeichenfolgenabgleich und Boolesche Auswertung. Mehrere Bedingungen pro Messwert werden in Prioritätsreihenfolge ausgewertet — die erste Übereinstimmung bestimmt den visuellen Zustand. Bediener konfigurieren benutzerdefinierte Einheiten, Symbolik und Farbzuteilungen pro Messwert.

**Anlagenbild-Widget (Neu)**

Stellen Sie einen Grundriss oder ein Anlagenlayout als interaktive Überwachungsfläche bereit. Positionieren Sie Sensorindikatoren an präzisen Koordinaten auf dem Bild. Jeder Indikator zeigt Live-Telemetrie an und wendet in Echtzeit bedingte Formatierung an — und bietet so unmittelbare räumliche Orientierung über die Betriebsbedingungen in der gesamten Anlage.

Das Bild-Widget unterstützt mehrere Ebenen für Gebäude mit mehreren Stockwerken oder segmentierte Anlagen. Wechseln Sie zwischen Etagen, um von einem einzigen Dashboard-Widget aus vollständige Situationsübersicht zu behalten.

**Anzeige des Echtzeitwerts**

Überwachen Sie aktuelle Gerätewerte mit konfigurierbaren numerischen, Donut- oder Kreisdiagramm-Visualisierungen. Aggregieren Sie mehrere Geräte und Messwerte in einem einzigen Widget. Bedingte Formatierung hebt Abweichungen von den erwarteten Betriebsparametern hervor.

**Historische Analyse**

Untersuchen Sie Telemetrie-Trends mit konfigurierbaren Linien- und Balkendiagrammen. Definieren Sie Schwellenwertbereiche, die Datenbereiche farblich codieren — so wird sofort sichtbar, wenn Messungen in Warn- oder Kritisch-Bereiche eintreten. Mehrere Datenquellen mit anpassbaren Zeitfenstern unterstützen sowohl Echtzeitüberwachung als auch retrospektive Analyse.

***

**Produktionsreife Automatisierungs-Engine**

Kilo IoT 3.0.0 führt eine unternehmensreife Automatisierungs-Engine ein, die auf BPMN (Business Process Model and Notation) basiert. Die Engine ist auf Produktionszuverlässigkeit ausgelegt — jede Regel wird versioniert, vor der Bereitstellung validiert und ohne Datenverlust rückgängig machbar.

**Visuelles Workflow-Design**

Automatisierungsregeln werden auf einer BPMN-konformen visuellen Leinwand erstellt. Bediener konstruieren Verarbeitungsabläufe, indem sie typisierte Knoten anordnen und verbinden: Startereignisse empfangen Sensordaten, exklusive Gateways bewerten Verzweigungsbedingungen, Skriptaufgaben führen Transformationslogik aus, Anreicherungsknoten korrelieren Daten über mehrere Geräte hinweg, Alarmknoten lösen die Benachrichtigungspipeline aus, und Rand-Fehlerereignisse bieten fehlertolerantes Ausnahme-Routing.

**CEL-Ausdruckssprache**

Regelbedingungen und Transformationen werden in CEL (Common Expression Language) formuliert — einer kompilierten, sandboxierten Ausdruckssprache von Google. CEL ermöglicht es Bedienern, komplexe Bedingungen mit mehreren Variablen auszudrücken, die die Fähigkeiten einfacher Schwellenwertvergleiche übersteigen:

```
sensor.co2_ppm > 1000 && sensor.ventilation_status == "off"
sensor.cold_storage_temp > -15 || sensor.door_open_duration > 300
sensor.vibration_rms > 4.5 && time.now.hour >= 6 && time.now.hour <= 22
```

CEL wird deterministisch ausgewertet, ohne Dateisystemzugriff, ohne unbeschränkte Iteration und ohne Seiteneffekte. Technische Referenz: [cel.dev](https://cel.dev).

**Schutz vor gleichzeitiger Bearbeitung**

Die Plattform erzwingt exklusive Bearbeitungssperren für aktive Regeln. Teammitglieder sehen den aktuellen Sperrinhaber und die Sperrdauer. Ein Sitzungs-Timeout löst vor dem Freigeben der Sperre ein automatisches Speichern aus. Organisationsadministratoren können Sperren zwangsweise aufheben, wenn es die operative Dringlichkeit erfordert — zwangsweise Aufhebungen bewahren alle ausstehenden Änderungen.

**Kontinuierliches Auto-Speichern**

Der Regelzustand wird automatisch in konfigurierbaren Intervallen, beim Schließen des Editors und vor Ablauf der Sitzung gespeichert. Manuelles Speichern ist jederzeit verfügbar. Ein persistenter Statusindikator zeigt den aktuellen Speicherstatus an — in Bearbeitung, bestätigt oder Fehler — und stellt sicher, dass Bediener immer wissen, ob ihre Arbeit gespeichert ist.

**Versionskontrolle und Rollback**

Jeder Speichervorgang erzeugt einen separaten Versionseintrag. Bediener können Versionen kennzeichnen, zwei beliebige Revisionen vergleichen und eine frühere Version mit einer einzigen Aktion wiederherstellen. Die Wiederherstellung von Versionen ist nicht destruktiv — die ersetzte Version bleibt in der Verlaufstimeline erhalten.

**Validierte Build- und Bereitstellungspipeline**

Regeln werden durch einen Build-Schritt, der eine strukturelle Validierung durchführt — Vollständigkeit des Ablaufs, Korrektheit der Ausdrücke und Integrität der Verbindungen überprüft — in versionierte Bereitstellungsartefakte kompiliert. Eine fehlgeschlagene Validierung verhindert die Erstellung des Artefakts. Validierte Artefakte werden mit einer einzigen Aktion in die Laufzeitumgebung bereitgestellt. Laufende Regeln können sofort gestoppt werden. Frühere Builds bleiben für ein sofortiges Rollback verfügbar.

**Wiederherstellung bei Soft-Delete**

Gelöschte Regeln werden in einer Wiederherstellungswarteschlange mit konfigurierbarer Aufbewahrungsfrist aufbewahrt. Jede Regel kann vor Ablauf des Aufbewahrungsfensters wieder in den aktiven Status zurückversetzt werden.

***

**Operative Alarmierung und Eskalation**

Kilo IoT 3.0.0 liefert ein strukturiertes Alarmverwaltungssystem, das Benachrichtigungen über konfigurierbare Eskalationsketten mit Multi-Channel-Zustellung weiterleitet.

**Zustellung mobiler Benachrichtigungen**

Native mobile Anwendungen für Android und iOS ermöglichen es Außendienstmitarbeitern und Bereitschaftsingenieuren, Push-Benachrichtigungen direkt auf ihren Geräten zu erhalten. Kritische operative Alarme erreichen das verantwortliche Team, ohne dass Zugriff auf einen Arbeitsplatzrechner erforderlich ist.

**Zentrale Alarmkonsole**

Alle aktiven und historischen Alarme werden in einem einheitlichen Posteingang konsolidiert und nach Schweregrad sortiert. Jeder Alarm verlinkt direkt auf die zugrunde liegende Automatisierungsregel. Bediener bestätigen und lösen Alarme aus der Konsole heraus auf, um die operative Verantwortlichkeit zu wahren.

**Schweregradbasierte Klassifizierung**

Alarmdefinitionen unterstützen fünf Schweregradstufen — Kritisch, Hoch, Mittel, Niedrig und Info — die jeweils das Eskalationsverhalten und die Zustellungsdringlichkeit steuern. Eskalationsrichtlinien definieren mehrstufige Benachrichtigungsketten: Empfänger, Zustellkanal und Verzögerungsintervall vor der Eskalation auf die nächste Stufe angeben.

**Zustellkanäle**

* **E-Mail** — Detaillierte Alarmnutzlasten, zugestellt in die Posteingänge der Bediener
* **SMS** — Zeitkritische Textbenachrichtigungen für Bereitschaftspersonal
* **Push** — Native mobile Zustellung auf Android- und iOS-Geräte

Für die Kanalaktivierung ist eine Verifizierung erforderlich — E-Mail-Bestätigungslink oder SMS-Validierungscode. Wiederholungsintervalle für Benachrichtigungen sind pro Alarm konfigurierbar, um Ermüdung der Bediener bei anhaltenden Alarmzuständen zu verhindern.

**Betriebspläne**

Wöchentliche Zustellfenster mit Zeitzonenbewusstsein steuern, wann Benachrichtigungen versendet werden. Nicht kritische Alarme werden während definierter Ruhezeiten unterdrückt. Gesammelte Alarme werden zugestellt, wenn der Zeitplan wieder einsetzt, sodass keine Ereignisse stillschweigend verworfen werden.

***

**Multi-Tenant-Governance und Compliance**

Kilo IoT 3.0.0 implementiert ein umfassendes Modell zur organisatorischen Isolierung mit Attributbasierter Zugriffskontrolle und unveränderlicher Aktivitätsprotokollierung.

**Organisatorische Isolierung**

Jedes Benutzerkonto wird bei der Registrierung mit einer persönlichen Organisation bereitgestellt. Zusätzliche Organisationen können für Kundenbereitstellungen, Projektteams oder operative Abteilungen erstellt werden. Jede Organisation verwaltet vollständig isolierte Ressourcen — Geräte, Connectoren, Dashboards, Automatisierungsregeln, Alarmkonfigurationen und Abonnementabrechnungen existieren innerhalb strikter Mandantengrenzen.

**Attributbasierte Zugriffskontrolle (ABAC)**

Kilo IoT ersetzt die traditionelle rollenbasierte Zugriffskontrolle durch ABAC — ein dynamisches Berechtigungsmodell, das Zugriffsentscheidungen anhand mehrerer kontextueller Attribute bewertet: Organisationsmitgliedschaft, Autorisierung auf Seitenebene, Ressourceneigentum und Bedienerkontext. Ein Systemintegrator kann Bearbeitungsrechte für ein einzelnes Kunden-Dashboard erhalten, ohne andere Organisationsressourcen offenzulegen. ABAC beseitigt den Rollenwildwuchs und die Berechtigungs-Workarounds, die traditionelle RBAC-Bereitstellungen kennzeichnen.

Bediener werden Organisationen mit präzise abgegrenzten Berechtigungen eingeladen, die auf Seiten- und Ressourcenebene zugewiesen werden.

Organisationsadministratoren konfigurieren Mandanteneinstellungen einschließlich Anzeigename, Unternehmens-E-Mail-Identität und Branding. Benutzer mit Mitgliedschaft in mehreren Organisationen wechseln zwischen ihnen ohne erneute Authentifizierung.

**Unveränderlicher Audit-Trail**

Jedes Ereignis der Organisationsmitgliedschaft wird aufgezeichnet: Versand der Einladung, Annahme durch den Benutzer, Änderung der Berechtigungen und Entfernung des Benutzers. Das Audit-Log unterstützt Suche und Filterung nach Akteur und Ereigniskategorie. Der Zugriff auf Audit-Datensätze wird durch eine dedizierte Berechtigung geregelt — nur autorisierte Bediener können organisatorische Aktivitäten prüfen. Dies bietet die Nachverfolgbarkeit, die für regulatorische Konformität und interne Sicherheitsprüfungen erforderlich ist.

**Abonnementverwaltung**

* Evaluierungsstufe — bis zu 2 Geräte ohne Zahlungsanmeldung bereitstellen
* In der Verwaltungsoberfläche angezeigte, planbedingt erzwungene Ressourcenlimits
* Versionsverlaufsaufbewahrung durch die Abonnementstufe gesteuert
* Stripe-integrierte Abrechnung und Zahlungsabwicklung

</details>

<details>

<summary>Scale Log. Veröffentlichung 2.2.1</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-c398fc7962fca2778b9d60925d9e3c4fdfd737cc%2FKilo_Scale_Log_Release_2.2.1.jpg?alt=media" alt=""><figcaption></figcaption></figure>

### Größere Änderungen

#### Stripe-Bankkartenintegration

**Funktionen**

* Kartenverknüpfung: Benutzer können jetzt ihre Bankkarte über Stripe verbinden, um kostenlose Testabonnements zu aktivieren
* Kartenverwaltung: Benutzer können verknüpfte Karten in ihrem Stripe-Konto anzeigen und verwalten
* Kartenentfernung: Benutzer haben jederzeit die Möglichkeit, ihre Bankkarte zu entkoppeln/zu entfernen

**Sicherheit**

* Alle Zahlungsdaten werden sicher über Stripes PCI-konforme Infrastruktur verarbeitet

### Kleinere Änderungen

#### Fehlerbehebung bei der Stripe-Abonnementverwaltung

**Behoben**

* Benutzer haben nach dem Upgrade des Abonnementplans jetzt nur noch eine aktive Bestellung
* Die Logik zum Ersetzen der Bestellung wurde korrigiert, um sicherzustellen, dass die vorherige Abonnementbestellung beim Upgrade ordnungsgemäß storniert wird

**Verbessert**

* Der Ablauf zum Upgrade des Abonnements wurde verbessert, um den Übergang zwischen Tarifplänen ordnungsgemäß auszuführen
* Die Stripe-Bestellverwaltung wurde verbessert, um saubere Abonnementänderungen sicherzustellen
* Die Behandlung des Bestelllebenszyklus während Upgrades von Tarifplänen aktualisiert

**Technische Änderungen**

* Korrekte Logik für Stornierung/Ersetzung von Bestellungen während Abonnement-Upgrades implementiert
* Validierung hinzugefügt, um doppelte aktive Bestellungen für denselben Benutzer zu verhindern

#### Bereinigung technischer Schulden im Frontend

**Refaktoriert**

* Zentrale UI-Komponenten: Button, Tab, Text Field, Select, Typography
* Verbesserte Konsistenz und Wartbarkeit in der gesamten Komponentenbibliothek

**Entfernt**

* Veraltete Legacy-Komponenten
* Nicht verwendete Übersetzungsschlüssel

**Verbessert**

* Verbesserte Wiederverwendbarkeit von Komponenten und Typsicherheit
* Reduzierte Bundle-Größe
* Sauberere Komponenten-APIs

</details>

<details>

<summary>Scale Log. Veröffentlichung 2.2.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-efe3a0c11e0ad3a558f706ceb54c0af7056511f2%2FKilo_Scale_Log_Release_2.2.0.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### **Scale Log 2.2.0 ist eine der größten Veröffentlichungen des Jahres — und dieses Weightlog ist eine großartige Möglichkeit, das Jahr stark abzuschließen.**

Dieses Update führt mehrere wichtige Plattformfunktionen ein, die Kilo in eine neue Phase der Skalierbarkeit führen — Teams erhalten zuverlässigere Alarmierung, bessere Dashboard-Organisation und stärkere Werkzeuge für die Verwaltung von Multi-User-Bereitstellungen.

Am wichtigsten ist, **KILO 2.2.0 verbessert den täglichen Betrieb realer Bereitstellungen**: Benutzer können kritische Alarme jetzt über **SMS**, Dashboards in einer **Ordnerhierarchie**, organisieren und Organisationen mit mehr Kontrolle durch Eigentumsübertragungen und bearbeitbare Einstellungen verwalten. Diese Änderungen machen Kilo im Feld zuverlässiger, teamübergreifend einfacher zu bedienen und mit wachsenden Bereitstellungen einfacher zu skalieren.\
\
Größere Änderungen

***

#### SMS als Benachrichtigungskanal hinzufügen

**Neue Funktion: SMS-Benachrichtigungsunterstützung**

Die Benachrichtigungszentrale unterstützt jetzt **SMS-Alarme**, sodass Benutzer wichtige Benachrichtigungen direkt auf ihrem Telefon erhalten können. Dies verbessert die Zuverlässigkeit bei zeitkritischen Ereignissen und gibt Teams einen weiteren Kanal, wenn E-Mails verzögert oder verpasst werden.

**SMS-Benachrichtigungsfunktionen**

* SMS-Benachrichtigungskanal mit Telefonverifizierungsablauf
* Eingabefeld für Telefonnummer und Oberfläche für Bestätigungscode
* Umschalter zum Aktivieren/Deaktivieren von SMS-Benachrichtigungen
* Fehlermeldungen für ungültige oder abgelaufene Bestätigungscodes
* Erkennung doppelter Telefonnummern

**So verwenden Sie es**

1. Navigieren Sie zu **Benachrichtigungen → Einstellungen**
2. Im **SMS-Benachrichtigungen** Abschnitt klicken Sie auf **„+ Telefonnummer hinzufügen“**
3. Geben Sie Ihre Telefonnummer ein und klicken Sie auf **Speichern**
4. Geben Sie den an Ihr Telefon gesendeten Bestätigungscode ein
5. SMS-Benachrichtigungen umschalten **ein/aus** bei Bedarf

Dieses Update ermöglicht es Benutzern, kritische Warnungen direkt per SMS zu erhalten, und erhöht so die Zuverlässigkeit und Flexibilität über alle Bereitstellungen hinweg.

***

#### SMS-Add-on

**Neue Funktion: Kauf von SMS-Guthaben (Stripe)**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2FGIOeyFYCJtBFWpxnPKQU%2Fimage.png?alt=media&amp;token=087d5fb8-c4a7-4f6f-bfd9-2b74154693ab" alt=""><figcaption></figcaption></figure>

Kilo unterstützt jetzt den direkten Kauf von SMS-Guthaben innerhalb der Plattform. Dadurch können Teams die SMS-Benachrichtigung ohne zusätzlichen betrieblichen Aufwand skalieren und die Nutzung durch ein einfaches Kontostandssystem besser planbar machen.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Ft3FNbnMrIO3N1iepahLD%2Fimage.png?alt=media&amp;token=9c8c5ba4-59dd-4655-bb13-316cb0db8f4e" alt=""><figcaption></figcaption></figure>

**Highlights der SMS-Kauf-Funktion**

* **Flexible Mengenwahl** — wählen Sie die genaue Anzahl der zu kaufenden SMS-Nachrichten
* **Transparente Kostenberechnung** — Stückpreis pro SMS und Gesamtkosten werden vor dem Kauf angezeigt
* **Sichere Transaktionen** — Zahlungen werden über Stripe abgewickelt
* **Sofortige Bestätigung** — nach erfolgreicher Zahlung erscheint ein Bestätigungsdialog
* **Aktualisierung des Live-Kontostands** — SMS-Kontostand wird in Echtzeit aktualisiert

**So verwenden Sie es**

1. Navigieren Sie zu **Benachrichtigungen → SMS-Einstellungen**
2. Wählen Sie die Anzahl der SMS-Guthaben aus, die Sie kaufen möchten
3. Prüfen Sie den Stückpreis und die Gesamtkosten
4. Zahlung über Stripe abschließen
5. Die Bestätigung und den aktualisierten SMS-Kontostand anzeigen

***

#### Aktualisierungen zu Abonnement und Abrechnung

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2FHk8tl69uFDJxexivuvV8%2Fimage.png?alt=media&amp;token=3f13ab54-5814-452f-b198-e1933d9b9281" alt=""><figcaption></figcaption></figure>

**Kostenloser Standardtarif**

KILO 2.2.0 verbessert die Verwaltung von Abonnements, sodass Onboarding und Tarif-Upgrades klarer und besser vorhersehbar sind.

**Verbesserungen beim Abonnement**

* Neue Benutzer werden automatisch dem **kostenlosen Standardtarif** bei der Registrierung zugewiesen
* Details zum kostenlosen Tarif sind jetzt im Bereich **Abrechnung / Abonnement** sichtbar
* Benutzer können jederzeit vom kostenlosen Tarif auf ein kostenpflichtiges Abonnement upgraden
* Nach Ablauf eines kostenpflichtigen Abonnements werden Benutzer automatisch auf den kostenlosen Tarif herabgestuft
* Nach der Herabstufung gelten die Funktionsbeschränkungen gemäß dem kostenlosen Tarif

***

#### Organisationseinstellungen ändern

**Verbesserungen der Organisationsverwaltung**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2F6LA5jO7IXzYszYuFladw%2Fimage.png?alt=media&amp;token=55df328c-1a2f-46ca-a759-f18147ffa044" alt=""><figcaption></figcaption></figure>

Eigentümer von Organisationen haben jetzt eine verbesserte Kontrolle über Organisationseinstellungen und Eigentümerschaft, was die Verwaltung lang laufender Bereitstellungen und Teamwechsel erleichtert.

**Neue Funktionen**

* **Bearbeitung des Organisationsnamens** direkt in den Organisationseinstellungen
* **Eigentumsübertragung** an einen anderen Benutzer über die Mitgliederliste der Organisation
* **E-Mail-Einladungs-Workflow** zur Annahme der Eigentumsübertragung
* Die Einladung zur Eigentumsübertragung läuft ab nach **1 Woche**
* **Erneute Authentifizierung erforderlich** für den neuen Eigentümer während der Annahme
* Nach der Annahme wird dem neuen Eigentümer die **Editor-Rolle** mit vollständigen Administrationsrechten
* Änderungen am Organisationsnamen und an der Eigentümerschaft müssen ausdrücklich **gespeichert werden** damit sie wirksam werden

***

#### Dashboard-Hierarchie

**Verbesserte Verwaltung und Anzeige von Dashboards**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2FqyFjaiK1YHtOzOY4estW%2Fimage.png?alt=media&amp;token=fc473333-80c3-47d2-95d0-a3d04a539792" alt=""><figcaption></figcaption></figure>

Das Änderungsprotokoll 2.2.0 führt eine neue Dashboard-Struktur ein, die für Benutzer entwickelt wurde, die mehrere Bereitstellungen oder operative Ansichten verwalten.

**Verbesserungen am Dashboard**

* Dashboards können jetzt in einer **zweistufigen Hierarchie** (Ordner → Dashboards)
* Ordner werden über das **Einstellungen** Symbol neben der Schaltfläche „Dashboard hinzufügen“ im linken Menü erstellt
* Dashboards können innerhalb der Ordnerstruktur hinzugefügt, gelöscht und geändert werden
* Dashboards können mit der **Bearbeiten** Schaltfläche
* angeordnet und neu strukturiert werden

Widgets können auf jedem Dashboard platziert werden, unabhängig von seinem Ordnerstandort

***

#### Kleinere Änderungen

**Informationen zu Admin-Kontakten**

* Tooltips für Berechtigungen zeigen jetzt **Kontaktdaten von Administratoren**, damit Benutzer bei erforderlichen Berechtigungen schnell Zugriff oder Unterstützung anfordern können.

</details>

<details>

<summary>Scale Log. Version 2.0.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-a368ee7c58587b82e8bf0f936f2da83fd05ca9f0%2FKilo_Scale_Log_Release_2.0.0.jpg?alt=media" alt=""><figcaption></figcaption></figure>

#### Größere Änderungen

**Benutzerdefinierte Dashboards**

* Es wurde die Möglichkeit hinzugefügt, benutzerdefinierte Dashboards für die personalisierte Datenüberwachung und die Übersicht über mehrere Geräte und Parameter auf einem Dashboard zu erstellen.

**Benutzer können jetzt:**

* Ein neues Dashboard hinzufügen.
* Ein Dashboard löschen, wenn es nicht mehr benötigt wird.
* Widgets zu Dashboards hinzufügen.
* Hinzugefügte Widgets können von verschiedenen Geräten stammen.
* Widgets sind jetzt verschiebbar und anpassbar.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-3a8f21d3c6678850d7ba576f281328bf55bcd984%2Fwid2.gif?alt=media" alt=""><figcaption></figcaption></figure>

**Einklappbares Menü**

* Ein einklappbares Menü wurde hinzugefügt, das auf einen schmalen Streifen mit Symbolen reduziert werden kann.
* Benutzer können das Menü mithilfe des Hover-Pfeils ein- oder ausklappen und so mehr Bildschirmfläche für Hauptinhalte oder benutzerdefinierte Dashboards freigeben.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-aed29bca0dda74e046f845305c292b9fe1c74b4b%2Fwid.gif?alt=media" alt=""><figcaption></figcaption></figure>

**Platzhalter & Direkt-Upload für Geräte- und Gateway-Fotos**

* Es wurde ein Platzhalterbild für Geräte ohne Fotos hinzugefügt, um anzuzeigen, dass ein Foto hochgeladen werden kann.
* Benutzer können Fotos jetzt direkt von der Geräte- oder Gateway-Seite aus hochladen, ohne zu den Einstellungen navigieren zu müssen.
* Upload-Optionen über Avatar, Dropdown-Menü oder Einstellungen verfügbar.

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2FQLdFBPvoAVYTiYPM9D4Z%2Fplaceholder.png?alt=media&amp;token=ed8e5799-77a1-45a4-a673-7055fed4cc91" alt=""><figcaption></figcaption></figure>

#### Kleinere Änderungen

**Korrektur des E-Mail-Fehlers bei inaktiven Regeln**

* Ein Problem wurde behoben, bei dem Benachrichtigungen weiterhin gesendet wurden, nachdem eine Regel auf inaktiv gesetzt wurde.
* Inaktive Regeln stoppen jetzt korrekt E-Mail-Benachrichtigungen und markieren Benachrichtigungen als behoben.

**Korrektur des E-Mail-Fehlers beim Löschen von Regeln**

* Ein Problem wurde behoben, bei dem Benachrichtigungen weiterhin gesendet wurden, nachdem eine Regel gelöscht wurde.

**Korrektur der GPS-Tracker-URL**

* Die Geräte-URL verweist jetzt korrekt auf die Produktionsumgebung.

**Korrektur des Anheftens von Widgets**

* Ein Problem wurde behoben, bei dem Widgets auf Geräteseiten nicht angeheftet werden konnten

**Zugriffsbeschränkung auf Seiten bei leeren Abonnements**

* Das Frontend sperrt jetzt den Zugriff auf Seiten, wenn der Benutzer kein aktives Abonnement hat oder die Abonnement-/Daten-API leere Werte zurückgibt.
* Verhindert, dass Benutzer mit Funktionen interagieren, die ein gültiges Abonnement erfordern.

**Korrektur der Erstellung von Nicht-LoRa-Geräten**

* Ein Problem wurde behoben, bei dem Benutzer keine Nicht-LoRa-Geräte hinzufügen konnten, wenn isEnabledDevicePhoto deaktiviert war.
* Benutzer können jetzt Nicht-LoRa-Geräte unabhängig von der Einstellung für Gerätefotos hinzufügen.

</details>

<details>

<summary>Scale Log. Version 1.0.0</summary>

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-826ac0608e0e514f3fb809548b32028df5384b30%2FScale_Log_Release_1.0.0.jpg?alt=media" alt=""><figcaption></figcaption></figure>

### Veröffentlichte Funktionen

**Hochladen von Geräte- und Gateway-Fotos**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2FvNgPctZQDizFKgYbayoS%2FScreenshot%202025-10-06%20at%2018.15.24.png?alt=media&amp;token=6f8b3696-bb69-4237-b920-d6dd39670294" alt=""><figcaption></figcaption></figure>

* Benutzer können jetzt bis zu 3 Fotos für Geräte und Gateways hochladen (während der Erstellung oder über die Geräte-/Gateway-Seite).
* Hochgeladene Fotos sind auf der Geräteseite und beim Erstellen von Regeln sichtbar.
* Upload-Schaltfläche mit „+“-Symbol und die Möglichkeit, alle Fotos in erweiterten Informationen anzuzeigen, wurden hinzugefügt.
* Fotos können in den Einstellungen gelöscht werden (Löschsymbol beim Darüberfahren, auf Mobilgeräten immer sichtbar).
* Verbesserte Benutzererfahrung: Die gesamte Geräte-/Gateway-Karte kann jetzt per Klick erweitert oder reduziert werden.

### Kleinere Änderungen

**Korrektur der Anzeige des Benachrichtigungssymbols**

* Ein Problem wurde behoben, bei dem das Benachrichtigungssymbol bei mehr als 10 Benachrichtigungen eines Benutzers nicht vollständig angezeigt wurde.
* Das Symbol wird jetzt unabhängig von der Anzahl der Benachrichtigungen korrekt angezeigt.

**Korrektur der Gateway-Einreichung**

<figure><img src="https://895787959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2FoSIGHGizBCWxFpCkaD0s%2Fimg.png?alt=media&amp;token=45bd918c-78e2-4b3f-b2fe-d4ae03df982f" alt=""><figcaption></figcaption></figure>

* Die Gateway-Einreichung funktioniert jetzt korrekt ohne serverseitige Zugriffsfehler.

**Korrektur der Fehlermeldung**

* Eine falsche Fehlermeldung beim Hinzufügen von Gateways wurde behoben.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kiloiot.io/kilo-docs-de/faq/changelog.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.