ESP8266 KNX mit ETS

[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

[mumpf]

Bernator: Super, einfach irre!

Ich konnte es nicht lassen, einen ersten einfachen Test zu machen. Dein Coding genommen, mit meinem zusammen compiliert, auf den SAMD hochgeladen, läuft. Bei mir gibt PlatformIO folgendes aus:

DATA:    [==        ]  19.5% (used 6396 bytes from 32768 bytes)
PROGRAM: [====      ]  36.6% (used 95988 bytes from 262144 bytes)

Vorher stand da was von knapp 12500 bytes (hab mir leider den Wert nicht genau gemerkt). Zu weiteren Test komme ich erst am Wochenende, aber das ist schon mal irre! Ist ja gerade mal die Hälfte an RAM. Ich werde mal mit den max. möglichen 80 Logikkanälen testen, die mein Generator kann (derzeit sind es 40).

Ist übrigens die Flash-Version. Wieso muss ich eigentlich nirgendwo die max. Speichergröße angeben?

Und ein kleiner Wermutstropfen: Ein erneutes Flashen löscht doch die ETS-Daten. Leider... ich muss mal googlen, ob man das bei PlatformIO irgendwie verhindern kann. Ansonsten würde mir eine bessere Variante für Dein "external" einfallen: Man speichert im externen EEPROM, beim lesen packt man aber alles ins Flash (und nicht ins RAM) und arbeitet von da an so wie die Flash-Variante. Würde ein Löschen des Flash überstehen und immer noch mehr RAM sparen als Deine derzeitige Implementierung. Ist mir gerade nur eingefallen, ich hab das noch nicht wirklich durchdacht, ich hoffe, es ist kein Unsinn, den ich hier verzapfe...

Also erstmal vielen Dank, der erste Straight-Forward-Test hat schon mal super geklappt, ich werde weiter berichten.

Gruß, Waldemar

[Sonnengruesser]

Na gut, dann war meine Einschätzung wohl doch verkehrt, Glück auf manu241 und MasterOfPuppets .
Vielleicht sollte ich mir den Stack doch mal genauer ansehen...

[manu241]

Hallo Waldemar,

danke für deine Hilfe. Die Demo-Version habe ich bereits zum laufen gebracht.

Mein erster Arduino schickt bereits Munter diese Zufallswerte.

Gruß Manuel

[MasterOfPuppets]

Vielen Dank für die Mühe =).

Jetzt habe ich es geschnaggelt, also doch so einfach wie ich zu Anfang erst dachte

Gruß Pierre

[mumpf]

Hi,

Sonnengruesser: Sorry, ich fand "mit der ETS integration herumquälen" negativ behaftet und wollte nur klarstellen, dass ich das als wesentlichen Vorteil sehe. Aber natürlich hast Du recht: Damit ist die Einstiegshürde gegenüber den anderen genannten Frameworks hoch! Und man braucht auch recht potente Microcontroller (schnell, viel Flash, viel Speicher), damit alles überhaupt läuft. Wie schon oben geschrieben:

manu241 und MasterOfPuppets: Hier nochmal die Schritte, die es erfordert, um die knx-demo.ino zum laufen zu bringen:

1. Verbindung mit TP herstellen, wenn man damit arbeiten will (Siemens BCU, MicroBCU)
2. Falls notwendig, einen Programmierbutton an einen Pin anschließen
3. knx-demo.ino mit entsprechenden Angaben für die Anschluß-Pins anpassen
4. knx-demo.ino auf einen der unterstützen Microcontroller hochladen
5. Falls es die ESP-Plattform ist, WLAN-Verbindung herstellen (steht weiter vorne im Thread, wie das geht)
6. knxprod für IP oder für TP in die ETS laden
7. Am Microcontroller den Programmierbutton drücken
8. Jetzt sollte die Prog-LED leuchten
9. Von der ETS aus die physikalische Adresse programmieren
10. Jetzt sollte die Prog-LED ausgehen
11. In der ETS der Applikation ein paar GA zuweisen
12. Dann von der ETS aus die Applikation hochladen
13. Jetzt sollte das Device auf den zugewiesenen GA Telegramme schicken (Temp, Temp max, Temp min). Das kann man sich im Gruppenmonitor ansehen.

Erst wenn man das alles erfolgreich durch hat, sollte man über Anpassungen und Änderungen nachdenken.

Gruß, Waldemar

[Sonnengruesser]

Vielleicht hab ich aufgrund der Wortwahl ein falsches Bild im Kopf, aber Aussagen wie

die I/Os eines Arduino nutzen kann um KNX Befehle per Arduino sendet

und

Arduinos habe ich auch schon des öfteren programmiert

klingen für mich eher nach Arduino copy-paste Programmierung ohne Hintergrundwissen - entschuldigt mich bitte falls dem nicht so ist. Und ich denke um dieses Projekt zu nutzen, sollte man zumindest verstehen wie structs, Klassen, usw. funktionieren.
Allein um die paar Zeilen aus der knx-demo.ino zu verstehen muss man sich schon ein bisschen reinfuchsen können:

 [TABLE]
 	 		[TR]
 			[TD]// print values of parameters if device is already configured[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]if (knx.configured())[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]{[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]// register callback for reset GO[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goReset.callback(resetCallback);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goReset.dataPointType(DPT_Trigger);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goCurrent.dataPointType(DPT_Value_Temp);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goMin.dataPointType(DPT_Value_Temp);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goMax.dataPointType(DPT_Value_Temp);[/TD]
 		[/TR]
 	 [/TABLE]

Das geht dann über wire.begin() und pinMode() ein wenig hinaus - das verstehe ich unter "Arduino schon des öfteren programmiert".

Das Projekt hier selbst finde ich klasse! Nur die Einstiegshürde sollte man auch realistisch sehen.

[jeff25]

kann mumpf nur zustimmen, bin auch erst seit kurzem eingestiegen mit Vorwissen aber schon lange her, gerade KNX-IP in Verbingung mit einem ESP8266 bringt schnelle Erfolge und man kann an den Demo Projekt viel anpassen um zu verstehen wie das alles funktioniert, auch die ETS Integration finde ich klasse und ist mir zum großen Teil klar. Ich rede natürlich nicht von eigenen XML Files erstellen im Editor :-)

[mumpf]

und man muss sich nicht mit der ETS-Integration herumquälen.

Ähhhh... Aber das ist doch gerade DER Pluspunkt für dieses Framework! Man kann DIY-Geräte basteln UND sie in die ETS integrieren. Und dann noch über KNX-IP und KNX-TP arbeiten! Ich empfinde eher die anderen Frameworks als "quälend", da ich entweder für jede Änderung eine neue Firmware brauche (bei Arduino am KNX) oder eine alternative Parametrisierungssoftware brauche (bei KONNEKTING).

Aber klar: Jeder soll das nehmen, was für einen am Angenehmsten ist.

Gruß, Waldemar

[jeff25]

Ich bin nun auch nicht wirklich der Profi aber du musst dir erst mal überlegen was du überhaupt machen willst, denke als erste Übung wäre ja ein Tasterinterface mit einem Eingang gut, da musst du ja nur den Eingang abfragen und bei Änderung das KNX Objekt ändern bzw die Änderung raussenden, das kann man sich ganz gut ableiten von den existierenden Beispielen (knx-demo).

[Sonnengruesser]

manu241 und MasterOfPuppets: Für den Einstieg ist sicher erst mal das Projekt Arduino am KNX zu empfehlen. Das ist deutlich einfacher und man muss sich nicht mit der ETS-Integration herumquälen. Später kann man sich schrittweise dann in Richtung dieses Projekts bewegen. Als Zwischenschritt vielleicht noch mal bei KonnektING reinschauen.
Wenn man sich natürlich mit Softwareentwicklung auskennt sollte auch der direkte Einstieg hier möglich sein.

[mumpf]

Hi,

eigentlich macht das knx-demo.ino alles nötige (also keine Abfrage von IO-Pins, aber das kann man in anderen dafür gedachten Projekten abgucken). Ich gehe mal davon aus, dass Du knx-demo.ino auf Deiner Wunschplattform (linux, SAMD, ESP8266 oder ESP32) zum laufen gebracht hast.

In measure_temp gibt es z.B.

    goCurrent.value(currentValue);

das schreibt den aktuellen Temperaturwert auf das Kommunikationsobjekt goCurrent. Du könntest jetzt (erstmal testweise) einen pin auslesen und so was machen wie

if (pinValue != goCurrent.value()) goCurrent.value(pinValue);

Damit würde der Pin-Wert auf den Bus geschrieben werden, wenn er sich ändert.

Ein Beispiel zum Empfangen siehst Du in resetCallback. Der wird immer aufgerufen, wenn das KO goReset einen Wert vom Bus empfängt. Da kannst Du dann so was machen wie

pinValue = go.value();
// hier kommt der Code, um pinValue auf dem Pin auszugeben...

Das ist natürlich sehr "hausbacken", um mit dem aktuellen knxprod auszukommen (der pinValue, der auf den Bus gesendet wird, wird als Temperatur (DPT9.001) gesendet). Um was richtiges zu machen, musst Du mit CreateKnxProd eine knxprod-Datei basteln, dann kannst Du das auch über die ETS parametrisieren. Aber wie gesagt, in der knx-demo.ino sind schon alle Teile zum empfangen und senden drin.

Oder ich hab das Problem nicht verstanden... Vielleicht solltet ihr genauer euer Problem beschreiben, dann kann man euch konkret helfen...

Gruß, Waldemar