FHEM - Anwendungen > Multimedia

[reloaded] TvHeadend-Modul

<< < (3/6) > >>

Beta-User:
...einen habe ich noch gefunden: Die Attribute in .AttrList scheinen sich zu vervielfachen...

Fix (hoffentlich) - Zeile 511 so ändern:

--- Code: ---my $devattrs = $defs{$name}{'.AttrList'} // getAllAttr($name);
--- Ende Code ---

--- Zitat von: alanblack am 13 Oktober 2021, 22:05:02 ---Ich habe inzwischen die API für die Input-Devices vom TVHeadend-Server gefunden. Ich schaue mal, was ich davon umsetzen kann.

--- Ende Zitat ---
Bitte gib Bescheid, wenn du Hilfe brauchst.

Vielleicht noch was für den Hinterkopf: Wenn man einen nicht administrativen Nutzer hat, gibt es auch entsprechende Rückmeldungen, wenn man was versucht, was nicht erlaubt ist (war eine der Absturzursachen aus dem anderen Thread, weil dann kein JSON zurückkommt). Vielleicht muss/sollte man das irgendwo sichtbar machen, dass bzw. mit welchem Ergebnis das gecheckt wurde.

alanblack:

--- Zitat von: Beta-User am 13 Oktober 2021, 22:37:41 ---...einen habe ich noch gefunden: Die Attribute in .AttrList scheinen sich zu vervielfachen...

Fix (hoffentlich) - Zeile 511 so ändern:

--- Code: ---my $devattrs = $defs{$name}{'.AttrList'} // getAllAttr($name);
--- Ende Code ---

--- Ende Zitat ---
Bisher habe ich auch ohne diesen Fix keine Vervielfachung erkennen können. Ich habe ein Auge darauf.

--- Zitat ---[Input-Devices]
Bitte gib Bescheid, wenn du Hilfe brauchst.
--- Ende Zitat ---
OK! Danke für das Angebot! Werde aber frühestens nächste Woche Zeit finden.

--- Zitat ---Vielleicht noch was für den Hinterkopf: Wenn man einen nicht administrativen Nutzer hat, gibt es auch entsprechende Rückmeldungen, wenn man was versucht, was nicht erlaubt ist (war eine der Absturzursachen aus dem anderen Thread, weil dann kein JSON zurückkommt). Vielleicht muss/sollte man das irgendwo sichtbar machen, dass bzw. mit welchem Ergebnis das gecheckt wurde.

--- Ende Zitat ---
Wäre vielleicht etwas, das den STATE beeinflussen könnte, so in der Art: Server liefert reguläre Antworten => STATE = "connected" (oder so) - irgendein Input geht nicht => STATE = "warning" - User macht Unsinn => STATE = "alert". Auch nur für den Hinterkopf; eigentlich aber, weil mich die "? ? ?" im STATE irritieren. 

Grüße

Beta-User:
Das mit "sehr vielen comment-Einträgen" ist bei mir halt vorgekommen, warum auch immer. Jetzt mit dem fix erst mal auch nicht mehr ;D .

Was STATE angeht => stateFormat würde helfen. Mit dem "verfrühten" Füllen des Readings "state" habe ich so meine Erfahrungen gemacht, seither reserviere ich das für den "Hauptschalter" ;D ...

Aber sowas wie ein "connection"-Reading würde Sinn machen, etwa in die Richtung: unreachable, unauthorized, ok, priviledged. Tendenziell würde man sowieso sowas wie eine "ping"-Routine brauchen (Rudi hat da was im Repertoire, man braucht kein qx...).

Das Logging von den nächsten Verbindungsversuchs-Zeiten auf Level 3 erscheint mir auch nicht optimal, sollte eigentlich auch eher ein Reading sein.

(Vielleicht bei Gelegenheit mal).

alanblack:

--- Zitat von: Beta-User am 13 Oktober 2021, 22:37:41 ---[InputDevices]
Bitte gib Bescheid, wenn du Hilfe brauchst.

--- Ende Zitat ---
Die Abfrage habe ich eingebaut. Ich bin mir nicht klar, ob ich die Devices in Attribute, ein Internal (aktuell) oder Readings ablegen sollte. Die "activeInputDevices" habe ich auf jeden Fall als Reading angelegt. Nur hatte ich irgendetwas mit dem InternalTimer darauf falsch gemacht. Damit war FHEM eingefroren. Das ist hier komplett wieder draußen. Kannst Du mir da mal bitte zumindest einen Ansatz geben. Danke!

Grüße

CoolTux:

--- Zitat von: Beta-User am 14 Oktober 2021, 20:51:58 ---Das mit "sehr vielen comment-Einträgen" ist bei mir halt vorgekommen, warum auch immer. Jetzt mit dem fix erst mal auch nicht mehr ;D .

Was STATE angeht => stateFormat würde helfen. Mit dem "verfrühten" Füllen des Readings "state" habe ich so meine Erfahrungen gemacht, seither reserviere ich das für den "Hauptschalter" ;D ...

Aber sowas wie ein "connection"-Reading würde Sinn machen, etwa in die Richtung: unreachable, unauthorized, ok, priviledged. Tendenziell würde man sowieso sowas wie eine "ping"-Routine brauchen (Rudi hat da was im Repertoire, man braucht kein qx...).

Das Logging von den nächsten Verbindungsversuchs-Zeiten auf Level 3 erscheint mir auch nicht optimal, sollte eigentlich auch eher ein Reading sein.

(Vielleicht bei Gelegenheit mal).

--- Ende Zitat ---

Vielleicht hilft das etwas beim Thema connection

https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV



Grüße

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln