SHC Application Framework (SHC 3.0)

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    Hallo Forum-Mitglieder,

    es ist ja ziemlich ruhig geworden hier im Forum geworden. Neue Beiträge sind kaum zu verzeichnen.
    Auch werden sicherlich ziemlich viele ihr SHC aufgegeben haben und auf ein moderneres System umgestiegen sein.

    Daher stellt sich die Frage, ob ich diese Forum überhaupt noch aufrecht erhalten muss. Zumal auch ich selber nicht
    mehr so häufig reinschaue.
    Ich habe zu diesem Thema auch einen Thread unter News eingestellt. Bitte stimmt dort ab, wenn ihr mal online seid.

    Gruß Dieter

    • SHC Application Framework (SHC 3.0)

      Ich hatte schon mehrfach überlegt das komplette SHC noch einmal neu in Java auf zu bauen. Diese Idee aber aufgrund des Aufwandes erst einmal wieder verworfen.
      Nachdem ich nun angefangen habe die neuen Funktionen für Version 2.4 zu programmieren. Musste ich immer wieder feststellen das, dass aktuelle Konzept zu schwerfällig geworden ist. Also vor allem was Erweiterungen angeht, aber auch was die Performance angeht.
      Aktueller Stand ist wie die meisten ja wissen das der Scheduler recht instabil wird sobald man ein paar mehr Funktionen einstellt. Nach langem überlegen und einigen Tests musste ich nun auch zu der Erkenntnis kommen das der Java Scheduler da auch nicht viel daran ändern kann. Da das Konzept darunter schon nicht perfekt passt.

      Diese und einige weitere Erkenntnisse haben mich nun doch dazu bewegt noch einmal eine neue Basis auf zu bauen, diese möchte ich euch jetzt einmal kurz Vorstellen.
      Das ganze Projekt wird weitestgehend in Java geschrieben sein, das macht es auch für mich einfacher. Allerdings werden eigene Erweiterungen schwieriger.
      Voraussetzung ist dann Java 8.
      Das ganze ist dann so aufgeteilt das es einen Server gibt der eine JSON Schnittstelle bereitstellt, aber selbst keine Grafikoberfläche. Über diese JSON Schnittstelle wird es mehrere Clients geben welche die Anzeige auf bestimmten Systemen übernehmen.

      Das komplette Projekt SHC wird in mehrere eigenständige Module zerlegt:

      SHC_Core:

      Der Core bildet die Basisdaten des SHC ab (z.B.: Benutzer, schaltbare Elemente, Sensoren, ...) enthält aber keine Geschäftslogik.

      SHC_Application_Server:
      Der Application Server bildet das neue Herz. Er wird sich um die Abarbeitung der Aufgaben kümmern (die Funktionen des jetzigen Schedulers). Zudem wird er die komplette Datenhaltung verwalten. Im Gegensatz zum jetzigen Zustand das für jede Aufgabe alle Daten aus der Datenbank geholt, verarbeitet und geschrieben werden, wird der Server alle Daten selbst verwalten und in der Datenbank nur zyklisch ein Abbild ablegen. Dieses Abbild dient dann nur dazu das nach einem Neustart die Daten wieder geladen werden können. Das hat zum einen den Vorteil das sehr viel weniger Datenbankoperationen durchgeführt werden müssen. Zum anderen auch das die Daten an einem Ort immer aktuell sind.
      Der Application Server nutzt die Daten des Core als Basis und Stellt eine umfangreiche Json Schnittstelle über einen eingebetteten HTTP-Server zur Verfügung.
      (Der Application Server besitzt keine eigene Grafikoberfläche und wird über die Kommandozeile bedient)

      SHC_Switch_Server:
      Übernimmt die Funktionen des jetzigen Switch Servers. Das Dezentrale konzept des SHC bleibt also erhalten.

      [u]SHC_Sensor_Transmitter:
      [/u]Übernimmt die Funktionen des jetzigen Sensor Transmitters. Die HTTP Schnittstelle zum Empfangen der Sensordaten bleibt gleich, die URL wird sich aber ein wenig ändern.

      SHC_CLI_Client:
      Der CLI Client ermöglicht es die Funktionen des SHC über die Kommandozeile zu schalten.

      SHC_Desktop Client:
      Der Desktop Client bildet die neue Haupoberfläche, es können also alle Schaltfunktionen und Verwaltungsfunktionen genutzt werden. Für die Grafikoberfläche ist geplant JavaFX 8 zu verwenden, dafür wird Java 8 mit mindestens Update 40 benötigt. Das bedeutet aber auch das diese Oberfläche nicht auf dem Raspberry Pi selbst läuft (zumindest vorerst), da soweit ich weiß Oracle Java 8 Update 40 noch nicht für den RPi erschienen ist.

      SHC_Android_Client:
      Der Android Client wird wie der Desktop Client vollen Funktionsumfang erhalten und von der Programmierung etwas effizienter aufgebaut sein als die aktuelle App.

      SHC_Web_Client:
      Der Web Client wird die Oberfläche zum schalten von SHC Funktionen für den Browser als Desktop und Mobile Webseite bereitstellen. Der Web Client wird vorerst keine Verwaltungsfunktionen erhalten.

      Release und Funktionsumfang:

      Die Einzelnen Module (ausgenommen dem SHC_Core) werden dann mit jedem Release als einzelne ausführbare Jar Dateien ausgeliefert, was auch den Release stabiler machen sollte. Es wird also nicht mehr mit "git clone" gearbeitet was ohnehin nicht so funktioniert hat wie ich mir das vorgestellt hatte.
      Geplant ist der Release mit dem Funktionsumfang wie ich ihn für Version 2.4 vorgesehen hatte.

      -> https://github.com/agent4788/SHC_Application_Framework

      Bei Fragen, Anregungen, Kritik usw. immer raus damit.
    • RE: SHC Application Framework (SHC 3.0)

      Für alle neugierigen, schon einmal ein paar erste Infos. Wie ich schon erwähnt hatte bin ich aktuell dabei das neue Datenmodell zu erstellen. Dabei habe ich jetzt auch gleich einige neue Abläufe und Funktionen geschaffen. Diese möchte ich jetzt kurz erklären.

      Benutzer zu Hause:
      Die Benutzer zu Hause sind jetzt kein Separates Modul mehr sondern einfach lesbare Elemente die wie jedes Andere Element einem Raum oder einer Box hinzugefügt werden können. Die Box wie man sie von der Weboberfläche kennt entfällt komplett.

      Raum Elemente:
      Jedes Element (Sensor, schalt oder lesbares Element) ist jetzt ein Raumelement und hat die selben Grundfunktionen, wie zum Beispiel in mehreren Räumen dargestellt werden zu können.
      In der Benutzeroberfläche wird sich das weniger bemerkbar machen, bei der Programmierung erleichtert das aber erheblich.

      schaltbare Elemente:
      Alle Schaltbaren Elemente besitzen jetzt automatisch einen Betriebsstundenzähler und Optional einen Energiezähler. Für den Energiezähler muss man beim erstellen eines solchen Elementes den Verbrauch angeben, die Energie wird dann Rechnerisch durch die Betriebsstunden ermittelt.
      Die Button Texte können jetzt als Freitext verwendet werden.

      neue Elemente / neue Funktionen in den Elementen:
      Es gibt auch einige neue Element.
      • Taster (Tastfunktion -> ist eine Gruppenelement welches nur einen Button besitzt und automatisch nach einer Einstellbaren Zeit von 100 - 1000ms wieder ausschaltet) [vom Prinzip her ein Spezialisierter Countdown]
      • Input und Output können jetzt Invertiert werden d.h. 0 und 1 Signal umgekehrt
      • RemotReboot/RemoteShutdown -> darüber können Schaltserver neu gestartet oder Herunter gefahren werden (im Standard Shaltserver wird das den RPi neu Starten oder Herunterfahren)
      • RemoteScript -> Skripte werden jetzt im Schaltserver ausgeführt d.h. es sind jetzt auch Scripte auf anderen Raspberry Pi Ausführbar
      • UserAtHome -> lesbares Element Benutzer zu Hause
      • VirtualSocket -> Virtueller Schalter zum händischen vorwählen von Bedingungen
      • zusätzlich zu den neuen Sensoren und Virtuellen Sensoren die für Version 2.4 angekündigt waren kommt jetzt noch ein Stromzähler Sensor

    • RE: SHC Application Framework (SHC 3.0)

      Hallo agent,

      könntest Du die Tastfunktion vielleicht einstellbar zwischen 100 und 3000 ms machen. Ich denke da an einen Taster zum Türöffner. Da wäre 1 sek. etwas kurz, bis man bemerkt, das der Türöffner schnurrt und man dagegen drückt.

      Bezüglich des Stromzählers, wird da dann universal ein Puls an einer GPIO gezählt und verarbeitet?

      Damit wäre es möglich So Schnittstellen von Strom Gas Wasserzähler zu erfassen, beziehungsweise Pulse von selbstentworfenen optischen Abnehmern oder auch nur Kundenzählung durch eine Lichtschranke an der Tür, wer so etwas braucht.

      Da gibt es bestimmte jede Menge Einsatzgebiete, wo etwas erfasst und gezählt werden soll.
      SHC Master B2+ WLAN sowie 1 Slave B2+, 2 Slave B+ und 2 Slave Raspi B. 5x Pi Cam; Imac mit OSX El Capitan; Iphone 6 plus; Ipad mini; Lenovo Android Tablet.
    • RE: SHC Application Framework (SHC 3.0)

      Strom, Gas und Wasserzähler sind Addierer, also wenn du 3Wh per push übergibst werden die 3Wh zum Sensorwert addiert. Die Hardware Umsetzing bleibt dem jeweiligen Transmitter überlassen.

      Die könnte dann so aussehen das pro GPIO Impuls 5Wh an den Application Server gemeldet werden und der das dann Summiert.

      Gesendet von meinem SM-T805 mit Tapatalk
    • RE: SHC Application Framework (SHC 3.0)

      Ich habe jetzt auf GitHub schon einmal die Projektvorstellung erstellt -> http://agent4788.github.io/SHC_Application_Framework/
      Zudem gibt es noch einen weiteren Sensor, der einen Akku Ladezustand anzeigt. Der ist für die Android App vorgeshen. Die dann den Akkustand ans SHC senden kann. Der Sensor kann auch über die Sensorschnittstelle beeinflusst werden.
    • Hallo agent,

      werden beim SHC3 die Schnittstellen der Schaltserver und das empfangen der Sensordaten gleich bleiben?

      Also ich meine werden, Arduinos mit den jetzigen Sketche als Schaltserver oder Sensortransmitter, bzw. Slave's mit SHC 2.2 7 auch unter SHC 3 weiter funktionieren, oder ändert sich da die Kommunikation?

      Prinzipiell verspreche ich mir stabilere und einfachere Systeme durch Austausch von Slave Raspi's gegen Arduinos oder ESP's, da wenn der Sketch einmal funktioniert die Dinger einfach rennen. Auch nach einem Stromausfall gehts einfach weiter. Keine SD Karte, die Probleme machen kann.
      SHC Master B2+ WLAN sowie 1 Slave B2+, 2 Slave B+ und 2 Slave Raspi B. 5x Pi Cam; Imac mit OSX El Capitan; Iphone 6 plus; Ipad mini; Lenovo Android Tablet.
    • agent47 wrote:

      Taster (Tastfunktion -> ist eine Gruppenelement welches nur einen Button besitzt und automatisch nach einer Einstellbaren Zeit von 100 - 1000ms wieder ausschaltet) [vom Prinzip her ein Spezialisierter Countdown]
      Ich würde das tatsächlich auch Timer oder Countdown nennen. Und einen Taster so machen, das er so läuft wie in der IOS-App, nämlich solange, wie der Benutzer den Button hält. Ich denke da auch an Türöffner, aber auch an Jalousienschalter, wo ich ja bei konfigurieren noch nicht weiß wie lange ich den jeweils drücken möchte.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.