JoergK

Hallo, sorry, ich war auf einem Anwendertreffen eines Softwareherstellers und konnte daher nicht antworten. Nochmals zum Aufbau: a) Es wird später eine oder mehrere Zündmodule geben, die entfernt voneinander stehen werden. b) Gesteuert wird das ganze über ein Tablet in einiger Entfernung. 1) Ich schließen nun jeden Kanal eines Zündmoduls an die Zünder an. 2) Danach schalte ich die Spannungsversorgung ein. Hierdurch fährt TF hoch. 3) Nun lege ich den Entsperr-Schalter um, womit alle angeschlossenen Schaltungen die entsprechende Versorgungsspannung erhalten. Weiterhin wird die Hauptspeisung durch Kondensatoren unterstützt. Diese Kondensatoren werden über Widerstände aufgeladen und letztendlich bei erreichen einer Schwell-Spannung werden die Widerstände überbrückt. 4) Zündmodul (im Koffer) wird abgeschlossen. 5) Entfernen vom Gefahrenbereich 6) Verbinden mit Zündmodulen über WLAN. 7) Durchführen von Kanaltests (Widerstandsmessung jedes Kanals und Berechnung ob Zündstrom ausreicht). Anlage wird schlafen gelegt. ... Ein paar Stunden vergehen nun ... 9) Anlage aufwachen lassen 10) Durchführen von Kanaltests. 11) Hauptspannung (36V) einschalten (über TF eines IO-Ports) 12) Warnton ertönen lassen. 30 Sekunden lang, gepulst 13) Optische Warnmeldung (rote blinkende LEDs) 14) Programm mit Zündreihenfolge ablaufen lassen. 15) Publikum Ooohs und Aaahs aufsagen lassen (machen die automatisch, ohne Quatsch) 16) Hauptspannung (36V) über TF ausschalten. 17) Warten auf Nachzündungen 18) Begutachten der Feuerstelle und Entsperr-Schalter ausschalten. 19) Hauptspannung ausschalten. Ende Bei 3 meldet sich der Summer schon und das geht leider nicht. Cheers, Jörg P.S.: Da ich im 36V-Teil noch einen Fehler habe, werde ich mich erst am WE mit der Firmware-Erstellung auseinander setzen.

Ja, wenn man wie in meinem Fall Sachen anschließt, die nur zu einem bestimmten Zeitpunkt ausgelöst werden sollen, dann schon. (Feuerwerk-Zündanlage) Zum Glück habe ich noch Hardware-Schalter eingebaut, welche die Hauptspannung erst einschalten. Randschaltungen, wie beispielsweise ein ziemlich lauter Summer (zur akustischen Warnung) sind aber direkt an die Versorgungsspannung angeschlossen. D.h. der Summer meldet sich beim Anlegen der Hauptversorgung bis zum Initialisieren. Unschönes verhalten, zumal der Summer ausgelegt ist, in einer Entfernung wahrgenommen zu werden. Wenn ich direkt am Gerät stehe und den Schalter umlege, holla die Waldfee, das klingelt in den Ohren... Ich hab versucht die setPortConfiguration-Output Einstellung in den constructor zu übernehmen (wie oben ausgeführt). Mal schauen was beim nächsten Testlauf raus kommt... Cheers, Jörg

Input ist wohl nicht das Problem, eher der Pull-up. Ich habe am Port einen N-MOS hängen, der entsprechende Sachen schaltet. Schaltung: Port-> Gate-Widerstand - NMOS | Pull-Down-Wiederstand | _ Durch Input-Pullup leitet der NMOS nach sehr kurzer Zeit und das ist unschön. Bei Output-Low sperrt er ordnungsgemäß und bei Output-High schaltet er sauber. Aber meine Frage ist damit immer noch nicht beantwortet. Muss ich es halt testen... Prozess: 1. Spannung anlegen. (Tinker und einige andere Sachen erhalten Spannung) ---- Ab hier müssen Tinkerforge-Baugruppen einen validen Status erreichen. 2. Hauptschalter betätigen (Sämtliche andere Schaltungen sind aktiv) 3. Entfernen vom Gerät. 4. Software starten und mit Gerät verbinden 5. Gerät über WLAN nutzen 6. Hauptschalter betätigen (Sämtliche andere Schaltung sind inaktiv) 7. Spannung trennen.

Wenn ich die Spannung anlege (nicht über USB, da ich WLAN nutze), fährt der Brick hoch und initialisiert die IO-Bänke. Von diesen IOs nutze ich ein paar zum Steuern von diversen Schaltungen. Bis ich mit einer Software die Bricklets neu initialisiert habe, ist es schon zu spät. Im Konstruktor könnte ich auch einfach am Ende die setPortConfiguration aufrufen, aber dann ist es auch schon zu spät. D.h. so früh wie nur irgend möglich die Ports richtig initialisieren. Cheers, Jörg

Hallo, ich muss für meine Anwendung das Standardverhalten der Firmware des IO16 Bricklets ändern. Statt eine Input mit Pull-Up benötige ich Low-Outputs. Sehe ich es richtig, dass ich lediglich diese Zeilen void constructor(void) { ... // Default is input pull up io_write(I2C_INTERNAL_ADDRESS_GPPU_A+i, 0xFF); io_write(I2C_INTERNAL_ADDRESS_IODIR_A+i, 0xFF); ... } wie folgt void constructor(void) { ... // Default is input pull up io_write(I2C_INTERNAL_ADDRESS_OLAT_A+i, 0x00); io_write(I2C_INTERNAL_ADDRESS_IODIR_A+i, 0xFF); ... } ändern muss? Hab mich leider noch nicht in die Firmware eingearbeitet, muss aber kurzfristig eine Lösung herstellen. Besten Dank im voraus. Cheers, Jörg

Hallo, ja so sehe ich das von den Code-Ausschnitt. Durch diese Schleifen belegst du dauerhaft den Thread, in dem die Schleife ausgeführt wird. Wenn du nun die schlechtere Alternative zum Testen nehmen möchtest, legt den Thread kurz schlafen. Do While Portal.inBewegung = True Threading.Thread.Sleep(500) Loop MsgBox("hin") ... Dann hat ein anderer Thread die Möglichkeit, in den 500ms etwas zu tun. Besser ist, wenn du im "Portal" statt der boolschen Variable ein Event erstellst. public Event IchHabeFertig Wenn du dann an den Punkt kommst, wo du die Variable inBewegung setzt, einfach ein RaiseEvent IchHabeFertig(). Auf der GUI musst du dann "nur" noch einen Handler auf das Event vom Portal setzen: AddHandler Portal.IchHabeFertig, AddressOf MeineMethodeUmZuReagieren Sehr kurz beschrieben, aber Google gibt die viele Treffer bezüglich Event-Handling etc. Der theoretische Hintergrund ist das Entwicklungsmuster Observer. Cheers, Jörg

Du erstellst Schleifen, höchstwahrscheinlich auf dem Hauptthread (den man niemals für soetwas nutzen sollte), die quasi dauerhaft den Prozessor blockieren. Dieses Relikt aus alten VB6 Zeiten (Application.DoEvents) sollte man wenn überhaupt extrem sparsam einsetzen und nicht in einer Warteschleife verwenden. Anstatt dem DoEvents hätte hier ein Thread.Sleep eher gepasst. irgendwas sinnvolles, je nachdem was du an Laufzeit erwartest. Wenn deine Steuerung 2 Minuten läuft bis die Endposition erreicht ist, sind 50ms übertrieben. Den Hauptthread alle 200ms oder 250ms schlafen zu legen wäre da eher gut. Kommt halt sehr drauf an. Wie gesagt, dein Hauptthread ist ständig damit beschäftigt, DoEvents auszuführen und blockiert mal gerne alles andere. Das .NET Framework muss man nicht darauf hinweisen, Hintergrund-Threads auszuführen. Das kann dies viel besser und schlauer von alleine. Also Finger weg von DoEvents (CompactFramework < 3.5 mal abgesehen, aber auch da sparsam). So nun zu einer besseren Lösung. Man legt ein Delegate an sowie ein Event. Der Hauptthread bindest du dann (Observer-Pattern) an das Event. Wenn du in deiner Steuerung den Wert "True" erreichst, setzt du nicht die Variable sondern feuerst das Event. Der Hauptthread wird informiert, aber vorsicht, wenn du deine Steuerung in einem anderen Thread hast, wird das Ziel des Events auf diesem ausgeführt. Der Backgroundthread darf aber keine GUI-Elemente verändern. Also mit Invoke-Required prüfen und über delegate auf GUI-Thread ausführen lassen. => GUI ist während der Laufzeit deiner Steuerung ansprechbar und keine lästigen und unnötigen Warteschleifen. Fazit: Thread.Sleep in Schleifen wenn du nicht viel ändern möchtest, Events und delegates, wenn du es richtig machen willst. Cheers, Jörg

Erstmal kurz, da ich unterwegs zur Arbeit bin. Schau dir mal delegates und invokerequired an. dann erkläre mal, was dein code da oben macht. Damit meine ich nicht, was hinter den methodenaufrufen steckt. Sondern was der code genau macht. Stichwort schleife und dieses dämliche doevents. Dann wirst du wohl verstehen, was daran nicht so toll ist und warum es zu großer wahrscheinlichkeit zu fehlverhalten kommt. just my 2 cents. Ja ja Gemeinde, ich werde im Laufe des Tages mehr dazu sagen. Aber erstmal sollte man Nachdenken was man macht...

Wow habt Ihr extrem trockene Luft... 40-60% sollten es sein. (Lüften?!?)

Hallo, nachdem ich nun länger nicht hier war, mal einen Zwischenstand. 1) Ich habe einiges bezüglich Elektronik aufzuholen/aufzuarbeiten. Daher meine lange Abwesenheit. Nun habe ich endlich meinen Kompromiss zwischen Hauruck-Elektrik und Elektronik gefunden. Dennoch wollte ich TF-Einheiten galvanisch trennen, also hab ich einige Optokoppler verbaut. Vielleicht nicht schön, aber mir war es sicherer. 2) Finales Design ist nun hardseitig: - Tinkerforge, 12V Batterie, 12V-36V DC-DC-Konverter, Pufferung und galvanische Trennung kommen in einen Koffer. Zusätzlich habe ich in dem Koffer noch 14-Zündkänale vorgesehen. - Weitere 14-Zündkanäle sind in einem externen Gehäuse über einen Kombi-Sub-D angeschlossen (36V; GND über Hochstromkontakte, 5V + Steuerleitungen und Rückkopplung zur Widerstandsmessung und Spannungsmessungen über AWG24) - Weitere externe Gehäuse erweiterbar, wenn notwendig. 3) Platinen sind gerade in der Fertigung 4) DC-DC-Wandler ist auch bald da (Hongkong...) 5) WLAN Modul bei TF bestellt und einen Tag später vorhanden! TOP-Leistung!!! Sobald alles da ist, stelle ich ein paar Fotos ein. Wenn gewünscht, kann ich auch ein paar - unschönere - Zwischenergebnisfotos einstellen. Softwareseitig bin ich durch ein paar private Hindernisse etwas in Verzug, aber sobald die Hardware steht, kann ich dann ja wenigstens Live-Ergbnisse sehen. Soweit der Stand an der pyrotechnischen Front... Beste Grüße Jörg Firework.pdf MainIgnition.pdf

Ups, ok goldige Sache. Jedoch wurde in einigen Foren (mirkocontroller etc.) schon über die Widerstandsmessung von Erde bezüglich Feuchtigkeit diskutiert. Meines Erachtens ist die Methode der Widerstandsmessung nicht wirklich zuverlässig. Und wie sich Gold und Korrosion/Kalkablagerung auswirken, ist auch nicht gut geklärt. Daher mein Vorschlag mit der kapazitiven Messung. Alternativ diese Gardena Methode (55 Euronen für eine Messeinheit... da geht doch was selbst gestricktes günstiger...) Beste Grüße Jörg

Hallo, ich weiss, es gibt schon ein Moisture-Bricklet, aber ich denke, dass dieses nicht für Pflanzen geeignet ist. Pflanzen vertragen sich nicht wirklich gut mit Kupfer. Da ich aus aktuellem Anlass nach einer Lösung suche, um den Garten von meinen Schwiegereltern zu "automatisieren", habe ich ein wenig geforscht. Man könnte das ganze doch als kapazitiven Sensor aufbauen. Die Kupferflächen kann man dann mit entsprechenden Schrumpfschläuchen oder ähnlichen vom Medium trennen. Wie hier gezeigt: http://www.dietmar-weisser.de/elektronik-projekte/analogtechnik/sensoren/bodenfeuchtesensor Andere Messmethoden, wie beispielsweise von Gardena eingesetzt, erschließen sich mir (noch) nicht. Just my 2 cents...

Also ein XBee Pro (60mW in EU verboten, daher muss man es softwareseitig drosseln ) kostet um die 40 Euros. Die kleineren Varianten um die 24 Euros. Das ist meines Erachstens weit weg von den TF WLAN 60 Euronen. Daher prüfe ich zurzeit, für mein Projekt ein RaspPi zu kaufen und dem nen USB-WLAN zu spendieren. Adapter für XBee gibt es für den RaspPi ja (evtl. Ausbaustufe 2). Aber hier muss ich noch prüfen ob ich den Pi einfach als Router nutzen kann, oder das Hauptprogramm auf Pi läuft und ich nur über Meldungen mit PI kommuniziere. Schwere Entscheidung... Auch wenn sich der RED Brick interessant anhört, preislich wird er wohl erstmal an meinem Sieb hängenbleiben und kommt nicht zu mir durch (Frauen... ). Gruß Jörg

Hallo, könntet Ihr ein paar mehr Informationen zu dem 2 Pol Stecker GR/SW geben. Belastbarkeit Spannung/Strom wären für mich von interesse. Danke und beste Grüße Jörg

Hallo, so nun auch mit den Widerständen nochmals nachvollzogen. Es fließt lediglich der Leckstrom des MOSFETs. Macht es Sinn, wenn ich den IO16-Ausgang, der mit 1KOhm am Optokoppler liegt, noch mit 10K gegen GND lege, also sodass der 10K parallel zur Diode des Optokopplers geschaltet ist. Damit hätte ich bei einem Hochohmigen IO16-Pin einen definierten L-Level. Grund der Überlegung: Ich weiss nicht wie sich das IO16 beim Startup verhält. Sind die Pins standardmäßig auf Input und hochohmig gelegt, oder merkt er sich den letzten Zustand? Ich hatte mal kurz den Fall, dass am A0 0,2V trotz Einstellung Output-L anlag. Nach erneutem Setzen von L waren es dann 0V. Ich weiss 0,2V ist noch im Rahmen, aber Vorsicht ist bei meinem Projekt die Mutter der Porzellankiste. Gruß Jörg

Hallo, a) ich habe nie verlangt eine neue 'API' zu bekommen b) da mir die bindings aus software-architektur sicht nicht ausreichen, habe ich beschlossen, mir eine neue zu schreiben. c) Anscheinend ging es aber nicht nur mir so, daher dieser ausufernde Thread. d) ich weiss das Software wie babies sind. Kritisiert man meinen Sohn kritisiert man meist auch mich persönlich. Das ist menschlich, nur bedarf es einige jahre (war bei mir so) dies beruflich gesehen loszuwerden. Daher nehmt auch gerade aus getätigte aussagen nicht persönlich. e) ich finde die wertigkeit der tf hardware hat auch eine professionelle sw verdient. Daher wäre meines Erachtens eine gute Unterstützung von einer handvoll sprachen besser als alle möglichen eher schlecht zu unterstützen. Klar kann man mit den Bindings alles machen. Hier unterscheide ich aber zwischen Hobby bereich und professionellen bereich. Da TF auch kommerziell arbeitet (finde ich ha auch gut) sollten die bindings auch prof. sein. Again just my 2 cent. Jeder hat seine Meinung und ich finde wir sollten aufhören darüber endlos zu diskutieren. Vielleicht finden sich hier ein paar gleichgesinnte und wir stellen gemeinsam was auf die Beine. Das ganze muss dovh nicht morgen umgesetzt werden. Das sollte hier nzr als Anregung dienen und nicht als API sofort ersetzen thread...

Ok, nochmal eine Meinungsäußerung: Wie borg schon sagte: Weniger ist oftmals mehr. Das schließt sein Kommentar bezüglich 'Quellcode' aufzwingen ein, aber auch dass man nicht jede Sprache unterstützen sollte. Lieber eine paar weniger dafür die anderen richtig. Viele der Vorschläge - die nicht nur für C# gut sind - sind meines Erachtens zwingend notwendig, um in den Sprachen ordentlich schreiben zu können. Ich habe mal versucht mir dir Erstellung der C# Bindings anzuschauen. Wenn ich die py's richtig verstehe (hatte bisher keinen kontakt zu schlangen) wird die C# aus anderen py über eine art reflection erstellt. Wenn ja, weerden andere sprachen die eigenarten von python auferzwungen. Ich bin mittlerweile dazu übergegangen, ein adapter pattern zu nutzen. Mal schauen ob das sinn macht. Ach ja, gerne werde ich meine Ideen veröffentlichen. Ich bin auch gerne bereit, dies offen zu diskutieren und gemeinsam etwas sinnvolles auf die Beine zu stellen. beste Grüße Jörg

Ja das ist wohl korrekt. Es fließt nur der Leckstrom von 25uA. Somit hat der MOSFET 440K Widerstand im "gesperrten" Zustand. Vorwiderstand ist 1K also gegenüber FET zu vernachlässigen. Bzw. 1K Widerstand und 0,05V = 50uA. Wenn ich die Spannungsabfälle nochmals genauer aufnehme, dann komme ich bestimmt auf die 25uA! Ich werde die LED mal entfernen und nur mit Widerständen arbeiten zur Untermauerung und Auffrischung elektronik Berührung von vor 15 Jahren... Vielen Dank für die Aufklärung! Beste Grüße Jörg P.S: POC bestanden, jetzt kann ich ans Layouten gehen.

Hi, nun das Relais ist viel zu schwach! ich muss mindestens 2A für eine Reihenschaltung von Zündern aufbringen, bei paralellschaltung kommen da schnell mal 8A und mehr zustande. Da wird es mit Relais auch schon teurer. Mit dem o.g. Mosfet komme ich auf unter 1€ pro kanal und bin quasi in der Neuzeit angekommen (mehr als scherz gedacht). Gruß Jörg

Hab leider im Moment kein MM zur Hand. ULED hab ich berechnet: ULEDgerechnet = SpannungAmLEDgem. - SpannungAmMOSFETgem. ULED = 12,75V - 11V (dritte Stelle hinter dem Komma hab ich weggelassen). Das Problem bei mir ist, dass ich über den MOSFET Brückenzünder ansteuern möchte, um mir die Relais zu sparen (wg. Baugröße und Kosten). Die Brückenzünder sollen bei Stromfluss entsprechend Heiß werden und damit eine Ladung entzünden. Dauerhafter Stromfluss in mA-Bereich ist da nicht toll. Für eine kurze Zeit zur Durchgangsprüfung ok, aber mehr auch nicht. Vielleicht überdenke ich das nochmal und prüfe einen P-MOSFET. Habe eigentlich ungern die Speisung an den Zündern, aber P-MOSFETs in der Größenordnung sind wieder teurer als Relais. Ich werde wohl nicht drum herum kommen, ein paar Zünder für das POC zu opfern. BTW: Gibt es keine Möglichkeit beispielsweise bei VoltageCurrent Bricklet, die Massverbindung zu kappen oder überhaupt wegzulassen, wodurch ein Messen innerhalb einer Schaltung möglich wäre? Beste Grüße Jörg

Hallo, ich hab mal ein POC erstellt und wie im Anhang geschildert aufgebaut. Das LED schaltet ein und aus, so wie es sollte. Aber da ich später mit dem MOSFET kleine Lasten (max.10 Ohm) schalten werde, und ich absolut sicher gehen muss, dass die Leitung bei L-Level "getrennt" ist, habe ich ein paar Bauchschmerzen mit meinen Messwerten. Die Spannungen habe ich mit dem Analog-In gemessen: H-Level: Ugs = 12,8V Uds = 0V L-Level: Ugs = 0V Uds = 11,0V Uled = 1,75V Da ich keine Schaltzeiten < 100ns brauche, ist der große Gate-Widerstand eigentlich kein Problem. Mach ich mir umsonst Sorgen, oder hab ich in der Schaltung etwas übersehen? P.S.: Selbstverständlich sind alle Massen miteinander verbunden. Die 12V Batterie liegt auf meinem Steckbrett und am Step-Down-Bricklet. Einzig das GND vom IO16 habe ich nicht auf das Steckbrett geführt.

Hallo, nachdem ich ein wenig gesucht habe bezüglich Funkanbindung (wieder dieses leidige Thema, was? Aber unsere Welt ist nunmal nicht mehr Drahtgebunden), bin ich auf den Chibi-Thread gestoßen. Hier ging es um SPI kommunikation mit WLAN etc. Also ich weiss nichts über die Schmerzen mit Chibi (noch was das genau für ein Protokoll ist), aber Zigbee scheint eine nette Alternative neben WLAN zu sein. Wenns um SPI geht: http://www.digi.com/support/kbase/kbaseresultdetl?id=3362 Immerhin versprechen die 100-1500m Reichweite ne nach Modul. Also könnte man ja ein Brick erstellen, welches immer das oberste sein muss und eine Xbee-Schnittstelle beinhaltet. Das Funkmodul könnte man dann selber auswählen und auf den Brick stecken (daher immer als Oberstes ). Bspw: http://www.watterott.com/de/Schnittstellen/Funk/Xbee-ZigBee So, nun harre ich der Dinge und schreibe meine API weiter... Beste Grüße Jörg

Und ja, das ganze muss ich noch dokumentieren. Aber die Nachfrage nach dem Stein meines Anstoßes drohte auszuarten, daher erste schnelle Entwürfe. Detaillierteres später, sobald ich mehr Zeit habe. Version.cs HardwareVersion.cs FirmwareVersion.cs

Hallo, da ich in meinem Projekt die API kritisiert habe, kommt hier ein erster Vorschlag, der noch ausgebaut werden muss. (Konnte nur 10 Minuten dafür aufwenden). Beste Grüße Jörg IPConnection.cs DeviceIdentifier.cs BrickDC.cs

Wie schon einige vorher geschrieben haben, fängt das Fehlen von OO schon bei IPConnection an. Zum Thema BrickViewer: Ja hier kann ich die UIDs herausfinden. Aber wenn ich eine Software schreibe, dann sollte die auch für andere gelten. Wenn nun jemand seinen eigenen Stack aufbaut und meine Software einsetzt, wird derjenige nur notwendige Konfiguration machen müssen. Bezüglich konstruktiver Kritik werde ich selbstverständlich meinen Ansatz einer API darstellen. Wohl aber in einem anderen Thread, da hier mehr auf mein Projekt eingegangen wird und welche Schmerzen/Erfolge ich erziele. Auch habe ich erst angefangen, einen Einblick in die "API" zu bekommen. Aber wenn ich beispielsweise IpConnection.Enumerate aufrufe und im Callback short-Arrays sowie ints für DeviceIdentifier finde und die nicht dokumentiert (woher bekomme ich die Info beim programmieren, welche ID ein BrickMaster hat?) sind, dann kribbelt es mir in den Fingern, direkt die API in Frage zu stellen. Hierfür gibt es Kommentare im Quellcode! Wenn einer meiner Entwickler zu mir kommt und Quellcode abliefert, der nicht kommentiert ist, kann er zurück gehen und dies nachholen... Wie gesagt, jetzt nicht aus der Hose springen, konstruktiv wird das noch und zumindest IPConnection ist kaum dokumentiert. Beispielsweise könnte folgender Ansatz in Betracht gezogen werden, um mal meine ersten Gedanken aufzuzeigen. Das Ganze muss detailiert und umgebaut werden, sobald ich mehr Einblick habe! 1. Grundsatz der OO: Programming against an interface not an implementation: IStack - Connect(IConnection con) : boolean // falls es mal eine andere Connection Art gibt - GetMaster : IBrickMaster - Bricks : IList<IDevice> // könnte auch IBrick sein - Bricklets(IDevice device) : IList<IDevice> // könnte auch IBrick / IBricklet sein - Disconnect : boolean IConnection IIpConnection : IConnection IDevice IBrickMaster IBrickletAnalogIn abstract Version HardwareVersion : Version FirmwareVersion : Version Enum DeviceIdentifier usw. Kein Handling von Bitmasken, ints oder shorts. In Objekten denken. Quasi mal schauen wir TF aufgebaut wird. Mal bildet einen TF-Stack. Jeder Stack muss einen MasterBrick haben. Es können bis zu ? Bricks ein einem Stack sein. Ein Brick kann Bricklets verwalten. Etc. In den vier Sätzen stecken eine Menge Objekte. Morgen erhalte ich meine später eingesetzte Stromversorgung (12V 7ah Batterie nebst Ladestation, letztere brauche ich für mein Auto daher trifft sich das ganz gut). Mit der Batterie werde ich dann mal erste Tests mit den Current und Analog Bricklets machen. Jetzt habe ich nebenher die IPConnection umgebaut. Ich erstelle mal einen anderen Thread.