ESP8266 KNX mit ETS

[thewhobox]

Gibt ja auch noch ExtendedMemoryWrite mit 8 bit-Count (und 24 bit Adressen)

Danke für den Hinweis.
Wo finde ich den in der Spec?
Oder brauche ich da ne neuere als die von knx.org?

Grud Mike

[Klaus Gütter]

Gibt ja auch noch ExtendedMemoryWrite mit 8 bit-Count (und 24 bit Adressen)

[mumpf]

Vielen Dank Thomas,

dann werde ich damit jetzt ne Runde testen. Mal sehen, welche Seiteneffekte ich finde.

Ich würde das auch so sehen.

Wenn man für ein MemoryWrite nur 63 Bytes hat (dafür spricht auch, dass die MDT-Schnittstelle auch versucht hat, mit 63 zu schreiben, als der Stack noch 250 (genaue Zahl weiß ich nicht mehr) als APDU-Länge zurückgegeben hat), dann lohnt sich aber nicht wirklich, hier weiter zu forschen, ob man beim SAMD mehr als die 53 Bytes, die derzeit gehen, durch vergrößern des seriellen Puffers oder ähnlichem erreicht. Denn man würde wohl maximal 10 Bytes mehr pro Paket bekommen.

Gruß, Waldemar

[thesing]

mumpf Klingt gut. Laut Spezification "may" ein Gerät auf ein Read antworten.

thewhobox Ich würde das auch so sehen. Bei UserMemoryWrite hat man sogar noch ein Bit weniger. Dafür aber mehr Platz für die Adresse.

[mumpf]

Hi Mike,

Aber mit iwas solltest auf jeden Fall antworten^^

meine Idee ist, so zu tun, als wenn das L-Flag nicht gesetzt wäre. Ich hab es mal mit dem Busmonitor getestet, ein KO von einem offiziellen Gerät zu lesen, wenn da kein L-Flag gesetzt ist. Es kommt ein ACK, aber kein GroupValueResponse. Genau das will ich. Und es ist - glaube ich - die beste Lösung im Sinne der Buskommunikation.

Die Frage ist, ob es das Richtige ist, ein von der ETS gesetztes Flag eine Zeit lang nicht zu beachten.

Zu Deinem anderen Problem kann ich Dir leider nichts sagen, so tief bin ich in die Kommunikation noch nicht "herabgestiegen".

Gruß, Waldemar

[thewhobox]

Sollte ein GroupValueResponse auf ein GroupValueRead überhaupt gesendet werden, wenn noch kein Wert vorliegt, somit der gesendete Wert ganz sicher inkorrekt ist?

Also ich wäre immer noch für die Rückmeldung Busy.
Wenn du ne normale GroupValueResponse schickst wird der Wert ja wieder geloggt, der nicht korrekt ist.
Wenn du nicht antwortest, wird das Telegramm nur unnötig wiederholt.
Wenn du ein Nack schickst wird es glaub auch erneut probiert.

Eine andere Art zu antworten fällt mir gerade nicht ein.
Aber mit iwas solltest auf jeden Fall antworten^^

---

Ich beschäftige mich gerade mit einem anderen Thema bei dem ich nicht weiter komme, bzw vll nen Denkfehler habe.
Ich bin grad dran den Extended Frame einzubauen...
Sind ja theoretisch maximal 252 Bytes circa für das Telegramm (eig 254 Bytes, aber 2 Bytes gehen für APCI und TPCI drauf).
Wenn ich jetzt einen MemoryWrite machen möchte verwende ich ja folgendes:
Screenshot 2021-04-25 200804.png
Hier kann ich ja bei "number" (was die Länge angibt) maximal 63 eintragen.
Hat ein MemoryWrite ein Limit von 63 Bytes?
Oder übersehe ich da was?


Gruß Mike

[mumpf]

Aber ich stöber mal im Stack.

So, ich habe einen Weg gefunden, der ein KO auch nicht größer macht - bin mir nur nicht sicher, wie "Sauber" das ist. Ich habe beim GroupObject ein neues commFlag New eingeführt, das jetzt beim GroupObject::readEnable() abgefragt wird. Solange das commFlag auf New steht, ist readEnable() immer false. Bei GroupObject::valueNoSend() wird dann das commFlag auf Ok gesetzt. Wenn man bei der Initialisierung dafür sorgt, dass alle KO ihren Startwert mit value() oder valueNoSend() gesetzt bekommen, funktioniert das zuverlässig, soweit ich das sehen konnte. Aber ich habe natürlich schon ein paar Stellen gefunden, die ich nicht richtig initialisiere . Aber das ist ja ein lösbares Problem.

Die allgemeine Frage ist eher: Sollte ein GroupValueResponse auf ein GroupValueRead überhaupt gesendet werden, wenn noch kein Wert vorliegt, somit der gesendete Wert ganz sicher inkorrekt ist?

Gruß, Waldemar

[mumpf]

Hi Mike,

Der NCN sendet dann für alle Ankommenden Requests ein NACK Busy zurück.

kenne ich. Ich könnte den auch einschalten... Das Problem hier wäre, dass das nur im Auto-ACK Modus funktioniert und damit für ALLE Telegramme ein Busy senden würde. Ich würde also für diese Zeit den Bus lahmlegen. Und wenn es in der Zeit einen Hänger geben sollte, dann würde der Modus ja nicht aufgehoben werden. Und ich will ja durchaus, dass das Modul seine Werte senden kann, ich will nur nicht, dass es zu früh antwortet.

Aber ich stöber mal im Stack. Vielleicht kann ich ja wirklich noch ne Methode ergänzen, die zur Laufzeit mal das L-Flag am KO deaktiviert udn ich aktiviere es wieder, sobald das erste Mal ein Wert reingeschrieben wurde. Oder ich baue in meinen Fork standardmäßig ein, dass ein von der ETS vergebenes L-Flag nur dann beachtet wird, wenn das KO gültige Werte hat. Muss mal ein bisschen debuggen...

Gruß, Waldemar

[thewhobox]

Hallo Waldemar.

Hab mir den Stack nicht angeschaut, aber eine Idee wäre es das Gerät in eine Art Busy-Mode zu stecken.
Der NCN sendet dann für alle Ankommenden Requests ein NACK Busy zurück.
Sie Datenblatt (Anhang) auf Seite 31.

Wenn du dann alle Werte hast, setzt den Busy Mode wieder auf False und Anfragen werden normal beantwortet.

Inwieweit das der Stack implementiert hat weiß ich aber wie gesagt nicht.


Gruß Mike

[mumpf]

Ich hab noch eine Frage an die Leute, die sich im Stack auskennen: Kann ich irgendwie die Antwort auf einen ReadRequest eine Zeit lang verhindern?

Folgende Situation: Beim Startup meines Sensormoduls ist der KNX-Stack immer das Erste, was "Up" ist, und ich möchte auch, dass beim Startup Sensorwerte initial gesendet werden, sobald sie bekannt sind. Ich möchte natürlich auch, dass Sensorwerte beliebig gelesen werden können, deswegen haben die entsprechenden KO auch immer das L-Flag gesetzt.

Jetzt sind bestimmte Teile der Applikation erst nach ca. 2 Sekunden "da" (bei 1-Wire dauert es so lange, bis ich die ersten Sensorwerte habe). Wenn diese Sensorwerte beim Startup per ReadRequest angefragt werden, liefern sie 0, da das KO intern noch gar nicht beschrieben wurde, der KNX-Stack aber den ReadRequest beantwortet.

Abstrakt formuliert: Ich möchte, dass das L-Flag an einem KO erst funktioniert, nachdem sicher ist, dass das KO auch korrekt antworten kann, also mit einem nicht-initialen Wert.

Beispiel:

• Modul startet, KO1 liefert normalerweise Tempeartur, Temperatursensor braucht 2 Sekunden für Startup
• nach 1 Sekunde macht die Visu (warum auch immer) einen ReadRequest auf KO1
• Modul sendet ein 0°C als Response
• nach 2 Sekunden liefert der Temperatursensor einen Wert, KO1 sendet 22.5°C auf den Bus

Ich habe dann 1 Sekunde lang einen falschen Wert auf dem Bus, das möchte ich verhindern. Hört sich kurz an, aber in Logs/Diagrammen sieht so was immer "falsch" aus. Und ich möchte eigentlich das Lesen von nicht definierten Werten verhindern.

Gruß, Waldemar

[mumpf]

Hi Michael,

danke für den ausführlichen Bericht. Stellt sich (leider) so dar, wie ich es befürchtet habe - als zu energiehungrig. Ich bin eben mit Hardware nicht so erfahren, dass ich das bewerten kann, aber die Hardware soll ja auch nicht beliebig teuer werden.

Viel Erfolg noch,
Waldemar

[keil]

Hallo Waldemar (und alle Interessenten),

Aber interessieren würde es mich schon, wie Du das machst. BT low power kann ich mir noch vom Bus vorstellen, aber WLAN nicht mehr...

ich kann es mir nach wie vor über WLAN vorstellen, allerdings werde ich das erst mal nicht weiter verfolgen.

Ich will hier nicht zu offtopic werden, aber eventuell interessieren die Messungen ja doch den einen oder anderen.
Wie die Softwareseite aussieht habe ich ja zwei Posts drüber beschrieben (https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1216828-esp8266-knx-mit-ets?p=1643328#post1643328)

Hardwaremäßig hatte das

• sowohl über USB vom Laptop aus,
• als auch vom Netzteil über 5 V in den Step Down Wandler auf dem Nano 33 IoT,
• oder aber direkt vom Netzteil in das 3.3 V Potential eingespeist

eigentlich ziemlich gut funktioniert (halbwegs vernünftiger WLAN-Empfang vorausgesetzt).

An der MicroBCU 2 (NCN5120) ging dann aber leider nichts mehr. Die Stromaufnahme ist zwar nur kurzzeitig zu hoch, aber das reicht leider aus um die Spannung soweit einbrechen zu lassen, dass es den Controller resettet.


Hier ein paar Scope-Aufnahmen mit folgenden Hinweisen:

• Zeitbasis: 2 s / Div
• gelb = Spannung (meist 2 V / Div, Ausnahme bei 20 V Versorgung, dann 5 V / Div)
• blau = Strom (immer 50 mA / Div, 1 mV -> 1 mA)
• die einzelnen Funktionen wurden künstlich verlängert, um das im Oszi besser zu sehen
• die Dauer für das Herunterladen der Firmware und das Kopieren vom WiFi Chip war immer irgendwo zwischen 0.5 s und 2 s
• die Firmware war im Prinzip ein "Blink" Beispiel mit der SNU-Update Funktionalität sowie vielen Debug-Ausgaben, insgesamt 36 kB

Hier mal exemplarisch mit einem Netzteil welches direkt in das 3.3 V Potential des Nano 33 IoT einspeist:

tekway29_6_commented.gif

Der Ablauf ist:

1. Anlagen der Spannung (hier 3.3 V) und der SAMD Chip ist in der "setup()"-Funktion, der WiFi Chip wird auch gestartet, nach kurzer Zeit aber wieder in den Reset-Zustand versetzt (Stromaufnahme = 0 mA)
2. Der SAMD geht in die "loop()" Funktion über (LED blinkt mit 0.25 Hz -> 2 s an, 2 s aus)
3. Das Firmwareupdate wird gestartet (dazu wird der Reset des WiFi Chip aufgehoben und ein Verbindungsversuch zum WLAN unternommen (per DHCP minimal 1.2 Sekunden, mit fester IP geht das schneller), die Stromaufnahme liegt (die Peak ausgenommen) Anfangs bei ca. 135 mA, danach bei ca. 120 mA
4. Die Firmware wird per http von einem Raspberry Pi in den Speicher des WiFi Chip heruntergeladen, die Stromaufnahme liegt (ebenfalls Peak ausgenommen) bei ca. 145 mA, geht dann auf ca. 120 mA zurück
5. Die WLAN Verbindung wird getrennt -> knapp über 50 mA
6. Die "WiFi.end()" Methode wird aufgerufen und das Kopieren der Firmware vom WiFi Chip in den SAMD gestartet
7. Das WiFi Modul wird über ein Low am Reset-Eingang in den Reset-Zustand versetzt (-> keine Stromaufnahme mehr)
8. Ein automatischer Reset des SAMD führt dazu, dass auch der WiFi Chip resettet wird
9. Der WiFi Chip wird wieder in den Reset-Zustand gebracht und die LED blinkt durch die neue Firmware mit 0.5 Hz -> 1 s an, 1 s aus)

Hier das ganze nochmal mit 5 V aus dem Netzteil (links) und 21 V (rechts, dazu hätte ich VFILT oder den V20V Ausgang des NCN2150 genommen, aber die Stromaufnahme geht leider nicht weit genug runter):

tekway29_7.gif tekway29_8.gif

Hier mit aktiviertem "LowPowerMode" des WiFi Chips (die Stromaufnahme während dem Aufbau der Verbindung sowie dem Download des Firmware bleibt gleich, zwischendrin geht sie aber deutlich runter).

tekway29_9.gif tekway29_10.gif

Und hier das eigentliche Problem: links (wie bei allen bisherigen Aufnahmen auch) aus dem Netzteil versorgt, rechts aus dem 5 V Ausgang des NCN5120:

tekway29_13.gif tekway29_15.gif

Den Stromanstieg beim Verbindungsversuch mit dem WLAN von ca. 70 mA auf knapp 170 mA macht der DCDC-Wandler des NCN5120 sehr kurz mit, dann aber ist die Spannung soweit eingebrochen, dass es zum Reset kommt.

Die Zeit, welche hier die Stromaufnahme zwischen den sicher geltenden 100 mA des NCN5120 und dem Maximalstrom von knapp 170 mA bei 5 V Versorgungsspannung liegt ist nicht sehr lang (der Peak ganz am Anfang auf 170 mA sind weniger als 40 ms), aber es reicht halt ohne zusätzliche Komponenten nicht aus.


Wenn man das weiter verfolgen wollte, würde ich mit einem großen Elko und/oder Goldcap (alternativ ganz kleiner Akku) versuchen, für die Zeitdauer des WLAN-Verbindungsversuchs und des Downloads die benötigte Energie bereitzustellen.

Allerdings wären das dann immer "gesondert zu behandelnde" Geräte mit extra Hardware, und eigentlich will man sowas nicht unbedingt haben, sondern am besten sollten alle Geräte eine Firmwarupdatemöglichkeit von Haus aus bieten.


Viele Grüße,
Michael

[Sisamiwe]

Hallo,

ich würde den Stack bzw. die Firmware für das Raumsensormodul mumpf nutzen mit einer microBCU2 und einem Seeeduino XIAO (mit SAMD21) nutzen.
Der SAMD wird aus der BCU2 versorgen, RX und TX sind mit Pin 6 und 7 (Serial1) verbunden. Die Debug-ausgabe auf Serial 1 lautet "ERROR, TPUART not responding"

Sowohl der SAMD21 als auch die µBCU2 sind funktionsfähig. Ein einem einfach Sketch mit dem knxtpuart funktioniert die Kommunikation

Kennt jemand den Fehler bzw lässt sich der Fehler einkreisen?
Bin für jeden Hinweis dankbar.

Beste Grüße

[keil]

Wie machst Du Dein OTA?

Hallo Waldemar,

ich wollte es eigentlich noch direkt vom Bus versorgt testen, hänge hier aber noch. Daher erst mal die Antwort zum OTA Update:

Ich verwende einen Arduino Nano 33 IoT (SAMD21 + NINA W102 per SPI angebunden): Greenshot 2021-04-14 21.18.39.png


Die Möglichkeit die Du nennst (also unter Nutzung des internen Flash Speichers) funktioniert natürlich, allerdings hat man dann wie auch von Dir erwähnt etwas weniger als die Hälfte des Flashs zum Zwischenspeichern des Binaries zur Verfügung. Das klappt zum Beispiel mit der ArduinoOTA Bibliothek gut: https://github.com/jandrassy/ArduinoOTA

Für den SAMD gibt es aber noch bessere Wege für ein OTA Update (Quellen und Beispiele sind im Core für den SAMD enthalten, siehe: https://github.com/arduino/ArduinoCo...ster/libraries). Für den Nano 33 IoT kommen folgende Möglichkeiten in Frage

• SDU: Update von einer SD-Karte (die ist nicht auf dem Board drauf sondern müsste extern angeschlossen werden)
• SFU: Update über einen externen Flash (z.B. auf dem MKR MEM Shield, also auch noch eine weitere Komponenten nötig)
• SNU: Update über den Flash-Speicher des NINA W102 (der ist ja eh verbaut -> keine weiteren Komponenten nötig)

Ich plane die Nutzung der SNU Bibliothek (habe das aber wie gesagt noch nicht direkt mit dem knx-Stack getestet). Ein Beispiel für die Nutzung findest Du hier: https://github.com/arduino/ArduinoCo...sage/Usage.ino

Erwähnenswerte Features:

• Den Update-Vorgang kann man direkt vom SAMD21 aus (also z.B. über einen externen Taster) oder aber auch (zumindest theoretisch, getestet habe ich es noch nicht) über KNX starten -> es wird für das Update keine IDE oder ein Rechner, sondern nur die einmalig exportierte Binärdatei benötigt
• Das WiFi Modul muss nur für das Update eingeschaltet werden und kann danach wieder deaktiviert werden -> spart Strom (die genaue Stromaufnahme muss ich nochmal messen, während des Updates sind es für das ganze Board etwa 100 mA bei 5 V... das könnte knapp werden rein über KNX)
• Die Binärdatei lädt der SAMD21 über das WiFi Modul in dessen Speicher von einer beliebigen URL via HTTP (das funktioniert mit jedem Server, NAS, Raspberry Pi, o.ä.):
  

  WiFiStorage.download("http://192.168.0.123/OTA/Blink.bin", "UPDATE.BIN");

• Der Update-Vorgang vom WiFi Modul in den SAMD21 wird mit folgender Zeile gestartet:
  

  WiFiStorageFile update = WiFiStorage.open("/fs/UPDATE.BIN");

• Danach ist nur noch ein Reboot nötig, das wars. Das Ganze benötigt zusätzlich etwa 20 kB Flash und 300 Byte RAM

Falls das mit der Versorgung über den Bus doch irgendwie klappen sollte, könntest Du so ein ESP32 Modul evtl. mit der WiFiNINA Firmware flashen und per SPI an Deine KNX-Hardware dranhängen.


Viele Grüße,
Michael

[thewhobox]

Interessanter Thread.
Ich hab mir mal die Applikation von dem Zennio angeschaut und da ist die Firmware auch drin.

<RelativeSegment Id="M-0071_A-51A1-26-E6AC_RS-04-00000" Name="Parameters+APP" Size="565536" LoadStateMachine="4" Offset="0">
<Data>VQYHAM0HBwCRCg...</Data>
<Mask>...</Mask>
</RelativeSegment>

Wie genau die LoadProzedure das nochmalige übertragen der APP verstehe ich noch nicht ganz.
Werde mir das morgen mal weiter anshauen.
Aber schon mal danke für den Denkanstoß.


Gruß Mike