API für Kalenderabfrage zur Heizungssteuerung/Gebäudeautomatisierung.



  • In unserer Gemeinde läuft die Heizungssteuerung mittels EIB/KNX Protokoll und es ist ein EIB-Server vorhanden. Bisher muss die Programmierung der Heizung auf dem EIB Server jeweils für die nächsten 7 Tage vorgenommen werden. Nun ist die Frage wie man den EIB-Server mit dem ChurchTools/Ressourcen Management verbinden könnte.

    Ist eine API denkbar, mit der der EIB-Server zyklisch (alle 10 Minuten) bei ChurchTools abfragen kann welcher Raum in welchem Zeitraum geheizt werden soll. Wenn (evtl. über eine zusätzliche Funktionalität) für jeden Raum auch eine Vorlauf-/Nachlaufzeit für die Heizung eingegeben werden kann, muss die Heizungssteuerung keine Logik mehr haben und kann die Daten von der Ressource 1:1 übernehmen. Die Vorlauf-/Nachlaufzeiten müssten zusätzlich zu den aktuellen Vorlauf/Nachlaufzeiten möglich sein, da je nach Gebäude der Raum nur 1 Stunde vorher geöffnet wird, aber 4 Stunden vorher beheizt werden muss (Zumindest in unserem alten Gebäude ist das so).

    Der Zugriff sollte ohne Benutzername/Passwort möglich sein.
    Der Umfang der abfragbaren Daten sollte aber sehr gering sein (Sicherheit).
    Im Moment ist noch nicht klar, ob es besser ist für jeden Raum eine eigene http Abfrage zu starten, oder ob mit einem http Request alle Räume mit den Heizungszeiten hintereinander kommen können. Evtl. lässt die API ja beides zu.

    • In den Ressourcen sollten man einstellen können welche(r) Resourcen Typ für die Heizungssteuerung-Abfrage verfügbar ist.
    • Für jeden Raum, der der Heizungssteuerung zugeordnet wird sollten Standard Vorlauf-/Nachlaufzeiten einstellbar sein (Die Zeiten müssen positiv und negativ sein dürfen).
    • Für jeden Raum sollte die Bezeichnung hinterlegt werden können, die über die API an die Steuerung geliefert werden soll.

    Für jede Buchung sollte man aber die Vorlauf/Nachlaufzeiten abhängig vom Event anpassen können (Wenn sich die Senioren treffen, dann brauchen die es nun mal besonders warm).

    Evtl. ist eine separate Kalenderansicht denkbar in der man die Heizungsbelegung sieht.

    API Abfrage:

    • Raumbezeichnung / Alle Räume
    • Berücksichtigter Zeitraum in Stunden (1 Stunde bis 99 Stunden)

    API Rückmeldung

    • Raumbezeichnung
    • Startzeit / Endzeit, Startzeit / Endzeit, ...

    Später sind evtl. Abhängigkeiten denkbar:

    • Die Toiletten bzw. Warmwasser werden mit Ihren Vorlauf/Nachlaufzeiten automatisch belegt/geheizt/aktiviert, sobald einer der normalen Räume gebucht wird.

    Evtl. könnte damit auch später eine erweiterte Gebäudeautomatisation möglich sein (Rolläden öffnen, Licht einschalten, ...)

    Das ganze wäre vielleicht auch im ICAL Format denkbar, allerdings erhöht sich dadurch die größe der abgefragten Daten und der EIB-Server müsste den ICAL stärker zerlegen. Seitens des EIB-Programmierers wäre eine API schöner.

    Was habe ich als Laie nicht bedacht?
    Ist das denkbar?
    Welcher Aufwand ist damit verbunden?
    Wäre das ein zusätzliches Modul (Lizenzkosten?)?
    Oder ist das schon eine Individual-Lösung?

    Danke fürs mitdenken, bin gespannt auf die Rückmeldungen.
    Martin



  • Ein Anfang könnte vielleicht dieser rest request sein:

    https://URL_ZU_CHURCHTOOLS/?q=churchresource/ajax&func=getBookings

    weiss aber nicht, ob der parameter annehmen kann.

    http geht glaub ich default nicht, nur https. Ausser es steht noch ein apache oder ähnliches 'vor' dem churchtools server, wo man https->http umlenken kann.

    Alternativ, kann man im Ressourcenmanagement ical's abbonieren pro ressource



  • @tomzi sagte:

    https://URL_ZU_CHURCHTOOLS/?q=churchresource/ajax&func=getBookings

    Diese URL jetzt ein Vorschlag von dir und keine API die es schon gibt, oder?

    Bei HTTPS ist ja nicht automatisch eine Benutzeranmeldung erforderlich, oder? Bin da nicht so bewandert, vielleicht kannst du mich kurz aufklären. Danke



  • @MRBaum Das ist die API (zb getBookings) von Churchtools die über einen URL erreichbar ist. Und die gibt es schon. Aber ich weiss nicht wie öffentlich die ist. Was es auf jedenfall gibt, was auch über die CT Benutzeroberfläche erreichbar ist, dass man die alle Ressourcen als ICAL abbonieren kann.



  • @tomzi Also die API ist verfügbar, wenn ich sowieso in einem anderen Tab angemeldet bin. Daher wäre es aktuell für unseren Bedarf nicht hilfreich.

    Ich hoffe noch auf ein paar Unterstützungen, oder man müsste klären, wie aufwändig eine separate API dafür wäre.
    Request "Get Booking Ressource for EIB", ggfs. parameter "EIB-ID"
    Feedback: "EIB-ID", Starttime, Endtime,

    Allerdings müssten EIB-ID, Starttime und Endtime wie zuvor beschrieben zusätzlich zu den bisherigen Datenbankfeldern angelegt und verwaltet werden können.
    Die EIB-ID in den Stammdaten, Starttime und Endtime abhängig von der Buchung der Ressource.



  • Dann les dir mal dies hier durch, man braucht die Authentifizierung anscheinend nur per POST request mit der URL mitschicken.
    https://intern.churchtools.de/?q=churchwiki#WikiView/filterWikicategory_id:10/doc:API/



  • Habe in der Richtung auch mal etwas ermittelt. Der Zugriff über die API, z.B. mit einem PHP-Skript, ist zwar hochinteressant und ermöglicht einiges, aber es müsste in jedem Fall noch ein bisschen was mit den Daten angestellt werden, um am Ende die Information zu erhalten, ob zum aktuellen Zeitpunkt die Heizung für Raum X ein- oder ausgeschaltet werden soll.

    Ein Brückenglied zwischen CT und der Heizung ist also nötig. In dem Fall ist es m.E. einfacher, den iCal-Export des Raumes zu verwenden. Diesen kann man auch z.B. mit PHP einlesen und darin nach solchen Zweizeilern suchen:

    DTSTART:20160428T150000
    DTEND:20160428T170000

    Das sind dann die Belegungszeiten. Ob Du von den Zeiten (hier z.B.: T150000 = 15:00 Uhr) noch eine Zeitspanne abziehst, weil das Aufheizen ja einen zeitlichen Vorlauf benötigt, könntest Du über einen Aufrufparameter einstellbar machen. Die Logik wäre dann diese:

    • alle enthaltenen Wertepaare (Zeiträume) aus der iCal-Datei ermitteln und die Zeiten ggfs. um die Vorlaufzeit korrigieren
    • alle diese Zeiträume abklappern und prüfen, ob wir uns gerade innerhalb eines dieser Zeiträume befinden
    • davon abhängig dann ein "Heizung EIN" oder "Heizung AUS" ausgeben in einer Form, mit der das Heizungssystem direkt arbeiten kann.

    Hoffe, das hilft etwas weiter. Ein entsprechendes PHP-Skript (kann natürlich auch in einer anderen Programmiersprache sein) ist ziemlich schnell geschrieben und könnte auf Eurem normalen Webserver liegen.



  • @artus70 Falls du da mal ein fertiges skript hast, vielliecht könntest du es unter Tips & Tricks zur verfügung stellen, denn wir sind auch grad dabei für Loxon etwas ähnliches zu entwickeln, sind aber noch nicht soweit....



  • Ich verfolge mal weiter den Ansatz, die ICS Datei pro Raum abzurufen und auszulesen. Aber parallel möchte ich gerne auch folgendes klären:

    @jmrauen Hallo Jens Martin,

    kannst du abschätzen wie viel Aufwand (Manntage) folgende Erweiterung wäre.

    1. Ressourcen -> Stammdaten -> Ressourcen-Typ
      Maske und DB Erweitern um das Feld "Ressource für Gebäudesteuerung verwenden" (Boolscher Wert)

    2. Ressourcen -> Stammdaten -> Ressourcen
      Maske und DB abhängig von dem Flag aus (1) um folgende Felder erweitern:
      2.1 ID für Gebäudesteuerung
      2.2 Vorlaufzeit für Gebäudesteuerung (positiver und negativer Wert möglich, ggfs. nur Minuten einzustellen)
      2.3 Nachlaufzeit für Gebäudesteuerung (positiver und negativer Wert möglich, ggfs. nur Minuten einzustellen)
      2.4 Kommentar

    3. Ressourcen Verwaltung
      Jede Ressource vom Typ mit dem Flag Gebäudesteuerung erhält beim buchen drei Felder in der Datenbank
      3.1 Startzeit Gebäudesteuerung (Berücksichtigt jeweils den gebuchten Zeitraum + Vorlaufzeit aus (2))
      3.2 Nachlaufzeit Gebäudesteuerung (Berücksichtigt jeweils den gebuchten Zeitraum + Nachlaufzeit aus (2))
      3.3 Kommentar: ausgefüllt durch Standardwert aus dem Stammdaten

    4. Mit Hilfe der API sollte dann ein Request möglich sein - mit folgenden Parametern
      4.1 GetHomeAutomationData:ALL oder
      ----- Get HomeautomationData:ID=12345 (entspricht der HomeAutomationID)
      4.2 StartTime:20160304T000000
      4.3 EndTime:20160311T235959

    5. Das Ergebnis könnte dann so aussehen
      5.1 Nur Einträge liefern, bei denen gilt
      HomeAutomationStart > StartTime und < EndTime oder
      HomeAutomationEnd > StartTime und
      --
      5.2 Die Antwort wäre dann
      BEGIN:HOMEAUTOMATION
      UID:
      HOMEAUTOMATIONID: 12345
      HOMEAUTOMATIONSTART:
      HOMEAUTOMATIONEND:
      HOMEAUTOMATIONCOMMENT:
      END:HOMEAUTOMATION

    Da wir bei uns pro Woche im Winter ca. 20 Events mit je 1-15 Räumen programmieren müssen, ist der Aufwand im Moment dafür sehr hoch. Im Moment kommt es immer wieder zu Abweichungen zwischen Kalender und Heizungsprogrammierung. (Räume bleiben kalt, oder werden überflüssig geheizt)

    Danke für dein Feedback. Vielleicht findest sich auch jemand, der das praktisch oder monetär bei uns unterstützen würde.



  • Mir fällt noch ein, der ganze Export der Daten sollte auch abhängig sein vom Ressourcen Status. Evtl. könnte das als Parameter auch in dem Request mit übergeben werden. Es sollten in unserem all nur bestätigte Räume auch geheizt werden.



  • @MRBaum gibt es da jetzt nicht schon eine Funktionierende Lösung?

    Die Ressourcen können ja schon per Ical abgefragt werden.



  • @merhard Ja, grundsätzlich kann man die Raumbelegungen per API abfragen, aber

    • die für die Heizung notwendigen Vorlaufzeiten kann ich zur Zeit in ChurchTools nicht konfigurieren. Diese weichen von der Nutzungsvorlaufzeit ab.
    • es wäre optimal, wenn ChurchTools feststellen könnte, wenn sich zwei Buchungen überlappen und bei der Abfrage nur ein Zeitraum übermittelt wird. Überlappen sich zwei Heizungszeiträume schaltet mir nämlich die Endezeit von Periode 1 die Heizung während Periode 2 aus.

    Daher wäre ein bisschen "Heizungsintelligenz" optimal.
    So werden wir das vorübergehend in einer Schnittstelle abbilden müssen, die jedoch keiner im Fokus hat bzw. an die nur ein Programmierer ran kommt.



  • @MRBaum
    Ok, hm das scheint tatsächlich ein Spezialfall zu sein.

    Welches Heizungsystem benutzt ihr denn generell um die Steuerung zu automatisieren?
    Wir bauen nämlich gerade an und da wäre es eine ganz interessante Frage mal zu hören, wie ihr das gelöst habt.



  • @merhard Also für dich ein kurzer Ausflug in unsere Heizungs-Welt:

    Wir haben vor 15 Jahren ein ca. 50 Jahre altes Gebäude erworben, dass in allen Räumen klassische Rippenheizkörper mit normalen Thermostatköpfen hatte. Wir nutzen nun Raum-Thermostate, die per EIB/KNX vernetzt sind, das ist ein Datenprotokoll zur Gebäudesteuerung. In diesem "Netzwerk" befinden sich auch EIB Relais, jeder Relais-Kontakt steuert dann kleine Stellmotoren, die anstelle der alten Thermostatköpfen an jedem Heizkörper sitzen. Wie das Relais nun den Stellmotor ansteuert kann ich nicht genau sagen, aber es funktioniert ganz gut. Wir steuern ca. 12 Räumen mit insgesamt etwa 60 Heizkörpern. Grundsätzlich kann jedes Thermostat nun die Stellmotoren seines Raumes ansteuern, u.A. mit einer "Vor Ort" Steuerung. Im Netzwerk sitzt nun ein kleiner EIB-Server der über eine HTTP Oberfläche erreichbar ist. Hier wurde die Oberfläche für uns angepasst, damit wir es leicht bedienen können. Über eine Ablaufsteuerung können wir nun jedem Thermostat bis zu 7 Tage im Voraus sagen, ob er Tag- oder Nachtschaltung fahren soll. Diese Verwaltung ist aber nicht für jeden zugänglich und muss parallel zu ChurchTools gepflegt werden. Aktuell prüfen wir wie weit wir den iCal Kalender pro Raum so umarbeiten, dass daraus die Steuerung für die Heizung gespeist werden kann.
    Das ganze ist also recht stark auf unsere alte Gebäude-Situation zugeschnitten. Für einen Neubau sollte man prüfen, ob Alternativ zu einer klassischen Heizung eine Lüftungsanlage mit Wärme-Rückgewinnung nicht wirtschaftlicher ist. Wenn du mehr Fragen hast schreib mich einfach direkt an.



Es scheint als hättest du die Verbindung zu ChurchTools Forum verloren, bitte warte während wir versuchen sie wieder aufzubauen.