yavdr ansible

  • Ich hatte die udev-Regel für den lircd_helper aus yavdr-remote umbenannt, aber nicht gesehen, dass die mit dem selben Namen im eventlircd-Paket steckt. Ich lade gleich noch eine neue Version hoch, die das Problem nicht hat.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das Fernbedienungsproblem von Frodo erinnert mich stark an diese beiden Beiträge und mein eigenes Problem.

    yavdr-ansible-zweite-fernbedienung-mceusb-wird-nicht-richtig-eingebunden

    mce-remote-mit-1804-ansible-verhält-sich-komsich

    Für mich habe ich es mit der System-Unit gelöst.

    Zum Einen wird das richtige Protokoll eingestellt und zusätzlich die Lirc-Module entladen, da sie trotz Blacklist nach jedem Reboot wieder aktiv sind.

    Natürlich nur ein Workaround, aber für mich funktioniert es.

    Das eigentliche Problem erkenne ich leider nicht :(

    set-mce-remote-protocol.service

    Ich habe nur einen Empfänger, e scheint also nicht zwingend etwas mit der Anzahl der Empfänger zu tun zu haben.

    Ich nutze Bus 002 Device 003: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver

    YaVDR-ansible , Case: HFX Classic, Mainboard: ASUS H97M-E, CPU: Intel Celeron CPU G1840T, GPU: GeForce GT 1030, DVB-S: Digital Devices Cine S2 V6

    YaVDR-ansible (24/7), Case: Akasa, Mainboard: NUC D34010WYB, DVB-S: SkyTV Ultimate IV, Miscellaneous: epgd, pihole (DoH)

    YaVDR-ansible (headless), System: HP 260 G2 DM, DVB-S: Sundtek SkyTV Ultimate 6 2016/Q1

  • Es gibt ein generelles Problem mit dem lirc_helper wenn er direkt über eine udev-Regel gestartet wird (die 98-lircd.rules habe ich heute im Paket yavdr-remote deaktiviert), - mit neueren Versionen von udev dürften solche Prozess nicht endlos laufen und werden nach einem Timeout abgewürgt. Da es mittlerweile rc-core Treiber für die Empfänger gibt, hilft das hoffentlich allen, die so einen Empfänger haben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich habe eine kleine ansible role gebastelt welche die Imon VFD Displays (15c2:0036,15c2:0044) einbindet d.h. das Plugin vdr-plugin-lcdproc und den LCDd Daemon einrichtet und startet.

    Es wird analog zum imonlcd eine /lib/udev/rules.d/92-imon.rules angelegt. Ausserdem wird die Konfiguration für den LCDd vervollständigt und er systemd Job aktiviert.


    Ich weiss nicht ob alle Zeichen richtig dargestellt werden, bei Ubuntu Trusty mußte man noch eine charmap im LCDd.conf für das imon Device angeben. Diese Maps gibt es unter Bionic nicht mehr.


    Eventuell werden noch Anpassungen bei den default vdr-plugin-lcdproc Parametern benötigt. Hier hab ich ersteinmal nur meine vorhandenen (von Trusty) Einstellung übernommen aber nicht ins ansible gepackt.

    Files

    Gruß
    Frodo

  • Danke, ich habe deine Rolle etwas überarbeitet (die 92-imon.rules wird potentiell schon vom vdr-plugin-imonlcd angelegt, daher der geänderte Name und Pfad) und ins Git gepackt: https://github.com/yavdr/yavdr…a80a6e2da87a0acba322a2af1 - bitte probier mal, ob das so passt.


    Hat sich am Verhalten des ttyusbir-Empfängers etwas mit dem letzten yavdr-remote Paket mit deaktiverter udev-Regel für den lircd_helper geändert?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich hatte noch keine Zeit das zu testen. Ich schau mir das heute Abend an.

    Gruß
    Frodo

  • Ohne das ich es probiert habe in der Zeile ist was falsch:

    imon_vfd_device: '{{ "imon_00044" if "15c2:0044" in usb else "imon_0044" }}'

    Die 0 von imon_00044 dürfte zu viel sein und für das 0036 USB Device wird die Variable gar nicht gesetzt.


    Sollte das nicht wie folgt aussehen?

    imon_vfd_device: '{{ "imon_0044" if "15c2:0044" in usb else "imon_0036" }}'

    Gruß
    Frodo

    The post was edited 2 times, last by Frodo ().

  • Ja, du hast Recht, ich habe es gerade im Git korrigiert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Mit meinem 0036 Device habe ich es getestet, es funktioniert :)

    Das 0044 kann ich erst heute Abend prüfen, da ist aber immer noch eine 0 zuviel in dem String imon_00044 der sollte doch sicherlich wie folgt aussehen: imon_0044

    Gruß
    Frodo

  • Frodo und Seahawk


    Vielen Dank für das Überarbeiten des Remote Packets. Ich habe ein imonlcd und erhielt nach dem Start für kurze Zeit folgende FehlerMeldung in vielfacher Wiederholung:

    Code
    1. kernel: [ 184.797636] imon 3-6:1.0: Unsupported IR protocol specified, overriding to iMON IR protocol

    Diese wiederholten Fehlermeldungen sind seit dem Update von heute verschwunden.


    Es kommen nur noch einmal diese zwei FehlerMeldungen nach dem Start:

    Code
    1. Jun 14 12:39:49 localhost kernel: [ 8.185576] imon 3-6:1.0: Looks like you're trying to use an IR protocol this device does not support
    2. Jun 14 12:39:49 localhost kernel: [ 8.185579] imon 3-6:1.0: Unsupported IR protocol specified, overriding to iMON IR protocol

    Übrigens, die iMon Fernbedienung funktioniert jetzt gleich nachdem der VDR hochgefahren ist; vorher schien es eine kleine Verzögerung zu geben.


    MfG

  • Bei mir ist das Problem mit der zweiten Fernbedienung auch behoben. Beide funktionieren wie es sein soll. :)

    Gruß
    Frodo

  • Bei den Änderungen zu den imon Geräten sind irgendwo die udev Regeln für das imonlcd Display verloren gegangen.

    Gruß
    Frodo

  • Da die Datei nicht aus einem Paket kommt, packe ich sie nach /etc/udev/rules.d: https://github.com/yavdr/yavdr…monvfd/tasks/main.yml#L13

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das habe ich gesehen.


    Es gibt aktuell noch ein Probleme mit den Imon Displays


    1. Für yavdr-ansible/roles/autoinstall-imonvfd/tasks/main.yml habe ich einen Pull request gestellt weil die Zeile imon_vfd_device: '{{ "imon_0044" if "15c2:0044" in usb else "imon_0036" }}'

    im git noch falsch ist.


    Das andere hat sich gerade gelöst die udev Regeln für die imonlcd Devices 0038 und ffdc waren verschwunden. Nachdem ich das Paket vdr-plugin-imonlcd nochmals installiert habe

    apt install --reinstall vdr-plugin-imonlcd

    sind sie wieder da.

    Gruß
    Frodo

  • Danke, ich habe den Pull-Request übernommen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • Hallo,
    hat eigentlich jemand yaVDR Ansible mit einer Intel HD600 laufen?
    Gibt es da Einschränkungen? Muss ich besondere Anpassungen in den Playbooks machen oder Treiber nachinstallieren?

    Gruß,
    Grillbert

    Cine S2 V6.5 + DuoFlex V4 Apollo-Lake Celeron (Asrock J3355M), ATRIC Einschalter, MLD 5.4 testing

  • Mal eine kurze Frage zu dem vdr-addon-lifeguard-ng. Ist dafür das vdr-plugin-dbus2vdr nötig?




    Dann noch eine Sache zum vdr-addon-acpiwakeup. Irgendwie will das bei mir nicht so richtig und ich bekomme im log jedes mal die folgende Meldung:

    Code
    1. /usr/share/vdr/shutdown-hooks/S90.acpiwakeup: 84: /usr/share/vdr/shutdown-hooks/S90.acpiwakeup: Syntax error: "(" unexpected (expecting "fi")

    Erklären kann ich mir das nicht, da mit dieser Zeile eigentlich alles stimmt.


    Wenn ich die Elemente dem Array aber einzeln zuweise, dann läuft alles wie es soll.

    Diff
    1. --- S90.acpiwakeup So Apr 7 11:19:44 2019
    2. +++ S90.acpiwakeup Do Jul 18 16:20:23 2019
    3. @@ -84 +84,4 @@ SetWakeupTime()
    4. - dates=("now +1 year -1 min" "now +1 month -1 min" "now +1 week -1 min" "now +1 day -1 min")
    5. + dates[0]="now +1 year -1 min"
    6. + dates[1]="now +1 month -1 min"
    7. + dates[2]="now +1 week -1 min"
    8. + dates[3]="now +1 day -1 min"

    The post was edited 2 times, last by tecfreak ().

  • Mal eine kurze Frage zu dem vdr-addon-lifeguard-ng. Ist dafür das vdr-plugin-dbus2vdr nötig?

    Soweit ich das im Code sehen kann nicht - im Shutdown-Hook für den VDR wird ein Skript aufgerufen, das über DBus mit dem lifeguard-Daemon kommuniziert, aber der VDR ist daran nicht beteiligt (der würde den Shutdown ja selber vorher abbrechen, wenn er etwas dagegen hätte).

    Wenn ich die Elemente dem Array aber einzeln zuweise, dann läuft alles wie es soll.

    Das klingt nach einer dash vs. bash Geschichte - bei yavdr-ansible wird die Standard-Shell auf die bash gesetzt: https://github.com/yavdr/yavdr…s/configure_system.yml#L1


    Das Skript hat zwar die Bash im Shebang aber wenn es nicht ausführbar ist, ruft das vdr-shutdown Skript es mit sh auf, was dann mit der dash als Standard-Shell schief geht. Ich denke, ich baue da im Paket für das vdr-addon-acpiwakeup noch etwas ein, das die Datei ausführbar macht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ach ja - die gewünschten Shutdown-Hindernisse muss man beim vdr-addon-lifeguard-ng erst mal in der Konfigurationdatei aktivieren, standardmäßig blockiert das nichts: https://github.com/seahawk1986…lob/debian/lifeguard.conf

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo,
    hat eigentlich jemand yaVDR Ansible mit einer Intel HD600 laufen?
    Gibt es da Einschränkungen? Muss ich besondere Anpassungen in den Playbooks machen oder Treiber nachinstallieren?

    Gruß,
    Grillbert

    So - die Frage habe ich mir selber beantwortet ... erster Test ohne Schnickschnack läuft - super Bild, super Umschaltzeiten HD und SD funzt.

    Yavdr Ansible (Installiert nach upgrade und dist-upgrade) Asrock j4105M mit INTEL HD600 Grafik.

    Cine S2 V6.5 + DuoFlex V4 Apollo-Lake Celeron (Asrock J3355M), ATRIC Einschalter, MLD 5.4 testing