[Unwetterwarnung] 77_UWZ.pm Modul für unwetterzentrale.de und wetteralarm.at

[Elektrolurch]

Hallo,

nach heutigem Update und Neustart bekomme ich:

2016.07.22 10:27:20 1: define XXX_UWZ UWZ de XXXX: Wrong syntax: use define <name> UWZ [CountryCode] [PLZ] [Interval]


X=anonymsisiert

Habe ich da irgendeine Umstellung verpasst?
Mit der Version davor gings noch.

Elektrolurch

[CoolTux]

Wenn jedes X eine Zahl ist dann hast Du eine zu wenig. DE hat seit Anfang der 90er fünfstellige Postleitzahlen 
Ansonsten bitte gib mal bitte noch das Updateintervall mit an.

define NAME UWZ DE PLZ INTERVAL

[Elektrolurch]

Ha ha, sind natürlich schon 5 - Stellen. Das Intervall habe ich bislang per Attribut gesetzt und in der Ausgabe steht ja für jeden zusätzlichen Wert beim define eine Optionsklammer [], bislang ging es ja auch ohne Angabe des Intervalls. Hast Du das geändert?

[CoolTux]

Ja das wurde geändert und eine harte Prüfung eingebaut.

[tdoe]

Moin Michael,

Moin

Erst mal, eine Super Arbeit was Ihr da macht.

Danke dir, hört man gerne

Habe aber noch einen "Fehler" gefunden oder auch nicht. 
_levelName passt nicht zu _uwzLevel und _uwzLevel_Str, zwei Bilder sind im Anhang.

hier liegt ein Missverständniss mit den levelNamen zugrunde, denn anhand von forewarn in deinem Fall alert_forewarn_orange und alert_forewarn_red wird definiert dass es sich "nur" um eine Vorwarnung handelt und eine Vorwarnung ist laut Unwetterzentrale Stufe Gelb, somit richtig. Was dich verwirrt hat ist das Level des zu erwartenden Unwetters bei dir orange und red.

Und eine Änderung würde ich mir wünschen. 
In _uwzLevel_Str steht zb Stufe Gelb (Vorwarnung für Unwetterwarnung) wäre es nicht besser das so zu machen
Vorwarnung für Unwetterwarnung usw.
Dann könnte man diesen Eintrag für die Infoframe's auf einfache weise nutzen.

Die verwendeten Texte sind exact das wording von Unwetterzentrale in de und en. Durch die Kürzung würden wir dann jedoch ein weiteres Reading benötigen, um die Farbe der Stufe anzuzeigen. Werde mal mit CoolTux darüber quatschen.

Danke dir für deine Meldung und Ideen

Gruß Tobias

[tdoe]

Moin frank,

event-on-change "problem"

1. es betrifft nur warn-readings mit laufender warn-nummer.
2. es geht nicht darum, dass die readings gelöscht werden, wenn die warnungen nicht mehr existieren. es ist gut und richtig, dass die readings nicht mehr vorhanden sind, wenn es keine entsprechenden warnungen gibt.
3. es geht "nur" darum, dass es für eine eventuell über tage gleichbleibende warnung, bei jedem interval erneut events gibt, obwohl das attr event-on-change für alle readings gesetzt ist. abgesehen von vielen unnötigen events, geht es mir in erster linie um die erkennung von änderungen der warn-inhalte.

das wird so nicht möglich sein, da die einzelnen Warnungen keine id haben. Und wenn z.B. heute 2 Warnungen sind (Regen(Warn_0_) und Schnee(Warn_1_)) und morgen ist nurnoch die Schnee Warnung übrig, dann ist diese auf platz 0. Somit würde das so sowieso nicht funktionieren.

wenn dieses verhalten natürlich so gewollt ist, zieh ich meinen "fehlerhinweis" wieder zurück und äussere den wunsch, dieses verhalten vielleicht noch einmal zu überdenken. ein mögliches umsetzen hat andre ja bereits skizziert.
wie kann ich denn sonst in erfahrung bringen, dass es eine änderung gab?
die überwachung des readings warnCount macht ja nur sinn, wenn sich die anzahl ändert. der inhalt kann sich aber auch bei gleichbleibender anzahl ändern und es passiert auch.

zur zeit müsste ich ja bei jedem interval alle readings zusätzlich speichern und jedes einzelne auf änderung prüfen.
daher ja auch mein wunsch zu jeder warnung ein reading mit dem aktualisierungs- / erstellungs-zeitpunkt der jeweiligen warnung zu generieren, um änderungen der warnungen deutlich einfacher ermitteln zu können.
wenn diese info dann auch im html für den weblink stehen würde, wäre es auch hier einfacher zu erkennen, dass sich etwas geändert hat.

ein weiterer wunsch wäre der hinweis im html auf die zu erwartende "erhöhung" der warnstufe bei einer vorwarnung. also ob orange, rot oder violett zu erwarten ist. vorbereitungstechnisch macht es schon einen deutlichen unterschied, was da genau auf mich zu kommt.

gruss frank

So einfach wie das x und y Beispiel skizziert war funktioniert das leider nicht siehe obige Begründung. Um selbst eine ID zu generieren (z.b. aus start und end time + unwettertyp, muss hier einiges an Code geändert/neu erstellt werden.

Dein Vorschlag mit der "erhöhung" gefällt mir. mal schauen wie sich das umsetzen lässt.

Danke für deine Unterstützung

Grz0 Tobias

[justme1968]

das x y beispiel funktioniert schon. zumindest wird so verhindert das bei völlig gleichen meldungen ein event erzeugt wird. wenn sich etwas ändert wird damit aber nicht die event anzahl minimiert. wenn sich z.b. die reihenfolge ändert wird das dabei nicht berücksichtigt. dazu müsste man in der tat eine eigene id erzeugen und dann auch noch nach start zeit sortieren. das wäre aber in der tat eine sinnvolle erweiterung .

gruss
  andre

[CoolTux]

Wir werden es sehr gerne auf die ToDo Liste setzen. Das wird aber diesen Sommer nichts mehr. Sowohl Tobias wie auch ich sind doch sehr eingespannt.
Vielen Dank auf jeden Fall für die Anregungen.


Grüße

[frank]

hi tobias,

das wird so nicht möglich sein, da die einzelnen Warnungen keine id haben. Und wenn z.B. heute 2 Warnungen sind (Regen(Warn_0_) und Schnee(Warn_1_)) und morgen ist nurnoch die Schnee Warnung übrig, dann ist diese auf platz 0. Somit würde das so sowieso nicht funktionieren.

mit einer ereignis-id wäre das natürlich traumhaft einfach, da hast du recht.

aber auch ohne id würde dein "positions-wechsel-beispiel" nicht wirklich stören, da es insgesamt gesehen eine neue warnlage ist => eine warnung weniger, die lage entspannt sich.
letztendlich geht es mir darum zb eine email zu senden, wenn es eine änderung der gesamten warnlage gab.

ein weiterer wunsch würde eventuell das "wechselverhalten" ein wenig entschärfen.
ich würde mir wünschen, das die reihenfolge der warnungen nach Warn_x_Severity sortiert werden würden. das scheint ja die "stärke" des zu erwartenden unwetters zu charakterisieren. über hinweise und vorwarnungen zu violettem (severity=12) unwetter. die readings würde ich von warn_0 => kleinstes severity aufsteigend bis zum grössten severity => warn_max sortieren. bei identischem severity zuerst die warnung mit grösstem warn_x_end wert, da diese am längsten erhalten bleibt.

im html würde ich die reihenfolge dann aber entgegengesetzt darstellen, um immer das wichtigste/stärkste ereignis als erstes sehen zu können.

Wir werden es sehr gerne auf die ToDo Liste setzen. Das wird aber diesen Sommer nichts mehr. Sowohl Tobias wie auch ich sind doch sehr eingespannt.

danke. lasst euch nicht von mir stressen, gut ding braucht weile.

angenehmen sommer,
gruss frank

[tdoe]

Moin,

im svn ist eine neue Version mit minor Änderungen. Es gibt nun ein zusätzliches "lang" Attribut, mit welchem direkt einfluss genommen werden kann welche Sprache die Long und Short Warn MSG hat.

Als Wert für den lang Parameter funktioniert immer der zum Land passende 2-Zeichen Ländercode und "en". Beispiele: [de,en,es,sv,it,...]

Gruß Tobias

[tdoe]

Moin,

konnte mir ein wenig Zeit aus den Rippen schneiden. Somit gibts doch noch vor ablauf des Sommers
für die experimentierfreudigen eine BETA-Version 1.4.3 im new-features branch:

Code Auswählen Erweitern


update 77_UWZ.pm https://raw.githubusercontent.com/tobias-d-oe/fhem-uwz/new-features/controls_uwz.txt


Folgende Änderungen sind enthalten:

• Neue Attribute


• sort_readings_by (start|severity)
• htmlsequence (ascending|descending)
• Neue Readings


• Warn_X_Creation
• Warn_X_Creation_Date
• Warn_X_Creation_Time
• Warn_X_EventID
• event-on-change - sollte nun auf allen Readings funktionieren
• commandref update

Könnt ihr bitte mal testen, bevor es upstream geht?

Gruß Tobias

[frank]

ergänzung: ausserdem funktioniert "event-on-change=.*" perfekt.

weiterhin alles bestens, auch htmlsequenze. 

gruss frank

[tdoe]

Moin,

nun im new-features Branch die Beta-Version 1.4.4

• Neue Readings


• Warn_X_AltitudeMin
• Warn_X_AltitudeMax

Also Leute....freiwillige vor!
Nachdem nun 98% der offenen Wünsche erfüllt wurden, suche ich nun freiwillige die den Wiki Eintrag auf Vordermann bringen. Gerne auch mit Beispiel zu event-on-change mit Pushbullet oder sowas. 

PS: Die Commandref denke ich sollte up2date sein.

Gruß Tobias

[tdoe]

Nachtrag:

Neues attribut "localiconbase".

Dadurch kann die BaseURL der WarnIcons verändert werden. Wenn der Wert gesetzt ist wird ein .png file kein .gif erwartet.

Gruß Tobias

[frank]

Also Leute....freiwillige vor!
Nachdem nun 98% der offenen Wünsche erfüllt wurden, suche ich nun freiwillige die den Wiki Eintrag auf Vordermann bringen. Gerne auch mit Beispiel zu event-on-change mit Pushbullet oder sowas. 

@wikischreiber
zur einstimmung erst einmal eine minianwendung (stateformat), damit man mal sieht, wann es änderungen gibt:

userreadings:

Code Auswählen Erweitern

lastWarnUpdate:Warn_.* {
return ReadingsTimestamp($name,"lastConnection","???");
}

stateformat:

Code Auswählen Erweitern

{ return InternalVal($name,"PLZ","xxxxx").
" --- events: ".ReadingsVal($name,"WarnCount","???").
" --- update: ".ReadingsVal($name,"lastWarnUpdate","???");
}

event-on-change:

Code Auswählen Erweitern

.*Warn.*
damit fallen die events der readings state, lastConnection und durationFetchReadings ganz weg, da sie sonst doch sehr häufig auftauchen. also nur WarnCount und alle Warn_X readings geben bei änderung events ab.

das userreading wird zur zeit allerdings nur durch die Warn_X readings getriggert. das hat den vorteil, dass warnungen, die wegfallen, nur eine änderung auslösen, wenn dadurch ein wechsel in den warnreadings ausgelöst wird. wahrscheinlich werde ich noch auf extrem ereignisse reduzieren, mal schauen.
pushbullit, oder email senden, einfach ins userreading einbauen.

gruss frank