Generische Ein-Aus Geräte in CUxD?

[Goglo]

Hallo zusammen - oder besser Uwe,

schon seit einiger Zeit denke ich darüber nach, wie man z.B. eine koukaam NetIO-Schalterleiste (oder auch irgendwelche anderen per http ansprechbaren Geräte, Verstärker, WLAN-Lampen,...) in die CCU integriert bekomme. Und zwar so, dass sie als "richtiges" Gerät angezeigt werden. Insbesondere mit korrektem Status.

Nun ist dieses NetIO-Ding über sys_exec ja ganz simpel anzusprechen und ich kann per webUI oder App auch schalten. Nur möchte ich lieber so etwas wie eine Schaltsteckdose angezeigt bekommen - und vor allem auch ob sie gerade ein- oder ausgeschaltet ist. Denn schalten kann ich die auch über andere Wege als die CCU. Nun wäre es ja ein leichtes, per cron alle paar Minuten mal zu pollen und das Ergebnis irgendwie an CUxD weiterzuleiten. Oder CUxD pollt selbst per frei definierbaren Befehl und Intervall.

Was ich also suche, ist ein neuer universeller Aktor, den ich mit konfigurierbaren Kommandos schalten kann und dessen Status mit einem anderen Kommando ausgelesen werden kann. Sozusagen ein Multi-Dim-Exec mit Ein/Aus-funktionalität statt Taster / Dimmer und vor allem auch "Empfangsrichtung". Oder ein FS-20-Aktor mit sys_exec-Anschluss anstelle CUL per USB.
Wäre so etwas einfach in den CUxD hereinzubauen oder liegt die Lösung doch eher in ccu.io? Das würde mir nicht so gut gefallen, da meine Universalfernbedienung eigentlich pocketControl ist und ich bislang die Mühe gescheut habe, irgendwelche grafischen UIs zusammenzubasteln.

Danke & Gruss,

Goglo

[uwe111]

Hallo Goglo,

Oder CUxD pollt selbst per frei definierbaren Befehl und Intervall.

Vielleicht sollte ich eine Erweiterung vom System.Timer Gerät mit Weiterleitung vom Rückmeldestatus an ein beliebiges CUxD-Gerät (z.B. System.Exec für die Schalter) implementieren?

Viele Grüße

Uwe

[Goglo]

Grrr, da ist doch glatt mein ellenlanger Post von gestern im Nirvana verschwunden. Also nochmal neu:

Hallo Uwe,

Die Idee mit dem Timer ist sicherlich gut, die wahre Herausforderung liegt aber an anderer Stelle. Der Rückkanal muss in das virtuelle Gerät und nicht in den sys-exec.

Der Multi-Kanal-Dimmer geht eigentlich schon in die richtige Richtung, nur fehlt ihm der Rückkanal. Das ist im UI auch konsistent so abgebildet, denn es ist ein Taster mit nur einer Schaltfläche und nicht zwei Schaltflächen Ein und Aus. So etwas würde ich mir wünschen, auch gerne in den Varianten 2- und 4-Kanal, dann mit entsprechend mehr Befehlen. Der Setter-Aufruf könnte z.B. sein: <cmd> $1 mit $1 entweder 1 oder 0, je nachdem ob "Ein" oder "Aus" gedrückt wurde. Der Getter würde dann entsprechend per exitcode $? den aktuellen Zustand des Geräts zurückliefern und regelmäßig pollen. Da kann man natürlich auch auf das Timerdevice und sys-exec verweisen. Wichtig ist aber, dass der returncode vom getter in das virtuelle Device geht und da den Zustand setzen kann. Alternativ kann man bei 2- oder 4-fach Geräten den Setter auch <cmd> $1 $2 [$3 $4] aufrufen mit $x für den Status des jeweiligen Schalters. Für den Getter könnte man den retruncode dann binär codieren um den Zustand aller Kanäle in den einen Integer reinzubekommen.

Ein anderer Ansatz wäre ein normalerweise per USB verbundener Aktor, z.B. das Gerät (36), weil das in drei verschiedenen Kanalanzahlen kommt. Nur muss der Aktor nun nicht Telegramme per USB empfangen bzw. gesendet bekommen, sondern halt per shellscript und für den Rückweg halt pollen, da man den Aktor ja auch anders als über CUxD schalten kann. Wie man das da am geschicktesten auftrennt, kann ich so nicht sagen, da ich die Hardware nicht habe und mich da noch nicht so recht durch die Konfiguration durchklicken konnte.

Die Anwendung wäre halt eine Erweiterung um den Rückkanal von Steuerungen, die hier schon viele mit dem sys-exec unternehmen. Z.B. Gäste-WLAN auf dem Router einstellen. Ein Klacks per sys-exec. Nur bekommt die CCU nicht mit, ob das WLAN nun eingeschaltet ist oder nicht; man kann es nur "auf Verdacht" einschalten. Schöner wäre es ja, wenn der Schalter im webUI oder der App anzeigen könnte, ob das Gäste-WLAN an ist oder schon wegen Inaktivität wieder ausgeschaltet wurde. Dito für alle anderen Geräte mit Netzwerkanschluss, von denen es ja mehr und mehr gibt.

Ich glaube, drüben bei ccu.io basteln die an solchen Lösungen als Adapter für den Onkyo-Verstärker und die hue-LEDs. Ich fänd' eine Implementierung im CUxD aber schöner, weil schlanker und auf die CCU bezogen. Ich könnte mir auch vorstellen, die zur Ansteuerung von meinem koukaam-NetIO und den Philips hue notwendigen Shellskripts in eine Zusatzsoftwarepaket zu packen, so dass auch technisch nicht so versierte von dieser neuen Funktionalität profitieren können. (bei der hue-implementierung würde ich mich erst einmal auf simples ein/aus in Weiß beschränken, da ja ein Farbregler so in der CCU nicht vorgesehen ist und ich gerne zur CCU kompatibel bleiben möchte)

Was denkst Du, wäre so eine Erweiterung ohne Einschnitte in die Architektur von CUxD machbar?

Goglo

Ah, Edit sagt: für die hue LED-Lampen wäre ein Dimmer natürlich sinnvoller als nur simples ein/aus. Also wären da nun schon zwei virtuelle Aktoren: (multikanal) Ein/Aus und Dimmer

[uwe111]

Hallo Goglo,

Der Rückkanal muss in das virtuelle Gerät und nicht in den sys-exec.

Ja, sowas hatte ich auch gemeint. Das per Timer.Exec aufgerufene Script fragt den Status eines oder mehrerer Geräte ab und könnte z.B. folgendes auf STDOUT zurückliefern:

Code: Alles auswählen

CUX2801001:1.STATE 0
CUX2802001:5.LEVEL 100
...

und daraufhin wird dann der Status der entsprechenden CUxD-Geräte auf der CCU geändert.
Wie findest Du das?

Viele Grüße

Uwe

[Goglo]

Hallo Uwe,

ich glaube, nun hab' ich verstanden, wo Du hinwillst.

A) Ich habe mir ein system.exec angelegt mit Ein-Aus-Schalter als Symbol. Mit diesem Schalter kann ich über CMD_SHORT und CMD_LONG ein- und ausschalten. Das funktioniert auch, wenn ich den Schalter in PocketControl betätige. (Für die LED-Lampen bräuchte es hier dann noch die Variante "Dimmer")

B) Ich habe mir einen Timer eingerichtet, der alle 5 Sekunden ein Shellscript aufruft. Darin gebe ich über STDOUT einen string aus und setze einen returncode.

C) in einem HMscript lasse ich mir die Datenpunkte meines Timers ausgeben:

Code: Alles auswählen

WriteLine("TIMER_GET: " # dom.GetObject("CUxD.CUX2800001:1.TIMER_GET").State());
WriteLine("TIMER_EVENT: " # dom.GetObject("CUxD.CUX2800001:1.TIMER_EVENT").State());
WriteLine("CMD_RET: " # dom.GetObject("CUxD.CUX2800001:1.CMD_RET").State());
WriteLine("WORKING: " # dom.GetObject("CUxD.CUX2800001:1.WORKING").State());

Ich kann schön sehen, wie der Timer so langsam auf 0 läuft. Allerdings verändern sich die anderen Datenpunkte nie.

TIMER_GET: 3.000000
CMD_RET:
TIMER_EVENT: false
WORKING: true

Bei den letzten beiden mag ich das ja noch verstehen, aber bei CMD_RET hätte ich eigentlich entweder den string oder den returncode erwartet - je nachdem popen() oder system() eingestellt ist. Aber CMD_RET bleibt leider immer leer.

Mache ich da was falsch, stimmt da die Doku nicht, oder ist das gar der Punkt, den Du implementieren würdest?

Gruss,

Goglo

[uwe111]

Hallo Goglo,

eine direkte Abfrage von dom.GetObject("CUxD.CUX2800001:1.TIMER_EVENT").State() und dom.GetObject("CUxD.CUX2800001:1.CMD_RET").State() liefert immer false bzw. einen Leerstring zurück, da diese Werte nur als Event vom CUxD zur CCU gesendet werden.
Du solltest den Rückgabewert aber erhalten, wenn Du dom.GetObject("CUxD.CUX2800001:1.CMD_RET").Value() aufrufst.

Ich würde für EXEC_FUNC neben system() und popen() noch einen weiteren Punkt mit dem von mir beschriebenen Verhalten implementieren.

Viele Grüße

Uwe

[Goglo]

Ich würde für EXEC_FUNC neben system() und popen() noch einen weiteren Punkt mit dem von mir beschriebenen Verhalten implementieren.

Das klingt doch vielversprechend. Könntest Du bei der Gelegenheit zusätzlich zu Taster und Schalter noch einen Dimmer für den system.exec einbauen? Das würde LED-WLAN-Lampen in die CCU integrieren. Natürlich ohne Farbregler, das geben die Controls der CCU ja nicht her. Denn auf diese Art und Weise bekommt man dimmbares Licht ohne den Einbau von homematic-Dimmern.

Eine Frage hätte ich noch zum CMD_RET von oben: Was wäre da denn eine sinnvolle Anwendung? Ich meine, wie bekommt man denn den Rückgabewert da raus, wenn TIMER_EVENT nur feuert, wenn EXEC_FUNC leer ist. Oder ist das ausschließlich zum loggen gedacht?

Vielen Dank!

[uwe111]

Das klingt doch vielversprechend. Könntest Du bei der Gelegenheit zusätzlich zu Taster und Schalter noch einen Dimmer für den system.exec einbauen?

Dafür war eigentlich System.Multi-Dim-Exec gedacht.

Eine Frage hätte ich noch zum CMD_RET von oben: Was wäre da denn eine sinnvolle Anwendung? Ich meine, wie bekommt man denn den Rückgabewert da raus, wenn TIMER_EVENT nur feuert, wenn EXEC_FUNC leer ist. Oder ist das ausschließlich zum loggen gedacht?

Mit EXEC_FUNC meinst Du bestimmt CMD_EXEC? Da sollte man die Programmverknüpfung eigentlich auf Aktualisierung von CMD_RET triggern. Funktioniert das nicht?

Viele Grüße

Uwe

[Goglo]

Dafür war eigentlich System.Multi-Dim-Exec gedacht.

Passt schon. Ich hatte bislang immer eine Fernbedienung als Geräterepräsentation eingestellt. Da kam in PocketControl nichts Sinnvolles zustande. Mit einem ordentlichen UP-Dimmer ist dann aber alles OK.

Mit EXEC_FUNC meinst Du bestimmt CMD_EXEC? Da sollte man die Programmverknüpfung eigentlich auf Aktualisierung von CMD_RET triggern. Funktioniert das nicht?

Genau, meine ich. Das triggert auch. Allerdings wird auch bei der Auswahl von popen() im webUI-Programm nur die Auswahl auf Zahlenvergleich angeboten. An den String selbst kommt man halt nur in HMscript dran. Aber wenigstens weiss ich nun, wie man da drankommt & wofür das gut sein kann. (Auf diese Art und Weise bekäme man auch einen Workaround bis zum nächsten Release vom CUxD hin - muss ich mal ausprobieren ob ich das Rückkopplungsfrei zusammengebastelt bekomme)

Danke!

[uwe111]

Allerdings wird auch bei der Auswahl von popen() im webUI-Programm nur die Auswahl auf Zahlenvergleich angeboten.

Ja, das ist mir auch aufgefallen. Die WebUI bietet leider immer nur einen Zahlenvergleich an. Auch wenn der Datenpunkt vom Typ String ist.

Viele Grüße

Uwe