What are temporal tables?

Temporal tables, also known as temporal data tables, are a feature in database systems that allow you to keep track of states of data over time. These tables store historical versions of data, providing a way to query and analyze how data has evolved over different points in time. A mechanism to fly back in time, so to speak. Such a feature is especially useful when handling data that does not only consist of immutable facts, but also data that is mutable or somewhat mutable. There is more mutable data than one might think. Let’s look at an example, a table of employees:

It looks simple enough, doesn’t it? It’s very immutable at first glance, one might think, but then life happens. Max and Erika get married, so both take the last name “Muster”. A year later, Max decides to be a stay-at-home dad and quits. Now, the table might look like this:

Answers to the questions: “Did we have an employee called Mustermann?” or “Did we have an employee called Musterfrau” are lost.

One might work around this by adding “employment_start” and “employment_end” columns and maybe some column like “maiden name”, but all of this only covers the cases we thought about. Things like a name change caused by a divorce would not be covered. Furthermore, we haven’t looked at more fluid data like addresses, for example.

From this example, we can see that building a history on the application layer might be a solution, but having a history on the database layer might be more convenient.

Basic layout of a temporal table

Temporal tables contain time slices of each row of the original data table. Practically speaking, all the data with an added “valid_from” and “valid_to” column. By that, there can be multiple rows of our employee data that were valid at different times. The temporal table of our employee table might look like this:

As we can see, all the states of our employee data are preserved in our history table:
We can see that there were once rows of Max Mustermann and Erika Musterfrau that changed to Max & Erik Muster. Afterward, the row of Max Muster stopped to exist.
We don’t have any reasons for these changes, but we have all the history, and we can have that without changing the application by letting SQLite take care of it by using triggers.

Database-Triggers

Database triggers are powerful and versatile tools in the world of database management. Essentially, a database trigger is a set of instructions that automatically execute in response to a specific event or action within a database. The most common events for triggers are data modifications, such as inserts, updates or deletes. We will use triggers to log the data changes to our history / temporal table. One might say we instruct the database to log all changes.

How to get there with SQLite – Technical steps

To get it working there are two steps needed:
1.) Create the history table that holds the historic data based on the original data structure
2.) Create triggers that fill or update the history table on insert, update and delete of the original data.
Both of these steps might be done by hand, but I’m lazy. Therefore, I created a Python script that takes a SQLite Database and a table name and creates SQL-Statements for 1.) & 2.).

The script can be found over on github: https://github.com/balu-/temporal-tables-in-SQLite

Appendix:
I’m not the first one thinking about something like this:
Simon Willison has created something in the same direction (https://simonwillison.net/2023/Apr/15/sqlite-history/). His storage format is more sophisticated and space-preserving, but, in my opinion, less easy to access.
Thatdevsherry (https://github.com/thatdevsherry/historia) has taken a different aproch to reach a similar result. He built a layer between the application and the database, that layer creates, updates history data.

You can use the following settings to ensure that Dovecot and Postfix use a modern TLS version:

For Dovecot:

1. Open the file /etc/dovecot/conf.d/10-ssl.conf (Debian).
2. Uncomment the line starting with ssl_min_protocol and set it to ssl_min_protocol = TLSv1.2.

For Postfix:

1. Open the file /etc/postfix/main.cf (Debian).
2. Add the following directive: smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1.

Finally, reload Postfix with systemctl reload postfix and restart Dovecot with systemctl restart dovecot.

1. Check the state of timedatectl
Therefore type the comand timedatectl to the shell.
The output should look something like this:

Local time: Fr 2023-01-06 19:34:27 CET
Universal time: Fr 2023-01-06 18:34:27 UTC
RTC time: n/a
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no

The important part is “System clock synchronized: no” and “NTP service: n/a“. This tells us that there currently is no timesyncing via systemds timedatectl.

2. Install systemd-timesyncd

To install the missing software via apt by typing

sudo apt install systemd-timesyncd

After installing the software the output of timedatectl shows that syncing and ntp is working now:

Local time: Fr 2023-01-06 19:38:40 CET
Universal time: Fr 2023-01-06 18:38:40 UTC
RTC time: n/a
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

(Optional 3. Configure time servers)

For me the next step was to configure the timeservers that should be used. This might not be needed but my system doesn’t have internet access so the default ntp servers are not accessible. (To show which settings are active currently the comand “timedatectl show-timesync --all” can be used)

The timeservers are configured in /etc/systemd/timesyncd.conf after changing its content the service has to be reloaded/restarted by sudo systemctl restart systemd-timesyncd.

Erase flash of the esp
esptool.py -- erase_flash

One of my smart ESP devices wasn’t responding after a power down.
I debugged the problem by connecting it to a serial interface. On the comandline I saw that the chip wasn’t able to connect to its WIFI. To check wether the chip was fried or if its just the software thats messing around I had to delete all of its storage, to reflash the software afterwards. To do that i used the comands stated above.

To do so you need to use the deconz touchlink api (described here):

First step is to search for touchlink devices, its done by:
POST /api/<apikey>/touchlink/scan

Afterwards the result is queryed by
GET /api/<apikey>/touchlink/scan

The result will look something like this
{
"scanstate": "scanning",
"lastscan": "2022-10-12T08:14:12",
"result": {
"1": {
"factorynew": true,
"address": "0x00123abc"
}
},
}
Refresh that url until the scan is finished which is shown by “scanstate” having the value “idle”.

After having the full list of touchlink devices you need to identify which one is the desired light strip. To do so you can lat the devices “blink” by calling
POST /api/<apikey>/touchlink/<result_device_id>/identify where is the result id of the scanresult (like 1 in the example).

When you have the result id of the strip you want to reset simply call
POST /api/<apikey>/touchlink/<result_device_id>/reset

Förnuftig ist der neue Luftreiniger von Ikea und als solcher hat er mein Interesse geweckt. Aber scheinbar anders als viele Andere finde ich das Gerät nicht interessant um Viren aus der Luft zu filtern, dazu eignet er sich wohl auch nicht. Mir geht es eher um größere Verunreinigungen wie Pollen, Staub o.ä. das sich in der Luft tummelt.

So weit so gut, der Haken: Förnuftig lässt sich von Hause aus so gar nicht ins Smart Home integrieren. Das Gerät hat als Interface lediglich einen Drehschalter mit den Stuffen „Aus“, 1, 2 und 3. That’s all.
Für mich ist hier die Challenge dies zu ändern, denn natürlich möchte ich den Filter am liebsten laufen lassen wenn mich der „Krach“ nicht stört. Und natürlich auch nicht dauerhaft sondern vielleicht in Intervallen. Oder z.B. dann wenn der Staubsauger fährt und Staub aufwirbelt. Und wer weiß was mir sonst noch so einfällt.
Es muss also eine digitale Steuerung ans Gerät.

Abkürzung – der einfache Weg

Der erste Gedanke in Richtung smarte Steuerung war schon da vor dem Gerät:
Entsprechend simpel ist er: Eine schaltbare Steckdose.
Dank des analogen Drehschalters “merkt” sich der Luftfilter seinen Zustand auch ohne Strom. Mit einer schaltbaren Steckdose lässt sich also sehr einfach zwischen “Aus” und der am Gerät eingestellten Stufe umschalten.
Ich hab hier einfach zu einer Steckdose mit Tasmota Firmware gegriffen,
zum einen weil ich sie da hatte, zum anderen da diese sich super ohne Cloudanbindung nutzen lässt.

Die Umsetzung ist einfach, Zwischenstecker rein, fertig, aber die Möglichkeiten sind es leider auch. Die schaltbare Steckdose kann also nur ein erster Schritt sein. Deshalb hab ich mir als nächstes das Innenleben angesehen.

Aufschrauben

Wenn man die Stoffbespannung und den Filter aus dem Gerät entfernt, offenbart sich der Förnuftig als schlichter, in meinem Fall schwarzer Kasten.

Dabei wirkt das Plastik aus einem Guss, abgesehen von einem Streifen an der Oberseite, der sich auf der Unterseite zum Drehknopf befindet und in dem sich der kleine rote Knopf befindet.
Interessanterweise ist dieser Plastikstreifen mit “normalen” Philipps Schrauben befestigt, wohin gegen die restlichen Schrauben ein Dreiecks-Profil aufweisen.
Nach dem Lösen der beiden Schrauben kann der Plastikstreifen nach oben abgehoben werden. Darunter offenbart sich ein Teil der Elektronik.

Zum Vorschein kommt eine kleine Platine. Netterweise ist sie nicht überkomplex, hat nur einen Layer und der ist auch schön beschriftet. Ohne wirklich geschaut zu haben was passiert vermute ich dass diese Platine einefach eine Art PWM Signal für den Lüftermotor erzeugt. Aber so tief will ich gar nicht einsteigen, mir reicht es den Drehschalter zu “automatisieren”.

Selbiger sitzt über den zwei 5er Kontaktreien auf dem “leer” scheindenden Platz der Platine.

Messen

Ausgebaut und von oben sieht die Platine aus wie obriges Foto, geprägt vor allem durch den großen Drehschalter. Die Beschriftungen auf der Platinen unterseite weisen darauf hin, dass die Logik mit einem 5V Pegel arbeitet. Um das zu bestätigen habe ich flux das Multimeter verwendet und gemessen was beim Einstellen der verschiedenen Stufen geschieht. Dabei kam herraus, dass der Drehschalter 4 der von oben betrachteten rechten Pins schaltet. Für jeden Status (Aus, I, II und III) wird ein ander Pin auf GND gezogen. Für Aus der Erste, für I der Zweite etc. Es ist je nur der eine Pin geschaltet, die anderen Pins sind durch die Pull-Ups auf der Platine auf High (5V) gezogen [also bei aus 2, 3 und 4 auf 5V, bei I 1, 3 und 4 etc].

Löten

Nach dieser Erkenntnis kann der Schalter ab, und durch einen ESP ersetzt werden.

Aufgrund der 5V Logik reicht leider der ESP alleine nicht, sonder es ist auch ein Pegelwandler nötig der die 3,3V des ESP auf 5V umsetzt. Außerdem braucht der ESP durchaus etwas Strom. Deshalb ist noch einen DC-DC Wandler nötig, der aus den 24V des Netzteils 3,3V für den ESP erzeugen kann.

Das wars mit der Hardware, jetzt noch Software auf den ESP. Am einfachsten Tasmota und zack lässt sich der Luftfilter via MQTT schalten

By accident I ended up with an Garmin vivofit, that luckily could meet all of my requirements in the end. But first things first, the Garmin vivofit is a bracelet that tracks movements. It distincts between steps walked, steps runned and movement done while asleep. You might think that its not much but this data is quite interessting. Its amazing how many/ how little steps one does during the days. The vivofit runs on batteries, that should last for one year and may be replaced afterwards. So the no charging requirement is met. Whats left is the cloud connection. Out of the box the vivofit syncs with garmin apps against the “garmin connect” cloud. But…

Get the data from vivofit localy

But luckily there is a python implementation of the ant+ protocoll (openant). It’s the protocol that is used by the vivofit to transmit its data. Further more there is python code to download all the data from the vivofit, so called ‘.fit’ files. Its called antfs-cli. Now one may decode the ‘.fit’ files and extract its values to generate statisitcs, graphics and so on. I’ve written some code to dump the ‘.fit’ content to the mysql-db of a remote webserver, and further some php & js number of steps per day. If there is interest drop me a line and I might publish the code. Further more I think about creating a detailed description how to setup a raspi to read data from vivofit and display the data on a website.

After using all the python projects and my own code, the vivofit meets all my expectations.
And works like a charm.

Some day the described bugged me enough so i created an add-on which prevents firefox from shutting down if “CMD+Q” is pressed only once. The Add-on is called “CMD-Q Catcher” and may be found at the Mozilla-Add-on Repository. If you’ve found yourself in the same Situation in the past this add-on will help you in the feature.

That’s not nice. I do want to use SSHFP, partly because i think its a nice feature, partly because i hardly ever check the fingerprints of my hosts.

So lets fix OS X ssh client, shall we.

Key is building a new version of openssh. The easiest way to do so is using Homebrew. So install brew, if you havent allready.
After wards we need to add the ‘brew recipes’ for software thats already on a mac by default. This is done by
brew tap homebrew/dupes.
Half way there, secound step is to build openssh. We’ll build it with a few extra options. Worth to be mentioned is --with-ldns. As Jan-Piet Mens explains in his intresting post VerifyHostKeyDNS=yessssss using ldns is mainly about openssh being able to make sure valid dnssec is used for the record, and therefor not bothering you if there is a valid key as a SSHFP record secured by dnssec.
Openssh is build by
brew install openssh --with-brewed-openssl --with-keychain-support --with-ldns
Afterwards just follow the instructions given by brew:

For complete functionality, please modify:
/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist
and change ProgramArguments from
/usr/bin/ssh-agent
to
#{HOMEBREW_PREFIX}/bin/ssh-agent
Finally, add these lines somewhere to your ~/.bash_profile:
eval $(ssh-agent)
function cleanup {
echo "Killing SSH-Agent"
kill -9 $SSH_AGENT_PID
}
trap cleanup EXIT

\o/ We are done, ssh with -o VerifyHostKeyDNS=yes will work smoothly and hardly ever confirmed known_host-file hashes should be history.

Aber langsam, was ist das eigentliche Problem?
Ich habe zwei Rechner die ich sehr abwechselnd Benutze, und eine handvoll Dateien die ich mal hier und mal da brauche. Die gesuchte Software soll also die synchronisation der Datein bieten, so das die Datein offline auf den jeweiligen Rechnern zur Verfügung stehen. Die Software darf gerne mit einem Serverteil reden, dieser muss aber selbst betreibbar sein.

Was die Software nicht können muss:
Hellsehen können. Was ich damit meine ist, es ist klar das wenn Änderungen ein und der selben Datei gleichzeitig geschehen kann Software nicht zuverlässig sagen was das richtige ist. Das ist auch Okay, so lange dann einfach beide Dateien (z.B. mit unterschiedlichen Namen) weiterexistieren.

Die getestete Software:

Teamdrive – war die erste derartige Software auf die ich stieß (damals 2009). Daher ist mein Eindruck auf schon ein paar Tage alt, dennoch war er so ernüchternd das ich das nicht noch mal brauche. Zum einen erfüllte Teamdrive nur halb die Anforderungen, da es zwar die Daten die Synchornisiert werden auf einem beliebigen Webdav speicher ablegen konnte, aber zum Betrieb dennoch ein Teamdrive-Account benötigt wurde. Damals musste ich zudem beobachten, dass über die Email-Addresse welche ich nur für jenen Account verwendet habe nach einiger Zeit massiv Spam an kam. Zwar kann das Zufall sein, ein unschöner beigeschmack blieb trotzdem, und Teamdrive kann ich guten gewissens keinem Empfehlen.

Als Ersatz für Teamdrive tat sich bald SparkleShare auf. Bei Sparkleshare handelt es sich im Prinzip um ein Frontend für Git, was es zu Synchronisation tut ist nämlich das automatische commiten / pushen und pullen von git repos. Git zu erklären würde hier zu weit führen, nur so viel es ist ein Versionscontrollsystem zum verwalten von Sourcecode. Git an dieser Stelle zu verwenden ist eigentlich keine schlechte Idee, kommt allerdings mit dem ein oder anderen Nachteil: Git ist nicht gut geeignet größere Binärdateien zu verwalten. Auch vergisst git nicht, will sagen alle Dateien die über Sparkleshare synchronisiert wurden liegen, auch nachdem sie aus dem Ordner gelöscht wurden, noch im Git. Das muss kein Nachteil sein, aber man muss es eben wissen (und am besten noch wissen wie man mit git umgeht um diese Altlasten eventuell wieder loszuwerden wenns doch mal zu viel wird). Manchmal muss man halt unter die Haube, ansonsten tut SparkleShare aber sehr gut das was es soll und vorallem das ganze auch Cross-Platform unter Linux und MacOS (ja sogar auch Windows… ;) ).

Kurz darauf macht Owncloud gefühlt mit viel Wind von sich reden. Leider war das Ergebnis sehr ernüchternd, Owncloud kann sicher eine Menge, beim Dateisync zeigt es aber eher ein mangelhaftes Bild. Bei zwei gleichzeitigen Änderungen geht eine einfach Verloren, im nichts und ohne Hinweis. Das geht für mich einfach so garnicht, damit erledigte sich der Owncloud ausflug sehr schnell wieder.

Auch wenn SparkleShare seine Sache im Großen ganzen ganz gut macht halte ich natürlich weiter die Augen offen. So stieß ich die Tage auf ein scheinbar weniger bekanntes Tool namens OmniPresence. Dabei handelt es sich um ein Tool das von der Firma Omni geschaffen wurde, um Synchronisation für ihre eigene Software (OmniOutliner und OmniFocus) zu bieten. Allerdings Synchronisiert das Tool einfach einen Ordner und ist auch dafür gemacht Dateien unabhänig der OmniTools zu Synchronisieren. Als Backend spricht OmniPresence mit einem simplen Webdav-Server, wodurch auch größere und binärdateien kein Problem sind. Einziger Haken, OmniPresence gibt es leider nur für den Mac, sprich sobald es um Synchronisierung von Geräten geht bei denen nicht alle Macs sind scheidet OmniPresence leider aus.

Alles in allem bleibt als SparkleShare mein Favorit, allerdings finde ich OmniPresence von der Oberfläche und dem “Gefühl” her schöner ohne Linux support nützt mir das nur leider wenig.

Download newest Version

Ich bastele gerne mal und probiere dabei Dinge aus,
einfach weils geht. Wie der Zufall so will war heute dieser Blog dran. Ich hatte bereits vorher hin und wieder an Optimierungen geschraubt, dabei allerdings immer auf Datenspaarsamkeit und ähnliches geachtet.
Google Analytics kam daher z.B. bisher nicht in Frage. [Ja das ist einfach ein bischen meine Macke]

Umso mehr verwunderte es mich, als ich dann heute feststellte das dieser, mein eigener Blog, Skripte von Google nach lud. Und das gleich garnicht zu knapp: Ganze neun Scripte wurden bei einem Seitenaufruf von ajax.googleapis.com geladen. Der Sache musste also nachgegangen werden. Drehte vielleicht eines der Pluings frei, war in einem der letzten Updates eine entsprechende Änderung gewesen oder am schlimmsten gar war es eventuell jemandem gelungen Code bei mir einzuschläusen ?

Die Google-Suche war leider wenig erfolgreich. Lediglich einige Blogposts die beschrieben wie man all seine Scripte von Google läd tauchten auf, und das war ja nun genau das gegenteil von dem was ich suchte. Da das nun also nicht half war der nächste logische Schritt mal zu schauen wo diese Einbindung den eigentlich stattfindet. Also Shell aufgemacht, und die WordPressfiles nach “ajax.googleapis.com” durchsucht. Das Ergebnis deutete Relativ eindeutig auf “wp-includes/script-loader.php”. Hier werden scheinbar diverese “scriptaculous” Scripte aus den googleapis eingebunden.
Na das war zumindest schon mal konkreter. “wp-includes/script-loader.php” ist aber kein File eines Plugins, dass ist ein File des WordPress-Cores. Also nochmal schnell in die Suchmaske, und siehe da unter “Removed from Core” tatsächlich wurde in Version 3.5 diverse Scriptaculous-Scripte von “Mitgeliefert” auf die “Google-Version” umgestellt. WordPress-Core,umgestellt, dann müssten ja andere das “selbe Problem” haben, so dachte ich. Nun gut, schnell in ein-zwei WordPressblogs befreundeter Nerds aufrufen. Aber hier war keine Spur von “ajax.googleapis.com”.
Also doch mal genauer schauen wie das mit diesen Javascript libs in WordPress funktioniert.

Wenig später war dann auch die Sachlage klar und der “Schuldige” gefunden:
Wordpress hat ganz grob gesagt, einen Mechanismus der scheinbar verhindert das Scripte mehrfach eingebunden werden. Daher wird ein Script registriert (das passiert für die googleapi Scripte in der “script-loader” Datei). Wird das Script anschließend benötigt wird eine Funktion aufgerufen (bei den Scriptaculous-Scripten war es bei mir das Lightbox-Plugin) die dann dafür sorgt, das das Script eben genau nur ein mal eingebunden wird.
Sprich der eine Schuldige sind eigentlich zwei. Wobei das Lightbox-Plugin nicht wirklich was dafür kann, denn bei dessen letztem Update lieferte WordPress die entsprechenden Scripte noch frei Haus mit.

Abschließend ein etwas unschönes Problem, vor allem da mir kein schöner Lösungsweg klar ist.
Natürlich kann ich das Lightbox-Plugin deaktivieren, aber das kann ja nicht die Idee sein.
Ich kann natürlich auch in dem script-loader File die Locationen der Scriptaculous-Scripte von Googleapis auf meine Domain biegen, aber das ist nicht nur extrem unschön sondern geht auch bei jedem Update flöten.

Voll der Erwarung, dass das ja jetzt irgendwie hochglanz und hochnützlich -weil endlos teuer- sein müsste saß ich also vor dem Gerät.
Da saß ich also, und beim sitzen blieb es auch erstmal,
denn das passende hellblaue “Cisco-“Consolenkabel fehlte.
Ja, na gut, mein Fehler, hätte man auch früher dran denken können.
Also $Leute nach Kabel fragen, und hey das hat auch super geklappt.
Aber auch mit dem Kabel war es irgendwie unrund.
Die Console so völlig ungewohnt, na gut aber ich hab sowas ja auch noch nie gemacht.
Ohne zu wissen was ich tat also durch Konsole, Google und schließlich das Webinterface gehangelt,
und es ging … nicht.

Also andere Nerds mit Ahnung involvieren, weiter frickeln…

Ich viel vom Glauben ab als sich so ganz zum Schluss rauskristalisierte, dass die Hardware erst per TFTP mit aus $quellen bezogenen Images versorgt werden musste, damit die Funktionalität die man vorher schon konfigurieren konnte überhaupt da war.

Enterprise und so, wissen schon.

Also it’s recommended to use bcrypt as hashalgorythm from now on, and this is default for new installtions, existing installations wont change algorythm automaticaly.

But changing the algorythm in existing installations is quiet easy.
As always you should remember doing a backup at first.
After that do this simple steps:

1. First the DB scheme has to be updated, so that the filed named ‘md5’ can take 124 Characters. If you use mysql this change will be done by the following sql statement

   ALTER TABLE `users` CHANGE `md5` `md5` VARCHAR( 124 ) CHARACTER SET latin1 COLLATE latin1_swedish_ci NULL DEFAULT NULL;

   .

2. After adapting the DB, you may enable bcrypt by adding

   define("BCRYPT", true); 
   define("BCRYPT_ROUNDS", 12);

   to your config.php

3. As last step you simply have to sync. While the correspoding login, the FSyncMS-Software will replace the Passwordhash in your database with the new version.

Further more, if you’re using sqlite, you may now change the destination or name of the database file in config.php,
by the a statement like this:

define("SQLITE_FILE", "weave_db");

In this context I want to remind that the weave_db should never be accessible directly via web, also its data should be encrypted.
So eighter use .htacces or similar technology to deny access to this file via browser, or move it anywhere that is not served via your webserver.

Download newest Version

In the end it seems to be a bug in the 'gma500_gfx' module witch caused the Graphic-Blackout.
After blacklisting the mentiond modul, it worked again as it should.