DMX-Gateway

[tuxedo]

In welchem Anwendungsfall braucht man mehr als einen UART?

Drei unterschiedliche Geräte in ein Gerät stecken, nur weil der µC mehrere UARTs beherrscht: Wäre absolut nicht mein Fall. Separation of Concerns ist da mein Devise.

Die Nachfrage geht ja immer weiter weg von "universllen, eierlegenden wollmilchsäuen", hin zur "fertigen Lösung".

Folgende Anwendungsfälle kommen mir in den Sinn (sofern man S-o-C in Betracht zieht):

* Modbus: Ich hab 1..n Modbus-fähige Zähler im Verteiler und möchte diese auslesen... Modbus sagt's ja schon: Bus... ich kann die alle an einen Bus hängen --> Ein UART
* Ich habe ein 3rd-Party RS485 Bus-System das ich anbinden möchte: Wieder Bus... Ein UART.
* Ich habe DMX im Haus und möchte das anbinden: DMX macht 512 Kanäle ohne mit der Wimper zu zucken. Da reicht eigtl auch ein UART
* Ich habe eine XYZ-Steuerung (Heizung, Lüftung, ...) die einen RS232 Schnittstelle hat: Da reicht ein UART wenn man S-o-C berücksichtigt. Man wird ja eher weniger mehrere RS232 Geräte haben die alle das gleiche Protokoll sprechen?!

RS422 ... hatte ich noch keinen Bedarf für, bzw. hatte noch kein Gerät zwischen den Fingern das RS422 macht. Ganz im Gegensatz zu RS485.

Kurzum: Mir fällt fast kein Szenario ein wo ich tatsächlich mehr als einen UART bräuchte. Bedenke auch, dass die Anzahl an KOs aktuell nicht beliebig ist. Aktueller Stand sind 85 KOs... Bei noch mehr KOs wird's auch für den µC aufwendig bei jedem eingehenden Telegramm die eingehende GA mit allen 276453784 KOs im Gerät abzugleichen und so das passende KO zu finden.

Das Argument von wegen "Kosten sparen durch mehr UARTs pro Gerät, so dass ich nicht 3 Geräte brauche" zieht für mich aktuell nicht.

Wenn ich das grob überschlage, kommt man mit <=50EUR Materialkosten "locker" hin für ein 2TE Gerät mit einem UART (aber variabler bestückung: rs485, rs232 oder rs422 oder dmx(auch rs485)). Klar, zwei weitere UARTs reinpacken würde die Kosten nicht deutlich nach oben treiben. Aber: KISS Prinzip. Ein Gerät, ein UART (mit variabler bestückung), eine Auswahl an Standardsketches (DMX Gateway, Modbus-Zähler Auswertung, Diverse Lüftungsanlagen Steuerung. Diverse Heizungsanlagen Steuerung) und fertig ist das "modulare Projekt". Ein Gerät, viele Anwendungen, großer Einsatzbereich --> Keine Mini-Stückzahlen.

Ich werde dich nicht aufhalten ein Gerät mit vielen UARTs zu basteln, aber solange du da keinen plausiblen Anwendungsfall lieferst der für den 80% Markt zutrifft (also nicht nur eine Nische bedient), sehe ich da keinen Bedarf für ein für den User aufwendiges Gerät das in mehr als 9 von 10 Fällen nur mit einem UART betrieben wird.

[Ing-Dom]

Ich hab jetzt auch keinen Anwendungsfall, bei dem man zwangsläufig mehr als ein UART pro Gerät braucht.

Mehr als ein UART, um Einbauplatz und Kosten zu sparen. Unter der Prämisse, dass sich die HW sowieso langweilt.

Wenn 85 KO die Grenze ist, ist das eigentlich schon wieder hinfällig - selbst bei einem 2-Channel DMX-Gateway würde ich mit 85 KO nicht auskommen.

Ich mach hier sicher keine Alleingänge. Erstens fehlt mir dazu sowieso das HW-Know-How, zum Anderen leben OSS-Projekte von der Zusammenarbeit, und Zerbrechen leider auch viel zu schnell daran.

Insofern: Let's go for 1x RS485/232

[tuxedo]

Ich versuche die 85KO Grenze zu strecken. Wird mit Beta5 kommen. Aber 512KOs werden's nicht werden.

Hast du mal geschaut wie andere KNX-DMX Gateways das machen?

Die HW langweilt sich eigtl nie... Es muss im 400µs Takt nach neuen Bytes von neuen KNX Telegrammen geschaut werden, und zwar AKTIV. Ich habs noch nicht ausgerechnet oder ausprobiert, aber mehr als 10ms sollte man zwischen zwei "Knx.task()" aufrufen im Code nicht haben, sonst riskiert man einen Telegrammverlust.

Bei 3 UARTs und verschiedenen Anwendungen darauf, hast du schnell mal einen kleinen, zeitlichen Engpass.

Mit DMX kenn ich mich nur in Sachen "Veranstaltungstechnik" aus. Da hat uns für unsere Vereinsbühne bisher ein DMX-Kanal gereicht.

Was würdest du denn mit 2 DMX Kanälen machen? Vllt. macht es Sinn zwei UARTs mit der selben Ansteuerung (DMX) zu haben...

[Ing-Dom]

DMX überträgt ja maximal 512 Byte.
Das ist aber, selbst wenn man alles 4kanalig ansteuert (RGBW), ausreichend (128 Stripes).
Eng wird es, wenn man Moving-Heads oder Laufanzeigen ansteuern möchte. Das kommt aber im Home-Bereich eher nicht vor.

Da RS485 aber eine Linientopologie fordert, könnte es sinnvoll sein, mehrere DMX-Linien zu haben.

[tuxedo]

hmm, stimmt. Vor allem bei zwei oder mehr Stockwerken macht das ggf. sehr viel Sinn.

Zurück zur Frage: Wie haben andere Gateways das gelöst?

[tuxedo]

Beispiel:

https://www.voltus.de/?cl=details&an...k64aAu_N8P8HAQ

Also nur ein DMX-UART ... hmm.

fast 1000EUR ist ja ganz schön happig.

Da kann man ja ohne mit der Wimper zu zucken pro benötigten DMX-Channel die ~50EUR ausgeben ;-)

[Eugenius]

nur 1xUART/RS485 auf 4TE ist nicht gut, Platzverschwendung. Da könnte man über einen dedizierten 2TE (oder sogar 1TE) Gerät nachdenken? ...für die Zukunt. Anfagen, um die Erfahrungen zu sammeln, kann man auch mit 4 TE

[tuxedo]

Ja, so war auch mein Gedanke. 4TE weil es da schon Controller gibt, da testen (geht ja prima mit einem Lochrasteraufbau für den DMX Anteil). Und wenn das läuft, kann man schauen wie man das auf 2TE (OKW hat für 1TE keine KNX Klemmenabdeckung :-( ) quetscht und da einen modularen Ansatz daraus macht, so dass man künftig für 2TE Geräte nicht immer wieder einen neuen Controller entwickeln muss.

[Ing-Dom]

Beispiel:

https://www.voltus.de/?cl=details&an...k64aAu_N8P8HAQ

Also nur ein DMX-UART ... hmm.

fast 1000EUR ist ja ganz schön happig.

Da kann man ja ohne mit der Wimper zu zucken pro benötigten DMX-Channel die ~50EUR ausgeben ;-)

geht auch billiger.

Babtec DUODMX mit KNX/TP = 330€
mit KNXNet/IP 250€.
hat 2 DMX-Channels.


mir ist 4TE auch recht.

[evolution]

Oder das Arcus KNX-GW-KNX-2TE für rd. €300. Mit dem funktionsgleichen KNX-GW-KNX bin ich grundsätzlich zufrieden, da man mit dem GW auch problemlos Sequenzen generieren kann. Einzig stört mich die Programmierung via USB - eine Netzwerkschnittstelle wäre imho schon komfortabler. Andererseits programmiere ich das GW ja auch eher selten und dann geht das auch...

[tullsta]

Hat jemand evtl das Ingenium-Gateway im Einsatz?

[tullsta]

bzgl. Eigenbau und das Umsetzen von UART auf DMX-Protokoll hier noch ein pdf.

[ivande]

Hallo tuxedo,

Aktueller Stand sind 85 KOs...

die Begrenzung der KO's liegt sicher in der Suite und im Ablegen der CommObj im EEprom?
Da 85 KO's für mich zu wenig sind:
mein Projekt soll vorerst für 15 Beleuchtungsgruppen (=Räume) mit mindestens je Raum 6 KO starten (Szene, PMSchalten, TasterPlus, TasterMinus, Nacht, PMSperren). Hinzukommen noch einige KO's für Zentral-Funktionen,.. hmm.. da komm ich vermutlich auf das doppelte,..

Wieviele KnxComObject's sind mit der Original-Lib (Franck Marini) möglich. Evtl müsste ich auf diese ausweichen,..


Entwicklungsstand:

derzeit läuft eine LeuchtenGruppe (probeweise mein Büro) bereits über das Gateway.

kurzer Auszug aus dem Log

konnektingKnxEvents index=156
internalComObject index=156
->Event group nr:9 Büro id:1 value: 1 #PM schaltet : Gruppe9, erstes ComObj der Gruppe, Wert 1

set scene: (10) from group id(9) # RaumNr.9 (Büro) wird Szene 10 Aktiviert,.. PM - aktiviert die Szene10 - bei Tag ; bei Nacht Szene11
set offDelay: (600) # Nachlaufzeit PM wird in diese Szene auf 10 Minuten gesetzt
set light: (0) from scene (10) # Leuchte Nr. 0 wird von Szene 10 gesetzt
---->dimming ch (2) fade to (100) fadeTime (2000) # Fade der Leuchte Chanal 2 auf Wert 100 in 2s
set light: (1) from scene (10) # Leuchte Nr. 1 wird von Szene 10 gesetzt
---->dimming ch (3) fade to (50) fadeTime (10000) # Fade der Leuchte Chanal 3 auf Wert 50 in 10s

memUpdate: index=0x1af3 data=0x0a # Speichern der aktuellen Szene im EEprom - damit bei Neustart des Controllers die gleichen Szenen aktiviert werden können
memUpdate: using fctptr

Gruß Ivan

[tuxedo]

Beta4 hat noch keine Limitierung, genau wie die lib von Franck. Und ja, der eeprom ist einer der Gründe. Ein anderer ist die Performance. Die Lib muss bei jedem eingehenden Telegramm schauen ob an eine GA eines KO gesendet wurde. Mit zunehmender Anzahl KOs wird das langsamer. Und damit steigt die Gefahr eines Telegrammverlusts.

Für beta5 werde ich schauen was ich machen kann um die Anzahl möglicher KOs weiter anzuheben ohne dass die Performance darunter leidet und der eeprom voll läuft.

Aber das dauert noch...

[andi11]

für die Performance könnte sortieren nach GA im Vorfeld helfen, wenn GA>SollGA dann break;