KONNEKTING Enocean-Gateway

[jentz1986]

Ja, OK. Also... Ist ja schon was peinlich. Läuft. Nach heute 5 min Arbeiten. Was hab ich gemacht:

1. EnOcean Hardware zusammengebaut
2. Arduino Umgebung ertüchtigt mit SAMD Hardware zusammenzuspielen, also die Zero Board Definition runtergeladen (OK, war sie schon vorher, nur der Vollständigkeit halber)
3. Den EnOcean Gateway per USB mit dem ArduinoEntwicklungs-PC verbunden, den Sketch aufgespielt. (war wahrscheinlich unnötig, weil war schon drauf)
4. Auf meinem KNX Rechner die Konnekting Suite aufgerufen
5. Die kconfig.xml geladen und mit einer PA parametriert
6. Die Taster-ID von der Rückseite des Tasters abgelesen, in das Feld Taster_1 Sender ID eingetragen
7. In der ETS meine Fake GAs rausgesucht (hatte mir 15/0/...) für Konnekting reserviert.
8. Bei den Kommunikationsobjekten in der Konnekting Suite beim Gateway-Gerät die 15/0/0 .. 15/0/5 eingetragen
9. Den Roten Knopf "Alles Programmieren" in der Konnekting Suite gedrückt
10. Den Programmierknopf am EnOcean Gateway gedrückt
11. Abgewartet, bis mein Arduino-PC das Abkoppeln des Devices gemeldet hat, direkt danach das ankoppeln
12. Dann den Konnekting Bus-Monitor gestartet
13. Enocean Taster gedrückt NICHTS
14. gewartet, achso im Debug-Out des Arduino stand noch nicht "FINISH Setup", ah jetzt ja
15. Im Konnekting Bus-Monitor Telegramme auf die 15/0/... Adressen gesehen, je nach dem wo ich gedrückt hab
16. Proof of Concept bestanden

So einfach hatte ich mir das nicht vorgestellt.
Zeit in die Entwicklung einzusteigen. Mit der Belegung der logischen Funktionalität bin ich noch nicht einverstanden. Das werde ich in der nächsten Zeit angehen, kann aber was dauern.

EDIT: Gut, dann mal her mit den Wiki Zugangsdaten, dann schubse ich das nachher noch da rein, alles andere auch. Masifi ich bin begeistert! Vielen Dank!

[Masifi]

Läuft. Nach heute 5 min Arbeiten

:-)

So einfach hatte ich mir das nicht vorgestellt.

:-)

Masifi ich bin begeistert! Vielen Dank!

:-)

Freut mich so positives Feedback zu bekommen, vielleicht merkt man hier wie "toll" und "einfach" es mit der Konnekting Suite läuft "keine Werbung in eigener Sache" :-)

dann mal her mit den Wiki Zugangsdaten

Dazu musst du als "KONNEKTING Manufacturer" registriert sein.

[Masifi]

Nächster großer Erfolg, das Status abfragen funktioniert jetzt auch :-)

Jetzt wird es Zeit, dass der Code noch strukturiert wird damit man ihn besser versteht und wollala man hat echt ein cooles KNX-EnOcean-Gateway !!!

[jentz1986]

Hmm, also jetzt bin ich doch über ein paar Sachen gestolpert. Erstmal wollte ich die XML für die Suite aufbereiten und die Taster smarter machen. Der zusätzliche Taster wäre der für mich größte Benefit. Daher habe ich mir gar nicht über Enocean Aktoren Gedanken gemacht.

Ich mir mal die Möglichkeiten der KNX Taster auf dem Markt angeschaut und die entsprechenden Funktionen als CommObj angelegt. Das sind pro Tasterpunkt 9 Objekte und eines zur Reserve, also eigentlich 10. Macht beim Eltako FT55 mit zwei Wippen schon 54 Objekte für einen Schalter (6 Druckpunkte x 9 Objekte). Die Anzahl der Parameter kann ich noch gar nicht absehen. Fazit: Das wird eng mit 256 Objekten in Konnekting, wenn man mehr als 5 Taster hat. Es sind bei jedem Schaltpunkt nur 2-3 Objekte maximal aktiv, daher mache ich mir keine Gedanken über die Last der GA-Tabelle auf dem µC.

Es gibt noch ein paar andere Macken in der Suite, für die ich jetzt erstmal Issues ergänzt, bzw. angelegt habe. Meine Java-Zeit ist jetzt 11 Jahre her, danach hatte ich nur noch .Net gemacht und jetzt ein Jahr lang nix mehr im Bereich GUI Entwicklung. Trau mich daher nich so richtig die Suite zu forken und zu fixen.

Noch eine Konnekting-Konzeptsache: Klasse Hardware von Masifi, aber die Software wäre dann jetzt von mir. (Alles offen, klar) Konnekting sieht zur Zeit nur vor, dass es einen Manufacturer gibt. Wie wäre denn dafür jetzt die Bezeichnungsweise damit alle Eitelkeiten erfüllt und Schuldigkeiten eingetragen sind?
Weiters: Die Hardware kann ja auch auf GitHub gepostet werden, dazu die passende Library mit der entsprechenden *.kdevice.xml. Sollte es dafür nicht auch eine Art Repository geben? Egal in welcher Qualität Dinge vorhanden sind, wenn sie erstmal da sind kann man sie ja verbessern.

Ich habe mich jetzt auch als Manufacturer registriert, aber noch keine Bestätigung bekommen. Sobald das kommt, kann es losgehen.

Achso:
Wie wäre es, wenn man die einzelnen EnOcean-Profile innerhalb der Konnekting-EnOcean-GW-Bibliothek in eigene .h-Dateien auslagert und damit erstmal die Funktionalität der Sensoren und Aktoren von der Konnekting-Verbindung trennt. Damit wird das Ganze wartbarer.

Wie sieht es denn mit potentiellen Mitstreitern im Konnekting/EnOcean Umfeld aus?
trollmar, trexter, ivande, SirUli gibt es etwas, womit ihr euch einbringen könnt, z.B. Tester, Anforderungsgeber, Dokumentatoren. Habt ihr schon Masifis Gateway?

[Masifi]

Der zusätzliche Taster wäre der für mich größte Benefit

Was für einen zusätzlichen Taster denn !? man kann aktuell 10 Taster einlesen und 10 Taster über das Gateway ausgeben

Ich mir mal die Möglichkeiten der KNX Taster auf dem Markt angeschaut und die entsprechenden Funktionen als CommObj angelegt. Das sind pro Tasterpunkt 9 Objekte und eines zur Reserve, also eigentlich 10. Macht beim Eltako FT55 mit zwei Wippen schon 54 Objekte für einen Schalter (6 Druckpunkte x 9 Objekte).

wie kommst du auf 9 Objekte pro Tastendruck !?

Noch eine Konnekting-Konzeptsache: Klasse Hardware von Masifi, aber die Software wäre dann jetzt von mir. (Alles offen, klar) Konnekting sieht zur Zeit nur vor, dass es einen Manufacturer gibt. Wie wäre denn dafür jetzt die Bezeichnungsweise damit alle Eitelkeiten erfüllt und Schuldigkeiten eingetragen sind?

Warum soll es bei KONNEKTING nur einen Manufacturer geben !? Ja man muss einen eintragen, aber jeder kann ihn ändern. Gedacht ist dieser ja nur, damit man es später einfacher hat es nachzuvollziehen wer was gemacht hat und vor allem das später die XML Datei zum Programm-Code passt. Deinen letzten Satz hier habe ich jetzt 10mal gelesen und kann ihn immer noch nicht entschlüsseln :-)

Weiters: Die Hardware kann ja auch auf GitHub gepostet werden, dazu die passende Library mit der entsprechenden *.kdevice.xml. Sollte es dafür nicht auch eine Art Repository geben? Egal in welcher Qualität Dinge vorhanden sind, wenn sie erstmal da sind kann man sie ja verbessern.

Ja das wird und kann es alles geben, aber du wirst schnell merken das wenn man noch einen normalen Job parallel hat, alles ziemlich Zeit intensiv wird. Online stelle ich es, wenn ich denke das es passt. Aber falls sich jemand an der Arbeit beteiligen will, dann darf er das gerne tun. Aber du merkst schon selber, das du alles dann doch anders machen würdest und ob das dann der Allgemeinheit gut tut wenn es 10 unterschiedliche Varianten gibt, glaube ich auch nicht.

Achso:
Wie wäre es, wenn man die einzelnen EnOcean-Profile innerhalb der Konnekting-EnOcean-GW-Bibliothek in eigene .h-Dateien auslagert und damit erstmal die Funktionalität der Sensoren und Aktoren von der Konnekting-Verbindung trennt. Damit wird das Ganze wartbarer.

Das soll ja schon passieren, SirUli hat sich ja bereiterklärt dort etwas zu verbessern und wenn das steht, dann kann man weiterschauen. Ich vertrete die Meinung "Simple is the best" daher alles mit seiner Zeit ohne das man jetzt von heute auf Morgen alle >100 EnOcean Profile hier integriert haben muss.

jentz1986 vielleicht kannst du es hier ja etwas genauer beschreiben was du dir so vorstellst, gerne auch als PN wie du möchtest.

[jentz1986]

Was für einen zusätzlichen Taster denn

Meine KNX Anlage um einen (bzw. mehrere) EnOcean Taster erweitern. Dazu muss der aber das können, was meine anderen Taster auch können. Einen Dummen An/Aus brauche ich nicht, weil ich kein Logikmodul habe und solche Funktionen, wie Jalousie, Dimmen, Szene eigentlich rein auf KNX halten möchte, ohne dass Logikengine hinter Visu o.ä. zum Einsatz kommen müssen.

wie kommst du auf 9 Objekte pro Tastendruck !?

So, und dann entsprechend mit der passenden Parametrierlogik dazu, das ist aber zuviel um es hier zu posten, gerade bin ich auf 630 Zeilen XML für EINEN FT55, und die Einzeltasterfunktion (sprich sechs einzelne Taster (A-oben, B-oben, A-unten, B-unten, AB-oben, AB-unten) ist damit noch nicht mal komplett parametrierbar:

            <CommObject Id="0" IdName="T1B1_SD">
                <Name>Taster 1 / Button 1 / Schalten/Dimmen</Name>
                <Function>Schalten</Function>
                <DataPointType>1.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="1" IdName="T1B1_ZF">
                <Name>Taster 1 / Button 1 / Zwangsführung</Name>
                <Function>Schalten</Function>
                <DataPointType>2.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="2" IdName="T1B1_JAL">
                <Name>Taster 1 / Button 1 / Jalousie</Name>
                <Function>Auf / Ab</Function>
                <DataPointType>1.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="3" IdName="T1B1_W">
                <Name>Taster 1 / Button 1 / Wert senden</Name>
                <Function>Wert</Function>
                <DataPointType>5.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="4" IdName="T1B1_SC">
                <Name>Taster 1 / Button 1 / Szene</Name>
                <Function>Szene Steuern</Function>
                <DataPointType>18.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="5" IdName="T1B1_JAK">
                <Name>Taster 1 / Button 1 / Lamellen</Name>
                <Function>Auf / Zu</Function>
                <DataPointType>1.009</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="6" IdName="T1B1_DIM">
                <Name>Taster 1 / Button 1 / Dimmen</Name>
                <Function>Auf / Zu</Function>
                <DataPointType>3.007</DataPointType>
                <Flags>52</Flags>
            </CommObject>
            <CommObject Id="7" IdName="T1B1_ISU">
                <Name>Taster 1 / Button 1 / Wert für Umschaltung</Name>
                <Function>Ein / Aus</Function>
                <DataPointType>1.001</DataPointType>
                <Flags>42</Flags>
            </CommObject>
            <CommObject Id="8" IdName="T1B1_IRJ">
                <Name>Taster 1 / Button 1 / Wert für Richtungswechsel</Name>
                <Function>Richtungsumkehr</Function>
                <DataPointType>1.001</DataPointType>
                <Flags>42</Flags>
            </CommObject>
            <CommObject Id="9" IdName="T1B1_UU">
                <Name>Taster 1 / Button 1 / Unused</Name>
                <Function>N/A</Function>
                <DataPointType>1.001</DataPointType>
                <Flags>0</Flags>
            </CommObject>

Deinen letzten Satz hier habe ich jetzt 10mal gelesen und kann ihn immer noch nicht entschlüsseln :-)

Gemeint war: Es ist Dein Hardwareentwurf und Dein erster Software-Entwurf. Das sollte berücksichtigt werden (im Sinne der Namensnennung). Wenn ich jetzt aber veröffentliche, dann fände ich es aber auch schön, dass ich mit auftauche (Meine Eitelkeit ;-) )... Und, Wenn ich es veröffentliche, dann soll es auch etwas Allgemein benutzbares werden, sonst kann ich mich auch ohne Suite und co in meinen Keller setzen und den Taster so programmieren, wie ich es brauche und keinen Pups mehr.

ob das dann der Allgemeinheit gut tut wenn es 10 unterschiedliche Varianten gibt, glaube ich auch nicht.

Daher meine ich, dass man lieber gemeinsam loslegt und sich ergänzt, als darauf zu warten, dass einer fertig wird.

von heute auf Morgen alle >100 EnOcean Profile hier integriert haben muss.

Das nicht, aber ich denke es wäre sinnvoll sich zu überlegen, wie man mit drei Profilen umgeht, und zwar so, dass es auch für 5 oder 9 noch passt. Danach wird es ohnehin wahrscheinlich mehr als exotisch.

Simple is the best

Ich tendiere an der einen oder anderen Ecke zum Over-Engineering und muss mich bremsen. (Reaktion des Lesers: Ach, Echt?) Dafür hilft eben auch Diskussion am Objekt, ohne dass das direkt Grundsatzdiskussion werden muss. Ich bin nicht empfindlich und neige zu drastischen Aussagen um klar zu machen, was ich meine. Wichtig ist aber immer: Wer meinen Respekt verliert, mit dem diskutiere ich nicht. Die mit denen ich streite, haben den Respekt, dass sie meine Meinung erhalten und auch jederzeit ein Bier, und eine Auszeit von mir, wenn gewünscht. ;-)

[Masifi]

Was mein Wunsch wäre, dass man jetzt einen gemeinsamen SW-Stand aufsetzt. Dieser soll alle wichtigen Funktion (senden / empfangen / Base-ID abfragen) implementiert haben. Die Struktur sollte passen, so das man sich einfach damit zurecht findet, was momentan noch das Thema ist, warum des Code noch nicht allgemein veröffentlicht wurde. Wenn das abgeschlossen ist, dann kann man ihn als Basis nutzen wenn man weiter daran entwickeln möchte.
Es steckt viel Arbeit von mir in der HW und der SW, aber ich werde mich nicht an die SW klammern, jeder darf nach den Lizenz-vorgaben daran weiterarbeiten. Es sollte nachher halt nicht 10 grundverschiedene Ansätze geben, sondern wenn möglich einen, der sauber im WIKI dokumentiert ist und einfach zu händeln.

[SirUli]

Hi zusammen,

bei mir kam in den letzten Wochen alles etwas anders als ich dachte. Erst "durfte" ich geschäftlich reisen und nun drehen im Bau alle Handwerker hohl und ich komme nicht an den Rechner Masifi Sorry auch dafür - daher die etwas verzögerten Meldungen und ein unklarer Stand der Dinge.

Insofern hierzu:

SirUli hat sich ja bereiterklärt dort etwas zu verbessern und wenn das steht, dann kann man weiterschauen

Ich habe bisher ENOCEAN verstanden (sorry, fand ich nicht intuitiv erstmal) und dann ein paar Prototypen gebaut. Da ich die Hardware momentan noch nicht nutze, war das natürlich erstmal auf der Basis von ein paar Dummys.

Meine erste Idee war, dass man in der KONNEKTING Suite die Profile konfigurieren kann und sozusagen ein vollmodulares Gateway hat - dafür ists aber wohl nicht gedacht und wird zu kompliziert. Das habe ich also verworfen.

Insofern bin ich eher beim Ansatz, dass sich jeder den ENOCEAN Gateway so zurecht bauen muss, dass er für den eigenen Fall passt. Daher:

Wie wäre es, wenn man die einzelnen EnOcean-Profile innerhalb der Konnekting-EnOcean-GW-Bibliothek in eigene .h-Dateien auslagert

Das wäre genau mein Ansatz, als Library wäre das ganze einfacher zu handhaben. Das war auch mein letzter Teil, wo ich noch etwas versucht habe Struktur rein zu bekommen. Schlussendlich war mein Ansatz für den Empfang:

• Aufbau einer kleinen "vorfilterung", die die empfangenen Daten zum einen als Debug-Output aufbereiten kann (für die Programmierung später) und zum anderen die Vorfilterung hinsichtlich des Equipment Profiles vornehmen kann.
• Aufgrund der Filterung entstünde dann (wie aktuell im Quellcode) eine kleine switch Anweisung, bei der dann wieder für jedes Equipment profile ein "case" besteht. Innerhalb dieses "case" würde ich dann eine Methode aus den eingebundenen Files aufrufen und kann dieser callbacks wie beispielsweise "Knx.write((n * 6) + 2, 0)" mitgeben.

Wenn man das aber nun auf den oben angesprochenen Taster überträgt, kann das etwas verrückt sein, die Methode mit den Callbacks auszustatten. jentz1986 was meinst du dazu? Ich habe bisher nur bisschen prototypen code gebastelt, also nix wirklich brauchbares - feel free was aufzusetzen! Ich wäre für Github zu haben und kümmere mich gerne ein bisschen um die Hygiene des Repository und passende Code-Beiträge.

Wie sieht es denn mit potentiellen Mitstreitern im Konnekting/EnOcean Umfeld aus?

Da mein Bau nun momentan mich völlig einnimmt, wird es etwas dauern bis ich wieder voll dabei bin.

Sorry Leute - so hatte ich das nicht geplant, kam alles etwas anders als gedacht.

Viele Grüße,
Uli

[jentz1986]

Ich hab mal ein Bildchen gemalt:
EnOceanKNXSchema.gif
Was man ja letztlich braucht, sind Logiken, die von KNX zu EnOcean übersetzen und umgekehrt. Ich stelle mir das so vor, dass es eben für jeden Typ der Anwendung eine Logik gibt. Diese U-Form stellt den Hauptteil um die Logiken herum dar. Jede Logik modelliert letztlich auch nur EIN Gerät.
Heißt,

• die Tasterlogik kapselt alle vier (+2) Berührungspunkte einer Verkaufseinheit;
• die NodOn-Logik kapselt 2 Schaltkanäle und 2 Tasterkanäle
• die Fenstergrifflogik kapselt die drei Zustände des Fenstergriffs (auf, zu, gekippt)
• die xyz-logik ...

Jede Logik müsste mehrfach instanziierbar sein.

• Klasse / Objekt?
• oder einfach über den numerischen Offset, der Anzahl der Parameter/Komm.-Objekte?.

Folgende Ereignisse gibt es:

• Ein KNX-Write trifft ein
  • Der KNX-Router identifiziert die Logik(en), die zu verwenden ist. (Achtung, es könnten auch mehrere Logiken sein, die der Reihe nach aufzurufen sind).
  • Die Logik übersetzt und tut und macht, und sendet die EnOcean Telegramme, die es gemäß XML-/Konnekting Konfiguration für richtig hält.
• Ein KNX-Read Request trifft ein
  • Der KNX-Router identifiziert die Logik(en), die zu verwenden ist.
  • Die Logik übersetzt und tut und macht.
  • Hier wird es nun schwierig, weil nun muss entweder
    • ein ge-cachter Wert verschickt via KNX-Reply werden muss (einfach, sofern Cache vorhanden).
    • oder eine Abfrage via Telegramm an EnOcean geschickt werden.
• Ein EnOcean Telegram trifft ein
  • Der Eno-Router identifiziert die Logik(en), die zu verwenden ist.
  • Die Logik übersetzt und tut und macht, und sendet
    • Einfacher Fall: Die KNX-Send Telegramme, die es gemäß XML-/Konnekting Konfiguration für richtig hält.
    • Reply-Fall: Die entsprechende Antwort wird erstellt.

Entsprechend muss jede Logik in der Lage sein, KNX und EnOcean Telegramme zu empfangen, zu prüfen, ob sie für sie relevant sind und dann zu agieren. Dies sollte einigermaßen intelligent gekapselt sein, so dass man nicht mehr so viele Details implementieren muss (EnOcean müsste daher in der Basis ähnlich weit in Arduino ertüchtigt werden, wie es Konnekting für KNX gemacht hat).

Mich würde eure Meinung dazu interessieren und wenn jemand fertige Bezugspunkte hat: Auch immer her damit!

[trollmar]

Wie sieht es denn mit potentiellen Mitstreitern im Konnekting/EnOcean Umfeld aus?
trollmar, trexter, ivande, SirUli gibt es etwas, womit ihr euch einbringen könnt, z.B. Tester, Anforderungsgeber, Dokumentatoren. Habt ihr schon Masifis Gateway?

Ich kann leider z. Z nicht helfen. Bin z. Z einfach zu viel noch mit Umbau und knx beschäftigt.
Habe auch noch kein Gateway da es etwas zu groß war für meine potentiellen Einbau Orte.
Aber das ist alles sehr interessant.
Werde sicher später mich hier wieder melden.
Lg

[Masifi]

jentz1986 meine SW Fähigkeiten sind sehr begrenz, daher kann ich dir dabei nicht viel helfen.

Wäre aber super wenn sich hier noch weitere Mitstreiter finden :-)

[ivande]

Gateway liegt vor mir am Schreibtisch. Leider kam es bisher nur kurz für ein paar Tests zum Einsatz.
Eines meiner DMX-LED-Treiber, ein Billigteil, (von zentralem 24V Netzteil versogt), bringt Spannunspeaks bis auf den KNX-Bus. Leuchten auf 0 gedimmt, sind die Störungen weg.
Sobald das EnOcean-Gatetway noch mit an den KNX-Bus angeschlossen wird, verstärken sich diese Spannungspitzen komischerweise, und blockieren komplett die Kommunikation über den KNX-BUS. Toll.

Ich muss somit zuest noch meine EMV-Probleme in den Griff bekommen, sodass EnOcean-Gateway störungsfrei am Bus bleiben kann.
dazu fehlt Zeit (und nochmehr die Lust)

ich bräucht das EnOcean-Gateway zur Steuerung der Raffstoren
je Tasten-Wippe:
kurzer Klick 0/1 Auf/AbLamellenverstellung auf einer GA,
langer Klick 0/1 Auf/AbFahrbefehl auf einer GA,

Gruß Ivan

[jentz1986]

ivande, welche / wieviele EnOcean Geräte hast Du denn?

[ivande]

jentz1986 geplant wären ca. 7 - 10 EnOcean-Taster, (derzeit hab ich nur einen zum Testen angekauft)

Gruß Ivan

[Masifi]

Mal ein kleines Status-Update: Der Code wurde von einem Forumsmitglied angepasst -> was ziemlich cool aussieht im ersten Moment :-) Wenn ich Github etwas besser verstehen würde, dann wäre der Code schon online.