ESP8266 KNX mit ETS

[Ing-Dom]

Hallo zusammen,

ich hab hier ja ne Menge verpasst. ESP8266 im Titel hat mich einfach nicht angemacht, und ich bin jetzt erst durch die alt. Software für Masifis Tool darauf gekomen dass das auch für SAMD21 und TP tut

Das probier ich doch gerne mal. Ich scheitere aber schon.. ziemlich früh

Ich hab die knx-demo (git head) als tp variante mit arduino gebaut. Board ist ein ItsyBitsyM0 und eine MicroBCU.

- die led blinkt mit ca. 3Hz
- in der ETS ist kein device im Prog mode, 15.15.255 ist nicht vorhanden
- am serial monitor kommt gar nichts
- keine Reaktion wenn ich am prog pin auf 3v3 oder gnd ziehe

1) was bedeutet das blinken mit ca. 3Hz ?
2) sollte das gerät im "neuzustand" nicht unter 15.15.255 ansprechbar sein?
3) ist das normal, dass am serial monitor nichts passiert? fehlt da ggf. ein while(!serial) ?
4) wie muss der knx buton pin angeschlossen werden? was wird hier erwartet?

[h1as]

Hallo SirSydom,

ich habe vor kurzem auch die Demo mit dem SAMD21 und Tpuart getestet.
Ich musste die KNX_Flashsize auf 1024 runtersetzen damit das Teil nicht im readmemory hängen bleibt. Außerdem musste ich im Code noch eine default Phy. Adresse zuweisen damit das Flashen aus ETS raus klappt.
Vielleicht hilft dir das.
Viele Grüße H!as

[Ing-Dom]

Ich musste die KNX_Flashsize auf 1024 runtersetzen damit das Teil nicht im readmemory hängen bleibt.

in der flashstorage lib von thesing steht bei mir:

#ifndef EEPROM_EMULATION_SIZE
#define EEPROM_EMULATION_SIZE 1024
#endif

das meinst du, oder?

Außerdem musste ich im Code noch eine default Phy. Adresse zuweisen damit das Flashen aus ETS raus klappt.

ok, magst du vielleicht den schnippsel posten? Wäre nett!

[mumpf]

Hi,

wenn es eher 5 Hz sind, dann bist Du wohl hier gelandet:

void ArduinoPlatform::fatalError()
{
    const int period = 200;
    while (true)
    {
#ifdef LED_BUILTIN
        if ((millis() % period) > (period / 2))
            digitalWrite(LED_BUILTIN, HIGH);
        else
            digitalWrite(LED_BUILTIN, LOW);
#endif
    }
}

Die Frage ist, warum... Dab den aktuellen Stack lange nicht mehr "angefasst", da ich (leider immer noch aus Zeitgründen) auf einem fork arbeite. Da hat sich ne Menge getan, das erinnert mich wieder daran, dass ich da ran muss, aber das ist nicht das Thema hier.

• Damals hat sich ein neues Modul immer mit 0.0.0 und nicht mit 15.15.255 gemeldet.
• Du musst in der Demo darauf achten, dass   ArduinoPlatform::SerialDebug = &Serial;  auch das richtige Serial adressiert (also passend zum Board auf die USB-Schnittstelle geht), beim Board von Masifi ist das z.B. "SerialUSB".
• Und Du musst die richtigen Pins zuweisen, falls die Defaults nicht stimmen:
  

  	    // pin or GPIO the programming led is connected to. Default is LED_BUILTIN
  	    // knx.ledPin(LED_BUILTIN);
  	    // is the led active on HIGH or low? Default is LOW
  	    // knx.ledPinActiveOn(HIGH);
  	    // pin or GPIO programming button is connected to. Default is 0
  	    // knx.buttonPin(0);

Ich bin mit Hardware nicht so fit, deswegen nutze ich ja das Board von Masifi, deswegen kann ich über die Verschaltung nichts sagen. Aber Du musst erstmal das blinken weg bekommen. Da einer der Aufrufe von fatalError(); im MemoryManagement liegt, ist der Tipp von h1as sicherlich sinnvoll.

Wenn es nach dem Start nicht mehr blinkt, sollte beim togglen vom Prog-Pin die Prog-LED auch togglen. Und wenn die KNX-Verbindung klappt, auch in der ETS ein Device 0.0.0 im ProgMode erscheinen.

Und dann kannst Du auch eine PA zuweisen und von der ETS aus programmieren. Und dann erscheint auch was im serial monitor.

Gruß, Waldemar

P.S.: Ich würde es weiter probieren, ich finde, der Stack lohnt sich...

[mumpf]

Das mit der eigenen PA geht hier:
https://github.com/thelsing/knx/blob...e_object.h#L42
Bei mir hat die 0 aber immer funktioniert. Trotzdem hab ich das auf 0xFFFF gesetzt, weil es andere Geräte auch so machen.

Zur EEPROM-Größe kann ich nichts sagen, das hab ich nie gebraucht.

Gruß, Waldemar

P.S.: Arbeitest Du mit der Arduino-IDE oder mit PlatformIO?

[h1as]

Ne nicht die Eeprom Size, sondern die KNX_Flash_Size in der Memory.cpp.

[Ing-Dom]

wenn es eher 5 Hz sind, dann bist Du wohl hier gelandet:

ja,ich habs nur grob geschätzt, wird schon das sein

Du musst in der Demo darauf achten, dass ArduinoPlatform::SerialDebug = &Serial; auch das richtige Serial adressiert (also passend zum Board auf die USB-Schnittstelle geht), beim Board von Masifi ist das z.B. "SerialUSB".

Serial passt für mich

Die Frage ist, wo wird die Serial für KNX festgelegt? Bzw. was ist hier der Default?

P.S.: Arbeitest Du mit der Arduino-IDE oder mit PlatformIO?

VisualStudio Code mit der MS Arduino-Extension

Ne nicht die Eeprom Size, sondern die KNX_Flash_Size in der Memory.cpp.

ah ok. probier ich gleich mal aus.

=> ah, das scheint es gewesen zu sein! porg button geht, ich finde das device in der ets
jetzt kann ich weitermachen

Das mit der eigenen PA geht hier:
https://github.com/thelsing/knx/blob...e_object.h#L42
Bei mir hat die 0 aber immer funktioniert. Trotzdem hab ich das auf 0xFFFF gesetzt, weil es andere Geräte auch so machen.

ich finde 15.15.255 auf jeden Fall besser, weil 0.0.0 eigentlich keine gültige PA ist. Die kann man in der ETS nicht überprüfen, ob vorhanden z.B.
Überschreiben klappt aber.

[mumpf]

Hi,

Du meinst das hier: https://github.com/thelsing/knx/blob.../memory.cpp#L6?

Ich hab eben mal nachgeschaut, das gibt es bei mir nicht. Was für ein Glück... ich würde nicht mal mit 8192 auskommen, ich habe 8621 Bytes an Parametern, dazu kommt dann ja auch noch die KO<->GA Zuordnung. Ich muss mich wirklich mit dem aktuellen Stack mal wieder beschäftigen.

Gruß, Waldemar

[mumpf]

Hi,

ich finde 15.15.255 auf jeden Fall besser, weil 0.0.0 eigentlich keine gültige PA ist.

ich denke, es war schon Absicht, dass es keine gültige PA ist, damit man diese auf jeden Fall mit der ETS programmieren muss. Wichtig ist, dass Du bei dem Stack KEINE PA in die Firmware gießen musst. Es geht nur um die Initiale PA, die man hat, wenn das Gerät entladen ist.

Gruß, Waldemar

[Ing-Dom]

da ich (leider immer noch aus Zeitgründen) auf einem fork arbeite.

interessant. Mit welcher Zielsetzung?

P.S.: Ich würde es weiter probieren, ich finde, der Stack lohnt sich...

Ja, der Stack hat was.

Einerseits bringt die System B Kompatibilität ne Menge Komplexität rein, aber andererseits ist eben diese Kompatibiltät auch toll.
Die Integration in die ETS verbessert das ganze handling für den Anwender ungemein.

Die Möglichkeiten mit WLAN und IP Linie sind auch irre interessant!

Was mich etwas abschreckt ist die kaum vorhandene "erklärende" Doku.

Die Kommobjekte und die Parameter - wo werden die eigentlich definiert? Also in der Firmware? Ist das alles dynamisch, wird also erst beim proggen angelegt?



Und dann auch die Situation mit der ETS DLL und dem signieren, was ja so im graubereich liegt... Ganze Geräte damit verkaufen (auch Sammelbestellen) würde ich mich glaub ich nicht so trauen. Ich sinniere, ob es ohne riesigen Aufwand machbar ist, ein Tool zu schreiben, dass die unsignierte xml nutzt um das Gerät zu proggen.
Das könnte man dann mitliefern. und wenn Endanwender dann im Netz ein Tool finden, mit dem man daraus eine knxprod macht und über ETS lädt...

[Ing-Dom]

Wichtig ist, dass Du bei dem Stack KEINE PA in die Firmware gießen musst. Es geht nur um die Initiale PA, die man hat, wenn das Gerät entladen ist.

das ist mir schon klar! Ist ja bei Konnekting, wo ich schon viel gemacht habe, auch so.

Du meinst das hier: https://github.com/thelsing/knx/blob.../memory.cpp#L6?

Ich hab eben mal nachgeschaut, das gibt es bei mir nicht. Was für ein Glück... ich würde nicht mal mit 8192 auskommen

Ja genau. Ich denke aber, ich weiß auch warum der 8192 nicht geht, denn in der FlashStorage wird ja default-mäßig mit 1024 gearbeitet!
Ich dreh hier mal auf 8192 hoch und schau was passiert.

[jeff25]

interessant. Mit welcher Zielsetzung?

Und dann auch die Situation mit der ETS DLL und dem signieren, was ja so im graubereich liegt... Ganze Geräte damit verkaufen (auch Sammelbestellen) würde ich mich glaub ich nicht so trauen. Ich sinniere, ob es ohne riesigen Aufwand machbar ist, ein Tool zu schreiben, dass die unsignierte xml nutzt um das Gerät zu proggen.
Das könnte man dann mitliefern. und wenn Endanwender dann im Netz ein Tool finden, mit dem man daraus eine knxprod macht und über ETS lädt...

Evtl wäre es auch interesant eine VD1 per tool zu schreiben und diese dann legal zu importieren. Darüber schon mal nachgedacht?

[Ing-Dom]

System B mit VD1 ? geht das?

[Sonnengruesser]

Was mich etwas abschreckt ist die kaum vorhandene "erklärende" Doku.

Die Kommobjekte und die Parameter - wo werden die eigentlich definiert? Also in der Firmware? Ist das alles dynamisch, wird also erst beim proggen angelegt?

Und dann auch die Situation mit der ETS DLL und dem signieren, was ja so im graubereich liegt...

genau deswegen ist die Einstiegsschwelle bewusst ein wenig erhöht. Ist ja ein "proof of concept" und keine Arduino library, die jeder Dummy bedienen können soll.

[mumpf]

Hi,

Mit welcher Zielsetzung?

Die alternative Software für das Board von Masifi ist von mir. Und ich hab damals einen fork gemacht, weil ich einige Anpassungen brauchte, die ich alleine schon deswegen nicht in den Stack bringen konnte, weil meine C++-Kenntnisse "unter aller Sa*" sind . Und leider ist es dabei geblieben.

Die Integration in die ETS verbessert das ganze handling für den Anwender ungemein.

Die Möglichkeiten mit WLAN und IP Linie sind auch irre interessant!

Für mich war das der Grund, überhaupt an ein DIY-Projekt zu gehen. Ich hatte auch in KONNEKTING reingeschaut, ist auch toll, was da entstanden ist, aber die Möglichkeiten der ETS, was Applikationsdesign angeht, sind da erheblich größer. Und für mich ist die ETS auch das zentrale Projektierungstool, ich will da alle Geräte sehen und alle GA-Verknüpfungen haben. Und es scheint so, als ob auch jemand an KnxSecure im Stack arbeitet.

Die Kommobjekte und die Parameter - wo werden die eigentlich definiert? Also in der Firmware? Ist das alles dynamisch, wird also erst beim proggen angelegt?

Ja, alles dynamisch. Es gibt eine Klasse GroupObject (in group_object.h), jedes Kommunikationsobjekt ist eine Instanz davon. Für die Parameter gibt es passende Parameter-Getter, technisch übergibt die ETS alle Parameter als ein Speicherblock.

Was mich etwas abschreckt ist die kaum vorhandene "erklärende" Doku.

Naja, mir hat die Demo und die Sourcen von Stack gereicht, zusätzlich hab ich mir ein paar knxprod-Files von echten Geräten angesehen. Und dann auch hier gefragt.

Und dann auch die Situation mit der ETS DLL und dem signieren, was ja so im graubereich liegt...

Das ist auch der Grund, warum ich nur Source und eine Anleitung zum selberbauen veröffentliche, aber keine fertigen knxprod-Files.

Ganze Geräte damit verkaufen (auch Sammelbestellen) würde ich mich glaub ich nicht so trauen.

Ich hab mit Hardware sowieso nicht so viel am Hut, deswegen hab ich mich auf das Modul von Masifi "gestürzt".

Ich sinniere, ob es ohne riesigen Aufwand machbar ist, ein Tool zu schreiben, dass die unsignierte xml nutzt um das Gerät zu proggen.

Es gab hier vor kurzem jemanden, der hat als eine Art Studienarbeit eine (kleine) Alternative zur ETS geschrieben. Mit der konnte man auch programmieren. Allerdings fehlte im UI noch einiges. Mir fällt der Username nicht ein, ich stell das noch rein, wenn ich das wiederfinde. Wäre eine Alternative, Du hast Recht.

Ich denke aber, ich weiß auch warum der 8192 nicht geht, denn in der FlashStorage wird ja default-mäßig mit 1024 gearbeitet!

Das ist eine Idee, allerdings dachte ich, das Standardmäßig inzwischen in den Flash vom SAMD geschrieben wird und FlashStorage gar nicht mehr gebraucht wird? Aber da bin ich leider nicht mehr Up-To-Date, sorry.

Ich wünsche Dir viel Erfolg,
Gruß, Waldemar