FHEM - Entwicklung > Wunschliste

FHEM Modul für CEC-Kommandos

(1/3) > >>

TheRelativ:
Hallo zusammen,

ich experimentiere seit einigen Tagen mit cec-utils und habe das auch fast soweit dass ich es anwenden.
Der Gedanke der mir kam, es wäre doch viel einfacher, wenn es ein Modul gäbe, welches den CEC-Traffic versteht und in FHEM Devices umsetzt.
Klar, cec ist vom Prinzip her einfach, man kann sich auch sämtliche Befehle mit http://www.cec-o-matic.com/ zusammenbauen bzw. auch decodieren lassen, aber dann muss für jedes Device ein notify usw eingerichtet werden.
Schöner wäre es, wenn man die Roh Traffic Ausgabe von cec-utils mittels einer named pipe an FHEM weitergeben könnte.

Mein Aufbau bisher:
- ein Raspberry Pi Zero W mit HDMI Kabel am Fernseher
- installierte cecutils und libcec-dev

Ein Script um das cec Tool als "Daemon" zu starten sowie ein-/Ausgabe in Named Pipes zu leiten:

--- Code: ---if [ -f "/tmp/cecclient_i.pipe" ]; then
        mkfifo /tmp/cecclient_i.pipe
fi
if [ -f "/tmp/cecclient_o.pipe" ]; then
        mkfifo /tmp/cecclient_o.pipe
fi




SERVICE="cec-client"
if pgrep -x "$SERVICE" >/dev/null
then
    echo "$SERVICE is running"
else
    echo "starting $SERVICE"
    killall tail
    killall cec_reader.sh
   (/usr/bin/tail -f /tmp/cecclient_i.pipe | /usr/bin/cec-client -d 8 &) > /tmp/cecclient_o.pipe &
fi

SERVICE="cec_reader.sh"
if pgrep -x "$SERVICE" >/dev/null
then
    echo "$SERVICE is running"
else
    echo "starting $SERVICE"
    /home/pi/cec_reader.sh &
fi

--- Ende Code ---


Ein Script um die Ausgabe-Pipe auszulesen, aktuell zu Debug-Zwecken einfach nur in eine Log-umgeleitet, aber daraus kann man ja machen was man möchte:

--- Code: ---#!/bin/bash

pipe=/tmp/cecclient_o.pipe

while true
do
    if read line <$pipe; then
        if [[ "$line" == 'quit' ]]; then
            break
        fi
        echo $line >> /home/pi/cecreader.log
    fi
done

echo "Reader exiting"

--- Ende Code ---

mit z.B. echo "tx 10:36" > /tmp/cecclient_i.pipe kann ich den TV in standby versetzen (Sender Logical ID:1 ist Raspberry, Empfäner ID:0 der TV, 36 der Code für Standby)

Mit dem oben angegebenen Log-Level (-d 8) erhält man im Log folgende Ausgaben:

--- Code: ---TRAFFIC: [ 1435037] << 1f:84:10:00:01
TRAFFIC: [ 1474721] << 10:36
waiting for input
TRAFFIC: [ 1475601] >> 0f:36
TRAFFIC: [ 1540722] >> 0f:87:00:00:f0
TRAFFIC: [ 1540722] << 1f:87:00:15:82
TRAFFIC: [ 1541692] >> 2f:84:10:00:01
TRAFFIC: [ 1543458] >> 0f:87:00:00:f0
TRAFFIC: [ 1543459] << 1f:87:00:15:82
TRAFFIC: [ 1544428] >> 2f:84:10:00:01
TRAFFIC: [ 1546288] >> 5f:87:00:00:f0
TRAFFIC: [ 1548141] >> 0f:87:00:00:f0
TRAFFIC: [ 1548141] << 1f:87:00:15:82
TRAFFIC: [ 1549111] >> 2f:84:10:00:01

--- Ende Code ---

Ohne setzen des Log-Levels bekommt man auch Menschen-Lesbare ausdrücke, aber da denke ich sind diese "Maschinen-Lesbaren" Ausdrücke gerade für Module besser geeignet.

Die Idee also, aus dem Raspberry Pi Zero W eine FHEM Instanz mit einem neu zu schaffenden CEC-Moduls, welches den Stream aus der Ausgabe Pipe bekommt und selbst Befehle in die Eingabe Pipe senden kann. Das Modul erstellt Devices anhand der Physical Address, die Logical Address kann als Attribut/Reading zusätzlich auftauchen.
Bei einem beispielweise "set tv on" (wobei tv eines der neuen devices ist) sendet das neue Modul dann "tx 10:04" an die Eingabe Pipe (10 = Raspberry an TV, 04 = einschalten)

Mittels FHEM2FHEM kann man alle Devices und Readings vom Raspberry Pi Zero W an die Hauptinstanz weiterleiten.
Die Hauptinstanz kann die Befehle dann mit bspw. system("echo 'set tv on' | /usr/bin/socat - TCP:1.2.3.4:7072"); auf der anderen Instanz absetzen.

Die Große Frage, gibt es jemanden der so ein Modul entwickeln möchte? =)

Otto123:
Hi,

alternative Idee: Ein "MQTT Device" bauen?
Man könnte einfach mosquitto-clients installieren und dann in dem Daemon die Ausgabe Werte zur MQTT2 Instanz in FHEM publishen. Bzw. auch wieder einen Topic abonnieren und auf den geeignet reagieren.

Das Ganze lässt sich damit auf scriptlevel abhandeln erfordert kein lokales FHEM. Mit MQTT wird es universeller und man braucht kein spezielles Modul.
Die dafür notwendigen Grundgedanken hatte ich hier schon mal skizziert.

Gruß Otto

justme1968:
schau dir mal an wie das tradfri modul einen externen prozess startet und mit dessen stdio kommuniziert. der externe prozess kann auch per ssh auf einem entfernten rechner gestartet werden. die gleiche methode per Prozess bzw. inzwischen gekapselt in CoProcess.pm wird auch in anderen modulen verwendet.

den umweg über mqtt etwas neues in fhem einzubinden das nicht von sich aus schon mqtt spricht halte ich für nicht gut.

Otto123:
Naja der Prozess "cec am Fernseher" spricht erstmal nichts was FHEM versteht. Dort in etwas zu übersetzen, was FHEM sowieso schon versteht und auch über einen Standard Kommunikationsweg funktioniert, halte ich für besser als einen neuen Sprachkundigen in FHEM auszubilden.

Und wenn ich an die Arien denke wie leicht es die Benutzer finden ssh mit public key für user fhem einzurichten  :'(

Ich finde nicht das es ein Umweg ist, aber war nur eine Idee - vielleicht war die doof. :-*

TheRelativ:
die MQTT Variante klingt ehrlich gesagt gar nicht mal so schlecht.
Man bräuchte dann auf dem HDMI-Raspberry nur ein MQTT Client und ein Script was daraus senden/empfängt und übersetzt.
Auf der anderen Seite könnte man die von mir gebauten Pipes nutzen.

Publishen geht laut deiner Seite mit mosquitto_pub, wie bekomme ich anders rum hin dass der hdmi-raspberry auf bestimmte topics lauscht?

also
CEC-Traffic -> Output Pipe -> Übersetzungs-Script -> mosquitto_pub -> MQTT Server -> FHEM
anders rum
FHEM -> MQTT Server -> ??? -> Übersetzungs-Script -> Input-Pipe -> CEC-Kommando


Man könnte jedes physical oder logical device (ich muss da nochmal genau nachdenken was besser wäre) als eigenes topic publishen und diverse Eigenschaften mitgeben die ebenfalls via CEC gesendet werden (Geräte-Typ, OSD-Name, HDMI-CEC-Version, letztes Kommando auf der FB)

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln