ARDUINO am KNX

[tuxedo]

In den Heise-Kommentaren hat einer einen Link gepostet. Ob's allerdings DAS Display ist weiß ich nicht.

http://www.buydisplay.com/default/se...nch-very-small
l-oled-display-module-64x48-ssd1306

Weiteres Zitat: "Das ist ein Visionox M00830_VGM064048A, erhältlich bei GLYN.de."

http://www.glyn.de/Produkte/Displays...VGM064048A0B01

"Life time min 10khrs, solder type"

https://www.glynshop.com/erp/owweb/D...20-%20GLYN.pdf

[dreamy1]

80mW sind schonmal super, aber 10kh sind jetzt nicht gerade viel. Und 10kh bedeuten nur noch halbe Helligkeit...dafür dürfte der Spaß viel zu teuer sein. Das von mir verwendete 160x128 SPI TFT in Farbe (!) kostet nackig beim Onkel Won noch keine 2€.

[swiss]

Der Arduino mit Micro OLED Touchedisplay den heisse vorstellt ist doch der aus dem Kickstarterprojekt, dass noch 21 Tage Geldgeber/Besteller sucht bevor die Produktion überhaubt beginnen kann...

https://www.kickstarter.com/projects...?ref=discovery

[dreamy1]

Mal was anderes:

Gibt es eigentlich eine Begrenzung, auf wieviel GA's der KNX-Arduino "hören" kann?

Irgendwo habe ich eine Begrenzung im Code im Hinterkopf...aber wenn ich es richtig verstanden habe, hört der Racker doch eh ALLE Telegramme am Bus mit, oder? Das würde ja keine fixe Begrenzung rechtfertigen...

Hintergrund ist eine Anwendung, bei der so um die 200 GAs "verwertet" werden müssen...

[wintermute]

Gibt es eigentlich eine Begrenzung, auf wieviel GA's der KNX-Arduino "hören" kann?

Irgendwo habe ich eine Begrenzung im Code im Hinterkopf...aber wenn ich es richtig verstanden habe, hört der Racker doch eh ALLE Telegramme am Bus mit, oder? Das würde ja keine fixe Begrenzung rechtfertigen...

Hintergrund ist eine Anwendung, bei der so um die 200 GAs "verwertet" werden müssen...

15 sind momentan in der KnxTpUart.h "vercodet" - zumindest in der Theorie spricht nix dagegen das aufzupusten, solange die Ressourcen das mitmachen.
Im Prinzip so wie bei jedem Bus-System, Ethernet zB: es kommt zwar alles an, aber das meiste wird einfach ignoriert um das System zu entspannen. Soll generell auf alles reagiert werden muesste man den Code anpassen - zZ isses halt so, dass die Lib einem die Arbeit abnimmt zu entscheiden ob ein bestimmtes Paket von Interesse ist oder nicht...

Wenn man fragen darf: für welchen Anwendungsfall soll er auf 200 GAs hoeren? Ich denke nicht, dass der zugehoerige Code in den Speicher passen wird - aber Versuch macht kluch

gruesse :: Michael

[JuMi2006]

Also beim kurzen überfliegen des Codes macht es m.M.n. keinen Unterschied ob man die Telegramme in der Library oder im Programm filtert.
Was aber übrigens nicht klappt ist mehrere Telegramme ohne ein delay (oder ähnliches) hintereinander zu versenden. Ich glaube bei 50ms war da die Grenze was dann 20 Telegrammen pro Sekunde entspricht ... sollte ausreichen.

[dreamy1]

Danke Euch für Eure Einschätzung!

Hintergrund meiner Frage: ich möchte gerne ein kleines Interface bauen, um mein Multiroom-Equipment direkt an KNX anzubinden...also ein intelligentes RS232-KNX-Interface. Da kommt einiges an GAs zusammen, wobei 200 vielleicht am Ende etwas hoch gegriffen ist.

[wintermute]

Also beim kurzen überfliegen des Codes macht es m.M.n. keinen Unterschied ob man die Telegramme in der Library oder im Programm filtert.
Was aber übrigens nicht klappt ist mehrere Telegramme ohne ein delay (oder ähnliches) hintereinander zu versenden. Ich glaube bei 50ms war da die Grenze was dann 20 Telegrammen pro Sekunde entspricht ... sollte ausreichen.

Noe, das macht auch nicht wirklich einen Unterschied, in die Telegramme reingucken muss man ja eh (irgendwann zumindest).
Im uebrigen ist die Einschraenkung momentan scheinbar nur "soda" - das einzige was sie macht ist das Hoeren auf weitere GAs zu unterbinden und in dem Fall eine Debug-Meldung auszugeben. Es spricht also erstmal nix dagegen - wie geschrieben - das einfach auf 200 zu setzen und zu schauen ob die Ressourcen reichen...

Was das delay angeht: haelst du es fuer sinnvoll ein delay(50) (oder vllt etwas mehr) nach dem Senden eines Paketes fest in der Lib zu vercoden?

gruesse :: Michael

[NetFritz]

Hallo

Im Photovoltaik Forum hat jemand den SDM630M-DC 3Phasen Messgerät/Stromzähler mit dem Arduino verbunden.
Wenn man den Arduino dann mit KNX verbindet hat man einen günstigen KNX-Stromzähler.

SDM630M-DC - 3 Phasen Messgerät/Stromzähler? Photovoltaikforum

Gruß NetFritz

[JuMi2006]

Was das delay angeht: haelst du es fuer sinnvoll ein delay(50) (oder vllt etwas mehr) nach dem Senden eines Paketes fest in der Lib zu vercoden?

gruesse :: Michael

Sicherlich, da besteht noch einiger Optimierungsbedarf um später einfachen Code damit zu schreiben. Gerade der Umgang mit den GAs ist nicht glücklich gelöst und ein anständiges mapping von Datentypen und Funktionen wäre durchaus hilfreich ... Zeit müsste man haben .

[dreamy1]

Was das delay angeht: haelst du es fuer sinnvoll ein delay(50) (oder vllt etwas mehr) nach dem Senden eines Paketes fest in der Lib zu vercoden?

Das schaue ich mir auch nochmal an. Ein reines "delay" in Arduino-Sprache darf das aber keinesfalls sein, da der Kleine in der Zeit einfach pennt und gar nix mehr macht...ich glaube sogar, das da auch keine Interrupts mehr verarbeitet werden.

Ich arbeite dazu immer mit folgenden Programmschnipseln, die ohne Pennphasen auskommen:

unsigned long currentMillis = millis();
if(currentMillis - previousMillis > interval)
{
previousMillis = currentMillis;
...und jetzt kommt die auszuführende Aktion
}

[wintermute]

Das schaue ich mir auch nochmal an. Ein reines "delay" in Arduino-Sprache darf das aber keinesfalls sein, da der Kleine in der Zeit einfach pennt und gar nix mehr macht...ich glaube sogar, das da auch keine Interrupts mehr verarbeitet werden.
...

Interrupts werden waehrend eines delay weiterhin verarbeitet - allerdings wird zB die serielle nicht mehr gepollt...
Dein Schnipsel macht Sinn innerhalb der loop-Routine, aber hier geht es eher darum, dass innerhalb der Lib nach dem Senden auf den seriellen Bus kurz gewartet wird. Sowas ohne delay zu realisieren wird extremst aufwaendig und fuehrt vermutlich dazu, dass die ganze Lib umgebastelt werden muss.

Ausgehend davon, dass es eher fuer "kleinere Basteleien" Gebrauch findet, wuerde ich es persoenlich schon sinnreich finden den delay zu verbasteln. Wer eine "Echtzeit-Anwendung" braucht wird mit der aktuellen Loesung eh nicht gluecklich und muss ohnehin was eigenes bauen; der Gedanke dahinter ist eher der - wie bei Arduinos ueblich - schnell was laufendes zu bekommen ohne sich viel Gedanken ueber den Background machen zu muessen.

Abgesehen davon: ich denke die 50ms nach jedem gesendeten Paket bremsen die Sache nicht wirklich aus. Aber ich machs im Header-File konfigurierbar, dann kann es jeder so anpassen wie er mag

beste Gruesse :: Michael

[Catter]

Fze1065

Hallo Leute,
Ich bin sehr interressiert an diesem Projekt und bin selbst schon beim rumbasteln.
Habe heute einen Jung Busankoppler zerlegt um zu sehen welcher Chip verwendet wird.
Hat sich schon mal jemand mit dem FZE1065 bzw FZE1066 beschäftigt?
In der Beschreibung HIER steht, dass er ein bit-Interface zum KNX-Bus hat.
Kann mir jemand erleutern was genau das bedeutet? und gibt es vielleicht eine Möglichkeit den Arduino mit ihm sprechen zu lassen?
Interressant wäre auch die Belegung der AST von Jung Busankopplern.
So wäre es möglich fast jeden Busankoppler für den Arduino zu verwenden

[NetFritz]

Hallo

@Catter
Interressant wäre auch die Belegung der AST von Jung Busankopplern.
So wäre es möglich fast jeden Busankoppler für den Arduino zu verwenden

Wenn Du diesen Thread durchgelesenen hättest, gleich im 1. Beitrag steht schon was dazu.
Die AST Schnitstelle mit dem Rechner zu verbinden ist ein alter Hut.
Siehe auch hier.my EIB projects
Gruß NetFritz

[l0wside]

Abgesehen davon: ich denke die 50ms nach jedem gesendeten Paket bremsen die Sache nicht wirklich aus. Aber ich machs im Header-File konfigurierbar, dann kann es jeder so anpassen wie er mag

Ich habe bei mir grade mal im Busmonitor nachgeschaut. Wenn der KNX-Multisensor zwei Frames direkt nacheinander schickt (was über einen Puffer geschieht, so dass die Verzögerung und der Einfluss auf den Programmablauf minimal sind), dann ist der Abstand zwischen zwei Frames rund 50ms. Passt also.

Max