Leer- und Sonderzeichen im Notify-Befehl

[Muschelpuster]

Moin zusammen,

ich versuche gerade eine Anzeige auf meinem alten 1-Wire-Display etwas aufzuhübschen. Dazu würde ich gerne mehrere Leerzeichen und °C senden. Leider klappt das nicht wie gewünscht. Das °C habe ich ursprünglich mal über ein entsprechend vorformatiertes User-Reading am Temperatursensor gemacht, aber das muss doch auch eleganter gehen.
Hier mal meine Definitionen:
Display:

Code Auswählen Erweitern

defmod LCD_1F0A00000100 OWDevice FF.1F0A00000100 60Notify:

Code Auswählen Erweitern

defmod DS2438_07738D010000_notify_2 notify DS2438_07738D010000:Temperatur:.* set LCD_1F0A00000100 line20.1 Temperatur:.....$EVTPART1°CMit den Punkten funktioniert das natürlich, aber eleganter wären Leerzeichen. '°C' erzeugt Steuerzeichen auf dem Display, obwohl es laut State des Display erst einmal ok ist:

Code Auswählen Erweitern

setstate LCD_1F0A00000100 2023-10-05 12:20:30 line20.1 Temperatur:.....29.2°CNun könnte man ja sagen, dass das Display das nicht kann, aber wie geschrieben - wenn das schon im User-Reading drin ist funktioniert es, was die Annahme relativiert.

Niels

[JoWiemann]

Hallo,

OWDevice muss im set Befehl mit Leerzeichen umgehen können. Schon mal:

set LCD_1F0A00000100 line20.1 "Temperatur:     $EVTPART1°C" oder set LCD_1F0A00000100 line20.1 Temperatur:%20%20%20%20%20$EVTPART1°C probiert?

Grüße Jörg

[Muschelpuster]

Danke Jörg,

aber da steht dann auch %20 im Display. Das Reading mit °C erzeuge ich übrigens mit:

Code Auswählen Erweitern

attr DS2438_07738D010000 userReadings TemperaturD { int ( 10 * ReadingsVal("DS2438_07738D010000","temperature",0) + 0.5 ) / 10 .chr(223)."C"}Da steht dann auf der FHEM GUI Müll im Reading, dafür aber was Vernünftiges im Display 
Eine rustikaler Ansatz war auch nicht erfolgreich:

Code Auswählen Erweitern

attr DS2438_07738D010000 userReadings TemperaturD { chr(32).chr(32).chr(32).chr(32). int ( 10 * ReadingsVal("DS2438_07738D010000","temperature",0) + 0.5 ) / 10 .chr(223)."C"}
Niels

[TomLee]

Weit hergeholt, aber evtl. funzt es ja ?

Code Auswählen Erweitern

defmod DS2438_07738D010000_notify_2 notify DS2438_07738D010000:Temperatur:.* { my $zeile_1 = sprintf('Temperatur:%9s chr(223) C',$EVTPART1);fhem ("set LCD_1F0A00000100 line20.1 $zeile_1")}

[Muschelpuster]

Weit hergeholt, aber evtl. funzt es ja ?

Leider nein. Es steht Temperatur 40.0 chr auf dem Display. Aber das °C war ja eher sportlicher Ehrgeiz das schicker zu bekommen, interessanter sind die Leerzeichen.

Danke
Niels

[rudolfkoenig]

#1 Leerzeichen:
- der FHEM set Befehl teilt die Zeile anhand Leerzeichen und Tabs in Woerter auf, und ruft die Modul eigene set Funktion mit diesen Woertern auf.
- fuer Leerzeichen muss das Modul diese Woerter entweder selbst zusammenkleben, oder die parseParams Funktionalitaet unterstuetzten.
- wenn weder/noch der Fall ist, dann hilft es nur die Modul eigene set Funktion direkt aufzurufen mit

Code Auswählen Erweitern

{ OWDevice_Set($defs{LCD_1F0A00000100}, ("LCD_1F0A00000100", "line20.1", "Temperatur:  $EVTPART1°C")) }(ungetestet).

#2 Sonderzeichen.
- FHEM-Intern sollte alles als UTF-8 Strings gespeichert sein, damit werden Sonderzeichen als eine Bytefolge gespeichert.
- es sei denn, man hat "attr global encoding unicode" gesetzt, dann werden Sonderzeichen als "wide character" gespeichert. Da das noch "relativ" neu und nicht die Voreinstellung ist, sind sicher nicht alle Module dafuer bereit.
- in diesem konktreten Fall muss man auch wissen, welchen Zeichensatz die Anzeige braucht, und ob das Modul eine Konvertierung vornimmt. Wenn nicht, dann ist man gezwungen die Sonderzeichen als \x... im perl String zu kodieren, mit der oben beschriebenen Methode.
- zwischen vorformatiertes Userreading und "direkte" Eingabe gibt es keinen Unterschied. 

[Muschelpuster]

Danke Rudi,

so klappt es mit den Leerzeichen. Das Grad-Zeichen funktioniert so jedoch nicht, auch nicht nach Anpassung des globalen Attributs. Damit ging es dann auch nicht mehr aus meinem Userreading, vermutlich hätte ich da dann einen anderen Code nehmen müssen (nicht ASCII, sondern UTF16?), was aber auch nicht auf Anhieb geglückt ist. Aber da ist ja ggf. auch der Zeichensatz des Displays dominierend. Daher habe ich an dieser Stelle zurück gerudert und empfinde die Herausforderung in Kombination mit dem Userreading als gelöst.

Niels