39_DLCD.pm - kleines Hilfsmodul um Datenzeilen für serial LCD vorzubereiten v2.0

Begonnen von epsrw1, 12 Juni 2014, 20:04:31

Vorheriges Thema - Nächstes Thema

epsrw1

update:
# $Id: 39_DLCD.pm 1114 2014-09-04 18:26:00Z Florian Duesterwald $


-> LogLevel attr geändert
-> zusätzlicher Logeintrag incl. Datenzeile bei warnmeldung "daten zu lang"
Ich habe keine Ahnung, aber davon wenigstens ganz viel

epsrw1

Zitat von: Tobias am 04 September 2014, 15:45:14
Nur so als Frage: sonderzeichen und Umlaute hast du auch berücksichtigt?
http://forum.fhem.de/index.php/topic,25727.msg187535.html#msg187535

update:
# $Id: 39_DLCD.pm 1115 2014-09-05 00:12:00Z Florian Duesterwald $

attr: dlcdReplaceRegex

;)
Ich habe keine Ahnung, aber davon wenigstens ganz viel

kpwg

Hallo Florian,

seit gut drei Wochen läuft das Modul nun produktiv. Ich bediene damit zwei Displays über LAN, welche an einer Eigenbau-Plattform mit ATMega32 und Ethersex hängen. Dabei schreibe ich 24/7 alle 15 Sekunden ein paar Werte in die Zeilen. Ich meine, das es als "stabil" gelten kann.  8)

Jetzt wo es draußen wieder kälter wird (aktuell 9°C), fiel mir dennoch ein Problem (Wunsch) bei der Formatierung auf:
Mit dlcdVal3formatnum 3+1+- erreiche ich theoretisch stets drei Stellen inkl. einer Nachkommastelle und Vorzeichen. Das funktioniert jedoch nicht, wenn vor dem Komma nur einstellige Werte geliefert werden. Eine führende Null oder besser ein Blankspace wäre hier für einen Erhalt der Formatierung sinnvoll. Für bessere Lesbarkeit sollte dann sogar das Vorzeichen an den einstelligen Wert "heranrücken", also seinen Platz mit dem eingefügten Blankspace tauschen. Hast du eine Idee?

Viele Grüße, Ricardo

epsrw1

Zitat von: kpwg am 22 September 2014, 08:51:55
Jetzt wo es draußen wieder kälter wird (aktuell 9°C), fiel mir dennoch ein Problem (Wunsch) bei der Formatierung auf:
Mit dlcdVal3formatnum 3+1+- erreiche ich theoretisch stets drei Stellen inkl. einer Nachkommastelle und Vorzeichen. Das funktioniert jedoch nicht, wenn vor dem Komma nur einstellige Werte geliefert werden. Eine führende Null oder besser ein Blankspace wäre hier für einen Erhalt der Formatierung sinnvoll. Für bessere Lesbarkeit sollte dann sogar das Vorzeichen an den einstelligen Wert "heranrücken", also seinen Platz mit dem eingefügten Blankspace tauschen. Hast du eine Idee?

schön daß es stabil läuft :)

in der theorie sollten die führenden nullen drin sein. bei zahlen ohne nachkommastelle funktioniert das auch richtig.
warum es bei float nicht klappt finde ich die nächsten tage raus wenn ich zeit habe. (sprintf ist immer wieder überraschend)

LG, florian
Ich habe keine Ahnung, aber davon wenigstens ganz viel

moemoe

Hi,

danke für das Modul, ich hatte gerade angefangen mir das alles händisch zusammezufrickeln.

Ein paar Dinge sind mir noch aufgefallen:
- Das leidige Zeichenproblem, so gibt bei mir \xDF ein °-Zeichen, was ich aber dank Unicode so nichtmal gescheit gesendet bekomme. Daher hatte ich die Idee, zwei Attribute einzuführen, replaceFrom und replaceTo. Das sind beides Listen von irgendwie-getrennten Werten (das Zeichen ist dann natürlich verbrannt, ich würde , oder . vorschlagen), und dann wird einfach 1:1 ersetzt. Würde ich auch die Tage selber implementieren und dir ein Patch schicken wenn du nichts dagegen hast ;)
- Scrollen 1: Lässt sich irgendwie eine Geschwindigkeit vorgeben? Über das langsame i2c hier ist die Zeile kaum fertiggeschrieben, wenn sie schon wieder entfernt wird
- Scrollen 2a: Ich würde mir ein Parameter wünschen, um erst ab Zeile n zu scrollen, also oben ein paar feststehende Zeilen zu haben.
- Scrollen 2b: Eine Option, um die Zeilen vertikal zu scrollen, falls der Text nicht reinpasst, wäre grandios.

Die Scrolldinge sind jetzt nicht soo dringend, vielleicht nehme ich mich denen auch mal an wenn ich Lust darauf habe.

Grüße
Moritz

epsrw1

Das attr ReplaceRegex löst Dein Problem :)

Mit dem scrollen habe ich auch mal darüber nachgedacht, aber erstmal auf die lange Bank geschoben.
Ab Zeile x läßt sich leicht lösen durch aufteilen in ein dlcd für den statischen teil und ein zweites für die Folgezeilen mit scrolling.

Horizontales scrolling ist bei den meisten günstigen China Displays nicht möglich da das Zeile beschreiben sehr lange dauert.
Gerne lasse ich mich eines besseren belehren :))
Ich habe keine Ahnung, aber davon wenigstens ganz viel

moemoe

Zitat von: epsrw1 am 22 September 2014, 20:57:29
Das attr ReplaceRegex löst Dein Problem :)
Da war ich blind, danke...

Edit: Aber auch nur halb – das 8bit-Sonderzeichen muss ich da immernoch irgendwie reinbekommen, ein \xDF wird ja nicht fhem-seitig expandet :/

Zitat von: epsrw1 am 22 September 2014, 20:57:29
Mit dem scrollen habe ich auch mal darüber nachgedacht, aber erstmal auf die lange Bank geschoben.
Ab Zeile x läßt sich leicht lösen durch aufteilen in ein dlcd für den statischen teil und ein zweites für die Folgezeilen mit scrolling.
Manchmal kann es so einfach sein :)

Edit: Öhm, dann brauche ich im Ausgabekommando ja einen Offset, also sozusagen ein
attr dlcdTriggerCmd set lcd_wand writeXY 0,%L+2%,20,1 %T%

Derzeit geht es ja nur mit einer einzelnen durchscrollenden Zeile, wenn ich L hart ersetze.

Zitat von: epsrw1 am 22 September 2014, 20:57:29
Horizontales scrolling ist bei den meisten günstigen China Displays nicht möglich da das Zeile beschreiben sehr lange dauert.
Gerne lasse ich mich eines besseren belehren :))
Nur ist das hier kein billiges China-Display – aber ja, der Flaschenhals ist I2C ;)

Wobei ich gerade gesehen habe, dass Format 3+0 ja mit 0en paddet. Dazu findet sich im Wiki
Die möglichen Optionen sind in einer Liste fest vorgegeben, um Fehleinstellungen zu vermeiden. Über das configfile können Eigenkreationen eingestellt werden, die nicht in der Liste enthalten sind.

Welches Configfile meinst du hier? fhem.cfg? Ich hätte gerne kompletten Zugriff auf die Formatstrings, oder einen anderen Weg zu " "-gepaddeten Strings, so wie ich das sehe ist das im Code aber gar nicht vorgesehen?

Grüße
Moritz

epsrw1

Öhm, dann brauche ich im Ausgabekommando ja einen Offset, also sozusagen ein
attr dlcdTriggerCmd set lcd_wand writeXY 0,%L+2%,20,1 %T%
Derzeit geht es ja nur mit einer einzelnen durchscrollenden Zeile, wenn ich L hart ersetze.
-->zutreffend.

Welches Configfile meinst du hier? fhem.cfg? Ich hätte gerne kompletten Zugriff auf die Formatstrings, oder einen anderen Weg zu " "-gepaddeten Strings, so wie ich das sehe ist das im Code aber gar nicht vorgesehen?
-->in der fhem config kann man user defined zB formatnum 34+2+- einstellen.
wenn Du eine gute idee für den genannten "vollen zugriff" hast, insbesondere eine vernünftige syntax die sich einem durchschnittsuser gut erklären läßt, dann raus mit der sprache ;)

LG florian

PS: die scrollgeschwindigkeit läßt sich übrigens mit dem pollInterval beeinflussen
Ich habe keine Ahnung, aber davon wenigstens ganz viel

moemoe

So, ich habe mir das Problem gerade noch einmal angesehen mit den Regexps. Ich würde folgende Änderung vorschlagen:

410         foreach(@rex){
411             my($search,$replace)=split(/=/,$_);
412             $replace =~ s/\\(
413                     (?:x\{[0-9a-fA-F]+\}) |        # more than 2 digit hex
414                     (?:N\{U\+[0-9a-fA-F]{2,4}\})   # unicode by hex
415                     )/"qq|\\$1|"/geex; 
416             $txt=~s/$search/$replace/g;
417             }
418         }   


Damit ist es weiterhin möglich, wie bisher zu ersetzen – allerdings kommen zwei Sonderfunktionen hinzu:
\x{hex-code}, zB \x{DF} wird zu °
\N{U+code}, zB \N{U+0041}und  \N{U+41} werden zu A und A

Siehe auch http://stackoverflow.com/questions/3845518/how-do-i-convert-escaped-characters-into-actual-special-characters-in-perl

Somit kann einerseits wie bisher ersetzt werden, wer aber wirklich definieren möchte welchen 8bit-Code an das Display geschickt wird kann es mit \x{ab} machen.

Somit tut dann auch mein ° endlich: dlcdReplaceRegex °=\x{DF} => es wird wirklich binär 11011111 ans Display geschickt.

Ich würde für den vollen Zugriff einfach ein weiteres Attribut vorsehen, dlcdVal{n}formatstring, wenn das gesetzt ist setzt es dlcdVal{n}formatnum außer Kraft. Somit gibt es weiterhin die einfache Möglichkeit, aber wer möchte (und formatstrings versteht) kann machen was immer sprintf hergibt. Ich sehe hier keine Notwendigkeit oder Möglichkeit das einfacher darzustellen, aber an so vielen Stellen in FHEM wird es komplizierter und man kann Dinge kaputtmachen, und wer es nicht nutzen möchte oder kann tut es eben nicht. Den Benutzer hier auf Kosten von eigentlich einfach möglichen Features "vor sich selbst" zu schützen halte ich persönlich für kein gelungenes Konzept.

Und wenn wir gerade dabei sind:

226     my($date_dmy)=$mday.".".$mon.".".$Year;

da standen : statt ., laut Doku/Wiki sollten es aber auch . sein.

Grüße
Moritz

epsrw1

Zitat von: moemoe am 23 September 2014, 11:41:24
So, ich habe mir das Problem gerade noch einmal angesehen mit den Regexps. Ich würde folgende Änderung vorschlagen:

410         foreach(@rex){

Damit ist es weiterhin möglich, wie bisher zu ersetzen – allerdings kommen zwei Sonderfunktionen hinzu:
\x{hex-code}, zB \x{DF} wird zu °
\N{U+code}, zB \N{U+0041}und  \N{U+41} werden zu A und A
Siehe auch http://stackoverflow.com/questions/3845518/how-do-i-convert-escaped-characters-into-actual-special-characters-in-perl
Somit kann einerseits wie bisher ersetzt werden, wer aber wirklich definieren möchte welchen 8bit-Code an das Display geschickt wird kann es mit \x{ab} machen.
Somit tut dann auch mein ° endlich: dlcdReplaceRegex °=\x{DF} => es wird wirklich binär 11011111 ans Display geschickt.

Und wenn wir gerade dabei sind:

226     my($date_dmy)=$mday.".".$mon.".".$Year;

da standen : statt ., laut Doku/Wiki sollten es aber auch . sein.

erledigt.

Zitat von: moemoe am 23 September 2014, 11:41:24
Ich würde für den vollen Zugriff einfach ein weiteres Attribut vorsehen, dlcdVal{n}formatstring, wenn das gesetzt ist setzt es dlcdVal{n}formatnum außer Kraft. Somit gibt es weiterhin die einfache Möglichkeit, aber wer möchte (und formatstrings versteht) kann machen was immer sprintf hergibt. Ich sehe hier keine Notwendigkeit oder Möglichkeit das einfacher darzustellen, aber an so vielen Stellen in FHEM wird es komplizierter und man kann Dinge kaputtmachen, und wer es nicht nutzen möchte oder kann tut es eben nicht. Den Benutzer hier auf Kosten von eigentlich einfach möglichen Features "vor sich selbst" zu schützen halte ich persönlich für kein gelungenes Konzept.

-> L.243 ff im dateianhang. wenn es das ist was Du Dir vorgestellt hast bau ich das noch in die attr ein.

so macht das spaß ;)

LG, florian
Ich habe keine Ahnung, aber davon wenigstens ganz viel

moemoe

Du hast vergessen das Attribut zu definieren, ich habe das für dich mal nachgeholt (und da mit ein paar Schleifen das c&p-Coding aufgeräumt ;)
[EDIT: Sehe jetzt erst dein Edit :DD]

Sieht aus als tut jetzt alles, nur irgendwie mag mein LCD keine mehreren Leerstellen hintereinander, da muss ich nochmal nach schauen was da los ist...

Grüße

epsrw1

habe gerade noch was eingebaut für den offset, dlcdLineAddrMap

edit:
hat sich jetzt leider überschnitten, wo genau hast Du aufgeräumt?
Ich habe keine Ahnung, aber davon wenigstens ganz viel

epsrw1

Zitat von: moemoe am 23 September 2014, 12:48:02
Sieht aus als tut jetzt alles, nur irgendwie mag mein LCD keine mehreren Leerstellen hintereinander, da muss ich nochmal nach schauen was da los ist...

das problem ist bekannt und liegt im displaytreiber verborgen.
Ich habe keine Ahnung, aber davon wenigstens ganz viel

moemoe

Zitat von: epsrw1 am 23 September 2014, 12:59:46
edit:
hat sich jetzt leider überschnitten, wo genau hast Du aufgeräumt?

Z. 243-247
Z. 435ff sub _dlcdAttribs($@){

Zitat von: epsrw1 am 23 September 2014, 13:02:05
das problem ist bekannt und liegt im displaytreiber verborgen.

Das debugge ich gerade, denn im Moment kommen die mehrfachen Leerzeichen nichtmal bei LiquidCrystal.pm an.

Edit: Da ist der Displaytreiber vollkommen unschuldig, das liegt daran dass FHEM selber schon Kommandos an Leerzeichen in einzelne Argumente splittet, und daher mehrfache Leerzeichen verloren gehen.

epsrw1

Zitat von: moemoe am 23 September 2014, 13:08:39
Z. 435ff sub _dlcdAttribs($@){

ich nehme die lange liste da drin in kauf da die werte aus einer tabelle rauskopiert werden die gleichzeitig basis für den wikitext ist. vereinfacht mir die pflege ;)
Ich habe keine Ahnung, aber davon wenigstens ganz viel