weitere Icon-Bibliotheken einbinden (http://weathericons.io)

[sinus61]

Nichts für ungut. Aber das geht bei mir nicht durch den WAF-Filter.

Ich kann halt mit dem allem Wind Widget wenig anfangen, da muss man schon nach rangehen um zu sehen woher der Wind kommt. Das war zwar nett programmiert aber optisch nicht meins.

[setstate]

die weathericons sind nun mit dabei. Sie werden eingebunden, wenn der entsprechende Prefix benutzt wird 'wi-'

Ausserdem können sie direkt über den YahooCode im Weather-Widget angesprochen werden

Code Auswählen Erweitern


<div class="hbox items-space-around">
  <div data-type="weather" data-device="yhWeather" data-get="fc2_code" data-device-type="YahooCode" data-imageset="weathericons" class="big"></div>
  <div data-type="label" data-device="yhWeather" data-get="fc2_code"></div>
</div>


Andere Codes aus den verschiedenen Modules , die bestimmte Wetter-APIs benutzen, könnte ich auch noch direkt verlinken, wenn mir jemand erklären kann, wie die Readings dafür aussehen

https://erikflowers.github.io/weather-icons/api-list.html


update:
WindDirection ist jetzt auch direkt mit im Weather-Widget dabei

Code Auswählen Erweitern


<div class="vbox">
   <div data-type="weather" data-device="AgroWeather" data-get="windDir" data-device-type="WindDirection" data-imageset="weathericons" class="bigger"></div>
   <div data-type="label" data-device="AgroWeather" data-get="windDir" data-post-text="°" class="big"></div>
</div>


[tomster]

Ich hab gerade meine sheet/row/cols auf das "neue" Weather-Widget mit den weathericons angepasst. Augenscheinlich sind jedoch die einzelnen WindDirection-Icons unterschiedlich formatiert. Ich bekomme die einfach  nicht vernünftig untereinander in der Tabelle (siehe Bild).
Eigentlich dachte ich, der Code sollte passen, da die reinen Werte als label wunderbar zentriert untereinander stehen...

Code Auswählen Erweitern


<div class="sheet left-align">
        <div class="row">
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_02_date_weekday" class="calendar col-25"></div>
        <div data-type="weather" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_02_icon" data-imageset="weathericons"
        data-warn="forecast_simpleforecast_forecastday_02_snow_allday_cm" data-warn-on="^([1-9].*)" data-warn-off="0" data-on-color="#FFFFFF" class="wi we_icon col-10 right-align compressed"></div>
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_02_high_celsius" class="calendar col-10 center-align"></div>
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_02_low_celsius" class="calendar col-10 center-align"></div>
        <div data-type="weather" data-device="Krailling" data-device-type="WindDirection" data-get="forecast_simpleforecast_forecastday_02_avewind_degrees" data-imageset="weathericons" class="small col-10 center-align"></div>
        <div class="col-1-6 right-align">
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_02_avewind_kph" class="inline calendar right-narrow-0"></div>
        <div data-type="label" class="inline we-unit">km/h</div></div>
        <div class="col-1-7 right-align nowrap">
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_02_pop" class="inline calendar"></div>
        <div data-type="label" class="inline we-unit left-narrow-5">%</div></div>
        </div>
        <div class="row rank2">
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_03_date_weekday" class="calendar col-25"></div>
        <div data-type="weather" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_03_icon" data-imageset="weathericons"
        data-warn="forecast_simpleforecast_forecastday_03_snow_allday_cm" data-warn-on="^([1-9].*)"
        data-warn-off="0" data-on-color="#FFFFFF" class="wi we_icon col-10 right-align compressed"></div>
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_03_high_celsius" class="calendar col-10 center-align"></div>
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_03_low_celsius" class="calendar col-10 center-align"></div>
        <div data-type="weather" data-device="Krailling" data-device-type="WindDirection" data-get="forecast_simpleforecast_forecastday_03_avewind_degrees" data-imageset="weathericons" class="small col-10 center-align"></div>
        <div class="col-1-6 right-align">
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_03_avewind_kph" class="inline calendar right-narrow-0"></div>
        <div data-type="label" class="inline we-unit">km/h</div></div>
        <div class="col-1-7 right-align nowrap">
        <div data-type="label" data-device="Krailling" data-get="forecast_simpleforecast_forecastday_03_pop" class="inline calendar"></div>
        <div data-type="label" class="inline we-unit left-narrow-5">%</div></div>
        </div>

[tomster]

@setstate
Hmm, kann es sein, dass Du für WindDirection gar nicht die vorgegebenen Icons (wi-towards-nne, wi-towards-n, etc.) verwendest, sondern das "Standard-Icon" einfach um den angegebenen Wert in Grad drehst? Das würde zumindest das "Exzentrische" erklären. Die Icon-Ersteller legen nämlich anscheinend wenig Wert auf zentrierte Icons...

[setstate]

Das kann nicht sein, soviel Arbeit würde ich mir nicht machen 

Ich würde sheet > row > cell probieren.

[setstate]

Außerdem habe ich col-10 nicht definiert. Hast du bei dir? Wenn nicht, hättest du auch "untertasse" benutzen können, wäre die gleiche Wirkung. 

[tomster]

Ja, die Klassen existieren alle. Logo

Ich dachte eigentlich, dass es sogar einfacher wäre, einfach den Grad-Wert eines Readings aus dem Device auszulesen und das "Nord-Icon" einfach um den angegebenen Wert zu drehen, anstatt einzelne Bereiche (N-NNW-NW-etc.) zu definieren... Aber ich bin ja kein Programmierer, sondern nur Hausmeister.

Draufgekommen bin ich nur, weil ich mir auf alle col's einen Hintergrund gelegt habe, um eventuelle falsche Spaltenbreiten besser erkennen zu können. Rausgekommen ist dann das (man beachte die Hintergründe bei den Windrosen):

[setstate]

Das sieht aber mal krass aus und sehr aufschlussreich.
Da muss der Autor des Fonts das so im CSS definiert haben.
Muss ich mal eben reinschauen.

[setstate]

Ja, so einfach machen diese Designer sich das

.wi-wind.towards-20-deg {
  transform: rotate(20deg);
}

[tomster]

Super. Wenn man dann als Designer zudem noch keinen Wert darauf legt, dass das Icon an sich zentriert ist, dann kommt so eine Kacke raus...
Dabei ist der guteste erikflowers kein Einzeltäter. Auch die fa-Icons zeigen dieses Phänomen. Ist mir aufgefallen, als ich bei ein paar Icons eine fa-spin-Class hinzugefügt habe...

Muss ich mir etwas anderes einfallen lassen...

Ähh, weil ich Dich grad dranhabe:
im widget-weather.js definierst Du die einzelnen Mappings für die weather-icons ganz oben in der Yahoo-Definition, oder? Meinst Du man kann da ein für alle Mal auch Readings wie z.B. partlycloudy (gibt vielleicht auch noch andere ohne blanks) definieren? Ich muss nämlich nach jedem Update das Widget wieder manuell ändern damit die Icons angezeigt werden.
Ich würde natürlich sämtliche möglichen Ausgaben für (das von mir verwendte) Wunderground als Mapping zusammenstellen. Nur in's git müsstest Du das setzen...

[setstate]

Man muss dem Icon dann eine feste Weite und Höhe geben, dann sollte es funzen

Das Mapping müsst ihr mir bitte mundgerecht für Copy und Paste geben. 

[tomster]

Bissi off-topic:
@setstate

Was hältst Du von der Idee eine Klasse mit in's fhem-tablet-ui.css aufzunehmen, die das Debugging mit den col-Breiten zu erleichtern? Man könnte doch definieren, dass bei
<meta name="debug" content="<0"> <!-- verbose level 1-6 = output to console;0 = not output -->
eine Klasse in etwa wie die Folgende greift:

Code Auswählen Erweitern


div[class*="col"] {
background: red;
    background: -webkit-linear-gradient(red, yellow);
    background: -o-linear-gradient(red, yellow);
    background: -moz-linear-gradient(red, yellow);
    background: linear-gradient(red, yellow);
}

Dann würde man gleich sehen, ob die Spaltenbreiten für den gewünschten Content breit genug sind, oder?

[tomster]

OK, kein Problem! Naja, doch ein kleines Problem.
Auf der wi-Webpage sind ja nur Keys angegeben, z.B. f00d für wi-day-sunny. Wie setz ich die Codes richtig für das Mapping um?
Ein

Code Auswählen Erweitern


'sunny': '\f00d',


wird's ja nicht tun, oder?

[tomster]

Entweder hast Du die WunderGround-Mappings schon dazugefügt, oder die waren in der weather-icons.min.css schon drin...

Ich hab daraufhin einfach in widget_weather.js folgende Zeilen hinzugefügt:

Code Auswählen Erweitern


case "WunderGround":
                            elem.addClass('wi wi-wu-' + val);
                            ftui.log(3, 'weather: set weathericons WunderGround: wi-wu-' + val);
                            break;

Mit einem data-device-type="WunderGround" innerhalb des Widgets werden die Icons dann auch wunderbar angezeigt.

[tomster]

Ähnlich wie oben könnte man auch die Mondphasen hinzufügen.

Code Auswählen Erweitern


case "Moon":
                            elem.addClass('wi wi-moon-' + val);
                            ftui.log(3, 'weather: set weathericons WunderGroundMoon: wi-moon-' + val);
                            break;

Hier mal das Mapping:

Code Auswählen Erweitern


.wi-moon-0:before{content:"\f095"}
.wi-moon-1:before{content:"\f096"}
.wi-moon-2:before{content:"\f097"}
.wi-moon-3:before{content:"\f098"}
.wi-moon-4:before{content:"\f099"}
.wi-moon-5:before{content:"\f09a"}
.wi-moon-6:before{content:"\f09b"}
.wi-moon-7:before{content:"\f09c"}
.wi-moon-8:before{content:"\f09d"}
.wi-moon-9:before{content:"\f09e"}
.wi-moon-10:before{content:"\f09f"}
.wi-moon-11:before{content:"\f0a0"}
.wi-moon-12:before{content:"\f0a1"}
.wi-moon-13:before{content:"\f0a2"}
.wi-moon-14:before{content:"\f0a3"}
.wi-moon-15:before{content:"\f0a4"}
.wi-moon-16:before{content:"\f0a5"}
.wi-moon-17:before{content:"\f0a6"}
.wi-moon-18:before{content:"\f0a7"}
.wi-moon-19:before{content:"\f0a8"}
.wi-moon-20:before{content:"\f0a9"}
.wi-moon-21:before{content:"\f0aa"}
.wi-moon-22:before{content:"\f0ab"}
.wi-moon-23:before{content:"\f0ac"}
.wi-moon-24:before{content:"\f0ad"}
.wi-moon-25:before{content:"\f0ae"}
.wi-moon-26:before{content:"\f0af"}
.wi-moon-27:before{content:"\f0b0"}

Eingebunden würde das Ganze dann mit einer Syntax a lá:

Code Auswählen Erweitern


<div data-type="weather" data-device="Astro" data-get="moon_phase_ageOfMoon" data-device-type="Moon" data-imageset="weathericons" class="bigger inline"></div>

Eventuell kann man das auch "schlichter" halten, um auch andere Schnittstellen, deren Mondphasen mit einer Tages-Angabe versehen sind zu nutzen. Kann ich aber mangels Vergleich nicht sagen, welche das wären...