Software KNX Router: KNXD

Bei der Planung meiner KNX Smart Home Anlage habe ich mich damals dafür entschieden, einen KNX Tunnel für die Programmierung zu nutzen. Dies schien mir als eine einfache und kosteneffiziente Lösung, mit der ich nach der Programmierung auch einen Smart Home Server mit OpenHAB verbinden konnte. Alles funktionierte soweit reibungslos.

Kürzlich wollte ich jedoch einige Tasmota-basierte Smart Home Geräte über KNX IP in das KNX Netz integrieren. Dabei habe ich endlich den Unterschied zwischen einem Router und einem Tunnel verstanden. Ein Router kann als Brücke zwischen KNX IP und KNX TP arbeiten, ähnlich einem Linienkoppler. Leider gilt das nicht für den Tunnel.

Da ich keine weiteren 250 Euro für einen KNX Router ausgeben wollte, begab ich mich auf die Suche nach Softwarelösungen und stieß dabei auf KNXD. Diese schien eine einfache Lösung für mein Problem zu sein. Man konfiguriert zwei Schnittstellen, zum Beispiel ein Netzwerkinterface für KNX IP und einen Adapter für KNX TP (in meinem Fall das Tunnelgerät), und die Software routet die KNX-Pakete zwischen beiden Schnittstellen hin und her.

Es klang einfach – und war es irgendwie auch – aber die Konfiguration erwies sich als Graus. Irgendwann wurde die Konfiguration von Kommandozeilenargumenten auf eine Konfigurationsdatei umgestellt. In Foren findet man hauptsächlich Informationen zu den alten Einstellungen. Es gibt sogar ein Programm, das die Argumente in eine Konfigurationsdatei umwandelt, jedoch erstellt es keine korrekten Konfigurationsdateien, mit denen das Programm startet. Lustigerweise ist auf GitHub genau dieser Fehler beschrieben, aber die Entwickler sind anderer Meinung und haben das Problem geschlossen. Ich denke, sie haben es nie ausprobiert.

Wie auch immer, nach viel Recherche habe ich es geschafft, eine Konfiguration zu erstellen, die funktioniert. Für meinen einfachen Fall benötigt man folgende Argumente: -e 0.1.203 -E 0.1.6:9 -b ipt:192.168.178.12:3671 -DRS -n "KNXD", wobei -e die Adresse des Routers, -E freie Adressen im Netz zum Routen externer Geräte, -b die Schnittstelle ins KNX-Netz (in meinem Fall das Tunnelgerät) und weitere Optionen für das Ausführen als Daemon, Router-Modus, Name usw. sind.

Als Konfigurationsdatei sieht das ganze so aus:

[A.ipt]
dest-port = 3671
driver = ipt
ip-address = 192.168.178.12
[debug-server]
name = mcast:knxd
[main]
addr = 0.1.203
client-addrs = 0.1.6:9
connections = A.ipt,server
name = KNXD
systemd = systemd
[server]
debug = debug-server
discover = true
router = router
server = ets_router

Man bemerke, dies ist die Konfiguration für ein Debian-System. Für andere Linux-Varianten sieht es wieder anders aus. Ich empfehle, das Ganze in einem Docker-Container laufen zu lassen, sodass man sich darum keine Sorgen machen muss. Glücklicherweise sehen das auch andere Menschen so, die ebenfalls ein fertiges Image bereitstellen. Hier ist eine funktionierende Docker-Compose-Datei, die die oben stehende Konfiguration als „config.ini“ bereitstellt:

version: '3.4'
services:
  knxd:
    image: tekn0ir/knxd
    container_name: knxd
    volumes:
      - ./config.ini:/config.ini
    ports:
      - 6720:6720
      - 3671:3671
    restart: always
    network_mode: host

T1D Basalrate: Wissenschaft oder Religion?

Die richtige Einstellung der Insulin-Basalraten ist ein entscheidender Aspekt der Pumpentherapie bei Diabetes Typ 1. Diese kleinen, konstanten Insulindosen, die über den Tag hinweg abgegeben werden, bilden das Fundament der Blutzuckerkontrolle. Basalraten sind sozusagen der unsichtbare Held im Hintergrund, der dafür sorgt, dass der Blutzuckerspiegel abseits der Mahlzeiten im Alltag stabil bleibt.

Das erklärte Ziel der Basalrate ist somit klar: Wenn wir unserer ganz normalen Routine nachgehen aber nichts essen, soll der Blutzuckerwert im Optimalbereich bleiben. Es fällt schnell auf, dass dieses Ziel nicht zu erreichen ist. Was ist denn eine „normale Routine“? Welcher Mensch hat jeden Tag einen identischen Ablauf? Was ist mit länger schlafen am Wochenende? Was ist mit Sport? Was it mit Schichtarbeitern? Was ist mit Hormonzyklen? Man muss das Ziel also entschärfen und eventuell umformulieren auf „Die Basalrate denkt den Insulinbedarf abseits der Mahlzeiten in den allermeisten Fällen korrekt ab“.

In der „Looper-Community“ hat die Basalrate nochmal eine größere Bedeutung, da die meisten Algorithmen die Basalrate als Basis für ihre Regelung nehmen. D.h. es ist besonders wichtig, dass die Basalrate tatsächlich in den allermeisten Fällen grob dem Bedarf entspricht. Gerade bei Schichtarbeit und Hormonzyklen muss man daher oft mit mehreren Profilen arbeiten, die auf die unterschiedlichen Situationen optimiert sind. Aber wie bestimmt man denn ein Basalratenprofil?

Die Erstellung eines individuellen Basalraten-Profils bei Diabetes Typ 1 kann auf verschiedene Weisen erfolgen. Hier sind vier mir bekannte Methoden, die Diabetiker:innen bei der Feinabstimmung des Insulinregimes helfen können:

1. Renner Schieber: Diese Methode verwendet den „Renner Schieber“ um ein initiales Basalratenprofil für den Patienten zu erstellen. Durch schrittweise Anpassungen der initialen Basalraten auf Grundlage persönlicher Beobachtungen (oder besser: durch Nutzung der Trieal & Error Methode) wird versucht, das ideale Profil zu finden. Soweit mir bekannt, ist dies die gängige Methode um neue Pumpenpatienten mit einem Basalratenprofil zu versorgen.
2. Trial & Error: Hierbei werden Basalraten durch wiederholtes Testen und Anpassen im Alltag ermittelt. Allerdings ist die Methode sehr zeitaufwändig, vor allem wenn mehrere Profile benötigt werden.
3. Zirkandiale Basalrate: Dieser Ansatz berücksichtigt natürliche Schwankungen des Insulinbedarfs während des Tages. Durch Anpassung der Basalraten in Abhängigkeit von Tageszeiten können bessere Kontrollen erreicht werden. Sie zeigt auf den ersten Blick große Ähnlichkeit mit dem Renner Schieber (was man aber niemals laut sagen darf 😉 )
4. Datenbasierte Methoden: Moderne Insulinpumpen und kontinuierliche Glukosemesssysteme ermöglichen datengestützte Ansätze. Hier werden Blutzuckerdaten und Insulinbedarf analysiert, um die Basalraten präzise anzupassen. Diese Methoden sind in der Regel genauer, erfordert jedoch technisches Know-how.

Die Wahl der Methode hängt von persönlichen Vorlieben und individuellen Bedürfnissen ab. Man kann fast von einer „Glaubensfrage“ sprechen. Verfechter einer bestimmten Methode legen eine erstaunliche Leidenschaft an den Tag, fehler und unzulänglichkeiten der jeweils anderen Methoden aufzudecken und anzuprangern. In den folgenden 5 Artikeln werde ich mir mehrere Methoden genauer anschauen und pro und contra Argumente sammeln.

Was ist eure Lieblingsmethode? Und Warum?

Nightscout bei 10BE jetzt kostenpflichtig! Und nun? [DE]

Ich bin seit vielen Jahren zufriedener „Kunde“ des kostenlosen Nightscout-Service von 10 be. Ich fand den Service immer sehr praktisch, zuverlässig und nobel! Das veranlasste mich auch regelmäßig eine kleine Spende abzugeben.

Anfang der Woche erreichte mich eine Email vom Support-Team in dem mir angekündigt wurde, dass 10BE quasi ab sofort kostenpflichtig wird. Die Begründung in der Mail erscheint mir nachvollziehbar und es ist auch ein erwartbarer Schritt. Ich habe mich auch schon die letzten Jahre gefragt wie das finanziell aufgeht, aber es war wohl immer ein Zuschuss-Geschäft. Ich denke niemand erwartet, dass so ein Server auf kosten von wenigen Privatleuten bereitgestellt wird.

ABER, ich habe natürlich etwas zu meckern:

• Die Deadline ist zu kurz: Die Deadline zum 1.10.21 finde ich relativ knapp. Als normaler Arbeitnehmer bleibt mir quasi keine Zeit darauf zu reagieren. Klar wollen sie schnell ihre Verluste minimieren aber es kommt mir so vor als ob hier druck aufgebaut werden soll.
• Exports sind kostenpflichtig: Der Export meiner Datenbank in eine andere MongoDB soll 15 EUR kosten. Warum?? Das wird doch automatisch erledigt, warum soll das Geld kosten ?! Ein Export ist wohl kostenlos, aber wer weiß was passiert, wenn der schief geht. Ich finde das unnötig und nicht sehr Benutzerfreundlich.
• Hohe Betriebskosten: Den Preis finde ich auch sehr hoch gewählt. Ich habe mal kurz überschlagen was der Betrieb eines Clusters bei AWS oder AZURE kosten würde und bin auf ein Bruchteil gekommen. Ja man kann noch etwas Personalkosten ansetzen. Aber von „null“ auf „so teuer wie Netflix“ finde ich schon hart. Ich hätte einen Selbstkostenbeitrag fair gefunden. Hier muss man aber von gewinnorientiertem Business ausgehen. Schade!
  Ich habe eine länger Diskussion in der Community gelesen, in der Martin (der Betreiber) erklärt, dass der Beitrag scheinbar nicht kostendeckend ist. Ich verstehe nicht ganz warum, denn aus meiner (über 10 jährigen) Erfahrung in dem Bereich müsste das problemlos möglich sein. Eventuell spielt die suboptimale Softwarearchitektur eine Rolle. NS ist eben nicht als Hyperscaler gebaut, sondern ein Open-Source-Community Projekt.
• Geschmäckle: Die Kundenstruktur von 10BE sind bestimmt hauptsächlich nicht-technik-affine Menschen, die zum Loopen eine NS Instanz brauchen. Für diese Leute gibt es quasi keine Wahl als die Kosten zu akzeptieren, denn in der Zeit kann man nicht schnell Urlaub nehmen, einen Helfer organisieren und den Umzug durchziehen.

Ich sehe ein, dass es sich hier um Jammern auf hohem Niveu handelt. Sicher gibt es gut Gründe für die genannten Punkte aber die sind nunmal nicht kommuniziert worden.

Was jetzt?

Ich denke seit der E-Mail nach, was für mich eine gute Strategie ist. Als Informatiker stehen mir ja quasi keine technischen Hürden im Weg. Allerdings habe ich auch nur begrenzt Zeit. Wahrscheinlich werde ich mir ein Jahresabo gönnen und in der Zeit an einer Alternative arbeiten. Im moment sehe ich folgende Möglichkeiten:

• Umzug zu kostenlosen Hosting-Angeboten: Das wäre der Standard-Weg, wie er auch in der OpenAPS Doku vorgeschlagen wird. Finde ich aber nicht optimal, da meine Daten dann im Ausland liegen. Außerdem können die sich auch jederzeit überlegen den Service einzustellen.
• Selbst hosten: Natürlich kann man sich immer einen Server mieten und NS installieren. Das wäre aber wirklich teuer im vergleich zum 10BE Angebot. Alternativ kann man es auch zuhause auf einem PC installieren der immer läuft. Kann man machen. Vermutlich würde sogar die tolle, deutsche, super langsame Internetanbindung ausreichen. Allerdings kümmert man sich dann auch selbst um Backups usw.
• Was neues bauen: Solche Umbrüche sind ja immer eine Gelegenheit. Immer wenn WhatsApp seine AGB ändert, gibt es andere Messenger die plötzlich Kunden bekommen. Ich habe einige Ideen wie man NS optimieren (und damit deutlich billiger betrieben) kann. Wenn ich die Zeit finde könnte es sein, dass ich einen eigenen Service anbiete 🙂

Was macht ihr mit euerer NS instanz? Bezahlen oder umziehen?

Building upon AndroidAPS? [EN]

Because of my blog post „Completing AndroidAPS objectives – the developer way“ many people contacted me to complain about the objectives. As I wrote in my article I see the need that people using AndroidAPS should have some kind of training, but I don’t like the way how it’s done today.

Also there are many other „functions“ in the app I find annoying (or patronizing). For instance:

• Objectives (of course)
• Spamming me with text walls when I want to give a second meal bolus
• Try to kill me with SMB after eating something as hypo treatment
• Many restrictions in the „Actions“ plugin
• Warnings with 1g carbohydrate suggestions (seriously? 1g ??)
• Version update warnings

Also I find there are missing features, such as:

• Logging fitness tracker data
• Using fitness tracker data for looping
• Interface for „Alexa“ commands
• Some kind of useful reminder for missed meal bolus

I thought about building a modified AAPS to takle these issues but the developers have some measures to make this harder than expected. For example, I just found a module to check the signature of the APK and compare it to a black list. If your signature is on the black list, the app will stop functioning.

In summary, using AndroidAPS as basis for your own app might be tricky. It takes a substantial amount of work to clear the code from all the „safety“ mechanisms to make sure the devs can’t pull a self destruction trigger, or leaking data, or something like that. I still don’t know if it’s worth my time to follow the „own app“ path…

What do you think about the measures of the devs? Do you think that’s the good right of the devs or is it violating the spirit of open source? Let me know in comments down below!

Petrol Car Efficiency [DE]

Es gibt viele gute Gründe ein EV (electric vehicle) anstelle eines Verbrenners zu kaufen. Aber lassen wir diesmal die ganzen Umwelt-, Lebensqualität- und Fahrspaß-Gründe außen vor…

Als Ingenieur interessiert mich immer die Effizienz eines Systems. Ich freue mich einfach über gute Lösungen für ein Problem, die möglichst wenig Ressourcen verschwenden. Ich denke ziemlich viele Menschen wissen, dass ein Verbrenner einen Spizenwirkungsgrad von ca. 30% haben (also 100% chemische Energie rein, 30% Bewegung raus) und eine Elektromotor einen Spizenwirkungsgrad von >90%. Ok Thema erledigt? Jein … die Energie muss ja irgendwo her kommen. Sagen wir mal wir erzeugen die elektrische Energie aus Diesel-Öl und vergelichen es zu einem Dieselmotor.

Also: Die Ausgangssituation sind zwei fast baugleiche Fahrzeuge, die sich nur in ihrem Antrieb unterscheiden. Um eine bestimmte Strecke zu fahren verbrauchen die beiden Fahrzeuge eine gewisse Menge Energie. Ein Verbrenner verbraucht Benzin/Diesel und ein EV verbraucht eletrkischen Strom aus der Batterie.

Als Beispiel habe ich mal den VW Golf ausgesucht, denn den gibt es als EV und als Diesel. Außerdem richtet sich das Fahrzeug an eine Zielgruppe die ein Auto als Fortbewegungsobjekt und weniger als Statusobjekt nutzt. Laut spritmonitor.de bekommt man folgende Verbrausdaten:

Verbrauchsdaten des VW E-Golf laut Spritmonitor (in kWh/100km)

Verbrauchsdaten des VW Golf TDI laut Spritmonitor (in l/100km)

Der Median für den Verbrenner ist also 5,8 Liter Diesel pro 100 km und des EV 16,2 kWh pro 100 km. Diesel hat einen durchschnittlichen Energiegehalt von ca. 9,8 kWh, d.h. der Verbrenner verbraucht 56,84 kWh pro 100 km. Ok aber wie viel Energie würde das EV aus Diesel-Öl verbrauchen? Hierzu nehme ich die Angaben von notstromdiesel.com zur Berechnung des Treibstoffverbrauchs. In den Unterlagen findet man folgende Formel:

Formel zur Berechnung des Treibstoffverbrauchs eines Diesel-Aggregats

Die Einheitenbetrachtung zeigt, dass man für Rho kg/l als Einheit verwenden muss. Also wir setzten ein: V_spez. = 0,220 (aus dem Datenblatt), Rho = 0,835, Eta = 94 (aus dem Datenblatt), P_el = 19,754 (die verbrauchten 16,2 kWh + 22% Ladeverluste) und erhalten 5,53 l/h. Die Rechnung geht davon aus, dass das Agregat im besten Wirkungsgrad 1h arbeitet, um die 100 km Reichweite in das EV zu laden.

Also ziehen wir Bilanz: Der Verbrenner verbraucht ca. 10x so viel Diesel-Öl wie das EV. Wenn das bei der nächsten Stammtischdiskusion nicht weiter hilft, dann weiß ich auch nicht 😀

Offensichtlich ist das eine enorme Vereinfachung die allerdings einen gewissen Wert hat. Je mehr Details in diese Modellrechnung aufgenommen werden (Förderung des Öls, Transport des Treibstoffs, Erneuerbare-Energie …) desto schlechter sieht es für den Verbrenner aus. Deswegen muss man eigentlich gar nicht weiter rechnen 😀 Wenig überraschend ist der Sieger das EV 🙂

Completing AndroidAPS objectives – the developer way

Note: I will not answer any questions how to skip the objectives. If you are a developer I’m sure you figure it out within a few hours, but if not, you probably should complete them as you need a basic understanding how the system works.

Currently I’m testing Android APS with a second pump to get some experience with it and to evaluate if we can use it for our research. Apperently it has an education feature called „Objectives“ which teaches basic knowlege about the system. Even though I think the basic idea is very good, I don’t like the implementation. I thought I should try it, just in case there is something for me to learn but after I finished the first two of them (which were indeed interesting) they asked me questions about their documentation… Yes maybe people should be encuraged to read the documentation, but why should I know how to monitor children?? Or how the documentation author wants me to backup my data ??? And why are the answers written to confuse the reader instead of making the user think about the question ?!

I hated this part so much that I went straight to the AndroidAPS gitter room and complained to the developers that they are wasting my lifetime (and theirs too) with these questions. In my rage I totally fogot that they are nice people, spending their free time to write this application… Well, I apologized a short time later, but my point holds true. These „Objectives“ are a complete waste of time (in my optinion). We as developers are not in charge to keep stupid people from doing stupid things. We should warn them, but that’s all. We should not annoy other interested developers / scientists… I went to the code and looked up the answers to pass this objective.

Afterwards, I came back to my „maybe I should try it“ mode. But the next objective wanted me not only to enact some temporary basals by hand, but also to wait several days … Why should I do the looping by hand??? I do this 30 years by now. That’s what the looping software is supposed to do… And the waiting time serves no reason at all (in my oppinion). But the objective says I could ask for a shortcut code … and now the interesting part … when the developers *review my data* and think I’m experienced enough to start looping. I immediately entered rage mode again: „Who are they to decide if I’m good enough to use this software!“ I thought (Obviously this violated my professional integrity). But ok … I went back to the code to find out how they generate their shortcut code. After finding the respective code I used some standard tools to generete the code by myself. Done. It can be so easy 🙂

FAQ Miniloop

Some people liked my board and got a free sample 🙂 Unfortunately, I’m now faced with some support issues and want to summarize the most important aspects for getting started:

• First of all: You do this at your own risk! I can’t give any kind of guarantees or support for the board or what you do with it. Please respect local law and regulations when you build your board.
• NEVER power your Pi with a power supply when the board is connected. The board has no safety functions at all and I have no idea what happens with the voltage regulator or the connected battery when you connect a power supply to the Pi.
• You have to solder one jumper on the board which was not described in the previous post. I made a picture to show you how to connect. However, in general you should consult the schematic to answer such questions.

• The oref0 setup doesn’t support the board directly, but you can follow the install instructions for general RFM69HCW radio modules here.

 

BUT NOTE: I stopped working on this board, as Adafruit released the RFM69HCW Bonnet board, which is a Pi HAT with a radio transceiver and a OLED display. It’s also supported by the oref0-setup. I’ll post some more information about it soon.

Miniloop v0.1 Daughter Board

Since three month, I spend some time in the OpenAPS community. Of course I build some rigs and I try to find the optimal configuration for me at the moment. My design goals are clear:

• I want a super small rig, to carry it around all the time.
• It should run for at least one working day (10 hours).
• It should be super cheap to build, since it is a commodity item and may get damaged regularly.
• I don’t want to spend to much time to care about software issues.

Thankfully, the OpenAPS community has nearly the same design goals, and thus, there is lot’s of soft- and hardware around the RaspberryPi Zero. The current state-of-the-art solution is the Pi0 together with a communication board called 900MHZ Explorer HAT. It offers a radio chip, a step-up converter to use 1S Li-Po batteries to power the pi, a charging circuit to charge the 1S Li-Po, some LEDs and a display. It works quite well, but let’s face it: I hate it! I have lots of complains about that board, but that’s a topic for a different post. The important points are:

• It’s way to expensive! (~180 EUR inkl. tax, toll and shipping).
• I don’t need the display.

So .. typical (maybe German) reaction from my side: „Hold my beer for a moment, I can do that!“. I thought a bit, how to make it super small and easy to build at the same time (since I have no clue about electrical engineering). My solution was to build a daughter board, holding a RF module, a chip antenna, the Pi0, a buck-boost regulator and a ADC for measuring battery voltage. I also added some buttons and some LEDs just in case …

After some work making a schematic and a board design, I simply ordered everything and tired to build it up. The board came as 3 in 1 panels, so I had so separate them first. The quality looks decent and it seems to have enough space for all components.

Motivated from this first success I started soldering. As one of my design goals was easy to build, I used 1206 SMD components, since they are pretty easy to solder but keep the design small. As power plug I used a XT40 connector, since I have a lot of 2S batteries from my drones (caution: the voltage regulator destroys itself and every other component on the board including the Pi0 if you put more voltage than 11V). The RFM69 is place able as SMD component out of the box. For the voltage regulator I had to cut the board a bit, to be able to solder the through hole connections to my daughter board, but wasn’t any of an issue.

BTW: As minimal version, it’s enough to solder the voltage regulator, the radio board and a power plug along with some pin headers for the PI0. As Antenna a piece of wire with a length of 86 mm (for 868 MHz) is good enough.

As always in my hardware projects, I had some issues while placing the components. I figured, the SD-card slot is unreachable if I solder the buttons and the Pi und the bottom layer.

To fix this, I put the Pi0 on the upper layer. The result isn’t as thin as it was supposed to be, but still ok (and still thinner as the Explorer HAT 😀 ). For now, it’s good enough as development platform and for testing. When the main problems are solved and the software is ported, maybe I’ll update the design to match the original design goals.

I put together some affiliate links if you want to gather the parts at Amazon:

• RFM69 Module 868 MHz
• Chip Antenna for 868 MHz
• Pololu Buck-Boost-Converter

One word on software support: Since the OpenAPS usually uses a different (and lot more expensive) radio device, the RFM69 is not supported out of the box. At the current time, it’s possible to run this board with the oref0 version 0.7.0-dev, if the corresponding communication programs (programmed in GO-lang) are compiled with the tag „-tags rfm69“. More information about this is shown on github. I’ll work on this and write an update when the software is full compatible.

PS: I have some left over boards, which I’ll give away for free (except shipping). Just ask if you like to have one 🙂

Contour NEXT Link & Link 2.4 Teardown

Für die Insulinpumpen von Medtronic gibt es schon einige Jahre lang Blutzuckermessgeräte die das Messergebnis per Funk an die Pumpe übertragen können. Laut Hersteller braucht man das, um weniger Eingabefehler zu machen 😀 . Ich fühle mich zwar im Stande eine 2-3 stellige Zahl abzuschreiben aber finde es dennoch sehr praktisch, da es viel schneller und bequemer ist. Die aktuelle Reihe dieser Geräte sind die Contour NEXT Link für Paradigm Insulinpumpen und die Contour NEXT Link 2.4 für die neuen 600er Insulinpumpen. Ich habe mich immer gefragt warum man den Nachfolger 2.4 und nicht 2 nennt aber dazu gleich mehr!

Allerdings habe ich mich immer gefragt was technisch hinter dem Zauber steckt. Meine Annahme war, ein Standard-Prozessor der die Messung erledigt, ein Funk-Chip zur Übertragung und ein rieeeeesiger Akku. Ich wollte es dann doch aber etwas genauer wissen und hab mal eins auseinander genommen:

Mein erster Eindruck war etwas ernüchternd. Der Akku ist winzig (!!) und es ist noch jede Menge Luft im Gehäuse. Nicht das mir die Akkulaufzeit nicht reicht, ganz im Gegenteil. Aber man hätte das Ding halb so dick bauen können …. Ok weiter im Text: Man sieht eine schöne Platine mit integrierter Antenne, auf der anderen Seite das Display. Also mal weiter auseinander nehmen:

Unter dem Display findet sich ein Slot für die Teststreifen, zwei Mikrocontroller und jede Menge Kleinkram. Ich war etwas überrascht, dass es gleich zwei Mikrocontroller sind. Google lieferte mir auch keine belastbaren Informationen. Der eine ist ein „Toshiba T5DB0“ der vermutlich der Hauptprozessor ist, denn in einem Forum habe ich gelesen, dass der gleiche Chip in älteren Geräten zu finden ist. Der andere Chip mit dem formschönen Namen „F3796 018 usw“ scheint mir ein Displaycontroller zu sein, da er mit dem Display-Connector verbunden ist.

Hätte man sich meiner Meinung nach alles sparen können, denn ich benutze das Gerät nur um einen Teststreifen einzustecken und Blut drauf zu geben wenn ich dazu aufgefordert werde. Den Wert lese ich auf der Pumpe ab. Früher haben die Geräte auch schneller gebootet, da man kein Farbdisplay hatte auf dem 100 Logos eingeblendet wurden bevor man messen kann … Aber gut, lass sie machen.

Kommen wir zum interessanten Teil: Der Funkübertragung! Unter dem EM-Shield findet man einen Funk-Chip von Texas Instruments, den CC2430 (müsst Ihr mir jetzt glauben, ich habe das EM-Shield nicht vollständig entfernt da ich das Gerät noch brauche und konnte deshalb kein Foto machen). Das Datenblatt sagt, dass es sich um einen ZigBee-Chip auf dem 2.4 GHz Band handelt. Ahaaaa 2.4!!! Ich bin ein wenig überrascht, warum Medtronic von ihrem 868 MHz Band auf das 2.4er gewechselt sind. Aus meinen Vorlesungen habe ich noch im Hinterkopf, dass niedrige Frequenzen (im Vergleich zu hohen Frequenzen) weniger Energie brauchen und höhere Reichweite haben. 2.4 GHz hat den Vorteil, dass man die Antenne kompakter bauen kann und man mehr Bandbreite hat. Beide Punkte werden von dem Gerät nicht genutzt .. also … WTF! Man hat sich jetzt ein Band ausgesucht, dass dank WLAN total überlastet ist, mehr Energie verbraucht oder kürzere Reichweite hat und sich damit sicherlich einige Störungen eingehandelt …

Die einzigen beiden plausiblen Gründe die mir für so eine Entscheidung einfallen sind:

• Lizenzkosten für das 868 MHz Band (keine Ahnung was das kostet, aber soweit ich weiss ist 2.4 GHz weltweit kostenlos da es ein ISM Band ist und 868 MHz nicht).
• Man wollte diese (völlig nutzlose) „ich kann jetzt von meiner Pumpe aus einen manuellen Bolus geben“-Funktion einbauen, hat aber keine Lust gehabt das eigene Protokoll zu erweitern und hat ZigBee eingekauft. WTF ZigBee … das Protokoll über das es mehr security-break-Paper gibt als Bibeln im Jahr verkauft werden. Für ein lebenswichtiges Gerät!! Gäbe es doch nur ein Protokoll auf dem 2.4 GHz Band, dass halbwegs sicher und energiesparend ist und bereits für den Gesundheitseinsatz Protokolle definiert hat … Aber auf der anderen Seite ist das ganz nett, denn ZigBee ist deutlich leichter abzuhören als das 868 MHz Band, denn das Protokoll ist bekannt und die Hardware ist billig (das riecht nach einem Projekt).

Mich hat dann doch noch interessiert was die „alten“ Geräte zu bieten haben. Der Aufbaut ist prinzipiell identisch. Aber es ist natürlich kein ZigBee-Chip verbaut, sondern ein Funk-Chip der das 868 MHz Band unterstützt: Der CC1110 von Texas Instruments. Bei dem alten Geräte haben ich dann natürlich für ein Foto den EM-Shield entfernt 😉 .

Wir werden sehen wo das alles noch hin führt. Ich würde ja gerne mal in so ne Entwicklungsabteilung schauen und die Leute fragen was sie eigentlich so den halben Tag rauchen 😀 .

Sonoff Smart Home integration

Ich habe mir vor Monaten von Sonoff ein paar WLAN Relais gekauft, weil ich gelesen habe, dass sie auf dem ESP8266 von Espressif basieren.

Für alle die den ESP8266 nicht kennen: Schämt euch! Spass bei Seite: das ist ein WLAN Controller der sehr häufig auf Bastler und in Arduino WLAN-Modulen verbaut wird. Außerdem bietet er selbst relativ brauchbare (aber nicht besonders Stromsparende) Rechenleistung. Inzwischen lässt sich die Firmware auch ganz bequem per Arduino-Framework programmieren. Dadurch hat der Chip eine relativ große Community bekommen, denn ein Modul kostet gerade mal 2-3 Euro und Developer-Boards gibt es schon ab 8 Euro (convenient affiliate link). Inzwischen gibt es den ESP32, der (wie der Name suggeriert) einen 32Bit 2-Core Prozessor hat und sich ebenfalls (zumindest teilweise denn die Implementierung ist noch nicht fertig) über das Arduino-Framework programmieren lässt. Dieser bietet neben WLAN auch Bluetooth LE zur Kommunikation (noch ein convenient affiliate link). Märchenstunde Ende.

Ok warum ist das interessant? Sonoff ist ein China-Smart-Home-Hersteller der inzwischen eine ansehnliche Auswahl an Geräten hat (die alle auf dem ESP basieren). Das schöne ist jetzt, dass man die China-Firmware weg schmeissen und die Geräte gemütlich über das Arduino-Toolkit mit eigener Firmware ausstatten kann. Es drängt sich ja geradezu auf, die Relais per MQTT ansteuern zu wollen und sie dann in ein anständiges Smart-Home System einzubinden. Der Vorteil gegenüber dem kompletten selbstbau ist, dass man eine doch halbwegs brauchbar designte und gelötete Platine erhält und alles schön kompakt in einem Gehäuse sicher verpackt ist. Das alles zu einem attraktiven Preis und super zeitsparend. Außerdem sind die Programmierpins auf den Platienen prakitscherweise immer sehr gut erreichbar (oft ohne löten).

Wie so oft ist man nicht der Erste mit der Idee und nach kurzem googlen habe ich ein sehr cooles Projekt entdeckt, dass genau das macht: Tasmota. Das Projekt liefert (offenen (yeey)) Source-Code, um alles mögliche (wie auch MQTT Ansteuerung) mit den Sonoff Modulen zu machen. Außerdem unterstützt es nahezu die vollständige Bandbreite der Sonoff Produkte 🙂

Man kann ziemlich straight forward durch deren Wiki marschieren und einfach machen was da steht. Ich habe nur kurz PlatformIO eingerichtet, die Config so eingestellt, dass sich das Gerät mit einer statischen IP (geht schneller nach dem sleep) im WLAN anmeldet, MQTT (und sonst nichts) unterstützt, sich bei Leerlauf 250ms lang schlafen legt und über eine Web-Interface konfigurierbar ist… ideal! 🙂 Danach einfach Kompilieren und Flashen. Hat mich keine Stunde gekostet (inkl. einrichten und Doku lesen). Beim Flashen musste ich allerdings eine ordentliche Stromversorgung ran schaffen, denn mein FTDI-Adapter lieferte nicht genug Leistung. Das es dazu kein Hinweis im Wiki gibt finde ich seltsam, denn das ist ein übliches Problem bei den ESPs (dass sie eine anständige Stromversorgung beim Programmieren brauchen). Aber es sei ihnen verziehen, denn alles andere hat super geklappt.

Alles in allem bin ich sehr zufrieden mit dem Ergebnis. Das Ganze kommt jetzt in meinen Wohnzimmerschrank und wird mit ein paar Regeln in mein System integriert. Stay tuned for updates 😉