ESP8266 KNX mit ETS

[Marha]

Vermutlich wird es so, dass Du der einzige bist. Meine Hochachtung hast Du jedenfalls. Bringt Dich und das Projekt zwar nicht weiter, aber ich finde es eine super super Leistung. An dieser Stelle einmal Danke für Deine aufgewendete Zeit. Leider fehlt sie mir im Moment, mich aktiv mit diesem/Deinem Projekt hier zu beschäftigen, aber ich lese und verfolge es fleißig mit.

[thesing]

Es sollte in einer normalen Installation nicht vorkommen. Wenn man allerdings zwei Geräten die gleiche PA gibt hat man den Fall. ETS kann das über PID_DEVICE_CONTROL (PID = 14) abfragen (3_5_1) In 2.7 und 3_3_2 würde es auch stehen. Die richtige Information dazu findet sich in der Norm EN 50090-4-2:2004 4.3.6 L_Service_Information service. Ich bin wahrscheinlich der einzige, der sich Urlaub nimmt, um in die Universitätsbibliothek nach den Normen zu schauen.

Ob das wirklich ausgewertet wird weiß ich nicht.

[Bernator]

Klassendiagramm ist spitze

[Bernator]

"U_FRAMESTATE_IND" kommt nur im 8bit Uart Mode, sollte also passen

Frames die jemand anderes mit der gleichen Geräteadresse wie man selbst hat empfängt, sollen aber weiter gegeben werden.

Kanns das überhaupt geben? Woher kommt diese Info, hab im Standard auf die schnelle nichts dazu gefunden aber der ist ja ziemlich Umfangreich

Hab gestern noch mit einem eigenen Datalinklayer angefangen, wird aber noch ne Zeit dauern da ich vermutlich erst übernächste Woche wieder zum programmieren komme

[thesing]

Ich habe übrigens mal ein Klassendiagramm der wichtigsten Klassen erstellt. Da kann man sehen welche Klasse welche anderen nutzt: https://knx.readthedocs.io/en/latest...sdiagramm.html

[thesing]

Bernator Ich habe nochmal in die Doku vom NCN geschaut. Du hast recht. Es wird effektiv auf das Ack gewartet. Ggf. ist die Stelle eh falsch, da nach dem Frame erst U_FRAMESTATE_IND kommt. Ich meinte, dass die selbst versendeten Frames erkannt werden müssen und nicht an DataLinkLayer::frameRecieved übergeben werden dürfen. Frames die jemand anderes mit der gleichen Geräteadresse wie man selbst hat empfängt, sollen aber weiter gegeben werden. Man kann also nicht einfach auf die Quelladresse des Frames prüfen.

henfri TCP-Kommunikation gibt es nur beim Programmieren von Geräten und beim Tunnelling. Bei TCP müsste das Gerät die IP-Adresse und Port einer IP-Schnittstelle kennen. Die könnte man natürlich als Parameter in ETS einstellen, aber das wäre dann eine Gerät das mit anderen KNX-Geräten reden kann, aber kein KNX-Gerät. Ich würde eher diese zuverlässige Kommunikation von Gira implementieren. Wenn man dann noch ein RoutingNetworkLayer baut, kann man mit einem ESP oder einem Raspberry-Pi einen Router bauen. Dazu bräuchte ich aber einen Wireshark-Mitschnitt damit ich mir anschauen kann wie das genau funktioniert.

VG
Thomas

[henfri]

Wenn ich sehe was ihr hier vor habt dann bin ich optimistisch, dass bald die Kommunikation über TCP implementiert werden wird...
:-)
Habt ihr da bessere Erfahrungen gemacht als ich?
Auch im Zusammenhang der knx Implementation für tasmota wird ja auch immer wieder über verlorene Telegramme berichtet. (Auch ESP)

Gruß,
Hendrik

[Bernator]

Bist du sicher? Ich verstehe das so das sendFrame ja per Schleife darauf wartet bis _sendBuffer=0 wird und das passiert ja erst im receive Teile wenn das Echo +L_Data.con empfangen wurde:

if (len == _sendBufferLength && memcmp(_sendBuffer, buffer, len) == 0)
        {
            //we got the send telegramm back next byte is L_Data.con byte
            uint8_t confirm = _platform.readUart();
            confirm &= L_DATA_CON_MASK;
            _sendResult = (confirm > 0);
            _sendBuffer = 0;
            _sendBufferLength = 0;

            return true;
        }

btw. ist "_platform.readUart()" hier nicht potentiell gefährlich da es -1 returned wenn L_Data.con noch nicht im rx buffer des Arduino angekommen ist?

Dabei bitte darauf achten, dass selbst versendete Frames nicht auch als solche erkannt werden wenn sie wieder empfangen werden. (Es wir ein Fehlerflag gesetzt, wenn der Stack ein Paket verarbeitet, welches die eigene Geräteadresse hat.

Da kann ich dir nicht ganz folgen, eigene Frames sollen nicht erkannt werden?

Falls du dich daran versuchen möchtest muss du nur ein eigenes Datalinklayer schreiben

vielleicht mach ich das

[thesing]

SebastianObi Es gibt keine fest einprogrammierte Begrenzung. Ich fürchte dein Problem wirst du nur mit zusätzlichen Debugausgaben finden können. Dazu kannst du die print* Funktionen aus bits.h nutzen. Die werden auf die entsprechende serielle Schnittstelle umgebogen. Lesen und schreiben vom Flash findet in memory.cpp statt. Ich seh gerade, dass bei void Memory::readMemory() nur 512 Byte vom Flash gelesen werden. Vielleicht hilft es dir schon wenn man die Zahl erhöht. Wahrscheinlich wäre es besser gar keine feste Anzahl zu lesen und statt dessen am Anfang die Zahl der gespeicherten Bytes im Flash abzulegen.

Bernator 1 stimmt soweit. 2 nur in so fern, dass auf das darauf gewartet wird, bis das Paket versendet wurde. Beides kann man sicherlich besser machen. Falls du dich daran versuchen möchtest muss du nur ein eigenes Datalinklayer schreiben und in Bau07B0 nutzen. Dabei bitte darauf achten, dass selbst versendete Frames nicht auch als solche erkannt werden wenn sie wieder empfangen werden. (Es wir ein Fehlerflag gesetzt, wenn der Stack ein Paket verarbeitet, welches die eigene Geräteadresse hat. Das kann ETS abfragen. Das wird wahrscheinlich im Rahmen einer Fehlerdiagnose oder Installationsdiagnose gemacht. ) Patches welcome

Wenn man eine USB-Schnittstelle unter Linux nutzen wollen würde, kann man ähnlich vorgehen. Dabei müsste man wahrscheinlich du die Bytes vom CemiFrame direkt ins /dev/ttyUSBX oder so schreiben bzw. lesen.

[mumpf]

Hi,

ich habe mal einen Testlauf mit 240 KO (was in der Software Gruppenadresse heißt) und 9120 Bytes Parameter versucht, allerdings nur in der Linux-Implementation und nur als Machbarkeitsstudie, sprich: Ob man es prinzipiell programmieren kann. Da gab es keinen Hänger, ich muss es aber mit dem aktuellen Stand erneut probieren.
Bin derzeit am Debuggen von 3 KO und 114 Bytes Parameter und will das später um Faktor 80 erhöhen...

Wie gesagt, ich hab noch keine negativeffekte gefunden, aber ich habe es auch noch nicht auf die Zielplattform, den SAMD, gebracht.

Gruß, Waldemar

P.S.: In der ETS gibt es bei mir 80*27 = 2160 KO, aber es sind max. 240 davon sichtbar und somit für die Laufzeit relevant.

[SebastianObi]

Ich habe mal eine (ungetestete) Änderung committed. Vielleicht geht es damit.

Hallo,

damit ist der "Adress is not valid" Fehler behoben. Sonst scheint auch alles weitere zu funktionieren.

Jetzt habe ich nur noch eine Anforderung/Problem.
Was ist die maximale Anzahl an Gruppenadressen und Parameter/Bytes?
Ich programmiere gerade ein Enocean & 433MHz Gateway und verwende dort sehr viele Parameter und Gruppenadressen auch als Reserve/Optionen. Welche so auch nicht alle parallel je nach Konfiguration verwendet werden. 804 Gruppenadressen und 1108 Bytes Parameter. Ja ich weis, das ist extrem viel Am Ende des Applikations-Übertragungsprozesses bleibt der Microcontroller hängen/friert ein. Vermutlich gibt es hier irgendwo einen Variablenüberlauf oder Speicher kann nicht adressiert werden. Ich habe in der FlashStorage-Library eigentlich genügend Speicher reserviert.

[Bernator]

Hallo,

was mich ein wenig stört ist die Tatsache das knx.loop() teilweise doch recht lange blockiert, so wie ich das sehe liegt es hauptsächlich an 2 Punkten:

1. der tpuart Treiber pollt die serielle Schnittstelle solange bis ein komplettes Frame empfangen wurde
2. beim senden eines Telegrammes wird der eigentlich asynchrone Vorgang (send, confirm) im data_link_layer synchronisiert, d.h. der stack wartet bis das telegramm gesendet und wieder empfangen (confirm) wurde.

Stimmt das oder übersehe ich etwas?

[henfri]

Sorry, hab den Faden verloren.
Was fixt das?

[thesing]

Ich habe mal eine (ungetestete) Änderung committed. Vielleicht geht es damit.

[jorues]

Dann probier doch mal die Zeile auf:

if (_memoryReference == 0 || address < _memoryReference)
_memoryReference = address;

zu ändern.

Damit lässt sich bei mir der Sketch aus der ETS heraus programmieren. Allerdings sind die gesendeten Werte vom Sketch (bme680) alle "0".

Grüße und besten Dank für die Unterstützung