Test Adapter Weather-Warnings

[Chris76e]

@ticaki sagte in Test Adapter Weather-Warnings:

Zu 1. du kannst dir in Vorlagen alles zusammenbauen was du gerne hättest. Zur Zeit kann ich alle unter level 3 wegen dem Testen nicht filtern und da brauche ich die bekannten Farbnamen. widerstrebt mir gerade, weiß nicht wieso... kann sein weil ich hell grün bis weiß für DWD level 1 noch immer als zu kräfig empfinde. Ich denke drüber nach.

Jetzt habe ich es erst gefunden das man im Adapter bei den Vorlagen

_customHex

anlegen muss und dann zum Beispiel das eintragen kann

${[0,#FFFF00,#FFA500,#ff0000,#ee82ee]warnlevelnumber}}

erst dann wird der DP _customHEX erstellt.

[ticaki]

@chris76e

ja Vorlagen die mit _beginnen werden in die Datenpunkte geschrieben, aber nicht in der Auswahl im Admin angezeigt. Kannt aber alle Vorlagen in andere verwenden, aber keine Kreise machen, das wird noch nicht abgefangen.

[Chris76e]

@ticaki sagte in Test Adapter Weather-Warnings:

Vorlagen die mit _beginnen werden in die Datenpunkte geschrieben

Das wusste ich nicht, habe ich irgendwie überlesen.

[ticaki]

update was kompliziertes

folgende Vorlagen sind jetzt möglich :

_customAlexaIf

Warnung ${(0>cdfuture)ist seit#wird in}${(0<cdhour)\${_CustomIfHours\}} ${cdminute} Minute${(1!=cdminute)n} aktiv.

_CustomIfHours:

 ${cdhour} Stunde${(1!=cdhour)n} 

raus kommt:

Warnung wird in 2 Stunden 2 Minuten aktiv.
Warnung wird in 48 Minuten aktiv.

Das ist ziemlich empfindlich und klappt nur wenn alles richtig ist.
Es gehen < > = !=
Syntax ist
${(wert<Token)ergebnis1#ergenis2} - true#false
${(wert<Token)ergebnis1} - true

ergebnis kann: \${token\}oder \${_vorlage\}sein. Natürlich auch ein String.

Damit hab ich dann das 0 Minuten, 1 Minute, 2 Minuten auch darstellbar.

Die 2. Vorlage ist hier zwingend nötig, da in dieser Funktion zwar Tokens/Vorlagen aufgelöst werden aber keine weitere Funktion erkannt wird. Nach erkennen eines Tokens/Vorlage wird ein neuer Lauf gestartet. Bei 100 Läufen wird abgebrochen um Endlossschleifen zu vermeiden.

[Chris76e]

@ticaki

Danke, funktioniert.

Kann man eigentlich in der Telegram vorlage einen Zeilenumbruch machen? Mit \n funktioniert es bei mir nicht.

[ticaki]

@chris76e

hm... muß ich mir angucken. Admin escaped \ in 10 Minuten ist ne Version online in der \\n zu \n geändert werden, dann sollte es gehen... Ah deshalb ging in der plain email auch der Zeilenumbruch nicht. Egal jetzt ist es html.

Für Telegram gibts noch Markdownv2 oder html für fett und so. Bitte sagen was euch lieber ist, mir ist es wurscht.

[Chris76e]

mit \n funktioniert es jetzt.

@ticaki sagte in Test Adapter Weather-Warnings:

Für Telegram gibts noch Markdownv2 oder html für fett und so. Bitte sagen was euch lieber ist, mir ist es wurscht.

Sollen anderen entscheiden

[rtwl]

@ticaki sagte in Test Adapter Weather-Warnings:

in der \n zu \n geändert werden,

uh, da bin ich gespannt ob das auch für pushover geht.
werde ich aber erst am. Abend testen können.

[ticaki]

@rtwl

Müsste, der Admin escapt jedes \ also macht aus dem Sonderzeichen \n die normale Zeichenfolge ohne Sonderbedeutung.

[ticaki]

@rtwl sagte in Test Adapter Weather-Warnings:

@ticaki sagte in Test Adapter Weather-Warnings:

in der \n zu \n geändert werden,

uh, da bin ich gespannt ob das auch für pushover geht.
werde ich aber erst am. Abend testen können.

geht

Und was demnächst kommt ist das:

[ticaki]

@rtwl
Du testest doch pushover... klappt das eigentlich mit den Sounds? Hab gerade getestet.

[rtwl]

@ticaki
das mit den Sounds ist nichts für mich - mein Smartphone ist zu 90% auf Lautlos.
Testen kann ich es gerne, aber das hast du ja bereits. Oder soll ich auch nochmal?

[ticaki]

@rtwl
Das sehe ich ähnlich, geht ja, das reicht.

update

Noch ne Kleinigkeit:

Neue Tokens

startdaytime
enddaytime

export const daytimes = {
    morning: { start: 6, end: 10 },
    forenoon: { start: 10, end: 12 },
    noon: { start: 12, end: 14 },
    afternoon: { start: 14, end: 17 },
    evening: { start: 17, end: 21 },
    night: { start: 21, end: 6 },
};

Ja ich weiß dass das forenoon auch morning ist, aber das geht von English in alle sprachen, also forenoon

Und für Tage hatte ich mir folgendes gedacht:

letztens
heute
morgen
übermorgen
demnächst

letztens am vormittag passt
und demnächst am vormittag auch

EDIT: noch ist es vormittags - das ändere ich dann alles in vormittag morgen etc.
Ich lasse das am im Token weg...

[rtwl]

@ticaki sehr gute Implementierung!
"Morgen Nachmittag" ist viel verständlicher als "So, 22.10. 16:00 Uhr"
DANKE!

EDIT: Ändern sich die Tage, wenn eine Meldung über Mitternacht gleich bleibt - wird von "Morgen" auf "Heute" umgeschrieben?

[ticaki]

@rtwl
Du weißt schon das ich da einen countdown drin habe der minuten anzeigt? Meldungen werden für 1 Minute zwischen gespeichert und für jeden Nachrichtenabruf erstellt, soweit nicht noch im cache. Kann die natürlich um 0:01 Uhr nochmal erstellen lassen, das ist jetzt nicht drin.

Morgen Nachmittag geht nicht. Da ich einen begriff für >= 3 tage und Vergangenheit brauche. Da hab ich mich für letztens und demnächst entschieden.

Das kommt aber erst morgen.

[rtwl]

@ticaki sagte in Test Adapter Weather-Warnings:

Und für Tage hatte ich mir folgendes gedacht:
letztens
heute
morgen
übermorgen
demnächst

Wenn "morgen" nicht geht, was meinst du dann damit?

[ticaki]

@rtwl
Das sind Tokens die müssen frei kombinierbar sein ... sind sie aber doch nicht.

morgen nacht
letztens nacht
demnächst nacht

letztens am morgen
letztens am nacht

Hab noch nix.

Ich finde keine Bezeichungen für die 5 Zeiträume die mit nacht und morgen passen. Da muß dann ein s dran.

Naja... vorvorvorvorvorvorgestern nacht geht....

[rtwl]

@ticaki verstehe was du meinst.
wenns nach mir geht brauch ich keine variable für die Vergangenheit - ich glaube auch ZAMG liefert keine vergangene Meldungen. Und falls es 22 Uhr ist und in der VIS steht "Heute Vormittag" dann ist das auch noch logisch. "Gestern" könnte ja statt "letztens" funktionieren. oder gibt es tatsächlich eine Meldung welche länger als 1 Tag in der Vergangenheit lag?

Für die Zukunft, also weiter als "Übermorgen" brauche ich zumindest auch nicht, denn bis das Wetter-Ereignis tatsächlich eintrifft liefert ZAMG gefühlt 50 neue Aktualisierungen.
für "Über-Übermorgen" könntest du ja einfach beim Wochentag bleiben, aktuell also bei "Dienstag"?

[ticaki]

@rtwl sagte in Test Adapter Weather-Warnings:

@ticaki verstehe was du meinst.
wenns nach mir geht brauch ich keine variable für die Vergangenheit - ich glaube auch ZAMG liefert keine vergangene Meldungen. Und falls es 22 Uhr ist und in der VIS steht "Heute Vormittag" dann ist das auch noch logisch. "Gestern" könnte ja statt "letztens" funktionieren. oder gibt es tatsächlich eine Meldung welche länger als 1 Tag in der Vergangenheit lag?

Für die Zukunft, also weiter als "Übermorgen" brauche ich zumindest auch nicht, denn bis das Wetter-Ereignis tatsächlich eintrifft liefert ZAMG gefühlt 50 neue Aktualisierungen.
für "Über-Übermorgen" könntest du ja einfach beim Wochentag bleiben, aktuell also bei "Dienstag"?

Du nutzt kein Nina, aber da sind Meldungen auch mal Monate lang drin. aber hast schon recht Ich kann es einfach auf gestern, heute, morgen und übermorgen begrenzen und ansonsten bleibt der Token leer. kann man dann mit dem ${(=startdaytime)\${_Vorlagemitdatum\}#\${startdaytime\}}oder so ähnlich machen

[rtwl]

hast du beim Thema "Zeilenumbruch" noch was heimlich gedreht?

Ein \\n wird zu einem Zeilenbruch, aber eines der \ bleibt in der oberen Zeile sichtbar (pushover auf Android).
hab dann, wie die letzten Tage als es nicht ging, wieder nur \n eingegeben und der Zeilenbruch funktioniert wie erwartet.