ESP8266 KNX mit ETS

[thesing]

mumpf :
Um nochmal auf die Frage von https://knx-user-forum.de/forum/proj...49#post1360849 einzugehen.

Der Wert von einem Telegramm wird nur an ein KO zugewiesen, wenn auch die Größe des Wertes mit der Größe des KO übereinstimmen. Wenn man wie im anderen Thread gezeigt. die KO-Größe durch ETS festlegen lässt, solllte das aber immer die gleiche Größe sein.

[mumpf]

Hi,

danke für die Info - ich muss mir mal anschauen, was die ETS da wirklich macht bzw. was sie wirklich überträgt. Ich kann in der knxprod ja so was definieren:

<ComObject Id="M-00FA_A-0001-01-0000_O-9" Name="f1Out" Text="Funktion 1 - Ausgang" Number="9" FunctionText="Ausgang DPT 16.xxx" ObjectSize="14 Bytes" ReadFlag="Enabled" WriteFlag="Disabled" CommunicationFlag="Enabled" TransmitFlag="Enabled" UpdateFlag="Disabled" ReadOnInitFlag="Disabled" DatapointType="" />

...

<ComObjectRef Id="M-00FA_A-0001-01-0000_O-9_R-1009" RefId="M-00FA_A-0001-01-0000_O-9" FunctionText="Ausgang DPT 1.xxx" ObjectSize="1 Bit" DatapointType="DPT-1" />
<ComObjectRef Id="M-00FA_A-0001-01-0000_O-9_R-1109" RefId="M-00FA_A-0001-01-0000_O-9" FunctionText="Ausgang DPT 5.001" ObjectSize="1 Byte" DatapointType="DPST-5-1" />
<ComObjectRef Id="M-00FA_A-0001-01-0000_O-9_R-1209" RefId="M-00FA_A-0001-01-0000_O-9" FunctionText="Ausgang DPT 9.xxx" ObjectSize="2 Byte" DatapointType="DPT-9" />
<ComObjectRef Id="M-00FA_A-0001-01-0000_O-9_R-1309" RefId="M-00FA_A-0001-01-0000_O-9" FunctionText="Ausgang DPT 16.001" ObjectSize="14 Byte" DatapointType="DPST-16-1" />
<ComObjectRef Id="M-00FA_A-0001-01-0000_O-9_R-1409" RefId="M-00FA_A-0001-01-0000_O-9" FunctionText="Ausgang DPT 17.001" ObjectSize="1 Byte" DatapointType="DPST-17-1" />

...
                            <choose ParamRefId="M-00FA_A-0001-01-0000_P-64_R-64">
                              <when test="0">
                                <ComObjectRefRef RefId="M-00FA_A-0001-01-0000_O-9_R-1009"/>
                              </when>
                              <when test="1">
                                <ComObjectRefRef RefId="M-00FA_A-0001-01-0000_O-9_R-1109" />
                              </when>
                              <when test="2">
                                <ComObjectRefRef RefId="M-00FA_A-0001-01-0000_O-9_R-1209" />
                              </when>
                              <when test="3">
                                <ComObjectRefRef RefId="M-00FA_A-0001-01-0000_O-9_R-1309" />
                              </when>
                              <when test="4">
                                <ComObjectRefRef RefId="M-00FA_A-0001-01-0000_O-9_R-1409" />
                              </when>
                            </choose>

Somit definiere ich eigentlich nur ein KO9, die KOrefs erscheinen in der ETS zur Parametrierung unter "Kommunikationsobjekte", aber eben nur genau eines, je nach DPT-Auswahl über Parameter "M-00FA_A-0001-01-0000_P-64_R-64". Damit wird in der ETS die GA passend zum DPT zugewiesen (dafür mach ich das ganze ja). Was mir nicht klar ist: Hat man dann auf dem Device immer ein KO9 mit 14 Byte, weil das so im Original-KO spezifiziert ist, oder haben wir ein KO, dass sich letzendlich aus dem KOref ergibt?

Wenn ersteres gilt (immer 14 Byte), würde Deine Aussage

Der Wert von einem Telegramm wird nur an ein KO zugewiesen, wenn auch die Größe des Wertes mit der Größe des KO übereinstimmen.

problematisch sein. Wenn die KOref-Definition gilt, dann sollte alles passen. Ich werde das mal ausprobieren und Dir dann berichten.

Danke schon mal für die Hilfe, ist ein super Projekt, wie schon mehrere hier sagten: Genau das, was im DIY-Bereich noch gefehlt hat.

Gruß, Waldemar

[thesing]

Es sollte je nach Konfiguration in ETS die richtige Größe fürs KO übertragen werden. Ich habe lokal schon die Konfiguration der KO komplett durch ETS umgestellt. Wenn ich getestet habe pushe ich es nach github.

[thesing]

Ich habe gerade die Änderungen gepusht und die Beispiele aktualisiert. Man erhält nun die KOs durch knx.getGroupObject(NR). Die sind jetzt natürlich nur verfügbar, wenn das Gerät durch ETS konfiguriert wurde.

[mumpf]

Hi Thomas,

ich habe das Ganze jetzt so weit hin bekommen, dass knx-linux auf einer Debian-VM läuft und ich auch debuggen kann. Mein Router (auf eibd-Basis) läuft auch, aber die ETS findet kein Gerät im Programmiermodus. So wie ich das verstanden habe, geht er aber nach dem Start direkt in den Programmiermodus, oder? Dann sollte ich das doch über die ETS sehen, oder?

Falls Du noch einen Tipp hast, was ich noch checken könnte, wäre ich dankbar - für heute mach ich mal Schluß...

Gruß, Waldemar

[mumpf]

Ok, ich sehe gerade, dass die ETS den Router auch nicht unter "Gefundene Verbindungen" anzeigt. Ich muss mal mein Setup vereinfachen... ETS in ein einer VM, knx-linux läuft in einer anderen VM und der Router (eibd) nochmal woanders... wahrscheinlich liegt es daran.

Aber die eine Frage bleibt: knx-linux geht in den Programmiermodus, wenn ich es ohne vergebene PA starte, oder? Und falls nicht: Wie starte ich den Programmiermodus dann? Und überhaupt: Wo speichert denn die Linux-Implementation die ETS-Parametrisierung? In einem File? Wäre cool, denn dann könnte man gleich sehen, wie viel Speicher das Parameterset dann braucht...

Gruß, Waldemar

[thesing]

Wenn du ein knx-Linux programmieren willst, brauchst du keinen Router. Da musst du einfach nur in der ETS dein Netzwerkinterface als (Mulitcast-)Verbindung auswählen. ETS redet dann direkt mit knx-linux. knx-linux geht direkt in den Programmiermodus, wenn keine PA konfiguriert wurde (Siehe https://github.com/thelsing/knx/blob...c/main.cpp#L75).
Die Settings werden in einer Datei flash.bin abgelegt. Du kannst aber auch einen anderen Pfad mit platform.flashFilePath("my_file.bin") in der main.cpp festlegen.

[mumpf]

Da musst du einfach nur in der ETS dein Netzwerkinterface als (Mulitcast-)Verbindung auswählen.

Mist - eigentlich weiß ich das, war gestern wohl zu spät. Ich werde es heute Abend nach der Arbeit gleich versuchen.

Gruß, Waldemar

[mumpf]

Hi,

meine VMs wollen kein multicast, da muss ich noch forschen, warum...

Ich habe jetzt alles auf physikalische Geräte gebracht, knx-linux auf einen RasPi, ETS5 auf einen Desktop-Rechner. Damit konnte ich dann knx-linux erfolgreich programmieren. Die Demo sendet ja zufällige Temperaturwerte als DPT9. Beim Senden von DPT9 gibt es jetzt einen Speicherverletzungsfehler. Ich bin gerade nicht zu Hause, deswegen kommt das Fehlerprotokoll nachgeliefert. Ich dachte nur, dass die Demo vielleicht jetzt nicht mehr funktioniert, weil Du ja die dynamischen Größen für die KO eingeführt hast. Könnte das ein Grund sein?

Ich versuche erst die Demo zum laufen zu bringen, bevor ich dann mit meinem Coding weiter mache...

Gruß, Waldemar

[mumpf]

Hi, hier noch die versprochenen Fehlerdetails:

Callstack:

     pushWord    C++ (gdb)
     GroupObject::objectWriteFloatDpt9    C++ (gdb)
     GroupObject::objectWrite    C++ (gdb)
     measureTemp    C++ (gdb)
     appLoop    C++ (gdb)
     main    C++ (gdb)

Bei pushWord bricht er an der Stelle mit "Received a SIGSEGV: Segmentation fault occurred" ab, wobei "data: 0x000000b1 <error: Cannot access memory at address 0xb1> {???}" angibt.

uint8_t* pushWord(uint16_t w, uint8_t* data)
{
    data[0] = ((w >> 8) & 0xff);
->    data[1] = (w & 0xff);
    data += 2;
    return data;
}

Hilft das was? Ich versuch mich mal durchzudebuggen, aber ich kann nicht behaupten, dass ich Dein coding schon hinreichend durchdrungen habe... Wenn ich noch was konkretes testen soll, sag Bescheid.

Gruß, Waldemar

[henfri]

Hallo,

ich wollte mich jetzt mal wieder an die Arbeit machen.
Hattest du dir die Sonoff nochmal angesehen?

Ich hatte deinen Post übersehen, dass du einen Bug gefixt hast, der für meine Übertragungsprobleme verantwortlich sein kann. Ich habe gerade auf die aktuelle Lib aktualisiert. Danke dafür!

Erstmal hatte ich jetzt leider eine Exception:

62334, 25.73, 103096.77, 33.80, 583040.62, 25.00, 0, 25.62, 33.99, 0.00, 0
65334, 25.71, 103093.02, 33.43, 591281.44, 25.00, 0, 25.60, 33.66, 0.00, 0

Exception (29):
epc1=0x40211302 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont
sp: 3fff1680 end: 3fff18a0 offset: 01a0

>>>stack>>>
3fff1820: 3fff0118 3ffe9070 3fff07b8 4020fee0
3fff1830: 3fff2be4 3ffe9070 3fff2be4 40207a98
3fff1840: 3fff0118 3ffe9070 3ffeffd8 40203f5e
3fff1850: 00000000 00000000 00000000 00000000
3fff1860: 00000000 00000000 3fff2d1c 0000004f
3fff1870: 0000004a 00000000 00000001 40210de5
3fff1880: 3fffdad0 00000000 3fff0870 40210e10
3fff1890: feefeffe feefeffe 3fff0880 40100710
<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode3,6)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v614f7c32
~ld
start
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.177.21
Zykl. send:20
setup multicast addr: 224.0.23.12 port: 3671 ip: 192.168.177.21
result 1
Timestamp [ms], raw temperature [°C], pressure [hPa], raw relative humidity [%], gas [Ohm], IAQ, IAQ accuracy, temperature [°C], relative humidity [%], CO2
*WM: freeing allocated params!

Die wiederholt sich auch immer wieder.
Ich habe dennoch mal probiert zu programmieren. Das hat nicht geklappt. Anbei die Logs. Magst du dir das nochmal ansehen?


Gruß,
Hendrik

[thesing]

Das passiert wenn man dann doch nicht mehr testet.. Ich schau mal nach wenn die Kinder Mittagsschlaf machen.

[henfri]

;-)

[mumpf]

Hi,

ich wollte nur mal sagen, dass Du Dir keinen Stress machen sollst. Für meine ersten Tests kann ich auch ohne weiteres mit Deiner vorherigen Version arbeiten (also ohne dem letzten commit). Zumindest wollte ich das jetzt mal probieren. Und wenn das klappt (wovon ich ausgehe), kann ich erstmal mein Coding auf den Stand bringen und ausprobieren und so auch Deinen Stack besser kennen lernen. Die Mehrfachbelegung von KO und Parameter brauche ich erst, wenn ich viele Logikkanäle realisieren will.

Gruß, Waldemar

[thesing]

Ich habe den Stack eigentlich ziemlich genau nach KNX-Spezifikation gebaut. Vielleicht komme ich mal dazu ein Diagramm o.ä. zu machen.
Es gibt Kommunkationsobjekte (GroupObject). Eine Tabelle mit diesen (GroupObjectTable). Ein Tabelle mit zugewiesenen Gruppenadressen (AddressTable), eine MappingTabelle zwischen den GroupObjectTable und der AddressTable (AssociationTable). Die sagt welches GroupObject welche Adressen hat. Siehe dazu auch Kapitel 3.1.1 in 03_03_07 in der Spezi. Wie mit den GroupObjects gearbeitet wird kann man in 03_04_01 Kapitel 3 nachlesen.
Neben diesen Objekten gibt es noch ein DeviceObject (Geräteinformationen wie PA, Seriennummer usw.) ein ApplikationObjekt (Parameter) und ggf. ein IpParameterObject (IP-Konfiguration).
Alles Platform-Spezifische habe ich in einer Platform-Klasse gekapselt. Davon gibt es bisher eine für Linux, ESP8266 und SAMD.

Dazu gibt es die Diversen Schichten: BAU (BusAccessUnit in der Ausprägung SystemB), Anwendungsschicht (ApplicationLayer), Transportschicht (TransportLayer), Netzwerkschicht (NetworkLayer) und Datenzugriffsschicht( DataLinkLayer). Den DataLinkLayer gibt es in zwei Varianten: TPUART und IP.

Über die BAU bekommt man Zugriff auf die ganzen Interface-Objekte (GroupObjectTable, AddressTable, usw. ). Für Arduino habe davor noch eine Facade gebaut, damit man einfacher mit klar kommt.
Die Schichten haben alle noch Protocol-Data-Units und ServiceAccessPoints.

Der Datenfluss ist bei Gruppenkommunikation dann wie folgt:
am Beispiel Empfang:
Telegramm -> Datalinklayer -> NetworkLayer -> TransportLayer (Suchen von GruppenAddresse in Adresstabelle. Der Index ist der TSAP (TransportLayerServiceAccesPoint). Suche von allen Einträgen in der Assoziationstabelle zu diesen TSAP. Das sind die ASAPs (Nummer des Kommunikationsobjekts). -> ApplicationLayer (suche entsprechendes Kommunikationsobjekt in GroupObjectTable und ändere es)

Senden funktioniert genau andersherum

Beim Konfigurieren durch ETS werden im wesentlichen die Interfaceobjekte entladen, Speicher erzeugt, Daten geschrieben, Der Status der Interfaceobjekte wieder auf "geladen" gesetzt und das Gerät neu gestartet.

Ich hoffe das hilft erstmal beim Verständnis. Bei Fragen fragen.

Grüße,
Thomas