EMS Bus Dekodieren und Steuern

Visits: 17

Meine alte Heizung ist ausgefallen. Die wurde von einer Junkers TRQ21 gesteuert – was nichts anderes war als ein Thermostat, der für eine Wärmeanforderung 24V auf die Steuerleitung legt.

Da bei mir der Thermostat in der Küche hängt, die am wenigsten geheizt wird, ist die Steuerung für meine anderen Räume suboptimal. Ich hatte den Thermostat weiter in Betrieb, damit der für Frostschutz funktioniert, aber ich hatte zusätzlich einen Raspberry Pi, der mittels eines einfachen Scheduling-Systems und einer simplen Weboberfläche den Thermostat überbrücken konnte, und einfach die volle Spannung auf die Steuerleitung legte, wenn ich es wärmer haben wollte.

Die neue Heizung, eine Bosch Condens 5300i, hat (leider) eine EMS Steuerung, was zwar technisch viel besser ist, aber es schwieriger macht, mit selbstgebauten Systemen eine Fernsteuerung umzusetzen.

Grundsätzlich kann der Raspberry Pi die Daten vom Bus lesen, er braucht aber einen Pegel von 0V (0) bzw. 3,3V (1). Der EMS-Bus liefert bei mir gemessen 10V (0) und 15V (1). Bei kbza.de fand ich den Bauplan für einen Pegelwandler, der jetzt bei mir auch so läuft. Ich habe nur für R1 10kΩ genommen, da meine Messungen ergaben, dass meine Schaltung schon bei etwas unter 10V einen HIGH Pegel ergab, mit 10kΩ statt 8,2kΩ schaltet es bei mir zuverlässig und das Ergebnissignal sieht auf dem Oszilloskop sehr gut aus.

Auf der Webseite ist auch ein Python-Skript, das allerdings für mich nicht funktioniert. Das Skript selber ist auch nicht ein Beispiel für gute Programmierung, aber immerhin ein Hinweisgeber.

Das Skript erkannte keine der Nachrichten, die bei mir vom EMS Bus kommen. Eine extrem vereinfachte Form liefert die eingehenden Daten als Hexwerte:

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import time
import serial
import sys

ser = serial.Serial(
 port='/dev/ttyAMA0',
 baudrate = 9600,
 parity=serial.PARITY_NONE,
 stopbits=serial.STOPBITS_ONE,
 bytesize=serial.EIGHTBITS,
 timeout=1
)

while 1:
    char = ser.read()
    hex = char.encode('HEX')
    sys.stdout.write(hex + ' ');
    sys.stdout.flush()

Bei mir kommt dann z.B. folgendes raus:

89 00 08 00 88 00 09 00 89 00 12 00 18 00 98 00 08 00 88 00 08 00 88 00 13 00 09 00 89 00 08 00 88 00 09 00 89 00 14 00 18 00 98 00 08 00 88 00 08 00 88 00 15 00 09 00 89 00 08 00 88 00 09 00 89 00 16 00 18 00 98 00 08 00 88 00 08 00 88 00 17 00 09 00 89 00 08 00 88 00 09 00 89 00 20 00 18 00 98 00 08 00 88 00 08 00 88 00 28 00 09 00 89 00 08 00 88 00 09 00 89 00 30 00 18 00 98 00 08 00 88 00 08 00 88 00 38 00 09 00 89 00 08 00 88 00 09 00 89 00 40 00 18 00 98 00 08 00 88 00 08 00 88 00 48 00 09 00 89 00 08 00 88 00 09 00 89 00 50 00 18 00 98 00 08 00 88 00 08 00 88 00 58 00 09 00 89 00 08 00 88 00 09 00 89 00 60 00 18 00 98 00 08 00 88 00 08 00 88 00 68 00 09 00 89 00 08 00 88 00 09 00 89 00 0a 00 18 00 98 00 08 00 88 00 08 00 88 00 0b 00 09 00 89 00 08 00 88 00 09 00 89 00 0c 00 18 00 98 00 08 00 88 00 08 00 88 00 0d 00 09 00 89 00 08 00 88 00 09 00 89 00 0e 00 18 00 98 00 08 00 88 00 08 00 88 00 0f 00 09 00 89 00 08 00 88 00 09 00 89 00 10 00 18 00 98 00 08 00 88 00 08 00 88 00 11 00 09 00 89 00 08 00 88 00 e4 00 10 20 2d 2d 00 c8 40 02 84 64 12 03 00 02 6e 00 00 80 00 00 87 0f 00 02 83 00 00 02 00 88 00 e4 23 00 01 54 00 9a 12 64 f9 00 88 00 e3 00 01 00 01 00 00 00 00 00 00 00 00 02 84 12 64 46 00 40 00 00 0e 00 88 00 09 00 89 00 12 00 18 00 98 00 08 00 88 00 e9 00 00 80 00 80 00 00 00 00 00 46 3c 00 00 00 00 10 ba 00 01 cf 00 00 00 05 02 00 3c 00 88 00 08 00 88 00 13 00 09 00 89 00 08 00 88 00 09 00 89 00 14 00 18 00 98 00 08 00 88 00 08 00 88 00 15 00 09 00 89 00 08 00 88 00 09 00 89 00 16 00 18 00 98 00 08 00 88 00 08 00 88 00 17 00 09 00 89 00 08 00 88 00 09 00 89 00 19 00 18 00 98 00 08 00 88 00 08 00 88 00 21 00 09 00 89 00 08 00 88 00 09 00 89 00 29 00 18 00 98 00 08 00 88 00 08 00 88 00 31 00 09 00 89 00 08 00 88 00 09 00 89 00 39 00 18 00 98 00 08 00 88 00 08 00 88 00 41 00 09 00 89 00 08 00 88 00 09 00 89 00 49 00 18 00 98 00 08 00 88 00 08 00 88 00 51 00 09 00 89 00 08 00 88 00 09 00 89 00 59 00 18 00 98 00 08 00 88 00 08 00 88 00 61 00 09 00 89 00 08 00 88 00 09 00 89 00 69 00 18 00 98 00 08 00 88 00 08 00 88 00 0a 00 09 00 89 00 08 00 88 00 09 00 89 00 0b 00 18 00 98 00 08 00 88 00 08 00 88 00 0c 00 09 00 89 00 08 00 88 00 09 00 89 00 0d 00 18 00 98 00 08 00 88 00 08 00 88 00 0e 00 09 00 89 00 08 00 88 00 09 00 89 00 0f 00 18 00 98 00 08 00 88 00 08 00 88 00 10 00 09 00 89 00 08 00 88 00 09 00 89 00 11 00 18 00 98 00 08 00 88 00 08 00 88 00 12 00 09 00 89 00 08 00 88 00 09 00 89 00 13 00 18 00 98 00 08 00 88 00 08 00 88 00 14 00 09 00 89 00 08 00 88 00

Nichts sieht so aus wie die “Header”, die das Originalskript suchte. Den Beschreibungen im EMS Wiki scheine ich auch nicht zu verstehen. Wenn ich mir nur 08 00 88 00 09 00 89 00 ansehe, macht das im Moment keinen Sinn. Was ich glaube zu verstehen ist dass eine Nachricht, in der das oberste Bit in der Empfänger-ID gesetzt ist, gefolgt von einem BREAK, eine dringende Anfrage an die entsprechende ID ist. Die Antwort – wenn es nichts zu senden gibt – ist die ID ohne das oberste Bit, gefolgt von einem BREAK.

08 ist eine ID – wenn ich das richtig verstehe sollte das die ID des Brenners sein. 00 kann ein Break sein, oder eine echte 0. Danach aber kommt 88 (= 08 + bit 7) gefolgt von 00.

Was ist ein BREAK frage ich mich da – das ist ein Byte mit Wert 0 und nicht gesetztem Stop-Bit, oder auch: die Leitung liegt relativ lange auf 0. Das serial Modul von Python kann diese Unterscheidung nicht liefern, allerdings kann der PL011 UART im Raspberry Pi das erkennen.

Mit cat /proc/tty/driver/ttyAMA kann man die Anzahl von Breaks sehen, die entdeckt wurden während Daten vom seriellen Port gelesen wurden:

0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:0 rx:2663 brk:1154 oe:1 CTS

Im Schnitt kam es also etwa auf 2 1/2 empfangenen Bytes ein Break. Wenn ich die Daten oben genauer ansehe, dann scheint es oft zu sein, dass eine ID (mit und ohne 7. Bit) kommt, dann 00 gelesen wird, dann wieder ID und 00. Dann gibt es noch ein paar Bereiche, die mehr nach sinnvollen Daten aussehen. Grob geschätzt würde ich glauben, dass fast alle als 00 gelesene Bytes in Wirklichkeit Breaks sind.

Natürlich könnte ich mir bei BBQKees Electronics ein EMS-Gateway kaufen, das soll alles wichtige können, aber ich würde gerne das Problem für mich selber lösen.

Also: wie komme ich an die Info vom UART, dass wir einen Break und keine 0 haben?

Linux: warum geht meine Festplatte nicht in den Schlafmodus?

Visits: 138

Ich habe mich nach langer Zeit wieder entschieden, dass einer meiner Server mit Gentoo laufen soll, statt mit Ubuntu. Im Zuge des Umbaus kam dann auch ein RAID mit netto 30 TB Speicherplatz zum Einsatz.

Ich möchte immer, dass meine Festplatten nur dann angeschaltet sind, wenn sie auch benutzt werden, daher setze ich gewöhnlich mit hdparm -S40 /dev/sd? einen sleep timeout von knapp 4 Minuten.

Nachdem ich alle notwendigen Daten auf das RAID kopiert hatte, blieben die Festplatten noch aktiv.

lsof brachte leider keine Erkenntnis, aber grob jede Sekunde schrieb irgendetwas auf das RAID. Ich bin dann auf laptop mode tools gestoßen, was ich mir auch mal näher ansehen muss. Das verspricht, dass ich Energieoptionen besser einstellen kann und auch, Festplattenaktivität besser analysieren kann.

Aber mit ps aux fiel mir dann noch der prozess ext4lazyinit auf. Dieser sorgt – sehr simple ausgedrückt – dafür, dass die eigentliche Formatierung der Platte im Hintergrund geschieht, und die Festplatte schon genutzt werden kann. Das ist auch schön so, aber ich hätte doch gerne, dass das bald vorbei ist.

Die Geschwindigkeit, in der ext4lazyinit arbeitet, kann mittels mount Optionen eingestellt werden (man 5 ext4):

   init_itable=n
          The lazy itable init code will wait n times the number  of  mil‐
          liseconds  it  took to zero out the previous block group's inode
          table. This minimizes the impact on system performance while the
          file system's inode table is being initialized.

Und das schöne hier ist, dass das im laufenden Betrieb gemacht werden kann:

mount -o remount,init_table=0 <mount point>

Ich hoffe, das ist schon der einzige Prozess, der die Festplatten wach bleiben lässt, aber ich werde es sehen, wenn die Initialisierung wirklich durch gelaufen ist.

Home Automation für mich – erste Schritte

Visits: 215

ZigBee ist also ein Funkprotokoll, mit dem IoT-Geräte sich mitteilen können. Es ist nicht WiFi, also muss ich den Geräten auch nicht einen potentiellen Zugang zum Internet bieten. Es ist ein etablierter Standard, also erwarte ich, dass das auch funktioniert.

ZigBee benötigt eine Empfangsstation, also habe ich mir einen Sonoff ZigBee 3.0 USB Stick sowie einen ESSENTIALS Heizkörper-Thermostat Zigbee gekauft. Ich empfehle Geräte grundsätzlich nur und dann auch explizit, wenn ich der Meinung bin, dass sie gut sind. Diese beiden Geräte erwähne ich nur, weil ich jetzt mit denen angefangen habe.

Weil ich dachte, bzw. eher nur hoffte, dass wir vielleicht mit Heinautomatisierung bereits an wirklich vernünftigen Standards angekommen sind, bin ich erstmal davon ausgegangen, dass ich einfach Home Assistant installieren könne und alles funktioniert wie Magie.

Home Assistant kann unter anderem mittels HAOS (Home Asssistant Operating System) direkt auf einem Raspberry Pi ausgeführt werden, im Idealfall braucht es nur etwas Zeit und dann ein Pairing mit allen Geräten. Benutzt man HAOS, dann richtet sich weitgehend alles selber ein, der USB-Stick wurde erkannt, aber nach dem ersten Boot mit der neu geschriebenen SD-Karte dauert die Einrichtung noch fast eine halbe Stunde. Allerdings ist alles noch automatisch und man muss nur warten.

Unter http://homassistant:8123/ steht dann eine Weboberfläche zur Verfügung. Mit ein paar Klicks konnte ich dann nach ZigBee-Geräten suchen lassen. Diese müssen sich im Pairing-Modus befinden. Wie das aber bei dem Thermostat geht, dazu lässt sich die Betriebsanleitung nicht aus. In der steht

Die Steuerung und Verbindung mit dem Smartphone sowie der
essentials Smart Home App erfordert zwingend den Einsatz der
essentials Smart Home Zentrale.

Und wenn man die Smart Home Zentrale gekauft hat, dann soll die App die Information raus geben, wie der Thermostat in den Pairing-Modus gebracht wird. Andernfalls darf ich nicht wissen, wie das geht.

ESSENTIALS Heizkörper-Thermostat Zigbee Pairing: oberen Knopf für 4 Sekunden halten

Wenn der Thermostat in den Pairingmodus geht, kommt kurz auf dem LCD das Wort “Pair”. Home Assistant findet dann auch ein Gerät, allerdings weiß HA nicht, was es damit anfangen soll.

Zu dem Thermostat kamen nur 2 Datenpunkte automatisch ins System, RSSI (received signal strength indication) und LQI (link quality indicator), mehr nicht.

So direkt weiß ich nicht weiter. Ich kenne mich auch nicht genug mit ZigBee bzw. home automation aus, um zu beurteilen, wo das eigentliche Problem liegt.

  • Ist der Standard einfach nicht ausreichend, um – z.B. wie bei Bluetooth – alle wichtigen Gerätetypen per Class compliance zu erkennen und anzusprechen?
  • Ist Home Assistant einfach nicht gut genug?
  • Möchten alle Hersteller von Geräten vielleicht möglichst nicht kooperieren?

Ich vermute, dass es letzteres ist. Jeder Hersteller von Home automation Geräten will immer noch zusätzlich seine höchst eigene Zentrale mit verkaufen und den Anwender in sein Ökosystem zwingen. Dann muss das Opfer der Kunde alle zusätzlichen Geräte auch von diesem Ökosystem kaufen.

Nicht nur, dass ich das für sehr kundenunfreundlich halte, ich bin auch der Meinung, dass dadurch viel Elektromüll produziert wird. Weiterhin bin ich der Meinung, dass sich solche Hersteller gerade über längere Sicht selber damit ins Aus manövrieren. Gerade, wenn ich eine größere Installation plane und z.B. alles in meinem Haus automatisierbar machen möchte, muss ich mir Gedanken über Interoperabilität oder Zukunftssicherheit machen. Wird <kleiner Hersteller> noch in 3 Jahren existieren und weitere Geräte / Ersatzteile liefern können? Wird <kleiner Hersteller> Firmwareupdates liefern, wenn Sicherheitslücken bekannt werden? Wird der Cloudservice von <kleiner Hersteller> in 2 Jahren noch am Netz sein? Stehen die Server für die Dienste von <kleiner Hersteller> alle in China?

Bei diesen Fragen muss ich eigentlich zu dem Schluss kommen, dass <kleiner Hersteller> nicht in die engere Wahl kommen kann, und <großer Monopolist> auf dem Papier die sicherere Möglichkeit ist. Im Linux Magazin von 2017 ist das Dilemma schon beschrieben:

Und es gibt weitere gute Gründe, die gegen die fertige Hue Bridge von Philips sprechen: Wer etwa die schlauen Lampen von Ikea (Trådfri) besitzt, kann diese nicht mit dem Hue-Gateway verbinden. Denn die Ikea-Lampen sprechen ZHA, während Hue zwingend ZLL als Zigbee-Profil will. Im schlimmsten Falle muss man also zwei separate Steuergeräte betreiben, die voneinander nichts wissen: Komfortabel geht anders.

Natürlich könnte man verschiedenste Zentralen kaufen und diese dann über Home Assistant (in vielen Fällen zumindest) koordinieren, aber warum sollte ich mehr als eine Zentrale überhaupt haben? Zusätzlich ist es auch nicht so, dass <großer Hersteller> notgedrungen für Qualität steht, besonders schön beschrieben in einem Video von Linus Tech Tips.

Das vorläufige Fazit ist auf jeden Fall, dass es auch heute nicht möglich ist, einfach Heimautomatisierungs-Bestandteile zu kaufen und sie “einfach so” einzusetzen. Mindestens muss man sich lange mit Kompatibilitäten auseinander setzen.

Ich experimentiere jetzt erstmal mit Zigbee2MQTT rum, da ich da zumindest schonmal die Meldungen vom Thermostat roh sehen kann.

Home automation für mich

Visits: 172

Meine Heizung soll besser für mich funktionieren. D.h. dass nur geheizt werden soll wo und wann ich das möchte. In meiner Wohnung gibt es 5 Räume und einen Thermostat. Dieser Thermostat ist in der Küche montiert – die Küche gehört aber zu den Räumen, die ich am wenigsten heizen möchte.

Damit ein Thermostat an- und ausschalten kann, benötigt er neben einer Zieltemperatur, die über der aktuellen Raumtemperatur liegt (zum Anschalten) einen heizenden Heizkörper, damit die Raumtemperatur zur Zieltemperatur steigen kann (zum Ausschalten). Entweder heize ich die Küche gar nicht – dann kann der Thermostat aber auch nicht aus schalten, oder ich heize sie mit und rate, welche Temperatur in der Küche sein muss, wenn ich in meinen Wohnräumen vernünftige Bedingungen haben möchte. Allerdings, abhängig gerade auch von der Außentemperatur, ist das alles nur ein Raten.

Das Ziel für mich ist, 2 Räume sollen kontrolliert geheizt werden, 1 Raum bekommt etwas vom Heizwasser ab, und 2 Räume werden nicht geheizt. Solange einer der kontrollierten Räume noch geheizt werden muss, muss die Gastherme an sein (was sonst die Aufgabe des Thermostats in der Küche wäre). In den zu heizenden Räumen müssen Heizkörperthermostate jeweils dort die Wärme kontrollieren.

An-/Ausschalten der Therme ist eigentlich ganz einfach, da ist eine Signalleitung, die 0V – 24V hat. Mit einer simplen Transistorschaltung kann ein Raspberry-Pi das schalten. Ich habe mir da auch eine simple Weboberfläche für geschrieben, mit der ich die Therme (eigentlich die Pumpe der Therme) an und aus schalten kann, sowie simple Vorprogrammierung. Da die Schaltung parallel zu der bestehenden Funktion des Thermostats existiert, kann der originale Thermostat noch als Frostschutz funktionieren. Allerdings habe ich damit noch keine detaillierte Kontrolle darüber, wie warm die einzelnen Räume werden.

Also benötige ich ein Temperatur-Feedback sowie Thermostate an den einzelnen Heizkörpern.

Für mich klingt das so, als müsste das durch die eine oder andere Heimautomatisierung machbar sein.

Und jetzt versuche ich, zu verstehen, wie ich das hinkriegen kann. Insbesondere, da sämtliche Geräte nicht nach Hause telefonieren sollen. Alles soll über einen lokalen Server gehen (wie das von außen steuerbar ist, ist erstmal ein nachrangiges Problem). Ich möchte nicht, dass meine Steuerung davon abhängig ist, dass ein Hersteller einen Cloudservice auch in einem Jahr noch anbietet. Ich möchte auch nicht, dass der Cloudservice eines Herstellers die Information erhält, wie mein Lebensrhythmus ist.

Ein erster Versuch von mir, die Zusammenhänge und Anforderungen an die einzelnen Komponenten zu verstehen, brachte mir nur noch mehr Konfusion. Entweder bin ich nicht in der Lage, richtig zu suchen, oder es gibt sehr wenig Material für einen ersten Einstieg. Wäre ich nicht so paranoid, würde ich jetzt vielleicht doch irgendeinen scheinbaren Standard mit Cloud Service nehmen und dann unnötige Daten über mich auf Amazon Web Services speichern lassen, es scheint furchtbar kompliziert.

Glücklicherweise haben mir nette Benutzer auf Reddit geholfen, meine erste Verständnisblockade zu beheben.

Theoretisch sollte es also so funktionieren, dass ich an meinen lokale Server einen Zigbee-USB-Stick stecke, der dann mit einem Zigbee-Thermostat kommuniziert. Soweit so gut, insbesondere, da das Gerät dann nicht unkontrolliert im WLAN hantiert, sondern es ein anderer Kommunikationsweg ist.

Ich bin gespannt, was der Thermostat wirklich kann, insbesondere in Zusammenarbeit mit einem lokalen Server. In meiner Vorstellung kann ich nicht nur dem Thermostat mitteilen, dass er anmachen soll, sondern auch, dass ich Feedback bekomme, ob der Thermostat an ist, welche Temperatur er misst etc. Thermometer haben die alle, damit sie auch ihre eigene Funktion steuern können.

Wahrscheinlich wird es dann aber eher so sein, dass ich nur dem Thermostat eine Zieltemperatur geben kann, und es kommen keine auswertbaren Daten zurück. Aber ich weiß es im Moment noch nicht, die technischen Daten schweigen sich über so etwas natürlich aus.

Crumar Organizer T1 / T2 Netzteil

Visits: 293

Beide Geräte, Crumar Organizer T1 und T2, benutzen das gleiche Netzteil. Ein Transformator mit Mittenabgriff produziert Wechselspannung, die in einen Brückengleichrichter geht und dann +/- 22-24 Volt gegen Masse bzw. den Mittenabgriff darstellt. Über Spannungsregulierer (78M15 für positiv, 79M15 für negativ) werden dann die +/- 15V erzeugt, mit denen ein T1 / T2 arbeitet.

Fehlersuche

Alle T1 / T2, die ich bisher in den Händen hatte, hatten mindestens einen Fehler im Netzteil. Dank des übersichtlichen Aufbaus ist eine Fehlersuche recht einfach. In den meisten Fällen brennen die beiden 1A-Sicherungen (6) direkt beim Einschalten durch, daher sind die zuerst zu prüfen. Wenn die Sicherungen durchgebrannt sind, kann man natürlich sein Glück versuchen, die Sicherungen austauschen und hoffen, dass die nur zufällig durchgebrannt sind – ja, so etwas kommt vor, aber das habe ich bei diesen Netzteilen noch nicht gesehen.

Da die Spannungsregler (13) per Design auf 500 mA begrenzt sind (und +300mA / -200mA im Schaltbild gefordert werden), müssten die Sicherungen auch bei kurzfristig erhöhter Last funktionieren. Die Spannungsregler sind in Realität irgendwelche, je nachdem, was Crumar zu dem Zeitpunkt ergattern konnte. Hauptsache +/- 15V.

Wenn die Sicherungen aufgeben kann ich mir hier sicher sein, dass ein echter Kurzschluss vorliegt. Bei all meinen Netzteilen waren die 1µF-Kondensatoren (9/11/14) Tantal-versionen, und bei allen haben diese Kondensatoren aufgegeben was sich meistens als Kurzschluss gezeigt hat. Bei den größeren Elkos (laut Schaltbild beide 2000 µF, in Realität war aber immer der Kondensator in der negativen Spannungsversorgung lediglich ein 1000 µF) war es bisher 50/50 ob die defekt waren. In jedem Fall lohnt es sich, die Tantals mindestens an einem Beinchen auszulöten. Ich habe es bei 2 Netzteilen ausprobiert, dass ich die größeren Kondensatoren austausche, aber die Tantals drin lasse. Beides Mal explodierten die Tantals in der selben Reihenfolge – positiv vor Spannungsregler, negativ vor, positiv nach, negativ nach Spannungsregler.
Ich würde daher im Netzteil einfach sofort alle Kondensatoren tauschen.

Mir ist es noch nicht passiert, dass einer der Spannungsregler defekt wäre. Wären die direkt auf der Platine, würde ich die aber auch direkt austauschen, die Teile kosten nichts. Allerdings sind die Regler mit einer Steckplatine und dünnen Drähtchen verbunden. Ich möchte immer soweit möglich alles so original wie möglich erhalten, daher bleiben die Regler, wo sie sind. Würde ich da etwas anpassen wollen, dann würde ich mir direkt 2 15Volt Netzteile kaufen und die als vollen Austausch vom Originalnetzteil nehmen. Schon alleine, weil moderne Netzteile viel effizienter arbeiten. Das musste ich bei einem T1 machen, da dort der Transformator selber einen Kurzschluss hatte, und ich ehrlich gesagt keine Lust hatte, dann noch einen Ersatztrafo zu finden.

Wenn die Glimmlampe im Schalter nicht leuchtet, ist entweder das Kaltgerätekabel zum Netzteil kaputt, die 250 mA-Sicherung durchgebrannt, der Schalter defekt oder einfach die Glimmlampe hinüber – defekte Glimmlampe hatte ich schon, aber keins der anderen Probleme.

Mechanisches

Um an die Lötseite der Hauptplatine zu kommen, müssen 4 Schrauben gelöst werden. Die beiden näher am Transformator haben Abstandshalter während die beiden anderen Winkel zum Fixieren der Platine haben. Für mich ist die Schraube rechts oben im Bild nicht erreichbar, spätestens beim Einbau habe ich mit meinen Fingern keine Chance mehr.
Aber der Sicherungshalter und der Kühlkörper mit den Spannungsreglern kann abgeschraubt werden. Etwas Vorsicht ist hier geboten, ich reiße regelmäßig die dünnen Drähtchen ab und muss sie dann wieder anlöten.

Wenn alles gut gegangen ist, alle Kondensatoren ausgetauscht und neue Sicherungen eingesetzt sind, sollte das Netzteil am großen Steckverbinder (15) eine direkte Verbindung zu Erde haben, der kleinere daneben (16) eine Spannung von etwa -15V und der dritte (17) etwa +15V haben.

Da das Netzteil nicht immer (alleine) Schuld an Problemen ist, hilft eine kurze Messung bei dem ausgesteckten Stromanschluss (also hinter dem Netzteil). Wenn zwischen Masse und den +/- 15 Volt-Anschlüssen ein Widerstand im Bereich von 20kOhm besteht, kann man die Stromversorgung verbinden und alles könnte wieder funktionieren.

Bei einem T2 habe ich derzeit zwischen +15V und Masse gerade mal 63 Ohm, und das sinkt noch, wenn wirklich Spannung anliegt. Damit habe ich an diesem Gerät dann doch mal den positiven Spannungsregler erledigt.

Salesforce – Vergleich von 2 orgs

Visits: 397

Das ist mal ein gutes Tool, da bin ich gerade drauf gestoßen: Salesforce Org Compare. Damit kann man die Metadaten von 2 Orgs herunter laden lassen, und die Differenzen (einfach ein Diff auf den heruntergeladenen Daten) anzeigen lassen. Das ist wunderbar, wenn man mal wieder vergessen hat, welche Teile alle für ein Deployment notwendig sind, oder wenn die Orgs unterschiedlich reagieren, und man keinen Anhaltspunkt hat, warum das so ist.

Es sollte eigentlich nicht notwendig sein, schließlich weiß man genau, was man geändert hat, der Kollege hat auch nicht auf einer anderen Sandbox widersprüchliche Sachen geändert…

Thermische Probleme mit Raspberry Pi 4

Visits: 508

Der Raspberry Pi 4 sieht mit seinem Gigabit-Ethernet und den USB-3 Ports genau danach aus, was mir die ganze Zeit fehlte. Einer meine 3er-Pis spielt seit geraumer Zeit mit 3 externen Festplatten NAS. Das natürlich nur unbefriedigend, da mit USB 2 und 100 MBit bei dmcypt-verschlüsselten Platten in guten Fällen 6 MB/s per Samba übertragen werden. Das reicht für vieles, aber längst nicht alles, was ein NAS so tun soll.

Der Pi4 kopiert von dmcrypt zu dmcrypt mit etwa 70 MB/s (über Samba kommt bei mir dann etwa 50 MB/s an – bei großen Dateien), das ist die richtige Richtung. Allerdings lief er beim Kopieren von 2 TB nicht durch, sondern stürzte mit einer Kernel Panic ab. Wenn der als NAS funktionieren soll, muss er auch stabil sein, schnell alleine reicht nicht.

Mit fiel schon beim ersten Starten auf, dass vor allem die USB-Anschlüsse sehr warm werden, die CPU war auch fast nicht mehr anfassbar. Spätestens in einem Gehäuse kann die Wärmeableitung nicht mehr reichen. Bei Tom’s Hardware wird berichtet, dass eine neue Firmware den USB-Controller kühler laufen lassen soll, Tests zeigten 2°C Unterschied, was aber bei weitem noch nicht für den Betrieb in einem Gehäuse ausreicht. Meine Messungen (billigstes Infrarot-Thermometer) des CPU- und RAM-Chips zeigten Oberflächentemperaturen bis 62°C, wenn auf dem Bildschirm das Thermometer erscheint, und auch Thermal Throttling hinweist.

Mit

vcgencmd measure_temp

kann der CPU-Sensor ausgelesen werden. Bei 80°C auf dem Sensor zeigt sich das Thermometer. Meine Versuche bestätigen, dass bei Last nach etwas mehr als 3 Minuten der Prozessor bremst – kopiert der Pi verschlüsselte Dateien, haben alle Chips gut zu tun.

Mit aktiver Kühlung durch einen Lüfter (120mm auf 5 V statt 12 V, so nicht hörbar, und so aufgestellt, dass etwas Luft über die Chips zieht) bleibt der Sensor zwischen 50°C und 60°C, die Oberfläche liegt dann bei akzeptablen 36°C. Im Moment habe ich keine weiteren Abstürze, vielleicht ist die Temperatur das einzige Problem. Auf jeden Fall lasse ich den nur dann als NAS laufen, wenn ich einen Lüfter dran stellen kann, andernfalls ist mir das eine zu heiße Sache.

Atmel Atmega ISP Programmierung schlägt fehl

Visits: 1283

Von Pollin gibt es für 2,99 € ein ‘Entwicklungsboard’ mit einem Atmega 168PA drauf. Die Beschreibung ist dürftig, insbesondere, wie der In System Programmiert werden kann. Bei mir lag so ein Board etwas länger rum, weil einfach die Zeit fehlte.

Durchpiepen der Leitungen zeigte dann, dass der Programmer an folgende Pins am Pollinboard angeschlosen werden musste:

ICSP 1 (MOSI) – 11
ICSP 2 (Vcc) – Vcc
ICSP 4 (Gnd) – GND
ICSP 5 (RST) – RST
ICSP 7 (SCK) – 13
ICSP 9 (MISO) – 12

Vergleiche dazu das Anschlusslayout des Olimex Programmers.

Aber alles, was ich versuchte, die Kommunikation funktionierte nicht. Die Fehlermeldung war:

Timestamp: 2018-10-29 18:08:45.435
Severity: ERROR
ComponentId: 20100
StatusCode: 1
ModuleName: TCF (TCF command: Device:startSession failed.)

Failed to enter programming mode. ispEnterProgMode: Error status 
received: Got 0xc0, expected 0x00 (Command has failed to 
execute on the tool)

Da keine meiner Ideen fruchtete, bin ich diesem Troubleshooting gefolgt. Oszilloskop an der RESET Leitung zeigte dann nicht einen, sondern mehrere (ich glaube 5) Reset-versuche durch den Programmer. Das sollte so nicht sein. Das Lesen der Gerätesignatur in Atmel Studio schickt einen Reset, wenn alles gut geht.

Letztlich stellte sich heraus, dass ich zwar die Pins richtig raus gesucht hatte, aber einfach meiner eigenen Anleitung nicht gefolgt bin. MOSI hatte ich mit GND verbunden, und schon ging nichts mehr.

Ich habe noch weiter getestet mit allen Signalen: bei diesem Fehler kann es ganz einfach sein, dass ein Kabel nicht richtig angeschlossen ist. Am falschen Pin oder ein Kabelbruch – der Fehlercode ist immer derselbe wenn eins der ISP Signale fehlt, egal ob MOSI, MISO, SCK oder RST.

TBS5520SE – Multi-standard TV Tuner USB Box

Visits: 1476

Die kleine Box in schwarzen Metall verspricht, alles an Fernsehsignalen empfangen zu können, was so hier verfügbar ist.

An der Frontseite 2 LEDs, einmal in blau, um zu zeigen, dass das Gerät arbeitet, und einmal in grün, damit wird angezeigt, dass auf der aktuellen Frequenz ein Sender gefunden wurde. Aber davon sagt die nicht wirklich vorhandene Anleitung nichts. Außerdem sind die LEDs viel zu hell, reine Funktionsindikatoren sollten leicht sichtbar, aber nicht grell sein. Neben einem Monitor aufgestellt stört die Helligkeit massiv. 

Die Box hat einen Antenneneingang sowie einen LNB-Anschluß und ein USB-2.0 Interface.

Das Gehäuse ist aus Metall und hat ein paar Lüftungsschlitze. Die Beschreibung sagt: “Neben der guten Ausstattung und dem modernen Interface wurde auch auf eine geringe Leistungsaufnahme und damit eine niedrige Abwärme, für geräuschlosen Betrieb, geachtet.”. Ein Lüfter ist sicher auch nicht notwendig, aber das Gerät wird schon warm, die Lüftungsschlitze sind gerechtfertigt und gut.

Empfangbar seien DVB-S / S2 / S2X, DVB-C / C2, DVB-T / T2 und ISDB-T. Und das passt auch wunderbar zum zentralen Chip in dem Gerät, dem Si21832B. Dieser dekodiert all diese Standards für uns.

Daneben gibt es noch einen CY7C68013A für die USB-Kommunikation. Außerdem ein paar Verstärker- und Logikchips, aber keine Überraschung.Kommen wir zu den Treibern. Diese können von der Webseite herunter geladen werden, im Lieferumfang ist kein Datenträger – der sowieso nur veraltete Versionen haben würde.

Ich habe zum Ansehen des Video-Streams den kostenlosen TBS-Viewer ausprobiert. Der Sendersuchlauf hatte mich direkt demotiviert. Der Empfangstyp war auf Satellit voreingestellt.

Ein Wechsel auf DVB-T (‘Terrestrisch’) setzt immer die Transponderliste “DMB-TH Hong Kong” als Standard.Ein Suchlauf (Korrekt auf Transponderliste: DVB-T2 Deutschland gestellt) lieferte keinen Sender, über die gesamte Frequenzliste hinweg. Spezifisches Scannen einzelner Frequenzen, die hier definitiv empfangbar sind und unverschlüsselte Sender übertrage (514 MHz und 706 MHz), lieferten auch 0 Sender. Den Grund dafür liefert die etwas schwache Anleitung: absolut wichtig ist TBS 5520 SE ChangeMode-Tool v1.0.0.2, mit diesem kann der Empfangsmodus geändert werden. Bei mir war der auf Satellit voreingestellt; nur mit diesem Tool kann auf DVB-T2 umgestellt werden.

Danach funktionierte dann auch der Suchlauf im TBS-Viewer. Allerdings ist die Empfindlichkeit des Empfängers eher mittelmäßig. Eine mickrige Antenne, die auch an einem Fernseher hier eher schwierigen Empfang liefert, die aber an einer Xoro-Box sehr gut funktioniert, liefert auch am TBS-5520 keinen befriedigenden Empfang. Vermutlich braucht man mit dem Gerät meistens eine aktive Antenne.

Zum Test wollte ich auch den kostenpflichtigen DVB-Viewer installieren – TBS Viewer lief noch – und erhielt die Fehlermeldung, dass DVB-Viewer noch liefe. Meine Vermutung ist da klar, dass der TBS-Viewer eine verfiesemantuckte Version des DVB-Viewers ist.

Also: es funktioniert alles, aber die Dokumentation stinkt schon anrüchig, und die Lösung des Empfangsumschaltens mittels des Change-Mode-Tools ist suboptimal. Technisch Interessierte werden keine Schwierigkeiten damit haben, aber es ist nicht gut.

Ein für mich wichtiger Kaufgrund war die Zusage “Treiber für sämtliche 32- und 64-bit Betriebssysteme befinden sich im Lieferumfang: Win XP, Vista, Win 7/8/10 und Linux.” “Sämtliche 32- und 64-bit Betriebssysteme” … MacOS ist schon einmal nicht dabei, somit ist sämtliche eine leere Versprechung. Linux ist ein verlockendes Versprechen für mich; ich will immer noch den Empfang von Fernsehen auf einem Raspberry Pi machen, und das Dekodieren dann auf anderen Clients. Leider unterstützt der Raspberry Pi h.265 nicht. Linux und sämtliche klingt wunderbar. ARM-Linux scheint da aber nicht wirklich drunter zu fallen.

Mehr zum Linux-Treiber später….