Travel-Status-DE-DeutscheBahn-4.07.tar.gz (signature)

• hafas-m: Fix uninitialized value warnings in "--list" output
• Improve support for non-DB HAFAS instances
• Fix day change handling in departure board mode. Previously, journeys arriving / departing after midnight had wrong timestamps in some cases.

Travel-Status-DE-DeutscheBahn-4.06.tar.gz (signature)

• HAFAS->station: rename "uic" to "eva"; add "names" and "evas" keys
• Rename Journey->station_uic to Journey->station_eva

Travel-Status-DE-DeutscheBahn-4.05.tar.gz (signature)

• StopFinder: add new_p constructor for async requests via promises

Travel-Status-DE-DeutscheBahn-4.04.tar.gz (signature)

• Journey->is_cancelled: correctly report cancellations in station board mode

Travel-Status-DE-DeutscheBahn-4.03.tar.gz (signature)

• HAFAS: Add "station" accessor
• Journey: Add station, station_uic and line_no accessors
• Journey->line now returns journey type as well as line number
• Journey->line_no provides the old Journey->line behaviour
• Journey: Add route_interesting accessor

Travel-Status-DE-DBWagenreihung-0.07.tar.gz (signature)

• Add ICE 3neo (model 408)
• DBWagenreihung: Rename train_powertype to wagongroup_powertype
• DBWagenreihung: Rename train_desc to wagongroup_description
• DBWagenreihung: Rename train_model to wagongroup_model
• DBWagenreihung: Rename train_subtype to wagongroup_subtype

I have a growing collection of mostly cheap buck/boost converters and am kinda curious about their efficiency and output voltage stability. Measuring that typically entails varying input voltage and output current while logging input voltage (V_i), input current (I_i), output voltage (V_o), and output current (I_o). For each reading, efficiency is then defined as (V_o · I_o) / (V_i · I_i) · 100%.

+-------------+
|             |
|    Input    |
|             |
+---+-----+---+
    |     |
    |     +-+
    |      I_i
    |     +-+
    +-V_i-+
    |     |
+---+-----+---+
|             |
|  Converter  |
|    under    |
|    Test     |
|             |
+---+-----+---+
    |     |
    +-V_o-+
    |     +-+
    |      I_o
    |     +-+
    |     |
+---+-----+---+
|             |
|    Output   |
|             |
+-------------+

The professional method of obtaining these values would probably involve a Source/Measure Unit (SMU) with 4-wire sensing and remote control to automatically vary input voltage / output current while logging voltage and current readings to a database. I do not have such a device here -- first, they tend to cost €€€€ or even €€€€€, and second, many of those are more at home in the single-digit Watt range. I do, however, have a lab PSU with remote control and access to output voltage and current readings, a cheap electronic load (without remote control), an ADS1115 16-Bit ADC for voltage measurements, and an ATMega328 for data logging. This allows me to manually set a constant output current I_o and then automatically vary the input voltage while logging V_i, I_i, and V_o.

There is just one catch: The ADS1115 cannot measure voltages that exceed its input voltage (VCC, in this case 5V provided via USB). A voltage divider solves this, at the cost of causing a small current to flow through the divider rather than the buck/boost converter under test. In my case, I only had 10kΩ 1% resistors at hand, and used them to build an 8:1 divider for both differential ADS1115 input channels. This way, I can measure up to 40V, with up to 500µA flowing through the voltage divider. Compared to the 100 mA to several Amperes I intend to use this setup with, that is negligible.

V_i + ----+                  VCC  GND           VCC  GND
         70k                   |  |               |  |
          +--+ +------------+  |  | +-----------+ |  |
         10k +-+A0          +--+  | |           +-+  |
V_i - ----+-+  |            |     | |           |    |
            +--+A1          +-----+ |           +----+
V_o + ----+    |  ADS1115   |       | ATMega328 |
         70k+--+A2       SCL+-------+SCL      TX+--------to USB-Serial converter
          +-+  |            |       |           |
         10k +-+A3       SDA+-------+SDA        |
V_o - ----+--+ +------------+       +-----------+

Of course, this whole contraption is far from certifiably accurate or ppm-safe, and even less so when looking at the real-world setup on my desk.

I did however find it to be accurate within ±10mV after some calibration, so it is sufficient to determine whether a converter is in the 80% or 90% efficiency neighbourhood and whether it actually outputs the configured 5.2V or decides to go up to 5.5V under certain load conditions. Luckily, that is all I need.

The bottom line here is: If you have sufficiently simple / low-accuracy requirements, cheap components that may already be lying around in some forgotten project drawer can be quite useful. Also, I really like how easy working with the ADS1115 chip is :)

I'm running a Home Assistant instance at home to have a nice graphical sensor overview and home control interface for the various more or less DIY-ish devices I use. Since I like to monitor the hell out of everything, I also operate an InfluxDB for longer-term storage and fancy plots of sensor readings.

Most of my ESP8266 and Raspberry Pi-based DIY sensors report both to MQTT (→ Home Asisstant) and InfluxDB. For Zigbee devices I'm using a small script that parses MQTT messages (intended for Zigbee2MQTT ↔ Home Assistant integration) and passes them on to InfluxDB. However, there are also devices that are neither DIY nor using Zigbee, such as the storage and battery readings logged by the Home Asisstant app on my smartphone.

Luckily, Home Assistant has a Rest API that can be used to query device states (including sensor readings) with token-based authentication. So, all a Home Assistant to InfluxDB gateway needs to is query the REST API periodically and write the state of all relevant sensors to InfluxDB. For binary sensors (e.g. switch states), this is really all there is to it.

For numeric sensors (e.g. battery charge), especially with an irregular update schedule, the script should take its last update into account. This way, InfluxDB can properly interpolate between data points, producing (IMHO) much prettier graphs than Home Assistant does. If you also want to extend your Home Assistant setup with InfluxDB, c hass to influxdb may be a helpful starting point.

Travel-Status-DE-IRIS-1.81.tar.gz (signature)

• Update stations list

Travel-Status-DE-IRIS-1.79.tar.gz (signature)

• Stations: Further geoocordinate fixes for Dutch stations.

Travel-Status-DE-IRIS-1.80.tar.gz (signature)

• Update stations list
• Fix MANIFEST (broken in 1.79)

Travel-Status-DE-IRIS-1.78.tar.gz (signature)

• Stations: Fix geocoordinates for a variety of Dutch stations. In some cases, they were off by several hundred kilometers.

Travel-Status-DE-IRIS-1.77.tar.gz (signature)

• Handle "Betriebsstelle nicht bekannt" in routes.
• Update station list

Travel-Status-DE-IRIS-1.76.tar.gz (signature)

• Improve handling of stations that are not yet present in IRIS ("Betriebsstelle nicht bekannt 1234567")
• Update station list

Travel-Status-DE-IRIS-1.75.tar.gz (signature)

• Update station list
• Note that station names are no longer considered unique. get_stations() and the get_station_by_… set of functions may return multiple entries with the same name, but different DS100 and EVA IDs. For now, get_station_by_name() retains its behaviour of only returning a single match if the name matches exactly – for multiple stations with the same name, it returns the one with the lowest EVA number. get_station_by_name() return value and semantics may change in a future major release.