WeeWX ist eine quelloffene und freie Wetterstationssoftware für Linux, Mac OS X und Solaris. Geschrieben ist die Software in Python. Hauptautor ist Tom Keffer, wichtige Mitentwickler sind Matthew Wall und Gary Roderik. Auf GitHub gibt es viele Treiber und Erweiterungen von verschiedenen Autoren. Häufig wird WeeWX zum Auslesen von Daten über einen Raspberry Pi genutzt. Es läuft auch in der WSL2 (Windows Subsystem for Linux) Umgebung von Windows 10 und 11. Ebenfalls gibt es erfolgreiche Installationen auf NAS-Servern mit z.B. Ubuntu-Docker-Containern oder Ubuntu-LXC Containern.

Aufgrund der einfachen Erweiterbarkeit über ein Plugin-Konzept und einer aktiven Community unterstützt die Software eine Vielzahl an Wetterstationen und Wetternetzwerken. Hervorzuheben ist zudem die exzellente englischsprachige Dokumentation, die sich sowohl auf https://weewx.com findet als auch in WiKis auf GitHub zu den jeweiligen Treibern. Beispiel: der Treiber für das Ecowitt Konsolen API der GW1x00, GW2000, WN19x0 Konsolen - https://github.com/gjr80/weewx-gw1000/wiki Für die Teilnahme an der weewx-Benutzergruppe („forum“) benötigt man ein Google-Email-Konto. Die Gruppe, die als Forum dient, heisst: weewx-user weewx-user@googlegroups.com Die bevorzugte Forums- (user group) Sprache ist Englisch. Man kann auch in Deutsch Fragen posten, wird dann aber auch wohl nur Antworten von deutschen Gruppenmitgliedern erhalten. Die besonders aktiven Mitglieder Tom Keffer (Autor) und z.B. Gary Roderick (Ecowitt GW1000) und Mathew Wall kommunizieren nur in ihrer Muttersprache (Englisch). Ein sehr geeignetes (übrigens deutsches und bis 5000 Wörter kostenloses) Übersetzungstool findet man auf https://deepl.com

Da nicht jeder der Englischen Sprache und insbesondere des Wetter- und IT-Jargons mächtig ist, nachstehend eine Zusammenfassung in Deutsch.

Weewx liest mit Hilfe entsprechender Treiber (hardware-, wetterstationsabhängig) die Sensordaten („observations“) aus, verarbeitet bzw. verdichtet diese Daten und speichert sie („archiving“) in einem vom Benutzer definierten Zyklus in einer Datenbank (SQLite oder mySQL) ab. Der Standardwert sind 300 Sekunden = 5 Minuten. Die abgespeicherten Daten können auf einer (oder mehreren) Web-Browserseite(n) [weewx Name: skin] dargestellt werden, und zwar sowohl als Tabellen als auch als grafische Verläufe. Es gibt eine Vielzahl solcher Skins, für die die entsprechenden Daten und ihre Darstellung, auch parallel, im Archivierungsrhytmus erzeugt werden. Die weewx Standard-Skin ist die sogenannte Seasons-Skin. Zusätzlich gibt es auch die Möglichkeit, mit Hilfe von MQTT eine quasi Echtzeitdarstellung der aktuellen Daten zu ermöglichen (–> Belchertown Skin).

Mittlerweile (Mai 2023) liegt weewx in der Version 4.10.2 vor. Bereits in 4.7.0 erfuhr insbesondere die Season-Skin (s.u.) eine weitgehende Überarbeitung hinsichtlich automatischem Auffinden und Darstellen von Sensoren und auch in ihrer Arbeitsweise. Sie ähnelt jetzt sehr der bereits von neoground in ihrer jüngsten Version der neowx-Skin benutzten Arbeitsweise. Die „alten“ Skins (bis 4.6.0) sind weiterhin verwendbar, allerdings muss man sie getrennt installieren, d.h. von der neuen Skin getrennt halten (in einem eigenen ggf. umbenannten Skin-Verzeichnis).

Die Froggit WH3000SE, WH4000SE, Ventus W830 und andere Klone der Ecowitt WS2320 und WH2910 können unter weewx mit dem Interceptor Treiber betrieben werden.
Für die HP2551/HP2553 Station (Froggit HP1000SE Pro) gibt es mittlerweile auch einen erweiterten Interceptor Treiber (https://www.pc-wetterstation.de/forum/viewtopic.php?f=26&t=10333) dank unseres Kollegen Werner Krenn.
Für die Ecowitt GW1000, WH2650, GW1100, GW2000 und WN19x0 Konsolen (auch Gateways, Hubs genannt) gibt es den weewx Ecowitt Gateway Treiber (alter Name: GW1000 API Treiber), der die Daten direkt vom Konsolen-API ausliest. Das Abfrageintervall (Polling) z.B. alle 10 Sekunden wird in der weewx.conf eingetragen.
Der GW1000 API Treiber Version 0.5 (0.5.0b5 - September 2022) unterstützt auch den WS90 Kombisensor und die Möglichkeit, sowohl die Regendaten des WS90 (haptischer Regensensor, „piezo“) als auch die eines gleichzeitig in der Konsole registrierten klassischen Regensensors parallel auszulesen.
Vorausssetzung für den WS90 auf Konsolenseite: Firmware 1.7.0 (GW1000, WH2650) bzw. Firmware 2.1.4 (GW1100 und GW2000).

Nachstehend ein Beispiel der Seasons-Skin (erstellt mit weewx 4.5.3) - Grundlage: eine Ecowitt 2553 Station mit zusätzlichen Extra-Sensoren, die Sensor-Daten empfangen und verarbeitet von einem zusätzlichen Ecowitt GW1000 und von weewx auf einem Raspberry Pi 4 mit Hilfe des GW1000 API Treibers abgefragt und verarbeitet. (Hierfür gibt es eine erweiterte Version von Gary Rodericks GW1000 0.4.1 API Treibers erstellt von Werner Krenn: https://www.pc-wetterstation.de/forum/viewtopic.php?f=26&t=10333; mittlerweile [April 2022] auch auf den WS90 erweitert. Mittlerweile gibt es auch den „offiziellen“ GW1000 API Treiber in der Version 0.5.0, der ebenfalls den WS90 Sensor via GW1x00 und GW2000 beherrscht. s.o.)

Die Skin bietet links drei Tabellen - Current (=aktuelle Daten), darunter Sonnen- und Mondauf-/-untergangs-Daten, darunter die Min/Max Werte der ausgewählten Darstellung (Standard ist Tag, auswählbar sind auch Woche, Monat, Jahr - entsprechend auch die Grafiken) Die Sensoren-Namen können geändert werden - es ist auch eine Darstellung in Deutsch mit etwas Aufwand möglich.
Es gibt eine Standard-Auslieferung für die Basis-Sensoren, die Anzahl der Zeichnungen und die Anzahl der Sensorenwerte bis hin zu den verwendeten Farben auf den Zeichnungen, der Bildgrösse, der Skalierung, ist individuell anpassbar. Weewx läßt sich relativ einfach, selbst mit geringen oder gar keinen Linux-Kenntnissen z.B. auf einem RaspberryPi (empfohlen RPi4, 4 oder 8 GB) installieren. Es gibt eine entsprechende englischsprachige Wiki aber auch gute Zusammenfassungen im Internet.

Hinweis: wenn man weewx auf einem Raspberry Pi mit seinem Standard-Betriebssystem (Raspbian, Debian 10) installiert, muss man noch einen Webserver installieren (z.B. nginx oder Apache2), um sich die Skin ansehen zu können. Ein Webserver gehört nicht zur Standard-Auslieferung.

Will man selbst Anpassungen vornehmen bzw. weitere Sensoren anzeigen lassen, muss man die weewx Software-Architektur ein bisschen verstehen. Oder, einfach ausgedrückt, wissen, wo man was eintragen muss, damit die Änderungen in der Skin in der gewünschten Form erscheinen. Dazu mehr unter dem Bild der Seasons Skin.

Grundsätzlich arbeitet weewx folgendermassen:

• Sensor-Daten (observations) sammeln und verarbeiten
• Sensor-Daten in der Datenbank abspeichern
• Daten für die Darstellung in einer Skin (Report) mit Hilfe eines Programms, dem sogenannten Cheetah-Generator, in einem Verzeichnis auf dem Server bereitstellen (Text, Zahlen, Bilder), wo sie dann mit Hilfe eines Web Servers (Programm zur Darstellung von Webseiten) im Browser aufgerufen werden können. (z.B. http://IP-Adresse/weewx). Obiges Bild wird im Browser so aufgerufen.

Für die Datenspeicherung und Darstellung gibt es in weewx drei zentrale Konfigurationsdateien:

1. weewx.conf, die zentrale System-Konfigurationsdatei, wo Ortsdaten, Stationstyp, benutzte Skins, Einheiten, Sensornamen, Datenbank-Info etc. hinterlegt sind, also Einstellungen für das gesamte System (auf einem RPi unter /etc/weewx/weewx.conf zu finden)
2. skin.conf, eine spezielle Konfigurationsdatei für jede Skin, wo die erzeugten Bilder/Grafiken beschrieben bzw. definiert werden (zu finden in /etc/weewx/skins/Seasons/skin.conf)
3. index.html.tmpl, eine Definition/Muster (Template) für die Datei, die der web server bei Aufruf der Webseite lädt und darstellt (index.html); (zu finden in /etc/weewx/skins/Seasons/index.html.tmpl) - zu ihr gehören noch einige ausgelagerte Teile (sogenannte Includes), die bei der Verarbeitung in die index.html.tmpl eingefügt werden (current.inc, hilo.inc …) und wo die Tabellen definiert werden.

Am Ende also Überschrift, Tabellen (links) und Grafiken der letzten Archivierung sowie der Fußbereich der Seite: Stationsname/Hardwaretyp, Server-Uptime (Zeit seit letztem Server-(Re-)Boot, Programm-Uptime (Zeit seit letztem restart von weewx). (In anderen Worten: Was erscheint Wo mit welchem Text auf der Webseite)
Wenn man z.B. eine Ecowitt/Fine Offset Klon/Froggit Station mit Kombi-Aussensensor betreibt (z.B. Froggit WH3000SE, Froggit WH4000SE oder das gleiche Modell von Ecowitt oder eines anderen Rebranders), kann weewx die Daten mit dem Interceptor Treiber empfangen und verarbeiten und fertig darstellen. Für die Basis-Sensoren ist schon alles in den Konfigurationsdateien „eingerichtet“.

Wenn man einen GW1000/DP1500 mit diesem Kombi-Aussensensor und dem weewx GW1000 API Treiber betreibt, muss man einen zusätzlichen Eintrag in der weewx.conf Datei machen, damit die Sonnenstrahlung angezeigt wird (das hat mit der Art und Weise zu tun, wie weewx Sensordaten verarbeitet; der GW1000 liefert nämlich Lichtstärkewerte, die erst in Solarstrahlung umgewandelt werden müssen). Das Gleiche gilt für die WH2650, GW1100, GW2000 und WN19x0 Konsolen, die alle das gleiche API besitzen.
In der [StdCalibrate] [[Corrections]]-Stanza muss der Eintrag radiation = luminosity/126.7 if luminosity is not None else None hinzugefügt werden.

Nachstehend ein Beispiel, wie man die Werte zweier Ecowitt WH31 (Froggit DP50) 8-Kanal Temperatur/Luftfeuchtigkeits-Sensoren in die Tabellen bzw. als Verlaufs-Zeichnungen (Tag/Woche/Monat/Jahr) der Seasons-Skin hinzufügt.

Die WH31/DP50 Sensoren kennt weewx als extraTemp1 - extraTemp8 bzw. als extraHumid1 - extraHumid8 (das gilt nicht nur für Ecowitt/FO Klon Sensoren, auch für andere Hersteller z.B. Davis). Sie sind bereits Bestandteil des weewx Datenbank-Schemas (=Zusammenstellung aller vorhandenen Felder in einer Datenbank) wview-extended.py, das für alle neueren weewx Installationen als Standard-Einstellung gilt. Welches DB-Schema man hat, kann man in weewx.conf unter [DataBindings] [[wx_binding]] sehen.

Dazu müssen in jeder der drei Konfigurationsdateien Ergänzungen vorgenommen werden:

• in weewx.conf werden die Namen der Sensoren auf der Skin definert - gibt man dort nichts an, wird der Name des Datenbankfeldes angezeigt; z.B. beim ersten extra Temperatursensor „extraTemp1“. Wenn wir dort z.B. „WH31 CH1 Gewächshaus“ und „WH31 CH2 Kühlschrank“ sehen wollen, muss das in der weewx.conf unter [StdReport] [[Defaults]] [[[Labels]]] [[[[Generic]]]] eingetragen werden:

extraTemp1 = WH31 CH1 Gewächshaus
extraTemp2 = WH31 CH2 Kühlschrank
extraHumid1 = WH31 CH1 Gewächshaus
extraHumid2 = WH31 CH2 Kühlschrank

• in skin.conf müssen wir pro Sensor-Typ (Temperatur / Feuchtigkeit) je ein (oder zwei) Grafiken definieren, je nachdem ob wir die Werte zusammen in einer Zeichnung oder auf zwei Zeichnungen verteilt sehen wollen. Zusammen also entweder zwei Grafiken (je eine für Temperatur und Luftfeuchtigkeit - man kann nicht unterschiedliche Einheiten [°C und %] sinnvoll in einer Grafik darstellen) oder vier Grafiken. Diese Definition muss für alle Berichtszeiträume vorgenommen werden, also für Tag, Woche, Monat, Jahr. Für jeden dieser Zeiträume gibt es in skin.conf einen Abschnitt. Man legt die Einträge zunächst nur für den Tag an, und wenn die Darstellung passt, kann man die Einträge für die anderen Zeiträume durch +/- Kopieren vornehmen.

Dazu definieren wir im Abschnitt [ImageGenerator] [[day_files]] eine neue Grafik [[[dayextraTemp1_2]]] und ordnen die Variablen (Datenbankfelder) zu, die die Werte enthalten: extraTemp1 und extraTemp2
(die Reihenfolge der Einträge unterhalb von [[day_files]] oder [[week_files]] etc. ist egal, da sie nur der Erzeugung der Grafiken dienen. Erst in index.html.tmpl werden diese in die gewünschte Reihenfolge gebracht.)

 [ImageGenerator]
   [[day_files]]
     [[[dayextraTemp1_2]]]
        [[[[extraTemp1]]]]
        [[[[extraTemp2]]]]  

analog das Gleiche für die Luftfeuchtigkeit:

     [[[dayextraHumid1_2]]]
        [[[[extraHumid1]]]]
        [[[[extraHumid2]]]]  

Mit diesen Anweisungen erzeugt der Cheetah-Generator zwei Grafiken mit den Sensornamen als Überschrift und den passenden Einheiten, die im HTML_ROOT Verzeichnis abgelegt werden. Damit sie auch angezeigt werden, muss die entsprechende Information dazu in die Datei index.html gelangen, die der Webserver bei Aufruf anzeigt - dies geschieht in index.html.tmpl

• in index.html.tmpl wird jetzt festgelegt, was wo (Platz, Reihenfolge) in den Tabellen angezeigt wird bzw. in welcher Reihenfolge die Grafiken angezeigt werden. Nach diesen Anweisungen wird nach jedem Archivierungszyklus die Datei index.html neu erstellt, die dann die Anzeige im Browser vornimmt.

1. aktuelle Werte (current) –> current.inc
2. min/max Werte (high/low) –> hilo.inc
3. Grafiken –> index.html.tmpl

• aktuelle Werte

hier fügen wir vier Einträge in current.inc ein, und zwar unterhalb des Eintrags für die Innen-Luftfeuchtigkeit:

 #if $day.inHumidity.has_data
    <tr>
      <td class="label">$obs.label.inHumidity</td>
      <td class="data">$current.inHumidity</td>
    </tr>
 #end if

 #if $day.extraTemp1.has_data
    <tr>
      <td class="label">$obs.label.extraTemp1</td>
      <td class="data">$current.extraTemp1</td>
    </tr>
 #end if
 #if $day.extraTemp2.has_data
    <tr>
      <td class="label">$obs.label.extraTemp2</td>
      <td class="data">$current.extraTemp2</td>
    </tr>
 #end if
 #if $day.extraHumid1.has_data
    <tr>
      <td class="label">$obs.label.extraHumid1</td>
      <td class="data">$current.extraHumid1</td>
    </tr>
 #end if
 #if $day.extraHumid2.has_data
    <tr>
      <td class="label">$obs.label.extraHumid2</td>
      <td class="data">$current.extraHumid2</td>
    </tr>
 #end if

• min/max Werte

entsprechend das Gleiche für die min/max Werte unterhalb der Innen-Luftfeuchte in hilo.inc:

  
    #if $day.inHumidity.has_data
    <tr>
      <td class="label">$obs.label.inHumidity</td>
      #for $archive in $archive_data
      <td class="data new_row hilo_$archive[0]">
        <span title="$archive[1].inHumidity.maxtime">
          $archive[1].inHumidity.max.format(add_label=False)</span><br/>
        <span title="$archive[1].inHumidity.mintime">
          $archive[1].inHumidity.min.format(add_label=False)</span>
      </td>
      #end for
      <td class="units">$unit.label.inHumidity</td>
    </tr>
    #end if

    #if $day.extraTemp1.has_data
    <tr>
      <td class="label">$obs.label.extraTemp1</td>
      #for $archive in $archive_data
      <td class="data new_row hilo_$archive[0]">
        <span title="$archive[1].extraTemp1.maxtime">
          $archive[1].extraTemp1.max.format(add_label=False)</span><br/>
        <span title="$archive[1].extraTemp1.mintime">
          $archive[1].extraTemp1.min.format(add_label=False)</span>
      </td>
      #end for
      <td class="units">$unit.label.extraTemp1</td>
    </tr>
    #end if
    #if $day.extraTemp2.has_data
    <tr>
      <td class="label">$obs.label.extraTemp2</td>
      #for $archive in $archive_data
      <td class="data new_row hilo_$archive[0]">
        <span title="$archive[1].extraTemp2.maxtime">
          $archive[1].extraTemp2.max.format(add_label=False)</span><br/>
        <span title="$archive[1].extraTemp2.mintime">
          $archive[1].extraTemp2.min.format(add_label=False)</span>
      </td>
      #end for
      <td class="units">$unit.label.extraTemp2</td>
    </tr>
    #end if
    #if $day.extraHumid1.has_data
    <tr>
      <td class="label">$obs.label.extraHumid1</td>
      #for $archive in $archive_data
      <td class="data new_row hilo_$archive[0]">
        <span title="$archive[1].extraHumid1.maxtime">
          $archive[1].extraHumid2.max.format(add_label=False)</span><br/>
        <span title="$archive[1].extraHumid1.mintime">
          $archive[1].extraHumid1.min.format(add_label=False)</span>
      </td>
      #end for
      <td class="units">$unit.label.extraHumid1</td>
    </tr>
    #end if
    #if $day.extraHumid2.has_data
    <tr>
      <td class="label">$obs.label.extraHumid2</td>
      #for $archive in $archive_data
      <td class="data new_row hilo_$archive[0]">
        <span title="$archive[1].extraHumid2.maxtime">
          $archive[1].extraHumid2.max.format(add_label=False)</span><br/>
        <span title="$archive[1].extraHumid2.mintime">
          $archive[1].extraHumid2.min.format(add_label=False)</span>
      </td>
      #end for
      <td class="units">$unit.label.extraHumid2</td>
    </tr>
    #end if

• Grafiken

Jetzt fügen wir die Tagesverlaufs-Grafiken unterhalb der Innen-Temperatur- bzw. Innen-Luftfeuchte-Grafiken ein:

          #if $day.inTemp.has_data
          <img src="daytempin.png"    alt="$obs.label.inTemp" />
          #end if
          #if $day.inHumidity.has_data
          <img src="dayhumin.png"    alt="$obs.label.inHumidity" />
          #end if

          #if $day.extraTemp1.has_data or $day.extraTemp2.has_data
          <img src="dayextraTemp1_2.png"      alt="$obs.label.extraTemp1" />
          #end if
          #if $day.extraHumid1.has_data or $day.extraHumid2.has_data
          <img src="dayextraHumid1_2.png"      alt="$obs.label.extraHumid1" />
          #end if

Damit haben wir jetzt auch zwei weitere Grafiken in der Tagesverlaufsanzeige, eine mit den den Extra-Temperaturen 1 und 2 und eine mit den Extra-Luftfeuchtewerten 1 und 2.
Entsprechend müssen jetzt noch in skin.conf, current.inc, hilo.inc und index.html.tmpl die Einträge für Woche, Monat und Jahr entsprechend eingetragen werden.

Hinweis: damit Einträge in weewx.conf wirksam werden, muss weewx neu gestartet werden - Einträge in skin.conf und index.html.tmpl (und der dazugehörigen *.inc Dateien) werden sofort, d.h. beim nächsten Archvierungszyklus ohne Neustart wirksam.

Ausserdem wichtig: die Grafiken für die Wochen-, Monats- und Jahresverläufe werden nicht bei jedem Archivierungszyklus neu erstellt, sondern standardmäßig erst nach bestimmten Zeiträumen: die Wochenverläufe jede Stunde, die Monatsverläufe alle drei Stunden, die Jahresverläufe alle 24 Stunden.
(das wird festgelegt durch den Parameter aggregate_interval in skin.conf für den jeweilgen Zeitraum - dieser ist änderbar)

Insgesamt lassen sich die Grafiken auf vielfältige Weise ändern, formatieren bzgl. Hintergrund, Strich- oder Flächendarstellung, Farben, Skalierung, Zeiträume u.v.a.m. - dazu muss man sich allerdings in die Funktionsweise des Cheetah-Generators einarbeiten. Der englischsprachige Customization Guide gibt dazu viele Hinweise und Beispiele.

Man kann z.B. auch den sogenannten Historygenerator in Verbindung mit der sogenannten Neowx-Material Skin einbinden (https://neoground.com/projects/neowx-material), der es erlaubt, (farbige) Tabellen mit min/max/Mittelwerten zu bestimmten Messgrößen (Regenmenge, Regentage, Wind, Temperatur etc.) und Zeiträumen zu erstellen mit Jahres(summen)werten: z.B. Anzeige der monatlichen Höchstwerte für alle Jahre einschliesslich des Jahresmaximumms, -Minimums, -Durchschnitts …

Die Neowx-Material Skin (oben) - Tabelle mit History-Generator (unten)



Die neowx-material Skin hat ein modernes, ästhetisches Design. Die Graphiken werden beim Aufruf zur Laufzeit aus grossen vom Cheetah-generator erzeugten Tabellen erstelltt (was je nach Komplexität - Anzahl der Werteverläufe in einem Graphen - insbesondere bei der Jahresansicht etwas Zeit in Anspruch nehmen kann). Im Gegensatz zur Seasons Skin, die im Archivierungsintervall jeweils fertige Grafiken erstellt und bereitstellt.

Ein Beispiel zum Erstellen obigen Historienreports findet sich unter https://www.wetterstationsforum.info/viewtopic.php?p=6862#p6862

Ein Beispiel für das nachträgliche Einspielen (Importieren) von Froggit WH4000SE/ Ecowitt WS2320E Konsolen-Daten in weewx findet sich hier: https://www.wetterstationsforum.info/viewtopic.php?p=6667#p6667

Darüberhinaus wird von vielen gerne die sogenannte Belchertown Skin eingesetzt, die zusammen mit einem MQTT-Server/Broker eine quasi Echtzeitanzeige der Sensordaten ermöglicht.
Die Standardverarbeitung von weewx zeigt Änderungen „nur“ im Archiverungsintervall an (i.d.R. 5 Minuten). Man kann das Intervall auch heruntersetzen, stösst dann aber je nach vorhandener Sensoranzahl leicht an die Grenzen des eingesetzten Servers, wenn die Zeit zur Erstellung der Skin (Bilder, Tabellen) länger dauert als das Speicherintervall von weewx. Dann verwirft weewx neuere Skin-Daten bis die noch in Verbeitung befindliche abgeschlossen ist. „Echtzeit“ wird dann durch die Serverarchitektur (Prozessor, RAM, schnelle Massenspeicher) definiert. Der Einsatz von MQTT umgeht dies, indem dort die aktuellen Daten sehr zeitnah dargestellt werden, die Archivierung (Abspeichern in der Datenbank) der Daten aber weiterhin z.B. im 5-Minuten Intervall davon unabhängig erfolgt. Auf das Archiv wird nur für historische Daten zurückgegriffen. Durch die Nutzung von MQTT werden die Darstellung der aktuellen Daten und das Abspeichern der Daten für historische Zwecke voneinander Entkoppelt. Allerdings sind Aufbau und Betrieb der Umgebung auch komplexer und anspruchsvoller und brauchen i.d.R. vertiefte Kenntnisse der technischen Zusammenhänge.

Link zur weewx Website: WeeWx

Hardware Beispiele