Beiträge von zx81

Hi,
ich habe mal mein Script mit angehängt. Es ist aus Klaus' ursprünglichem Script entstanden und redet wie gesagt direkt mit dem Systa-LAN. Die Dekodierung der Antworten habe ich mir per Analyse der Hex-Antworten rausgesucht. Hilfreich war ein TCPdump während man mit der Systa-LAN Software den Monitor laufen lässt.
Da ich nur die Solaranlage habe, fehlt der Rest. Aber die SW kann auch die Heizung monitoren, daher denke ich, dass für diese Regler der Mechanismus (alle Minute einen UDP-Request abschicken) der Gleiche ist.

Bei Klaus gingen die Daten in das rrdtool, bei mir gehen sie in eine InfluxDB und werden per Grafana (siehe Screenshot) visualisiert.

HTH,
-Markus

Abry88: Wenn Du das SystaServiceLAN hast, dann ist da eine Software für Windows dabei.

Diese SW kann die einzelnen Regler (Systacomfort, SystaAqua 1+2 usw) abfragen. Dazu sendet diese einen UDP-Request an den Regler und der Antwortet dann fein mit UDP Datagrammen mit den Daten. Da brauch man dann keinen DNS umbiegen ....

Ich habe hier nur den Aqua II (da könnte ich das Perl-Script teilen, welches die Daten abfragt). Andere Regler habe ich nicht, der Mechanismus sollte aber ähnlich sein. Ist dann auch sehr einfach mit Wireshark rauszufinden, denn die SystaServiceLAN SW zeigt im sog. "monitor-mode" schön alle Daten an, die sie empfängt. Das macht die Analyse, welche Daten was im UDP-Packet bedeuten, relativ einfach.

VG,
-Markus

Hallo,
im vdr.log schreibt er ja immer bei non-timer start "assuming manual start". Scheinbar wird das über eine einfache Zeitdifferenz in der shutdown.c gemacht:

void cShutdownHandler::CheckManualStart(int ManualStart)
{
  time_t Delta = Setup.NextWakeupTime ? Setup.NextWakeupTime - time(NULL) : 0;


  if (!Setup.NextWakeupTime || abs(Delta) > ManualStart) {
     // Apparently the user started VDR manually
     dsyslog("assuming manual start of VDR");
     // Set inactive after MinUserInactivity
     SetUserInactiveTimeout();
     }
  else {
     // Set inactive from now on
     dsyslog("scheduled wakeup time in %ld minutes, assuming automatic start of VDR", Delta / 60);
     SetUserInactiveTimeout(-3, true);
     }
}

Kann man wohl so nicht abfragen, wohl einfach den Code kopieren.

Ich frage mich, ob man wirklich zwischen idle-powerdown und PowerOff-Knopf unterscheiden muss. So wie ich das CEC-Protokoll verstehe, sollte man bestimmte Dinge sowieso nur tun, wenn man "active-source" ist, damit man eben andere aktive Geräte am Bus nicht stört.
Daher wäre es wohl einfacher, generell vor dem Ausführen der onStop/poweroff-Kommandos zu prüfen, ob man active-source ist. Zum Übersteuern könnte man ein Tag onStopForce und PowerOffForce oder so machen, was die Befehle immer schickt.

Danke,
-Markus

Hallo,
das schaut ja von den Funktionen schon mal richtig gut aus.

Wenn ich noch 2 Vorschläge machen darf:

• Im "global" anstatt (oder zusätzlich) zu onstart/onstop des plugins selbst eine Funktion, die zwischen manuellem Start (powerknopf / remote des VDR) und Start durch Timer unterscheidet. Usecase: man könnte dann bei manuellem Start TV und Receiver anschalten (und wieder aus) und beim Timerstart nichts machen
• Abfragemöglichkeit (condition) ob "active-source" in den Kommando-Einträgen. Usecase: VDR, TV und Reciever laufen und man entscheidet sich, eine BluRay mit dem BD-Player zu schauen. Der switched per CEC den Eingang auf sich um. VDR fährt dann nach Inaktivität runter, und würde dann TV und Receiver ausschalten. Die libCEC gibt es meines Wissens her, dass man den "active source" abfragt. In diesem Fall könnte man dann das Ausschalten verhinden, da der VDR nicht "active-source" ist

Danke,
-Markus

Hi,
teste doch mal mit femon, wie sich BER und UNC verhalten, insb. beim Wechsel der Tuner.

Teste nach Möglichkeit mal mit QVC HD, da ist das bei mir auch sehr deutlich.

Ich vermute dann mal, dass Dein Problem nur bei Tuner 1 (der obere) auftritt, auch nach dem Wechsel der Kabel.

VG,
-Markus

Hi,
am Wochenende hatte ich beim meinem yavdr 0.5 das Mainboard tauschen müssen.

Grub war soweit OK, da dort die Geräte per device-ID angesprochen werden. Jedoch hing der yavdr nach dem Start des Kernels, da in der initrd der Treiber zum mounten des rootfs fehlte.
Ich habe dann rumprobiert und es aber nicht hin bekommen so dass ich neu installieren musste.

Die Frage ist daher: wenn ich über die yavdr-CD in die busybox-shell boote, gibt es da irgendeine Möglichkeit, die initrd neu zu bauen (möglichst mit automatischer Erkennung der benötigten Treiber für die aktuelle HW ?)

Danke,
-Markus

Hi,
der Support hat mir nun auch eine v6.5 im Tausch geschickt (das ging extrem fix). Was soll ich sagen ? Das Problem mit Tuner 1 tritt auch damit auf.

Am Sat-Kabel kann es nicht liegen, denn wie gesagt Einkabel - System und alle anderen Tuner laufen einwandfrei. Auch wenn ich kurzen Anschlusskabel wild tausche.
Treiber ist media-build-experimental (lauf dmesg recht neu mit Metzler-Version 0.9.9).

Hatte jetzt auch mein Board (ein Intel B75) im Verdacht und habe daher am Wochenende mal auf ein Intel Z77 getauscht leider auch ohne Änderung.

Evtl. ist ja dem einen Tuner der Pegel zu hoch - hatte da mal gelesen, dass diese Karten dazu neigen könnten. Muss jetzt mal sehen, ob ich testweise einen Pegelsteller auftreiben kann, den ich mal nur vor den Tuner 1 klemme ,,,

Habe jetzt dem Support erneut geschrieben - mal sehen ob die noch weitere Ideen haben ... Halte Euch hier auf dem Laufenden.

VG,
-Markus

Hi,
im bösen Plugin aktiviert man doch die Nutzung desselben auf jedem Tuner einzeln.

Hast Du das für Adapter 1 bis 4 gemacht ?

VG,
-Markus

Ich habe hier das gleiche Problem mit Tuner 1 - allerdings noch mit einer V6.2 (mit 2 Steckern für Module).

Habe letzte Woche mit einem Erweiterungsmodul auf 4 Tuner aufgerüstet und die Sat-Anlage auf ein Einkabelsystem umgestellt. Alle 4 Tuner hängen also am gleichen Kabel, am Ende ist ein 4-fach Einkabel-Verstärker mit 20cm Kabel dran.

Damit kann man nun unter gleichen Bedingungen auf einem HD-Kanal (bei mir war es bei QVC Plus HD am deutlichsten).

System ist hier auch yavdr mit einer SSD und media-build-experimental-Treibern. ddbridge und nvidia liegen laut "cat /proc/interrupts" alle auf einem eigenen IRQ. Allerdings sieht für mich das Fehlerbild wirklich nach einem HW-Problem aus, da ja die restliche Config (Treiber usw.) für alle Tuner gleich ist und das nur bei dem einen auftritt.

Ich habe mal linux4media angeschrieben. Mal sehen was da kommt. Evtl. können die die Karte testen

VG,
-Markus

D-Bus hatte ich geplant, aber erst später.
Die Idee war da, die libcec ganz zu beenden und zu entladen da ja XBMC u.U. eine eigene Instanz mitbringt und in diesem Fall der VDR nur Backend ist. Die kämen sich sonst ins Gehege.

Mit dem externen USB-Adapter kann man den VDR auch per CEC aufwecken, wenn das Board USB-Power liefert. Man benötigt also nicht zwingend den internen Adapter. Allerdings macht mein Board das nur im Soft-Off, den ich aber aus Stromgründen nicht nutze.

VG,
-Markus

Hi,
ich habe einen P8 an meinem produktiven yavdr. Habe den libcec-daemon (übel) gehackt, damit ich beim Hochfahren ein poweron und input-select vom Receiver und TV habe. Auch Abschalten von TV und Receiver beim VDR shutdown.

War damit aber nicht zufrieden und wollte eigentlich ein eigenständiges vdrcec-plugin schreiben. Den Test-P8 dazu und ein plugin-Gerüst habe ich zwar (schon), aber mangels Zeit geht es da aktuell nicht weiter.
Was das Plugin können soll (hier mal meine Gedanken aus meinem Scratchpad kopiert:

Poweron configurable list of devices upon startup
Check if wakeup for recording, then no powerup


Standby devices (optional) upon powerdown on VDR
Configurable list of devices to standby or broadcast


Do not standby if not active source (eg BD playing)


Monitor active-source (switch to eg BD player on TV/receiver)


Check if amplifier present and monitor vol control / mute


Poweroff VDR if CEC standby received


CEC remote-control keys like in libcec but configurable via conf-file

Idealerweise dahingehend abstrahiert, dass man zukünftig andere CEC Adapter (oder die geplante CEC-Unterstützung im Kernel) verwenden kann,

-Markus

Zitat von TheChief

Naja, bei einem Versionssprung von 1.7.x zu 2.0 bin ich immer davon ausgegangen, dass da was grösseres kommt. Sonst hätte es ja auch ne 1.8 getan. Das hat nichts mit "recht machen" zu tun, das war ne simple Frage.

Der Sprung ist ja auch von 1.6, dem letzten stable release. Und die Neuerung dazu verglichen rechtfertigen IMHO eher eine 2.0 als eine 1.8

Halllo,

also bei mir funktioniert mit dem Hermes (fast) alles.

Ich habe aber auch die Suse 8.1 genommen, die erkennt den Chipsatz und hat folglich mit dem DMA keine Probleme