Änderungsprotokoll

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

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 → Metrikenverfü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äteauswä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.

→ Ein Auslöser für mehrere Geräte

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ücksetzenlegen 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.

→ Auslösezeitpunkt

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 → Metrikenverwaltet. 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.

→ Metriken

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.

→ Abrechnung und Rechnungen

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.

→ Balkendiagramm

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.

→ Mit KI bauen

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.

→ Chats und KI-Zugriff verwalten

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.

→ MCP-Server

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.

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

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.

→ Emulator-Connector

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.

→ Physische KI-Plattform · → Mit KI bauen

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.

→ MCP-Server

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.

→ Emulierte Geräte

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.

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-Bereichakzeptiert, 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.

→ MIOTY-Basisstationen

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.

→ Audit Trail

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.

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

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) 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? · → Mioty-Connector · → Mioty-Basisstationen · → Mioty-Blueprints

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

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 Datenoder 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

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ügenkonfigurierst, 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

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 · → IoT-KI-Assistent

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 · → Widgets hinzufügen

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.

3.6.0 ist die Version, in der der Kilo IoT Server KI-firstwird. Der integrierte Assistent — AIoTkü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

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

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, 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 Brewund wurde intern als eigenständiges Produkt entwickelt, nicht als Chatbot, der um die API von jemand anderem gewickelt wurde.

→ IoT-KI-Assistent

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 · → Gerätebefehle

Ö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 · → API-Schlüssel

iFrame-Widget — externer Kontext auf dem Dashboard

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

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

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.

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

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

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

Steuer-Widgets — Geräte vom Dashboard aus bedienen

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.

→ Übersicht über Steuer-Widgets

Text- und Radial-Gauge-Widgets

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 · → Radial-Gauge-Anzeige

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

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 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

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

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 Stockwerkeenthalten, 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

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

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

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

Ü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

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.

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

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

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

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

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.

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

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:

CEL wird deterministisch ausgewertet, ohne Dateisystemzugriff, ohne unbeschränkte Iteration und ohne Seiteneffekte. Technische Referenz: 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

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

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)

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.

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

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

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

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.

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.

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.

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.

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.

Veröffentlichte Funktionen

Hochladen von Geräte- und Gateway-Fotos

• 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

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

Korrektur der Fehlermeldung

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