ESP8266 KNX mit ETS

[mumpf]

Hi,

mit der Siemens BCU hätte ich ein Gerät drinne, ja. Und dessen KOs.

Sorry, aber da hast Du eine falsche Vorstellung! Die Siemens-BCU, die hier so gerne im DIY-Bereich genutzt wird, ist nichts andres als ein Transceiver. Es gibt keine knxprod für die Siemens-BCU, höchstens für Siemens-Geräte, die die BCU nutzen. Es widerspricht auch dem Konzept: Die Firmware eines Gerätes muss zur knxprod passen, es kann keine "abstrakte" knxprod geben.

mein Hirnknoten gerade ist, dass ich für die ETS eine Gerätdatei brauche deren Zertifikat äußerst grau herzustellen ist (oder eben teuer).

Für die Erstellung der knxprod wird eine dll der ETS aufgerufen. Das macht die ETS auch selbst, wenn sie alte vd-Dateien in knxprod umwandelt. Wie "grau" das ist, muss jeder selber wissen. Solange man nicht anfängt, solche Geräte zu verkaufen, sollte keiner was dagegen haben.

Und wenn ich mein diy Gerät nicht in die ETS bekomme kann ich folglich auch keine Verbindungen herstellen.

Doch, über Konnekting (eigenes Konzept, wie man Geräte parametrisiert und GAs zuweist) oder eben über "KNX auf Arduino", indem Du die GA fest in der Firmware hinterlegst. Aber wie schon öfters geschrieben, der Hauptvorteil dieses Stacks ist ja, dass man auch die DIY-Geräte in die ETS bekommt.

Hallo Robert, das ist schon das Problem. Ich kann keine Phy. Adresse schreiben. Es wird kein Gerät im Programmiermodus gefunden.

Manuel, Du musst den eibd stoppen oder zumindest den -R Parameter entfernen. Leider stören der eibd und der knxd im Routermodus die Programmierung über Netzwerkschnittstelle. Allerdings hättest Du auch gestern schon das Problem haben sollen...

Gruß, Waldemar

[BlackDevil]

mumpf na da war ich doch fast richtig ... mein Hirnknoten gerade ist, dass ich für die ETS eine Gerätdatei brauche deren Zertifikat äußerst grau herzustellen ist (oder eben teuer). Und in der ETS parametriere ich am Ende die Verbindungen. Und wenn ich mein diy Gerät nicht in die ETS bekomme kann ich folglich auch keine Verbindungen herstellen.

mit der Siemens BCU hätte ich ein Gerät drinne, ja. Und dessen KOs. Es gibt hier aber ja auch DIY Geräte ohne Siemens BCU, sondern nur mit dem Transceiver. Oder taugt da auch das Siemens BCU Gerät in der ETS?

[manu241]

Hallo Robert, das ist schon das Problem. Ich kann keine Phy. Adresse schreiben. Es wird kein Gerät im Programmiermodus gefunden.

Gruß Manuel

[jeff25]

Hi Manu,

schau mal ob du eine neue Physik. Adresse schreiben kannst... seltsam.

Gruß
RObert

[manu241]

Hallo Jeff25.

hier meine Schnittstellen. Ausgewählt habe ich die: Intel(R) Dual Band Wireless ...

[jeff25]

ETS auf IP interface?

[manu241]

Hallo Jeff25,

ja, ich habe zu gestern nichts geändert.

Gruß Manuel

[jeff25]

KNXD am laufen oder hast du einen IP router?

[manu241]

Hallo,

ich habe nochmal eine Frage bzw Problem. Ich habe heute nochmal die Demo auf einen Arduino geladen. Dann diesen mit dem Netzwerk erfolgreich verbunden.
Die Programmiertaste lässt sich auch bedienen (Sehe ich an der LED und im Serial-Monitor).

Als Verbindung ist der ETS habe ich meine Netzwerkschnittstelle gewählt. (Multicast 224.0.23.12)

Jedoch findet die ETS den Arduino nicht. Was mache ich da falsch ?

Gruß Manuel

[mumpf]

Heist das, ich gebe über die ETS dem einen Verbindungspunkt die GA und Code die dann fest in mein selbstgebautes Gerät ein,

Nein, natürlich nicht! Wenn Du die GA in Deinem Coding drin hast, dann bräuchte man die ETS nicht mehr - allerdings müsste dann jeder User selber die Firmware kompilieren, um eine GA zu ändern. Das Ziel ist doch gerade, eine Abstraktion der Verbindung zu bekommen! Das mit fest programmierten GA ist der Weg, den "KNX auf Arduino" geht.

Du programmierst in Deinem Code auf ein bestimmtes KO, das ist der Verbindungspunkt. Die Zuweisung von GA zu KO übernimmt dann die ETS. Dein Coding weiß nichts von GA. Das ist der Weg, den die ETS geht und auch Konnekting.

Gruß, Waldemar

[BlackDevil]

Heist das, ich gebe über die ETS dem einen Verbindungspunkt die GA und Code die dann fest in mein selbstgebautes Gerät ein, womit wieder beide verbunden wären? Das würde dann auch erklären wie Konnekting und co funktionieren

[mumpf]

Hi,

die "DATA" Anzeige von PlatformIO ist nur die halbe Wahrheit, hier fehlen Stack/Heap ohne die aber nichts läuft

das ist klar, nur weiß ich (durch ausprobieren), dass im alten Stack nichts mehr über 12k ging, bei 6144 Bytes für die alte Flash-Lib. Und die 6144 Bytes wurde (in etwa) nochmal vom Stack für die Kopie verbraucht. Der Rest ging wurde sowieso vom knx-Framework und von weiteren libs verbraucht, das passiert ja jetzt auch. Somit habe ich durch Deine Implementierung in etwa 2*6k RAM gewonnen, und das nur für KO, denn anderes wandert ja jetzt in den Flash. Hat auf jeden Fall Potential.

da macht es doch Sinn gleich diese zu verwenden

Natürlich, ich hatte mich nur von Deiner Tabelle (in der Du den Speicherverbrauch verglichen hast) verwirren lassen, aber das waren die Angaben für die alte Flash-Lib.

Naja ich würde sagen wenn ich den nötigen Flash Speicher entbehren kann um externe EEPROM Daten zu puffern, kann ich doch gleich die "Flash only" Variante nutzen und auf den externen EEPROM verzichten.

Ich kam bisher gar nicht auf die Idee, dass der Flash eng werden könnte - bisher war da immer genug Luft nach oben. Und ich nutze ein Board, dass immer 32k I2C EEPROM mit drauf hat. Da speichere ich auch Werte beim Stromausfall weg, die mir auf Dauer wichtig sind. Deswegen kam ich auf die Idee, denn aus meiner Sicht ist ein neuer Programmer, der den Flash nicht löscht, weitere Hardware, die ich besorgen müsste .

Leider hab ich noch immer keinen Tipp gefunden, wie man das "Erase Flash" verhindert, dafür aber haufenweise welche, wie man absichtlich den Flash löscht...

Gruß, Waldemar

[mumpf]

Hi Robert,

kurz gesagt: Ja, Du musst alles, was Du in der ETS abbildest, auch in der Firmware nachbauen. Aber da Du oben von falschen Annahmen ausgehst, hole ich nochmal etwas aus:

Konzeptionell ist die ETS ein reines Parametrisierungswerkzeug, das mit der Firmware nichts zu tun hat. Kann man ähnlich sehen wie mit Visu und Logik: Eine Visu zeigt nur Zustände an und erlaubt Zustände zu wechseln, eine Logik kann in Abhängigkeit von einem oder mehreren Zuständen eigene Aktionen ausführen und braucht dazu keinerlei Visu. Aus der Visu-Sicht ist es egal, ob der Zustand direkt aus einem Gerät kommt oder aus einer Logik, somit ist die Visu auch unabhängig von der Logik.

Die ETS als Parametrierungswerkzeug stellt nur wenige Daten bereit (das ist der Output):

• Einen Parameterblock (ein kontinuierlicher Speicherbereich mit Daten), hier ist die ETS so nett und initialisiert alle Werte, auch die, die nicht eingegeben wurden. Deswegen braucht jeder Parameter einen "Value" als default.
• Einen GroupObjects-Block: Das sind in der deutschen ETS die Kommunikationsobjekte (KO) und stellen die Schnittstellenbeschreibung (Eingang/Ausgang) dar
• Eine Association-Table, die alle GA-Zuweisungen zu den jeweiligen KO hat, das wertet aber der KNX-Stack von Thomas aus, damit haben wir nichts zu tun.

Diese Daten sendet die ETS an "irgendetwas" beim Programmieren, es ist egal, ob das ein KNX-Gerät ist, oder ein Affe, der passend zu den Parametern immer Knöpfchen drückt, die Werte auf die KO schreiben oder an die CIA, die damit dann versucht, Dein Haus zu übernehmen . Es sind einfach ein paar Parameter und KO. Der Job der ETS ist es, dem User irgendwie diesen Parameterblock mit Hilfe eines UI erstellen zu lassen. Und das xml / knxprod ist dazu gedacht, komplett zu beschreiben, welche Parameter es gibt und wie deren Eingabe im UI zu erfolgen hat.

Ich hoffe, daraus geht klar hervor, dass die Firmware einfach nur ein paar Daten bekommt (immerhin korrekt initialisiert) und selber wissen muss, was sie damit anfängt. Übrigens greift knx.getGroupObject nur auf ein KO zu, einen Parameter bekommst Du mit knx.paramInt(), knx.paramWord(), knx.paramByte().

Innerhalb der ETS gibt es nochmal mehrere Abstranktionsebenen. Einmal die technische Ebene:

• ParameterTypes beschreiben die Typen der Parameter, wobei hier nicht nur ein Datentyp im Programmiersinn gemeint ist (also ob int, byte, char oder bool), sondern ein semantischer Datentyp (dieses Byte ist eine Dropdown mit verschiedenen Werten, dieser String wird nur in der ETS verwendet und nicht in den Parameterblock gepackt, dieser bool ist eine Checkbox). Datentypen eben aus UI-Sicht.
• Parameter beschreiben die Parameter selbst, als das, was dann als Parameterblock zum Gerät geschickt wird (nicht die ParameterRefRef). Hier spielt der Offset (Adresse innerhalb des Parameterblocks) eine wesentliche Rolle.
• CommObject beschreiben die Kommunikationsobjekte selbst, also die IO-Schnittstelle. Hier sind die Typen die bekannten DPT, die bereits über die KNX-Spec vorgegeben sind (müssen also nicht in der ETS definiert werden). Über die Flags bestimmt man, ob ein KO ein Ein- oder Ausgang (oder beides) ist.

Für die Nutzung der technischen Ebene im UI gibt es eine Abstraktion:

• ParameterRef referenzieren einen Parameter, erlauben aber für die konkrete Nutzung im UI noch Anpassungen, z.B. einen anderen Text. So kann man einen Parameter im UI an verschiedenen Stellen mit verschiedenen Texten nutzen so Parameterspeicher sparen.
• CommObjectRef referenziert ein ComObject und ist analog zum Parameter zu sehen: Ein ComObjectRef kann z.B. für ein ComObject mit DPT1 die Änderung auf DPT5 bewirken. So kann man ein ComObject mit verschiedenen DPT versehen, natürlich dann passend zu den Parametern.

Im UI selbst (Dynamic Section in der ETS) referenziert man dann:

• mit dem Element ParameterRefRef einen ParameterRef, der seinerseits den Parameter referenziert, um den es gerade geht.
• mit dem Element ComObjectRefRef ein ComObjectRef, der seinerseits das ComObject referenziert, um das es gerade geht.
• mit dem Element choose, gefolgt von when kann man Bedingungen formulieren, wann welche ParameterRef bzw. ComObjectRef angezeigt werden. Das sollte man nicht mit einem IF einer prozeduralen Sprache verwechseln! Es geht hier nur um Anzeige von UI-Elementen.

Das war es eigentlich, mit diesen wenigen Mitteln kann man schon recht intuitive UI bauen und entsprechend in der Firmware auswerten - aber wie schon gesagt, UI und Firmware haben NICHTS miteinander zu tun!

Gruß, Waldemar

[Bernator]

Danke, gut zu hören...
Aber Achtung, die "DATA" Anzeige von PlatformIO ist nur die halbe Wahrheit, hier fehlen Stack/Heap ohne die aber nichts läuft

Wieso muss ich eigentlich nirgendwo die max. Speichergröße angeben?

Weil die nötige Speichergröße schon von der ETS kommt (ist ja abhängig von den Verknüpfungen ect.) und da macht es doch Sinn gleich diese zu verwenden
ETS gibt Größe x bekannt --> Interface Object fordert x bei Platform an --> Platform stellt Speicherblock für x bereit oder landet im fatalError()

Ansonsten würde mir eine bessere Variante für Dein "external" einfallen....

Naja ich würde sagen wenn ich den nötigen Flash Speicher entbehren kann um externe EEPROM Daten zu puffern, kann ich doch gleich die "Flash only" Variante nutzen und auf den externen EEPROM verzichten. Nur für den Luxus in der Entwicklungsphase (den man noch anderst erreichen kann) eigene Hardware vorsehen kommt mir nicht so recht sinnvoll vor Wie schon vorher kurz erwähnt wäre hier eher Potential in die Richtung vorhanden, dass man nicht alle Daten aus dem externen Speicher im Ram puffern müsste (zb. die Parameter).

[jeff25]

mumpf ich habe deine selbst gebauten knxprod xml screenshots bewundert. Ich habe mir nun mal eine MDT knxprod file angesehen und dort die "when" parameter gesehen in dem man ja in der ETS unterschiedliche Auswahlen treffen kann. Je nachdem werden die Objekte auch unterschiedlich gefüllt. Weist du wie das im Framework ausgewertet wird. Bis jetzt dachte ich das jede ParameterRefRef´s der Reihe nach einer knx.getGroupObject(x) zugeordnet wird. Wenn das so sit wie ich denke müsste ich die ganzen "if´s" im Microcontroler code auch nochmal nachbauen das ich die knx.getGroupObject(x) korrekt gefüllt habe oder?

Gruß
RObert