ARDUINO am KNX

[bernji]

Edit:
Verstehe. Ich benutze ein e-ink display um die KNX-Werte anzuzeigen. Ich aktualisiere das Display alle 3 Minuten.
Dieser eine Durchlauf der loop Methode dauert ein bisschen länger (weil e-inks nun mal leider langsam updaten).
Die restlichen Durchläufe der loop sind aber sehr schnell, weil nur da nichts wesentliches gemacht wird (ich überprüfe ob 3 min vergangen sind durch 1x millis() und ein if)

Trotzdem sehe ich manche Werte einfach trotzdem nicht. Es gibt 2 Werte die gleichezitig alle 30 Sekunden geupdated werden. Werte sehe ich meistens nur bei einem. Der Andere ist meistens "0". Welcher von beiden den Wert bekommt ist mehr oder weniger Random.

Klar kann es sein, dass ich in dem längeren Loop Durchlauf ein paar Werte nicht bekomme. Trotzdem sollte ich in den 3 Minuten maximal 6x oder zumindest 5x Werte für die Datenpunkte bekommen

P.S. Auf meinem Bus ist viel los. Eventuell ist es trotz kurzer Loops einfach zu viel für den Buffer und da sind 99% einfach sachen drin, die durch die Lib einfach wieder verworfen werden?!

[Flole]

Siehe in der Dokumentation: https://www.arduino.cc/reference/en/...l/serialevent/

Dort steht "Called at the end of loop() when data is available.".

Je nachdem wie lange du nun im loop hängst dauert das also mal mehr und mal weniger lange. Je nachdem wie groß der Buffer nun ist passen da mal mehr und mal weniger Nachrichten rein.

Ich habe an der library noch einige Änderungen im Bezug auf die Datentypen vorgenommen (das alles mit Strings zu machen ist schon extrem unperformant), sehe das Problem bei mir aber nicht (habe aber auch einen kurzen loop).

[bernji]

Eine Frage:

Ich habe in den Examples gesehen, dass der Telegramme in der serialEvent() methode gelesen werden.
Fehlt hier nicht irgendeine Schleife, falls sich mehrere Telegramme im Buffer befinden? Oder wird serialEvent öfter aufgerufen, wenn mehrere Telegramme angekommen sind?

Ich habe eine Beobachtung gemacht: Es gibt zwei Werte, die immer zur gleichen Zeit in den Bus geschrieben werden. Ich bekomme aber immer nur eine. Meine Vermutung ist, dass die Lib immer nur den ersten Wert liefert und die Restlichen "unterschlagen" werden. Da sie gleichzeitig geschrieben werden, ist es eine racing condition und mehr oder weniger Zufall welchen Wert die Lib liefert.

Habe zusätzlich gesehen, dass die Lib von ThorstenGehrig seit 3 Jahren keinen Commit mehr hat.

netzlaff scheint das selbe Problem gehabt zu haben ARDUINO am KNX - KNX-User-Forum

[Charls]

Nein, die PA muss wohl im Busankoppler nicht programmiert werden, hab ich mir sagen lassen. Die gibst du ja im Code mit an. Ich weiß nicht, ob im Fall, dass du vom Bus Anfagen absendest, es eine Version gibt, wo du das brauchst aber eigentlich nicht.
Es gab mal bei GitHub Beispiele, wo die verschiedenen Datenflußrichtungen beschrieben waren. Die waren sehr verständlich und man gab glaube ich nur die PA im Code an und alles funktionierte.

Ich sehe gerade das sind ja die examples auf GitHup, die ich meine.

[bernji]

Danke für die Diskusionen hier. Die haben mir sehr geholfen

Eine Frage: Die PA, die ich bei der lib von ThorstenGehrig angebe. Das Busankoppler agiert dann dem Bus gegenüber als dieser Teilnehmer richtig? Den Busankoppler muss man nicht programmieren (weil die Programmierung ja quasi der Code des Arduinos macht)?

Bin nur verwirrt über diesen beispielcode, der bei der Lib beiliegt:
arduino-tpuart-knx-user-forum/LearnKNXAddress.ino at main · thorsten-gehrig/arduino-tpuart-knx-user-forum · GitHub

[Charls]

Das Ganze hat mit Rundungsfehlern nichts zu tun. Das ist eher die Genauigkeit der Hex-Werte in der Darstellung wie du oben schon selber sehen konntest in der ETS.
Ob du nun 997,08 Pa oder 997,1 Pa nimmst, es wird immer 997,12Pa heraus kommen. Das letzte Bit löst die Nachkommastelle einfach nicht genauer auf.
Kannst ja spasseshalber mal schauen ab wann auf den nächsten krummen Wert springt.

[boardman]

Hey emax , sorry! Das war wirklich nicht ernst gemeint und daher mein gescheiterter Versuch das als Ironie zu kennzeichenn, bitte nicht böse nehmen... ich entschuldige mich und nehem es zurück...

Also ich fasse zusammen:
Arduino schickt ein float mittels KNXTPUART auf den Bus, damit sind wir in der ETS Welt... dort kommt HEX an und wird mit Rundungsfehlern interpretiert...

Code:

knx.groupWrite2ByteFloat("0/0/22", adjustedpressData); // Luftdruck
in der ETS kommt

997,12 Pa

Ich hab nun endlich die ETS Doku gefunden... Hier die Definition:
http://www.knx.org/fileadmin/downloa....5.00%20AS.zip
Unbenannt.png
und damit hast du auch Recht dass es kein IEEE 754 half precision ist... da geht auch hier im Forum einiges durcheinander...

Uwe

[emax]

> Klugscheissen kann ich auch
Vielen Dank. Das wird auch durch das Alibi-Smiley nicht besser.

Oder meinst Du vielleicht das hier?
> Ich hab mich etwas in die Datentypen eingelesen und gehe nun davon aus, dass das die normalen Rundungsfehler bei IEEE 754 sind

Und
> dass wir von der ETS/EIB reden war ja klar
Ach so. Ich dachte, Du redest vom Arduino und von IEEE 754. Wo Du Dich ja eingelesen hast.

Mal kurz und knapp: Du hast gefragt und ich habe eine präzise Antwort zu Deiner (falschen) Vermutung, woher die Rundunsfehler kommen, gegeben.

Passiert mir nicht noch mal.

Viel Spaß noch.

[boardman]

Klugscheissen kann ich auch (-:
https://en.wikipedia.org/wiki/Half-p...g-point_format

man kann also durchaus auch 16 Bit mit IEEE 754 codieren...
https://en.wikipedia.org/wiki/IEEE_754-2008_revision

okay, geht erst seit 2008 und nennt sich IEEE 754r, aber dass wir von der ETS/EIB reden war ja klar und was die dort treiben kannte ich auch nicht...

[emax]

Bist du da sicher?

Ich bin nicht sicher, ich weiß es. ;-)
Kannst Du ja mal nachrechnen - oder auch hier nachrechnen lassen.

Die Genauigkeit auf dem Bus [...] ist ja ein 2 Byte float, nicht 4 Byte.

Das ist dann kein IEEE 754, wie boardman angegeben hatte. Diese Definition bezieht sich auf 32 Bit und 64 Bit Werte.

[boardman]

Hi Waldemar, das war zu einfsach... guter Trick...

[mumpf]

Die Genauigkeit auf dem Bus kann man einfach mit der ETS selber prüfen:
Sende einfach mit dem Gruppenmonitor einen Wert in DPT 9.x und schaue, welcher Wert wirklich gesendet wurde.
997.08 auf 997.12 halte ich für realistisch. Es ist ja ein 2 Byte float, nicht 4 Byte.

Gruß, Waldemar

[boardman]

Bist du da sicher? Ich gehe davon aus dass das binär codiert wird, nicht dezimal... und dann bin ich schon ziemlich weit hinter dem Komma...

[emax]

Ein Rundungsfehler von 0.08 ist unrealistisch. Das wäre eine Katastrophe.

997.08 ergibt in IEEE 754 den Wert 997.08001708984375

[boardman]

Ich hab mich etwas in die Datentypen eingelesen und gehe nun davon aus, dass das die normalen Rundungsfehler bei IEEE 754 sind... also damit leben oder mit Integer arbeiten und im HS umrechenn...