ESP8266 KNX mit ETS

[hotze]

Hi RObert, Ich suche nicht nur ein Mikrocontroller, sondern ein ganzes Board
radino32_CC1101_C_45_1000_logo.jpg
hi Waldemar, ja, das hätte mich intressiert auf welchen Systemen das hier läuft.
Angenommen dieses Modul könnte in grösserer Stückzahl für 3$ gekauft werden, währe es intressant den Code dazu zu optimieren.
Werde mir am Freitag sicher CC1101 + SAMD21 bestellen. wie kopmpiliere ich eigentlich dieses Projekt. hatte gerade versucht in Atom mit platfom.io zu machen. jezt mit VSC am üben. ist es noch gar nicht so weit fortgeschritten, das es Standalone arbeitet?

[thesing]

henfri Ich habe zwar schon eine Weile ein neuen sonoff s20 aber der ist noch orginalverpackt...

hotzen Ich weiß nicht ob der Stack auf einem Arduino-Leonardo funktioniert. Kannst ja mal probieren das Beispiel zu übersetzen. Wahrscheinlich fehlt den AVR in der C-Lib etwas. Ist aber bestimmt lösbar. Ob der Speicher ausreicht weiß ich allerdings nicht. Ich würde eher ein SAMD empfehlen.

mumpf Es ist gut möglich, dass er bei einem der Neustarts während der Programmierung schon ein ReadGA absetzt. Das sollte wohl nicht so sein. Ich hab mal ein Issue aufgemacht.

[mumpf]

Hi Thomas,

ich habe jeztz Bekanntschaft mit dem "ReadOnInit"-Flag machen dürfen... funktioniert nicht. Ich habe leider noch kein (überschaubares) reproduzierbares Beispiel, aber vielleicht hast Du ja schon eine Idee, wenn ich das Problem beschreibe.

Folgendes passiert: In der knxprod ist ein KO mit ReadOnInit="Enable" definiert. Dieses KO bekommt auch eine GA. Bei einem "blanken" SAMD, also ohne PA und ohne vorherige Firmware (Flash wurde komplett gelöscht) kann man die PA noch programmieren, die Applikation klappt aber nicht mehr. Ganz am Ende (ich vermute, bei der association- oder der adress-table) hängt er dann. Das letze Coding von uns im Callstack ist

bool GroupObject::valueReadOnInit()
{
    if (!_table)
        return false;
    return [COLOR=#FF0000]bitRead(ntohs(_table->_tableData[_asap]), 13)[/COLOR] > 0;
}

Ich habe leider weder das Protokoll aus dem Gruppenmonitor gesichert noch den Callstack komplett im Kopf, aber es sah für mich so aus, als ob er an der Stelle schon einen Read absetzen wollte.
Er war auf jeden Fall auch hier:

void ApplicationLayer::dataGroupIndication(HopCountType hopType, Priority priority, uint16_t tsap, APDU& apdu)
{

    ...

    int32_t asap = _assocTable.nextAsap(tsap, startIdx);
    for (; asap != -1; asap = _assocTable.nextAsap(tsap, startIdx))
    {
        switch (apdu.type())
        {
            case GroupValueRead:
                [COLOR=#FF0000]_bau.groupValueReadIndication(asap, priority, hopType);[/COLOR]
                break;
            case GroupValueResponse:
                _bau.groupValueReadAppLayerConfirm(asap, priority, hopType, data, len);
                break;
            case GroupValueWrite:
                _bau.groupValueWriteIndication(asap, priority, hopType, data, len);
        }
    }
}

Ich hätte das nicht während der Programmierung erwartet, sondern erst nach dem ersten Neustart. Der Debugger sprach bei obigen bitRead() (in rot) von einer Speicherverletzung.

Es ist aber nicht komplett fehlerhaft , wenn man beim ersten Programmieren dieses KO nicht mit einer GA versieht, sondern irgendein anderes KO (ohne I-Flag), und dann in einem 2. Rutsch die GA für dieses KO (das mit I-Flag) programmiert, geht das Programmieren durch - wobei ich nicht darauf geachtet habe, ob dann wirklich ein ReadRequest kommt.

Mir ist klar, dass das keine vollständige Feherbeschreibung ist, ich schreibe das hier aus 3 Gründen:

1. um es nicht zu vergessen
2. um die anderen Nutzer zu informieren
3. in der Hoffnung, dass es vielleicht doch genug ist, damit Du weißt, wo das Problem steckt.

Ich hab gestern recht lange rumprobiert, um ein reproduzierbares Beispiel hin zu bekommen und mich am Ende gefreut, als ich ne Lösung hatte. Deswegen kein sauberes Protokoll etc. Aber falls mehr erforderlich ist, bin ich gerne bereit, das nochmal nachzubauen, vielleicht mit der knx-demo, dann wäre das überschaubar...

Gruß, Waldemar

[mumpf]

Hi hotze,

ich bin zwar nicht so der Hardware-Mensch, aber ich bin mir ziemlich sicher, dass Du mindestens die 32-Bit-Version brauchst. Und ob die Implementierung hier im Stack ist für den SAMD21, also Cortex M0, ob das auch für einen Cortex M3 geht, weiß ich nicht. Aber da können wahrscheinlich die Leute, die sich damit besser auskennen, qualifiziertere Antworten geben. Ich wollte Dich nur vor einer voreiligen Bestellung bewahren.

Gruß, Waldemar

[jeff25]

Hi Hotze,

schau mal bei Mouser da ist er super billig. 3,60 Euro

https://www.mouser.de/ProductDetail/...7mKWjHIsNJ3w==

Gruß
RObert

[hotze]

Frage zur Hardware. Für KNX-RF würde ein radino CC1101 868 funktionieren?
ATmega32U4 Mikrocontroller https://shop.in-circuit.de/product_i...products_id=32
und Nachfolger: https://shop.in-circuit.de/product_i...roducts_id=180

ich finde es leider nirgends Preiswert. Kennt jemand andere ähnliche?

[henfri]

Hallo,

thesing Hattest du dir eigentlich die Sonoff Steckdose jetzt eigentlich noch einmal zur Brust genommen?
Funktioniert sie bei dir sie jetzt zuverlässig?

Gruß,
Hendrik

[thesing]

Ja die datapointTypes bleiben drin. Ich glaube außerdem nicht, dass es schon allzu viel Nutzer gibt.

VG
Thomas

[mumpf]

OK, dann mach ich das... Aber dann nur die lokalen Handler, den datapointType lasse ich mit #ifdef drin, oder? Und Du nimmst das auf Deine Kappe .

Gruß, Waldemar

[thesing]

Ich habe nichts gegen "breaking changes". Zumal die nötigen Änderungen überschaubar sind.

[mumpf]

Hi Thomas,

danke für die prompte Beratung, ich schau mir mal den DataLinkLayer an, so "tief" war ich noch nicht unterwegs .

Einen Neustart über einen internen Watchdog eines Geräts oder durch Unterbrechung der Spannung kriegst du nicht mit.

Das ist mir klar, aber es ist wieder ein Stück besser. Und nach einem kompletten Busreset (oder komplettem Stromausfall) macht es ja schon meine Logikengine.

Zu den small-Groupobjects: nimmst du bitte gleich den lokalen Handler ganz raus und passt die Beispiele entsprechend an?

Hmmm, das wäre aber ein "breaking change"? Ich wollte das den anderen nicht antun, deswegen das mit den #ifdef/#ifndef. So wie das jetzt ist, compiliert es weiterhin normal für alle, und erst wenn man SMALL_GROUPOBJECT setzt, muss man was am eigenen Coding ändern.

Gruß, Waldemar

[thesing]

Hallo Waldemar,

die Telegramme werden schon im DataLinkLayer gefiltert. Man müsste dann diesen Layer den Busmonitor-Modus aktivieren. Wenn der aktiv ist, und ein entsprechender Callback am DataLinkLayer registriert wurde, kann man dann alle Telegramme da hingeben.
Die kriegst dann allerdings nur mit, wenn jemand das Geräte per Telegramm zurück setzt. Einen Neustart über einen internen Watchdog eines Geräts oder durch Unterbrechung der Spannung kriegst du nicht mit.

Zu den small-Groupobjects: nimmst du bitte gleich den lokalen Handler ganz raus und passt die Beispiele entsprechend an?

Den Pull-request dann bitte gegen den devel-Branch stellen.

VG
Thomas

[mumpf]

Hi Thomas et al,

ich habe mal wieder eine Frage nach zur Stackfunktionalität und nach einem Tip, wo ich beginnen sollte...

Ich brauche quasi die Umkehrfunktion von "Restart device" (die übrigens super funktioniert und sich auch schon mal in der Praxis bewährt hat). Ich möchte eine logische Abfrage der Form "Wenn das Gerät mit der PA x.y.z neu gestartet wurde, dann mache <irgendwas>". Praktischerweise sind die letzten beiden Telegramme, die ein Gerät beim programmieren empfängt, genau die selben, die es bei einem Restart über die ETS (oder über mein Modul) empfängt, nämlich "Restart", gefolgt vom "T_Disconnect". Darauf würde ich gerne reagieren können.

Eigentlich sollte der knx-Stack ja alle Telegramme auf dem Bus empfangen können, aber wahrscheinlich werden recht früh alle Telegramme anhand der PA ausgefiltert. Wo müsste ich da schauen bzw. kommt man da noch vorher ran, um einen passenden Filter zu implementieren? Oder passiert das bereits im KNX-Chip?

Hintergrund: Obwohl viele Geräte heutzutage nach einem Neustart ihre Initialwerte vom Bus lesen können, gibt es immer noch Situationen, bei denen man "Nachinitialisieren" muss. Ich hab zwar über meine Logikengine ein recht zuverlässiges Verfahren entwickelt, diese Initialisierung nach einem Busreset zu machen, aber wenn ich zwischendurch einzelne Geräte neu programmiere (oder neustarte), dann ist diese Initialisierung wieder "futsch". Das würde ich jetzt gerne automatisieren...

Ich bräuchte einen Tipp, wo ich anfangen soll zu suchen...

Gruß, Waldemar

[mumpf]

Hi Thomas,

bevor ich mich ans Testen Deiner memory-Implementierung mache, wollte ich noch einen Pull-Request meiner Implementierung von speicherplatzsparenden Kommunikationsobjekten stellen. Die habe ich jetzt erfolgreich einige Zeit getestet. Vorher hier aber ein paar Eckdaten zur Diskussion:

• Eingeschaltet wird das durch ein   #define SMALL_GROUPOBJECT , derzeit nur als Compileroption (-DSMALL_GROUPOBJECT), später kann das in die von Dir vorgeschlagene config.h
• der Member   Dpt _datapointType  wird ausgeblendet und alle Methoden, die sich darauf beziehen. Somit muss man bei den Zugriffsmethoden immer einen Dpt mitgeben.
• Der callback (für Input-KO) und der entsprechende Member   _updateHandler  fällt ersatzlos weg
• Dann kommen noch Verbesserungen, die auch ohne SMALL_GROUPOBJECT funktionieren:
• Der Member   _table  ist jetzt statisch (Klassenmember)
• Es gibt einen neuen statischen Member   _updateHandlerStatic  mit der passenden Methode classCallback zum setzen/lesen eines Callback für die Input-KO. Da das jetzt eine Klassenmethode ist, gibt es genau einen Callback für alle Input-KO. Da der Callback mit dem KO als Argument aufgerufen wird, kann die aufgerufene Methode anhand vom ko.asap() weiter dispatchen.

Beim letzten Punkt haben wir letztens über eine statische Liste diskutiert. Da wir aber hier im Spar-Modus sind, kann man vom Caller nicht nur das mitgeben des DPT jeweils bei den Zugriffsfunktionen verlangen, sondern auch das Dispatchen der Callbacks. Somit muss vom Stack eigentlich nur ein Callback angeboten werden.

Wie schon weiter oben beschrieben, habe ich mit diesen Änderungen und durch konsequente vermeiden von Hilfsvariablen für KO-Inhalte (kann man mit valueNoSend stattdessen direkt im KO speichern) die Anzahl der KO, die ich im Speicher unterkriege, von ca. 135 auf ca. 399 bekommen (also fast Faktor 3, wobei ich die Obergrenze meiner Implementierung und nicht die Obergrenze des Speichers erreicht habe).

Ich finde, das ist eine sinnvolle Erweiterung und hätte sie gerne im Stack, ist das für Dich soweit ok? Vor allem das mit nur einem callback? Eine Liste zu halten bringt keinen Vorteil: Wenn man den Speicher hat, kann man ohne SMALL_GROUPOBJECT arbeiten, und wenn man sparen will, nutzt man einen Callback, implementiert diese Liste im eigenen Coding statisch, dann kommt sie in den Flash und man spart noch mehr RAM.

Gruß, Waldemar

P.S.: Ich hab das jetzt mal in meinen fork auf github in den branch small-groupobject gepushed, falls Du das sehen willst...

[thesing]

Ich habe jetzt das wiki für alle frei geschaltet: https://github.com/thelsing/knx/wiki
Wer mag kann gern Inhalt beisteuern.