Seite 1 von 2

HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 20.02.2021, 17:40
von f0obar
Hallo,

ich habe daheim in 5 Räumen Multiroom-Lautsprecher und würde nun gern in jedem Raum ein kleines Display anbringen, was anzeigt, was gerade läuft (Name des Künstlers, Songs und Albums). Natürlich nur die ersten 12 Buchstaben, scrollen ist ja nicht drin. Aber auch Play/Pause und die Lautstärke sollen regelbar sein.

Dafür würde ich gern jeden Raum mit einem HM-ePaper-Display austatten (z.B. HmIP-WRCD). Ich habe das schon Proof-of-Concept-mäßig umgesetzt (mittels Home Assistant), mir fehlt jetzt nur noch die Hardware. Um die konkrete Realisierung soll es auch gar nicht gehen. Meine Frage bezieht sich auf den Duty-Cycle und ob das überhaupt realistisch ist. Dazu habe ich folgende Gedanken:
  • Ich muss mindestens alle ~3 Minuten ein Update an bis zu 5 Displays senden.
  • Wenn man mal ein, zwei Lieder überspringt, werden auch gleich mal 15 Updates innerhalb kürzester Zeit verteilt (2x Skip und der 3. Song wird dann angezeigt). Hier könnte man noch ein bisschen optimieren, dass man die Displays erst etwas verzögert aktualisiert, aber das ist trotzdem eine Annahme.
  • Ich rechne daher erstmal mit insgesamt ca. 150 Updates pro Stunde für die Displays, die die CCU irgendwie handeln muss.
  • Der Duty-Cycle meiner derzeitigen Installation ist im Mittel im einstelligen Prozentbereich. Wenn wirklich mal viel los ist, komme ich auf knapp 20%.
Was natürlich super wäre, wenn die CCU ein Update als Broadcast an alle Displays senden könnte (ähnlich wie bei den virtuellen Direktverknüpfungen), das würde enorm viel Funkkommunikation einsparen. Aber ich vermute das wird bei den Display-Kanälen nicht gehen.

Was meinen die Spezis? Ist das Vorhaben DC-technisch realistisch oder doch zu heavy? Wie würde das Vorhaben bei nur einem Display aussehen (wären 30-40 Updates pro Stunde handhabbar)?


Danke und Grüße
f0obar

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 20.02.2021, 21:57
von Xel66
f0obar hat geschrieben:
20.02.2021, 17:40
[*]Ich rechne daher erstmal mit insgesamt ca. 150 Updates pro Stunde für die Displays, die die CCU irgendwie handeln muss.
Die CCU ist nicht das Problem, aber Dein Duty Cycle. Es muss immer der ganze Inhalt des Displays übertragen werden. Ich hatte mal so einen Displaytaster, der nur Daten bei Tastenbetätigung angezeigt hat und durch ein Script befüllt wurde. Das Spielen damit hatte massive Auswirkungen auf den Duty Cycle. Ich gehe davon aus, dass dieses auch bei den ePaper-Teilen nicht anders ist.
f0obar hat geschrieben:
20.02.2021, 17:40
Was natürlich super wäre, wenn die CCU ein Update als Broadcast an alle Displays senden könnte (ähnlich wie bei den virtuellen Direktverknüpfungen)
Da hast du keine Wahl. Es muss jedes Gerät separat angesprochen werden, weil man als Anwender keinerlei Zugriff auf die Art und Weise der Kommunikation hat.

Gruß Xel66

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 23.02.2021, 14:22
von Worka
Ich habe das Display eine Zeitlang selber benutzt (benutze nun die IP Variante) und halte das Vorhaben aufgrund des Duty Cycle Verbrauchs für aussichtslos.

Jede Änderung des Displayinhaltes sieht mal gleich im Duty Cycle.

Ich habe mal eben ein Programm gemacht, welches einfach nur den Text der Zeile2 auf den Textblock1 ("Schlafzimmer")setzt. Alleine das lässt bei jeder Auslösung den Duty Cycle um 1% ansteigen. Du müsstest ja sogar einen freien Text übertragen.

Sende ich den selben Text ("Schlafzimmer") als freien Text an das Display, so schlägt jede Aktualisierung mit 1%-2% zu Buche.
Stelle ich das Display auf Netzbetrieb, ändert sich daran kaum etwas. Das senden des freien Textes verbraucht so immer noch 1%.

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 23.02.2021, 15:24
von f0obar
Hallo und danke für das wertvolle Feedback. Das hatte ich fast schon ein bisschen befürchtet.

Jetzt wird's zwar Off-Topic aber kennt jemand Alternativen zu dem Display außerhalb des HM-Universums?

Ich brauche halt etwas, was man in einen 55er Rahmen einbauen kann, es muss batteriebetrieben sein und mind. 2 Buttons haben. Alternativ habe ich auch schon überlegt, mir einfach noch ein paar Funkmodule zuzulegen und an jedes nur 1-2 Displays anzulernen. Damit mache ich das Frequenzband dann zwar auch ziemlich zu, ist ja aber trotzdem rechtlich sauber (im Gegensatz zum Herumbasteln am DC-Limit). Na mal sehen.

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 23.02.2021, 18:01
von MichaelN
Ich würde das einfach über eine app am Handy steuern. Ich habe schneller das Handy in der Hand als zum Display gelaufen. Davon abgesehen das du dann eine bessere Benutzeroberfläche hast.

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 23.02.2021, 18:16
von f0obar
Ne, mit dem Handy mache ich das ja im Moment. Das ist sehr unkomfortabel, das hat man ja auch nicht immer einstecken.

Wir haben halt oft beim Rumwuseln im Haus in mehreren Räumen Musik an, da will man manchmal mal eben schnell wissen, was/wer das gerade ist. Da holt man nicht erst das Handy raus, zumal man manchmal nichtmal die Hände dafür frei hat (z.B. beim Putzen oder Kochen). 😁

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 23.02.2021, 21:47
von Ondas[tm]
In jedem Zimmer ein günstiges Tablet an die Wand, damit kann man noch viel mehr visualisieren. Einfach eine Frage der zuspielenden Software,

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 24.02.2021, 16:41
von dtp
Ondas[tm] hat geschrieben:
23.02.2021, 21:47
In jedem Zimmer ein günstiges Tablet an die Wand, damit kann man noch viel mehr visualisieren. Einfach eine Frage der zuspielenden Software,
Das stimmt zwar, aber man benötigt dann auch jeweils eine Stromversorgung, was mitunter etwas aufwändig sein kann.

Ein ePaper-Display mit gerade mal 12 Zeichen zur Anzeige von Musiktiteln halte ich aber ehrlich gesagt auch nicht gerade für zielführend.

Eine günstige Alternative könnte noch ein Echo Show 5 sein, den es häufig bei Amazon für unter 45,- € gibt. Evtl. lässt sich der in Verbindung mit dem passenden Skill auch zur Anzeige der gespielten Musiktitel motivieren. Man kann ihn aber auch mit einer ioBroker-Visualisierung nutzen.

Großer Vorteil von Echo Show und Tablet ist die gute Sichtbarkeit bei schlechten Lichtverhältnissen. ePaper-Displays müssen dagegen häufig beschienen werden.

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 24.02.2021, 18:25
von Fonzo
f0obar hat geschrieben:
23.02.2021, 18:16
Ne, mit dem Handy mache ich das ja im Moment. Das ist sehr unkomfortabel, das hat man ja auch nicht immer einstecken.
Wie wäre es dann z.B. mit einer Smart Watch, die hat man am Handgelenk, dann muss man weder irgendwo hinlaufen um was nachzuschauen, Du hast eine passende Benutzeroberfläche und Probleme mit dem Funk und Duty Cycle hast Du auch keine.

Re: HM-ePaper-Display: Abschätzung DutyCycle bei Multimediasteuerung

Verfasst: 26.02.2021, 07:23
von dtp
Fonzo hat geschrieben:
24.02.2021, 18:25
Wie wäre es dann z.B. mit einer Smart Watch,
Da böte sich dann natürlich das Apple-Ökosystem an. iPhone, Apple Watch, Apple Music, HomePod und HomePod Mini. That's it. 8)

Aber auch bei Apple ist leider nicht alles Gold, was glänzt. Trotzdem, kaum ein System greift derzeit so harmonisch ineinander. Kann man ja problemlos mit Macs, iPads und ggf. CarPlay ergänzen. Verträgt sich aber auch ganz gut mit Windows-Rechnern, die ich persönlich bevorzuge.

Aber die Idee mit den i-Paper-Displays von HomeMatic würde ich hier wieder verwerfen. Sind zwar teilweise ganz praktisch, aber als Informationsgeber mit ihrer kleinen Schrift und ihrer schlechten Ablesbarkeit bei ungünstigen Lichtverhältnissen nur bedingt tauglich. Wir haben auch eines im Schlafzimmer als Lichtschalter und als Anzeige, ob die Haustür abgeschlossen, das Licht im EG und UG ausgeschaltet sowie die Fenster im EG und UG geschlossen sind. Aber wirklich draufschauen tun wir aus besagten Gründen eigentlich nie.