ESP8266 KNX mit ETS

[SebastianObi]

Nur kein Stress, es kommt auf ein paar Tage nicht drauf an für diese unwichtige Änderung.

Ich habe ein Problem gefunden.
Mit der Version "async tpuart_data_link_layer version (#21)" bekomme ich keine Kommunikation mehr zustande mit dem SAMD21 und TPUART.
Folgende Fehler werden ausgegeben:

imeout during RX_L_DATA
got U_CONFIGURE_IND: 0x11
got UNEXPECTED: 0x91
got UNEXPECTED: 0xA6
got U_STATE_IND: 0x7F
got UNEXPECTED: 0xE3
got L_ACKN_IND
got L_ACKN_IND
got U_CONFIGURE_IND: 0xD
Timeout during RX_L_DATA
got L_ACKN_IND
Timeout during RX_L_DATA
got U_STATE_IND: 0xFF
got UNEXPECTED: 0xF2
got L_ACKN_IND
got L_ACKN_IND
got UNEXPECTED: 0xE1
got U_CONFIGURE_IND: 0x1
got L_ACKN_IND
got UNEXPECTED: 0xA2
Timeout during RX_L_DATA
got U_STATE_IND: 0xFF
got UNEXPECTED: 0xF2
got L_ACKN_IND
got L_ACKN_IND
got UNEXPECTED: 0xE1
got U_CONFIGURE_IND: 0x1
got L_ACKN_IND
got UNEXPECTED: 0xA2
Timeout during RX_L_DATA

Ohne diese Änderung funktioniert es noch ohne Probleme.
Bitte bei Gelegenheit mal prüfen.

Danke

[Bernator]

Welche BCU verwendest du genau? TPUART oder NCN oder....
Ist das die gesamte Debug Ausgabe, also von Anfang an oder fehlt da was?
So wie es hier aussieht bekommst du Timeouts zwischen den Bytes, dann wird der bisher empfangene Frame verworfen und von vorne begonnen....

Setz mal testhalber

#define BYTE_TIMEOUT 3

in tpuart_data_link_layer.cpp etwas rauf, evtl. ist das zu knapp bemessen. Was machst du sonst noch in der loop? Ich vermute nämlich stark das hier etwas länger blockiert und somit die bytes zu langsam abgeholt werden....

[SebastianObi]

Ich verwende die Siemens BCU. Natürlich wird in der Loop noch diverses gemacht, was bei mir zu diesem Problem geführt hatte.

#define BYTE_TIMEOUT 3

Ich habe dies nun auf 5 erhöht. Damit gibt es bei mir keine Probleme mehr.

Danke für den Tipp.

[mumpf]

Hi Thomas,

ich habe mal wieder eine Frage: Auch wenn ich immer noch nicht erfolgreich mit dem Teilprojekt war, mein Logikmodul auf den SAMD zu bringen - was aber daran liegt, dass ich meine knxprod nochmal komplett umbaue - so ist mir trotzdem folgendes in den Sinn gekommen:

Die ETS (zumindest ab 5.7.x) macht intern mehr Sachen über die Seriennummer des KNX-Gerätes, in der Annahme, dass diese Seriennummern eindeutig sind. Ich habe bisher nur in der CreateKnxProd eine Möglichkeit gefunden, eine Seriennummer anzugeben. Aber eigentlich müsste ich diese doch in der Firmware vergeben, oder? Ich will ja eigentlich nur eine knxprod für mehrere Instanzen eines Gerätetyps haben (z.B. 10 Temp/Hum-Sensoren oder auch 3 Logikmodule). Müsste man nicht eine Methode zur Vergabe der Seriennummer haben? Oder - falls die Seriennummer in der knxprod eine Bedeutung hat - zumindest etwas, um einen Suffix an die Seriennummer zu hängen, um diese eindeutig zu machen?

Ich sehe bei mir einen Bedarf von min. 3 Logikmodulen und würde dann einfach 2 GPIO unterschiedlich auf Masse legen und so 4 mögliche Seriennummern bekommen. Oder - falls es das beim SAMD gibt, irgendeine Prozessor-Id an die Seriennummer hängen, um es eindeutig zu machen.

Ich will nur verhindern, dass mir zukünftig die ETS bei einem Unload von einem Gerät gleich alle löscht, nur weil alle die gleiche Seriennummer haben...

Gruß, Waldemar

[mumpf]

Hi Thomas,

nochmal ich... beschäftige mich immer noch mit Updatefähigkeit von knxprod-Versionen. IMHO macht hier CreateKnxProd einen Fehler! Ich habe testweise mal ein Gerät angelegt mit Version 10, das dann in Version 11 mit 1 neuen ParameterTyp, neuen Parameter und einem neuen KO versehen. Bei "ReplaceVersions" auch eine 10 eingetragen.

Die 11 konnte ich nicht importieren, dann habe ich ins XML geschaut und folgendes gesehen:

            <ComObjectRefs>
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-1_R-1" RefId="M-00FA_A-0014-0B-0000_O-1" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-2_R-2" RefId="M-00FA_A-0014-0B-0000_O-2" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-3_R-3" RefId="M-00FA_A-0014-0B-0000_O-3" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-4_R-4" RefId="M-00FA_A-0014-0B-0000_O-4" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-5_R-5" RefId="M-00FA_A-0014-0B-0000_O-5" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-6_R-6" RefId="M-00FA_A-0014-0B-0000_O-6" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-7_R-7" RefId="M-00FA_A-0014-0B-0000_O-7" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-8_R-8" RefId="M-00FA_A-0014-0B-0000_O-8" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-9_R-9" RefId="M-00FA_A-0014-0B-0000_O-9" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-10_R-10" RefId="M-00FA_A-0014-0B-0000_O-10" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-11_R-11" RefId="M-00FA_A-0014-0B-0000_O-11" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-12_R-12" RefId="M-00FA_A-0014-0B-0000_O-12" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-13_R-13" RefId="M-00FA_A-0014-0B-0000_O-13" />
              <ComObjectRef Id="M-00FA_A-0014-0B-0000_O-14_R-14" RefId="M-00FA_A-0014-0B-0000_O-14" />
            </ComObjectRefs>

Soweit ist das OK, die   0014-0B  endete vorher mit "A", und die "O-14" ist auch neu. Passt. Aber im ChannelIndependentBlock:

                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-1_R-1" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-2_R-2" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-3_R-3" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-4_R-4" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-5_R-5" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-6_R-6" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-7_R-7" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-8_R-8" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-9_R-9" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-10_R-10" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-11_R-11" />
                <ComObjectRefRef RefId="M-00FA_A-0014-0A-0000_O-12_R-12" />
                <ComObjectRefRef RefId="M-00FA_A-[COLOR=#FF0000]0014-0A[/COLOR]-0000_O-13_R-13" />
              </ParameterBlock>
            </ChannelIndependentBlock>

Hier werden alle ComObjectRefRef immer noch mit   0014-0A  generiert und das neue KO (die O-14) steht nicht drin.

Nachtrag: Nachdem ich manuell alle ID's auf 0014-0B geändert habe, konnte ich importieren und ein Update machen.

Nachtrag 2: Inzwischen glaube ich, dass Du beim erneuten öffnen nicht sauber abräumst. Ich hab mir mit mal die Version 10 und 11 angeschaut und wollte dann noch eine 12 machen (leider weiß ich nicht mehr exakt die Editier-Schritte, ich versuche die aber noch zu reproduzieren). In der 12 (als SaveAs von der 11) hatte ich dann alle ParameterTypes von 10 (mit 0014-0A), von 11 (mit 0014-0B) und von 12 (mit 0014-0C). Dann kamen alle Parameter von 10 mit der ParameterID 0014-0C-nn, aber mit der Typreferenz auf den Parametertyp von 10 (0014-0A), gefolgt von allen Parametern von 11 wieder mit der ParameterID 0014-0C-nn, wobei nn einfach fortlaufend weiter nummeriert wurde und wieder die Typreferenz auf den Parametertyp von 11 (0014-0B) und dann die Parameter von 12. Hier mal repräsentative Ausschnitte:

            <Parameters>
              <Parameter Id="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_P-1" Name="StartupDelay" ParameterType="M-00FA_A-[COLOR=#FF0000]0014-0A[/COLOR]-0000_PT-DelaySeconds" Text="Anlaufzeit des Moduls nach Neustart" Value="10">
                <Memory CodeSegment="M-00FA_A-0014-0C-0000_RS-04-00000" Offset="0" BitOffset="0" />
              </Parameter>
              <Parameter Id="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_P-2" Name="Heartbeat" ParameterType="M-00FA_A-[COLOR=#FF0000]0014-0A[/COLOR]-0000_PT-DelaySeconds" Text="'In Betrieb' Signal senden (0=nicht senden)" Value="600">
                <Memory CodeSegment="M-00FA_A-0014-0C-0000_RS-04-00000" Offset="4" BitOffset="0" />
              </Parameter>
...

              <Parameter Id="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_P-[COLOR=#FF0000]43[/COLOR]" Name="StartupDelay" ParameterType="M-00FA_A-[COLOR=#FF0000]0014-0B[/COLOR]-0000_PT-DelaySeconds" Text="Anlaufzeit des Moduls nach Neustart" Value="10">
                <Memory CodeSegment="M-00FA_A-0014-0C-0000_RS-04-00000" Offset="144" BitOffset="0" />
              </Parameter>
              <Parameter Id="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_P-[COLOR=#FF0000]44[/COLOR]" Name="Heartbeat" ParameterType="M-00FA_A-[COLOR=#FF0000]0014-0B[/COLOR]-0000_PT-DelaySeconds" Text="'In Betrieb' Signal senden (0=nicht senden)" Value="600">
                <Memory CodeSegment="M-00FA_A-0014-0C-0000_RS-04-00000" Offset="148" BitOffset="0" />
              </Parameter>
...
              <Parameter Id="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_P-[COLOR=#FF0000]129[/COLOR]" Name="StartupDelay" ParameterType="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_PT-DelaySeconds" Text="Anlaufzeit des Moduls nach Neustart" Value="10">
                <Memory CodeSegment="M-00FA_A-0014-0C-0000_RS-04-00000" Offset="434" BitOffset="0" />
              </Parameter>
              <Parameter Id="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_P-[COLOR=#FF0000]130[/COLOR]" Name="Heartbeat" ParameterType="M-00FA_A-[COLOR=#FF0000]0014-0C[/COLOR]-0000_PT-DelaySeconds" Text="'In Betrieb' Signal senden (0=nicht senden)" Value="600">
                <Memory CodeSegment="M-00FA_A-0014-0C-0000_RS-04-00000" Offset="438" BitOffset="0" />
              </Parameter>

Das alles in einem xml, ohne es manuell zu editieren. Konsequenterweise wurden passend viele ParameterRef erzeugt und auch entsprechend viele ParameterRefRef... Wie gesagt, ich versuch nochmal rauszufinden, welche Editierschritte notwendig sind...

Das alles nur zur Info, ich nutze die CreateKnxProd normalerweise nicht zum editieren, sondern nur zum Signieren, insofern stört mich der Fehler jetzt nicht besonders...

Gruß, Waldemar

[mumpf]

Hi,

bezüglich dem hier (Replace Versions):

Das gleiche habe ich mich auch gefragt. Ich habe bisher immer nur die alte Version rein geschrieben. Sag bescheid, falls du heraus findest wie es geht.

Ich habe es mit mehreren Versionen (durch spaces getrennt) versucht, das funktioniert. Allerdings schreibt CreateKnxProd das nicht ins XML, da kommt bei "10 11 12" nur ein ReplaceVersions="10" im XML an.

Was ich sonst noch zur Versionierung rausgefunden habe, ist das Schema, nach dem die ETS die Versionen dezimal anzeigt, das ist etwas speziell. Die nehmen von dem Versions-Byte die beiden Nibbles und machen aus dem High-Nibble die Main-Version und aus dem Low-Nibble die Subversion. Anders gesagt:

Integer (in CreateKnxProd)	Hex (im XML)	Dezimal (in der ETS)
1	01	0.1
9	09	0.9
10	0A	0.10
15	0F	0.15
16	10	1.0
31	1F	1.15
32	20	2.0
99	63	6.3
100	64	6.4
255	FF	15.15

Die Werte bis 100 hab ich ausprobiert, die 255 ist eine Annahme. Aber somit gibt es max. 255 Versionen eines Produktes.

Gruß, Waldemar

[Klaus Gütter]

Ich habe bisher nur in der CreateKnxProd eine Möglichkeit gefunden, eine Seriennummer anzugeben. Aber eigentlich müsste ich diese doch in der Firmware vergeben, oder? Ich will ja eigentlich nur eine knxprod für mehrere Instanzen eines Gerätetyps haben (z.B. 10 Temp/Hum-Sensoren oder auch 3 Logikmodule). Müsste man nicht eine Methode zur Vergabe der Seriennummer haben? Oder - falls die Seriennummer in der knxprod eine Bedeutung hat - zumindest etwas, um einen Suffix an die Seriennummer zu hängen, um diese eindeutig zu machen?

Die SerialNumber am Hardware hat *überhaupt* nichts mit der Seriennummer des Geräts (in PID_SERIAL_NUMBER) zu tun. Blöde Namenskollision.
Und ja, wenn PID_SERIAL_NUMBER nicht eindeutig ist (pro Geräte-Instanz), passieren schlimme Dinge.

[mumpf]

Hallo Klaus,

vielen Dank für Deine wie immer kompetente und qualifizierte Antwort. Ich gebe ja zu, dass ich nicht weiß, was ich mache... aber dafür klappt es überraschend gut .
Und die Frage nach der PID_SERIAL_NUMBER muss ich gleich an thesing weitergeben: Wie wird die bestimmt bzw. ermittelt? Ich werde mal versuchen, 2 SAMD mit der gleichen Firmware zu bespielen und dann schauen, was die ETS als Seriennummer ausspuckt.

Aber wenn Du schon hier mitliest: Ich habe im Rahmen meiner Versuche, meine knxprod updatefähig zu machen (über ReplaceVersions) folgendes in der ETS hin bekommen:
ApplikationAendern.png
Dabei habe ich immer vor dem Import einer neuen V0.10 die alte immer entfernt, sowohl aus dem Projekt wie auch aus dem Produktkatalog. Technisch gesehen hatten die natürlich alle unterschiedliche Hashes, da sie ja inhaltlich nicht gleich waren. Wo wird denn das gespeichert? Ich habe versucht, den ProductStore zu löschen, auch im ProjectStore habe ich Geräte, die mehrfach mit gleicher Version drin waren, entfernt, aber die Dropdown lässt sich davon nicht beeinflussen. Hast Du eine Idee bzw. einen Tipp?

Ist nicht wirklich schlimm, da ich alle Tests in der ETS5 Demo mache, aber irgendwann will ich ja meine Produkte in meine Hauptinstallation machen, und da soll möglichst wenig "Dreck" übrig bleiben:-) Und Fehlversuche werde ich wohl nicht vermeiden können...

Gruß, Waldemar

P.S.: Seriennummer in der ETS sieht schlecht aus: 0000:00000000 - das wird wohl nicht so gut für die ETS sein, oder?

[mumpf]

Hi, ich mal wieder ,

ich habe jetzt mal eine Version von meinem Logikmodul auf den SAMD bekommen. Funktioniert soweit, derzeit noch mit 3 Logikkanälen... insofern habe ich meinen "Milestone" erreicht.

Bevor ich die Kanalzahl erhöhe und dann mit Speicherverbrauch und ähnlichem kämpfe, habe Ich mir mal DPT 9 angeschaut. Derzeit wird da nur 0 gesendet. Da ich auf dem SAMD nicht debuggen kann, hatte ich mal in float16ToPayload konstant den value auf 2127.88 gesetzt und gesehen, dass auf den Bus 2127.36 gesendet wird - das entspricht genau der Abweichung, die auch die ETS macht. Ich hab es auch mit ein paar anderen Werten versucht, aber wichtig ist, dass float16ToPayload nicht mehr das Problem ist. Es liegt nicht an der DPT zu Payload-Wandlung, sondern der Value selbst ist 0.

Jetzt ist die Frage, wie man weiter vorgeht, um rauszufinden, was da nicht stimmt. Ich bin die nächsten 3 Wochen im Urlaub und kann da nicht weiter testen. Ich wollte nur den Zwischenstand hier festhalten.

Gruß, Waldemar

[Sisamiwe]

Hallo,
ich möchte hier auch einsteigen und Erfahrung sammeln. Ziel ist ein oder mehrere direkt am KNX betriebene Temp/Hum-Sensoren.
Ich habe sowohl die Siemens BCU als auch Eugens µBCU verfügbar. Als Sensoren schwebt mir der BME280 vor.

Welches SAMD-Board könnt ihr mir empfehlen?

Adafruit ItsyBitsy M0 Express
WeMos D1 SAMD21 M0

Gibt es hier schon erfolgreiche Umsetzungen dafür? bzw. wie wäre der beste Einstieg?

Danke Euch für die Hinweise

[Klaus Gütter]

Hallo Waldemar,

noch gründlicher kannst du unbenutzte Produkte damit entfernen;
Komprimieren.jpg

Eine Seriennummer 0000:00000000 wird von der ETS ignoriert, so als ob das Gerät gar keine hätte. Bei Funktionen, für die es auch eine Version ohne Benutzung der Seriennummer gibt, also alles gut.

Gruß, Klaus

[mumpf]

Hallo Klaus,

vielen Dank!

noch gründlicher kannst du unbenutzte Produkte damit entfernen

Dann werde ich das mal versuchen und berichten, ob es in meinem Fall hilft - aber erst nach meinem Urlaub.

Gruß, Waldemar

[mumpf]

Hi Thomas,

Hat eigentlich jemand einen Geschwindigkeitszuwachs beim programmieren beobachtet? Ich hatte letztens die MAX_APDU_SIZE nach oben gesetzt.

dazu kann ich nicht wirklich was sagen, weil ich jetzt erst den SAMD zum laufen gebracht habe und unter Linux ging das schon immer "sauschnell". Aber die SAMD-Programmierung ist irgendwie anders als bei allen anderen Geräten, die ich kenne... Es wirkt so, als ob er 3 mal anfängt, zu programmieren und erst beim dritten mal klappt es. Im Gruppenmonitor sieht man auch 2 mal T_Disconnect. Es klappt alles, ich wollte nur fragen, ob das "normal" ist, beim knx-demo ist mir das nicht aufgefallen.
Ich hab auch mal die Ausgabe vom Serial-Monitor angeschaut, da kommt:

MemRef: 20002308 Mem: 20002710 Diff: 1032
MemRef: 20002308 Mem: 20003428 Diff: 4384
MemRef: 20002308 Mem: 20003408 Diff: 4352
MemRef: 20002308 Mem: 20003418 Diff: 4368
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht ...
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht ...
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht ...
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht ...
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht ...
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
got U_STATE_IND: 0x17
got U_STATE_IND: 0x17
got U_STATE_IND: 0x17
got U_STATE_IND: 0x17
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
Timeout during RX_L_DATA
restart

Wie gesagt, das programmieren klappt trotzdem.

Gruß, Waldemar

[Bernator]

"L_DATA_CON not received within expected time" kommt wenn nach dem senden eines Frames an den TPUART nicht innerhalb von 500ms ein Confirm zurück kommt...
hab aber gerade gesehen das ich das Timout schon nach dem Senden des ersten Bytes gestartet habe, das könnte bei langen Frames Probleme machen, hab das mal schnell gefixt

[mumpf]

Hi,

danke für die prompte Hilfe, ich konnte nicht umhin, es gleich auszuprobieren... ist nicht wirklich anders geworden:

[CODE]
MemRef: 20002DD8 Mem: 20003498 Diff: 1728
MemRef: 20002DD8 Mem: 20004A28 Diff: 7248
MemRef: 20002DD8 Mem: 20003460 Diff: 1672
MemRef: 20002DD8 Mem: 20003488 Diff: 1712
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
got U_STATE_IND: 0x17
... 19 Wiederholungen gelöscht
got U_STATE_IND: 0x17
L_DATA_CON not received within expected time
restart
[CODE]

Der Timeout am Ende ist weg... sonst sieht es sehr ähnlich aus. Da alles funktioniert, finde ich das jetzt nicht schlimm, wollte nur Feedback geben. Ich verwende übrigens die microBCU von Eugenius, falls das wichtig ist.

Gruß und Danke,
Waldemar