Aare.guru API: Auftakt Saison 2022 – Expansion nach Olten

Gute Neuigkeiten: Wir erweitern auf 2022 unser Einflussbereich aus und nehmen Olten als neuen Ort in der Aare.guru-API auf. Dank der privaten Messstation von Tobias Oetiker (TemperAare, iOS & Android) können wir diese Lücke im Messnetz schliessen.

Die schlechte Nachricht: Jetzt gibt’s ein Lehrstück in defensivem Programmieren: Da die neues Messstation nur die Temperatur, aber nicht die Wassermenge misst, wird die API für Olten einige null-Werte liefern.

Und ihr müsst jetzt sicherstellen, dass eure Integrationen & Apps damit umgehen können. (Hint: Die offizielle Aare.guru-App tut’s nicht…)

Die Änderungen sind auf der TEST-Instanz (https://aareguru-test.existenz.ch) bereits implementiert. Auf der LIVE-Instanz (https://aareguru.existenz.ch) folgen sie am 1. April 2022.

Betroffene Keys, welche neu null sein können:

  • flow (Insbesondere auch im Key aarepast)
  • flow_text
  • flow_gefahrenstufe

Betroffene LIVE-URLs, ab April:

Test-URLs:

Zukünftige Expansionspläne: Solothurn und Aarau

Wir würden auch gerne Solothurn und Aarau in der App aufnehmen und suchen für die Installation einer kleinen Messstation (Winziges Kästchen mit LoRaWAN-Anbindung, autonome Stromversorgung) Standorte an der Aare dafür.

Hast du in Solothurn oder Aarau einen Kontakt für einen Ort, z.B. ein Bootshaus, Ruderclub, Schwimmclub, Angler, Yachthafen, ARA-Ausfluss, Steg etc.? Melde den bitte bei mir (cstuder@existenz.ch).

P.S.: Das Techstack-Webinar vom letzten November ist hier online.

Link zum Wochenende: Datasette.io

Screenshot api-datasette für hydro_parameters

Das Open Source-Tool Datasette verwandelt SQLite-Datenbanken (Oder indirekt quasi jede CSV-Datei) schnell und unkompliziert in eine Webseite inkl. API. Es erlaubt einfach durch die Daten zu reisen, filtern, analysieren.

Screenshot api-datasette für hydro_locations

Erweiterbar mit Python-Plugins erlaubt es zusätzliche Visualisierungsmöglichkeiten wie diese Kartendarstellung.

Ich benutze es für meine OpenData-APIs für die Metadaten der Hydrologie- und SwissMetNet-Datenbanken. Dazu ruft ein Skript jeweils beim Deployment die API-Methoden auf und speichert die Resultate in die SQLite-Datenbank. Das ganze Skript als anschauliches Beispiel gibt es auf GitHub.

Office Hours

Auf das Projekt bin ich via diesem Artikel gestossen: Open source projects: consider running office hours. Letzte Woche habe ich einen dieser Slots gebucht und 20 Minuten mit Simon Willison konferiert.

Alles in allem ist Datasette eine ausserordentlich tolle Erfahrung, sowohl technisch wie auch menschlich. Ich kann es kaum erwarten noch mehr Anwendungsfälle dafür zu finden.

Aare.guru- & Existenz-API Newsletter Auftakt 2021

Den folgenden Text habe ich am 6. April 2021 an die API-Newsletter-Liste verschickt. Trag dich in den Newsletter ein um auf dem Laufenden zu bleiben.

Christian

Eine kurzfristige Ansage: Aufgrund einer Änderung an der Datenlieferung der Wasserwerte musste ich das sorgfältig entwickelte Refactoring der Existenz-API ohne weiteres Testen deployen. Es sind keine grossen Änderungen passiert, aber vielleicht habe ich etwas übersehen.

Keine Änderung an der bestehenden Aare.guru-API. Ein neuer Endpoint: widget

Minimale Änderungen an den Metadaten (Stations- und Parameterliste) der Existenz-API: Die details-Felder sind umgestellt und etwas ausführlicher.

Was gibt’s sonst noch Neues?

  • Die APIs sind intern poliert und auf den neuesten Stand gebracht: Bessere Testabdeckung, schnellere Deployments, zentralisierteres Logging, neues Hintergrundbild für die Doku. Wir sind damit etwa auf Faktor 327 von 12.
  • Eine experimentelle InfluxDB-Datenbank steht zum Ausprobieren zur Verfügung. Die Credentials für die Verbindung sind auf api.existenz.ch dokumentiert. Es gilt Bring-Your-Own-Visualization. Ich hoffe im Verlauf des Sommers das ganze Datenarchiv der letzten Jahre dort hinaufzuladen.
  • Alle Metadaten zu den SwissMetNet- und Hydrologie-Zeitreihen sind jetzt als nifty Datasette verfügbar: api-datasette.konzept.space. Das ersetzt meine handgestrickte Karte.

Zu guter Letzt bin ich stolz mein Lockdown-Projekt zu präsentieren: Das AareDisplay.

Und jetzt heisst es warten bis der Schnee zusammen mit den Viren endgültig definitiv verschwindet, die Wassertemperaturen steigen und wir hoffentlich einen gemütlichen Sommer geniessen dürfen.

Aare Display

Aare Display: Fertig gebaut

2006 habe ich auf eBay einen digitalen Wecker günstig ersteigert. Die blaue Digitalanzeige darin war allerdings dermassen hell, dass an Schlaf nicht zu denken war. Also wanderte der Wecker in meine Bastelkiste und verblieb dort etwa ein Jahrzehnt.

Vor 4 Jahren kam ich auf die Idee, mir daraus eine Aare-Temperaturanzeige für den Schreibtisch zu basteln. Die Daten holt sich das Gerät via WLAN selbständig aus dem Internet, zur Stromversorgung reicht ein einfaches USB-Netzteil.

Lötarbeiten auf dem Balkon

Vergangenen Corona-Lockdown im April 2020 stellte ich das Projekt endlich fertig. Den Code und das Schema gibt es auf GitHub: cstuder/AareDisplay.

Seit langer Zeit hatte ich dafür wieder einen Lötkolben angefasst und zum ersten Mal überhaupt habe ich ein Elektronikprojekt von Anfang bis zum Schluss durchgezogen. Gelernt habe ich viel, hier einige Gedanken:

  • Das Ökosystem rund um die ESP8266 ist toll: Bibliotheken, Support, Blogbeiträge, YouTube-Tutorials. Jedes Problem das ich hatte, hat schon jemand vor mir gelöst.
  • Die ESP8266- und ESP32-Mikrokontroller machen Spass (Eingebautes WLAN, genügend Speicherplatz, diverse Schnittstellen) und sind günstig (Ab SFr. 3.-, Development Boards sind ab SFr. 9.- erhältlich).
  • Die ausführlichen Vorarbeiten haben sich gelohnt: Der Prototyp auf dem Breadboard, danach das Übertragen des Schemas zu KiCad. Dazwischen fleissiges dokumentieren in meinem Entwickler-Tagebuch.
  • Die Aare.guru-API hat sich bewährt: HTTP-Zugang ohne TLS, die leichten Methoden und neu wäre sogar direkter Text-Output möglich. Damit wäre der mitkompilierte JSON-Parser hinfällig.
  • Zu meiner absoluten Freude funktioniert das Aare Display schon monatelang wunderbar stabil.

Kurzer Werbeblock: Anstelle monatelanger Lieferzeiten aus China habe ich lieber etwas mehr bezahlt und mir Teile & Werkzeug prompt von der lokalen Bastelgarage liefern lassen.

Nahaufnahme Sieben-Segment-Anzeige mit Multiplexer
Die Lötstellen sehen akzeptabel aus. Ein bisschen stolz bin ich schon.

Einen äusserst interessanten Aspekt des Projektes fand ich ganz zu Beginn: Als ich den Digitalwecker auseinandernahm, interessierte ich mich für die verbauten Komponenten und habe diese etwas gegoogelt. Gefunden habe ich einen Digitalen-Wecker-Komplettlösung-Chip namens UTCLM8560. Als Softwareentwickler welcher praktisch ausschliesslich mit General Purpose-Prozessoren hantiert, war ich fasziniert von derartiger Hardware welche ein fixfertiges Produkt antreibt.

Kein Wunder hat der Hersteller des Original-Weckers hunderte von Uhren im Angebot: Das Problem ist gelöst, nur das Design wird noch endlos variiert.

Aare.guru- & Existenz-API Newsletter 2020

Den folgenden Text habe ich am 15. Oktober 2020 an die API-Newsletter-Liste verschickt. Trag dich in den Newsletter ein um auf dem Laufenden zu bleiben.

Christian

Eine denkwürdige Badesaison ist zu Ende gegangen: Bis spät in den September war die Aare für Normalsterbliche bebadbar. Neue Wörter in unserem Wortschatz. Das Virus brauchen wir gar nicht erst zu erwähnen. 

Was wir diesen Sommer getan haben

  • Wir hatten keine grösseren Ausfälle zu verzeichnen, die APIs liefen stabil. Im Hochsommer gibt es jeweils knapp 5 Millionen Zugriffe pro Monat, selbst im Oktober kommen täglich noch um die 50’000 Requests rein.
  • Die Dokumentationen sind hübscher geworden. Und mit OpenAPI/Swagger-Definitionen auch praktischer:

https://aareguru.existenz.ch & https://api.existenz.ch

  • Für Integrationen in IoT-Dings und Wearables und anderen Geräten mit wenig Rechenpower gibt es beim Aare.guru neu einen values-Parameter welcher ausgewählte Werte als Text zurück liefert. Nachwievor ist die API auch per HTTP erreichbar.
  • Neue Daten in der Aare.guru-API: Koordinaten der Messstationen sowie den Temperatur-Text im Kurzformat (text_short / temperature_text_short, weniger als 15 Zeichen).
  • Aare.guru-API-Responses werden standardmässig mit einer Cachezeit von 120 Sekunden zurückgegeben. Vielleicht stillt das etwas den Datenhunger einiger Integrationen. 

Was wir im Winter so treiben

  • Auf der Existenz-API ist jeweils nur ein Teil der historischen Daten verfügbar (30-90 Tage), das wird wahrscheinlich so bleiben. Allerdings möchte ich unser gesamtes Datenarchiv öffentlich anbieten, voraussichtlich in einer InfluxDB, sobald deren Version 2 released ist. Dann wird’s dann auch ein Grafana zum drin Rumspielen geben.

Soll es schneller gehen? Unterstütz uns mit dem Konsumieren von Konsumgütern in unserem Konsum.

Neue Dokumentation für api.existenz.ch

Meine APIs für diverse OpenData-Daten haben in den letzten Wochen eine aktualisierte Dokumentation im OpenAPI V3-Standard (Aka. Swagger) erhalten: https://api.existenz.ch/docs/apiv1

Zusätzlich verlinkt von der API-Startseite ist ein Newsletter mit unregelmässigen Updates zum Zustand der API.

Ich freue ich immer über eine Nachricht wenn dir die Daten von Nutzen sind.

Eine API für die Aare

Auf Schwumm.ch bin ich gelegentlich etwas am Aare-Apps basteln. Leider sieht man noch nicht so viel. Dafür gibt es ab sofort frische und alte Wasserdaten für Programmierer: Die Aare hat jetzt eine API.

Dokumentation und eine Demoseite gibt’s unter aare.schwumm.ch/api. Bitte nie vergessen bei eigenen Projekten als Datenquelle das Bundesamt für Umwelt zu erwähnen.

Und ich würde mich auch über eine Mail freuen, wenn du was Interessantes damit gebastelt hast.

Der Schweizer Google Maps-Klon: Geo.admin.ch

Ein wenig technischer ging es beim Vortrag an der OpenExpo 2010 über das Geoportal des Bundes vor: David Oesch und Hanspeter Christ stellten die Seite map.geo.admin.ch vor. Sie soll als zentrales Portal für alle Geodaten des Bundes dienen und steht anderen Bundesämtern gratis zur Verfügung. Private Institutionen können auf Anfrage ebenfalls die Karten via API einbinden und benutzen. Der Anstoss gab das Geoinformationsgesetz von 2007.

David Oesch berichtete über die organisatorischen Probleme dieses Mammutprojektes: Wie kann er es innerhalb eines Jahres mit knappen Budget zu Stande bringen, wenn alleine der Serverbeschaffungsprozess für Bundesämter 3 Monate dauert? Wie soll mit diesen Frist eine flexible Infrastruktur entstehen, ohne dass genau absehbar ist, wieviel Nachfrage es geben wird.

Die Lösung war ein Hack: Anstelle der zeitaufwändigen Beschaffung von Servern, hat sich das Team einfach bei Amazon EC2-Server und S3-Speicherplatz gemietet.

Hanspeter Christ konnte auf dieser Infrastruktur mit konsequenter Anwendung von Open Source-Software wie OpenLayers und MapFish innerhalb von kürzester Zeit ein flexibles Kartensystem aufziehen, welches der Konkurrenz in keiner Weise nachsteht. Sein Lieblingsvorteil von Open Source: Es sind keine mühsamen Vertragsverhandlungen notwendig und es entstehen somit keine Anschaffungskosten.

Ich habe mir das Angebot des Bundes etwas angesehen: Das Kartenmaterial besteht aus den legendär guten swisstopo-Karten, gepaart mit denselben Luftaufnahmen, wie man sie bereits von Map Search.ch kennt. Die Kombination dieser zwei Ebenen ist allerdings bei der privaten Konkurrenz besser gelöst. Das Bundesangebot richtet sich demnach auch eher an Benutzer der zahlreichen öffentlichen Geodatensätze.

Trotzdem, ich war sehr positiv überrascht von der Seite. Wer hätte dem Bund schon eine derart agile Entwicklung zugetraut?

Eine API für Mobility – Nachtrag

Währenddem ich weiter über die Genossenschaftsstrukturen versuche, meinen API-Vorschlag für Mobility zu verbreiten, passierte etwas unverhofftes: Ein Mitglied des oberen Managements ist über mein Blog gestolpert* und hat mir daraufhin eine Mail geschickt. Mein Anliegen scheint jetzt zumindest auch von oben in die Firma einzufliessen.

Deren Antwort fordert Geduld: Wenn ich das richtig interpretiere, wird im Moment die internen Informatik überarbeitet. Diese Arbeiten sollten 2011 abgeschlossen sein, und ab diesem Zeitpunkt dürfen neue Funktionen gewünscht werden.

Ich werde abwarten, was geschieht. Und merke mir schon mal vor, nächstes Jahr den nächsten Anlauf zu starten.

* = Oder wurde vom Grossen Bruder vorbeigeschickt.

Eine API für Mobility

Auf meinem fortschreitenden Feldzug für eine öffentliche Mobility-API bin ich mittlerweile diese Mail am Verbreiten:

Vorschlag
Schaffung einer offenen Informatikschnittstelle (API) zum Mobility-Reservationssystem

Erläuterung
Der Erfolg des Internet hat dazu geführt, dass nicht nur mehr Benutzer mit Webseiten kommunizieren, sondern auch Webseiten untereinander Daten austauschen. Beispielsweise ruft ein Reiseportal auf Anfrage bei mehreren Fluggesellschaften nach passenden Flügen für den Kunden. Damit dieser Austausch möglich ist, haben sich standardisierte Formate gebildet, zusammengefasst Webservices genannt.

Viele erfolgreiche Firmen im Internet bieten derartige Webservices an: Amazon, Ebay, Facebook, viele Blogs etc. Die Überlegung dahinter: Je einfacher die Kommunikation mit dem Anbieter ist, desto öfter wird er benutzt.

Eine API für Mobility
Vorstellbar ist ein zweistufiger Webservice für Mobility: Auf einer ersten Stufe kann ohne Authentifizierung nach Standorten, Fahrzeugen und deren Zustand (Frei/Reserviert) gesucht werden.
Um Reservationen über den Webservice zu tätigen, muss entweder der Webservice-Anbieter authentifiziert sein, oder der Benutzer einfach auf eine entsprechende Mobility-Webseite weitergeleitet werden, auf dem die Reservationsdetails bereits eingefüllt sind (So ähnlich funktionieren zum Beispiel Zahlung via Postcard übers Internet).

Vorteile
Mit der Standardisierungen dieses Zugangs, ist die Integration von anderen Systemen einfach möglich. Geschäftspartner von Mobility können einfach das Reservationssystem z.B. in ihre eigenen Spesenabrechnung einbinden.

Viel wichtiger aber sind die Individuen, welche zusätzliche Ideen haben, wie man Mobility einsetzen kann: Gratis implementieren sie diese und verhelfen Mobility zu noch grösserer Visibilität im Internet verhelfen. Das ist zum Beispiel mit der inoffiziellen iPhone-Applikation passiert: Der Entwicklungsaufwand wurde von einer Privatperson getragen, Mobility hat das Potential erkannt und die Idee aufgenommen.

Herausforderungen
Dank API-Schlüsselvergabe kann ziemlich gut kontrolliert werden, wer was auf der Schnittstelle tut. Missbrauch kann einfach blockiert werden.
Je einfacher die Schnittstelle gehalten ist, desto mehr Idee werden von Externen implementiert werden.