Zuletzt geändert am 27. April 2011 um 22:44

Addon:lcd msg

Version vom 27. April 2011, 22:44 Uhr von DocZoid (Diskussion | Beiträge) (Beispiel für Priorität korrigiert)

Beschreibung

Übersicht

Das Addon lcd_msg dient dazu, die Displayfläche der CCU zu einer vollwertigen Textausgabe-Schnittstelle aufzuwerten, statt sie nur für das CCU-Menü zu verwenden. Das Menü der CCU wird durch das Addon nicht beeinträchtigt, sonder vielmehr auch erweitert. Weiterhin können zusammen mit der Textanzeige auch die Alarm- und die Service-LED, sowie die Hintergrundbeleuchtung der Station gesteuert werden.

FHZ-Forums-Thread
Datei:Lcd msg ccu.tar.gz

Features

  • Anzeige von ein- oder mehrseitigen Texten
  • Anzeige von scrollenden Texten
  • Anzeige von Texten aus verschiedenen Quellen im Wechsel ("gleichzeitige" Darstellung von verschiedenen Nachrichten)
  • Gruppierung und Sortierung von Texten
  • Texte können mit einem Timeout versehen werden (sie werden dann automatisch entfernt)
  • Texte können gruppenweise an der CCU gelöscht werden
  • Aktivierung der Alarm- und/oder der Service-LED beim Anzeigen von Nachrichten
    • Service-LED kann bis zu einer Minute blinken
    • Aktivierung kann mit einem Timeout versehen werden
  • Aktivierung der Hintergrundbeleuchtung beim Anzeigen von Nachrichten
    • Vor der Aktivierung kann die Hintergrundbeleuchtung zum Blinken gebracht werden
    • Aktivierung kann mit einem Timeout versehen werden
  • Anzeige von Texten mit Priorität (ausblenden der Texte mit niedrigerer Priorität)

Menü

Einseitige Nachricht

- (lang) = Anlernen
+ (lang) = Anlernen
Menu (kurz) = Menü "delete <group>?¶No Menu Yes"
- (kurz) = No = Zurück zur Anzeige der Nachricht
+ (kurz) = Yes = Nachricht wird gelöscht → Anzeige einer anderen Nachricht oder "CCU HomeMatic"
Menu (kurz) = Menü "Hauptmenü" (jetzt mit Anlernen als ersten Punkt)

Mehrseitige Nachricht

- (kurz) = erste Seite anzeigen
+ (kurz) = nächste Seite anzeigen
Menu (kurz) = Menü "delete <group>?¶No Menu Yes"
- (kurz) = No = Zurück zur Anzeige der Nachricht
+ (kurz) = Yes = Nachrichtengruppe wird gelöscht → Anzeige einer anderen Nachricht oder "CCU HomeMatic"
Menu (kurz) = Menü "Hauptmenü" (jetzt mit Anlernen als ersten Punkt)

Aufruf

Siehe Aufruf von Scripten aus WebUI-Programmen

/etc/config/addons/lcd_msg/display_msg.sh ['][$Parameterliste$]Seite1[|Seite2...][']

  • Die Hochkommata (') brauchen nur angegeben werden wenn es Probleme mit Leerzeichen gibt (hier kann auch <skip/> oder <skip count=n/> für ein oder n Leerzeichen verwendet werden)
  • Das Pipe-Symbol (|) vor Seite zwei und die Dollar-Zeichen ($) vor und nach der Parameterliste sind genau als solche anzugeben und nicht Teil der Parameter-Erklärung.
  • Die Parameterliste kann einen oder mehrere, mit Leerzeichen getrennte, im Folgenden beschriebene Parameter enthalten.

Parameter

Jeder Parameter der Parameterliste besteht aus einem Buchstaben und einem zugehörigen Wert.

Folgende Parameter sind definiert:

  • m<timeout> Nachrichtentimeout setzen
  • b<timeout> Hintergrundbeleuchtung aktivieren (mit Dauer)
  • g<group> Gruppennamen der Nachricht setzen (default 'msg', max 6 Buchstaben o. Zahlen)
  • i<id> Id der Nachricht setzen (default '500', max 20 Buchstaben o. Zahlen)
  • p<priority> Setzt die Priorität der Nachricht (default '500', max 20 Buchstaben o. Zahlen)
  • a<timeout> Alarm-LED aktivieren (mit Dauer)
  • s<timeout> Service-LED aktivieren (mit Dauer)
  • S<timeout> Service-LED blinken lassen (mit Dauer, max 1 Minute)
  • f<flash> Hintergrundbeleuchtung n-mal blinken lassen
  • d<script> Beim Löschen/Timeout der Nachricht das Script aufrufen
  • r<delay> Aktiviert die Scrollfunktion für überlange Textzeilen (mit regelbarer Scrollgeschwindigkeit, nur einseitig, <br/> dient als Zeilentrenner)

<group> Setzt die Nachrichtengruppe. Nachrichten lassen sich gruppenweise aus dem Menü heraus löschen. Das Menü wird durch Druck auf die Menü-Taste während der Anzeige der Nachricht aufgerufen. Es erscheint die Meldung 'del <group>?' (wobei <group> die selbst definierte Gruppe ist), die man bestätigen oder verwerfen kann. Der Gruppenname darf keine Sonderzeichen oder Leerzeichen enthalten.

<id> Setzt die Nachrichtenid. Beim Schreiben einer neuen Nachricht wird die Nachricht mit der selben id innerhalb der selben Gruppe überschrieben, während Nachrichten mit anderen ids oder anderen Gruppen weiter bestehen. Weiterhin dient die id dazu, die Nachrichten zu sortieren (Gruppenübergreifend). Die id wird nirgendwo angezeigt und kann frei gewählt werden. Die id darf keine Sonderzeichen oder Leerzeichen enthalten.

<priority> Setzt die Nachrichtenpriorität. Ein kleinerer Wert hier entspricht der umgangssprachlich höheren Priorität. Ein größerer Wert bedeutet also, dass die Nachricht weniger wichtig ist. Es werden nur Nachrichten angezeigt, die die gleiche höchste Priorität besitzen. Beispiel:

  • $m1h i1$Hallo Welt!
⇒zeigt 1 Stunde lang den Text "Hallo Welt!" mit der Standard-Priorität 500 an.
  • $m1h i2 p500$Test
⇒zeigt zusätzlich neben "Hallo Welt!" auch "Test" an. Die Angabe einer anderen id (wahlweise auch Gruppe) ist notwendig um nicht die vorherige Nachricht zu überschreiben.
  • $m1m p400$Neue Mail!
⇒zeigt eine Minute lang die Meldung "Neue Mail!" an. Während dieser Minute werden die anderen beiden Nachrichten nicht angezeigt! Nach Ablauf der Minute wird diese Meldung gelöscht, und es wird wieder im Wechsel "Hallo Welt!" und "Test" angezeigt.
Eine weitere Meldung mit p400 würde parallel zu dieser Nachricht angezeigt werden (innerhalb der Lebenszeit der Nachricht).
Eine weitere Meldung mit p300 würde diese Nachricht ausblenden (innerhalb der Lebenszeit der Nachricht).


<flash> Numerisch, gibt an, wie häufig die Hintergrundbeleuchtung blinken soll. Zur besseren Lesbarkeit wird die Hintergrundbeleuchtung hell und dunkel (nicht aus) geschaltet. Eine Bedienung der CCU ist während des Blinkvorgangs nicht empfehlenswert, daher sollte die Anzahl der Blink-Vorgänge klein gewählt werden. Nach einem Blinken ohne anschließender Hintergrundbeleuchtungsdauer wird die Beleuchtung auf die normale Beleuchtungsdauer gesetzt (dies ist notwendig, damit die Beleuchtungsdauer nicht auf 1 Sekunde stehen bleibt).

<script> Gibt an, welches Script beim Löschen, Überschreiben oder beim Timeout der Nachricht ausgeführt wird. Das Script wird mit folgenden Parametern aufgerufen: '<id> <gruppe> <unix-Zeitstempel der Nachrichtenerstellung> <überschreiben (0/1)>'

<delay> Gibt in Millisekunden die Verzögerung zwischen den einzelnen Scrollschritten an. Werte < 350 bringen keinen weiteren sichtbaren Geschwindigkeitsgewinn. Es wird keine Einheit an den Wert gehängt, wie bei timeout.

<timeout> Timeouts definieren für den jeweiligen Parameter an den sie angehängt werden die Dauer der Funktion. Sie bestehen aus einem 1-4 stelligen Wert (nnnn) und einem Buchstaben (x) zur Angabe der Einheit. Der Buchstabe wird direkt hinter den Wert geschrieben (nnnnx), und der Timeout direkt hinter den Parameter.

Folgende Zeiträume sind definiert:

  • s - Dauer in Sekunden
  • m - Dauer in Minuten
  • h - Dauer in Stunden
  • d - Dauer in Tagen

Außerdem kann ein Zeitpunkt angegeben werden:

  • t - Bis zur angegebenen Uhrzeit bezogen auf die nächsten 24 Stunden (hier sollte ein vierstelliger Wert übergeben werden, der nach hhmm codiert ist)

Beispiele:

  • $m100s$Hallo Welt!
⇒zeigt 100 Sekunden lang den Text "Hallo Welt!" an.
  • $m1h$Test
⇒1 Stunde Test
  • $m1430t$Neue Mail
⇒zeigt bis 14:30 Uhr "Neue Mail" an (Wenn die Uhrzeit überschritten wurde wird sie für den nächsten Tag angenommen).

Hinweis zur Hintergrundbeleuchtung

Es gibt bei der Hintergrundbeleuchtung grundsätzlich das Problem, dass die Beleuchtung nur an geht, wenn die neuen LCD-Parameter (z.B. Einschaltdauer) eingelesen werden. Das Problem liegt in der Umkehrung: es ist nicht möglich, der Applikation die alten LCD-Parameter wieder zurückzusetzen, ohne die Beleuchtung dabei zu aktivieren... Beispiel hierzu: Angenommen, man hat eine Leuchtdauer von 1 Minute eingestellt, und möchte eine Nachricht mit 10 Minuten Beleuchtung anzeigen lassen. Hier wird also kurzfristig (im RAM) die Konfigurationsdatei überschrieben mit dem Wert "10 Minuten", die Beleuchtung wird eingeschaltet, und die alte Konfigurationsdatei wird wieder hergestellt. Dennoch kennt das Programm nach Ablauf der 10 Minuten nur die "10-Minuten-Dauer", weil die alte Konfigurationsdatei noch nicht eingelesen wurde... Bei der Wahl der Beleuchtungsdauer also bitte berücksichtigen: die CCU läuft leider mit diesen Werten weiter.

Beispiele

  • $m20s$Hallo Welt
⇒begrüßt 20 Sekunden lang die ganze Welt
  • $gtemp iinnen m2h s5s$Temperatur innen: 20°C|Luftfeucht.innen: 80%
⇒stellt zweiseitig abwechselnd die Innen-Temperatur und Luftfeuchtigkeit für 2 Stunden dar, lässt bei neuen Werten anfangs die Service-LED 5 Sekunden leuchten
  • $gtemp iaussen m2h a5s$Temperatur außen: 11°C|Luftfeucht.außen: 55%
⇒(zusammen mit vorigem Beispiel) stellt zweiseitig abwechselnd die Außen-Temperatur und Luftfeuchtigkeit für 2 Stunden dar, lässt bei neuen Werten anfangs die Alarm-LED 5 Sekunden leuchten. Es wird der gleiche Kanal wie bei der vorigen Meldung benutzt, d.h. ein Druck der Taste Menü zeigt "del temp?", und bei Bestätigung würden beide Nachrichten gelöscht. Durch die andere Nachrichtenid wird die Innentemperatur nicht überschrieben.
  • $gwakeup m0930t b0930t$Guten<br/>Morgen!
⇒zeigt bis 9:30 morgens "Guten Morgen" mit Hintergrundbeleuchtung. Temperaturwerte (oder andere Nachrichten aus anderen Gruppen) würden dabei nicht überschrieben!
  • $m30s r400$Diese Nachricht wird in der ersten Zeile gescrollt
  • $m30s r400$Diese Nachricht wird in der ersten Zeile gescrollt<br/>Dies ist die zweite Zeile.
⇒Wenn man mehrzeilig scrollen will verwendet man einfach wie gewohnt <br/>. Gescrollt wird automatisch nur bei Überlänge der Zeile, also eine Zeile <= 11 Buchstaben wird statisch angezeigt (oben oder unten). Wenn beide Zeilen überlang sind werden sie synchron gescrollt. Das Ende der kürzeren Zeile wird so lange statisch angezeigt, bis die längere durchgescrollt ist (hier muss man also 11 Leerzeichen an die kürzere Zeile hängen damit diese ausläuft).

Weitere Scripte des Addons

reset_lcd.sh

/etc/config/addons/lcd_msg/reset_lcd.sh

Hiermit kann das Display resettet werden, falls es mal nicht reagiert.

delete_msg.sh

/etc/config/addons/lcd_msg/delete_msg.sh [g[roup] <group>] [i[d] <messageid>]

Löscht eine oder mehrere Nachrichten. Optional kann eine Gruppe und/oder eine Id angegeben werden, um das Löschen einzuschränken. Bei der Angabe einer Id ohne Gruppe werden alle Nachrichten mit dieser Id (von jeder Gruppe) gelöscht. (Vorsicht, hier muss zwischen dem g/i und der Bezeichnung ein Leerzeichen stehen, bei display_msg nicht! Ich gebe zu, nicht sehr intuitiv, müsste ich verbessern).

Beispiel:

  • delete_msg.sh g temp
⇒Löscht alle Nachrichten der Gruppe temp

flash.sh

/etc/config/addons/lcd_msg/flash.sh [<flash-count> [<light-duration>]]

Lässt das Display blinken und/oder leuchten

display_weather.sh

/etc/config/addons/lcd_msg/display_weather.sh <PLZ>

Aufruf des weather-Scriptes (wird im Addon mitgeliefert).

Alternative Anwendungsweise

Da ich das Erstellen von neuen Nachrichten immer recht kompliziert fand (Aufruf über Script), habe ich nach einer Vereinfachung gesucht. Eine (leider nicht perfekte) Möglichkeit ist das Schreiben der Texte über Systemvariablen. Hierzu legt man einfach eine Variable, z.B. lcd_msg, an, und nutzt diese, um beliebige Texte auf dem Display anzuzeigen. Dazu kann man folgendes einfaches Programm nutzen:

string stderr;
string stdout;
var x = dom.GetObject("lcd_msg").Value();
system.Exec("sh /etc/config/addons/lcd_msg/display_msg.sh "#x,&stdout, &stderr);

Das funktioniert soweit gut, jetzt wird es leider etwas unschön: wie soll man den Wenn-Teil des Programms formulieren? lcd_msg ist sinnvollerweise eine Textvariable, aber leider kann man nur Abfragen gegen numerische Werte formulieren. Vielleicht weiß ein erfahrener HM-Scripter, wie man auf Aktualisierungen der Text-Variablen das Programm ausführen kann? Ein Workaround besteht darin, das Programm an den Tastendruck eines virtuellen Kanals zu hängen. Man muss dann nach dem Setzen des Textes in der lcd_msg-Variablen diesen Kanal einmal "betätigen". Ideal wäre natürlich nur eine Variable...

Changelog

  • v1.2
    • Daemonizing beim Erstellen der Nachricht, dadurch reagiert das aufrufende ReGa-Script besser (CCU läuft runder)
    • Bugfixes in der flash.tcl, Blinken konnte niedrige Beleuchtung zurück lassen
    • Neues Feature: Priorität

Funktionsweise der zukünftigen Version

Entwicklungsbasis von MustangRocks und DocZoid für die weitere Entwicklung

Komponenten

Es gibt folgende Software-Komponenten:

  • hss_lcd.ko: Kernel-Treiber, basierend auf OpenSource, von MustangRocks weiterentwickelt, zur Ansteuerung des CCU-Displays und der LEDs und Tasten. Weiterentwickelte Version enthält zwei Kanäle, einen zur Kommunikation mit hss_lcd, und einen zur Kommunikation mit dem API.
  • hss_lcd: Programm von eq-3, welches die HTML-Interpretation der Menüdateien enthält. Ruft die Menüdateien über den Webserver auf, so dass cgi-Scripte ausgeführt werden. Kann keine LEDs ansteuern, nur Text anzeigen.
  • hss_index.cgi: Haupt-Menüdatei, welche bisher direkt den anzuzeigenden Text und einen autoswitch-timeout zurückgegeben haben, um ein refresh der angezeigten Daten zu erreichen. Die zukünftige Verwendung wird weiter unten beschrieben.
  • API: Das API wird von MustangRocks als tcl-Datei (Name) bereitgestellt, um eine einfachere Kommunikation zwischen TCL-Programmen und der hss_lcd.ko zu ermöglichen.
  • ccu_lcd: Daemon, welcher die Nachrichtenverwaltung übernimmt.

Initialisierung

  • hss_lcd wird gestartet und ruft hss_index.cgi auf.
  • in hss_index.cgi wird zunächst der ccu_lcd daemon Prozess gestartet, und ein default-String (ccu_lcd Va.b) zur Anzeige an der CCU zurückgegeben, ohne refresh-timeout.
  • in ccu_lcd wird die init-Routine des API aufgerufen, und ein TCP-Listener-Socket geöffnet (Nachrichtenannahme)
  • im API wird die initialisierung von hss_lcd.ko weitergeführt
  • hss_lcd.ko schaltet auf den zweiten Kanal zur Anzeige der eigenen Nachrichten
  • ccu_lcd zeigt ggf. bestehende Nachrichten an

Ereignisse

  • Neue Nachrichten werden durch Übertragung von TCP-Daten (Warum nicht UDP?) an ccu_lcd gemeldet. ccu_lcd verarbeitet daraufhin die Daten und hält sie für eine weitere Übermittlung an das API vor (vermutlich in Dateien).
  • Nachdem eine "showtime" von Nachrichten abgelaufen ist meldet sich hss_lcd.ko über das API beim ccu_lcd-Daemon. Dort können dann weitere Nachrichten übermittelt werden.
  • Tastendrücke werden von hss_lcd.ko abgefangen und über das API an ccu_lcd gemeldet. ccu_lcd kann dann entscheiden (über einen API-Aufruf), ob das alte Menü über den Standard-Kanal angezeigt werden soll. Langfristig müsste das alte Menü selbst dargestellt werden.

Fragen

  1. warum nicht UDP statt TCP
  2. Nachrichten in Dateien vorhalten hat den Vorteil, dass bei einem Neustart des Anzeigesystems alte Nachrichten wieder angezeigt werden können. Scheint mir (DocZoid) jedoch mehr Aufwand in der Programmierung, zumal ein Neustart des Anzeigesystem nicht notwendig sein sollte. Bei einem CCU-Neustart sind eh alle Nachrichten weg. Mal schauen inwieweit sich das alte Dateien-System übernehmen lässt.
  3. Wie werden neue Nachrichten an hss_lcd.ko gesendet? Wenn nur eine Nachricht angezeigt wird sollte hss_lcd.ko nicht ständig pollen, ob es neue Nachrichten gibt: man hätte nicht viel zum alten System gewonnen. Grundsätzlich sollten neue Nachrichten immer sofort angezeigt werden (wenn die Priorität dies zulässt), und das Pollen muss minimiert werden, sprich ccu_lcd darf dem API nur eine showtime übergeben, wenn weitere Nachrichten angezeigt werden müssen.
  4. Wer prüft auf den timeout einer Nachricht, insbesondere wenn es nur eine gibt und es kein Polling gibt?

Timeout-Überwachung

  1. LED- und Hintergrundbeleuchtungs-Timeouts werden von hss_lcd.ko überwacht
  2. Bei Nachrichten-Timeouts muss die Datei / der Datensatz in ccu_lcd gelöscht werden. Wird ccu_lcd hier extern von hss_lcd.ko getriggert?

API-Beschreibung