Logikengine, java powered

[tuxedo]

Bin aus den gleichen Gründen hin und hergerissen...

sqlite kommt für mich nicht in Frage. Entweder MySQL/MariaDB, oder sonst etwas an das man mit SQL und JDBC ran kommt.

Bei meinen Eltern läuft seit Jahren eine MySQL-DB. Hier werden pro Minute rund 40 Werte (double, 2 byte) von Heizung und PV-Anlage geschrieben. Die DB juckt das nicht und bei einem korrekten Index auf der Tabelle geht eine Abfrage auch recht fix.
Die Berechnung der Datenmenge ist aber nicht ganz korrekt: Du vergisst den Overhead den die DB mit ihrer DB Struktur mitbringt. Aber selbst 5GB wären bei den heutigen Speicherpreisen absolut kein Thema.

Da du DB im RAM erwähnst: Es gibt Java Embedded Datenbanken die sich auch zyklisch auf die Platte persistieren lassen:

http://www.h2database.com/html/performance.html

Hab ich in einem anderen Projekt schon erfolgreich eingesetzt. Die H2 DB ist auch Netzwerkfähig. Somit also ideal zum auslagern auf eine andere Maschine.

Für das Zusammenfassen würde ich, auch wenn's schneller ist, eher nicht auf Stored Procedures setzen. Allein schon um sich nicht abhängig von der DB zu machen. Hab da in der Vergangenheit zu schlechte Erfahrungen mit gemacht.
So allgemein würde ich sagen: Wenn's eine SQL-DB wird, dann muss die Schnittstelle der JDBC Treiber sein. D.h. man kann sich frei entscheiden welche DB es sein soll. Hauptsache es gibt einen JDBC Treiber. Und für die "Einrichtungsfaulen" wo alles out-of-the-box laufen muss, könnte man die embedded H2 DB mitliefern.

Bei meinen Eltern wird die DB nicht zusammengefasst. Aber das Stück Software das einen Zeitraum abfragt fast dann entsprechend zusammen, bzw. lässt Werte die nicht in die Abgefragte Auflösung passen unter den Tisch fallen. Das macht die Sache zwar etwas "ungenauer", aber Tests haben gezeigt dass das irrelevant ist. Hatte auch das zusammenrechnen der Werte ausprobiert: Hat aber für die damalige Kiste (auch ein embedded ARM) zu viel Leustung gefressen und war zu langsam.

[hotzen]

Also ich würde gerne was "schwergewichtiges" wie eine echte DB "nur" für logging der Daten vermeiden wollen.
Was ich mir gerade überlege, i.s.v "wenn schon, denn schon" ist einen ELK-Stack für die Daten aufzubauen: Elasticsearch, Logstash, Kibana.
Evntl. sogar AWS-hosted...

[tuxedo]

H2 ist nicht wirklich schwergewichtig. Das ist klein, aber fein und ausreichend schnell, und man müsste nix extra aufsetzen und konfigurieren, hätte aber immer noch die Möglickeit mit SQL drauf zuzugreifen. Und das macht es flexibel.
ELK sagt mir noch nix. AWS sagt mir was. Aber willst du wirklich diese Daten in die "Cloud" legen?

Zu KAD ganz allgemein kann ich weitere fortschritte vermelden:

Logic-Scripts können nun auch abhängigkeiten zu weiteren Klassen im selben Package haben (damit kann man Code in weitere Klassen auslagern und viel größere und komplexere Logiken basteln und dabei den Code übersichtlich halten) und es können 3rd-Party Libs hinzugezogen werden.
Letzteres hab ich vor allem für die Nutzung einer JSON-Library benötigt.

Als nächstes kommt wohl noch die Integration einer cron-API (cron, wie man es von Linux kennt). Damit kann man dann bequem und ohne viel Code-Overhead im Logicscript regelmäßig und/oder zeitgesteuert Aktionen ausführen.

Wenn das erledigt ist schau ich mir mal weiter die Sache mit der Datenaufzeichnung an. Leider hab ich bis jetzt noch nicht so viel Input bekommen... Mal schauen, vielleicht kommt ja noch was.

[tuxedo]

ELK mal kurz angeschaut. An sich eine feine Sache. Aber ich bin mir noch nicht sicher ob man das tatsächlich als Standard-Plugin für KAD heranziehen sollte. Das ELK Konstrukt ist sehr mächtig, und für den Standardfall in KAD ggf. etwas overkill. Vor allem da Logstash darauf ausgelegt ist, Daten von vielerlei Quellen entgegen zu nehmen. Das passt aber nicht auf die KAD philosophie, wo quasi der gemeinsame Nenner der Bus ist.

Aber es spricht auch nix gegen ein separates ELK-Plugin für KAD. Nur glaube ich halt nicht dass der Standardnutzer das brauchen wird.

Meine Anforderungen wären:

* KISS-Prinzip
* Minimalste Konfiguration: Man gibt nur an welche GA man archivieren möchte
* Intern abfragbar mit einer recht einfachen Query

Offene Fragen:

Wo ich mir noch unsicher bin, ist die Auflösung der Daten. Manche GAs kann man nicht über den Bus abfragen, man muss warten bis sie vom jeweiligen Gerät gesendet werden. Andere hingegen sind pro-aktiv abfragbar.
In welchem Intervall frägt man die Daten ab? Hat man nur z.B. 5 GAs, ist das recht wenig Buslast wenn man 1x pro Minute frägt. Hat man aber 50, ist das schon eine andere Hausnummer. Macht man's individuell, so ist das ganze wieder aufwendiger zu konfigurieren.

Aktuell würde ich zu "individuell konfigurierbar" tendieren, kombiniert mit dem bereits existierenden Cache tendieren: Sind die Daten im Cache nicht älter als X, werden die gecachten Daten genommen. Ansonsten wird erneut abgefragt.

[Steph]

Hey Alex,
super Arbeit bis hierher und schön, dass du dran bleibst!

Verstehe ich es richtig, dass der Cache damit das minimale Intervall vorgibt? Bei einem Bewegungsmelder möchte ich die Erkennung z.B. auf die Sekunde genau aufzeichnen, bei der Raumtemperatur reicht mir ein Wert alle 5 Minuten. Vielleicht ist eine Möglichkeit, einen Wert bei einer Änderung des Werts direkt mit Zeitstempel in der DB zu speichern?

[tuxedo]

Verstehe ich es richtig, dass der Cache damit das minimale Intervall vorgibt?

Für das CV-Backend und ggf. die Logiken (wenn dort pro-aktiv abgefragt statt auf ein Event gewartet wird): Ja.
Für die Archivierung: Nein.

Ich werden den KNX Zugriff mit dem Cache so bauen, dass man ein maximales Alter der angefragten Daten mit angeben kann.

Vielleicht ist eine Möglichkeit, einen Wert bei einer Änderung des Werts direkt mit Zeitstempel in der DB zu speichern?

Das ist ein guter Punkt:

Damit wären es drei Varianten für das Archiv:

1) Abfragen mit einem Alter >0 (ergibt ggf. einen gecachten Wert)
2) Abfrage mit einem Alter = 0 (ergibt einen top-aktuellen Wert, direkt vom Bus, der dann auch den Cache gleich aktualisiert)
3) Keine Abfrage, sondern Event-basiert

[l0wside]

Hallo Alex,

welche Daten sind das, die weder zyklisch noch bei Änderung gesendet werden, aber trotzdem ins Log sollen? Mir ist der Anwendungsfall für aktive Abfrage (aka Pollen) nicht so recht klar.
Bei den gängigen Sensoren (Temperatur, Helligkeit, ...) wird der Wert doch zyklisch gesendet. Meine Heizungsaktoren melden sich selbst, wenn sie das Tastverhältnis der PWM ändern. Habe ich etwas übersehen? Oder willst du zyklisch zum immer gleichen Zeitpunkt alle abfragen?

Max

[tuxedo]

welche Daten sind das, die weder zyklisch noch bei Änderung gesendet werden, aber trotzdem ins Log sollen?

Der Anwendungsfall wird eher eine Seltenheit sein ;-) Aber die Berücksichtigung in der Implementierung ist absolut 0 Mehraufwand.
Auf der anderen Seite: Der Cache lauscht auch auf GROUPWRITE-Telegramme. Somit sind die Werte so oder so im Cache, sobald sie über den Bus gingen und am IP-Gateway zu sehen waren.

Macht wohl tatsächlich keinen Sinn ...
Allerdings: Wenn sich nur verdammt selten was ändert:

Angenommen es gab vor 2 Wochen eine Änderung an einer GA, die auch ins Archiv gelangt ist. Seit 2 Wochen hat diese GA dann nichts mehr von sich gegeben. Also ist auch nix mehr im Archiv angekommen. Und in der Visu will ich mir die letzte Woche anzeigen. Dann sehe ich von dieser GA gar nichts, weil nichts im Archiv vorhanden ist.
Mit einer regelmäßigen Abfrage (konfigurierbar, z.B. 1x am Tag) wäre der Verlauf (nämlich dass sich nichts geändert hat und der Wert meinetwegen seit 10 Wochen bei "15" steht) auch sichtbar. Und man wäre sich sicher: Wenn es einen Eintrag im Archiv gibt, dann war dieser Wert zu diesem Zeitpunkt auch tatsächlich präsent.
Ansonsten müsste ich ja für den Abfragezeitraum, in dem nichts im Archiv steht (weil sich nichts geändert hat) annehmen, dass der Wert von vor 2 Wochen noch aktuell ist, ohne aber genau zu wissen ob das der Fall ist (vielleicht hat sich der Wert ja geändert und wegen eines Reboots hat das das Archiv nicht mitbekommen?).

Ergo bräuchte man eine Kombination aus Event-Basiert und einer regelmäßigen Abfrage um auf Nummer sicher zu gehen.

Weiß jemand wie z.B. der HS das handhabt?

Oder willst du zyklisch zum immer gleichen Zeitpunkt alle abfragen?

Nein, um himmels willen. Das würde ja den Bus fluten...Ich will das nicht vorgeben. Aber wenn einer sein System so konfiguriert... von mir aus.

[tuxedo]

Die cron-Lösung für die Logik ging schneller als gedacht. In der Logik kann man jede eigene Methode mit einer cron-annotation annotieren:

    @Scheduled(cron = "1 * * * * *")
    public void ping() {
        log.info("### PONG ###");
    }

Allerdings ist die Library dahinter etwas pingelig was den cron-String angeht. Ein Leerzeichen zu viel und das Ding scheitert.
Intern wird per default alle 5sek geprüft ob die Methode aufgerufen werden muss. Finde ich noch nicht so schön gelöst, aber gut. "There's room for improvement".
Die Lib ist nicht groß und steht unter der MIT License. Mal sehen, vielleicht adoptiere ich das bisschen Code einfach und passe es an.

[tuxedo]

So, Cron-Thema gelöst: Hab eine andere Lib gefunden die besser arbeitet und ähnlich klein ist. Die Annotation-Idee hab ich übernommen. Finde das recht praktisch.
Der kleinste Cron-Intervall ist allerdings 1min. Wer öfters als 1x pro Minute eine Aktion ausführen will, der muss den klassischen Timer in Java nutzen.

Die Cron-Annotation ist hauptsächlich für Steuerungsaufgaben in der Logik gemacht (z.B. um eine bestimmte Uhrzeit an Werktagen XYZ auszulösen).

Das heisst jetzt: Nächster Schritt ARCHIV ...

P.S. Aktuell gibt's keine stabile/lauffähige Version zum runterladen. Ich muss erst mal die einzelnen Versionabhängigkeiten gerade ziehen, bei meinen eigenen Paketen das "-SNAPSHOT" aus der Version nehmen und mein Maven-Repo wieder ans laufen kriegen (das frisst zur Zeit so viel RAM auf dem Server dass dieser nur noch swappen würde wenn das läuft... das kommt davon wenn man beim Server zu geizig mit dem RAM war...).

[hotzen]

Sauber, schöne Fortschritte, vor allem ELK Support rockt!

[tuxedo]

vor allem ELK Support rockt!

Wenn du das Plugin schreibst, dann gibt's Support dafür. Aus diesem Grund besteht KAD ja aus Plugins.
Wie ich schon schrieb: Ich glaube Logstash ist mit Kanonen auf Spatzen geschossen bei der bisherigen KAD Philosophie.
Wenn du die allerdings aufweichen willst und noch Daten aus anderen Quellen heranziehen/loggen willst (die nicht auf den Bus sollen/können/müssen/...), dann macht das ggf. wirklich Sinn.

[tuxedo]

Was mir aber eben noch eingefallen ist:

Bevor ich Version 1.0.0 einfriere, sollte noch ein Feature in die Logik-Engine rein:
Senden eines Response auf einen Read-Request... Bisher landen nur WRITE-Telegramme in der Logik, wenn sich die Logik für die jeweilige GA dafür registriert hat. READ und RESPONSE fehlen noch.

Damit kann dann eine Logik quasi als KNX-Software-Device agieren.
Damit ließen sich Gateways zu anderen Systemen (OneWire, EnOcean, ...) basteln.

Mal sehen wie ich das am einfachsten einbaue.

[tuxedo]

Arbeite bereits an besagtem Feature. Nebenbei gibt's aber noch etwas anderes erfreuliches zu berichten

Man benötigt keinen IP-Router und kein IP-Interface mehr. Es reicht prinzipiell das hier:

2015-11-13.jpg

Ein Siemens BCu für keine 30EUR und ein USB-RS232-Adapter für keine 3EUR aus der Bucht. Ein bisschen Verbindungsdraht zwischen den beiden, und schon kann's losgehen.
Okay, wer's nach Vorschrift/Norm richtig machen will setzt noch eine galvanische Trennung dazwischen, sind dann nochmal wenige Euro mehr.

Das ganze ist noch experimentell, da noch nicht ausgiebig getestet (erste Tests sehen aber äußerst gut aus) und der Code seitens Calimero dafür ist noch nicht in einem Stable-Release enthalten. Aber bisher sieht das ganze ganz gut aus.

Unter umständen kann ich das ganze noch weiter treiben und daraus softwaremäßig einen KNX-IP-Router machen. Das wär doch mal was.
Gut, geht mit knxd/eibd ja auch. ABER meine Variante würde auch unter Windows und ggf. sogar Mac laufen.
Mal schauen wie's hier weiter geht.

[hotzen]

Bewundere ja deinen Entwicklungsdruck +1