DE202020105811U1

DE202020105811U1 - Vorrichtung zur Datenaufbereitung für ein nutzerdatenbasiertes Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems für eine zeit-/ortsaufgelöste Funktionsweise sowie Computerprogrammprodukt und Verwendung

Info

Publication number: DE202020105811U1
Application number: DE202020105811.8U
Authority: DE
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-10-10
Filing date: 2020-10-10
Publication date: 2020-10-27
Anticipated expiration: 2030-10-11

Abstract

Kommunikations- und Steuerungs-/Regelungssystem (100) zur Datenaufbereitung für ein nutzerdatenbasiertes Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems (1) basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) zum Bereitstellen von Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters aus einer personenbezogenen Parametergruppe (GPp) umfassend zumindest die folgenden zeit-/ortsaufgelösten personenbezogenen Parameter eingerichtet ist: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort (GPSp) des Nutzers;
- wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) wenigstens einen uni-/oder bidirektionalen Kommunikationspfad aus der folgenden Gruppe nutzt oder bereitstellt: Kommunikationspfad (11) zwischen einer jeweiligen Person (I) und einem Daten-Host (5) und/oder einem Datenraum (3), Kommunikationspfad (12) zwischen einem/dem Daten-Host (5) und der jeweiligen Person (1) und/oder dem Datenraum (3), Kommunikationspfad (13) zwischen einem HLK-/PCS-System-Betreiber (7) und dem Daten-Host (5) und/oder dem Datenraum (3);
- wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) für die wenigstens eine Person (1) eine Eingabe-/Kommunikationsmaske (15) zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum durch Hinterlegen wenigstens eines subjektiven Komfort-Ratings (Sp) und/oder des wenigstens einen personenbezogenen Parameters (Pp) bereitstellt, insbesondere durch Cross Domain Content Management, wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist für eine Zeit- und/oder Ortsauflösung der nutzerspezifischen Komfort-Ratings (Sp) und der personenbezogenen Parameter (Sp) und eingerichtet ist zum Hinterlegen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4);
- wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist, die Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters (Pp) basierend auf den Komfort-Ratings (Sp) und/oder basierend auf bereits hinterlegten, momentan durch den jeweiligen Nutzer eingegebenen und/oder automatisiert abgerufenen zeit-/ortsaufgelösten personenbezogenen Parametern (Pp) aus der Nutzerpräferenzcharakteristik (4) aus dem Datenraum zu generieren und insbesondere für einen/den HLK-/PCS-System-Betreiber (7) bereitzustellen, insbesondere in Echtzeit.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft ein Kommunikations- und Steuerungs-/Regelungssystem zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter. Ferner betrifft die vorliegende Erfindung auch ein System zur Anwendung eines entsprechenden Verfahrens zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems, insbesondere in Abhängigkeit von Nutzerpräferenzen. Nicht zuletzt betrifft die vorliegende Erfindung auch ein entsprechendes Computerprogrammprodukt und entsprechende Verwendungen, insbesondere sowohl auf Front-End- Seite (Nutzer) als auch auf Back-End-Seite (Host bzw. Datenbe-/verarbeitungs-Entity, und/oder HLK-/PCS-System-Betreiber). Insbesondere betrifft die Erfindung eine Vorrichtung und eine Verwendung jeweils gemäß dem Oberbegriff des jeweiligen unabhängigen Anspruchs.
HINTERGRUND DER ERFINDUNG
Beim Einstellen von klimatischen Bedingungen in klimatisch abgrenzbaren Umgebungen (z.B. Wohnhaus) gibt es in vielen Situationen, trotz der bereits auf vielen Ebenen verfügbaren sehr guten und technisch ausgereiften Steuerungs-/Regelungssysteme, nach wie vor als sehr nachteilig oder ungünstig empfundene Diskrepanzen zwischen den von Nutzern erlebten momentanen klimatischen Ist-Zuständen und den auf technischer Seite definierten Soll-Zuständen. Die Liste der klimatischen Parameter, die sich auf diese Diskrepanzen auswirken, beginnt bei der Temperatur und Luftfeuchte, und lässt sich z.B. hinsichtlich konvektiven Einflüssen, Lichtintensität, akustischen Einflüsse oder weiteren durch die menschlichen oder tierischen Sinnesorgane wahrnehmbaren Parameter fortsetzen. Im Stand der Technik werden viele Maßnahmen auf HLK-System-Ebene beschrieben, um diese Diskrepanzen verringern zu können, insbesondere in Hinblick auf eine möglichst wunschgemäße Temperaturregelung. Nicht zuletzt aufgrund der mannigfachen technischen Unterschiede der HLK-Systeme (beispielweise Reaktionszeiten, Trägheiten, nur unidirektionale Regelungsmöglichkeiten) und der extrem stark voneinander abweichenden unterschiedlichen Nutzer-Vorlieben ist es bisher trotz der z.B. auch durch mobile Kommunikations-Hilfsmittel erleichterten Ansteuerung oder auch Regelung von HLK-Systemen immer noch schwierig gewesen, das jeweilige HLK-System auf möglichst einfache und intuitive Weise, möglichst sogar ortsunabhängig, für den jeweiligen Nutzer zu individualisieren. Weitere Nachteile ergeben sich dann, wenn ein Nutzer auf zeitaufwändige Weise involviert werden muss, um das jeweilige HLK-System optimal abstimmen zu können, und/oder wenn der Nutzer die Abstimmung nur in bestimmten Situationen oder an bestimmen Orten durchführen kann (erschwerte Zugänglichkeit). Daher besteht Interesse an einem System bzw. Verfahren, welches die heutigen technischen Möglichkeiten möglichst umfassend nutzt und derart für eine nutzerbedarfsorientierte Steuerung/Regelung von HLK-Systemen konsolidiert, dass sich einerseits das Komfort-Empfinden des jeweiligen Nutzers ohne großen Aufwand maximieren lässt, dass der jeweilige Nutzer aber auch andererseits in Hinblick auf die aktuellen klimatischen Herausforderungen und die weltweiten Energieeinsparbemühungen dabei nicht in Versuchung gerät, seinen CO₂-Abdruck zu verschlechtern bzw. den Energieverbrauch unnötig in die Höhe zu treiben. Sehr schön wäre es, wenn es gelingen würde, den Nutzer sogar auch bei/während der Maximierung des individuellen Komfort-Empfindens dazu anregen zu können, Energie einzusparen.
EP 1 806 543 B 1 beschreibt ein Klimaregelungsverfahren, bei welchem ein in einem Raum zu installierendes tragbares Umgebungskontrollgerät mit Sensoreinheit und Eingabeeinheit und Einstelleinheit und Bestimmungseinheit und Ausgabeeinheit eine Klima-Anpassung gemäß den von einem Benutzer eingegebenen subjektiven Komfort-Vorlieben ermöglicht, indem die Klima-Anpassung hinsichtlich der vom Benutzer definierten Komfortzone erfolgt.
Ausgehend vom Stand der Technik besteht Interesse und Bedarf an einem System, welches sich möglichst flexibel implementieren und skalieren und hinsichtlich sehr verschiedener momentaner klimatischer Bedürfnisse individueller Nutzer möglichst ohne zeitliche Nachteile aktualisieren lässt und eine einfache Nutzung sowohl durch einen oder mehrere Nutzer als auch durch die im jeweiligen Anwendungsfall zu involvierenden Systembetreiber ermöglicht.
ZUSAMMENFASSUNG DER ERFINDUNG
Aufgabe ist, eine Vorrichtung bzw. ein System zum Erfassen und Bereitstellen von Daten für eine nutzerspezifische Steuerung/Regelung von Klimasystemen bereitzustellen, womit die für die Steuerung/Regelung zugrunde zu legenden Daten besonders vorteilhaft aufbereitet bzw. verarbeiten und bereitgestellt und wahlweise auch von einem Systembetreiber genutzt werden können, sei es hinsichtlich der Aufbereitung und Bereitstellung der Daten durch eine Datenverarbeitungs-Entity, sei es hinsichtlich der Nutzung oder Pflege der Daten seitens Nutzern oder seitens Systembetreibern oder Energieverwaltern, oder sei es sogar auch noch hinsichtlich einer Steuerung und/oder aktiven Regelung der jeweiligen spezifischen klimatechnischen Vorrichtung (z.B. HLK-Systeme). Auch eine Aufgabe ist, ein entsprechendes Verfahren zum Bereitstellen von Daten zum Ermöglichen eines nutzerdatenbasierten Steuern/Regeln eines bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems basierend auf einer Mehrzahl personenspezifisch definierbarer Steuerungs-/Regelungsparameter zu ermöglichen, insbesondere in Hinblick auf eine ressourcenschonende energetische Ausbeute, insbesondere in Hinblick auf eine momentane und/oder mittelfristige Energiebedarfsprognose. Nicht zuletzt ist es eine Aufgabe, eine nutzerspezifische Datenaufbereitung vor dem weiteren Ziel einer Steuerung/Regelung der Funktionsweise wenigstens eines HLK-/PCS-Systems derart zu ermöglichen, dass ein nutzerbezogenes Komfort-Bedürfnis zunächst auf Datenebene, und wahlweise auch hinsichtlich klimatechnischer Umsetzung, möglichst vollumfänglich erfasst und befriedigt wird und gleichzeitig der CO₂-Abdruck (hier insbesondere zu verstehen als Synonym für jegliche durch Energieverbrauch begründete Emission) bzw. der nutzerspezifische Energiebedarf ohne spürbare Komfort-Einbußen minimiert werden kann, ohne dem jeweiligen Nutzer eine unnötig große Last für die Realisierung der Datenpflege aufzubürden.
Zumindest eine dieser Aufgaben wird durch ein System gemäß Anspruch 1 sowie durch Computerprogramme gemäß den nebengeordneten Vorrichtungsansprüchen sowie durch Verwendungen gemäß den nebengeordneten Verwendungsansprüchen gelöst. Vorteilhafte Weiterbildungen der Erfindung werden in den jeweiligen Unteransprüchen bzw. in weiteren nebengeordneten Ansprüchen erläutert. Die Merkmale der im Folgenden beschriebenen Ausführungsbeispiele sind miteinander kombinierbar, sofern dies nicht explizit verneint ist.
Erfindungsgemäß wird bereitgestellt: Ein Kommunikations- und Steuerungs-/Regelungssystem zur Datenaufbereitung für ein nutzerdatenbasiertes Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK- (bzw. HVAC-)Systems durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems (bzw. Building Management System BMS) basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter, wobei das Kommunikations-/Steuerungs-/Regelungssystem zum Bereitstellen von Klimapräferenzdaten zum zum Generieren/Vorgeben wenigstens eines Steuerungs-/Regelungsparameters aus einer personenbezogenen Parametergruppe umfassend zumindest die folgenden personenbezogenen Parameter (bzw. Parameterpräferenzen) in Bezug auf wenigstens einen Zeitpunkt/Zeitwert und/oder in Bezug auf wenigstens einen momentanen oder zukünftigen oder vordefinierten Aufenthaltsort eines/des jeweiligen Nutzers eingerichtet ist (d.h., als Funktion der Zeit oder in Bezug auf einen momentanen oder zukünftigen Zeitpunkt oder Tageszeitpunkt): individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort des Nutzers; wobei das Kommunikations-/Steuerungs-/Regelungssystem wenigstens einen uni-/oder bidirektionalen Kommunikationspfad aus der folgenden Gruppe nutzt oder bereitstellt, insbesondere wenigstens drei bevorzugt drahtlose Kommunikationspfade umfasst oder nutzt, nämlich einen ersten Kommunikationspfad zwischen einer jeweiligen Person (Nutzer, Individuum) und einem Host und/oder einem Datenraum (Cloud), einen zweiten Kommunikationspfad zwischen einem/dem Host (Datenbe-/verarbeitungs-Entity) und der jeweiligen Person (Nutzer, Individuum) und/oder dem Datenraum (Cloud), und einen dritten Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber (Energie-/Klimaverwaltungs-Entity) und dem Host und/oder dem Datenraum (insbesondere Cloud);

- wobei das Kommunikations-/Steuerungs-/Regelungssystem für die wenigstens eine Person (Nutzer, Individuum) eine Eingabe-/Kommunikationsmaske (insbesondere mit GUI), insbesondere in Ausgestaltung als Internetseite und/oder basierend auf wenigstens einem programmcodetechnisch eingebetteten Inlineframe (insbesondere HTML5), insbesondere durch Cross Domain Content Management, zum Hinterlegen oder Eingeben (oder wahlweise auch Nachjustieren) wenigstens eines mit einer Stellgröße korrelierbaren subjektiven Komfort-Ratings (stärker, schwächer, größer, kleiner, mehr, weniger, oder konkrete Level wie z.B. „sehr warm“ oder „leicht unterdurchschnittlich kühl“, Unwohlsein/Discomfort, Wohlbehangen/Befindlichkeit) und/oder des wenigstens einen personenbezogenen Parameters als individuelle Nutzervorgabe über einen der Kommunikationspfade (insbesondere über den ersten Kommunikationspfad) bereitstellt, insbesondere über eine SmartPhone-Kommunikationsverbindung, nämlich des wenigstens einen mit wenigstens einem der Steuerungs-/Regelungsparameter korrelierbaren/korrelierten Komfort-Ratings für ein momentanes Hinterlegen in Echtzeit (subjektiver Stellparameter zur Vorgabe eines Soll-Wertes für wenigstens einen der Parameter, beispielsweise „Raumtemperatur“ oder „Raumfeuchte“ oder „Umluftbewegung/- zug/-konvektion“) und/oder (unmittelbar) des wenigstens einen personenbezogenen Parameters, zum Hinterlegen oder Abrufen einer individuellen personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik durch Pflege von personenspezifischen Klimapräferenzdaten im Datenraum, zum Generieren/Vorgeben des Steuerungs-/Regelungsparameters;
- wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist, die Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf momentanen und/oder mit Zeit-/Ortsbezug vorgegebenen Komfort-Ratings bzw. (Erfahrungs-)Werten und/oder basierend auf den hinterlegten, eingegebenen und/oder automatisiert abgerufenen zeit-/ortsaufgelösten personenbezogenen Parametern gemäß der in den Klimapräferenzdaten hinterlegten Nutzerpräferenz aus dem Datenraum zu generieren und insbesondere für einen/den HLK-/PCS-System-Betreiber bereitzustellen, insbesondere in Echtzeit, wobei das Kommunikations-/Steuerungs-/Regelungssystem bevorzugt zudem auch eingerichtet ist, die Komfort-Ratings und/oder die personenbezogenen Parameter mit den im jeweiligen Anwendungsfall anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern zu korrelieren, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose bei minimalem Energieverbrauch; wobei das Kommunikations-/Steuerungs-/Regelungssystem bevorzugt zudem auch noch eingerichtet ist für die dynamische Steuerung/Regelung des HLK-/PCS-Systems basierend auf dem wenigstens einen generierten Steuerungs-/Regelungsparameter insbesondere unter Nutzung des dritten Kommunikationspfades und bei/hinsichtlich bedarfsangepasster Energie-/Klima-Steuerung, insbesondere in Echtzeit; insbesondere mit dem Kommunikations- und Steuerungs-/Regelungssystem eingerichtet zum Ausführen eines weiter unten beschriebenen Verfahrens. Dies ermöglicht eine nutzerspezifische Steuerung und Regelung, insbesondere auch basierend auf der Konsolidierung eines nutzerspezifischen Komfortprofils über einen frei wählbaren zeitlichen (Nutzungs-)Verlauf. Subjektive Nutzer-Bewertungen (Ratings, Komfort-Empfinden) können bei der Datenverarbeitung und beim Generieren/Bereitstellen von personenspezifischen Klimapräferenzdaten (Nutzerpräferenzcharakteristik) zur Definition einer multivariaten Wahrscheinlichkeitsverteilung genutzt werden, derart dass unter Berücksichtigung von Vorhersagen über den subjektiven Komfort beeinflussenden Parametern die kontrollierbaren/steuerbaren/regelbaren Stellgrößen eines jeweiligen HLK-Systems für eine Maximierung des subjektiven nutzerspezifischen Komforts bei Minimierung des dafür erforderlichen Energiebedarfs ermittelt oder auch als Steuer-/Regelungsdaten unmittelbar vorgegeben werden können. Dies ermöglicht beispielsweise eine Temperaturregelung in einem Haus um unteren Schwellwert einer vom Nutzer oder von der Nutzergruppe gerade noch als komfortabel empfundenen Mindesttemperatur (unterer Schwellwert des nutzerspezifischen Komfort-Ratings), oder wahlweise auch eine Steuerung/Regelung von Konvektion, Luftfeuchte oder dergleichen Klima-Parametern. Der im Rahmen der vorliegenden Offenbarung angesprochene Parametersatz schließt z.B. auch Parameter im Zusammenhang mit den folgenden klimatischen Zuständen ein: advektive bzw. konvektive Wärmetransportphänomene, lüftungstechnische Parameter.

Die Erfindung basiert vornehmlich auf dem Konzept, Komfort-Ratings auf besonders einfache und nutzerfreundliche zu generieren und durch Zeit-und Ortsauflösung und wahlweise auch durch Gewichtung zu verarbeiten, zum Erstellen einer möglichst hochaktuellen und möglichst sehr individuellen klimatischen Nutzerpräferenzcharakteristik. Dabei kann auch wenigstens ein personenbezogener Parameter, wie z.B. eine Wunsch-Temperatur oder ein Soll-Ist-Abgleich zwischen Wunsch- und tatsächlicher Temperatur, berücksichtigt werden (sei es durch Eingabe seitens des Nutzers, sei es durch zumindest teilweise automatisiertes Abrufen). Hierdurch lassen sich steuerungs-/regelungstechnische Schwierigkeiten überwinden, denn ein individuelles Komfort-Empfinden kann auch dann unzureichend positiv sein, wenn zwar die Wunsch-Temperatur vom HLK-System exakt gehalten wird, jedoch andere Einflüsse wie z.B. Konvektion, Feuchte, Licht-Impact, persönliche momentane Aktivität oder Gesundheitszustand, zu einer Diskrepanz zwischen theoretisch optimalen Klimabedingungen und tatsächlich empfundenen klimatischen Zuständen führt. Die Erfindung ermöglicht, diese Diskrepanz auf sehr intuitive Weise mit sehr einfachen technischen Mittel und bei gutem Kompromiss aus Aufwand und Nutzen zu überwinden oder zumindest zu verringern, insbesondere dank orts-/systemunabhängiger Bereitstellung von Eingabe-Kommunikationsmasken bzw. GUIs für das nutzerspezifische Komfort-Rating. Auch auf Nutzergruppen (z.B. Wohngemeinschaften) lässt sich dieses Konzept anwenden, so dass die Erfindung auch einen Beitrag zu einem erträglicheren Miteinander leistet.
Dabei können subjektive Nutzer-Bewertungen (Ratings, Komfort-Empfinden) bei der Datenverarbeitung und beim Generieren/Bereitstellen von personenspezifischen Klimapräferenzdaten (Nutzerpräferenzcharakteristik) zur Definition eines Models genutzt werden, insbesondere in Form einer multivariaten Wahrscheinlichkeitsverteilung, einer Look-up Tabelle, eines Entscheidungsbaums, eines Regressionsmodells und/oder anderer heuristischer Ansätze, z.B. basierend auf Klassifikationsverfahren.
Die erfindungsgemäße Interaktion des Daten-Hosts an der Schnittstelle zwischen Nutzer und HLK-System-Betreibern und/oder Energie-Hosts ermöglicht einen sehr einfachen Zugang zu vergleichsweise komplexen Steuerung-/Regelungsaufgaben. Im einfachsten Fall authentifiziert sich ein Nutzer lediglich beim Daten-Host, z.B. über eine E-Mail-Adresse, und erhält daraufhin Zugang zur Pflege der nutzerspezifischen Klimapräferenzen. Für den Fall dass ein Nutzer sich zwar beim Daten-Host einloggt bzw. zu erkennen gibt, jedoch nur wenig oder gar nichts bezüglich der eigenen Klimapräferenzen bekannt gibt, kann der Nutzer beispielsweise über Alter, Geschlecht und/oder sonstige SocialMedia-Daten einer bereits bestehenden Nutzergruppe oder einer neu zu definierenden Nutzergruppe zugeordnet werden. Insofern erhält dieser Nutzer zunächst ein eher standardmäßiges Klima-/Komfortpräferenzprofil - sobald der Nutzer jedoch eigene Ratings abgibt und/oder den gewünschten Parametersatz definiert (letzterer kann z.B. auch von einem HLK-System-Betreiber bezüglich des jeweils vom Nutzer z.B. in dessen Ferienhaus genutzten HLK-Systems abgerufen werden), kann die Nutzerpräferenzcharakteristik konkretisiert werden. Gegebenenfalls ist der Nutzer daraufhin einer anderen Nutzergruppe zuzuordnen, z.B. einem eher inaktiven Jugendlichen mit größerem Bedarf an warmem Raumklima als z.B. einem sportlich sehr aktiven oder an Außenumgebungen gewöhnten Individuum.
In der vorliegenden Offenbarung werden die Begriffe Person, Nutzer, Individuum bzw. nutzerspezifisch, individuell, personenbezogen jeweils weitgehend synonym verstanden. Eine Person ist ein menschliches Wesen, und ein Individuum kann z.B. auch ein Haustier sein, und ein Nutzer ist eine Person oder ein Individuum, welches sich bereits für die Nutzung des erfindungsgemäßen Systems entschieden hat, also welche(s) identifizierbar und authentifizierbar ist. Diese begriffliche Diversifizierung ist auch darin begründet, dass Klimapräferenzdaten z.B. auch zumindest teilweise aus einer Personengruppe (insbesondere bekannten Altersdurchschnitts, Geschlechts, sonstiger Vorlieben) generiert werden können, ohne dass die jeweiligen Personen notwendigerweise auch Nutzer des vorliegenden Systems sein müssen.
Das jeweilige Komfort-Rating kann auch als nutzerseitig skalierbare relative Stellgröße verstanden werden. Ein Komfort-Rating ist standardmäßig mit einem Parametersatz zu verknüpfen, insbesondere um eine Korrelation des Ratings mit den Steuerungs-/Regelungsparametern für das jeweilige HLK-System zu erleichtern. Der Parametersatz muss jedoch nicht zwingend eine Klimazone betreffen, die aktiv gemessen wird, sondern wahlweise kann z.B. die Temperatur von einem Nutzer von einem beliebigen Thermometer abgelesen und manuell für die Datenpflege erfasst werden. Auch eine nur teilweise Erfassung eines/des Klima-Zustands ist realisierbar. Dies liefert zahlreiche variable Anwendungsmöglichkeiten. Dabei kann auch die Definition einer bestimmten Raumnutzung basierend auf Nutzereingaben erfolgen; wahlweise wird eine Raumnutzung/-belegung automatisch unter Zuhilfenahme von Innenraumlokalisierungs-Methoden ermittelt (z.B. GPS-Tracking). Wahlweise kann auch die (momentane) Aktivität des jeweiligen Nutzers im Zusammenhang mit der Erfassung und Relativierung der Komfort-Ratings berücksichtigt werden, z.B. über eine Puls-/Atemfrequenz und/oder über ein Bewegungsmuster. Insofern kann das Komfort-Rating als Stellgröße verstanden werden, welche sich zumindest teilweise vom Parametersatz entkoppeln lässt, z.B. indem die Steuerung/Regelung nicht temperaturbasiert sondern z.B. feuchtebasiert erfolgt, wenn der Nutzer ein Rating „behaglicher“ oder „wärmer“ als Wunschvorgabe eingibt, es aber bereits sehr warm im Raum ist.
Das erfindungsgemäße System/Verfahren ermöglicht, eine Steuerungs-/Regelungsebene auf effiziente Weise mit den subjektiv empfundenen Klima-Eindrücken von Nutzern zu koppeln, insbesondere auch in Hinblick auf eine Minimierung des Energiebedarfs. Das erfindungsgemäße System/Verfahren umfasst nicht notwendigerweise auch die Steuerungs-/Regelungsebene an der Schnittstelle zum jeweiligen HLK-System, denn dazu müssen gegebenenfalls technische Besonderheiten eines jeweiligen HLK-Systems bekannt sein; über derartige Informationen verfügt gegebenenfalls, je nach Anwendungsfall, vornehmlich der jeweilige HLK-System-Betreiber, so dass die vorliegende Erfindung auch bereits durch das Bereitstellen der entsprechenden Daten für den HLK-System-Betreiber realisierbar ist, basierend auf der jeweiligen durch den Host erstellten zeit- und/oder ortsaufgelösten Nutzerpräferenzcharakteristik, welche die vergangenen und momentanen Nutzer-Ratings berücksichtigt.
Das Kommunikations-/Steuerungs-/Regelungssystem ist eingerichtet für eine Zeit- und/oder Ortsauflösung der nutzerspezifischen Komfort-Ratings (Sp) und der personenbezogenen Parameter (Sp). Der Begriff „Kommunikations- und Steuerungs-/Regelungssystem“ ist dabei derart zu verstehen, dass das System in einem ersten Schritt lediglich zum Generieren und Bereitstellen der für die Steuerung/Regelung vorgesehenen Daten eingerichtet ist (Datenkommunikationssystem bzw. Datenerhebungs- und aufbereitungssystem). In einem zweiten Schritt kann optional auch eine Koppelung an das jeweilige HLK-/PCS-System erfolgen, zwecks unmittelbarer Steuerung/Regelung durch das System selbst. Bevorzugt erfolgt jedoch eine Datenübergabe an der Schnittstelle zum jeweiligen Host, wodurch das erfindungsgemäße Verfahren/System breiter nutzbar und vielseitiger anwendbar ist. Demnach ist der Begriff „Kommunikations- und Steuerungs-/Regelungssystem“ dabei derart zu verstehen, dass das System wahlweise als ein reines (Daten-)Kommunikationssystem ohne direkte Steuerungs-/Regelungsfunktion ausgestaltete ist, welches sich jedoch in ein Steuerungs-/Regelungssystem integrieren oder damit verknüpfen lässt, also im Sinne eines Kommunikations- und optional auch Steuerungs-/Regelungssystems. Anders ausgedrückt: Der begriffliche Hinweis auf eine Steuerungs-Regelungs-Komponente impliziert noch nicht notwendigerweise auch die Implementierung einer Steuerungs-/Regelungs-Funktion. Dieser Aspekt ist nicht zuletzt von Bedeutung hinsichtlich möglichst breiter und variabler Implementierungs-Möglichkeiten, insbesondere vor dem Hintergrund dass die Steuerungs-/Regelungsseite von HLK-Systemen in vielen Fälle auch z.B. von einem Energielieferanten sichergestellt wird, beispielsweise im Zusammenhang mit erneuerbaren Energien. Demnach ist der Begriff „Kommunikations- und Steuerungs-/Regelungssystem“ dabei zunächst (nur) im Sinne eines Datenerhebungs-/verarbeitungssystems zu verstehen. Somit sind die Begriffe „Kommunikations- oder wahlweise zusätzlich auch Steuerungs-/Regelungssystem“ und die Begriffe „Datenerhebungs-/verarbeitungssystem“ im Rahmen der vorliegenden Offenbarung zumindest für all jene Varianten der Erfindung synonym zu verstehen, bei welchen keine Steuerung/Regelung als solche erfolgt, sondern bei welchen lediglich die Aufbereitung und Bereitstellung von Nutzerpräferenzcharakteristiken bzw. Klimapräferenzdaten erfolgt, derart dass darauf basierend eine nutzerspezifische und komforttechnisch und energetisch optimierte Steuerung/Regelung realisierbar wird.
Die Eingabe-/Kommunikationsmaske ist eingerichtet zum Hinterlegen des jeweiligen Komfort-Ratings (Sp), insbesondere skaliert über eine Skala (Intensität einer Empfindung) oder durch Gewichtung, und/oder des wenigstens einen personenbezogenen Parameters (Sp) durch den Nutzer. Das Kommunikations-/Steuerungs-/Regelungssystem ist dabei bevorzugt auch eingerichtet, die Komfort-Ratings und/oder die personenbezogenen Parameter mit den im jeweiligen Anwendungsfall anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern zu korrelieren, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose, insbesondere bei minimiertem Energieverbrauch. Dies ermöglicht auch eine verbesserte Steuerung/Regelung bei in energetischer Hinsicht sehr trägen bzw. langsamen HLK-Systemen.
Als Datenbe-/verarbeitungs-Entity ist insbesondere ein Datenbankanbieter bzw. Information Provider zu verstehen, welcher sich einerseits mit der Datenerfassung, Datenpflege und Datenaufbereitung befasst, und andererseits eine Datenbereitstellung zu weiteren Hosts oder Drittanbietern sicherstellt. Die Datenbe-/verarbeitungs-Entity kann dabei auch die Back-End-Seite betreuen und einem Nutzer den Zugang zur Datenpflege ermöglichen (Front-End). Die Datenbearbeitungs-Entity kann im Rahmen des hier beschriebenen Verfahrens/Systems insbesondere auch eine Daten-Fit-Methode anwenden, mittels welcher die subjektive Bewertung bzw. die nutzerspezifischen Ratings und Stellgrößen (auch die Stellgrößen können nutzerspezifisch sein, z.B. wünscht ein Nutzer ausschließlich eine Regelung der Temperatur, nicht aber der Luftfeuchte) durch den Nutzer in einem Präferenzraum (Klimapräferenzdaten) bei Korrelation bzw. unter Berücksichtigung relevanter beeinflussender Faktoren und/oder Parameter und/oder Randbedingungen ablegt und für weitere Anwendungen nutzbar gemacht und bereitgestellt werden kann.
Eine jeweilige Stellgröße kann dabei ebenfalls mit einer Nutzerpräferenz korreliert sein; beispielsweise für einen Nutzer, dem vornehmlich die Temperatur wichtig ist, wird die Stellgröße auf Temperaturregelungsparameter bezogen, und für einen Nutzer, der an einem starken Luftaustausch und reiner Luft interessiert ist, wird die Stellgröße möglicherweise stärker mit einem Konvektionsregelungsparameter korreliert, und ein Temperaturregelungsparameter mag dann in der Hierarchie nachgeschaltet bzw. niedriger sein. Auch insofern unterscheidet sich eine Stellgröße, die wahlweise auch aus der Nutzerpräferenzcharakteristik generierbar ist, von den gegebenenfalls HLKsystemspezifischen Steuerungs-/Regelungsparametern für technisch-klimatische Justage-Vorgänge.
Der momentane Aufenthaltsort bzw. Aufenthaltsorts-Parameter des jeweiligen Nutzers kann dabei auch in Korrelation mit einer Raumkennzahl gebracht werden, insbesondere mit einer Raumkennzahl, in welche zumindest die Art des Raumes und die Belegung des Raumes eingehen. Auch den weiteren Parametern können jeweils eine oder mehrere charakterisierende Kennzahlen zugrunde gelegt werden, je nach Anwendungsfall und Komplexität der Steuerungs-/Regelungs-Aufgabe.
Als HLK-/PCS-System ist insbesondere wenigstens ein System aus der folgenden Gruppe zu verstehen: Heizungs- und/oder Lüftungs- und/oder Klimatisierungs-System (HLK-System) bzw. Heating and/or Ventilation and/or Air Conditioning-System, beispielsweise eine individualisierbare Raumheizung, Belüftung oder Klimaanlage in einem Haus, Personalized Conditioning System (PCS-System), beispielsweise Wärmestrahler (z.B. am Arbeitsplatz, z.B. für eine Tastatur), Sitzheizung, Fußwärmer.
Als SmartPhone-Kommunikationsverbindung (oder dergleichen Kommunikationsverbindung wie z.B. Tablet-, SmartWatch-, Kommunikationsmodul-Kommunikationsverbindung) ist insbesondere eine Kommunikationsverbindung zu einem mobilen kommunizierenden Endgerät eines Nutzers zu verstehen, welche auf den üblichen Kommunikationspfaden über Telefonnetze, Internet oder dergleichen geknüpft werden kann.
Unter dem Begriff „in Echtzeit“ ist insbesondere eine für eine momentane Regelung des HLK-/PCS-Systems basierend auf bereits hinterlegten oder momentan vorgegebenen Parametern erforderliche oder vorteilhafte Reaktionszeit zu verstehen, bei welcher eine Regelung ohne spürbare Zeitverzögerungen auch über große Distanzen zwischen Nutzer und HLK-/PCS-System ermöglicht wird, also rund um den Erdball. Für eine reine Steuerung ohne Regelung muss nicht notwendigerweise eine Echtzeit-Regelungsmöglichkeit realisiert sein. Insbesondere bei sehr schnellen HLK-/PCS-Systemen mit wenig Trägheit und schneller Reaktionszeit, z.B. bei Lüftungssystemen, kann die minimale Reaktionszeit jedoch auch bereits für Steuerungsaspekte vorteilhaft sein, z.B. wenn ein Nutzer spontan die Nutzerpräferenzcharakteristik verändert bzw. umstellt.
Als Kommunikationspfad ist insbesondere eine weitgehend beliebige kommunikative Verbindung zwischen den hier jeweils im Einzelnen beschriebenen Absendern und Empfängern zu verstehen, insbesondere unter Berücksichtigung technischer Anforderungen oder Wünsche hinsichtlich Datenübertragungsrate und Übertragungszeit(-verlusten). Der jeweilige Kommunikationspfad kann drahtlos oder drahtgebunden sein.
Auf dem ersten Kommunikationspfad werden bevorzugt Daten seitens des Nutzers an den Host gesendet. Über den zweiten Kommunikationspfad erfolgt bevorzugt eine Datenpflege bzw. Datenbe-/verarbeitung durch den Host (insbesondere zur Erstellung der Nutzerpräferenzcharakteristik). Über den dritten Kommunikationspfad werden bevorzugt die Klimapräferenzdaten für wenigstens einen weiteren Host bzw. für einen HLK-System-Betreiber bzw. für eine Energieverwaltungs-Entity bereitgestellt.
Mit anderen Worten kann die Erfindung auch wie folgt beschrieben werden:

Bereitgestellt wird eine Kommunikations- und Steuerungs-/Regelungssystem zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist zum Generieren/Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf einer personenbezogenen Parametergruppe (GPp) zumindest umfassend die folgenden personenbezogenen zeit- und/oder ortsaufgelösten Parameter: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort (GPSp) des Nutzers; wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist, über wenigstens drei Kommunikationspfade zu kommunizieren bzw. Daten auszutauschen, nämlich über eine Kommunikationspfad zwischen einer jeweiligen Person und einem Host und/oder über eine Kommunikationspfad zwischen dem Host und dem Datenraum und/oder über einen Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Host und/oder dem Datenraum; wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist, für die wenigstens eine Person eine Eingabe-/Kommunikationsmaske zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum bereitzustellen, insbesondere durch Cross Domain Content Management, zum Hinterlegen oder Eingeben wenigstens eines über die Eingabe-/Kommunikationsmaske skalierbaren subjektiven Komfort-Ratings (Sp) und/oder des wenigstens einen personenbezogenen Parameters (Pp), zum Erstellen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik durch den Host und zum Generieren/Vorgeben des personenbezogenen Steuerungs-/Regelungsparameters (Pp) basierend auf der Nutzerpräferenzcharakteristik; wobei die Komfort-Ratings (Sp) zeit- und/oder ortsaufgelöst sind/werden; wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist zum Bereitstellen der zeit-/ortsaufgelösten Komfort-Ratings (Sp) und Steuerungs-/Regelungsparameters (Pp) für einen/den HLK-/PCS-System-Betreiber für die dynamische Steuerung/Regelung des jeweiligen HLK-/PCS-Systems, insbesondere in Echtzeit; insbesondere mit dem Kommunikations- und Steuerungs-/Regelungssystem eingerichtet zum Ausführen eines weiter unten im Einzelnen beschriebenen Verfahrens. Bevorzugt ist das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose basierend auf den Komfort-Ratings (Sp) und/oder personenbezogenen Parametern (Pp), insbesondere bei minimiertem Energieverbrauch.

Demnach basiert die Erfindung auch auf dem Konzept, die folgenden Prozesse miteinander zu korrelieren: Steuern/Regeln von HLK-Systemen durch Bereitstellen von nutzerspezifischen Klimapräferenzdaten seitens einer Datenverarbeitungs-Entity; Definition des verwendbaren Parametersatzes; Erfassen von Komfort-Ratings (insbesondere zeit-/ortsaufgelöst) und Bildung/Hinterlegung der nutzerspezifischen Klimapräferenzcharakteristik und Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose (insbesondere durch Datenverarbeitungs-Entity); Bereitstellung der Klimapräferenzdaten; optional: aktive Steuerung/Regelung des HLK-Systems basierend auf den Klimapräferenzdaten; wahlweise: Vorgeben unterschiedlicher Kommunikationspfade;
Die Erfindung ermöglicht es insbesondere auch, die folgenden Aspekte zusammen miteinander zu berücksichtigen bzw. ein System/Verfahren bereitzustellen, um synergetische Effekte beim (simultanen) Realisieren einzelner oder aller dieser Aspekte zu ermöglichen: Definition des verwendbaren Parametersatzes (insbesondere Temperatur, Feuchte; Zeit- und/oder Ortsauflösung, z.B. indem der Nutzer Raumnutzungen-/belegungen vordefiniert); Komfort-Rating als nutzerseitig skalierbare relative Stellgröße, die losgelöst vom im jeweiligen Einzelfall verfügbaren oder gewählten Parametersatz durch den Nutzer geregelt werden kann, und dabei auch zumindest teilweise vom Parametersatz entkoppelt werden kann (Abfrage des relativ empfundenen Wärmeempfindens anstelle einer konkreten technischen Wunsch-Temperatur), wobei die Komfort-Rating auch mit zeitabhängiger Gewichtung der einzelnen Ratings desselben Nutzers untereinander berücksichtigt werden können; Cross Domain Content Management, insbesondere in Ausgestaltung als Inlineframes, zur erleichterten Zugänglichmachung der erfindungsgemäßen System-Funktionalität; Korrelation von Nutzerpräferenzcharakteristiken mit aktuellen externen Parametern (z.B. Wetter, Aufenthaltsort, Aktivität), insbesondere auch mittels bzw. basierend auf KI-basierten Algorithmen; Definition von Nutzergruppen und (optionale) Gewichtung des Einflusses eines Ratings unter den Nutzern innerhalb einer Gruppe, wobei Daten über die klimatischen Wünschen dieser Nutzergruppen wahlweise auch aus externen Datenbanken zuführbar sind; automatisches Anfahren einer unteren Toleranzgrenze, zwecks Bestimmung eines nutzerspezifisch möglichen Energieverbrauchs-Minimums; Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose (Blick in die Zukunft);
Insbesondere für das Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose liefert das erfindungsgemäße System/Verfahren sowohl in kurzfristiger (Minuten, Stunden) als auch in mittelfristiger (Stunden, Tage, Wochen) bis langfristiger Hinsicht (Wochen, Monate, Jahre) eine Datenbasis, welche das nutzerspezifische und energieoptimierte Steuern/Regeln von jeglicher Art von HLK-/PCS-Systemen erleichtert. Die Erzeugung einer Präfrenzcharakteristik basierend auf der Erfassung von Komfort-Ratings in beliebiger Umgebung und dessen momentaner nutzerspezifischer Zustand liefert einen Datensatz, welcher auf HLK/PCS-Systeme portierbar ist, insbesondere auf solche System anwendbar ist, die eine Komfort-Trajektorie als Steuerungs-/Regelungsgröße lesen bzw. auswerten können. Dabei ist die Klima-Präferenzcharakteristik derart ausgestaltet, dass sie kombinierbar mit derjenigen von anderen Anwendern ist. Dies ermöglicht nicht zuletzt auch die Bereitstellung eines auf einem sehr breiten Datengrundstock aufgestellten System, welches dem Nutzer insbesondere dank Cross Domain Content Management in weitgehend beliebig konditionierter Umgebung ermöglicht (gegebenenfalls auch in Abhängigkeit der Belegung durch weitere Nutzer), die bestmögliche individuell angepasste Komfort-Erfahrung bei minimalen Energieeinsatz machen zu können, z.B. einen sehr angenehmen Hotelaufenthalt zu erfahren, ohne dass der Hotelbetreiber dafür einen besondere hohen Energieverbrauch tragen muss.
Gemäß einem Ausführungsbeispiel ist der wenigstens eine Steuerungs-/Regelungsparameter basierend auf den Komfort-Ratings auf automatisierte Weise für den jeweiligen Nutzer für eine nutzerspezifische Energieverbrauchsoptimierung generierbar, indem basierend auf den Komfort-Ratings ein nutzerspezifischer unterer Energieverbrauchslevel entsprechend einem unteren Komfort-Schwellwert ermittelt wird, insbesondere durch Vorgeben eines minimal kleinen nutzerspezifischen Verhältnisses aus einer Energieverbrauchskennzahl und einer Komfort-Kennzahl.
Gemäß einem Ausführungsbeispiel umfasst die Parametergruppe auch einen nutzerspezifischen Aktivitäts-Parameter, insbesondere charakterisierend die Art der Aktivität und die Nutzerpräferenz für die jeweilige Aktivität, wobei die Nutzeraktivität wahlweise gemäß dem hinterlegten Nutzerverhalten und/oder Aufenthaltsort prognostiziert und/oder durch Bezugnahme auf einen Tageszeit-/Jahreskalender und/oder basierend auf einer momentanen Herz-/Atemfrequenz oder einem Bewegungsprofil des Nutzers geschätzt/vordefiniert ist. Dies ermöglicht auch die energieverbrauchsoptimierte Steuerung/Regelung in Abhängigkeit der physiologischen organismusbezogenen und/oder tätigkeitsbezogenen Aktivität (Art der Tätigkeit, Belastung des Organismus). Es hat sich gezeigt, dass ein ruhendes Individuum in vielen Situationen einen größeren Bedarf an einem warmen, behaglichen Raumklima hat als ein sehr aktives Individuum. Durch eine Berücksichtigung der Aktivität ermöglicht das erfindungsgemäße System auch ein noch größeres Energieeinsparungspotential. Die momentane Herz-/Atemfrequenz und/oder das Bewegungsprofil des Nutzers kann beispielsweise über eine SmartWatch erfasst und an das hier beschriebene System als zusätzlicher personenbezogener Parameter übermittelt werden. Wahlweise kann auch ein Blutdruck berücksichtigt werden, z.B. indem bei Personen mit sehr niedrigem Blutdruck tendenziell eine wärmere Umgebung geschaffen wird.
Gemäß einem Ausführungsbeispiel ist die durch den Nutzer über die individuellen Klimapräferenzdaten gepflegte personenbezogene Parametergruppe wahlweise auch mit wenigstens einem der folgenden nicht-personenbezogenen Parameter korreliert, zum Generieren/Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters: prognostizierte ortsbezogene Außenklimabedingung, Tageszeit, Kalenderdatum. Auch des begünstigt eine situationsoptimierte Energieeinsparung.
Gemäß einem Ausführungsbeispiel sind die Klimapräferenzdaten vom jeweiligen Nutzer optional zeitspezifisch und/oder ortsspezifisch hinterlegbar, insbesondere basierend auf Geofencing durch Korrelation der Klimapräferenzdaten mit GPS-Daten eines momentanen Aufenthaltsortes des jeweiligen Nutzers und/oder mit für den Aufenthaltsort des Nutzers verfügbaren Wetterdaten (Außenklimabedingungen, Umweltparameter). Basierend auf Geofencing ist eine implizite Schlussfolgerung bezüglich des momentanen Aufenthaltsortes des Nutzers realisierbar. Wahlweise kann beim Geofencing oder in Kombination mit Geofencing (oder auch alternativ dazu) auch eine/die momentane örtliche Distanz des Nutzers zu dessen privaten Räumen (Privatadresse, Büro, Ferienwohnung) berücksichtigt werden, beispielsweise über einen Distanz-/Abstandsparameter. Dies begünstigt auch eine zielsicherere, belastbarere, weniger fehleranfällige Steuerung/Regelung des entsprechenden HLK-/PCS-Systems zur Vorgabe eines Ein-/Ausschaltzeitpunktes und/oder einer Vorlaufzeitdauer.
Gemäß einem Ausführungsbeispiel ist eine/die Zeitauflösung auf einen momentanen Tageszeitpunkt bezogen, insbesondere in Hinblick auf eine in den Klimapräferenzdaten hinterlegte Nutzerpräferenz mit Tagesverlaufs-Zeitabhängigkeit. Dies kann die Energiebedarfsoptimierung weiter spezifizieren, insbesondere in Hinblick auf einen stärkeren Effekt des subjektiven Empfindens (beispielsweise am Wochenende größeres Behaglichkeits-Bedarfs-Empfinden, beispielsweise zum Tagesende stärkerer Bedarf hinsichtlich warmem, optimalem Raumklima).
Gemäß einem Ausführungsbeispiel ist die Eingabe-/Kommunikationsmaske eingerichtet zum Definieren von personenbezogenen Zeitfenstern oder Tageszeitabschnitten individueller Dauer für den Aufenthalt des jeweiligen Nutzers an spezifischen Orten oder in spezifischen Wohnräume, insbesondere unter Berücksichtigung eines momentanen Aufenthaltsorts des Nutzers. Dies begünstigt die Optimierung der Steuerung/Regelung auch in Hinblick auf mehrere Aufenthaltsorte des jeweiligen Nutzers, insbesondere unter Beachtung von Trägheiten und Reaktionszeiten von HLK-Systemen.
Die Trägheit von HLK-Systemen, insbesondere in größeren Gebäuden bzw. bei stark schwankenden außenklimatischen Einflüssen, ist ein nicht zu unterschätzender (Neben-)Effekt, den auch die HLK-System-Betreiber in vielen Fällen nur unzureichend beherrschen. Insofern liefert die vorliegende Erfindung auch die technischen Mittel, diese (Neben-)Effekt basierend auf der Mitwirkung der Nutzer oder auch (zumindest zeitweise oder zumindest bezüglich konkretisierter Einzel-Steuerungs-/Regelungsaufgaben) lediglich basierend auf sensorisch erfassbaren Daten von z.B. offen zugänglichen Temperatursensoren (Daten-Schnittstelle auf sensorischer Ebene) in den Griff zu bekommen.
Gemäß einem Ausführungsbeispiel sind vom jeweiligen Nutzer momentane Aufenthaltsortsdaten über den wenigstens einen Kommunikationspfad übermittelbar und/oder vom Host abrufbar. Dies begünstigt auch einen Abgleich von realen tatsächlichen Zuständen mit prognostizierten oder geschätzten Zuständen, insbesondere im Sinne einer Plausibilitätsprüfung.
Gemäß einem Ausführungsbeispiel umfasst die Parametergruppe wenigstens einen weiteren Parameter aus der folgenden Gruppe: nutzerspezifischer Aktivitäts-Parameter, insbesondere zeit- und/oder ortsaufgelöst; prognostizierte ortsbezogene und zeitaufgelöste Außenklimabedingung (insbesondere Temperatur, Wind-Chill-Faktor oder dergleichen), korreliert mit wenigstens einem der personenbezogenen Parameter. Dies ermöglicht auch eine Berücksichtigung tatsächlicher momentaner Energiebedarfs-Szenarien, selbst dann, wenn im Haus bzw. Gebäude des Aufenthaltsorts des Nutzers keine Installationen zur Anpassung von HLK-Systemen an z.B. die momentane Sonneneinstrahlung oder die momentane Außentemperatur vorgesehen sind. Dadurch lässt sich mit dem erfindungsgemäßen System/Verfahren auch ein großer sensorischer und messtechnischer Installations-Aufwand einsparen.
Gemäß einem Ausführungsbeispiel sind die Klimapräferenzdaten personenbezogene Metadaten umfassen, die aus einer subjektiv erlebten thermischen/klimatischen Erfahrung des jeweiligen Nutzers aus bereits erfassten/erzeugten Klimapräferenzdaten und/oder aus den nutzerspezifischen Komfort-Ratings generiert, zur Anpassung und zukünftigen Vorgabe des wenigstens einen Steuerungs-/Regelungsparameters. Basierend auf Metadaten kann einerseits das Nutzerverhalten ausgewertet werden, insbesondere die Tendenz/Neigung eines Nutzers zu wiederholtem Nachjustieren von Präferenzen und/oder zum Beklagen/Kritisieren erlebter Klimabedingungen, und andererseits kann ein personenbezogener Toleranzparameter generiert werden, zum Vorgeben von Schwellwerten für eine Steuerung/Regelung des HLK-/PCS-Systems zur Vermeidung einer Unter-/Überklimatisierung. Somit kann auch der Energieaufwand für tolerantere Nutzer minimiert werden (z.B. ein Nutzer akzeptiert eine Obergrenze von 26°C in einem Raum in einer sehr heißen Umgebung mit Außentemperaturen von über 35°C; für diesen Nutzer kann mehr Energie eingespart werden als für einen empfindlicheren bzw. intoleranteren Nutzer, dessen oberer Schwellwert bereits bei nur 22°C liegt).
Gemäß einem Ausführungsbeispiel umfassen die Klimapräferenzdaten personenbezogene Metadaten, die mit einem personenbezogenen Bewertungshistorienparameter korreliert sind, welcher den Zeitpunkt oder das Alter eines Komfort-Ratings oder Nutzerpräferenzcharakteristik in die Datenverarbeitung durch den Host einbezieht. Dies ermöglicht auch, eine Präferenztendenz oder Entwicklung der Nutzergewohnheiten zu berücksichtigen (historisch bezogene Auswertung von Nutzerpräferenztendenzen), beispielsweise auch in einer Phase, in welcher ein neugeborener Nutzer in den ersten Monaten von einer besonders warmen Umgebung tagsüber und einer eher kühlen Umgebung nachts in eine klimatische Umgebung wechselt, die stärker den Präferenzen eines erwachsenen Nutzers ähnelt (nachts wärmer, tagsüber kühler). Dies kann z.B. auch über eine zeitaufgelöste Aufenthaltsortswechsel-Kennzahl berücksichtigt werden, welche in den Ortsparameter (GPSp) einfließen kann. Oder bei Nutzern, die über einen längeren Zeitraum älter und schwächer werden und weniger aktiv werden und daher mehr Wärme (Energie) benötigen.
Nicht zuletzt kann auch ein Betrag einer klimatischen Abweichung von den Soll-Bedingungen und auch deren Zeitanteil Berücksichtigung finden, insbesondere zur Korrelation dieser Situation mit einem aktuellen Komfort-Rating, das gegebenenfalls krasser ausfallen wird, wenn ein Nutzer zuvor über einen längeren Zeitraum klimatisch enttäuscht wurde. Eine solche Kennzahl kann z.B. als Zufriedenheitsgrad- oder „Discomfort“-Kennzahl bei der Gewichtung der einzelnen Ratings Berücksichtigung finden.
Gemäß einem Ausführungsbeispiel ist eine nutzerspezifische Sollwert-Trajektorie unter Berücksichtigung einer klimatischen Trägheit eines entsprechenden HLK-/PCS-Systems zur Vorgabe des wenigstens einen Steuerungs-/Regelungsparameters aus den Klimapräferenzdaten generierbar und in zeitlicher Hinsicht auf die Steuerung/Regelung des HLK-/PCS-Systems adaptierbar, insbesondere basierend auf einer HLK-/PCS-systemimmanenten Regelungslogik, letztere insbesondere bereitgestellt oder bereitstellbar seitens des HLK-/PCS-System-Betreibers, insbesondere zwecks Energieeinsparung. Diese Regelungs-Option kann optional seitens des (Energie-)Hosts und/oder seitens des jeweiligen HLK-/PCS-System-Betreibers implementiert werden, insbesondere um den tatsächlichen Energieverbrauch weiter senken zu können und/oder die Genauigkeit bei der Verwirklichung der Sollwert-Trajektorie zu vergrößern. Die Sollwert-Trajektorie kann dabei als eine spätere Stufe der Datenaufbereitung verstanden werden, welcher eine Erstellung einer Wahrscheinlichkeitsverteilung aus den Klimapräferenzdaten vorgelagert ist.
Gemäß einem Ausführungsbeispiel eine nutzerspezifische Sollwert-Trajektorie unter Berücksichtigung einer klimatischen Trägheit eines entsprechenden HLK-/PCS-Systems auf die Regelung des HLK-/PCS-Systems in zeitlicher Hinsicht adaptierbar, indem ein HLK-/PCS-Systemspezifischer Trägheits-Zeitwert bei der Steuerung/Regelung des entsprechenden HLK-/PCS-Systems zur Vorgabe eines Ein-/Ausschaltzeitpunktes und/oder einer Vorlaufzeitdauer (nutzerspezifische Phase für antizipierender Energiezufuhr oder Energieentnahme) für das HLK-/PCS-System vorgebbar ist, insbesondere basierend auf einer HLK-/PCS-systemimmanenten Regelungslogik, insbesondere unter Berücksichtigung der thermischen Eigenschaften der jeweiligen Klimaumgebung und durch Abgleich von Soll- und Ist-Klimazeitreihen. Die Berücksichtigung einer Vorlaufzeit ermöglicht insbesondere bei vergleichsweise großen Gebäuden oder Räumen (z.B. großes Wohnzimmer im Erdgeschoss bei nicht isoliertem oder nicht vorhandenem Keller) eine Effektivitätssteigerung von Energieeinsparungsmaßnahmen.
Gemäß einem Ausführungsbeispiel ist der wenigstens eine Steuerungs-/Regelungsparameter basierend auf einer Gewichtung des jeweiligen Alters mehrerer Komfort-Ratings desselben Nutzers auf automatisierte Weise generierbar, indem das jeweils jüngste Komfort-Rating des Nutzers mit der momentan stärksten Gewichtung attributiert ist/wird, insbesondere derart, dass die Nutzerpräferenzcharakteristik durch zeitlich gewichteten Klimapräferenzdaten gekennzeichnet ist, insbesondere bei mit der seit dem entsprechenden Rating vergangenen Zeit exponentiell fallender Abhängigkeit.
Gemäß einem Ausführungsbeispiel ist die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise basierend auf dem wenigstens einen Steuerungs-/Regelungsparameter durchführbar, wobei dieser wenigstens eine Steuerungs-/Regelungsparameter ein gemittelter Steuerungs-/Regelungsparameter oder ein bezüglich eines oder mehrerer Nutzer/Individuen gewichteter Nutzerdatenverarbeitungsparameter ist (z.B. umfassend eine Nutzerpräferenzverteilungskennzahl), der aus einer Mehrzahl von individuellen Steuerungs-/Regelungsparametern mehrerer Personen gebildet ist, insbesondere in Echtzeit in Abhängigkeit einer momentanen oder vordefinierten Belegung eines geschlossenen Raumes durch die mehreren Individuen. Die Mittelung oder Gewichtung unter einer Vielzahl von Nutzern ermöglicht auch die energetische oder komfortorientierte Optimierung des Energieverbrauchs z.B. in Gemeinschaftshaushalten, bei großen Familien, bei Einzelpersonen mit Haustieren, bei einem Ehepaar mit einem neugeborene Kind, oder dergleichen differenzierten Nutzergruppen-Zusammensetzung.
Wahlweise kann bei einer Gewichtung unter einer Mehrzahl von Nutzern auch ein Ausschluss bestimmter oder aller weiterer Nutzer vorgenommen werden, wenn ein einzelner Nutzer mit bestimmten vordefinierten Merkmalen in der Nutzergruppe vorhanden ist bzw. im Raum anwesend ist, z.B. wenn die alleinerziehende Mutter mit zwei Kindern in einem Haushalt im Raum anwesend ist, dass dann die Sollwert-Trajektorie allein basierend auf der Nutzerpräferenzcharakteristik der Mutter erstellt wird. Wenn die Mutter nicht anwesend ist, wird die Sollwert-Trajektorie basierend auf einer Mittelung bzw. Gewichtung der Nutzerpräferenzcharakteristiken der beiden Kinder erstellt. Insofern kann der Begriff „Gewichtung“ auch die Ausblendung von weiteren Personen umfassen, wenn eine/die als am wichtigsten/prioritär definierte Person anwesend ist.
Gemäß einem Ausführungsbeispiel ist das kommunikative Steuern/Regeln durch den wenigstens einen Nutzer über die Eingabe-/Kommunikationsmaske realisierbar, indem über eine Internetseite, die in programmcodetechnischer Einbettung wenigstens einer GUI und/oder wenigstens eines Inlineframes in eine weitere (insbesondere systemfremde) Internetseite integriert ist, insbesondere HTML5, die Angaben des Nutzers bezüglich subjektiver Komfort-Ratings und/oder des wenigstens einen personenbezogenen Parameters hinterlegbar bzw. anpassbar sind. Die Erfassung bzw. Eingabe von Komfort-Ratings ermöglicht insbesondere mittels Inlineframes eine Implementierung des Systems/Verfahrens auf einfache Weise, sowohl auf Front-End-Seite als auch auf Back-End-Seite. Das erfindungsgemäße System/Verfahren kann daher auch ohne vordefinierte HLK-Systembedingungen bzw. ohne messtechnische Anforderungen implementiert werden. Auch insofern kann das erfindungsgemäße System/Verfahren die komfort- und energiebezogene Optimierung im Wesentlichen nutzergesteuert und nutzerseitig implementiert realisieren.
Gemäß einem Ausführungsbeispiel ist das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet zur Auswertung der zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose durch Invertierung, indem momentane oder zukünftige Ist-Werte der Steuerungs-/Regelungsparameter mit den Klimapräferenzdaten des jeweiligen Nutzers korrelierbar sind und indem eine zu erwartende Nutzerpräferenz deduktiv im Rückschluss von vorgegebenen oder tatsächlich gemessenen klimatischen Zuständen ermittelbar ist, insbesondere für eine Last-/Energieverbrauchsreduktion in Abhängigkeit des vorhergesehenen bzw. zu erwartenden Nutzerverhaltens und momentanen oder zukünftigen Nutzer-Aufenthaltsortes. Hierdurch kann auch eine nutzerspezifische Historie (zeitliche Auswertung von Nutzerdaten) für die energetische Optimierung herangezogen werden, insbesondere auch im Zusammenhang mit Post-Stay-Ratings, z.B. bei Abgabe eines Feedbacks des Nutzers erst nach einem Hotelaufenthalt.
ITEM1 Zumindest eine der zuvor genannten Aufgaben wird auch gelöst durch ein Kommunikations- und Steuerungs-/Regelungssystem zur Datenaufbereitung und Datenbereitstellung zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist zum Bereitstellen von Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters aus einer personenbezogenen Parametergruppe (GPp) zumindest umfassend die folgenden personenbezogenen zeit- und/oder ortsaufgelösten Parameter: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort (GPSp) des Nutzers; wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist, Daten über wenigstens drei Kommunikationspfade auszutauschen, nämlich über eine Kommunikationspfad zwischen einer jeweiligen Person und einem Host und/oder über eine Kommunikationspfad zwischen dem Host und dem Datenraum und/oder über einen Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Host und/oder dem Datenraum; wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist, für die wenigstens eine Person eine Eingabe-/Kommunikationsmaske zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum bereitzustellen, insbesondere durch Cross Domain Content Management, zum Hinterlegen wenigstens eines subjektiven Komfort-Ratings (Sp) und/oder des wenigstens einen personenbezogenen Parameters (Pp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Erstellen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4) und zum Generieren und Bereitstellen der Klimapräferenzdaten zum Vorgeben des personenbezogenen Steuerungs-/Regelungsparameters (Pp) basierend auf der Nutzerpräferenzcharakteristik; wobei die Komfort-Ratings (Sp) zeit- und/oder ortsaufgelöst sind; wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist zum Bereitstellen der zeit-/ortsaufgelösten Komfort-Ratings (Sp) in Form von nutzerspezifischen Klimapräferenzdaten zum Bestimmen des entsprechenden Steuerungs-/Regelungsparameters (Pp) für einen/den HLK-/PCS-System-Betreiber, insbesondere in Echtzeit; insbesondere mit dem Kommunikations- und Steuerungs-/Regelungssystem eingerichtet zum Ausführen eines weiter unten im Einzelnen beschriebenen Verfahrens; wobei das Steuern/Regeln durch den wenigstens einen Nutzer über die Eingabe-/Kommunikationsmaske realisierbar ist, indem über eine Internetseite, die in programmcodetechnischer Einbettung wenigstens einer GUI und/oder wenigstens eines Inlineframes in eine weitere Internetseite integriert ist, die Angaben des Nutzers bezüglich subjektiver Komfort-Ratings und/oder des wenigstens einen personenbezogenen Parameters hinterlegbar oder anpassbar sind, wobei das Kommunikations- und Steuerungs-/Regelungssystem auf wenigstens einem der Kommunikationspfade wenigstens eine offene Programmierschnittstelle zur Verlinkung oder programmiertechnischen Einbettung von in maschinenlesbarer Sprache geschriebenen Elementen, insbesondere HTML-Elemente, bereitstellt, insbesondere eine REST API.
ITEM2 Zumindest eine der zuvor genannten Aufgaben wird auch gelöst durch ein Kommunikations- und Steuerungs-/Regelungssystem zur Datenaufbereitung und Datenbereitstellung für ein dynamisches nutzerdatenbasiertes Steuern/Regeln einer bedarfsangepassten zeit-/ortsaufgelösten Funktionsweise wenigstens eines HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist zum Bereitstellen von Klimapräferenzdaten basierend auf nutzerspezifischen Komfort-Ratings, welche für die Erstellung einer Nutzerpräferenzcharakteristik herangezogen werden, wobei die bereitzustellenden Klimapräferenzdaten aus der Nutzerpräferenzcharakteristik insbesondere unter Einbezug von momentanen Zuständen der zu klimatisierenden Umgebung und/oder des jeweiligen Nutzers generiert werden und insbesondere basierend auf einer modellbasierten Repräsentation, insbesondere basierend auf einer multivarianten Wahrscheinlichkeitsverteilung, in Form einer tages-/jahreszeit- und/oder aufenthaltsortsabhängigen Sollwert-Trajektorie bereitgestellt werden; wobei das Kommunikations- und Steuerungs-/Regelungssystem eingerichtet ist für die nutzerspezifische Erfassung, Berücksichtigung oder Verarbeitung wenigstens eines Merkmals, einer Größe oder wenigstens eines Parameters aus der folgenden Gruppe oder im Zusammenhang mit einer der folgenden Funktionalitäten: Definition des verwendbaren Parametersatzes, insbesondere Temperatur, Feuchte, Zeit- und/oder Ortsauflösung, insbesondere nutzerspezifisch definierte Raumnutzungen-/belegungen; Komfort-Ratings als nutzerseitig skalierte relative Stellgröße bezüglich des Komfort-Empfindens, insbesondere bei zeitabhängiger Gewichtung der einzelnen Ratings desselben Nutzers untereinander; Cross Domain Content Management, insbesondere in Ausgestaltung als auf systemfremden Internetpräsenzen einbettbare Inlineframes; Korrelation von Nutzerpräferenzcharakteristiken mit aktuellen externen Parametern, insbesondere Wetterdaten, momentaner Aufenthaltsort des Nutzers, Aktivität des Nutzers, insbesondere auch mittels bzw. basierend auf KI-basierten Algorithmen; Definition von Nutzergruppen und optionale Gewichtung des Einflusses eines Ratings unter den Nutzern innerhalb einer Gruppe, wobei Daten über die klimatischen Vorlieben der jeweiligen Nutzergruppe wahlweise auch aus externen Datenbanken zuführbar sind; automatisches Anfahren einer unteren klimatischen Toleranzgrenze, z.B. einer minimalen Temperatur, zwecks Bestimmung eines nutzerspezifisch möglichen Energieverbrauchs-Minimums; Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose, insbesondere für einen Zeitraum von mehreren Stunden, Tagen, Wochen oder Monaten; insbesondere Kommunikations- und Steuerungs-/Regelungssystem gemäß den zuvor beschriebenen Ausgestaltungen.
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch Ermöglichung eines Verfahrens zum Generieren und Bereitstellen von Klimapräferenzdaten zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch (individuell) definierter/definierbarer Steuerungs-/Regelungsparameter, wobei wenigstens ein für die dynamische Regelung herangezogener/heranzuziehender Steuerungs-/Regelungsparameter aus einer personenbezogenen Parametergruppe umfassend zumindest die folgenden personenbezogenen Parameter in Bezug auf wenigstens einen Zeitpunkt/Zeitwert (d.h., als Funktion der Zeit oder in Bezug auf einen momentanen oder zukünftigen Zeitpunkt oder Tageszeitpunkt oder Jahreskalenderzeitpunkt) und/oder in Bezug auf wenigstens einen momentanen oder zukünftigen oder vordefinierten Aufenthaltsort eines/des jeweiligen Nutzers (Person, Individuum) generiert/vorgegeben wird: individuelle Temperatur bzw. Temperaturpräferenz (Tp), individuelle Luftfeuchtigkeit bzw. Luftfeuchtigkeitspräferenz (Hp), individueller Temperaturverlauf über die Tages-/Jahreszeit bzw. Temperaturschwankungspräferenz als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankungspräferenz als Funktion von Ort und/oder Zeit (Hp(t,s)), momentaner und/oder zeitpunktbezogener Aufenthaltsort des Nutzers; wobei für das Verfahren oder durch das Verfahren wenigstens ein uni-/oder bidirektionaler Kommunikationspfad aus der folgenden Gruppe genutzt oder bereitstellt wird, insbesondere wenigstens drei bevorzugt drahtlose Kommunikationspfade bereitgestellt oder genutzt werden, nämlich ein erster Kommunikationspfad zwischen einer jeweiligen Person (Nutzer, Individuum) und einem Host und/oder einem Datenraum (Cloud), ein zweiter Kommunikationspfad zwischen einem/dem Host (Datenbe-/verarbeitungs-Entity) und der jeweiligen Person (Nutzer, Individuum) und/oder dem Datenraum (Cloud), und ein dritter Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber (Energie-/Klimaverwaltungs-Entity) und dem Host und/oder dem Datenraum (insbesondere Cloud); wobei wenigstens einem Individuum (Nutzer) eine Eingabe-/Kommunikationsmaske (GUI), insbesondere in Ausgestaltung als Internetseite und/oder basierend auf der programmcodetechnischen Einbettung wenigstens eines Inlineframes, insbesondere durch Cross Domain Content Management, zum Hinterlegen oder Eingeben (oder wahlweise auch Nachjustieren) wenigstens eines mit einer Stellgröße korrelierbaren subjektiven Komfort-Ratings (stärker, schwächer, größer, kleiner, mehr, weniger, oder konkrete Level wie z.B. „sehr warm“ oder „leicht unterdurchschnittlich kühl“; Unwohlsein/Discomfort, Wohlbehangen/Befindlichkeit) und/oder des wenigstens eines personenbezogenen Parameters als individuelle Nutzervorgabe über einen der Kommunikationspfade (insbesondere über den ersten Kommunikationspfad) bereitgestellt wird, insbesondere über eine SmartPhone-Kommunikationsverbindung, nämlich das wenigstens eine mit wenigstens einem der Steuerungs-/Regelungsparameter korrelierte subjektiv Komfort-Rating, beispielsweise für ein momentanes Hinterlegen in Echtzeit (subjektiver Stellparameter zur Vorgabe bzw. Beeinflussung eines Soll-Wertes für wenigstens einen der Parameter, beispielsweise „Raumtemperatur“ oder „Raumfeuchte“ oder „Umluftbewegung/-zug/-konvektion“) und/oder des wenigstens eines personenbezogenen Parameters zum Definieren einer individuellen personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik durch Pflegen von personenspezifischen Klimapräferenzdaten im Datenraum; wobei die Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf momentanen und/oder mit Zeit-/Ortsbezug vorgegebenen (Erfahrungs-)Werten (beispielsweise auch basierend auf zeitlich zurückliegenden Stell-Maßnahmen durch den jeweiligen Nutzer) oder Komfort-Ratings für die wenigstens eine Stellgröße und/oder basierend auf den hinterlegten, eingegebenen und/oder automatisiert abgerufenen zeit-/ortsbezogenen personenbezogenen Parametern gemäß der in den Klimapräferenzdaten hinterlegten Nutzerpräferenz aus dem Datenraum generiert werden, insbesondere in Form einer tages-/jahreszeit- und/oder aufenthaltsortsabhängigen Sollwert-Trajektorie, insbesondere in Echtzeit; insbesondere mit dem Verfahren ausgeführt mittels des weiter oben beschriebenen Kommunikations- und Steuerungs-/Regelungssystems. Dies liefert zuvor weiter oben beschriebene Vorteile, insbesondere in Hinblick auf eine effiziente Bereitstellung von Daten zum Ermitteln eines vorteilhaften Kompromisses aus maximal gutem Komfort-Empfinden und minimalem Energieverbrauch. Basierend auf diesem Verfahren ist die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise (zeitabhängig bzw. zeitpunktbezogen) basierend auf dem wenigstens einen generierten Steuerungs-/Regelungsparameter insbesondere unter Nutzung des dritten Kommunikationspfades und bei/hinsichtlich bedarfsangepasster Energie-/Klima-Steuerung durchführbar, insbesondere in Echtzeit. Wahlweise werde die Komfort-Ratings und/oder die personenbezogenen Parameter auch mit den im jeweiligen Anwendungsfall für einen einzelnen Nutzer oder eine Nutzergruppe für eine spezifische Klimaumgebung (Raum, Haus, Zimmer) anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern korreliert, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose. Für die Korrelation können seitens des jeweiligen HLK-System-Betreibers systemspezifische Steuerungs-/Regelungs-Größen bereitgestellt werden oder durch den HLK-System-Betreiber einbezogen werden.
Das Abrufen der Stellgröße und/oder des personenbezogenen Parameters kann dabei wahlweise auch auf automatisierte bzw. durch den Nutzer automatisierbare Weise erfolgen (wahlweise auch ausschließlich), insbesondere indem z.B. von einem Thermostat in vordefinierbaren Zeitabständen die tatsächlichen Temperaturen im jeweiligen Raum (Klimaumgebung) erfasst werden, insbesondere drahtlos über einen der Kommunikationspfade (automatisiert abgerufene momentane personenbezogene Parameter). Ein zumindest teilweise automatisiertes Abrufen von personenbezogenen Parametern ermöglicht z.B. auch eine zeitnahe Reaktion auf einen thermischen Drift z.B. bei einer plötzlich auftretenden Wetteränderung (Umweltparameter) oder bei fehlender/ausbleibender Lüftung bzw. Konvektion oder dergleichen.
Mit anderen Worten kann die Erfindung auch wie folgt beschrieben werden:

Die Erfindung ermöglicht ein Verfahren zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierbarer Steuerungs-/Regelungsparameter, wobei wenigstens ein für die dynamische Regelung heranzuziehender Steuerungs-/Regelungsparameter aus einer personenbezogenen Parametergruppe umfassend zumindest die folgenden personenbezogenen Parameter in Bezug auf wenigstens einen Zeitpunkt und/oder in Bezug auf wenigstens einen momentanen oder zukünftigen oder vordefinierten Aufenthaltsort eines/des jeweiligen Nutzers vorgegeben wird: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort des Nutzers; wobei für das Steuern/Regeln eine Datenübertragung über wenigstens drei Kommunikationspfade erfolgt: über einen Kommunikationspfad zwischen einer jeweiligen Person und einem Host, über einen zweiten Kommunikationspfad zwischen einem/dem Host und dem Datenraum, und über einen dritten Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Host und/oder dem Datenraum; wobei dem wenigstens einen Individuum eine Eingabe-/Kommunikationsmaske, insbesondere durch Cross Domain Content Management, zum Hinterlegen oder Eingeben wenigstens eines subjektiven Komfort-Ratings und/oder des wenigstens eines personenbezogenen Parameters bereitgestellt wird, zum Definieren einer individuellen personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik durch Pflegen von personenspezifischen Klimapräferenzdaten im Datenraum; wobei der wenigstens eine Steuerungs-/Regelungsparameter basierend auf zeit-/ortsaufgelösten Komfort-Ratings und/oder basierend auf zeit-/ortsaufgelösten personenbezogenen Parametern gemäß der in den Klimapräferenzdaten hinterlegten Nutzerpräferenz aus dem Datenraum generiert wird, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose; derart dass die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise basierend auf den zeit-/ortsaufgelösten Komfort-Ratings und den Steuerungs-/Regelungsparametern zur bedarfsangepassten Energie-/Klima-Steuerung-/Regelung durchführbar ist, insbesondere in Echtzeit; insbesondere mit dem Verfahren ausgeführt mittels eines zuvor weiter oben beschriebenen Kommunikations- und Steuerungs-/Regelungssystems.

Gemäß einem Ausführungsbeispiel wird der wenigstens eine Steuerungs-/Regelungsparameter basierend auf den Komfort-Ratings auf automatisierte Weise für den jeweiligen Nutzer insbesondere unter Einbezug von Computerprogrammcode für eine nutzerspezifische Energieverbrauchsoptimierung generiert, indem ein nutzerspezifischer unterer Energieverbrauchslevel entsprechend einem unteren Komfort-Schwellwert ermittelt wird, insbesondere durch Vorgeben eines minimal kleinen bzw. optimalen nutzerspezifischen Verhältnisses aus einer Energieverbrauchskennzahl und einer Komfort-Kennzahl. Wahlweise kann dem jeweiligen Nutzer auch dessen Energieverbrauchskennzahl bereitgestellt werden, insbesondere im Sinne einer Anregung zu Energieeinsparungen. Dies vereinfacht nicht zuletzt die Bemühungen, den Energieverbrauch derart gering einzustellen, dass das Komfort-Empfinden des jeweiligen Nutzers in der jeweiligen Lebenssituation so gerade noch nicht negativ beeinträchtigt wird. Die Komfort-Kennzahl kann dabei jeweils orts- und zeitaufgelöst vorgegeben sein, z.B. indem der Nutzer für das Wohnzimmer und die Zeit am Abend ab ca. 19:30 eine höhere Behaglichkeitstemperatur (mehr Wärmeenergie) fordert als für die Aufenthaltszeit im Büro oder im HomeOffice.
Gemäß einem Ausführungsbeispiel umfasst die Parametergruppe auch einen nutzerspezifischen Aktivitäts-Parameter, insbesondere charakterisierend die Art der Aktivität (z.B. Sport, Spiel, Krafttraining, Kochen, Musik, Yoga, Gymnastik, Meditation, Duschen, Gartenarbeit, Computerspielen, Fernsehen, Medienkonsum im Allgemeinen) und die Nutzerpräferenz für die jeweilige Aktivität, wobei die Nutzeraktivität wahlweise gemäß dem hinterlegten Nutzerverhalten und/oder Aufenthaltsort (insbesondere auch abhängig von einer Raumbelegung) prognostiziert und/oder durch Bezugnahme auf einen Tageszeit-/Jahreskalender und/oder basierend auf einer momentanen Herz-/Atemfrequenz oder einem Bewegungsprofil des Nutzers geschätzt/vordefiniert wird.
Gemäß einem Ausführungsbeispiel werden die durch den Nutzer über die individuellen Klimapräferenzdaten gepflegte personenbezogene Parametergruppe wahlweise auch mit wenigstens einem der folgenden nicht-personenbezogenen Parameter korreliert, zum Generieren/Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters: prognostizierte ortsbezogene Außenklimabedingung (Temperatur, Feuchtigkeit, Niederschlag), Tageszeit, Kalenderdatum. Gemäß einem Ausführungsbeispiel werden die Klimapräferenzdaten vom jeweiligen Nutzer optional zeitspezifisch (momentan, für die Zukunft, oder auch für Erfahrungswerte der Vergangenheit) und/oder ortsspezifisch hinterlegt, insbesondere basierend auf Geofencing (Definition von räumlichen Bereichen, zwischen denen steuerungs-/regelungstechnisch unterschieden werden soll, insbesondere bei frei durch den Nutzer wählbarem Raster/Ortsauflösung) durch Korrelation der Klimapräferenzdaten mit GPS-Daten eines momentanen Aufenthaltsortes des jeweiligen Nutzers und/oder mit für den Aufenthaltsort des Nutzers verfügbaren Wetterdaten (Außenklimabedingungen). Gemäß einem Ausführungsbeispiel erfolgt der Zeitbezug basierend auf einem momentanen Tageszeitpunkt, insbesondere in Hinblick auf eine in den Klimapräferenzdaten hinterlegte Nutzerpräferenz mit Tagesverlaufs-Zeitabhängigkeit.
Gemäß einem Ausführungsbeispiel werden vom jeweiligen Individuum momentane Aufenthaltsortsdaten über den wenigstens einen Kommunikationspfad übermittelt und/oder vom Host abgerufen.
Dies liefert jeweils zuvor weiter oben insbesondere im Zusammenhang mit den entsprechenden Vorrichtungsaspekten beschriebene Vorteile.
Gemäß einem Ausführungsbeispiel werden Metadaten aus der subjektiv erlebten thermischen/klimatischen Erfahrungen des jeweiligen Nutzers aus den Klimapräferenzdaten generiert, zur Anpassung und zukünftigen Vorgabe des wenigstens einen Steuerungs-/Regelungsparameters. Gemäß einem Ausführungsbeispiel werden personenbezogene Metadaten generiert und in den Klimapräferenzdaten in der Nutzerpräferenzcharakteristik hinterlegt, die mit einem personenbezogenen Bewertungshistorienparameter korreliert werden, welcher den Zeitpunkt oder das Alter eines Komfort-Ratings oder einer Änderung der Nutzerpräferenzcharakteristik abbildet. Gemäß einem Ausführungsbeispiel wird eine nutzerspezifische Sollwert-Trajektorie unter Berücksichtigung einer klimatischen Trägheit eines entsprechenden HLK-/PCS-Systems zur Vorgabe des wenigstens einen Steuerungs-/Regelungsparameters aus den Klimapräferenzdaten generiert und in zeitlicher Hinsicht auf die Steuerung/Regelung des HLK-/PCS-Systems adaptiert, insbesondere basierend auf einer HLK-/PCS-systemimmanenten Regelungs-Logik, insbesondere bereitgestellt oder bereitstellbar seitens des HLK-/PCS-System-Betreibers, insbesondere zwecks Energieeinsparung. Gemäß einem Ausführungsbeispiel wird eine nutzerspezifische Sollwert-Trajektorie unter Berücksichtigung einer klimatischen Trägheit eines entsprechenden HLK-/PCS-Systems auf die Regelung des HLK-/PCS-Systems in zeitlicher Hinsicht adaptiert, indem ein HLK-/PCS-Systemspezifischer Trägheits-Zeitwert bei der Steuerung/Regelung des entsprechenden HLK-/PCS-Systems zur Vorgabe eines Ein-/Ausschaltzeitpunktes für das HLK-/PCS-System vorgegeben wird, insbesondere basierend auf einer HLK-/PCS-systemimmanenten Regelungs-Logik, insbesondere unter Berücksichtigung der thermischen Eigenschaften der jeweiligen Klimaumgebung (Haus, Wohnung, Raum, Zimmer) und durch Abgleich von Soll- und Ist-Klimazeitreihen.
Dies liefert jeweils zuvor weiter oben insbesondere im Zusammenhang mit den entsprechenden Vorrichtungsaspekten beschriebene Vorteile.
Gemäß einem Ausführungsbeispiel wird eine Feedback-Schleife mit dem Host durchgeführt, insbesondere über den zweiten Kommunikationspfad, insbesondere zum Nachjustieren oder Korrigieren der jeweiligen nutzerspezifischen Klimapräferenzdaten und/oder zum vordefinierten Vorgeben zukünftig folgender personenbezogener Parameter insbesondere für bestimmte Zeitfenster oder bestimmte zukünftige Aufenthaltsorte. Hierdurch kann auch die Zeit- und/oder Ortsauflösung konkretisiert werden, insbesondere auch in Hinblick auf eine optionale Erweiterung hinsichtlich Nutzer-Interaktionen (beispielsweise auch Raumbelegungen).
Gemäß einem Ausführungsbeispiel wird/werden die Nutzerpräferenzcharakteristik oder die Klimapräferenzdaten (insbesondere zum weiteren Vorgeben des wenigstens eine Steuerungs-/Regelungsparameter an einer Steuerungs-/Regelungsschnittstelle des Daten-Hosts) basierend auf einer Gewichtung des jeweiligen Alters mehrerer Komfort-Ratings desselben Nutzers auf automatisierte Weise insbesondere unter Einbezug von Computerprogrammcode generiert, indem dem jüngsten Komfort-Rating des Nutzers die stärkste Gewichtung (der größte Impact-Faktor) attributiert wird, insbesondere derart, dass die Nutzerpräferenzcharakteristik durch zeitlich gewichteten Klimapräferenzdaten gekennzeichnet ist, insbesondere bei mit der seit dem entsprechenden Rating vergangenen Zeit exponentiell fallender Abhängigkeit (sinkendem Impact) und/oder unter Berücksichtigung eines maximalen Alters-Schwellwertes, ab welchem Alter bzw. Zeitwert das jeweilige Rating nicht mehr berücksichtigt wird (Vernachlässigung übermäßig weit zeitlich zurückliegender Ratings). Anders ausgedrückt: Jedes Komfort-Rating wird mit einem zeitlichen Datum versehen und zum momentanen/aktuellen Steuerungs-/Regelungs-Zeitpunkt wird eine aktuelle/momentane Nutzerpräferenzcharakteristik für den jeweiligen Nutzer generiert (dynamische Auswertung der Komfort-Ratings zwecks Aktualisierung/Anpassung der momentanen Nutzerpräferenzcharakteristik); somit existiert nicht notwendigerweise eine vordefinierte statische Nutzerpräferenzcharakteristik, sondern die Nutzerpräferenzcharakteristik wird dynamisch und so aktuell wie möglich für die jeweilige Steuerungs-/Regelungsaufgabe ermittelt. Gibt der Nutzer beispielsweise tagesaktuell eine Änderung des Komfort-Ratings über die Eingabemaske ein, z.B. aufgrund eines Unfalls und aufgrund des Erfordernisses, mehr oder weniger bewegungslos zu Hause eine Krankheit auszukurieren, so wirkt sich dieses Komfort-Rating extrem stark auf die am gleichen Tage ausgeführte/auszuführende Steuerungs-/Regelungsaufgabe aus, insbesondere dann, wenn derselbe Nutzer das vorletzte Komfort-Rating bereits vor vielen Tagen oder gar Wochen abgegeben hatte. Die Nutzerpräferenzcharakteristik kann dabei auch als eines von mehreren Objekten im Datenraum gedeutet werden. Eine Aktualisierung der Nutzerpräferenzcharakteristik kann dabei wahlweise stetig, regelmäßig oder bei Bedarf erfolgen, beispielsweise auch in Hinblick auf das momentane Alter des Nutzers (z.B. Kleinkind mit sich nach kurzer Zeit verändernden Klima-Präferenz).
Der Nutzer kann wahlweise auch die einzelnen Klima-Parameter (insbesondere Temperatur, Feuchte, Konvektion, Helligkeit) durch Intensitäts-Klassifizierung gewichten, z.B. indem für die Helligkeit angegeben wird, dass diese wichtiger ist als z.B. ein Temperaturanstieg (Begünstigung der Nutzung von thermischem Licht-Energieeintrag für die Aufwärmung des Hauses bzw. der Klimaumgebung, z.B. an einem sehr sonnigen Wintertag bei tief stehender Sonne; gegebenenfalls kurzzeitig zu hohe Temperatur bzw. zu grelles Licht im Haus, jedoch über den Tag gesehen deutlich verbesserter CO₂ ^-Abdruck, da die durch Lichteinstrahlung bewirkte erhöhte Temperatur nutzerseitig akzeptiert wird und weniger geheizt werden muss).
Die Bezugnahme auf eine Nutzergruppe und deren Charakteristik erleichtert die Implementierung der Steuerung/Regelung basierend auf Komfort-Ratings noch weiter, insbesondere da eine Messinfrastruktur noch unwichtiger oder gegebenenfalls sogar komplett entbehrlich wird. Beispiel: Für die tatsächliche Steuerung/Regelung des HLK-Systems ist es dann weitgehend unerheblich, ob bereits nur 19°C im Raum vorliegen - wenn der Nutzer bzw. die Nutzergruppe (z.B. Olympiamannschaft oder Extremsportler für Wintersportarten) tendenziell auch mit einer Raumtemperatur von nur 18°C oder 17°C oder noch weniger auskommen, kann die energiebedarfsoptimierte Steuerung/Regelung weiter in Richtung Minimum-Schwellwert gefahren werden, insbesondere so lange, bis ein neues Komfort-Rating eingeht, dass die Temperatur nun langsam zu niedrig wird. Auch insofern beruht die vorliegende Erfindung auf dem Konzept einer nutzerinteressensbasierten Steuerung/Regelung in Abhängigkeit von Relativwerten und Empfindungen, also weitgehend entkoppelt von absoluten tatsächlichen Messwerten. Eine Standard-Raumtemperatur-Empfehlung von z.B. 22°C in kalten Regionen oder 24°C in warmen Regionen mag dann auch für Hotel-/Gastronomiebetreiber oder dergleichen Dienstleister weitgehend hinfällig sein, wenn sich herausstellt, dass die meisten Nutzer mit z.B. 19°C in kalten Regionen oder 27°C in warmen Regionen bereits sehr zufrieden sind. Hierin ist nicht zuletzt auch das große (insbesondere auch globale) Energieeinsparpotential bei Anwendung des erfindungsgemäßen Verfahrens/Systems erkennbar.
Ein Nutzer kann wahlweise weitgehend ohne jegliche Messinfrastruktur ein Komfort-Rating abgeben; wahlweise kann der Nutzer auch von allgegenwärtigen analogen/digitalen Thermometern bzw. Wetterstationen Messwerte ablesen (manuelle Datenpflege) und im Zusammenhang mit Komfort-Ratings oder Stellgrößen und/oder Steuerungs-/Regelungsparametern über die Eingabe-/Kommunikationsmaske übermitteln (insbesondere über den entsprechenden Kommunikationspfad transmittieren lassen).
Es hat sich gezeigt, dass eine Berücksichtigung des Alters eines Komfort-Ratings, insbesondere eine überproportionale Gewichtung der jüngsten Ratings, einerseits eine Berücksichtigung einer zeitlichen Entwicklung eines Nutzers (z.B. im Alter von 12 bis 50 Jahren) ermöglicht, und andererseits auch eine sehr gute Response in Hinblick auf unvorhersehbare Ereignisse oder schlagartige Präferenz-Änderungen sicherstellen kann. Es kann der folgende Grundsatz herangezogen werden: Je älter das einzelne Rating, desto weniger Gewicht hat es bei der Bestimmung/Bildung der gesamten Nutzerpräferenzcharakteristik. Vorzugshalber wird diese Zeitabhängigkeit als exponentieller Abfall modelliert: w = exp(-\lambda D) mit w = Gewicht, \lambda = Parameter, D = Dauer.
Die Host-seitige Verarbeitung der Komfort-Ratings unter Berücksichtigung der Gewichtung (Impact, Zeitfaktor) liefert eine auf einem im jeweiligen Anwendungsfall anzuwendenden Modell basierende Repräsentation (insbesondere basierend auf bzw. unter Einbezug einer multivarianten Wahrscheinlichkeitsverteilung), die herangezogen werden kann, um die optimale Raumklimatisierung zu prognostizieren, insbesondere unter Berücksichtigung der örtlichen Wetter-Vorhersagen (oder allgemein irgendwelcher Umweltparameter) und unter Einbezug eines unteren Schwellwerts zur unteren Raumklima-Akzeptanz (unterer nutzerspezifischer Komfort-Schwellwert).
Dabei kann auch die Dauer seit Übergang des Nutzers in eine entsprechende Klimazone bei der Verarbeitung von Komfort-Ratings über eine Gewichtung Berücksichtigung finden, was zu einer weiteren Verbesserung der Aussagekraft der Nutzerpräferenzcharakteristik führt. Beispiel: Für einen Nutzer, der nach dem Sport in einen vergleichsweise warmen Raum eintritt, wird dessen initiales „zu heiß“-Rating weniger gewichtet als ein erneutes „zu heiß“-Rating nach einer gewissen Zeit (Berücksichtigung von Trägheiten bei subjektiver Wahrnehmung und bei klimatischen Anpassung von Organismen). Insofern kann die Nutzerpräferenzcharakteristik (nutzerspezifisches Komfort-Profil) auch vor dem Hintergrund subjektiver momentaner Empfindungs-Verzerrungen nachhaltig dynamisch aktualisiert und für den jeweiligen individualisiert werden, insbesondere mittels eines Ratings basierend auf einem skalierbaren Positiv- oder Negativ-Feedback bezüglich des Komfort-Empfindens.
Die Nutzerpräferenzcharakteristik bzw. das Komfort-Profil kann dabei wahlweise auch durch untere und/oder obere Schwellwerte für die einzelnen Parameter charakterisiert werden, z.B. eine nutzerspezifische unterste Temperatur oder oberste Luftfeuchtigkeit, jeweils auch zeit- und/oder ortsaufgelöst („acceptance band“ bzw. Toleranzbereich für akzeptierte bzw. soeben noch akzeptable klimatische Variationen, insbesondere Temperatur- und Luftfeuchtigkeitsschwankungen).
Gemäß einem Ausführungsbeispiel erfolgt die Regelung des HLK-/PCS-Systems auf dynamische Weise basierend auf dem wenigstens einen Steuerungs-/Regelungsparameter, wobei dieser wenigstens eine Steuerungs-/Regelungsparameter ein gemittelter oder bezüglich eines oder mehrerer Nutzer/Individuen gewichteter Steuerungs-/Regelungsparameter ist, der aus einer Mehrzahl von individuellen Steuerungs-/Regelungsparametern mehrerer Personen (Individuen- oder Personengruppe) gebildet ist, insbesondere in Echtzeit in Abhängigkeit einer momentanen Belegung eines geschlossenen Raumes durch die mehreren Individuen. Hierdurch kann nicht zuletzt auch in Gemeinschaftshaushalten das Klima-Management erleichtert und in energetischer Hinsicht optimiert werden.
Gemäß einem Ausführungsbeispiel ist die Nutzerpräferenzcharakteristik eine personengruppenbezogene Nutzerpräferenzcharakteristik, wobei ein/der jeweilige Nutzer basierend auf Nutzerkennwerten, wie z.B. Alter, Gewicht, Größe, Geschlecht, einer bestimmten Personengruppe zugeordnet wird und die Nutzerpräferenzcharakteristik für diesen Nutzer deduktiv aus der Nutzerpräferenzcharakteristik dieser Personengruppe ermittelt wird, insbesondere basierend auf der Auswertung von Metadaten. Dies erleichtert nicht zuletzt auch die Anwendung und Implementierung, selbst dann, wenn die jeweiligen Nutzer weniger dazu neigen, eigene Komfort-Ratings abzugeben (z.B. sehr alte Nutzer im Alter von über 70 Jahren, die in ihrem Leben bisher wenig oder gar nicht in Berührung mit modernen Internet- oder Kommunikations-Applikationen gekommen sind oder dies gar nicht mehr wünschen). Die Präferenzcharakteristik stützt sich dabei z.B. auf wenigstens ein Komfort-Rating von wenigstens einem anderen Nutzer dieser Nutzergruppe. Bei einer Gruppe von z.B. 30 Nutzern mit denselben Nutzerkennwerten (z.B. allesamt weiblich, im Alter von 20 bis 24 Jahren) mag es bereits genügen, wenn nur einige wenige Nutzer einige wenige Komfort-Ratings abgeben. Auch bei der Berufung auf eine Nutzergruppencharakteristik kann dabei das Konzept realisiert werden, dass zeitlich zurückliegende Rating weniger gewichtet werden. Durch diese Art der indirekten Zuweisung einer Präferenzcharakteristik über eine Personengruppe kann eine Steuerung/Regelung bereits basierend auf Daten erfolgen, die der jeweilige Nutzer nicht notwendigerweise selbst generieren muss; vielmehr muss der Nutzer, wenn überhaupt, gegebenenfalls lediglich leichte Korrekturen hinsichtlich sehr spezifischer klimatischer Vorlieben durchführen, z.B. bezüglich der Badezimmertemperatur im Ferienhaus in der Zeit von 22 bis 24Uhr im Monat November.
Gemäß einem Ausführungsbeispiel erfolgt das kommunikative Steuern/Regeln durch den wenigstens einen Nutzer über die Eingabe-/Kommunikationsmaske (insbesondere mit GUI), indem über eine Internetseite, die in programmcodetechnischer Einbettung wenigstens einer GUI und/oder wenigstens eines Inlineframes in eine weitere (insbesondere systemfremde) Internetseite integriert wird, insbesondere durch Cross Domain Content Management, insbesondere Einbettung wenigstens eines Inlineframes, insbesondere Einbettung eines HTML-Elementes (z.B. HTML5), die Angaben des Nutzers bezüglich subjektiver Komfort-Ratings und/oder des wenigstens einen personenbezogenen Parameters hinterlegt oder angepasst werden. Hierdurch wird nicht zuletzt auch eine rein nutzergesteuerte bzw. nutzerseitige Implementierung erleichtert. Insbesondere kann eine Vordefinition irgendwelcher HLK-Systembedingungen oder auch jeglicher messtechnischer Aufwand entbehrlich werden. Dadurch kann auch das Anwendungsspektrum für das erfindungsgemäße Verfahren/System verbreitert werden.
Als „Cross Domain Content Management“ bzw. Domainübergreifende Contentverwaltung ist dabei eine Art Querverweis oder programmtechnische, programmiertechnische Verlinkung im Zusammenhang mit der Strukturierung von Webseiten zu verstehen. Das Einbetten erfolgt insbesondere durch Darstellung bzw. Ablaufen von Webinhalte fremder Seiten bzw. Drittanbieter als eigenständige Dokumente oder Elemente in einem definierten Bereich des jeweils genutzten Browsers. Bevorzugt erfolgt das Einbetten basierend auf HTML-Elementen, insbesondere HTML5-Elementen. Wahlweise können (zusätzlich oder alternativ) zu den bereits erwähnten Inlineframes auch so genannte „object“-Elemente und/oder „embed“-Elemente und/oder „ajax“-Elemente und/oder weitere HTML/HTML5-basierte Web-Komponenten vorgesehen sein (nicht abschließende beispielhafte Auflistung). Der Fachmann kann die jeweils zielführende Programmiersprache und die Auswahl der Art der Elemente situationsbedingt für den jeweiligen Anwendungsfall und die insbesondere nutzerseitig verfügbaren Ressourcen optimieren.
Die Eingabe-/Kommunikationsmaske kann auch mehrere GUI umfassen, insbesondre eine erste GUI für die Datenpflege beim Erstellen bzw. dynamischen Aktualisieren der Nutzerpräferenzcharakteristik, und eine zweite GUI für die nutzerseitige Definition von z.B. Raumkennzahlen oder für die Art und Weise einer Gewichtung, z.B. bei mehreren Nutzern einer Nutzergruppe (Control Setup). Das jeweilige GUI-Element wird bevorzugt durch Cross Domain Content Management auf Internetseiten eingebettet, insbesondere mittels Inlineframes. Der im jeweiligen Anwendungsfall zweckdienlichste Aufbau bzw. die Struktur und optional die Einbettung der GUI(s) kann jeweils anwendungsspezifisch definiert werden.
Gemäß einem Ausführungsbeispiel wird auf wenigstens einem der Kommunikationspfade wenigstens eine (Ressourcen bzw. Infrastruktur des WWW nutzende) Programmierschnittstelle (offen oder geschlossen) zur Verlinkung oder programmiertechnischen Einbettung von in maschinenlesbarer Sprache geschriebenen Elementen, insbesondere HTML-Elementen, bereitgestellt, insbesondere eine REST API (REST Representational State Transfer; Maschine-zu-Maschine-Kommunikation, insbesondere http-requests). Dies erleichtert nicht zuletzt auch die Erstellung und Pflege von Nutzerpräferenzcharakteristiken in diversen Situationen und auch über Dritte, z.B. über Klima-Hosts.
Als „in maschinenlesbarer Sprache geschriebene Elemente“ sind dabei z.B. HTML-Elemente für die Gliederung, Formatierung, Strukturierung von Text- und Bild- und Video- oder dergleichen Webseiten-Daten zu verstehen. HTML-Elemente haben sich als sehr zweckdienlich erwiesen; wahlweise können andere Auszeichnungssprachen (Markup Languages) alternativ oder zusätzlich zu HTML verwendet werden.
Gemäß einem Ausführungsbeispiel umfasst das Verfahren eine Auswertung der zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose durch Invertierung, indem momentane oder zukünftige Ist-Werte der Steuerungs-/Regelungsparameter mit den Klimapräferenzdaten des jeweiligen Nutzers korreliert werden und indem im Rückschluss von vorgegebenen oder tatsächlich gemessenen klimatischen Zuständen auf eine zu erwartende Nutzerpräferenz geschlossen wird, insbesondere für eine Last-/Energieverbrauchsreduktion in Abhängigkeit des vorhergesehenen bzw. zu erwartenden Nutzerverhaltens und momentanen oder zukünftigen Nutzer-Aufenthaltsortes. Hierdurch kann nicht zuletzt auch die Prognose-Sicherheit und Belastbarkeit der seitens der Datenbe-/verarbeitungs-Entity vorgegebenen Steuerungs-/Regelungsparameter verbessert werden, insbesondere dann, wenn nur wenig aktuelle Komfort-Ratings verfügbar sind.
ITEM11 Zumindest eine der zuvor genannten Aufgaben wird auch gelöst durch Ermöglichung eines Verfahrens zum Generieren und Bereitstellen von Klimapräferenzdaten zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierbarer Steuerungs-/Regelungsparameter,

- wobei die Klimapräferenzdaten für das Vorgeben von die dynamische Regelung heranzuziehender Steuerungs-/Regelungsparameter aus einer personenbezogenen Parametergruppe umfassend zumindest die folgenden personenbezogenen Parameter in Bezug auf wenigstens einen Zeitpunkt und/oder in Bezug auf wenigstens einen momentanen oder zukünftigen oder vordefinierten Aufenthaltsort eines/des jeweiligen Nutzers generiert werden: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort des Nutzers; wobei für das Steuern/Regeln eine Datenübertragung über wenigstens drei Kommunikationspfade erfolgt: über einen Kommunikationspfad zwischen einer jeweiligen Person und einem Host, über einen zweiten Kommunikationspfad zwischen einem/dem Host und dem Datenraum, und über einen dritten Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Host und/oder dem Datenraum; wobei dem wenigstens einen Individuum eine Eingabe-/Kommunikationsmaske, insbesondere durch Cross Domain Content Management, zum Hinterlegen oder Eingeben wenigstens eines subjektiven Komfort-Ratings und/oder des wenigstens eines personenbezogenen Parameters bereitgestellt wird, zum Definieren einer individuellen personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik durch Pflegen von personenspezifischen Klimapräferenzdaten im Datenraum; wobei der wenigstens eine Steuerungs-/Regelungsparameter basierend auf zeit-/ortsaufgelösten Komfort-Ratings und/oder basierend auf zeit-/ortsaufgelösten personenbezogenen Parametern gemäß der in den Klimapräferenzdaten hinterlegten Nutzerpräferenz aus dem Datenraum generiert wird, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose; derart dass die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise basierend auf den zeit-/ortsaufgelösten Komfort-Ratings und den Steuerungs-/Regelungsparametern zur bedarfsangepassten Energie-/Klima-Steuerung-/Regelung durchführbar ist, insbesondere in Echtzeit; insbesondere mit dem Verfahren ausgeführt mittels eines zuvor weiter oben beschriebenen Kommunikations- und Steuerungs-/Regelungssystems; wobei die Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf einer Gewichtung des jeweiligen Alters mehrerer Komfort-Ratings desselben Nutzers auf automatisierte Weise generiert werden, indem dem jüngsten Komfort-Rating des Nutzers die stärkste Gewichtung attributiert wird, insbesondere derart, dass die Nutzerpräferenzcharakteristik durch zeitlich gewichteten Klimapräferenzdaten gekennzeichnet ist, insbesondere bei mit der seit dem entsprechenden Rating vergangenen Zeit exponentiell fallender Abhängigkeit, wobei der wenigstens eine Steuerungs-/Regelungsparameter basierend auf den Komfort-Ratings auf automatisierte Weise für den jeweiligen Nutzer für eine nutzerspezifische Energieverbrauchsoptimierung generiert wird, indem ein nutzerspezifischer unterer Energieverbrauchslevel entsprechend einem unteren Komfort-Schwellwert ermittelt wird, insbesondere durch Vorgeben eines minimal kleinen nutzerspezifischen Verhältnisses aus einer Energieverbrauchskennzahl und einer Komfort-Kennzahl.

Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch ein Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte eines zuvor weiter oben beschriebenen Verfahrens auszuführen, insbesondere Computerprogrammprodukt in Ausgestaltung als SmartPhone-Applikation oder Endgeräte-Applikation (für mobile und/oder kommunizierende Endgeräte), insbesondere umfassend Front-End-Computerprogrammcode für eine Eingabe-/Kommunikationsmaske zum Definieren von personenbezogenen Zeitfenstern (Zeitabschnitten) oder Tageszeitabschnitten individueller Dauer für den Aufenthalt des jeweiligen Nutzers an spezifischen Orten oder in spezifischen Wohnräume, insbesondere unter Berücksichtigung eines momentanen Aufenthaltsorts des Nutzers, wobei das Computerprogrammprodukt eingerichtet ist zur Korrelation der personenbezogenen Zeitfenster oder Tageszeitabschnitte mit über die Eingabe-/Kommunikationsmaske eingegebenen Komfort-Ratings des jeweiligen Nutzers. Dies liefert zuvor genannte Vorteile, insbesondere auch in Hinblick auf eine Zeit-/Ortsauflösung der Komfort-Ratings.
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch ein Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte eines zuvor beschriebenen Verfahrens auszuführen, insbesondere Computerprogrammprodukt umfassend Back-End-Computerprogrammcode und eingerichtet für eine serverseitige Verarbeitung von personenbezogenen Klimapräferenzdaten auf automatische Weise und/oder in Reaktion auf einzelne Nutzer-Eingabe-Ereignisse, wobei sowohl nutzerspezifische Komfort-Ratings als auch personenbezogene Parameter zeit- und ortsaufgelöst verarbeitet werden, zum Erstellen einer Nutzerpräferenzcharakteristik basierend auf den Klimapräferenzdaten. Dies liefert zuvor genannte Vorteile, insbesondere auch in Hinblick auf eine möglichst effiziente Verarbeitung und Bereitstellung von Klimapräferenzdaten.
Es hat sich gezeigt, dass eine Energieverbrauchsoptimierung basierend auf den erfindungsgemäßen Verfahren/Systemen besonders effizient bzw. effektiv durchgeführt werden kann, wenn für den jeweiligen Nutzer auf automatische Weise ein unterer Komfort-Schwellwert gefunden wird, also ein Energieverbrauchslevel, bei welchem das Komfort-Empfinden zumindest durchschnittlich gut ist, und gleichzeitig ist der Energieverbrauch für dieses Empfinden minimiert. Insofern kann auch von einem Automatismus zum Finden/Definieren eines möglichst kleinen Verhältnisses aus einer Energieverbrauchskennzahl und einer Komfort-Kennzahl gesprochen werden; das erfindungsgemäße Verfahren/System ermöglicht bzw. erleichtert, personenbezogen den Energieverbrauch an einen unteren Schwellwert zu fahren, an welchem sich das Komfort-Empfinden bzw. das Komfort-Rating des jeweiligen Nutzers gerade noch nicht verschlechtert. Ein solcher Automatismus zum Finden der unteren Akzeptanzschwelle z.B. bezüglich einer Raumklimatisierung kann ein-/ausschaltbar sein, beispielsweise auch durch Integration eines entsprechenden Eingabefeldes in die Eingabe-/Kommunikationsmaske. Dieser Algorithmus oder diese Schleife zwischen Nutzer-Feedback und Datenaufbereitung zum Erleichtern von Steuerung-/Regelungsmaßnahmen des Systems (z.B. einer dauerhaften Absenkung der Temperatur im Schlafzimmer um 1-2 °C) ermöglicht auf sehr nutzerspezifische und sehr einfache Weise, die Datengrundlage zum Einstellen der Raumklimatisierungs-Parameter derart weit zu optimieren (insbesondere in energetischer Hinsicht), bis sich der Nutzer äußert und ein neues bzw. schlechteres Komfort-Rating abgibt, also bis der Nutzer dem System vorgibt, dass das Komfort-Empfinden sich nun (spürbar) verschlechtert, um die entsprechende Datengrundlage zu schaffen, um wieder in die andere Richtung zu steuern/regeln zu können, also z.B. wieder von 16°C Raumtemperatur auf 17 oder 18°C Raumtemperatur zu gehen.
Als „serverseitige“ Datenverarbeitung ist dabei insbesondere auch eine Datenbe-/verarbeitung seitens eines/des (Daten-)Host zu verstehen, zum Bereitstellen von aufbereiteten Nutzer-/Klimapräferenzdaten für systemfremde oder an das erfindungsgemäße System gekoppelte Dienstleister (z.B. Energieverwaltungs-Entity).
Zumindest eine der zuvor genannten Aufgaben wird demnach auch gelöst durch ein Computerprogramm eingerichtet zum Bereitstellen bzw. Realisieren der hier beschriebenen Nutzerdatenverarbeitung und Datenbereitstellung bzw. der hier beschriebenen Verfahrensschritte.
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch ein Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte eines zuvor weiter oben beschriebenen Verfahrens auszuführen, wobei das Verfahren ausschließlich zur Datenerfassung und Datenbereitstellung an der Schnittstelle zwischen dem jeweiligen Nutzer und dem wenigstens einen HLK-/PCS-System-Betreiber oder einem systemfremden Host durchgeführt wird.
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch Verwendung eines Computerprogrammproduktes für ein Verfahren zum Generieren von Nutzerdaten und zum Bereitstellen von nutzerspezifischen Daten (insbesondere Zeitreihen) zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch basierend auf zeit- und/oder ortsaufgelösten Klimapräferenzdaten definierter Steuerungs-/Regelungsparameter, insbesondere bei einem zuvor weiter oben beschriebenen Verfahren; wobei mehrere bevorzugt drahtlose Kommunikationspfade genutzt werden: ein erster Kommunikationspfad zwischen einer jeweiligen Person und einem Host und/oder einem Datenraum, in welchem eine jeweilige Nutzerpräferenzcharakteristik in personenspezifischen Klimapräferenzdaten hinterlegt ist, ein zweiter Kommunikationspfad zwischen einem/dem Host und der jeweiligen Person und/oder dem Datenraum, und ein dritter Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Host und/oder dem Datenraum; wobei zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum und zum Definieren der Nutzerpräferenzcharakteristik über eine Eingabe-/Kommunikationsmaske, insbesondere in Ausgestaltung als Internetseite und/oder basierend auf der programmcodetechnischen Einbettung wenigstens eines Inlineframes, wenigstens ein subjektives Komfort-Rating und/oder der wenigstens eine personenbezogene Parameter als individuelle Nutzervorgabe hinterlegt wird; wobei die Nutzerpräferenzcharakteristik zum Generieren des wenigstens einen Steuerungs-/Regelungsparameters bereitgestellt wird, derart dass die Komfort-Ratings und/oder die personenbezogenen Parameter mit den im jeweiligen Anwendungsfall für einen einzelnen Nutzer oder eine Nutzergruppe für eine spezifische Klimaumgebung anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern korrelierbar sind, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose und derart dass die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise zur bedarfsangepassten Energie-/Klima-Steuerung-/Regelung durchführbar ist, insbesondere in Echtzeit,
insbesondere mit der Parametergruppe umfassend wenigstens den weiteren folgenden Parameter: nutzerspezifischer Aktivitäts-Parameter, insbesondere zeit- und/oder ortsaufgelöst; wobei das Computerprogrammprodukt bevorzugt Back-End-Computerprogrammcode umfasst und eingerichtet ist für eine serverseitige Verarbeitung von personenbezogenen Klimapräferenzdaten auf automatische Weise und/oder in Reaktion auf einzelne Nutzer-Eingabe-Ereignisse. Hierdurch ergeben sich zuvor genannte Vorteile, insbesondere auch auf Back-End-Seite.
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch Verwendung eines Computerprogrammproduktes für ein/das weiter oben zuvor beschriebene Verfahren zum Generieren von Nutzerdaten und zum Bereitstellen von nutzerspezifischen Daten (insbesondere Zeitreihen) zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch basierend auf zeit- und/oder ortsaufgelösten Klimapräferenzdaten definierter Steuerungs-/Regelungsparameter; wobei eine nutzerspezifische Steuerung und wahlweise auch Regelung des wenigstens eines HLK-/PCS-Systems erfolgt, indem bei der Datenverarbeitung basierend auf generierten personenspezifischen Klimapräferenzdaten eine Repräsentation erstellt wird, in welcher die Komfort-Ratings, die personenbezogenen Parameter und Klimadaten zusammengeführt werden, insbesondere unter Anwendung von auf künstlicher Intelligenz basierenden Algorithmen. Das modellbasierte Generieren einer Repräsentation, insbesondere einer multivarianten Wahrscheinlichkeitsverteilung, erleichtert nicht zuletzt die Überwindung von Komplexitäts- und Datenbereitstellungs-Hürden. Beim Generieren/Korrelieren/Bereitstellen von personenspezifischen Klimapräferenzdaten und/oder Steuerungs-/Regelungsparametern kann eine berechnungsmodellbasierte Repräsentation (insbesondere multivariate Wahrscheinlichkeitsverteilung) insbesondere basierend auf Algorithmen der künstlichen Intelligenz (gegebenenfalls selbstlernend) die individuellen Nutzer-Ratings noch effizienter mit aktuellen Phänomenen wie z.B. der Anzahl der Personen in einem Raum, oder klimatischen (Außen-)Bedingungen in Verbindung bringen, so dass die Datengrundlage und Aussagekraft der ermittelten Daten verbessert werden kann. Diese Art der Repräsentation ermöglicht es auch, Vorhersagen für wenigstens eine steuerbare/regelbare Stellgröße bzw. für den wenigstens einen Steuerungs-/Regelungsparameter für das jeweilige HLK-/PCS-System zu treffen, insbesondere zum Maximieren des subjektiven nutzerspezifischen Komforts und zum Minimieren des dafür eingesetzten Energiebedarfs. Hierdurch ergeben sich zuvor genannte Vorteile, insbesondere auch in Hinblick auf eine starke Individualisierung von einer Mehrzahl von HLK-Systemen durch zentrale Datenverwaltung und Datenverarbeitung und Datenbereitstellung, insbesondere auch bei minimiertem sensorischen bzw. messtechnischen Aufwand, insbesondere weitgehend unabhängig von technischen Besonderheiten eines jeweiligen HLK-Systems. Die generierbaren Zeitreihen können auch als ein/das Ergebnis der Verarbeitung von Vorhersagen basierend auf der jeweiligen Nutzerpräferenzcharakteristik beschrieben werden (Rückführung auf die erfasste bzw. generierte Datengrundlage).
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch Verwendung eines Computerprogrammproduktes zum Bereitstellen eines Kommunikations- und Steuerungs-/Regelungssystem zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf einer personenbezogenen oder personengruppenbezogene Parametergruppe (GPp) insbesondere umfassend Temperatur (Tp)- und Luftfeuchtigkeitsparameter (Hp), und zum Bereitstellen einer Eingabe-/Kommunikationsmaske zur Pflege von personenspezifischen Klimapräferenzdaten, insbesondere durch Cross Domain Content Management, und zum Erfassen von eingegebenen subjektiven Komfort-Ratings (Sp) und/oder wenigstens eines personenbezogenen Parameters (Pp), und zum Erstellen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4) basierend auf zeit- und/oder ortsaufgelösten Komfort-Ratings (Sp); und zum Bereitstellen der zeit-/ortsaufgelösten Komfort-Ratings (Sp) und Steuerungs-/Regelungsparameters (Pp) für einen/den HLK-/PCS-System-Betreiber für die dynamische Steuerung/Regelung des jeweiligen HLK-/PCS-Systems, insbesondere in Echtzeit. Hierdurch ergeben sich zuvor genannte Vorteile, insbesondere in Hinblick auf eine Datenverarbeitung an der Schnittstelle zwischen mehreren Nutzern und mehreren Hosts bzw. Dienstleistern unterschiedlicher Art.
Bei einer personengruppenbezogenen Parametergruppe kann z.B. auch berücksichtigt werden, dass bestimmte Personen/Nutzer eine Regelung vornehmlich basierend auf stärker zu gewichtenden Regelungsparametern wünschen, z.B. weniger feuchtelastig, sondern eher temperaturlastig, oder in Hinblick auf vordefinierbare Schwellwerte (z.B. maximale Temperatur jedenfalls nicht über 24°C, auch dann nicht, wenn dies regelungstechnisch z.B. in Hinblick auf eine Systemträgheit oder hinsichtlich momentaner Strahlungseinflüsse in der Theorie erforderlich sein würde). Hierdurch kann die Güte der bereitgestellten Klimapräferenzdaten (klimatischen Nutzerpräferenzdaten) weiter verbessert werden.
Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch Verwendung eines Computerprogrammproduktes für ein Verfahren zum Verarbeiten von Nutzerdaten zum Bereitstellen von Klimapräferenzdaten zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch basierend auf zeit- und/oder ortsaufgelösten Klimapräferenzdaten definierter Steuerungs-/Regelungsparameter, insbesondere bei einem zuvor beschriebenen Verfahren; wobei wenigstens ein bevorzugt drahtloser Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Host und/oder einem Datenraum genutzt wird, in welchem eine jeweilige Nutzerpräferenzcharakteristik in personenspezifischen Klimapräferenzdaten hinterlegt ist, wobei wahlweise ein weiterer Kommunikationspfad zwischen einer jeweiligen Person und dem Datenraum und ein weiterer Kommunikationspfad zwischen einem Host und der jeweiligen Person und/oder dem Datenraum nutzbar ist; wobei die Pflege von personenspezifischen Klimapräferenzdaten im Datenraum und die Definition der Nutzerpräferenzcharakteristik über eine Eingabe-/Kommunikationsmaske, insbesondere in Ausgestaltung als Internetseite und/oder basierend auf der programmcodetechnischen Einbettung wenigstens eines Inlineframes, nutzerseitig über wenigstens ein subjektives Komfort-Rating und/oder über den wenigstens einen personenbezogenen Parameter als individuelle Nutzervorgabe durchführbar ist; wobei die Nutzerdaten aus der Nutzerpräferenzcharakteristik zum Generieren des wenigstens einen Steuerungs-/Regelungsparameters bereitgestellt werden, wobei die Komfort-Ratings bzw. Stellgröße(n) und/oder die personenbezogenen Parameter mit den im jeweiligen Anwendungsfall für einen einzelnen Nutzer oder eine Nutzergruppe für eine spezifische Klimaumgebung anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern korreliert werden, für eine zeit- und orts- und nutzerabhängige Energie-/Klima-Bedarfsprognose, wobei die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise zur bedarfsangepassten Energie-/Klima-Steuerung-/Regelung durchgeführt wird, insbesondere in Echtzeit, insbesondere mit der Parametergruppe umfassend wenigstens den weiteren folgenden Parameter: prognostizierte ortsbezogene und zeitaufgelöste Außenklimabedingung, korreliert mit wenigstens einem der personenbezogenen Parameter. Hierdurch ergeben sich zuvor genannte Vorteile, insbesondere auch seitens eines HLK-/PCS-System-Betreibers und/oder einer Energieverwaltungs-Entity.
ITEM42 Zumindest eine der zuvor genannten Aufgaben wird wie erwähnt auch gelöst durch Verwendung eines Computerprogrammproduktes zum Verarbeiten von Nutzerdaten zum Bereitstellen von Klimapräferenzdaten für ein dynamisches nutzerdatenbasiertes Steuern/Regeln einer bedarfsangepassten zeit-/ortsaufgelösten Funktionsweise wenigstens eines HLK-/PCS-Systems (1), wobei die Klimapräferenzdaten basierend auf nutzerspezifischen Komfort-Ratings bereitgestellt werden, welche für die Erstellung einer Nutzerpräferenzcharakteristik herangezogen werden, wobei die bereitzustellenden Klimapräferenzdaten aus der Nutzerpräferenzcharakteristik insbesondere unter Einbezug von momentanen Zuständen der zu klimatisierenden Umgebung, insbesondere Umgebungstemperatur und Umgebungsfeuchte (innen, außen), und/oder des jeweiligen Nutzers, insbesondere dessen Aktivität, generiert werden und insbesondere basierend auf einer modellbasierten Repräsentation, insbesondere basierend auf einer multivarianten Wahrscheinlichkeitsverteilung, in Form einer tages-/jahreszeit- und/oder aufenthaltsortsabhängigen Sollwert-Trajektorie bereitgestellt werden; wobei eine nutzerspezifische Erfassung, Berücksichtigung oder Verarbeitung wenigstens eines Merkmals, einer Größe oder wenigstens eines Parameters aus der folgenden Gruppe oder im Zusammenhang mit einer der folgenden Funktionalitäten mittels des Computerprogrammproduktes erfolgt: Definition des verwendbaren Parametersatzes, insbesondere Temperatur, Feuchte, Zeit-und/oder Ortsauflösung, insbesondere nutzerspezifisch definierte Raumnutzungen-/belegungen; Komfort-Ratings als nutzerseitig skalierte relative Stellgröße bezüglich des Komfort-Empfindens, insbesondere bei zeitabhängiger Gewichtung der einzelnen Ratings desselben Nutzers untereinander; Cross Domain Content Management, insbesondere in Ausgestaltung als auf systemfremden Internetpräsenzen einbettbare Inlineframes; Korrelation von Nutzerpräferenzcharakteristiken mit aktuellen externen Parametern, insbesondere Wetterdaten, momentaner Aufenthaltsort des Nutzers, Aktivität des Nutzers, insbesondere auch mittels bzw. basierend auf KI-basierten Algorithmen; Definition von Nutzergruppen und optionale Gewichtung des Einflusses eines Ratings unter den Nutzern innerhalb einer Gruppe, wobei Daten über die klimatischen Vorlieben der jeweiligen Nutzergruppe wahlweise auch aus externen Datenbanken zuführbar sind; automatisches Anfahren einer unteren klimatischen Toleranzgrenze, z.B. einer minimalen Temperatur, zwecks Bestimmung eines nutzerspezifisch möglichen Energieverbrauchs-Minimums; Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose, insbesondere für einen Zeitraum von mehreren Stunden, Tagen, Wochen oder Monaten; insbesondere mittels eines zuvor beschriebenen Kommunikations- und Steuerungs-/Regelungssystems. Dies liefert zuvor genannte Vorteile.
Figurenliste
In den nachfolgenden Zeichnungsfiguren wird die Erfindung noch näher beschrieben, wobei für Bezugszeichen, die nicht explizit in einer jeweiligen Zeichnungsfigur beschrieben werden, auf die anderen Zeichnungsfiguren verwiesen wird. Es zeigen:

1 in schematischer Darstellung ein Kommunikations-/Steuerungs-/Regelungssystem gemäß einem Ausführungsbeispiel;
2 in schematischer Darstellung die Einbindung von Schnittstellen in ein Kommunikations-/Steuerungs-/Regelungssystem gemäß dem Ausführungsbeispiel der 1 oder gemäß einem weiteren Ausführungsbeispiel;
3 in schematischer Darstellung ein Kommunikations-/Steuerungs-/Regelungssystem gemäß einem weiteren Ausführungsbeispiel, insbesondere bei Variation der Kommunikationspfade;
4 eine schematische Darstellung von optionalen Kommunikationspfaden zu einem weiteren Host (Klima-Host) für eine Datenbereitstellung in einem Kommunikations-/Steuerungs-/Regelungssystem bzw. -verfahren gemäß einem der zuvor beschriebenen Ausführungsbeispiele oder einem weiteren Ausführungsbeispiel;
5 in schematischer Darstellung ein Kommunikations-/Steuerungs-/Regelungssystem gemäß einem weiteren Ausführungsbeispiel, wobei automatisiertes Abrufen von personenbezogenen Steuerungs-/Regelungsparametern durch einen oder mehrere Hosts erfolgt;
6 in schematischer Darstellung eine beispielhafte GUI zur Einbindung in eine Eingabe-/Kommunikationsmaske eines Kommunikations-/Steuerungs-/Regelungssystems gemäß Ausführungsbeispielen;
7 in schematischer Darstellung eine Übersicht zur Art und Weise der Nutzung eines Kommunikations-/Steuerungs-/Regelungssystems gemäß Ausführungsbeispielen durch mehrere Entities;
8 in schematischer Darstellung eine Systematik zum Generieren einer Nutzerpräferenzcharakteristik mittels eines Kommunikations-/Steuerungs-/Regelungssystems bzw. -verfahrens gemäß Ausführungsbeispielen;
9 in schematischer Darstellung eine Systematik zum Generieren einer Komfort-Trajektorie mittels eines Kommunikations-/Steuerungs-/Regelungssystems bzw. -verfahrens gemäß Ausführungsbeispielen;
10 in schematischer Darstellung eine Systematik zum Erfassen bzw. Bestimmen eines tatsächlichen subjektiv empfundenen Komforts des jeweiligen Nutzers (Komfort-Zufriedenheit) mittels eines Kommunikations-/Steuerungs-/Regelungssystems bzw. -verfahrens gemäß Ausführungsbeispielen;

DETAILLIERTE BESCHREIBUNG DER FIGUREN
Die Erfindung wird zunächst unter allgemeiner Bezugnahme auf alle Bezugsziffern und Figuren erläutert. Besonderheiten bzw. Einzelaspekte der vorliegenden Erfindung werden im Zusammenhang mit der jeweiligen Figur thematisiert, die sich jeweils auf ein Kommunikations-/Steuerungs-/Regelungssystem 100 gemäß Ausführungsbeispielen der Erfindung beziehen.
In einem Datenraum 3, insbesondere in einer Cloud, ist für einen jeweiligen Nutzer I oder zumindest für eine Nutzergruppe GI eine Nutzerpräferenzcharakteristik 4 mit individuellen Klimapräferenzdaten D hinterlegt, insbesondere als Datengrundlage zum Generieren von nutzerspezifischer Klima-/ Komfort-Zeitreihen, insbesondere zeit-/ortsaufgelöst. Die Klima-/Komfort-Zeitreihen können auch als Ergebnis der Auswertung der jeweiligen Nutzerpräferenzcharakteristik beschrieben werden. Die Nutzerpräferenzcharakteristik 4 wird basierend auf subjektiven personenbezogenen Komfort-Ratings Sp der jeweiligen Nutzer I (bzw. aus den daraus ermittelbaren nutzerbezogenen Stellgrößen) und/oder aus zumindest teilweise automatisiert abrufbaren personenbezogenen Steuerungs-/Regelungsparametern Pp ermittelt (beispielsweise personenbezogene Parametergruppe GPp umfassend die nutzerspezifische Luftfeuchtigkeit Hp, den nutzerspezifischen orts-/zeitaufgelösten Luftfeuchtigkeitsverlauf Hp(t,s), einen nutzerspezifischer Aufenthaltsorts- und/oder Distanz-Parameter GPSp (insbesondere auch umfassend eine Raumkennzahl S_n), eine individuelle Temperatur Tp und/oder einen individuellen Temperaturverlauf Tp(t,s)), insbesondere von einem Host 5 bzw. von einer Datenbe-/verarbeitungs-Entity 5. Eine zeitliche Auflösung kann dabei auch in Form eines personenbezogenen Bewertungshistorienparameters Dp berücksichtigt werden, insbesondere unter Einbezug der Aktualität und des Impacts eines Ratings Sp eines einzelnen Nutzers oder einer Nutzergruppe GI (z.B. Ehepaar mit zwei Kindern, davon ein neugeborenes Kind mit großem Impact für dessen Rating). Durch Berücksichtigung des Alters eines jeweiligen Ratings bzw. einer entsprechenden Information kann Verzerrungen vorgebeugt werden, und eine Evolution bzw. Tendenz des Komfort-Empfindens des Nutzers kann mit guter Belastbarkeit berücksichtigt werden.
Die Nutzerpräferenzcharakteristik 4 bzw. die daraus generierbaren nutzerspezifischen Steuerungs-/Regelungsparameter Pp können für wenigstens eine weitere Entity bereitgestellt werden, insbesondere für einen weiteren Host (Klima-Host) 6 bzw. für Klima-Dienstanbieter, z.B. Hoteldienstleister, und/oder für einen HLK-/HVAC-System-Betreiber 7 bzw. eine Energieverwaltungs-Entity oder ein Building Management System BMS.
Ein oder mehrere HLK-/PCS-Systeme bzw. HVAC-/PCS-Systeme 1, die jeweils basierend auf der ermittelten Nutzerpräferenzcharakteristik 4 angesteuert bzw. geregelt werden können, insbesondere hinsichtlich einer Minimierung des nutzerspezifischen Energieverbrauchs bzw. nutzerspezifischen Energiebedarfs(-empfindens), sind beispielsweise in einer geschlossenen bzw. abgrenzbaren Klimaumgebung 9 in Ausgestaltung als Einfamilienhaus oder Schule oder behördliches Gebäude (z.B. städtisches Rathaus) oder Hotel oder Restaurant vorgesehen.
Dabei können unterschiedliche Kommunikationspfade 10 (bevorzugt drahtlos) genutzt bzw. bereitgestellt werden, insbesondere wenigstens ein erster Kommunikationspfad 11, wenigstens ein zweiter Kommunikationspfad 12, 12a, wenigstens ein dritter Kommunikationspfad 13, und/oder wenigstens ein vierter Kommunikationspfad 14 (zwischen HLK-/PCS-System und System-Betreiber). Als Eingabe-/Kommunikationsgerät 20 insbesondere zur Abgabe von Komfort-Ratings Sp eignen sich z.B. SmartPhone, Tablet, SmartWatch, Datenbrillen, oder dergleichen mobile oder standfeste Endgeräte (nicht abschließende Aufzählung).
Ein Computerprogrammprodukt 30 kann dabei eine oder mehrere offene und/oder geschlossene Programmierschnittstellen 31, 32, 33 bereitstellen oder umfassen (z.B. API, REST API, mobile Applikation, Web-Interface). Bevorzugt sind zumindest die Programmierschnittstellen zu weiteren systemfremden Hosts bzw. Energieverwaltungs-Entities bzw. HLK-/PCS-Systemanbietern offene Pro grammierschni ttstellen.
Über eine Eingabe-/Kommunikationsmaske bzw. GUI 15 kann der jeweilige Nutzer I bzw. die weiteren Kommunikationspartner ein Rating Sp abgeben. Der Nutzer kann wahlweise auch direkt eine Luftfeuchtigkeitspräferenz Hp, eine individuelle orts-/zeitaufgelöste Luftfeuchtigkeitsverlaufspräferenz Hp(t,s), eine individuelle Temperaturpräferenz Tp, und/oder eine individuelle orts-/zeitaufgelöste Temperaturschwankungspräferenz Tp(t,s) oder auch weitere Präferenzen oder Kennzahlen (z.B. Gewichtung einzelner Ratings in einer Gruppe von Individuen, z.B. höhere Gewichtung für die Eltern einer Familie) über die Eingabe-/Kommunikationsmaske 15 hinterlegen.
In der 1 ist eine Ansicht eines Gesamtsystems mit unterschiedlichen Anbietern 5, 6, 7 bzw. Entities gezeigt. Die Nutzer I halten sich (momentan) irgendwo in der Umgebung oder in vordefinierten Klimaumgebungen 9 auf. Für eine Ortsauflösung der Steuerung/Regelung können die Klimapräferenzdaten wahlweise automatisch und/oder durch Unterstützung seitens des Nutzers gebildet werden. Beispielsweise können die Nutzer Ijeweils individuell oder als Gruppe GI für die einzelnen Räume eines Hauses 9 eine Raumkennzahl S_n vergeben, z.B. eine erste Raumkennzahl S₁ für das Schlafzimmer und eine zweite Raumkennzahl S₂ für die Küche. Dies erleichtert auch eine RaumKlima-Steuerung/-Regelung in Hinblick auf die Art des Raumes und die Nutzung des Raumes. Wahlweise kann z.B. auch eine Raumausrichtung und die Anzahl und Größe von Fensterflächen berücksichtigt werden, insbesondere für die Berücksichtigung von Wärme-/Lichtstrahlung zu bestimmten Tageszeiten. Letzteres kann auch erlernt werden, insbesondere unter Anwendung von Künstlicher Intelligenz-Methoden, beispielsweise unter Berücksichtigung von Orientierung und/oder Größe der jeweiligen Fensterfläche sowie herstellerspezifischen (Wärme-)Übergangskoeffizienten und/oder der aktuellen Tages-/Jahreszeit (Sonnenstand), Bewölkungsgrad oder dergleichen.
Unter Bezugnahme auf 1 kann auch klargestellt werden, dass der Daten-Host 5 an der Schnittstelle zwischen dem jeweiligen Nutzer und dessen Ratings einerseits und weiteren, systemfremden und näher an der klimatischen Steuerungs-/Regelungsseite agierenden Hosts andererseits angesiedelt ist, und diese Schnittstellen bedient, insbesondere indem die insbesondere in Form von Zeitreihen generierten und für einen oder mehrere systemfremde Hosts bereitgestellten Klimapräferenzdaten in aufbereiteter Form zugänglich gemacht werden. Der Daten-Host 5 liefert demnach die (Daten-)Grundlage für die weiteren Schritte zur Realisierung konkreter klimatischer Maßnahmen. Letztere können wahlweise, müssen jedoch nicht auch vom Daten-Host 5 realisiert werden. Je nach Definition der Steuerungs-/Regelungsebene ist der Daten-Host 5 daher eine reine Datenaufbereitungsentity oder wahlweise auch eine für die jeweilige tatsächlich stattfindende klimatische Steuerung/Regelung involvierte Entity. Voraussichtlich lässt sich die Erfindung auf einfachere Weise für die unterschiedlichen Anwendungsfälle implementieren, wenn der Daten-Host 5 lediglich auf Datenverarbeitungs- und Datenbereitstellungsebene agiert.
In der 2 sind Schnittstellen bzw. Interfaces 31, 32, 33 auf einzelnen Kommunikationspfaden angedeutet, an welchen die Nutzer I und die beteiligten Hosts 5, 7 die Möglichkeit zur Datenpflege bzw. Datenbereitstellung bzw. Datenübernahme/Datenübergabe erhalten. Zumindest an der Schnittstelle 31 zum jeweiligen Nutzer ist wenigstens eine GUI 15 vorgesehen.
In der 3 ist eine alternative Anordnung von Kommunikationspfaden angedeutet. Ein Computerprogrammprodukt 30 wird insbesondere seitens der Datenbe-/verarbeitungs-Entity 5 bereitgestellt und kann mehrere Programmierschnittstellen bzw. Interfaces 31, 32, 33 umfassen, insbesondere jeweils für einen der Kommunikationspfade.
Im Ausführungsbeispiel gemäß 3 entspricht der Host 5 dem HLK-/HVAC-System-Betreiber bzw. der Energieverwaltungs-Entity 7, so dass ein/der vierte/r Kommunikationspfad entbehrlich ist.
In der 4 ist die Zwischenschaltung der Datenbe-/verarbeitungs-Entity 5 zwischen Nutzer und weiterem Dienstleister 6 (insbesondere Hotelbetreiber oder dergleichen) erläutert. Durch Einbettung (bzw. durch Cross Domain Content Management) kann das erfindungsgemäße Verfahren bzw. System beispielsweise von einem oder mehreren weiteren Hosts 6 (Klima-Host) genutzt werden, wodurch die Anwendung auch für den Nutzer besonders anwendungsfreundlich wird, insbesondere auch unabhängig davon, wie oft oder wie viele unterschiedliche Hosts 6 vom jeweiligen Nutzer I adressiert werden. Der Kommunikationspfad 12a führt zum Klima-Host 6, welcher einen im Zusammenhang mit klimatisch zu steuernden/regelnden Umgebungen stehenden Dienst wie z.B. eine Hotelübernachtung anbietet. Der Nutzer I kommuniziert wahlweise ausschließlich mit dem Klima-Host 6, oder wahlweise sowohl mit der Datenbe-/verarbeitungs-Entity 5 als auch mit dem Klima-Host 6. Insofern ist der Nutzer frei in der Wahl, ob ein Komfort-Rating an den Klima-Host 6 und/oder an die Datenbe-/verarbeitungs-Entity 5 abgegeben wird.
Das in 4 dargestellte Prinzip der Kommunikationsstruktur kann jeweils bei den zuvor beschriebenen Ausführungsbeispielen implementiert sein.
In 5 wird ein automatisierbares Abrufen von Parametern bzw. tatsächlichen momentanen Messwerten illustriert. Der jeweilige Nutzer I kommuniziert beispielsweise ausschließlich mit der Datenverarbeitungs-Entity 5, und ein oder mehrere Hosts bzw. Klima-Dienstleister 6 rufen tatsächliche Messwerte (z.B. Temperatur, Temperaturverlauf) in einer Klimaumgebung 9 und/oder an einzelnen Geräten 1 ab. Durch Vernetzung der Dienstleister 6 mit der Datenverarbeitungs-Entity 5 können momentane bzw. dynamisch aktualisierte Klimapräferenzdaten mehr oder weniger in Echtzeit berücksichtigt werden.
In 6 ist eine GUI 15 illustriert, über welche z.B. auf einem SmartPhone 20 ein skalierbares Komfort-Rating Sp eingegeben werden kann, beispielsweise auf einer Skala von 1 (gar nicht komfortabel) bis 5 (sehr komfortabel) bezüglich des gesamten Komfort-Empfindens oder auch nur bezüglich z.B. des Wärmeempfindens (Stellgrößen dann z.B. nur Temperatur und/oder Feuchte), oder z.B. bezüglich Frischluft, Lichtimpact und/oder akustischen Einflüssen. Letztere können z.B. dann als nachteilig empfunden werden, wenn die zu klimatisierende Klimaumgebung (Raum, Wohnung, Haus, oder dergleichen) an einer Straße oder nahe eines großen Wasserfalls liegt. Wahlweise kann dieselbe GUI 15 oder eine weitere GUI auch genutzt werden, um nutzerspezifische Parameter Pp zu hinterlegen, z.B. ein gewünschter Temperaturverlauf (T(t)), insbesondere zeit- und/oder ortsbezogen (z.B. je Wohnraum, z.B. morgens kühler als abends).
In 7 werden beispielhafte Nutzungsmöglichkeiten näher erläutert: Die Strichlinie deutet eine Systemgrenze zum Daten-Host 5 an. Dargestellt wird die Generierung eine Komfort-Trajektorie in Reaktion auf eine Anfrage seitens des HLK-/PCS-Systems 1 und/oder seitens eines weiteren Hosts 6, 7. Alternativ ist auch eine automatische Generierung basierend auf Anfangsbedingungen und regelmäßiger Wiederholung realisierbar. Der Buchstabe „y“ bedeutet im jeweiligen Flussdiagramm (auch 8 bis 10) jeweils einen Ja/Yes-Abzweig, und der Buchstabe „n“ bedeutet einen Nein/No-Abzweig.
Schritt bzw. Feld 200: Ein HLK-/PCS-Systembetreiber 1 bzw. ein weiterer Host 6, 7 kann aufbereitete Klimapräferenzdaten D anfragen, insbesondere Anfrage einer Komfort-Trajektorie für Nutzer n in einer bestimmten Gruppe GI an einem bestimmten Ort (GPS-Daten) für einen bestimmten Zeitpunkt t und/oder für eine bestimmte (Nutzungs-)Dauer für einen bestimmten Raum eines vordefinierten Gebäudes.
Schritt 201: Es wird ein Datenverarbeitungs-Vorgang beim Host 5 initiiert.
Schritt 202: Diese Abfrage bzw. Entscheidung verifiziert, ob die aktuelle Zeit (Zeitpunkt) den Startzeitpunkt der angeforderten Komfort-Trajektorie abzüglich der notwendigen Vorlaufzeit zur Sicherstellung der klimatischen Konditionierung erreicht hat. Falls es noch zu früh ist, wird im Schritt 203 der Prozess angehalten bzw. noch „on hold“ gesetzt, bis dieser Zeitpunkt erreicht wird. Falls der Zeitpunkt erreicht wurde, wird mit dem Schritt 204 fortgefahren.
Schritt 203: Der Prozess wird angehalten, bis die Fortsetzungsbedingungen erfüllt sind.
Schritt bzw. Feld 204: Für den ersten (oder einzigen) Nutzer I in der Personengruppe GI wird der momentane und vorhersagbare Zustand ermittelt.
Schritt 205: Eine Komfort-Trajektorie wird basierend auf dem momentanen und vorhersehbaren Zustand des Nutzers I und der vorausgesagten klimatischen Bedingungen und seiner Nutzerpräferenzcharakteristik insbesondere unter Berücksichtigung seines minimalen Komfort-Schwellwertes generiert.
Schritt 206: Falls noch weitere Nutzer I in der Personengruppe GI vorhanden sind, werden die Schritte 204 und 205 wiederholt.
Schritt 207: Sind mehrere Nutzer im zu klimatisierenden Raum anwesend, werden alle Komfort-Trajektorien der Nutzer der Gruppe GI zu einer einzigen Komfort-Trajektorie verarbeitet bzw. konsolidiert (Datenzusammenführung). Daher überprüft diese Entscheidung nach der Generierung aller in der entsprechenden Situation relevanten Komfortprofile, ob es auch mehrere Nutzer in der Personengruppe GI gibt. Alternativ könnte sequentiell die finale Komfort-Trajektorie mit jeder neuen individuellen Komfort-Trajektorie vor der entsprechenden Daten-Übermittlung aktualisiert werden.
Schritt 209: Wenigstens eine Entity 1, 6, 7 wendet die vom Daten-Host 5 übermittelte Komfort-Trajektorie an, um demnach den Raum bzw. die Klimaumgebung nach deren Vorgaben zu konditionieren. Hier wird eine Steuerung dargestellt, welche ohne Einflussnahme des Nutzers vorgenommen wird, was einem bevorzugten anwendungs-/nutzerfreundlichen Szenario entspricht. Dies schließt jedoch keinesfalls Eingriffe auf die Konditionierung des Raumes durch den Nutzer während des Aufenthalts aus.
In 8 wird ein beispielhafter Prozess im Zusammenhang mit der Datenpflege durch einen Nutzer beschrieben; insbesondere wird dargestellt, wie nach erfolgter Registrierung eines Nutzers eine Generierung oder Aktualisierung von dessen Nutzerpräferenzcharakteristik erfolgen kann; insofern beschreibt 8 auch die Datenerfassungs- und aufbereitungs-Aspekte der vorliegenden Erfindung, also Handlungen des Daten-Hosts 5 an der nutzerseitigen Schnittstelle:

Schritt 300: Der Prozess wird mit der Registrierung eines Nutzers gestartet.
Schritt 301: Falls die Registrierung über eine Eingabeterminal 15, 20 erfolgt ist, so kann die Registrierung mit einem Komfort-Rating gekoppelt sein; falls kein Komfort-Rating vorliegt, kann mit Schritt 309 fortgefahren werden; falls Komfort-Rating vorliegen, wird mit Schritt 302 fortgefahren.
Schritt 302: Anwendung von Komfort-Ratings und der damit korrelierten Zustände des Nutzers (insbesondere momentane Aktivität) sowie klimatischer (Außen-)Bedingungen und Meta-Daten, zur Aktualisierung der Nutzerpräferenzcharakteristik, insbesondere unter Berücksichtigung des Alters der neuen und der vorherigen (älteren, zurückliegenden) Komfort-Ratings des Nutzers.
Schritt 303: Hier wird überprüft, ob der Nutzer einer Nutzergruppe zugeordnet ist. Falls dem so ist, wird mit Schritt 305 fortgefahren. Falls dem nicht so ist, wird mit Schritt 304 fortgefahren.
Schritt 304: Da es nicht zwingend eine Nutzergruppe mit deren Nutzer(gruppen)präferenzcharakteristik zu den Komfort-Erwartungen des hier verarbeiteten Nutzers passen muss (kein Matching), wird in diesem Schritt überprüft, ob es eine Nutzergruppe gibt, die (besser) zum verarbeiteten Nutzer passt. Falls dem so ist, wird der Prozess mit Schritt 307 fortgesetzt. Falls der Nutzer nicht mit einer (bzw. mit keiner) Nutzergruppe matcht, wird mit Schritt 306 fortgesetzt.
Schritt 305: In diesem Schritt wird überprüft, ob die aktualisierte Nutzerpräferenzcharakteristik mit derjenigen der Gruppe übereinstimmt, welcher der Nutzer zugeordnet ist. Falls eine Übereinstimmung gegeben ist, wird mit Schritt 308 fortgefahren. Im gegensätzlichen Fall wird der Prozess mit Schritt 304 fortgesetzt.
Schritt 306: Falls es eine Zuordnung zwischen Nutzer und Nutzergruppe gibt, wird diese aufgehoben.
Schritt 307: Ordne den Nutzer der angepassten neuen (besser passenden) Nutzergruppe zu.
Schritt 308: Aktualisiere die Nutzergruppenpräferenzcharakteristik unter Einbezug mit der aktualisierten Nutzerpräferenzcharakteristik der Nutzers I. Der Schritt 308 kann dabei auch wenigstens einen selbstlernenden Algorithmus umfassen, insbesondere zum nachhaltigen Erstellen einer belastbaren Nutzergruppenpräferenzcharakteristik. Die Begriffe Nutzergruppenpräferenzcharakteristik und Nutzerpräferenzcharakteristik können hier synonym verstanden werden, also der Oberbegriff Nutzerpräferenzcharakteristik kann den Begriff Nutzergruppenpräferenzcharakteristik umfassen (implizieren).
Schritt 309: In diesem Schritt wird überprüft, ob vom jeweiligen Nutzer oder im Zusammenhang mit dem jeweiligen Nutzer Meta-Daten erfasst worden sind. Diese können dazu herangezogen werden, den Nutzer I mit besserem Matching einer Gruppe zuzuordnen, wie es im Schritt 310 erläutert wird. Schritt 310: Wende Meta-Daten an, um den entsprechenden Nutzer einer (neuen, alternativen) Nutzergruppe zuzuordnen.

In Hinblick auf eine Nutzergruppenpräferenzcharakteristik ist zu erwähnen, dass das erfindungsgemäße System/Verfahren zwischen zwei Arten von Nutzern unterscheiden kann, insbesondere in Abhängigkeit von deren Gruppenzuordnung: Die an einen systemfremden Host zu übergebende Sollwert-Trajektorie kann z.B. bezüglich aller in einem zu klimatisierenden Raum anwesenden Nutzer eine fusionierte bzw. konsolidierte Trajektorie basierend auf den mehreren Nutzern sein, oder die Sollwert-Trajektorie wird lediglich dadurch generiert, dass der Nutzer (insbesondere auch basierend auf Meta-Daten) einer Nutzergruppe zugeordnet wird/wurde, für welche Nutzergruppe die Sollwert-Trajektorie situationsbezogen generiert wird, insbesondere auch in Abhängigkeit der momentanen Aktivität des Nutzers. Der Begriff Nutzer schließt diese beiden Interpretationen mit ein, sofern in der vorliegenden Offenbarung nichts Gegenteiliges erläutert wird.
In 9 wird ein beispielhafter Prozess im Zusammenhang mit der Anfrage einer Komfort-Trajektorie (Dienstleistungs-Gesuch seitens eines systemfremden Hosts, z.B. seitens eines HLK-/PCS-System-Betreibers); insofern beschreibt 9 auch die Datenbereitstellungsseite der vorliegenden Erfindung, also Handlungen des Daten-Hosts 5 an der bzw. für eine Steuerungs-/Regelungs-Schnittstelle.
In diesem Flussdiagramm wird die Generierung der Komfort-Trajektorie für einen individuellen Nutzer dargestellt, insbesondere in Abhängigkeit davon, ob der jeweilige Nutzer bereits ein Komfort-Profil aufweist oder sich einer Nutzergruppe mit bereits vordefiniertem Komfort-Profil zuordnen lässt. Nicht dargestellt wird, welche Bedingung diese Verarbeitung in Gang setzen. Es könnte wahlweise eine automatisch Verarbeitung oder eine Verarbeitung nach Bedarf sein.

Schritt 400: Der Prozess wird mit einer Anfrage einer Komfort-Trajektorie für Nutzer I begonnen.
Schritt 401: Nach dem Prozessstart wird verifiziert, ob der Nutzer I bereits eine Nutzerpräferenzcharakteristik 4 besitzt. Falls dem so ist, wird der Prozess mit Schritt 402 fortgesetzt. Im gegensätzlichen Fall wird mit Schritt 403 fortgesetzt.
Schritt 402: In diesem Schritt wird die hinterlegte individuelle Nutzerpräferenzcharakteristik ermittelt bzw. herangezogen.
Schritt 403: Es wird in diesem Schritt überprüft, ob der Nutzer I einer Personengruppe GI zugeordnet ist. Falls dem so ist, wird mit Schritt 404 fortgesetzt. Im gegensätzlichen Fall wird mit Schritt 405 fortgesetzt.
Schritt 404: In diesem Schritt wird die hinterlegte Nutzergruppenpräferenzcharakteristik ermittelt bzw. herangezogen.
Schritt 405: Da es für diesen (neuen) Nutzer weder eine individuelle Nutzerpräferenzcharakteristik noch eine Nutzergruppenpräferenzcharakteristik gibt, wird zunächst eine/die beim Daten-Host hinterlegte Standardpräferenzcharakteristik genutzt. Hierdurch kann sichergestellt werden, dass jeder Nutzer die im Allgemeinen als bestmöglich anerkannte Komfort-Erfahrung macht, insbesondere da die Standardpräferenzcharakteristik basierend auf allen Nutzern des Systems bzw. den Nutzern der entsprechenden Nutzergruppe regelmäßig aktualisiert werden kann.
Schritt 406: In diesem Schritt wird die Komfort-Trajektorie mit der ermittelten Präferenzcharakteristik unter Berücksichtigung des Zustands des Nutzers und/oder einer Klima-/Wettervorhersage und/oder des Raumtyps (sowie gegebenenfalls einer Raumbelegung) und eingestellten oder automatisch ermittelten, minimalen Komfort-Schwellwerten ermittelt.

In 10 wird ein Prozess die Datenpflege und -aufbereitung im Zusammenhang mit Komfort-Ratings erläutert, insbesondere unter Einbezug spezifischer Klimaumgebungen und wahlweise auch externer (Wetter-)Daten. Das Flussdiagramm veranschaulicht, auf welche Weise ein Komfort-Rating erfasst bzw. verarbeitet werden kann.

Schritt 500: Der Verarbeitungsprozess beginnt durch die Erfassung eines neuen Komfort-Ratings des Nutzers, bzw. durch entsprechende Datenpflege durch den Nutzer I.
Schritt 501: Grundsätzlich besteht die Möglichkeit, ein Komfort-Rating zu jeglichen Gebäuden und beliebigen Räumen vorzunehmen, in denen das Raumklima konditioniert wird. Daher wird in diesem Schritt überprüft, ob das Rating ein Gebäude betrifft, welches dem System (bzw. Daten-Host) bekannt ist. Im gegeben Fall wird der Prozess mit Schritt 502 fortgesetzt, im gegensätzlichen mit Schritt 507.
Schritt 502: Es wird derjenige Raum ermittelt, mit welchem das Komfort-Rating assoziiert wird. Hier können zwei Fälle unterschieden werden. Im ersten Fall befindet sich der Nutzer momentan in demjenigen Raum (Klimaumgebung), zu welchem das Komfort-Rating abgegeben wird, oder aber der Nutzer bewertet sein Komfortempfindung im Nachhinein. In beiden Fällen ist es wünschenswert, den Raum zu ermitteln. Falls kein Raum ermittelt werden kann, so wird das Komfort-Rating mit einem Standardraum bzw. einer möglicherweise nutzerspezifizierten Standard-Klimaumgebung assoziiert.
Schritt 503: Um den Eingabeaufwand für den Nutzer so gering wie möglich zu gestalten, wird ermittelt, ob es aktuelle Klimabedingungen zum momentan genutzten Raum gibt. Falls dem so ist, wird mit Schritt 504 fortgesetzt. Im gegensätzlichen Fall wird mit Schritt 505 fortgesetzt.
Schritt 504: Das Komfort-Rating wird mit den erfassten Raumklimabedingungen assoziiert.
Schritt 505: Auf Grund von Wärmeaustauschphänomene zwischen den Räumlichkeiten in einem Gebäude ist davon auszugehen, dass andere Räume ähnlich konditioniert sind wie derjenige Raum, für welchen das Komfort-Rating erfasst worden ist. Falls keine Raumklimabedingungen bekannt bzw. hinterlegt sind, können als Rückfalllösung die über das Gebäude gemittelten Raumklimabedingungen herangezogen werden. Falls diese jedoch nicht existieren, wird mit Schritt 507 fortgesetzt, andernfalls mit Schritt 506.
Schritt 506: Das Komfort-Rating wird mit den erfassten Gebäudeklimabedingungen assoziiert.
Schritt 507: Nur wenn es anders nicht möglich ist, wird der Nutzer aufgefordert, die zu assoziierenden Klimabedingungen zu erfassen. Dies kann der Nutzer beispielsweise auch manuell bzw. analog durch Ablesen von Wetterstationen oder Thermometern bewerkstelligen; wahlweise können auch offene Sensorschnittstellen ausgelesen bzw. über den Nutzer zugänglich gemacht werden.
Schritt 508: Der letzte Verarbeitungsschritt ist die Speicherung der Klimabedingungen, des wenigstens einen Komfort-Ratings und des Nutzerzustands (falls vorhanden) im Datenraum 3.

Aus den Flussdiagrammen der 7 bis 10 wird deutlich, an welchen Schnittstellen und in Hinblick auf welche datentechnischen Herausforderungen die vorliegende Erfindung durch eine Konsolidierung der verfügbaren Daten und eine Berücksichtigung der momentanen Komfort-Empfindungen eines jeweiligen Nutzers Synergieeffekte sowohl hinsichtlich Datenerfassung, Datenaufbereitung und Datennutzung bzw. Datenbereitstellung liefert, und dabei wahlweise auch einen Steuerungs-/Regelungsaspekt berücksichtigen kann. Erwartungsgemäß lässt sich das erfindungsgemäße System besonders dann vorteilhaft implementieren, wenn die Schnittstelle zu den jeweiligen HLK-PCS-Steuerungs-/Regelungssystemen eine Schnittstelle zu systemfremden Systemen bleibt, also wenn die je nach Anwendungsfall spezifische Steuerung/Regelung vom entsprechenden HLK-/PCS-System-Betreiber durchgeführt wird, basierend auf den vom Daten-Host 5 bereitgestellten nutzerspezifischen aktuellen zeit-/ortsaufgelösten Klimapräferenzdaten. Die konkrete Zusammensetzung des Parametersatzes und die jeweils gewünschte Gewichtung lassen sich anwendungsspezifisch definieren und auch in Hinblick auf Vorstellungen von HLK-/PCS-SystemBetreibern und/oder Energieverwaltungs-Entities konkretisieren. Durch Aggregation und Kombination von Daten basierend auf nutzerspezifischen Ratings liefert die vorliegende Erfindung einen Mehrwert hinsichtlich der Güte und der Menge der bei der Datenaufbereitung einbezogenen Informationen und kann dadurch einen guten Kompromiss aus maximal positivem Komfort-Empfinden und minimiertem Energieverbrauch liefern. Insbesondere im Vergleich zu bisherigen SmartHome-Lösungen ermöglicht die vorliegende Erfindung auch dahingehend einen Mehrwert, dass die technischen Möglichkeiten besonders nachhaltig ausgenutzt werden, um den Energieverbrauch nur dann zu steigern, wenn dies in Hinblick auf das Wohlbefinden des Nutzers auch gewünscht bzw. erforderlich ist. Nicht zuletzt ermöglicht die vorliegende Erfindung eine Verbesserung des Energiemanagements (sei es in absoluter Hinsicht, sei es aus Sicht der die Energie bereitstellenden Dienstleister) basierend auf belastbaren Energiebedarfsprognosen.
Bezugszeichenliste

1: HLK-/PCS-System bzw. HVAC-/PCS-System (HVAC- und/oder PCS-System)
3: Datenraum bzw. Cloud
4: Nutzerpräferenzcharakteristik als Basis für individuelle Klimapräferenzdaten
5: Daten-Host bzw. Datenbe-/verarbeitungs-Entity
6: weiterer Host (Klima-Host) bzw. Klima-Dienstanbieter, z.B. Hoteldienstleister
7: HLK-/HVAC-System-Betreiber bzw. BMS bzw. Energieverwaltungs-Entity
9: geschlossene bzw. abgrenzbare Klimaumgebung (insbesondere Haus, Wohnung)
10: Kommunikationspfad, bevorzugt drahtlos
11: erster Kommunikationspfad, bevorzugt drahtlos
12, 12a: zweiter Kommunikationspfad, bevorzugt drahtlos
13: dritter Kommunikationspfad, bevorzugt drahtlos
14: vierter Kommunikationspfad (zwischen HLK-/PCS-System und System-Betreiber)
15: Eingabe-/Kommunikationsmaske bzw. GUI
20: Eingabe-/Kommunikationsgerät
30: Computerprogrammprodukt
31: Programmierschnittstelle, insbesondere auf erstem Kommunikationspfad
32: Programmierschnittstelle, insbesondere auf zweitem Kommunikationspfad
33: Programmierschnittstelle, insbesondere auf drittem Kommunikationspfad
100: Kommunikations-/Steuerungs-/Regelungssystem
D: Klimapräferenzdaten
Dp: personenbezogener Bewertungshistorienparameter
GPp: personenbezogene oder personengruppenbezogene Parametergruppe
GI: Gruppe von Individuen
Hp: individuelle (personenbezogene) Luftfeuchtigkeit bzw. Luftfeuchtigkeitspräferenz
Hp(t,s): individuelle Luftfeuchtigkeitsschwankungspräferenz als Funktion von Zeit/Ort
I: Nutzer, Person, Individuum allgemein (wahlweise auch Lebenwesen wie z.B. Haustier)
GPSp: personenbezogener Aufenthaltsorts- und/oder Distanz-Parameter (mit Raumkennzahl S_n)
Pp: personenbezogener Steuerungs-/Regelungsparameter (allgemein)
Sp: subjektives personenbezogenes Komfort-Rating bzw. subjektive Stellgröße/Stellparameter
Tp: individuelle Temperatur bzw. Temperaturpräferenz
Tp(t,s): individuelle Temperaturschwankung als Funktion von Zeit/Ort

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 Patentliteratur

EP 1806543 [0003]

Claims

Kommunikations- und Steuerungs-/Regelungssystem (100) zur Datenaufbereitung für ein nutzerdatenbasiertes Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems (1) basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) zum Bereitstellen von Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters aus einer personenbezogenen Parametergruppe (GPp) umfassend zumindest die folgenden zeit-/ortsaufgelösten personenbezogenen Parameter eingerichtet ist: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort (GPSp) des Nutzers; - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) wenigstens einen uni-/oder bidirektionalen Kommunikationspfad aus der folgenden Gruppe nutzt oder bereitstellt: Kommunikationspfad (11) zwischen einer jeweiligen Person (I) und einem Daten-Host (5) und/oder einem Datenraum (3), Kommunikationspfad (12) zwischen einem/dem Daten-Host (5) und der jeweiligen Person (1) und/oder dem Datenraum (3), Kommunikationspfad (13) zwischen einem HLK-/PCS-System-Betreiber (7) und dem Daten-Host (5) und/oder dem Datenraum (3); - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) für die wenigstens eine Person (1) eine Eingabe-/Kommunikationsmaske (15) zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum durch Hinterlegen wenigstens eines subjektiven Komfort-Ratings (Sp) und/oder des wenigstens einen personenbezogenen Parameters (Pp) bereitstellt, insbesondere durch Cross Domain Content Management, wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist für eine Zeit- und/oder Ortsauflösung der nutzerspezifischen Komfort-Ratings (Sp) und der personenbezogenen Parameter (Sp) und eingerichtet ist zum Hinterlegen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4); - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist, die Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters (Pp) basierend auf den Komfort-Ratings (Sp) und/oder basierend auf bereits hinterlegten, momentan durch den jeweiligen Nutzer eingegebenen und/oder automatisiert abgerufenen zeit-/ortsaufgelösten personenbezogenen Parametern (Pp) aus der Nutzerpräferenzcharakteristik (4) aus dem Datenraum zu generieren und insbesondere für einen/den HLK-/PCS-System-Betreiber (7) bereitzustellen, insbesondere in Echtzeit.
Kommunikations- und Steuerungs-/Regelungssystem (100) zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems (1) basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Generieren/Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf einer personenbezogenen Parametergruppe (GPp) zumindest umfassend die folgenden personenbezogenen zeit- und/oder ortsaufgelösten Parameter: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort (GPSp) des Nutzers; - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist, über wenigstens drei Kommunikationspfade (10; 11,12,13) zu kommunizieren bzw. Daten auszutauschen, nämlich über eine Kommunikationspfad (11) zwischen einer jeweiligen Person (I) und einem Daten-Host (5) und/oder über eine Kommunikationspfad (12) zwischen dem Daten-Host (5) und dem Datenraum (3) und/oder über einen Kommunikationspfad (13) zwischen einem HLK-/PCS-System-Betreiber (7) und dem Daten-Host (5) und/oder dem Datenraum (3); - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist, für die wenigstens eine Person (I) eine Eingabe-/Kommunikationsmaske (15) zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum bereitzustellen, insbesondere durch Cross Domain Content Management, zum Hinterlegen oder Eingeben wenigstens eines subjektiven Komfort-Ratings (Sp) und/oder des wenigstens einen personenbezogenen Parameters (Pp), zum Erstellen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4) und zum Generieren/Vorgeben des personenbezogenen Steuerungs-/Regelungsparameters (Pp) basierend auf der Nutzerpräferenzcharakteristik; - wobei die Komfort-Ratings (Sp) zeit- und/oder ortsaufgelöst sind; - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Bereitstellen der zeit-/ortsaufgelösten Komfort-Ratings (Sp) und Steuerungs-/Regelungsparameters (Pp) für einen/den HLK-/PCS-System-Betreiber (7) für die dynamische Steuerung/Regelung des jeweiligen HLK-/PCS-Systems (1), insbesondere in Echtzeit.
Kommunikations- und Steuerungs-/Regelungssystem nach Anspruch 1 oder 2, wobei der wenigstens eine Steuerungs-/Regelungsparameter basierend auf den Komfort-Ratings auf automatisierte Weise für den jeweiligen Nutzer für eine nutzerspezifische Energieverbrauchsoptimierung generierbar ist, indem basierend auf den Komfort-Ratings ein nutzerspezifischer unterer Energieverbrauchslevel entsprechend einem unteren Komfort-Schwellwert ermittelt wird, insbesondere durch Vorgeben eines optimalen nutzerspezifischen Verhältnisses aus einer Energieverbrauchskennzahl und einer Komfort-Kennzahl.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Parametergruppe auch einen nutzerspezifischen Aktivitäts-Parameter umfasst, insbesondere charakterisierend die Art der Aktivität und die Nutzerpräferenz für die jeweilige Aktivität, wobei die Nutzeraktivität wahlweise gemäß dem hinterlegten Nutzerverhalten und/oder Aufenthaltsort prognostiziert und/oder durch Bezugnahme auf einen Tageszeit-/Jahreskalender und/oder basierend auf einer momentanen Herz-/Atemfrequenz oder einem Bewegungsprofil des Nutzers geschätzt/vordefiniert ist.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die durch den Nutzer über die individuellen Klimapräferenzdaten gepflegte personenbezogene Parametergruppe wahlweise auch mit wenigstens einem der folgenden nichtpersonenbezogenen Parameter korreliert ist, zum Generieren/Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters: prognostizierte ortsbezogene Außenklimabedingung, Tageszeit, Kalenderdatum.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Klimapräferenzdaten vom jeweiligen Nutzer optional zeitspezifisch und/oder ortsspezifisch hinterlegbar sind, insbesondere basierend auf Geofencing durch Korrelation der Klimapräferenzdaten mit GPS-Daten eines momentanen Aufenthaltsortes des jeweiligen Nutzers und/oder mit für den Aufenthaltsort des Nutzers verfügbaren Wetterdaten.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei eine/die Zeitauflösung auf einen momentanen Tageszeitpunkt bezogen ist, insbesondere in Hinblick auf eine in den Klimapräferenzdaten hinterlegte Nutzerpräferenz mit Tagesverlaufs-Zeitabhängigkeit.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Eingabe-/Kommunikationsmaske eingerichtet ist zum Definieren von personenbezogenen Zeitfenstern oder Tageszeitabschnitten individueller Dauer für den Aufenthalt des jeweiligen Nutzers an spezifischen Orten oder in spezifischen Wohnräume, insbesondere unter Berücksichtigung eines momentanen Aufenthaltsorts des Nutzers.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei vom jeweiligen Nutzer momentane Aufenthaltsortsdaten über den wenigstens einen Kommunikationspfad übermittelbar und/oder vom Daten-Host abrufbar sind.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Parametergruppe wenigstens einen weiteren Parameter aus der folgenden Gruppe umfasst: nutzerspezifischer Aktivitäts-Parameter, insbesondere zeit- und/oder ortsaufgelöst; prognostizierte ortsbezogene und zeitaufgelöste Außenklimabedingung, korreliert mit wenigstens einem der personenbezogenen Parameter.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Klimapräferenzdaten personenbezogene Metadaten umfassen, die aus einer subjektiv erlebten thermischen/klimatischen Erfahrung des jeweiligen Nutzers aus bereits erfassten/erzeugten Klimapräferenzdaten und/oder aus den nutzerspezifischen Komfort-Ratings generiert sind, zur Anpassung und zukünftigen Vorgabe des wenigstens einen Steuerungs-/Regelungsparameters.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Klimapräferenzdaten personenbezogene Metadaten umfassen, die mit einem personenbezogenen Bewertungshistorienparameter korreliert sind, welcher den Zeitpunkt oder das Alter eines Komfort-Ratings oder Nutzerpräferenzcharakteristik in die Datenverarbeitung durch den Daten-Host einbezieht.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei eine nutzerspezifische Sollwert-Trajektorie unter Berücksichtigung einer klimatischen Trägheit eines entsprechenden HLK-/PCS-Systems zur Vorgabe des wenigstens einen Steuerungs-/Regelungsparameters aus den Klimapräferenzdaten generierbar ist und in zeitlicher Hinsicht auf die Steuerung/Regelung des HLK-/PCS-Systems adaptierbar ist, insbesondere basierend auf einer HLK-/PCS-systemimmanenten Regelungslogik, insbesondere bereitgestellt oder bereitstellbar seitens des HLK-/PCS-System-Betreibers, insbesondere zwecks Energieeinsparung.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei eine nutzerspezifische Sollwert-Trajektorie unter Berücksichtigung einer klimatischen Trägheit eines entsprechenden HLK-/PCS-Systems auf die Regelung des HLK-/PCS-Systems in zeitlicher Hinsicht adaptierbar ist, indem ein HLK-/PCS-System-spezifischer Trägheits-Zeitwert bei der Steuerung/Regelung des entsprechenden HLK-/PCS-Systems zur Vorgabe eines Ein-/Ausschaltzeitpunktes und/oder einer Vorlaufzeitdauer für das HLK-/PCS-System vorgebbar ist, insbesondere basierend auf einer HLK-/PCS-systemimmanenten Regelungslogik, insbesondere unter Berücksichtigung der thermischen Eigenschaften der jeweiligen Klimaumgebung und durch Abgleich von Soll- und Ist-Klimazeitreihen.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei der wenigstens eine Steuerungs-/Regelungsparameter basierend auf einer Gewichtung des jeweiligen Alters mehrerer Komfort-Ratings desselben Nutzers auf automatisierte Weise generierbar ist, indem das jeweils jüngste Komfort-Rating des Nutzers mit der momentan stärksten Gewichtung attributiert ist/wird, insbesondere derart, dass die Nutzerpräferenzcharakteristik durch zeitlich gewichteten Klimapräferenzdaten gekennzeichnet ist, insbesondere bei mit der seit dem entsprechenden Rating vergangenen Zeit exponentiell fallender Abhängigkeit.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise basierend auf dem wenigstens einen Steuerungs-/Regelungsparameter durchführbar ist, wobei dieser wenigstens eine Steuerungs-/Regelungsparameter ein gemittelter Steuerungs-/Regelungsparameter oder ein bezüglich eines oder mehrerer Nutzer/Individuen gewichteter Nutzerdatenverarbeitungsparameter ist, der aus einer Mehrzahl von individuellen Steuerungs-/Regelungsparametern mehrerer Personen gebildet ist, insbesondere in Echtzeit in Abhängigkeit einer momentanen oder vordefinierten Belegung eines geschlossenen Raumes durch die mehreren Individuen;
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei die Nutzerpräferenzcharakteristik eine personengruppenbezogene Nutzerpräferenzcharakteristik ist, wobei ein/der jeweilige Nutzer basierend auf Nutzerkennwerten, wie z.B. Alter, Gewicht, Größe, Geschlecht, einer bestimmten Personengruppe zuordenbar ist und die Nutzerpräferenzcharakteristik für diesen Nutzer deduktiv aus der Nutzerpräferenzcharakteristik dieser Personengruppe ermittelbar ist, insbesondere basierend auf der Auswertung von Metadaten.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei das kommunikative Steuern/Regeln durch den wenigstens einen Nutzer über die Eingabe-/Kommunikationsmaske realisierbar ist, indem über eine Internetseite, die in programmcodetechnischer Einbettung wenigstens einer GUI und/oder wenigstens eines Inlineframes in eine weitere insbesondere systemfremde Internetseite integriert ist, insbesondere HTML5, die Angaben des Nutzers bezüglich subjektiver Komfort-Ratings und/oder des wenigstens einen personenbezogenen Parameters hinterlegbar oder anpassbar sind.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei das Kommunikations- und Steuerungs-/Regelungssystem auf wenigstens einem der Kommunikationspfade wenigstens eine Programmierschnittstelle zur Verlinkung oder programmiertechnischen Einbettung von in maschinenlesbarer Sprache geschriebenen Elementen, insbesondere HTML-Elemente, bereitstellt, insbesondere eine REST API.
Kommunikations- und Steuerungs-/Regelungssystem nach einem der vorhergehenden Ansprüche, wobei das Kommunikations-/Steuerungs-/Regelungssystem eingerichtet ist zur Auswertung der zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose durch Invertierung, indem momentane oder zukünftige Ist-Werte der Steuerungs-/Regelungsparameter mit den Klimapräferenzdaten des jeweiligen Nutzers korrelierbar sind und indem eine zu erwartende Nutzerpräferenz deduktiv im Rückschluss von vorgegebenen oder tatsächlich gemessenen klimatischen Zuständen ermittelbar ist, insbesondere für eine Last-/Energieverbrauchsreduktion in Abhängigkeit des vorhergesehenen oder zu erwartenden Nutzerverhaltens und momentanen oder zukünftigen Nutzer-Aufenthaltsortes.
Kommunikations- und Steuerungs-/Regelungssystem (100) zur Datenaufbereitung und Datenbereitstellung zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems (1) basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Bereitstellen von Klimapräferenzdaten zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters aus einer personenbezogenen Parametergruppe (GPp) zumindest umfassend die folgenden personenbezogenen zeit- und/oder ortsaufgelösten Parameter: individuelle Temperatur (Tp), individuelle Luftfeuchtigkeit (Hp), individueller Temperaturverlauf als Funktion von Ort und/oder Zeit (Tp(t,s)), individuelle Luftfeuchtigkeitsschwankung als Funktion von Ort und/oder Zeit (Hp(t,s)), Aufenthaltsort (GPSp) des Nutzers; - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist, Daten über wenigstens drei Kommunikationspfade (10; 11,12,13) auszutauschen, nämlich über eine Kommunikationspfad (11) zwischen einer jeweiligen Person (I) und einem Daten-Host (5) und/oder über eine Kommunikationspfad (12) zwischen dem Daten-Host (5) und dem Datenraum (3) und/oder über einen Kommunikationspfad (13) zwischen einem HLK-/PCS-System-Betreiber (7) und dem Daten-Host (5) und/oder dem Datenraum (3); - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist, für die wenigstens eine Person (I) eine Eingabe-/Kommunikationsmaske (15) zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum bereitzustellen, insbesondere durch Cross Domain Content Management, zum Hinterlegen wenigstens eines subjektiven Komfort-Ratings (Sp) und/oder des wenigstens einen personenbezogenen Parameters (Pp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Erstellen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4) und zum Vorgeben des personenbezogenen Steuerungs-/Regelungsparameters (Pp) basierend auf der Nutzerpräferenzcharakteristik; - wobei die Komfort-Ratings (Sp) zeit- und/oder ortsaufgelöst sind; - wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Bereitstellen der zeit-/ortsaufgelösten Komfort-Ratings (Sp) in Form von nutzerspezifischen Klimapräferenzdaten zum Bestimmen des entsprechenden Steuerungs-/Regelungsparameters (Pp) für einen/den HLK-/PCS-System-Betreiber (7), insbesondere in Echtzeit; wobei das Steuern/Regeln durch den wenigstens einen Nutzer über die Eingabe-/Kommunikationsmaske realisierbar ist, indem über eine Internetseite, die in programmcodetechnischer Einbettung wenigstens einer GUI und/oder wenigstens eines Inlineframes in eine weitere Internetseite integriert ist, die Angaben des Nutzers bezüglich subjektiver Komfort-Ratings und/oder des wenigstens einen personenbezogenen Parameters hinterlegbar oder anpassbar sind, wobei das Kommunikations- und Steuerungs-/Regelungssystem auf wenigstens einem der Kommunikationspfade wenigstens eine Programmierschnittstelle zur Verlinkung oder programmiertechnischen Einbettung von in maschinenlesbarer Sprache geschriebenen Elementen, insbesondere HTML-Elemente, bereitstellt, insbesondere eine REST API.
Kommunikations- und Steuerungs-/Regelungssystem (100) zur Datenaufbereitung und Datenbereitstellung für ein dynamisches nutzerdatenbasiertes Steuern/Regeln einer bedarfsangepassten zeit-/ortsaufgelösten Funktionsweise wenigstens eines HLK-/PCS-Systems (1) basierend auf einer Mehrzahl personenbezogener Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), wobei das Kommunikations-/Steuerungs-/Regelungssystem (100) eingerichtet ist zum Bereitstellen von Klimapräferenzdaten basierend auf nutzerspezifischen Komfort-Ratings, welche für die Erstellung einer Nutzerpräferenzcharakteristik herangezogen werden, wobei die bereitzustellenden Klimapräferenzdaten aus der Nutzerpräferenzcharakteristik insbesondere unter Einbezug von momentanen Zuständen der zu klimatisierenden Umgebung und/oder des jeweiligen Nutzers generiert werden und insbesondere basierend auf einer modellbasierten Repräsentation, insbesondere basierend auf einer multivarianten Wahrscheinlichkeitsverteilung, in Form einer tages-/jahreszeit- und/oder aufenthaltsortsabhängigen Sollwert-Trajektorie bereitgestellt werden; wobei das Kommunikations- und Steuerungs-/Regelungssystem (100) eingerichtet ist für die nutzerspezifische Erfassung, Berücksichtigung oder Verarbeitung wenigstens eines Merkmals, einer Größe oder wenigstens eines Parameters aus der folgenden Gruppe oder im Zusammenhang mit einer der folgenden Funktionalitäten: Definition des verwendbaren Parametersatzes, insbesondere Temperatur, Feuchte, Zeit- und/oder Ortsauflösung, insbesondere nutzerspezifisch definierte Raumnutzungen-/belegungen; Komfort-Ratings als nutzerseitig skalierte relative Stellgröße bezüglich des Komfort-Empfindens, insbesondere bei zeitabhängiger Gewichtung der einzelnen Ratings desselben Nutzers untereinander; Cross Domain Content Management, insbesondere in Ausgestaltung als auf systemfremden Internetpräsenzen einbettbare Inlineframes; Korrelation von Nutzerpräferenzcharakteristiken mit aktuellen externen Parametern, insbesondere Wetterdaten, momentaner Aufenthaltsort des Nutzers, Aktivität des Nutzers, insbesondere auch mittels bzw. basierend auf KI-basierten Algorithmen; Definition von Nutzergruppen und optionale Gewichtung des Einflusses eines Ratings unter den Nutzern innerhalb einer Gruppe, wobei Daten über die klimatischen Vorlieben der jeweiligen Nutzergruppe wahlweise auch aus externen Datenbanken zuführbar sind; automatisches Anfahren einer unteren klimatischen Toleranzgrenze, z.B. einer minimalen Temperatur, zwecks Bestimmung eines nutzerspezifisch möglichen Energieverbrauchs-Minimums; Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose, insbesondere für einen Zeitraum von mehreren Stunden, Tagen, Wochen oder Monaten; insbesondere Kommunikations- und Steuerungs-/Regelungssystem (100) gemäß einem der vorhergehenden Ansprüche.
Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte eines Verfahrens nach einem der vorhergehenden Verfahrensansprüche auszuführen, insbesondere Computerprogrammprodukt in Ausgestaltung als SmartPhone-Applikation oder Endgeräte-Applikation, insbesondere umfassend Front-End-Computerprogrammcode zum Bereitstellen einer Eingabe-/Kommunikationsmaske zum Definieren von personenbezogenen Zeitfenstern oder Tageszeitabschnitten individueller Dauer für den Aufenthalt des jeweiligen Nutzers an spezifischen Orten oder in spezifischen Wohnräume, insbesondere unter Berücksichtigung eines momentanen Aufenthaltsorts des Nutzers, wobei das Computerprogrammprodukt eingerichtet ist zur Korrelation der personenbezogenen Zeitfenster oder Tageszeitabschnitte mit über die Eingabe-/Kommunikationsmaske eingegebenen Komfort-Ratings des jeweiligen Nutzers.
Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte eines Verfahrens nach einem der vorhergehenden Verfahrensansprüche auszuführen, insbesondere Computerprogrammprodukt umfassend Back-End-Computerprogrammcode und eingerichtet für eine serverseitige Verarbeitung von personenbezogenen Klimapräferenzdaten auf automatische Weise und/oder in Reaktion auf einzelne Nutzer-Eingabe-Ereignisse, wobei sowohl nutzerspezifische Komfort-Ratings als auch personenbezogene Parameter zeit- und ortsaufgelöst verarbeitet werden, zum Erstellen einer Nutzerpräferenzcharakteristik basierend auf den Klimapräferenzdaten.
Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte eines Verfahrens nach einem der vorhergehenden Verfahrensansprüche auszuführen, wobei das Verfahren ausschließlich zur Datenerfassung und Datenbereitstellung an der Schnittstelle zwischen dem jeweiligen Nutzer und dem wenigstens einen HLK-/PCS-System-Betreiber oder einem systemfremden Host durchgeführt wird.
Verwendung eines Computerprogrammproduktes für ein Verfahren zum Generieren von Nutzerdaten und zum Bereitstellen von nutzerspezifischen Daten zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch basierend auf zeit- und/oder ortsaufgelösten Klimapräferenzdaten definierter Steuerungs-/Regelungsparameter, insbesondere bei einem Verfahren nach einem der vorhergehenden Verfahrensansprüche; wobei mehrere Kommunikationspfade genutzt werden: ein erster Kommunikationspfad zwischen einer jeweiligen Person und einem Daten-Host und/oder einem Datenraum, in welchem eine jeweilige Nutzerpräferenzcharakteristik in personenspezifischen Klimapräferenzdaten hinterlegt ist, ein zweiter Kommunikationspfad zwischen einem/dem Daten-Host und der jeweiligen Person und/oder dem Datenraum, und ein dritter Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Daten-Host und/oder dem Datenraum; wobei zur Pflege von personenspezifischen Klimapräferenzdaten im Datenraum und zum Definieren der Nutzerpräferenzcharakteristik über eine Eingabe-/Kommunikationsmaske, insbesondere in Ausgestaltung als Internetseite und/oder basierend auf der programmcodetechnischen Einbettung wenigstens eines Inlineframes, wenigstens ein subjektives Komfort-Rating und/oder der wenigstens eine personenbezogene Parameter als individuelle Nutzervorgabe hinterlegt wird; wobei die Nutzerpräferenzcharakteristik zum Generieren des wenigstens einen Steuerungs-/Regelungsparameters bereitgestellt wird, derart dass die Komfort-Ratings und/oder die personenbezogenen Parameter mit den im jeweiligen Anwendungsfall für einen einzelnen Nutzer oder eine Nutzergruppe für eine spezifische Klimaumgebung anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern korrelierbar sind, zum Erstellen einer zeit- und orts- und nutzerabhängigen Energie-/Klima-Bedarfsprognose und derart dass die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise zur bedarfsangepassten Energie-/Klima-Steuerung-/Regelung durchführbar ist, insbesondere in Echtzeit, insbesondere mit der Parametergruppe umfassend wenigstens den weiteren folgenden Parameter: nutzerspezifischer Aktivitäts-Parameter, insbesondere zeit- und/oder ortsaufgelöst; wobei das Computerprogrammprodukt bevorzugt Back-End-Computerprogrammcode umfasst und eingerichtet ist für eine serverseitige Verarbeitung von personenbezogenen Klimapräferenzdaten auf automatische Weise und/oder in Reaktion auf einzelne Nutzer-Eingabe-Ereignisse.
Verwendung eines Computerprogrammproduktes für ein Verfahren zum Generieren von Nutzerdaten und zum Bereitstellen von nutzerspezifischen Daten zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch basierend auf zeit- und/oder ortsaufgelösten Klimapräferenzdaten definierter Steuerungs-/Regelungsparameter, insbesondere bei einem Verfahren nach einem der vorhergehenden Verfahrensansprüche; wobei eine nutzerspezifische Steuerung und wahlweise auch Regelung des wenigstens eines HLK-/PCS-Systems erfolgt, indem bei der Datenverarbeitung basierend auf generierten personenspezifischen Klimapräferenzdaten eine Repräsentation erstellt wird, in welcher die Komfort-Ratings, die personenbezogenen Parameter und Klimadaten zusammengeführt werden, insbesondere unter Anwendung von auf künstlicher Intelligenz basierenden Algorithmen, insbesondere zum Maximieren des subjektiven nutzerspezifischen Komforts und zum Minimieren des dafür eingesetzten Energiebedarfs.
Verwendung eines Computerprogrammproduktes zum Bereitstellen eines Kommunikations- und Steuerungs-/Regelungssystem (100) zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) durch dynamische Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems (1) basierend auf einer Mehrzahl personenbezogener und personenspezifisch definierter Steuerungs-/Regelungsparameter (Pp; Hp, GPSp, Tp), zum Vorgeben des wenigstens einen Steuerungs-/Regelungsparameters basierend auf einer personenbezogenen Parametergruppe (GPp) insbesondere umfassend Temperatur (Tp)- und Luftfeuchtigkeitsparameter (Hp), und zum Bereitstellen einer Eingabe-/Kommunikationsmaske (15) zur Pflege von personenspezifischen Klimapräferenzdaten, insbesondere durch Cross Domain Content Management, und zum Erfassen von eingegebenen subjektiven Komfort-Ratings (Sp) und/oder wenigstens eines personenbezogenen Parameters (Pp), und zum Erstellen einer personenbezogenen oder personengruppenbezogenen Nutzerpräferenzcharakteristik (4) basierend auf zeit- und/oder ortsaufgelösten Komfort-Ratings (Sp); und zum Bereitstellen der zeit-/ortsaufgelösten Komfort-Ratings (Sp) und Steuerungs-/Regelungsparameters (Pp) für einen/den HLK-/PCS-System-Betreiber (7) für die dynamische Steuerung/Regelung des jeweiligen HLK-/PCS-Systems (1), insbesondere in Echtzeit.
Verwendung eines Computerprogrammproduktes für ein Verfahren zum Verarbeiten von Nutzerdaten zum Bereitstellen von Klimapräferenzdaten zum nutzerdatenbasierten Steuern/Regeln des bedarfsangepassten Betreibens wenigstens eines HLK-/PCS-Systems (1) zur dynamischen Steuerung/Regelung einer zeit-/ortsaufgelösten Funktionsweise des wenigstens einen HLK-/PCS-Systems basierend auf einer Mehrzahl personenbezogener und personenspezifisch basierend auf zeit- und/oder ortsaufgelösten Klimapräferenzdaten definierter Steuerungs-/Regelungsparameter, insbesondere bei einem Verfahren nach einem der vorhergehenden Verfahrensansprüche; wobei wenigstens ein Kommunikationspfad zwischen einem HLK-/PCS-System-Betreiber und dem Daten-Host und/oder einem Datenraum genutzt wird, in welchem eine jeweilige Nutzerpräferenzcharakteristik in personenspezifischen Klimapräferenzdaten hinterlegt ist, wobei wahlweise ein weiterer Kommunikationspfad zwischen einer jeweiligen Person und dem Datenraum und ein weiterer Kommunikationspfad zwischen einem Daten-Host und der jeweiligen Person und/oder dem Datenraum nutzbar ist; wobei die Pflege von personenspezifischen Klimapräferenzdaten im Datenraum und die Definition der Nutzerpräferenzcharakteristik über eine Eingabe-/Kommunikationsmaske, insbesondere in Ausgestaltung als Internetseite und/oder basierend auf der programmcodetechnischen Einbettung wenigstens eines Inlineframes, nutzerseitig über wenigstens ein subjektives Komfort-Rating und/oder über den wenigstens einen personenbezogenen Parameter als individuelle Nutzervorgabe durchführbar ist; wobei die Nutzerdaten aus der Nutzerpräferenzcharakteristik zum Generieren des wenigstens einen Steuerungs-/Regelungsparameters bereitgestellt werden, wobei die Komfort-Ratings und/oder die personenbezogenen Parameter mit den im jeweiligen Anwendungsfall für einen einzelnen Nutzer oder eine Nutzergruppe für eine spezifische Klimaumgebung anzuwendenden, systemspezifischen Steuerungs-/Regelungsparametern korreliert werden, für eine zeit- und orts- und nutzerabhängige Energie-/Klima-Bedarfsprognose, wobei die Steuerung/Regelung des HLK-/PCS-Systems auf dynamische Weise zur bedarfsangepassten Energie-/Klima-Steuerung-/Regelung durchgeführt wird, insbesondere in Echtzeit, insbesondere mit der Parametergruppe umfassend wenigstens den weiteren folgenden Parameter: prognostizierte ortsbezogene und zeitaufgelöste Außenklimabedingung, korreliert mit wenigstens einem der personenbezogenen Parameter.
Verwendung eines Computerprogrammproduktes zum Verarbeiten von Nutzerdaten zum Bereitstellen von Klimapräferenzdaten für ein dynamisches nutzerdatenbasiertes Steuern/Regeln einer bedarfsangepassten zeit-/ortsaufgelösten Funktionsweise wenigstens eines HLK-/PCS-Systems (1), wobei die Klimapräferenzdaten basierend auf nutzerspezifischen Komfort-Ratings bereitgestellt werden, welche für die Erstellung einer Nutzerpräferenzcharakteristik herangezogen werden, wobei die bereitzustellenden Klimapräferenzdaten aus der Nutzerpräferenzcharakteristik insbesondere unter Einbezug von momentanen Zuständen der zu klimatisierenden Umgebung, insbesondere Umgebungstemperatur und Umgebungsfeuchte (innen, außen), und/oder des jeweiligen Nutzers, insbesondere dessen Aktivität, generiert werden und insbesondere basierend auf einer modellbasierten Repräsentation, insbesondere basierend auf einer multivarianten Wahrscheinlichkeitsverteilung, in Form einer tages-/jahreszeit- und/oder aufenthaltsortsabhängigen Sollwert-Trajektorie bereitgestellt werden; wobei eine nutzerspezifische Erfassung, Berücksichtigung oder Verarbeitung wenigstens eines Merkmals, einer Größe oder wenigstens eines Parameters aus der folgenden Gruppe oder im Zusammenhang mit einer der folgenden Funktionalitäten mittels des Computerprogrammproduktes erfolgt: Definition des verwendbaren Parametersatzes, insbesondere Temperatur, Feuchte, Zeit- und/oder Ortsauflösung, insbesondere nutzerspezifisch definierte Raumnutzungen-/belegungen; Komfort-Ratings als nutzerseitig skalierte relative Stellgröße bezüglich des Komfort-Empfindens, insbesondere bei zeitabhängiger Gewichtung der einzelnen Ratings desselben Nutzers untereinander; Cross Domain Content Management, insbesondere in Ausgestaltung als auf systemfremden Internetpräsenzen einbettbare Inlineframes; Korrelation von Nutzerpräferenzcharakteristiken mit aktuellen externen Parametern, insbesondere Wetterdaten, momentaner Aufenthaltsort des Nutzers, Aktivität des Nutzers, insbesondere auch mittels bzw. basierend auf KI-basierten Algorithmen; Definition von Nutzergruppen und optionale Gewichtung des Einflusses eines Ratings unter den Nutzern innerhalb einer Gruppe, wobei Daten über die klimatischen Vorlieben der jeweiligen Nutzergruppe wahlweise auch aus externen Datenbanken zuführbar sind; automatisches Anfahren einer unteren klimatischen Toleranzgrenze, z.B. einer minimalen Temperatur, zwecks Bestimmung eines nutzerspezifisch möglichen Energieverbrauchs-Minimums; Erstellen einer nutzerspezifischen Energie-/Klima-Bedarfsprognose, insbesondere für einen Zeitraum von mehreren Stunden, Tagen, Wochen oder Monaten; insbesondere mittels eines Kommunikations- und Steuerungs-/Regelungssystems (100) gemäß einem der Ansprüche 1 bis 22.