DE102012224393A1 - App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes - Google Patents

App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes Download PDF

Info

Publication number
DE102012224393A1
DE102012224393A1 DE201210224393 DE102012224393A DE102012224393A1 DE 102012224393 A1 DE102012224393 A1 DE 102012224393A1 DE 201210224393 DE201210224393 DE 201210224393 DE 102012224393 A DE102012224393 A DE 102012224393A DE 102012224393 A1 DE102012224393 A1 DE 102012224393A1
Authority
DE
Germany
Prior art keywords
app
interaction device
apps
core component
building
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE201210224393
Other languages
English (en)
Inventor
Roland Eckl
Franz Marquart
Wolfgang Hass
Asa MacWilliams
Thomas Riffel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE201210224393 priority Critical patent/DE102012224393A1/de
Publication of DE102012224393A1 publication Critical patent/DE102012224393A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426Programming the control sequence
    • HELECTRICITY
    • H05ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05BELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10Controlling the light source
    • H05B47/175Controlling the light source by remote control
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/23Pc programming
    • G05B2219/23121Display graphics with corresponding text
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/23Pc programming
    • G05B2219/23132Multifunction display
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/23Pc programming
    • G05B2219/23304Download program from host
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/23Pc programming
    • G05B2219/23377Touch screen, with representation of buttons, machine on screen
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/23Pc programming
    • G05B2219/23378Touch sensitive key
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/26Pc applications
    • G05B2219/2642Domotique, domestic, home control, automation, smart house

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)

Abstract

Interaktionsgerät (10, 10a, 10b) für eine Gebäudeinfrastruktur umfassend: einen Mikrocontroller (12), ein Benutzerinterface (14), eine oder mehrere Kommunikationsschnittstellen (16, 18) und eine Kernkomponente (20); wobei die Kernkomponente (20) durch eine App (26, 28) nutzbar ist; wobei die Kernkomponente (20) und die App (26, 28) durch den Mikrocontroller (12) ausführbar sind und die App (26, 28) in Form eines nachladbaren Programmblocks realisiert ist, der in den Mikrocontroller (12) einlesbar ist und dessen Verwaltung durch die Kernkomponente (20) durchführbar ist; wobei das Benutzerinterface (14) durch die App (26, 28) ausgestaltbar ist.

Description

  • Die vorliegende Erfindung bezieht sich auf das technische Gebiet der Anpassung eines Interaktionsgerätes an eine Gebäudeinfrastruktur.
  • Bislang gibt es in Gebäudeinfrastrukturen meist folgende Steuer-Möglichkeiten:
  • (1) Mechanische Schalter in verschiedenen Bauarten:
  • Gewöhnliche Schalter sind sehr eingeschränkt in ihrer Funktion; sie liegen etwa als einfache Taster oder Wipp-Schalter vor, können nur wenige einfache Signale verschicken. Die Bauart ist dabei vorgegeben, etwa: eine Wippe über die Gesamtfläche, zwei nebeneinander angeordnete Wippen, ein Drehrad, usw.
  • Rein äußerlich ist solchen Schaltern dabei ihre konkrete Funktionszuordnung (etwa Licht schalten, die Jalousie hoch- bzw. herunterfahren, oder die Zieltemperatur variieren) häufig nicht anzusehen, es sei dann sie werden direkt bei der Fertigung oder später manuell mit Piktogrammen und/oder Beschriftungen versehen.
  • Darüber hinaus gibt es Schalter mit einem oder mehreren kleinen Displays. Diese erlauben i.d.R. die Anzeige der dem zugehörigen Schaltelement zugeordneten Funktion bei einer festen Anordnung von Anzeigeelementen und Schaltern.
  • (2) Display-gestützte Schalter:
  • Ebenso können teilweise LCD-Display vorgefertigte Piktogramme ein- und ausblenden. Die visuelle Darstellung ist dabei sehr eingeschränkt. Manche Geräte erlauben auch beschränkte Textausgaben.
  • Diese Schalter sind jedoch in ihrer Funktion vorkonfiguriert, etwa als Lichtschalter oder Temperatur-Anzeige. Der Funktionsumfang ist daher sehr limitiert.
  • (3) Panele:
  • Darüber hinaus existieren größere Panels, welche jedoch allein schon vom Formfaktor her nicht mit gewöhnlichen Unterputz-Schaltern vergleichbar sind und i.d.R. ebenfalls einen festen Satz an Funktionsmöglichkeiten aufweisen. Sie sind also vorkonfiguriert für einen bestimmten Zweck, bzw. wurden explizit/manuell programmiert.
  • Ebenso gibt es Panele, welche über einen Browser Webseiten darstellen, welche wiederum erst die tatsächliche Funktionalität abbilden und das Steuern ermöglichen.
  • Alle diese Schalter haben somit gemein, dass sie in ihrer Funktionsvielfalt eingeschränkt (wenn nicht gar statisch nur für einen Zweck bestimmt) sind, darüber hinaus keine oder nur eingeschränkte Darstellungsmöglichkeiten (bzw. Individualisierung) bieten. Komplexere Geräte sind wiederum vom Formfaktor her nicht mit gewöhnlichen Schaltern vergleichbar und müssen darüber hinaus manuell programmiert werden.
  • Vertiefend zu den obigen Beschreibungen der bestehenden Lösungen sollen nachfolgend einige konkrete Beispiele aufgezeigt werden. Hierbei soll der Fokus auf display-basierten Schaltern und Panels liegen, da diese am ehesten Ähnlichkeiten zur vorgeschlagenen Lösung aufweisen.
  • Bekannt ist beispielsweise das Gerät Busch-PriOn (http://www.busch-jaeger.de/de/gebaeudesystemtechnik/prion.htm) der Firma Busch-Jaeger, mit einem TFT-Display mit rotierender Anzeige. Die Funktionen sind auf einen festen Satz begrenzt. Ebenso ist das Display nicht in einer Standard-Unterputzdose (z.B. nach DIN 49073) einbaubar.
  • Bekannt ist weiterhin das Gerät Bush-EnergyControl (http://www.busch-jaeger.de/de/produkte/energycontrol.htm) der Firma Busch-Jaeger welches zur Energie-Kontrolle ausgestaltet ist, sowie Busch-EnergyDisplay (http://www.busch-jaeger.de/de/produkte/energydisplay.htm) der Firma Busch-Jaeger welches eine reine Energie-Anzeige ist. Das Gerät zur Kontrolle als visuelles Panel hat ebenfalls nicht mehr den Formfaktor eines Schalters und passt somit in keine Standard-Unterputzdose. Das Anzeige-Gerät hingegen passt in eine Unterputzdose, hat jedoch eine sehr eingeschränkte Darstellung (vorgefertigte Piktogramme sowie bis zu vier numerische Zeichen). Beide Geräte sind dabei in ihrer Funktion vorbelegt und können nicht individuell mit neuen Funktionen versehen werden. Sie denen also ausschließlich der Energie-Steuerung bzw. -Anzeige.
  • Zudem sind aus http://myube.co/ und http://techcrunch.com/2012/10/02/ube-aims-to-make-home-automation-cheaper-with-ip-enabled-smart-devices-mobile-app/ Schalter und Dimmer bekannt, welche über WiFi oder über ein Smartphone bedient werden können.
  • Der vorliegenden Patentanmeldung liegt die Aufgabe zugrunde, in der Gebäudesteuerung neuartige Bedienelemente zu ermöglichen. Diese Bedienelemente sollen je nach Raumkontext verschiedene Funktionen ausführen können; ihre Benutzeroberflächen sollen ohne neuen physischen Installationsaufwand anpassbar sein.
  • Diese Aufgabe wird durch die in den unabhängigen Ansprüchen beschriebenen Lösungen gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in weiteren Ansprüchen angegeben.
  • Gemäß einem ersten Aspekt betrifft die Erfindung ein Interaktionsgerät für eine Gebäudeinfrastruktur. Das Interaktionsgerät umfasst einen Mikrocontroller, ein Benutzerinterface, eine oder mehrere Kommunikationsschnittstellen und eine Kernkomponente. Die Kernkomponente ist durch eine App nutzbar.
  • Die Kernkomponente und die App sind durch den Mikrocontroller ausführbar. Die App ist in Form eines nachladbaren Programmblock realisiert. Der nachladbare Programmblock ist in den Mikrocontroller einlesbar. Die Verwaltung des Programmblocks ist durch die Kernkomponente durchführbar. Das Benutzerinterface ist durch die App ausgestaltbar.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung ein Verfahren zum Anpassen eines Interaktionsgerätes an eine Gebäudeinfrastruktur. Dabei wird eine Kernkomponente auf dem Interaktionsgerät ausgeführt. Mindestens eine App wird durch die Kernkomponente verwaltet. Die App wird auf dem Interaktionsgerät ausgeführt. Die Kernkomponente wird durch die App genutzt. Ein Benutzerinterface des Interaktionsgerätes wird durch die App ausgestaltet.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung ein Gebäudeautomatisierungssystem, welches ein Interaktionsgerät gemäß einer bevorzugten Ausführungsform der Erfindung, eine Zentraleinheit und mindestens ein Feldgerät umfasst. Die Zentraleinheit ist beispielsweise ein zentraler Gebäudeautomatisierungs-Server oder ein lokaler Raumcontroller. Unter Feldgeräten sind zur Gebäudeautomatisierung geeignete Aktoren und Sensoren zu verstehen. Die Zentraleinheit ist mit einer der Kommunikationsschnittstellen des Interaktionsgerätes und mit dem mindestens einen Feldgerät verbunden. Das Benutzerinterface ist durch die App an das mindestens eine Feldgerät anpassbar.
  • Die Erfindung wird nachfolgend anhand eines Ausführungsbeispieles im Zusammenhang mit den Figuren ausführlicher erläutert. Dabei zeigen:
  • 1 ein Interaktionsgerät für eine Gebäudeinfrastruktur;
  • 2 ein Interaktionsgerät für eine Unterputzdose mit aufsteckbarem Display;
  • 3A3F Aufsätze mit verschiedenen Anordnungen für ein Ein- und Ausgabe sowie verschiedenen Anzeigeinhalten; und
  • 4 ein Gebäude mit einem Gebäudeautomatisierungssystem.
  • 1 zeigt ein Interaktionsgerät 10 für eine Gebäudeinfrastruktur. Das Interaktionsgerät umfasst einen Mikrocontroller 12, ein Benutzerinterface 14, Kommunikationsschnittstellen 16, 18 und eine Kernkomponente 20. Die Kernkomponente 20 ist durch eine oder mehrere Apps 26, 28 nutzbar. Die Kernkomponente 20 und die App 26, 28 werden auf dem Mikrocontroller 12 ausgeführt. Jede App 26, 28 ist in Form eines nachladbaren Programmblocks realisiert, der in den Mikrocontroller 12 einlesbar ist. Die Verwaltung der Apps wird durch die Kernkomponente 20 vorgenommen. Das Benutzerinterface 14 wird durch die Apps ausgestaltet.
  • Vorzugsweise ist ein solches Interaktionsgerät, respektive dessen Gehäuse, ausgestaltet, dass es in eine Unterputzdose eingebaut werden kann. Ebenso sind jedoch Interaktionsgeräte für Aufputz-Montage oder Interaktionsgeräte welche für eine spezielle Wandhalterung oder Wandauslässe geeignet sind, möglich. Die Kernkomponente 20 ist eine App-Plattform, welche einen Systemkern 22 und eine Basisbibliothek 24 umfasst. Die Basisbibliothek stellt Abstraktionsschichten zur Abbildung der Gebäudeinfrastruktur bereit, welche durch den Systemkern 22 und die Apps 26, 28 gleichzeitig oder alternierend nutzbar sind und welche einen vereinfachten Zugriff auf das Benutzerinterface 14 ermöglichen. Die Verwaltung der Apps 26, 28 wird durch den Systemkern 22 vorgenommen, welcher insbesondere dafür sorgt, dass die Apps sich nicht gegenseitig in Ihrer Funktion behindern.
  • Die Kernkomponente 20 und/oder der Systemkern 22 sind funktionsagnostisch. Unter funktionsagnostisch versteht man, dass die Kernkomponente 20 und/oder der Systemkern 22 keine Information über die konkret vorgesehene Verwendung des Interaktionsgerätes 10 haben. Mit andern Worten, solange keine App 26, 28 auf dem Interaktionsgerät 10 gespeichert ist oder ausgeführt wird, hat das Interaktionsgerät 10 keine Information darüber, ob es beispielsweise als Lichtschalter, Jalousienschalter, oder Temperaturanzeige verwendet werden soll. Das Interaktionsgerät 10 ist daher sehr vielseitig einsetzbar.
  • Das Interaktionsgerät 10 umfasst einen persistenten Speicher 30, in welchen Apps gespeichert werden können und aus welchem gespeicherte Apps wieder gelöscht werden können. In dem in 1 dargestellten Ausführungsbeispiel ist zudem auf dem persistenten Speicher 10 die Kernkomponente 20 gespeichert. In einer Variante kann eine App über eine der Kommunikationsschnittstellen 16, 18 auf einen Speicher 13 des Mikrocontrollers 10 geladen werden. Das Interaktionsgerät braucht in diesem Fall nicht zwingend einen persistenten Speicher 30, sondern auszuführende Apps können beispielsweise auch beim „hochfahren“ des Interaktionsgerätes von einem Server geladen und im Hauptspeicher 13 des Prozessors 12 gehalten werden. Mögliche Kommunikationsschnittstellen können ein Datenbus für die Gebäudesteuerung; ein drahtgebundenes Ethernet-Netzwerk für Kommunikation mit einem Server, oder auch ein drahtloses Netzwerk, etwa WiFi sein.
  • In weiteren Variante ist die Kernkomponente 20 in einem persistenten Speicher abgelegt, die Apps hingegen werden nur in den Hauptspeicher 13 geladen.
  • In einer weiteren Variante ist die Kernkomponente persistenten Speichermodul 30 abgelegt, die Apps hingegen in einem zweiten persistenten Speichermodul. Dadurch können leicht alle Apps gelöscht werden, ohne dass die Kernkomponente beeinträchtigt wird.
  • Vorzugsweise umfassen die Kommunikationsschnittstellen 16, 18 einen Datenbus 16, an welchen ein Busendgerät anschließbar ist. Das Busendgerät wird durch die App bedient. Typische Busendgeräte sind Aktoren oder Sensoren, welche Teil der Gebäudeinfrastruktur sind, beispielsweise Dimmer, Schaltaktoren, Jalousiesteuerungsmotoren, Heizungsregler, Thermometer, Hygrometer, Windgeschwindigkeitsmesser, Helligkeitssensoren, oder Bewegungsmelder.
  • Die App 26, 28 oder die Apps 26, 28 sind ausgestaltet und/oder adaptiert, Funktionen eines Gebäudes zu steuern oder Informationen bezüglich eines Gebäudes anzuzeigen.
  • Vorzugsweise ist das Interaktionsgerät 10 mit einem oder mehreren Sensoren und/oder Aktoren verbindbar, welche Teil der Gebäudeinfrastruktur sind und welche durch die App 26, 28 oder durch die Apps 26, 28 bedient werden. Vorzugsweise ist auch das Interaktionsgerät 10 Teil der Gebäudeinfrastruktur.
  • Vorzugsweise umfasst mindestens eine der auf dem Interaktionsgerät 10 auszuführenden Apps 26, 28 eine lokale Intelligenz, durch welche ortsabhängig, zeitabhängig und/oder kontextabhängig das Verhalten der App 26, 28 beeinflussbar ist. Auch kann eine App ortsabhängig, zeitabhängig und/oder kontextabhängig dem Interaktionsgerät zur Verfügung gestellt werden.
  • Vorzugsweise ermöglicht die vorliegende Erfindung Interaktionsgeräte 10, welche im Kern vollständig funktionsagnostisch sind, zur Laufzeit eine oder gar mehrere Funktionen (so genannte Apps) zugewiesen (oder entfernt) bekommen können. Diese Funktionen sollen wiederum mit frei definierbaren Benutzeroberflächen versehen werden können. Neben der Eingabe besteht also auch die Möglichkeit der Ausgabe.
  • Ebenso können diese Funktionen dabei beliebig programmierbar sein und nicht lediglich zur (De-)Aktivierung auf der Elektronik des Schalters/Interaktionsgerätes vordefiniert vorliegen. Vorzugsweise soll diese Programmierung eine gewisse Intelligenz lokal im Interaktionsgerät ermöglichen.
  • Die Funktionszuweisung kann dabei durch die Gebäude-Infrastruktur erfolgen und erfordert nicht zwingend einen Installateur zur individuellen Programmierung am Interaktionsgerät 10. Auf diese Weise wird sichergestellt, dass bei verändertem Bedarf die Funktion schnell und einfach durch die Infrastruktur angepasst werden kann – ggf. auch automatisch.
  • Das Interaktionsgerät 10 soll darüber hinaus den reibungslosen parallelen Ablauf von Funktionsprogrammen ermöglichen, ohne dass sich diese gegenseitig ungewollt beeinflussen.
  • Im Folgenden wird das Ausführungsbeispiel im Zusammenhang mit den Figuren noch detaillierter erläutert.
  • Das Benutzerinterface 14 umfasst eine graphische Display-Einheit, idealerweise pixel- und nicht segmentbasiert, um freier in der jeweiligen Darstellung zu sein. Zudem umfasst das Benutzerinterface 14 eine oder mehrere Eingabemöglichkeiten, z.B. durch Knöpfe/Schalter/Wippen, welche auch am Gehäuse, also fest mit dem Interaktionsgerät 10 verbaut, oder an einem steckbaren Aufsatz 50, 50a, 50b, 50c wie beispielsweise anhand der 2 und der 3A bis 3F beschrieben, eingelassen sein können. Ebenso kann das Display stattdessen oder zusätzlich mit einer berührungsempfindlichen Einheit versehen sein, welche Koordinaten zu einem oder mehreren Berührungspunkten liefert.
  • Der Microcontroller 12, im Folgenden auch MCU 12 genannt, dient zur Ausführung des funktionsagnostischen Systemkerns 22 sowie der lokalen Intelligenz nachgeladener Funktionen (diese werden kurz Apps genannt). Ebenso erledigt die MCU 12 die Generierung der visuellen Inhalte, welche über das Display des Benutzerinterfaces ausgegeben werden und durch die Apps 26, 28 individuell definiert beziehungsweise verändert werden können.
  • Ebenso können ein oder mehrere externe Speicher vorgesehen sein, etwa falls die MCU 12 über keinen oder nicht ausreichenden internen Speicher (volatile und persistent) verfügt. Dieser kann auch in Form eines entfernbaren Speichermediums (USB-Stick, SD-Karte, etc.) realisiert werden.
  • Eine oder mehrere Kommunikations-Schnittstellen: Hierbei wird unterschieden in Steuer-Schnittstellen 16 (diese sind i.d.R. Infrastruktur-spezifisch, z.B. KNX/EIB) und allgemeine Daten-Schnittstellen 18 (etwa Ethernet oder auch WLAN). Über die Daten-Schnittstelle können dabei auch größere Mengen von Daten transportiert werden, etwa solche für das Nachladen neuer Funktionsprogramme. Beide Arten von Schnittstellen können nebeneinander existieren, oder aber in einer gemeinsamen Form (etwa BACnet über IP) vorkommen. Über die Daten-Schnittstelle können darüber hinaus beliebige (auch nicht infrastrukturspezifische) Dritt- bzw. Fremdsysteme integriert werden, etwa die Anbindung eines Kalender-Servers für Informationen über Raumbelegungen. Ebenso kann gegebenenfalls über eine oder beide dieser Schnittstellen mit weiteren solchen Interaktionsgeräten 10 kommuniziert werden.
  • Die Bauform des Interaktionsgerätes 10 ist kompatibel zur genormten deutschen Unterputzdose (UP). Diese stellt die international kleinstmögliche Bauform einer UP dar und ist somit der limitierende Faktor bei den Ausmaßen. Das System kann somit in sämtlichen Ländern verbaut werden.
  • Die Flexibilität des Interaktionsgerätes 10 wird vorzugsweise durch die App-Plattform 20 auf dem Interaktionsgerät 10 erreicht. Diese besteht aus dem Kern-Modul 22 sowie den Basisbibliotheken 24. Beide sind fester Bestandteil des funktionsagnostischen Systems und fest in das Interaktionsgerät 10 eingebracht. Der Kern 22 stellt den Einstiegspunkt aus Software-Sicht dar und wird von der MCU 12 ausgeführt. Die Basisbibliotheken 24 bieten dabei Abstraktionsschichten zur Gebäudeinfrastruktur, sowie vereinfachen den Zugriff auf die Einund Ausgabeelemente 14. Sie können sowohl vom Kern-Modul 22 als auch von Apps 26, 28 genutzt werden.
  • Die flexiblen Funktionen sind dabei in Form nachladbarer Programmblöcke realisiert, so genannte Apps 26, 28. Die Verwaltung dieser Apps (das Nachladen, Entfernen, Ausführen, Pausieren, Stoppen) übernimmt das Kern-Modul. Die Apps 26, 28 werden dabei jeweils in dem persistenten Speicher abgelegt. Der persistente Speicher kann auch innerhalb der MCU 12 oder ein externer Speicher sein. Die Apps 26, 28 können jederzeit von dort gelesen oder entfernt werden. Eine App bedient sich dabei lediglich der Basisbibliotheken 24 und seiner eigenen Programmierung. Das Kern-Modul 22 stellt dabei sicher, dass Apps isoliert vom Kern-Modul 22 selbst sowie isoliert von anderen Apps ablaufen. Auf diese Weise wird sichergestellt, dass eine defekte App das gesamte Interaktionsgerät 10 nicht beeinträchtigen kann. Ebenso können Apps beim Beenden auch vollständig und sicher aus dem Arbeitsspeicher 13 verdrängt werden. Das Kern-Modul 22 kann ebenso sicherstellen, dass Apps nicht zu viele Ressourcen (Arbeitsspeicher 13, persistenten Speicher 20, Rechenkapazität, Energie, usw.) verbrauchen und auf diese ggf. manipulierend einwirken (etwa weniger Rechenkapazität zuweisen, oder die App unterbrechen).
  • Eine App 26, 28 kann dabei das Benutzerinterface und die Eingabemöglichkeiten selbständig ausgestalten. So können Status-Informationen angezeigt werden, aber auch Hinweise zur aktuell möglichen Steuerung. Eingaben wiederum können mit entsprechenden Aktionen verknüpft werden, welche zu anderen Anzeigen oder Steuer-Kommunikation führen.
  • Das Interaktionsgerät (10) erlaubt also über Apps 26, 28 sowohl das Schalten (Eingabe), als auch eine Anzeige (Ausgabe), bzw. einen Dialog (lokale Ein- und Ausgabe, welche nicht direkt zum Schalten führt, oder Notifikation durch die Infrastruktur, welche bestätigt werden kann).
  • Im Gegensatz zu bestehenden Ansätzen, wie etwa Panels, kann die Gebäudeinfrastruktur einem spezifischen Interaktionsgerät 10 bei Bedarf die für seine Umgebung vorgesehene Funktion in Form einer oder mehrere Apps 26, 28 zur Verfügung stellen. Hierbei kann die App-Übertragung durch das Interaktionsgerät 10 gepollt oder durch die Gebäudeinfrastruktur gepusht werden.
  • Alternativ kann eine Funktion/App 26, 28 auch weiterhin manuell am Interaktionsgerät (etwa per USB oder SD-Karte) hinzugefügt werden, falls die Gebäudeinfrastruktur dies nicht unterstützt.
  • Indem die App oder die Apps 26, 28 von der Infrastruktur auf das Interaktionsgerät 10 bedarfsgerecht aufgebracht werden können, aber auch weil die Apps selbst eine lokale Intelligenz aufweisen, können die Funktionen in Bezug auf Ort (z.B.: Um welches Interaktionsgerät handelt es sich, und wo befindet sich dieser?), Zeit (z.B.: Ist es Abends/Wochenende/außerhalb der Arbeitszeit?) und sonstigen Kontext (z.B.: Wie ist das Wetter gerade? Findet gerade ein Meeting im Raum statt?) variiert werden. Der Kontext beeinflusst also gegebenenfalls sowohl die Auswahl der verfügbaren Apps 26, 28 durch die Infrastruktur als auch das Verhalten der jeweiligen Apps 26, 28 selbst.
  • Sensorik für Kontextinformationen kann dabei über die Steuerschnittstelle 16, beziehungsweise die Daten-Schnittstelle 18 angesprochen werden; ebenso kann das Interaktionsgerät 10 auch baulich mit einem oder mehreren Sensoren/Aktoren verbunden sein.
  • Ist das Interaktionsgerät 10 bislang noch nicht in eine Infrastruktur integriert worden, so kann das Kernmodul 22 den Installateur bei der Kommissionierung des Interaktionsgeräts unterstützen. So kann es unabhängig von speziellen zur Kommissionierung vorgesehenen Geräten selbst abfragen wo es sich befindet und welche Kennung es besitzen soll (Kommissionierungsmodus).
  • Das vorgeschlagene Interaktionsgerät 10 ist prinzipiell in vielseitiger baulicher Art vorstellbar. Vorzugsweise umfasst es in der Regel eine oder mehrere Daten- und Infrastruktur-Schnittstellen, Ausgabegeräte in Form eines oder mehrerer Displays, Eingabegeräte in Form von Schaltern, Wippen, Knöpfen oder über berührungsempfindliche Flächen (auch kombiniert).
  • 2 zeigt den Aufbau eines App-basierten Interaktionsgerätes 10 für eine Unterputzdose 90, hier mit aufsteckbarem Display 54. Das Interaktionsgerät 10 umfasst ein Basisgerät 40 für die Unterputzdose 90, sowie einen Aufsatz 50. Der Aufsatz 50 umfasst eine oder mehrere Befestigungskrallen 52, das Display 54 und vier Schalter 56, 57, 58, 59 für eine 4-Wege-Navigation. Die Schalter 56, 57, 58, 59 sind als Drucktasten ausgebildet mit einer rechten Drucktaste 56, einer oberen Drucktaste 57, einer linken Drucktaste 58 und einer unteren Drucktaste 59.
  • Das Basisgerät 40, welches auch Geräteteil genannt werden kann, umfasst eine Buchse 44 für die Ansteuerung des Displays 54, eine Buchse 49 für einen Tasteranschluss zur Ansteuerung der Schalter 56, 57, 58, 59, ein Gehäuse 42 in welchem der Mikrocontroller 12, der Speicher 30, eine Funkeinheit, und allfällige weitere Komponenten untergebracht sind. Zudem umfasst das Basisgerät 40 eine Busklemme 43, an welche ein Anschlusskabel 93 für ein Gebäudesteuerungsbussystem 63 anschließbar ist. Auch umfasst das Basisgerät 40 eine Buchse 46, an welche ein weiteres Anschlusskabel 96 für ein Datennetzwerk anschließbar ist.
  • Das Interaktionsgerät 10 selbst ist vorzugsweise in die Unterputzdose 90 verbaubar. Der Anwender sieht nur die Eingabegeräte 56, 57, 58, 59 und Ausgabegeräte 54 auf der Frontblende 50. Die Front des Aufsatzes 50 kann aber auch ein reines Touch-Display umfassen, oder ein kleineres Display 54 umgeben von mehreren Schaltern 56, 57, 58, 59.
  • Die 3A, 3B, 3C, 3D, 3E, 3F zeigen steckbare Aufsätze 50, 50a, 50b, 50c, welche auch als Blenden 50, 50a, 50b, 50c oder Frontblenden 50, 50a, 50b, 50c bezeichnet werden, mit verschiedenen Anordnungen für Ein- und Ausgabe sowie verschiedenen Anzeigeinhalten und Funktionen. Hardwareseitig zeigen die Figuren vier unterschiedliche Display-Steckaufsätze 50, 50a, 50b, 50c.
  • 3A zeigt einen Aufsatz 50c, wobei eine App zur Auswahl einzelner Lichter mittels der rechteckigen Schalter 56c, 57c, 58c, 59c und dem Display 54 ausgeführt wird. Die gewünschten Lichter (z.B. Licht beim Tisch) lassen sich durch die horizontalen Schalter 56c, 58c auswählen, die Intensität des ausgewählten Lichtes lassen sich durch die vertikalen Tasten 57c, 59c auswählen.
  • 3B zeigt den Aufsatz 50, wobei eine App zur Auswahl einzelner Lichter mit den trapezförmigen Schaltern 56, 57, 58, 59 und dem Display 54 ausgeführt wird. Im Gegensatz zu der in 3A dargestellten Ausführungsform, wird in 3B jedoch eine App ausgeführt, bei welcher sich das gewünschte Licht durch die vertikalen Schalter 57, 58 auswählen lässt, während die Intensität des Lichts sich durch die horizontalen Schalter 56, 58 auswählen lässt.
  • 3C zeigt den Aufsatz 50, wobei eine App zur Regelung der Temperatur, Luftfeuchtigkeit und Lüftung ausgeführt wird. Mit Hilfe der Schalter 56, 57, 58, 59 lassen sich die Temperatur, Luftfeuchtigkeit oder Lüftung und die betreffenden Soll-Werte dafür einstellen. Das Display zeigt die jeweilige Auswahl und den jeweiligen Zielwert an.
  • 3D zeigt den Aufsatz 50, wobei eine App zur Rolladensteuerung mit Hilfe der Schalter 56, 57, 58, 59 und dem Display 54 ausgeführt wird. Über die horizontalen Schalter 56, 58 lässt sich ein gewünschter Rolladen wählen, über die vertikalen Schalter 57, 59 kann der ausgewählte Rolladen bedient werden. Indem man lange drückt, werden alle Rolladen gewählt.
  • 3E zeigt einen Aufsatz 50a, welcher ein reines Touch-Display 54a ohne mechanische Schalter umfasst. Die Frontblende 50a wird durch eine App gesteuert, mit welcher eine Szenenauswahl per Tag Cloud und Touchscreen 54a ausgewählt werden kann.
  • 3F zeigt einen Aufsatz 50b, welcher ein Display 54b und lediglich zwei Schalter 57b, 59b (oben und unten) umfasst. Der Aufsatz 50b wird durch eine App gesteuert, mittels der eine Nachfrage des Systems eine gewünschte Aktion eines Anwenders zulässt. Hier erlaubt eine Lichtsteuerung mit einem Zeitschalter, welche nach einer gewissen Zeit das Licht automatisch löschen würde, mittels Betätigung des unteren Schalters 59b das Licht sofort zu löschen, oder dieses für längere oder unbegrenzte Zeit mittels Betätigung des oberen Schalters 57b brennen zu lassen.
  • Anhand der in 3A bis 3F dargestellten Ausführungsbeispiele wird ersichtlich, dass die angezeigten Elemente auf einem Display in räumlichem Bezug zu den Schaltern stehen (die Anzeige auf dem Display ist also vorzugsweise auf die Anordnung der Taster abgestimmt, was durch eine Selbstbeschreibung des Display-Aufsatzes ermöglicht wird), und dass Aufgrund der großen funktionalen Variationsbreite durch die App-Plattform auf dem Display beliebige Inhalte denkbar sind. Einige sind exemplarisch in 4 im größeren Kontext eines Gebäudes 70, welches eine elektronische Gebäudeinfrastruktur umfasst dargestellt.
  • In einem Gebäude würden typischerweise viele Interaktionsgeräte 10 verwendet, oft auch viele in einem Raum. Dies ist schematisch in 4 dargestellt. Bei einem Umzug der Nutzer innerhalb des Gebäudes, z.B. der Umwandlung eines Büros in einen Besprechungsraum oder umgekehrt, würde man die Display-Aufsätze einfach tauschen.
  • 4 zeigt daher das Gebäude 70 mit mehreren Räumen und mit einem Gebäudeautomatisierungssystem. Das Gebäudeautomatisierungssystem umfasst einen Gebäudeautomatisierungs-Server 69, ein Bus-System 63, Interaktionsgeräte 10, 10a, 10b, 10c, sowie Aktoren und Sensoren als Feldgeräte 72, 74. Die in 4 dargestellten Interaktionsgeräte 10 umfassen dabei jeweils ein Basisgerät 40 (2) und den Aufsatz 50 (2, 3B3D). Das Interaktionsgerät 10a umfasst das Basisgerät 40 (2) und den Aufsatz 50a (2, 3E). Das Interaktionsgerät 10b um-fasst das Basisgerät 40 (2) und den Aufsatz 50b (2, 3E). Das Interaktionsgerät 10c umfasst das Basisgerät 40 (2) und den Aufsatz 50c (2, 3A).
  • Der Gebäudeautomatisierungs-Server 69, die Interaktionsgeräte 10, 10a, 10b, 10c, sowie die Feldgeräte 72, 74 sind über das Bus-System 63 miteinander verbunden. Die Interaktionsgeräte 10, 10a, 10b, 10c sind über eine ihrer Kommunikationsschnittstellen 16, 18 mit dem Gebäudeautomatisierungs-Server 69 verbunden. Das Benutzerinterface 14 eines der Interaktionsgeräte 10, 10a, 10b, 10c ist durch eine App an das mindestens eine Feldgerät 72, 74 anpassbar, das durch das Interaktionsgerät angesteuert werden soll. Beispielsweise ist in Figur das Interaktionsgerät 10b an die Ansteuerung der Lampen 72 im Dachstock angepasst.
  • Natürlich könnten als Variante der vorliegenden Erfindung die Interaktionsgeräte 10, 10a, 10b, 10c auch nicht-modular ausgestaltet sein, also mit je mindestens einem Benutzerinterface welches nicht als entfernbarer Aufsatz ausgestaltet ist, sondern welches fest mit den restlichen Teilen des jeweiligen Interaktionsgerätes 10, 10a, 10b verbaut ist.
  • Der Gebäudeautomatisierungs-Server 69 und die Interaktionsgeräte 10, 10a, 10b, 10c sind mit dem Bus-System 63 verbunden. Die Gebäudeinfrastruktur umfasst auch die oben erwähnten Aktoren und Sensoren, beispielsweise Lampen 72, Jalousien 74, Thermometer, Temperaturregelungen, Belegungssysteme, welche ebenfalls an das Bussystem 63 angeschlossen sind und welche sich daher durch geeignet programmierte Interaktionsgeräte 10, 10a, 10b, 10c bedienen lassen.
  • Ein weiterer Vorteil von bevorzugten Ausführungsformen liegt in der Kombination der verfügbaren Kommunikationskanäle sowie den neutralen Ein- und Ausgabemöglichkeiten. Hierbei müssen keine Funktionen fest in das Interaktionsgerät integriert werden, sondern das Interaktionsgerät selbst ist sogar vollständig funktionsagnostisch. Eine App-Plattform, eine Laufzeitumgebung (Runtime) für nachladbare Funktionen, bietet darauf aufbauend erst die Flexibilität durch Apps. Dabei werden nur die Funktionen hinzugefügt (oder entfernt) die für das Interaktionsgerät 10 aktuell vorgesehen sind bzw. relevant erscheinen.
  • Apps können dabei orts-, zeit- und kontextabhängig von der Infrastruktur zur Verfügung gestellt werden. Apps selbst wiederum können durch ihre lokale Intelligenz ebenfalls diese Kontextinformationen berücksichtigen und ihr eigenes Verhalten beeinflussen.
  • Durch die zusätzliche lokale Intelligenz auf dem Interaktionsgerät 10 wird darüber hinaus die Gebäudeinfrastruktur entlastet. Eine solche Intelligenz könnte beispielsweise die Abfrage von Webservices sein, sowie die Kombination/Auswertung von lokal nahen Sensoren (etwa Bewegungsmelder-Daten oder auch weitere solcher Interaktionsgeräte) und darauf basierende Aktionen. Die Interaktionsgeräte sind somit nicht nur konfigurierbar gemäß den vordefinierten Funktionen, sondern erlauben das Ausführen komplexer Programme.
  • Ein weiterer Vorteil liegt in der einfachen Kommissionierung des Interaktionsgerätes. Das Interaktionsgerät kann im Auslieferungszustand in einen speziellen Kommissionierungsmodus schalten. Dieser wird als Teil des Kernmoduls, oder als vorinstallierte App realisiert. Dieser Modus erlaubt es dem Installateur, z.B. dem Gerät eine ID und einen Raum zuzuweisen. Nach seiner erfolgreichen Installation wird diese Kommissionierungsfunktionalität () inaktiv oder entfernt.
  • Die grundsätzliche Funktionsunabhängigkeit erlaubt es darüber hinaus ein solches Interaktionsgerät in sehr großer Stückzahl zu produzieren und die konkrete Ausprägung erst bei der Installation bzw. sogar zu jedem späteren Zeitpunkt während der Laufzeit festzulegen oder zu ändern.
  • Durch die geringe (auf eine deutsche Unterputz-Dose abgestimmte) Bauform kann das Interaktionsgerät beinahe in jedem Land in eine ggf. bereits bestehende Unterputz-Dose eingebracht werden. Dies erlaubt auch das nachträgliche Installieren des Systems in bestehende Infrastrukturen, ohne dass spezielle Veränderungen an Gebäuden notwendig werden. Ebenso können mehrere solche funktionsagnostische Interaktionsgeräte über- oder nebeneinander in einem Aufsatz verbaut werden und sogar miteinander interagieren.
  • Vorzugsweise entlastet eines, mehrere oder alle Interaktionsgeräte auch den zentralen Gebäudesteuerungs-Server von einfachen Rechenaufgaben.
  • Gemäß einer bevorzugten Ausführungsform umfasst ein Interaktionsgerät 10, 10a, 10b, 10c für eine Unterputzdose einen Mikrocontroller, Anschlüsse für Netzwerk und Bussysteme, Anschlüsse für Eingaben und Ausgaben, und einer Software-Plattform für Apps, die von einem Gebäudemanagement-Server bei Bedarf nachgeladen werden können.
  • In kleinen Geräten für die Gebäudesteuerung werden Apps heute nicht verwendet, da sie rechenintensiver sind als fest programmierter Code. Stattdessen hat man relativ fest einprogrammierte Funktionalität in den Geräten. Apps werden heute z.B. bei Smartphones eingesetzt. Diese würden aber zu viel Energie und Platz verbrauchen, um sie wirtschaftlich z.B. anstelle eines Lichtschalters einzusetzen. Gemäß einer weiteren bevorzugten Ausführungsform kann man in dieser speziellen Domäne, der Gebäudeautomatisierung, einen besonderen Effekt ausnutzen: Die meiste Zeit tun Interaktionsgeräte 10, 10a, 10b, 10c im Gebäude nichts und können deshalb in einem Stand-by-Modus sein. Sie können so ausgestaltet und adaptiert sein, dass sie nur bei Daten vom Bus oder bei Benutzerinteraktion aufwachen. Durch eine auf Event-Verarbeitung und Energiesparen ausgelegte App-Plattform kann man nun eine App-Plattform für kleine Interaktionsgeräte in der Gebäudesteuerung bauen, die auf kostengünstiger Hardware läuft und sich über ein Bussystem mit Strom versorgen lässt.
  • Vorzugsweise ist das Interaktionsgerät 10, 10a, 10b, 10c an allen Stellen in einem Gebäude einsetzbar, wo heute Bedienelemente mit Bussystem-Anschluss eingesetzt werden: Taster für Licht- oder Jalousiesteuerung, Heizungs- und Lüftersteuerung, Szenensteuerungen, Informationsanzeigen etc. Die Funktionalität eines Interaktionsgeräts kann jedoch einfach geändert werden, auch z.B. automatisch je nach Tageszeit und Raumbelegung. Besonders in Räumen, die immer wieder unterschiedlich genutzt werden (flexibles Bürogebäude, Veranstaltungszentrum) ist dies ein großer wirtschaftlicher Vorteil. Ein weiterer Vorteil ist, dass die kleinen Interaktionsgeräte auch Funktionen eines subsidiären Raum-Controllers übernehmen können, und damit einen zentralen Server 69 entlasten sowie die Privatsphäre der Nutzer schützen (da nicht alle Steuerbefehle über einen Server laufen müssen).
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • http://www.busch-jaeger.de/de/gebaeudesystemtechnik/prion.htm [0012]
    • ist das Display nicht in einer Standard-Unterputzdose (z.B. nach DIN 49073) einbaubar [0012]
    • http://www.busch-jaeger.de/de/produkte/energycontrol.htm [0013]
    • http://www.busch-jaeger.de/de/produkte/energydisplay.htm [0013]
    • http://myube.co/ [0014]
    • http://techcrunch.com/2012/10/02/ube-aims-to-make-home-automation-cheaper-with-ip-enabled-smart-devices-mobile-app/ Schalter [0014]

Claims (23)

  1. Interaktionsgerät (10, 10a, 10b, 10c) für eine Gebäudeinfrastruktur umfassend: einen Mikrocontroller (12), ein Benutzerinterface (14), eine oder mehrere Kommunikationsschnittstellen (16, 18) und eine Kernkomponente (20); wobei die Kernkomponente (20) durch eine App (26, 28) nutzbar ist; wobei die Kernkomponente (20) und die App (26, 28) durch den Mikrocontroller (12) ausführbar sind und die App (26, 28) in Form eines nachladbaren Programmblocks realisiert ist, der in den Mikrocontroller (12) einlesbar ist und dessen Verwaltung durch die Kernkomponente (20) durchführbar ist; wobei das Benutzerinterface (14) durch die App (26, 28) ausgestaltbar ist.
  2. Interaktionsgerät (10, 10a, 10b, 10c) nach Anspruch 1, wobei die Abstraktionsschichten durch mehrere Apps (26, 28) nutzbar sind, welche jeweils in Form eines nachladbaren Programmblocks realisiert sind; wobei die Apps (26, 28) durch den Mikrocontroller (12) ausführbar sind; wobei die nachladbaren Programmblöcke in den Mikrocontroller (12) einlesbar sind; wobei die Verwaltung der Apps (26, 28) durch die Kernkomponente (20) durchführbar ist; und wobei das Benutzerinterface (14) durch die Apps (26, 28) ausgestaltbar ist.
  3. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei die Kernkomponente (20) eine App-Plattform ist, welche einen Systemkern (22) und eine Basisbibliothek (24) umfasst, und wobei die Basisbibliothek Abstraktionsschichten zur Abbildung der Gebäudeinfrastruktur bereitstellt, welche durch den Systemkern (22) und die App (26, 28) oder die Apps (26, 28) nutzbar sind.
  4. Interaktionsgerät (10, 10a, 10b, 10c) nach Anspruch 3, wobei die Abstraktionsschichten vereinfachten Zugriff auf das Benutzerinterface (14) ermöglichen.
  5. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei die Kernkomponente (20) funktionsagnostisch ist.
  6. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei die App (26, 28) oder die Apps (26, 28) über die Kommunikationsschnittstelle (16, 18) auf einen Speicher (13) des Mikrocontrollers (12) ladbar ist.
  7. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei die Kommunikationsschnittstelle (16, 18) einen Datenbus (16) umfasst, an welchen ein Busendgerät anschließbar ist, welches durch die App (26, 28) oder durch die Apps (26, 28) bedienbar ist.
  8. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei das Interaktionsgerät (10, 10a, 10b, 10c) mit einem oder mehreren Sensoren und/oder Aktoren verbindbar ist, welche durch die App (26, 28) oder durch die Apps (26, 28) bedienbar ist oder sind.
  9. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei die App (26, 28) eine lokale Intelligenz umfasst, durch welche ortsabhängig, zeitabhängig und/oder kontextabhängig das Verhalten der App (26, 28) beeinflussbar ist, oder die App (26, 28) ortsabhängig, zeitabhängig und/oder kontextabhängig zur Verfügung stellbar ist.
  10. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, umfassend einen persistenten Speicher (30), wobei die App (26, 28) oder die Apps (26, 28) in den persistenten Speicher (30) ablegbar ist oder sind und/oder von dem Speicher (30) entfernbar ist oder sind.
  11. Interaktionsgerät (10, 10a, 10b, 10c) nach einem der vorhergehenden Ansprüche, wobei die App (26, 28) oder die Apps (26, 28) ausgestaltet und adaptiert sind, Funktionen eines Gebäudes zu steuern oder Informationen bezüglich eines Gebäudes anzuzeigen.
  12. Verfahren zum Anpassen eines Interaktionsgerätes (10, 10a, 10b, 10c) an eine Gebäudeinfrastruktur, umfassend die Verfahrensschritte: Ausführen einer Kernkomponente (20) auf dem Interaktionsgerät (10, 10a, 10b, 10c); Verwalten mindestens einer App (26, 28) durch die Kernkomponente (20); Ausführen der App (26, 28) auf dem Interaktionsgerät (10, 10a, 10b, 10c); Nutzen der Kernkomponente (20) durch die App (26, 28); Ausgestalten eines Benutzerinterfaces (14) des Interaktionsgerätes (10, 10a, 10b, 10c) durch die App (26, 28).
  13. Verfahren nach Anspruch 12, wobei die Kernkomponente (20) eine App-Plattform ist, welche einen Systemkern (22) und eine Basisbibliothek (24) umfasst, und wobei die Basisbibliothek (24) Abstraktionsschichten zur Abbildung der Gebäudeinfrastruktur bereitstellt, welche durch den Systemkern (22) die App (26, 28) genutzt werden.
  14. Verfahren nach Anspruch 13, wobei die Abstraktionsschichten vereinfachten Zugriff auf das Benutzerinterface (14) ermöglichen.
  15. Verfahren nach einem der Ansprüche 12–14, wobei die Kernkomponente (20) funktionsagnostisch ist.
  16. Verfahren nach einem der Ansprüche 12–15, wobei die App (26, 28) über eine Kommunikationsschnittstelle (16, 18) des Interaktionsgerätes (10, 10a, 10b, 10c) auf einen Speicher (13) des Mikrocontrollers (12) geladen wird.
  17. Verfahren nach einem der Ansprüche 12–16, wobei die Kommunikationsschnittstelle (16, 18) einen Datenbus umfasst, an welchen ein Busendgerät anschließbar ist, welches durch die App (26, 28) bedient wird.
  18. Verfahren nach einem der Ansprüche 12–17, wobei das Interaktionsgerät (10, 10a, 10b, 10c) mit einem oder mehreren Sensoren und/oder Aktoren verbunden wird, welche durch die App (26, 28) bedient wird oder werden.
  19. Verfahren nach einem der Ansprüche 12–18, wobei die App (26, 28) eine lokale Intelligenz umfasst, durch welche ortsabhängig, zeitabhängig und/oder kontextabhängig das Verhalten der App (26, 28) beeinflusst wird, oder die App (26, 28) ortsabhängig, zeitabhängig und/oder kontextabhängig zur Verfügung gestellt wird.
  20. Verfahren nach einem der Ansprüche 12–19, umfassend einen persistenten Speicher (30), wobei die App (26, 28) in den persistenten Speicher (30) abgelegt und/oder aus dem persistenten Speicher entfernt wird.
  21. Verfahren nach einem der Ansprüche 12–20, wobei die Kernkomponente (20) durch mehrere Apps (26, 28) genutzt wird, welche jeweils in Form eines nachladbaren Programmblocks realisiert sind; wobei die Apps (26, 28) durch den Mikrocontroller ausgeführt werden; wobei die nachladbaren Programmblöcke in den Mikrocontroller eingelesen werden; wobei die Verwaltung der Apps (26, 28) durch die Kernkomponente (20) oder durch den Systemkern durchgeführt wird; und wobei das Benutzerinterface durch die Apps (26, 28) ausgestaltet wird.
  22. Verfahren nach einem der Ansprüche 12–21, wobei die App (26, 28) oder die Apps (26, 28) Funktionen eines Gebäudes steuert oder steuern oder Informationen bezüglich eines Gebäudes anzeigt oder anzeigen.
  23. Gebäudeautomatisierungssystem umfassend ein Interaktionsgerät (10, 10a, 10b, 10c) gemäß einem der Ansprüche 1–11; eine Zentraleinheit, die vorzugsweise als Gebäudeautomatisierungs-Server (69) oder als Raumcontroller ausgebildet ist; und mindestens ein Feldgerät (72, 74); wobei die Zentraleinheit mit einer der Kommunikationsschnittstellen (16, 18) und mit dem mindestens einen Feldgerät (72, 74) des Gebäudeautomatisierungssystems verbunden ist, und wobei das Benutzerinterface (14) durch die App (26, 28) an das mindestens eine Feldgerät (72, 74) anpassbar ist.
DE201210224393 2012-12-27 2012-12-27 App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes Ceased DE102012224393A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE201210224393 DE102012224393A1 (de) 2012-12-27 2012-12-27 App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE201210224393 DE102012224393A1 (de) 2012-12-27 2012-12-27 App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes

Publications (1)

Publication Number Publication Date
DE102012224393A1 true DE102012224393A1 (de) 2014-07-03

Family

ID=50928439

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201210224393 Ceased DE102012224393A1 (de) 2012-12-27 2012-12-27 App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes

Country Status (1)

Country Link
DE (1) DE102012224393A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050143863A1 (en) * 2003-12-19 2005-06-30 Margaret Ruane Building control system field panel having integrated web server
US20080016493A1 (en) * 2006-06-29 2008-01-17 Honeywell International Inc. System level function block engine
US7526364B2 (en) * 2004-01-30 2009-04-28 Siemens Building Technologies, Inc. Virtual field controller

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050143863A1 (en) * 2003-12-19 2005-06-30 Margaret Ruane Building control system field panel having integrated web server
US7526364B2 (en) * 2004-01-30 2009-04-28 Siemens Building Technologies, Inc. Virtual field controller
US20080016493A1 (en) * 2006-06-29 2008-01-17 Honeywell International Inc. System level function block engine

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
http://myube.co/
http://techcrunch.com/2012/10/02/ube-aims-to-make-home-automation-cheaper-with-ip-enabled-smart-devices-mobile-app/ Schalter
http://www.busch-jaeger.de/de/gebaeudesystemtechnik/prion.htm
http://www.busch-jaeger.de/de/produkte/energycontrol.htm
http://www.busch-jaeger.de/de/produkte/energydisplay.htm
ist das Display nicht in einer Standard-Unterputzdose (z.B. nach DIN 49073) einbaubar

Similar Documents

Publication Publication Date Title
DE102008017292A1 (de) Computergestütztes System zur Verwaltung und/oder Steuerung eines Gebäudemanagementsystems
EP2561413A1 (de) System für die gebäudeautomation
EP2579113A1 (de) Struktur eines Gebäudeautomationssystems
EP2081415B1 (de) Mikrokontroller-gesteuerte Notlichtbeleuchtungsanlage und geeignetes Kommunikationsverfahren hierfür
DE102005010914A1 (de) Verfahren zur Gebäudesteuerung und Gebäudeüberwachung
EP2750335A2 (de) Steckbares Interaktionsgerät
EP3293588A1 (de) Verfahren zur provisionierung von raumautomationskomponenten eines gebäudeautomationssystems
WO2016034236A1 (de) Verfahren zur datenerhebung für die konfiguration eines gebäudeautomationssystems und verfahren zum konfigurieren eines gebäudeautomationssystems
DE202011004895U1 (de) Steuerungsanordnung einer Hausautomatisierungsanlage
DE102012224393A1 (de) App-basiertes Interaktionsgerät und Verfahren zum Anpassen eines Interaktionsgerätes
DE10327504A1 (de) Multifunktionsgerät
EP2523396A2 (de) Tragbares Anzeige- und Bediengerät
DE102014210000A1 (de) Vorortbedienung von Geräten eines Installationsbuses
DE102017121252B4 (de) System, Verfahren und Funkmodul zur Anwesenheitserkennung zwecks Energieeinsparung
DE102013103851B4 (de) Verfahren zum Ansteuern von gebäudesystemtechnischen Aktoren
EP1971080B1 (de) Verfahren zur Inbetriebnahme eines Funksystems
DE102014201343A1 (de) Haustechnische Steuervorrichtung für eine klimatechnische Anordnung
EP3664380B1 (de) Upgradbares stufenkonzept für beleuchtungssysteme
DE102012224391A1 (de) Lokaler Funkzugang zur Steuerung eines Infrastruktur-Abschnitts
EP3657286B1 (de) Verfahren zum einrichten eines ansteuergerätes in einem gebäudeinstallationsnetzwerk
EP3847516B1 (de) Identifizieren von steuergeräten in automatisierungssystemen
DE102006025300B4 (de) Elektrisches Installationsgerät
DE202023102814U1 (de) Steuerungs-und Verwaltungssystem der Elemente eines Hauses
EP3355138B1 (de) Verfahren zur bestimmung der geometrischen position eines raumreglers
DE102012204686B3 (de) Verfahren zur Konfiguration einer Beleuchtungsanlage

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final
R003 Refusal decision now final

Effective date: 20140716