ESP8266 KNX mit ETS

[mumpf]

Hi Thomas,

Da sich noch niemand beschwert hat, scheint mein letztes Update gut gegangen zu sein.

ich habe ehrlich gesagt noch nicht die neueste Version verwendet. Ich wollte noch vor meinem Urlaub alles auf den SAMD bringen und neue Probleme vermeiden, sorry.

In der GUI kann man zu ReplacesVersions glaub ich nur eine Zahl zuweisen

Ich hatte das nur erwähnt, weil Du mal geschrieben hast, ich sollte Dir bescheid geben, wenn ich herausgefunden habe, wie man mehrere Versionen im XML angibt.

Bernator : Ich habe in Deinem Coding gesehen, dass es #ifdef für NCN5120 gibt... ich habe den aber gar nicht gesetzt. Könnte es daran liegen?

Gruß, Waldemar

[thesing]

Hallo allerseits,

mumpf CreateKnxProd erweitere ich immer je nach Bedarf. In der GUI kann man zu ReplacesVersions glaub ich nur eine Zahl zuweisen. Für mich reicht das bisher.
Die Seriennummer setzt sich aus DeviceObject::manufacturerId und DeviceObject::bauNumber zusammen. Beides kann man auch über die KnxFacade setzen.

Sisamiwe Ich habe so ein Wemos Board (das in Wirklichkeit gar nicht von Wemos ist). Sollte aber egal sein welches du nimmst.

Da sich noch niemand beschwert hat, scheint mein letztes Update gut gegangen zu sein.

[mumpf]

Hi,

ich weiß nicht, ob knx.configured() false liefert, während programmiert wird (hoffe es aber). Bei dem obigen log ging es aber um die Erstprogrammierung, wodurch meine Logik sowieso nicht durchlaufen wurde. Und ich mach im loop() normalerweise nur ein for von 1 bis 50 in dem ein if ist... das kann nicht so viel Zeit kosten.

Ich bin gerne bereit, weiter zu analysieren, aber ich bin heute in den Urlaub los und kann erst in 3 Wochen wieder an meinem Modul weiterarbeiten.

Danke und Gruß, Waldemar

[Masifi]

Eventuell wird knx.loop nicht schnell genug aufgerufen und das übertragen der Bytes dauert dem Chip zu lange?

Bei Konnekting wird bei einem Programmier-Vorgang durch die loop so eingeschränkt, das immer nur die Funktion knx.loop(); aufgerufen wird.

macht das die Funktion auch:

// only run the application code if the device was configured with ETS
    if (!knx.configured())
return;

Wenn das der Fall ist, dann kann ich mir beim besten Willen nicht vorstellen, dass ein SAMD21 zu lange dafür braucht. Außer ihr macht ganz wilde Sachen in knx.loop().

Und auch die Datenübertragung der Bytes zum Chip geht schnell genug. Man stellt die UART Geschwindigkeit (z.B. 9600 Baud) zwischen SAMD und NCN ja fest ein, dann muss der NCN auch damit klarkommen.

[Bernator]

hmm U_State.ind 0x17 meldet der TPUART bzw NCN zurück wenn das Frame welches vom SAMD kommend auf den Bus gesendet werden soll nicht stimmt (CRC bzw. Protokollfehler)
Ich glaube hier gibt es keinen Unterschied zwischen TPUART und NCN, sollte also eigentlich passen....
Eventuell wird knx.loop nicht schnell genug aufgerufen und das übertragen der Bytes dauert dem Chip zu lange?

[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

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

[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

[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

[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

[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

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

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

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