Neues Interface FHT 8I

Könnte man alles, wenn es denn so wäre.

Leider hat ELV keinen Standart.

Siehe hier-

was sind das für DLLs von denen Du da sprichst?
Welche Funktionen bieten sie und wie werden sie eingebunden?

inpout32.dll (http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html) ->erlaubt direkte Portzugriffe (wie unter DOS)
Es gibt nur 2 Befehle:
outp(Adresse,wert)
inp(Adresse)
Damit kann man direkt die Hardware-Bausteine Lesen/Beschreiben.

port.dll (Beschrieben in „PC-Schnittstellen unter Windows“ von B.Kainka , Download unter http://www.b-kainka.de/port.zip, Referenz unter http://www.b-kainka.de/referenz.txt)
Im wesentlichen werden hier Funktionen für die serielle Schnittstelle zur Verfügung gestellt, wie man sie von früher kennt (opencom, rts/cts/dtr/ri usw. readbyte/Sendbyte sowie eine Reihe „exotischer“ Funktionen für Joystick-Abfrage,Soundkarte und Zeitroutinen.

Ich verwende die Module als Basis für eine I2C-Library für verschiedene Interfaces (Elektor,Horter,CC-Control usw).

Tommi

Hallo Tommi,

vielen Dank für die Information. :slight_smile:

Ich werde mich ab Donnerstag mal damit beschäftigen.

Ein schönes Wochenende und
Gruß
HJH

Kurzer Zwischenstand:

Mein IPS redet schon erfolgreich mit dem FHT8I. Hab’s über die Serielle gemacht (Mit Z-Dioden und Widerständen).

Eine Übertragung dauert ca. 40ms. Problem ist nur, dass das FHT8I vom Werk her auf Energiesparmodus eingestellt ist. Da braucht er nach dem ersten Bit ganze 53ms zum Aufwachen. Ich denke, ich werde das Busy-Signal noch zurücklesen müssen, sonst müsste ich die Übertragung von haus aus auf die 53ms/Bit ausrichten. Wenn man den Energiesparmodus aber ausschaltet, geht es dann eben in 40ms für das gesamte Telegramm.

Unten 2 Screenshots:
1.) Übertragung OK
2.) Übertragung NOK, da Energiesparmodus und Wakeup

Gruß
Erich

PS: So, jetzt wird der Gartengriller angeworfen und das Ergebnis gefeiert!:smiley:

Hallo Erich,

wenn Du die Wurst verdaut hast - nur zu Info:
mit welcher Hardware nimmst Du die Kurven auf?

Grüße

MST

PS: bei uns gab es schon Grünkohl

Der beste Platz zum Verdauen ist am Schreibtisch;)

Die Hardware: Ein genialer Kollege aus der Entwicklung hat das bei uns in der Firma mal für interne Zwecke entwickelt. Wurde dann mit vielen zusätzlichen Funktionen ausgestattet und als Produkt auf den Markt gebracht. http://www.sicam.de/Html/acp/protocol_test.htm Meins ist aus dem E-Schrott. Ein paar Stunden Fehlersuche - und es funkt wieder:D .

Gruß
Erich

Habe mal einen Adapter mit einem AVR-Prozessor programmiert.
Wer ihn nachbauen will, hier ein Bascom-Code, Hex-File und ein Layout zur Ansicht. Die Platine ist ein Vorschlag, der Code ist mit dem Pollinboard geprüft und funktioniert.
Die Platine mache ich nur wenn Bedarf besteht. Ist nur für Hobbybastler. :slight_smile:

$regfile = "m8def.dat"
$framesize = 42                                             'keine Ahnung ob das passt
$swstack = 42
$hwstack = 42
$crystal = 7372800                                          'Quarzfrequenz
$baud = 9600                                                'Normale Hardware RS232 (hier hängt PC dran)
Config Watchdog = 2048                                      'reset after 2048 mSec
Start Watchdog                                              'start the watchdog timer

'### I/O Declaration  ###

Config Portc.0 = Input
Config Portc.1 = Output
Config Portc.2 = Output
Config Portc.3 = Output

'### Aliase Declaration  ###
Clockpin Alias Portc.2                                      ' Clock,Data,Load(3xOUT),Busy(IN) laut Beschreibung
Datenpin Alias Portc.1                                      ' Busy ist In,
Loadpin Alias Portc.3
Busypin Alias Pinc.0

'###  Dimensionieren und Declarieren ##
Dim Datenausgang As Long At $70 Overlay                     ' 112.Stelle im Ram, könnte gehen
Dim Verknuepfung As Long
Dim Quersumme As Byte At $71 Overlay
Dim Daten As Byte At $72 Overlay
Dim Befehl As Byte At $73 Overlay
Dim I As Byte
Dim Temp As String * 1
Dim Dat As String * 3
Dim Befehlsbyte As String * 1
Dim Datenbyte As String * 1
Dim Flag As Byte

Enable Interrupts
Enable Urxc                                                 'enable den seiellen Interupt
On Urxc Seriell

Print "Version von Helmut Holm vom " ; Version(1)
Print " nur zur privaten Verwendung"
'################################ Hauptprogram
Do

Reset Watchdog
If Flag = 1 Then                                            ' eine Datenuebertragung soll bei "1" nu' sein
Befehlsbyte = Left(dat , 1)                                 'erst das "linke Bein"
Datenbyte = Mid(dat , 2 , 1)                                ' dann das "rechte Bein"
Befehl = Befehlsbyte                                        'konvertieren
Daten = Datenbyte
Dat = ""                                                    '
Flag = 0                                                    ' wenn das gemacht ist, auf ein Neues vom Ser.
Quersumme = Befehl + Daten                                  ' noch die Quersumme berechnen
Quersumme = Quersumme + 6
Gosub Ausgabe                                               ' jetzt aber raus damit
End If
                                                            ' wenn kein Flag, dann is' auch nix vom PC gekommen
Loop

Ausgabe:
Disable Interrupts                                          ' wir wollen nicht gestoert werden
Disable Urxc
Reset Loadpin                                               ' Sicherheitshalber mal Loadpin auf Low
For I = 1 To 24                                             ' 24 Bit sind zu uebertragen
Set Clockpin                                                ' Clockpin setzen--
   If Datenausgang.31 = 1 Then                              ' wenn Bit31 vom Wert des Datenausgang eine 1, dann
       Set Datenpin                                         ' setze Datenpin
       Else                                                 ' oder
       Reset Datenpin                                       ' nicht
   End If
 Do
   Loop Until Busypin = 1                                   ' wenn Busy noch Low warte auf High
 Do
   Loop Until Busypin = 0                                   ' wenn Busy High war, warte bis Daten übernommen
                                                              'und deshalb Busy auf Low geht

   Reset Clockpin                                           ' neuer Clock, neues Glück
   Reset Datenpin                                           ' Sicherheitshalber Daten lieber mal auf Low
   Shift Datenausgang , Left                                ' Wert Datenausgang einmal Links schieben

Next I                                                      ' Das machmal für alle 24 Bit
Set Loadpin
Enable Interrupts                                           ' Interupt wieder frei geben
Enable Urxc
Return
End                                                         'sicherheitshalber end program

Seriell:                                                    ' serielle Interuptprogramm
Flag = 1
Dat = ""
Temp = ""
    Do                                                      'Auf "Echo aus dem All" warten
      Temp = Inkey()
      If Temp <> "" Then Dat = Dat + Chr(temp)
    Loop Until Temp = Chr(13)                               'wenn Chr 13 = Return kommt, beenden
Reset Watchdog

Return
End                 

Grüsse Helmut

atmega8-fuses2.png

TEST_OVERLAY_M8_MIT_SER_0_FEHLER.zip (31.1 KB)

Bin mir sicher, da haben viele drauf gewartet…

Danke fürs posten.

Gruß,

Toni

Wenn man diese Variante nimmt und auch noch über FHT das Ventil anfährt, gibt es einiges zu berichten. Das Interface vergibt eigene, nach Zufall generierte, Adressen für das Ventil. Man muss also diese Adressen danach den FHT’s mitteilen und ev. auch der Ipsymcon Soft.
Zu der Ansteuerung: Nur Hex- oder Bin-Werte abgeschlossen mit (cr) =13 übertragen. Keine Asci-Codes.
Das Program wartet auf Zeiche abgeschlossen mit chr(13) und dekodiert die vorherigen 2 Zeichen.
Wenn der Code oder das Layout nicht so toll ist, bitte ich um Nachsicht, bin kein Profi.:wink:

Hallo Helmut,

die ComPort-Lösung ist nahezu kostenlos und damit sehr attraktiv.

Deine Lösung erfordert die Anfertigung einer (teuren) Platine.
Welche Vorteile hat diese gegenüber dem ComPort, dass sich dieser finanzielle Mehraufwand lohnt?

Gruß
HJH

Also die Platine kostet ca 8 Euro ungebohrt, Prozessor Quarz usw ca 20 Euro.
Kleines Uni-Netzteil noch…
Diese Kosten sind nicht so dolle, das Layout habe ich so gemacht, dass es unter dem Modul befestigt werden kann. 3 Löcher kann man benutzen, eins hat nur 'ne Auflage.
Ein nettes Gehäuse fehlt noch, aber ist es nicht immer so, bei Bausätzen? :wink:
Das FHTBi ist ja auch ein Bausatz.
Die Platinen würde ich als Sammelbestellung besorgen können. Den Schlaumeier (Prozessor) könnte ich bei Bedarf gegen Rückporto brutzeln. Da kann man sicher sich einigen.
Aber erstmal sehen ob überhaupt Interesse besteht.
Wie erwähnt, ich habe es mit dem Pollinboard entwickelt und auch ich habe noch keine Platine, da warte ich jetzt mal ab, ob noch „Welche, welche“ wollen.:slight_smile:
Geht selbstverständlich auch mit einem USB-Adapter, da nur RX/TX benutzt werden.
Ich verweise nochmal auf die Möglichkeit damit eine Fußbodenheizung programmieren zu können.
Das ging so nicht mit dem Funkset, da hier einige Verzögerungen in der Regelung berücksichtigt werden müssen.
Und auch die Herren der 1Wirer-Technik können mit einem Dallas 18X20, also ohne FHT’s Heizungen regeln. Mit eigenen Programmen, selbstverständlich…
Bei jetzt über 1500 Hits auf diesen Tread kann ich mir einen Anwenderkreis ausmalen. :slight_smile:

Gruß Helmut

Hallo Helmut,

alles, was Du aufführst, lässt sich auch mit der kostenlosen ComPort-Lösung realisieren (FHT-8I plus Material für 30Cent plus Skript).

Ich verstehe ehrlich gesagt immer noch nicht, wozu dieser Aufwand nötig ist. Aber das kann auch an meinem beschränkten Auffassungsvermögen liegen.

Viel Spaß noch.

Gruß
HJH

Vorteil von Helmut’s Lösung:
Er kann über den Atmel-Chip das Busy-Signal des FHT8I rücklesen und so die Übertragung danach zeitlich optimieren. Gerade wenn der FHT8I im Energiesparmodus ist, dauert es eine ganze Ewigkeit, bis er wieder wach ist und das erste Bit akzeptiert. Bei meiner ComPort-Lösung muss ich nach Hochlauf immer zuerst den Energiesparmodus ausschalten und danach hoffen, dass das FHT8I nicht rebootet wird. Darum sperre ich den Energiesparmodus 1x/h zur Sicherheit.An dieser Stelle ein Wunsch von mir: Möglichkeit zum Rücklesen der COM-Statusleitungen im IPS

Ganz Sicher ist die Übertragung aber weder bei der einen noch bei der Anderen Lösung. Stimmt die Checksum nicht, so verwirft das FHT das Telegramm ohne Komentar.
Vorteil meiner ComPort-Lösung:
3 Dioden, 3 Widerstände, 3 Z-Dioden und 1 Lötkolben und fertig ist das Ding. Netzgerät brauchen beide Lösungen. Ich hab’s seit ein paar Tagen ohne Probleme so laufen.

Fazit:
Helmut’s Lösung: Sehr elegant dafür halt aufwändiger
Meine Lösung: „cheap, quick and dirty“

Nachfolgend mein Code zum Ansteuern des FHT8I (Seid bitte etwas nachsichtig, meine PHP-Kenntnisse sind gerade mal 2 Wochen alt):slight_smile: :

<?
/*
*******************************
 IP-SYMCON Event Scripting
*******************************
File     : FHT8I_CMD.ips.php
Trigger  : 
Interval : 
*/

   //7..RTS....Data..3
   //3..TxD....Clock..2
   //4..DTR....Load..1

   //Instance-ID
   $iid = 30138;
   //Wartezeit für Pulslänge in ms
   $sleep = 1;
   //CMD holen
   $cmd = GetValueInteger("FHT_Cmd");
   //Datenbyte herauslösen
   $data = $cmd % 256;
   $cmd = floor($cmd / 256);
   //Checksum berechnen
   $chk = 6 + $data + $cmd;
   $chk = $chk & 0xff;
   
   //Bei "Energiesparmodus ausschalten" lange Wartezeit (erstes Kommando nach Hochlauf)
   if ($cmd == 0x26) $sleep = 60;
   
   //Senden
   SendByte($cmd,$iid,$sleep);
   SendByte($data,$iid,1);
   SendByte($chk,$iid,1);
   
   //Load anreizen
   COMPort_SetDTR($iid,True);
   IPS_Sleep(1);
   COMPort_SetDTR($iid,False);

   return;


   function SendByte($byte,$iid,$sleep) {
   //Send Byte to COM

      //Schleife über alle Bits
      for ($i = 1;$i < 9 ; $i++){

         //Maske auf oberstes Bit
         $temp = $byte & 0x80;
         //Abhängig vom obersten Bit RTS setzen
         if ($temp == 0x80) {
            COMPort_SetRTS($iid,True);
         }else{
            COMPort_SetRTS($iid,False);
         }

         //Clock-Impuls generieren
         COMPort_SetBreak($iid,True);
         //Falls Energiesparmodus: Erstes Bit braucht länger
         if ($i == 1) {
            IPS_Sleep($sleep);
         }else{
            IPS_Sleep(1);
         }
         COMPort_SetBreak($iid,False);
         
         //Nächstes Bit vorbereiten;
         $byte = $byte<<1;
      }
      
      return;
   }

?>

Gruß
Erich

Ich habe mir auch eine Lösung mit AVR gebastelt, weil ich es blöd finde, eine serielle Schnittstelle im Bitbang-Modus dafür zu „vergewaltigen“. OK, habe ich für I2C auch schon mal gemacht, aber erstens hat man nicht mehr überall eine serielle Schnittstelle,zweitens ist es am Rande der RS232-Spec(+/-12V-Pegel), drittens geht es nicht mit den USB-Adaptern, die nur TX/RX bereitstellen und letztendlich ist es pure Rechezeitverschwendung.

Der Vorteil ist, das man jedes Standard serielle Programm (in IPS das Comport-Modul) nutzen kann und das man den AVR auch dazu benutzen kann, eine USB-Schnittstelle anzusteuern. Das kann ein altbekannter FTDI oder zur Not auch der AVR selber sein.
Das kostet zwar etwas mehr als 30cent für die Z-dioden, Widerstände und 1Transistor für die Busy-leitung(1.30 fuer den AVR,5.90 für ein ftdi232RL+Kleinkram), ist aber wesentlich technologisch interessanter.

So hat halt jeder seine Preferenzen.

Tommi

fht8i.txt (3.13 KB)

Bin voll und ganz Deiner Meinung! Bei mir gings darum, vor der Heizperiode noch schnell mal meine bestehende Steuerung mit ein paar tausend Zeilen VB.NET und AVR-Code auf IPS umzustellen (zumindest mal den Heizungsteil). Als „alter“ AVR-Bastler werde ich sicherlich wenn Zeit ist auch auf die elegante Lösung nachrüsten:rolleyes:

Gruß
Erich

Also, ich bin dabei - ATMEGA"bruzle" ich mir aber selber;) .

Gruß
Erich

Hallo Erich,

ich stelle hier meine Lösung vor, wie ich sie ursprünglich mit dem NanoTerminal benutzt habe.
Das Skript ist für den ComPort umgeschrieben und ein wenig optimiert worden.

An dieser Stelle möchte ich mich bei Dir herzlich dafür bedanken, dass Du meine Anregung aufgegriffen und gezeigt hast, dass sie funktioniert. :slight_smile:

Zur Übertragungssequenz:
Jedes Kommando besteht immer aus der selben Anzahl von Bytes, nämlich 3. Daher wurden diese 3 Bytes zu einer einzigen 24-Bit-Sequenz zusammengefasst.

Zum Busy-Signal:
Die Bedeutung des Busy-Signals sollte nicht überschätzt werden. Es ist ein extrem simples Handshake-Signal, dessen Verhalten sehr gut vorhersehbar ist. Genaugenommen kann die Dauer des Signals auf zwei Möglichkeiten reduziert werden:

  • lang, beim Aufwachen (ca. 50…60ms)
  • kurz, im Wachzustand (ca. 1…2ms)
    Das bedeutet,dass es sehr einfach für ein Skript ist, sich darauf einzustellen, ohne den Aufwand einer physischen Abfrage treiben zu müssen. Aus diesem Grunde wird im Skript die Wartezeit für das erste Bit auf „lang“ gesetzt, so, wie Du es auch in Deinem Skript gemacht hast.
    Also: Es ist nicht nötig das Busy-Signal abzufragen.

Zum Energiesparmodus:
Wenn im Skript die (einmalige) Dauer des Aufwachens berücksichtigt wird, ist es auch nicht nötig den Energiesparmodus abzuschalten. In meinem Skript bleibt er aktiv, ohne das dabei Probleme auftreten.

Zur Verwendung der Handshake-Signale:
Die Handshake-Pins (RTS, DTR) sind nichts anderes als Digitale Ausgänge. Einer zweckdienlichen Verwendung steht somit absolut nichts entgegen. Ein sehr berühmtes Vorbild hierfür ist das LapLink-Kabel, das millionenfach in aller Welt zum Datenaustausch über den Parallelport verwendet wird. Ich glaube, nur sehr wenige Leute kämen auf den Gedanken, diese hochintelligente Lösung als „blöd“ oder als „Vergewaltigung“ zu bezeichnen. Ganz im Gegenteil: es stellt eine Bereicherung der Verwendbarkeit von vorhandenen Resourcen dar.

Mein Fazit:
Die ComPort-Lösung ist „cheap and quick“, aber alles andere als „dirty“!
Wer einen Standard-COM-Port besitzt, ist mit dieser Lösung zur Ansteuerung des FHT-8I mit Sicherheit am besten bedient.

Eine Lösung, die nichts kostet, sollte nicht automatisch als minderwertig angesehen werden.

Und hier das Skript:

// Dieses Programm stellt eine Funktion bereit,
// mit der Daten über eine serielle Schnittstelle (RS232) an ein FHT-8I gesendet werden können.
// Die Funktion arbeitet im "Blindflug", da das Busy-Signal nicht ausgewertet wird.
// RTS: Data
// TxD: Clock
// DTR: Load

define("FHT8I", 16023);                                  // Instance-ID des ComPorts



// Funktionsparameter: Instance-ID, Befehls-Code, Daten
SendFHT8I(0x33, 0x55);                                   // Dummy Befehl, LED leuchtet kurz grün
return;



function SendFHT8I($cmd, $dat)
{
  $cmd &= 0xff;                                           // Wert beschränken auf Byte-Größe
  $dat &= 0xff;                                           // Wert beschränken auf Byte-Größe
  $chk = (6 + $cmd + $dat) & 0xff;                        // Check-Summe berechnen (laut Bauanleitung)

  $seq = ($cmd<<16) + ($dat<<8) + $chk;                   // alle Bytes zu einer Übertragungs-Sequenz zusammenfassen

  for ($i=0; $i<24; $i++)                                 // es werden 24Bit (3 Byte) übertragen
  {
   ComPort_SetRTS(FHT8I, ($seq & 0x800000) > 0);          // zu übertragendes Bit ausmaskieren und ausgeben
   ComPort_SetBreak(FHT8I, true);                         // Clock setzen
   if ($i == 0) IPS_Sleep(50);                            // beim ersten Bit länger warten
   IPS_Sleep(3);                                          // Busy abwarten
   ComPort_SetBreak(FHT8I, false);                        // Clock rücksetzen
   $seq <<= 1;                                            // nächstes Bit bereitstellen
  }

  ComPort_SetDTR(FHT8I, true);                            // Load setzen
  IPS_Sleep(3);                                           // Busy abwarten
  ComPort_SetDTR(FHT8I, false);                           // Load rücksetzen
}

Gruß
HJH

Bei meinen Test hat es sich gezeigt, das man sehr wohl auf das Busy-Signal zurückgreifen sollte, wenn man die korrekte Übertrageung sicher stellen möchte. Dazu gehört auch, das man am Ende den Load-Impuls länger machen muss als das Busy-Signal andauert. Dazu muss man erstmal wissen, wie lange das Signal dauert.
Im Fehlerfall kann natürlich nicht viel passieren, ausser das der Befehl nicht funktioniert. Das kann man in Kauf nehmen, muss man aber nicht.

Zur Verwendung der Handshake-Signale:
Die Handshake-Pins (RTS, DTR) sind nichts anderes als Digitale Ausgänge. Einer zweckdienlichen Verwendung steht somit absolut nichts entgegen. Ein sehr berühmtes Vorbild hierfür ist das LapLink-Kabel, das millionenfach in aller Welt zum Datenaustausch über den Parallelport verwendet wird. Ich glaube, nur sehr wenige Leute kämen auf den Gedanken, diese hochintelligente Lösung als „blöd“ oder als „Vergewaltigung“ zu bezeichnen. Ganz im Gegenteil: es stellt eine Bereicherung der Verwendbarkeit von vorhandenen Resourcen dar.

Bestimmungsgemäß ist die RS232 Schnittstelle dazu ausgelegt, i.d.R. 7 oder 8 Datenbits und dazu noch evtl. Stopp und Parity-Bits zu übertragen. Dazu gibt es die Handshake-Signale, welche die UART auffordern/hinweisen, das Daten übertragen werden(sollen)
Der LPT-Port ist eigentlich dazu gedacht, 8 Bits auf einmal an einen Drucker zu senden und seine Antwort entgegenzunehmen. DAS ist das, wofür man diese Ports erfunden hat.
Zur Erfindungszeit dieser Ports hat definitiv noch niemand daran gedacht, das Programmierer einmal aus dem Zusammenhang gerissen einzelne Pins dieser Port setzten wollen. Natürlich kann man damit auch den Zweck erreichen, aber das ist meiner Meinung nach genauso, als ob man einen einzelnen Baumstamm fällt um über den Fluss zu kommen anstatt eine Brücke aus Beton zu bauen. Das Laplinkkabel ist nur aus dem Grunde so entwickelt worden, weil es damals nur ein langsames RS232 und den etwas schnelleren LPT-Port gab.„Blöd“ habe ich nicht geschrieben, es ist nicht dafür gedacht.

Mein Fazit:
Die ComPort-Lösung ist „cheap and quick“, aber alles andere als „dirty“!
Wer einen Standard-COM-Port besitzt, ist mit dieser Lösung zur Ansteuerung des FHT-8I mit Sicherheit am besten bedient.

…Der ist mit dieser Lösung am schnellsten bedient.Da kann ich zustimmen. Am Besten->da würde ich mich streiten, siehe oben. Schon, weil es nicht mehr automatisch RS232-Schnittstellen gibt, zweitens die geforderte Spezifikation nicht eingehalten wird und es letztendlich heute technisch bessere Möglichkeiten gibt.

Eine Lösung, die nichts kostet, sollte nicht automatisch als minderwertig angesehen werden.

Auch das habe ich nicht geschrieben. Ich habe geschrieben, das jeder seine Preferenzen hat. Viele Wege führen bekanntlich … in den Entwicklerhimmel. Ich wollte mit meiner Lösung in diesem Fall mein technisches Ego befriedigen und folgendes realisieren:

  1. eine vollständige Implementation des Protokolls incl. Protokoll-Fehlererkennung
    2.Eine Weiterentwicklungsmöglichkeit in Richtung USB-Anschluss offenhalten

Tommi

Hallo HJH,

sehr eleganter Code :eek: . Ich merke, ich habe noch einiges in Richtung PHP aufzuholen:mad: . Aber zum Glück ist heute früh entlich mein PHP-Praxisbuch mit 600 Seiten angekommen :smiley: .

Zur philosophischen Diskussionsrunde möchte ich auch einen kleinen Beitrag leisten:
Ich finde, beide Versionen haben ihre Daseinsberechtigung! Jede wurde aus anderen Beweggründen heraus entworfen. In Wirklichkeit ist es bei den meisten von uns ein schönes, aufregendes Hobby das eigene Haus zu automatisieren. Wenn ich denke, wie viele Stunden ich schon damit verbracht habe und das hochrechne, könnte ich mir alles als Fertiggerät vergoldet mit Platinauflage kaufen und wäre noch immer günstiger. Sehr oft ist einfach der Weg das Ziel aber manchmal möchte man halt eine Abkürzung zum Ziel machen.

Gruß
Erich

PS: Weil mir mal fad war, habe ich einfach in den Klo-Lüfter einen Prozessor eingebaut, welcher als Timer die Laufzeit steuert. Kann das gleiche wie ein Lüfter vom Bauhaus um ein paar Euro aber halt mit Flash-Speicher und 8MHz - krass oder?