HB-Dis-EP-42BW - 4.2" ePaper Display

[Hoppla]

Genau das tue ich mit WriteLine.
Bis zur Darstellung des DC geht alles, dann wollte ich das Datum hinzufügen.
Ich bin aber seit heute Früh um 8 nur dabei, die 9 wegzubekommen. Erfolglos.


Was die Scriptprobleme hier angeht: Das aufteilen wurde weiter vorn schon angeregt.
Es sollte dann aber nur um die Scripte zum Display gehen, sonst wird das genau so zugeschüttet wie hier.

[chka]

Code: Alles auswählen

integer t = system.Date("%w").ToInteger() +3;
string timeCommand =  "" #t.ToString();

WriteLine( timeCommand );


string time = system.Date("%H:%M");


WriteLine(  time );


WriteLine( timeCommand # ""  # time );

Code: Alles auswählen

9
13:41
913:41

Keine Minute Arbeit

[Hoppla]

..bin ja schon ruhig

Danke

[Hoppla]

Funktioniert doch, habe wieder eine Verbindungsunterbrechung und der dc geht nicht hoch.
KA warum sich die Displays ab und an verabschieden.

Wie kann man das realisieren, denn wenn das passieren sollte wenn keiner da ist, ist es für eine einfache Fehlersuche zu spät, dann steht alles.
Bei allen anderen Geräten kann man das mit dem BI-schutz verhindern, was ja beim Display offenbar so nicht funktioniert.

[jp112sdl]

abe wieder eine Verbindungsunterbrechung und der dc geht nicht hoch.

Zu dem Fehlerbild hatte ich schon was geschrieben, aber nie eine Antwort erhalten:
Ich vermute, dass das Telegramm zu lang oder falsch aufgebaut ist, so dass es vom RFD verworfen wird.
Da gar nicht erst versucht wird zu senden, kommt weder eine Störung noch passiert was mit dem DC.

Bei allen anderen Geräten kann man das mit dem BI-schutz verhindern, was ja beim Display offenbar so nicht funktioniert.

Ich weiß zwar nicht wie das "bei allen anderen Geräten" funktioniert... aber warum soll das dann so nicht auch beim Display funktionieren?

[chka]

Zu dem Fehlerbild hatte ich schon was geschrieben, aber nie eine Antwort erhalten:
Ich vermute, dass das Telegramm zu lang oder falsch aufgebaut ist, so dass es vom RFD verworfen wird.
Da gar nicht erst versucht wird zu senden, kommt weder eine Störung noch passiert was mit dem DC.

Bisher keinen Ausfall gehabt, logge die systemvariablen aktuell mit. wennn es wieder passiert melde ich mich.

@Hoppla wie es geht steht genau unter dem was du zitiert hast

[Hoppla]

aber warum soll das dann so nicht auch beim Display funktionieren?

Ich habe hier beobachtet, das der DC sehr schnell nach oben geht, wenn das Display einfach aus ist.
So schnell habe ich das bisher bei keinem anderen Gerät gesehen.
Ein gestörtes Gerät meldet sich einfach mit "Unreach" ohne das der DC nennenswert ansteigt. Das ist der Unterschied.

@chka
Wüsste ich, was man mit der Zeile anfängt, würde ich nicht fragen.
Die Auflösung hab ich in der Scrip-Doku bisher nicht gefunden.

[jp112sdl]

Ich habe hier beobachtet, das der DC sehr schnell nach oben geht, wenn das Display einfach aus ist.

Ja das ist doch aber normal.
Jedes mal wenn du per Skript das Display ansteuerst, wird es angefunkt. Die CCU kann nicht wissen, dass "noch aus" oder "bewusst aus" ist.
Aber du hattest ja da schon mit der if-Abfrage auf UNREACH einen guten Ansatz

[chka]

UNREACH heißt nicht erreichbar
Bei UNREACH = true ist der Display nicht erreichbar!
Das ! Zeichen vor der abfrage ist die Negation also aus WAHR wird FALSCH und anders rum.

Code: Alles auswählen

  if(!dom.GetObject("BidCos-RF.JPDISEP001:0.UNREACH").State())
  {
  WriteLine("Sende die Daten an den Display");
  ...
  }
  

Übersetzt: Wenn der Display erreichbar ist sendet ich die befehle an den ihn, Grundlagen Programmierung

[Hoppla]

sorry
den Sinn der Zeile an sich habe ich schon verstanden.
daher die Frage: wie bekomme ich das zusammen.
Was fehlt, ist einfach die Syntax, das einfache Einfügen in das Script führt zuverlässig dazu, das die darauf folgende Zeile als fehlerhaft ausgegeben wird.
Das dann die geschweiften Klammern eingefügt werden müssen wusste ich einfach nicht.
Und da hilft die Doku auf eQ3 nicht wirklich weiter, weil gar nicht klar war, WAS der Fehler ist.