Hallo,
nach längerer Pause arbeite ich wieder daran, DMX Geräte in fhem zu integrieren.
Dazu will ich keine neue HW anschaffen, sondern einen CUNO2 nutzen.
Stand:
Die FW des CUNO2 habe ich mit DMX Support neu kompiliert und geflashed. Über eine Konsole kann ich direkt mit den Dxxxxx Kommandos die DMX Geräte steuern.
In fhem lassen sich alle Geräte/Kanäle auch über CUNO2 direkt ansteuern mit z.B.:
set CUNO2 raw Dw1180
Das setzt z.B. die Lampe auf DMX Kanal auf den Wert 128 - halbe Helligkeit. So weit so gut.
Ziel:
Ich möchte fhem um ein Modul CUL_DMX erweitern. Jedes DMX Device soll eine Startadresse (address) erhalten (wo es im DMX Frame liegt) und die Anzahl der Kanäle (channels), die zur Steuerung gebraucht werden.
Die Kanäle werden auch in den Readings gespeichert. So kann ich DMX Blackout realisieren und später die Werte
wieder daraus rekonstruieren.
Dazu habe ich mir aus bestehenden Modulen (großen Dank) einen ersten Code zusammengesetzt und nach bestem Wissen angepasst. Das sicher noch einiges drin, was falsch oder schlichtweg zu viel ist.
Was geht z.B.:
define DMX17 CUL_DMX 123456 17 1 - definiert ein Device an Adresse 17 mit einem Kanal (Lampe)
attr DMX17 loglevel 3
attr DMX17 IODev CUNO2
set DMX17 channel 1 128 - soll die Lampe auf halbe Helligkeit setzen
attr DMX17 address 20 - ändert die Startadresse
attr DMX17 channels 3 - erhöht die Kanäle (auch in den Readings)
Das Problem:
Die Interna des Device werden mE passend geändert. Mit list DMX17 kann ich die Änderungen im
Device sehen. Nur, es wird nichts in den DMX Frame geschrieben - keine Funktion auf dem CUNO2.
Ich komme nicht klar, wie ich dem Modul beibringe, dass es das IODev CUNO2 zur Ausgabe nutzen soll.
Oder evtl. sende ich einfach einen falschen String an das CUNO2. Dazu fehlt mir leider noch das tiefere
Verständnis, wie fhem mit der IODev Ausgabe funktioniert.
Könnt ihr mir bitte helfen :-\
Hi,
und bist du mit deinem Modul weiter gekommen?
Wie muss man sich das denn vorstellen. Der CUNO gibt in einem Loop die 512 DMX Kanäle aus einem Buffer aus. Diesen Buffer beschreibst du mit dem CUNO Befehl Dwxxxx?
Kann man mit dem UART Signal (3.3V) direkt in die DMX Geräte gehen?
Mfg
Hi,
ja, mit dem Modul bin ich etwas weiter (s. Anhang). Ich kann die DMX Kanäle jetzt in fhem mit
set <name> channel <channel> <value> [<value>] setzen.
Das Device wird vorher definiert mit
define <name> CUL_DMX <ID> <startaddr> [<channels>]
attr <name> IODev <phydevice>
Beispiel RBG-Leuchte mit 4 Kanälen (RGB + Summe), Startadresse 17 im DMX-Frame:
define DMXRGB CUL_DMX 123456 17 4
attr DMXRGB IODev CUNO2
set DMXRGB channel 1 65 200 111 255
Habe das im TabletUI auch bereits mit Slidern verbunden - das geht.
Nun hänge ich daran, im Modul Werte vom CUNO zurückzulesen. Z.B. mit Dc, die maximale Kanalzahl der
Firmware oder einen DMX-Kanalwert mit Drxx. Da ich mit Dwxxxx geschriebene Werte auch in den Readings
halte, brauche ich Drxx nicht unbedingt. Aber für einige Prüfungen wäre Dc nicht schlecht.
Hier weiß ich noch nicht, wie das Rücklesen vom physikalischen Device, also CUNO(2), funktioniert.
Im Logfile (5) steht nur UNKNOWNCODE..., das von der Funktion CUL_Parse (Modul 00_CUL.pm) stammt.
An mein Modul wird aber nichts weitergereicht :(
Ja, funktioniert im Prinzip so wie du es beschreibst.
Du musst die Firmware cul_fw mit der Option HAS_DMX neu kompilieren und flashen. Dort gibst du auch die maximale Kanalzahl an (bei mir 192).
Du musst nicht alle 512 Kanäle ausgeben - nur soviele, wie deine DMX-World groß ist.
Auf dem CUNO(2) ist nach dem UART ein RS485-Treiber. RS485 ist der physikalische Bus, der DMX zugrunde
liegt. Mit den Signalen an der Längsseite des CUNO(2) kannst du dann direkt auf die DMX-Geräte.
Viele Grüße
Im Modul habe ich noch zwei Attribute hinzugefügt. "hue" definiert die Startadresse eines RGB Tripels im DMX -Device und erzeugt die Readings hue, sat und bri für dieses Tripel. Diese Werte können auch gesetzt werden. Die Werte werden zwischen den DMX-Kanälen und der "hue", "sat", "bri" Darstellung jeweils umgerechnet. Damit kann das volume-Widget die Farbe einstellen. Mit dem Attribut "pct" bestimme ich einen DMX-Kanal, der mit 0-100% gedimmt werden kann.
Damit kann ich meine DMX-Installation jetzt mit dem Tablet steuern.
Das direkte Rücklesen aus dem phy. Device habe ich immer noch nicht hinbekommen.
Hallo,
ich finde das sehr interessant, weil ich mich auch gerade mit dem Thema DMX und FHEM beschäftige. Also, ich suche gerade noch Möglichkeiten. ;D
Was meinst Du mit dem direkten Rücklesen auf dem phy. Device? Möchtest Du bei dem DMX-Gerät, dass eine Adresse bekommen hat nachfragen welche DMX-Werte es gerade verarbeitet? Das ist, so wie ich das DMX-Protokoll verstehe nicht möglich. Es gibt einen DMX-Sender, der das DMX-Signal erzeugt und auf die Leitung bringt. Das jeweilige Gerät mit dem eingestellten Kanal reagiert dann darauf. Es gibt aber keinen "Rückkanal" der einem quasi bestätigt "Ich führe gerade den DMX-Wert XYZ aus". Was jedoch geht: mit einem DMX-USB-Empfänger das aktuelle DMX-Signal auslesen und die Kanalwerte ausgeben. Aber diese Werte sollten eigentlich dem Gerät bekannt sein, dass das DMX-Signal erstellt. (Diese Erfahrung beruht auf einem Programm dass ich vor einigen Jahren mal in Visual Basic für das Enttec Open DMX Interface "geschrieben" habe.)
Viele Grüße
Mark
Hi Mark,
bei mir ist das CUNO das physikalische Device (für Fhem), d.h. das ist der DMX Master. Dafür musst du
dessen Firmware neu compilieren mit #define HAS_DMX, und die maximale Kanalzahl festlegen (bei mir 192). Aus diesem physikalischen
Device (also nicht aus den Endgeräten, die am DMX Bus hängen) kannst du mit den raw commands:
Dc die in der Firmware hinterlegte maximale Kanalzahl lesen
Dr die Kanalwerte des aktuell gesendeten DMX-Frames zurück lesen
Du hast recht, Dr braucht man nicht unbedingt. Die Daten halte ich in den logischen Devices in Fhem, die
den DMX Endgeräten entsprechen.
Ich mache aber Bereichsprüfungen im Software-Modul. Da jeder User eher seine eigene maximale Kanalzahl
festlegt, wäre die Software unabhängig von der Hardware, wenn ich die maximale Kanalzahl zurück lesen könnte.
Ich weiß nur nicht wie's geht - dazu reichen meine Kenntnisse nicht. Bzw. ich habe nicht vollständig
verstanden, wie der Fallback-Mechanismus beim Lesen von IODev funktioniert.
Für mich taugt der Code so - nur als evtl. allgemeines Modul reicht es nicht.
Den Code hatte ich hier eingestellt in der Hoffnung, es findet sich ein Interessent, der weiß wie's geht :)
Viele Grüße
Joachim