ESP8266 KNX mit ETS

[mumpf]

Hi,

auch wenn das ein Monolog wird , die erste Frage scheint sich erledigt zu haben, Reset ist Reset... hab ich auch befürchtet, aber was solls, ist ein seltener Fall im Produktivbetrieb, kommt nur oft beim entwickeln vor.

Und nachdem ich mir nochmal das Datasheet vom NCN5130 im Zusammenhang mit der Implementierung vom tpuart_data_link_layer angesehen habe, hab ich zumindest eine Idee, was ich versuchen muss, um den 5V Regler abzuschalten. Falls jemand Beispielcoding hat, wäre das hilfreich, aber ich denke, ich werde es auch so hin bekommen.

Wie der JLink den gesamten Flash löschen kann hab ich aber immer noch nicht in Erfahrung bringen können...

Gruß, Waldemar

[jeff25]

Hi Waldemar,

ich lese Deine Monologe mit Interesse, bin nur fachlich nicht so weit Antworten zu geben :-)

Gruß
RObert

[mumpf]

Hi,

für die Nachwelt und falls es jemand anders auch braucht (und hier überhaupt findet): So greift man auf die internen Register des NCN5130 zu:

#define U_INT_REG_WR_REQ_WD       0x28
#define U_INT_REG_WR_REQ_ACR0     0x29
#define U_INT_REG_WR_REQ_ACR1     0x2A
#define U_INT_REG_WR_REQ_ASR0     0x2B
#define ACR0_FLAG_V20VEN          0x40
#define ACR0_FLAG_DC2EN           0x20
#define ACR0_FLAG_XCLKEN          0x10
#define ACR0_FLAG_TRIGEN          0x08
#define ACR0_FLAG_V20VCLIMIT      0x04
void savePower() {
    println("savePower: Switching off all energy hungry devices...");
    // turn off 5V rail (CO2-Sensor & Buzzer)
    uint8_t buffer[] = {U_INT_REG_WR_REQ_ACR0, ACR0_FLAG_XCLKEN | ACR0_FLAG_V20VCLIMIT };
    knx.platform().writeUart(buffer, 2);
}

Im obigen Bespiel greife ich auf das Analog Control Register 0 zu und lösche die Bits 5 und 6 (ACR0_FLAG_V20VEN, ACR0_FLAG_DC2EN), die anderen lasse ich so, wie sie sind (default). Die Register sind im datasheet https://www.onsemi.com/pub/Collateral/NCN5130-D.PDF beschrieben.

Gruß, Waldemar

[thesing]

Soll ich das wiki auf der github-Seite frei schalten? Da könnte man solche Dinge nachhalten.

[jeff25]

fände ich total gut dann muss man nicht 44 Seiten durchsuchen :-)

[thesing]

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

[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...

[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

[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,

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]

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

[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]

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

VG
Thomas

[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

[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?