https://hobbyelektronik.org/w/api.php?action=feedcontributions&user=Chris&feedformat=atomHobbyelektronik.org - Benutzerbeiträge [de]2024-03-29T01:04:09ZBenutzerbeiträgeMediaWiki 1.34.1https://hobbyelektronik.org/w/index.php?title=Hauptseite&diff=1890Hauptseite2024-01-17T22:08:19Z<p>Chris: /* Neues & Änderungen */</p>
<hr />
<div>'''Willkommen auf hobbyelektronik.org!'''<br />
<br />
Auf diesen Seiten findest du [[Hobbyelektronik.org:Impressum|unsere]] Projekte rund um Elektronik und allem möglichen, was uns interessiert.<br />
<br />
Neben dem Wiki hier gibt es auch ein '''[//hobbyelektronik.org/b/ Blog]''', das sich nicht nur mit Elektronik und der Homepage beschäftigt. Dort kann - im Gegensatz zum Wiki hier - auch fleißig kommentiert werden, was an dieser Stelle aufgrund von massivem Spam deaktiviert werden musste.<br />
<br />
Aber nun wünsche ich viel Spaß beim stöbern auf den Seiten hier!<br />
<br />
Bitte benutze die Navigation links, um zu den [[Spezial:Alle Seiten|Artikeln]] zu kommen.<br />
=[//hobbyelektronik.org/b/ Blog]=<br />
<WPPlatest /><br />
<br />
=Neues & Änderungen=<br />
<div id="mw-latest-changes10"><br />
*17.01.2024 Egal ob heiß oder kalt, jetzt auch über Modbus: [[DS18B20-Modbus-Adapter]]<br />
*11.04.2023 Pünktlich zu Ostern wird ein paar [[Freifunk-Rebooter|Freifunk-Routern]] in die... - ach, lassen wir das.<br />
*24.11.2022 Beim VBus-ESP8266-Adapter kann es [[VBus-Decoder/Adapter_für_den_ESP8266#Fehlerhafter_Datenempfang|Fehler beim Datenempfang]] geben<br />
*22.11.2022 Kleine Korrektur beim [[VBus-Decoder/Adapter_für_RS-232|VBus-Adapter für RS-232]]<br />
*11.11.2022 Weitere Informationen zu den [[Prozeda-Decoder#Display|Displaydaten]] beim [[Prozeda-Decoder]]<br />
*10.11.2022 Ein CitrinSolar CS 1.3 wurde [[Resol_-_Zerlegt#CitrinSolar_CS_1.3|zerlegt]] und [[Resol - Reparaturen|repariert]]<br />
*02.11.2022 Ein [[Resol 71005014 Schnittstellenadapter]] wurde repariert und verbessert<br />
*02.11.2022 Warum zur Abwechslung nicht einmal paar [[Resol - Zerlegt|Resol Geräte zerlegen]]<br />
*23.12.2021 Es wird heimelig zu Weihnachten: ein [[LED-Lagerfeuer]]<br />
*13.12.2021 Mal wieder ein VBus-Decoder - jetzt für den [[VBus-Decoder/Adapter_für_den_ESP8266|ESP8266]]<br />
*07.09.2021 Eine aktualisierte Untersuchung des [[ECL-Bus-Protokoll]]s<br />
*12.07.2021 Der Pythoncode der [[MCP-USB-Bridge]] ist auf GitHub umgezogen und spricht nun mit dem MCP2210 (SPI)<br />
*26.02.2021 Und noch ein Update für den VBus-Decoder: [[VBus-Decoder/Adapter_für_den_Raspberry_Pi#Die Enttäuschung - Teil 2| Version 1.2b]] und [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Version 1.3]], sowie einem einfachen [[VBus-Decoder#Protokoll-Analysator|Protokoll-Analysator]]<br />
*09.02.2021 Die Artikel [[VBus-Decoder]] und [[Prozeda-Decoder]] sind nun in Unterseiten aufgeteilt<br />
*10.05.2020 Mit irgendwelchen Tasten OBS steuern: [[Anykey x6]]<br />
*08.04.2020 Etwas für den Drucker: [[3D-Druck-Sammelsurium#Mikrofonarm_f.C3.BCr_den_Zoom_H2n|Mikrofonarm für den Zoom H2n]]<br />
*04.04.2020 [[Reparatur_R%26S_CMU200_Hintergrundbeleuchtung|Ein neues Backlight für eine CMU200]]<br />
*31.03.2020 Es geht auch günstiger: [[VBus-Decoder/Adapter_für_den_Raspberry_Pi#Kostenreduzierte_Variante.2Fv1.2|Costdown für den VBus-Decoder am Raspberry Pi]]<br />
*10.03.2020 Wer braucht es nicht: einen [[USB-Fußtaster]]<br />
*15.02.2020 Ein bisschen Modellpflege: [[MCP-USB-Bridge#USB-I.C2.B2C-Bridge_v1.1|MCP USB-I²C-Bridge v1.1]], ein [[VBus-Decoder/Adapter_Nano|VBus-Adapter für den Raspberry Pi]] und die VBus-Boards Nano-Boards sind wieder da :)<br />
*19.01.2020 [[Pirozeda]] Version 0.4 hat wohl Stabilitätsprobleme<br />
*19.01.2020 Update für die [[MCP-USB-Bridge|MCP2221-Python-Lib]] und Anmerkungen zu Datenblattfehlern<br />
*13.01.2020 Backplates für den [[3D-Druck-Sammelsurium#Diamex_AVR-Prog_Bodenplatte|Diamex AVR-Prog]] und die [[3D-Druck-Sammelsurium#USB-I.C2.B2C-Bridge_Bodenplatte|MCP USB-I²C-Bridge]] im [[3D-Druck-Sammelsurium]]<br />
*25.12.2019 [[3D-Druck-Sammelsurium]]<br />
*16.12.2019 Ein paar [[Softwaretools|Tools]] um die [[Softwaretools#SerialPlayer|serielle Schnittstelle zu bespaßen]] und [[Softwaretools#SaleaeTools|Daten aus Saleae Logic komfortabler verarbeiten zu können]]<br />
*10.11.2019 Für den VBus-Adapter Nano gibt es nun einen [[VBus-Decoder/Adapter_Nano#Troubleshooting|Troubleshooting-Guide]] und eine [[VBus-Decoder#Python-Implementierung|Python-Implementierung]]<br />
*17.09.2019 Für den MCP2221 und MCP2210 (USB I²C- & SPI-Interface) gibt es nun eine [[MCP-USB-Bridge#C.23-Lib|C#-Lib]]<br />
*07.05.2019 Ein Adapter für den Adapter: Der [[Atmel-ICE-Adapter]]<br />
*21.03.2019 Doku des [[Pirozeda-HAT]] korrigiert & aktualisiert<br />
*16.03.2019 Ein paar Infos und ein mechanischer Adapter für [[Ikea Trådfri]] (teilweise aus dem Blog übernommen)<br />
*11.02.2019 Der [[VBus-Decoder/Adapter_Nano|VBus-Adapter Nano]] ist nun aufgebaut und getestet<br />
*10.02.2019 Der [[EAGLE-BOM]]-Export kann nun auch JSON<br />
*03.01.2019 Auch für den VBus gibt es neue Hardware: [[VBus-Decoder/Adapter_Nano|VBus-Adapter Nano]]<br />
*03.01.2019 Langsam wird ein Hut draus: Der [[Pirozeda#Pirozeda-HAT|Pirozeda-HAT]] ist zwar noch nicht da, aber bald.<br />
*27.10.2018 [[MCP-USB-Bridge#Python-Lib|MCP-USB-Bridge]] es gibt nun eine Python-Lib, die die meisten Features des MCP2221 unterstützt<br />
*23.08.2018 [[MCP-USB-Bridge]] - billiges und einfaches I²C- & SPI-Interface für den PC<br />
*19.08.2018 EAGLE kann nun direkt [[EAGLE-BOM_für_MediaWiki|BOMs als MediaWiki-Tabelle]] exportieren<br />
*05.08.2018 [[Pirozeda]] Version 0.31. ...und nochmal ein Bugfix. Die Aktualisierung für die aktuellen Daten/Display und Statistik wurden nicht richtig aktualisiert<br />
*05.08.2018 [[Pirozeda]] Version 0.3. Ein paar Bugfixes und ein 3D-Diagramm für historische Daten<br />
*16.04.2018 Im Artikel des [[Prozeda-Decoder]] gibt es nun [[Prozeda-Decoder#Einblick_in_den_Regler|Einblick in den Regler]]<br />
*15.04.2018 Der [[Prozeda-Decoder]] ist nun mit einem Raspberry Pi verheiratet: [[Pirozeda]]<br />
*12.11.2017 [[Mini-LED-Treiber]]<br />
*17.04.2017 Update von MediaWiki, mehr im [//hobbyelektronik.org/b/?p=1556 Blog]<br />
*22.02.2017 Solaranlagen von Wagner-Solar bzw. [[Prozeda-Decoder|Prozeda]] können nun ausgelesen werden<br />
*31.12.2016 Dank [[Briefkasteninnenbeleuchtung]] ist mein Briefkasten innen beleuchtet<br />
*11.03.2016 Kleines Update für den [[VBus-Decoder]]: Es gibt nun [[VBus-Decoder/Adapter_für_RS-232|Hardware für den PC]]<br />
*19.04.2015 Ein Nachtrag bei der [[Kühlung_für_Zhongdi_ZD-939L#Nachtrag_19.04.2015|Kühlung für Zhongdi ZD-939L]]<br />
*10.04.2015 [[ASCII-Tabelle]]: Dez- & Hex-Angaben deutlicher, neue Druckformate.<br />
*10.05.2014 Neu: [[Kühlung für Zhongdi ZD-393L]]<br />
*02.02.2014 Neu: [[EAGLE-Bibliotheken]]<br />
*10.11.2013 Neu: [[Zeitraffer mit Linux]]<br />
*20.10.2013 [[EMR7370]] korrigiert. In main() war ein falscher Funktionsaufruf.<br />
*14.08.2013 Neu: [[Umbau Belkin Auto-USB-Lader]]<br />
*02.05.2013 Neu: [[Farnell-Assistent]]<br />
*16.01.2013 Neu: [[Halbleiterelektronik-Formelsammlung]]<br />
*11.10.2012 Neu: [[EAGLE-Toolbar]]<br />
*26.09.2012 Neu: [[Sony Dimmer]]<br />
*05.05.2012 Neu: [[Raspberry Pi IO]]<br />
*28.04.2012 [[EMR7370]] ergänzt. Der Quellcode ist nun verfügbar.<br />
*14.03.2012 Ein paar Bilder zum [[Kameratimer]] und dem [[SNES-Joypad]] hinzugefügt<br />
*12.03.2012 Neu: [[EMR7370]]<br />
*29.12.2011 Neu: [[Polizeiauto]]<br />
*03.10.2011 Neu: [[Audioslave]]<br />
*13.09.2011 Neu: [[Modellbau-Leuchtstofflampe]]<br />
*12.09.2011 Neu: [[Gartenbrunnen]]<br />
*12.06.2011 Neu: [[Maschinenleuchte]]<br />
*04.05.2011 Neu: [[ECL-Bus-Decoder]]<br />
*19.03.2011 [[What's next?]]: Zimmerbus<br />
*19.03.2011 Neu: [[Physik-Formelsammlung]]<br />
*15.01.2011 Neu: [[Belichtungsgeraet]]<br />
*09.12.2010 Neu: [[Energieerfassung/Solarleistung]]<br />
*21.11.2010 [[What's next?]]: Ein paar Infos zum Moodlight<br />
*21.11.2010 [[AVR-Doper]]: "Patch" für AVR-Studio<br />
*21.11.2010 [[Energieerfassung]]: Abschnitt [[Energieerfassung#Nerviges/Todo|Todo/Nerviges]] hinzugefügt<br />
*15.11.2010 [[Energieerfassung#Downloads|Energieerfassung ? Downloads]]: Die Firmware steht jetzt zum Download bereit<br />
*10.10.2010 [[Energieerfassung#Solaranlage|Energieerfassung ? Solaranlage]]: Die PT1000 haben nun doch ihren Zweck erfüllt<br />
*10.10.2010 Neu: [[Kameratimer]]<br />
*10.10.2010 [[Energieerfassung#Solaranlage|Energieerfassung ? Solaranlage]]: Die PT1000 haben nun doch ihren Zweck erfüll<br />
*31.08.2010 Neu: [[Energieerfassung]]<br />
*09.08.2010 Neu: [[AVR-NET-IO-Shield]]<br />
*15.07.2010 Neu: [[Nokia 5110 Displayadapter]]<br />
*09.07.2010 Neu: [[Sommerhitz]]<br />
*16.06.2010 Seiten in [[:Kategorie:AVR|Kategorie AVR]]: AVR Infobox hinzugefügt<br />
*13.06.2010 [[Touchlight]] (Abschnitt [[Touchlight#Praxis|Praxis]] hinzugefügt)<br />
*19.03.2010 [[What's next?]]: Zimmerbus<br />
*04.03.2010 Neu: [[VBus-Decoder]]<br />
*04.03.2010 [[SNES-Joypad]] (Autocal-Version & ATtiny2313-Version)<br />
*24.02.2010 Neu: [[UnitColor]]<br />
*12.02.2010 Neu: [[Panasonic-Zapper]]<br />
*09.01.2010 Neu: [[ASCII-Tabelle]]<br />
*27.12.2009 Neu: [[USBLotIO]]<br />
*04.07.2009 Neu: [[Touchlight]]<br />
*19.01.2009 Neu: [[Datenlogger]]<br />
*01.09.2008 Neu: [[Labornetzteil]]<br />
*09.08.2008 Neu: [[Cursor]]<br />
*08.08.2008 Neu: [[Image Resizer]]<br />
*14.03.2008 Neu: [[Platinenbohrmaschine]]<br />
<html><a id="showall" href="#Neues_.26_.C3.84nderungen" onclick="document.getElementById('mw-latest-changes10').className='all';">Alle Änderungen anzeigen</a></html><br />
</div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=DS18B20-Modbus-Adapter&diff=1889DS18B20-Modbus-Adapter2024-01-17T22:00:30Z<p>Chris: /* Layout */ Gallery korrigiert</p>
<hr />
<div>[[Bild:DS18B20Modbus_v0.1_aufgebaut.jpg|thumb|Aufgebauter Leiterkarte (v0.1)]]<br />
Der Plan, der Heizung etwas genauer auf die Finger zu schauen, sie zu verstehen, Fehler möglichst früh zu erkennen und das System schlussendlich zu optimieren, nimmt (in kleinen Schritten) Form an.<br />
<br />
So werden die Messwerte der Solaranlage (inkl. ein paar Temperaturwerte der Heizung) und die Stromaufnahme der Wärmepumpe mittlerweile in eine InfluxDB geloggt, aber das soll nicht alles bleiben.<br />
<br />
Um besseren Einblick zu bekommen was rein und raus geht, sollen u. a. die Temperaturen für Vor- und Rückläufe, Mischerstellungen und Drücke erfasst werden. Ideal wäre natürlich auch, die Durchflussmenge zu messen (hier fehlt es aber noch an Zählern - dazu muss der Heizungsbauer ran...).<br />
<br />
Wenn man sich mit Automatisierung und deren Kommunikation beschäftigt, kommt man fast nicht um Modbus. Das Protokoll ist relativ einfach, robust und hat sich in der Industrie etabliert.<br />
<br />
Da dieser in Form von Stromzählern bereits Einzug ins Haus gefunden gefunden hat und dadurch eine Verkabelung vorhanden ist, ist es ein logischer Schritt, auf diesen Bus aufzubauen.<br />
<br />
Zwar kann man fertige Messwandler für Modbus kaufen, die können dann oft nur "Eines" und sind, gerade wenn sie aus dem Industrie-Umfeld sind, entsprechend teuer. Warum also nicht selber bauen?<br />
<br />
=Plan & Features=<br />
<br />
Der ATtiny1616 hat ein gutes Preis-/Leistungsverhältnis, verfügt über eine angenehme Anzahl an I/Os, ist einfach zu programmieren (man brauch nicht mehr als einen [https://github.com/mraardvark/pyupdi USB-UART-Adapter]) und die Verfügbarkeit ist gut.<br />
<br />
Als Temperaturfühler sollen, weil ebenfalls preiswert und einfach in der Verkabelung, Sensoren mit [[wpde:1-Wire|1-Wire]] zum Einsatz kommen. Genauer gesagt DS18B20 bzw. deren vielfältige [https://github.com/cpetrich/counterfeit_DS18B20/ Fakes/Clones/Nachahmer].<br />
<br />
Um die Stellung von Mischern oder analogen Manometern zu erfassen, soll ein magnetischer Encoder (genauer ein AMS AS5600) eingesetzt werden. Mit einem auf die Achse geklebten diametralen Magnet lässt sich so ohne nennenswerte Eingriffe die Position mit hoher Auflösung erfassen.<br />
<br />
Mehr ist natürlich immer besser:<br />
<br />
Da der Mikrocontroller über mehrere ADC-Kanäle verfügt, sollen diese ebenfalls zur Verfügung stehen können.<br />
<br />
Um Zählausgänge (zum Beispiel von Wasseruhren) zu erfassen, soll ebenfalls ein Pulszähler zu den Funktionen gehören.<br />
<br />
=Hardware=<br />
<br />
==Schaltplan==<br />
<br />
Der Schaltplan ist relativ straight forward:<br />
<br />
Da die externe Stromversorgung irgendwas sein kann, regelt ein 78(L)05. Für ein bisschen Flexibilität sind gleich 3 Footprints auf der Leiterkarte: im SOT89-Gehäuse (weil schön klein und gute thermische Anbindung), SO8-Gehäuse (weil davon sicher einer herumliegt) und im TO220-Gehäuse. Letzteren nicht, weil man ihn bräuchte, aber man kann bei Bedarf auch so etwas wie einen [[Mini-Schaltwandler]] einbauen.<br />
<br />
Für Modbus hängt ein MAX485 am UART des Mikrocontrollers, für DIR wird die XDIR-Funktionalität des Mikrocontroller ignoriert, weil die dafür verfügbaren Pins etwas blöd liegen (mehr dazu später).<br />
<br />
I²C ist ebenfalls einfach: zwei Pull-ups und fertig. <br />
<br />
Etwas aufgehoben, aber ehrlicherweise als erstes festgelegt: 1-Wire. Der Einfachheit halber soll jeder Sensor seinen eigenen Pin bekommen (auch wenn man mehrere Devices über einen Bus ansprechen kann). Da das Auslesen die CPU etwas länger blockieren kann und um die Werte synchron zu erhalten sollen alle Sensoren gleichzeitig angesprochen werden, dazu sollen möglichst viele Pins von einem Port genutzt werden - der ATtiny1616 hat 3 Ports mit unterschiedlich vielen IOs, wobei es eine relativ starke (wenn auch etwas flexible) Doppelbelegung besteht. PORTA ist mit 8 IOs am "breitesten", wobei PA0 als UPDI-Pin verwendet wird. Ohne HV UPDI, einem guten Bootloader oder dem Vertrauen, dass die Firmware fertig ist.<br />
<br />
Wie auch immer: 7 Kanäle sind noch immer besser als 6 (an PORTB). <br />
<br />
Um bei der Verwendung der Sensorkanäle flexibel zu sein, beinhaltet das Design Bestückungsoptionen für Serienwiderstände (per default überbrückt), Pull-Ups und Kondensatoren um Tiefpassfilter einzubauen. Zudem gibt es an allen nach außen geführten Leitungen ESD-Schutz. Darf auch mal sein.<br />
<br />
Als Anschlussklemmen gibt es zur Abwechslung mal keine Schraubklemmen, sondern Federkraftklemmen. Um nicht für jeden der Sensoren jeweils zwei Klemmen für die Versorgung zu spendieren (bei 7 Temperaturfühlern wären das immerhin 21 KIemmen), teilen sich zwei Sensoren ein Pärchen für die Versorgung, was die Klemmenanzahl auf 16. Mit zwei 12er-Klemmblöcken lässt sich so die Versorgung, RS485-Interface, 8 Sensoreingänge und ein I²C-Interface unterbringen.<br />
<br />
Zur Statusanzeige dienen zwei LEDs, die sich die IOs mit dem auf eine Stiftleiste herausgeführten SPI-Interface teilen.<br />
<br />
Die Stiftleiste stellt zugleich das Programmierinterface und den GPIO (der auch als Analogeingang genutzt werden kann) zur Verfügung.<br />
<br />
Der Plan, die Modbus-Adresse über ein Mäuseklavier zu konfigurieren scheiterte in der ersten Hardware-Revision. Ein analoges Signal auf einen der wenigen Pins zu führen, der nicht über einen ADC-Kanal verfügt ist immerhin auch eine Leistung ;)<br />
<br />
Viel Text, jetzt Butter bei die Fische - der Schaltplan:<br />
<br />
<gallery><br />
DS18B20Modbus_v0.1_sch.png | Schaltplan v0.1<br />
</gallery><br />
<br />
==Layout==<br />
Wie immer folgt das Layout dem Prinzip "So groß wie nötig, so klein wie möglich". Die Breite der Leiterkarte wird von den Federkraftklemmen vorgegeben, die Länge ergibt sich durch das Design.<br />
<br />
Um keinen einseitigen Wust an Leitungen zu haben, sind die Klemmen gegenüberliegend platziert, in der Mitte sitzt die ganze Logik.<br />
<br />
ESD-Schutz und (optionale Filter RC-Filter) liegen so nah wie möglich an den Klemmen.<br />
<br />
Da für die - wie sich im Nachhinein herausstellte - etwas zu knapp platzierten Schraublöchern ungenutzter Platz entstand, gibt es Beschriftungen für die Klemmblöcke.<br />
<br />
<gallery><br />
DS18B20Modbus_v0.1_pcb_top.png | Oberseite (Vollbestückung)<br />
DS18B20Modbus_v0.1_pcb_bot.png | Unterseite (Vollbestückung)<br />
DS18B20Modbus_v0.1_pcb_top_assy.png | Oberseite (tatsächliche Bestückung)<br />
DS18B20Modbus_v0.1_pcb_bot_assy.png | Oberseite (tatsächliche Bestückung)<br />
</gallery><br />
<br />
==BOM==<br />
{| class="wikitable"<br />
! Menge !! Referenz !! Wert !! Package !! Reichelt Bestellcode<br />
|-<br />
| 1 || SV2 || || MA04-1R || MPE 087-1-004 <br />
|-<br />
| 1 || SV1 || || MA08-1R || MPE 087-1-008 <br />
|-<br />
| 4 || C2, C3, C5, C14 || 0u1 || C0603 || KEM Y5V0603 100N<br />
|-<br />
| 1 || C1 || 0u1 || C0805 || KEM X7R0805 100N<br />
|-<br />
| 1 || C4 || 10u || C0805 || KEM X5R0805 10U <br />
|-<br />
| 1 || R24 || 120 || R0603 || RND 155HP03 AL <br />
|-<br />
| 1 || R14 || 1k5 || R0603 || SMD-0603 1,5K <br />
|-<br />
| 1 || R13 || 2k2 || R0603 || SMD-0603 2,2K <br />
|-<br />
| 2 || R10, R11 || 47k || R0603 || SMD-0603 47K <br />
|-<br />
| 1 || C9 || 47u/25V || E2,5-5 || HD-A 47U 25 <br />
|-<br />
| 9 || R1, R2, R3, R4, R5, R6, R7, R8, R18 || 4k7 || R0603 || SMD-0603 4,7K <br />
|-<br />
| 1 || R9 || 4k7 || R0603 || SMD-0603 47K <br />
|-<br />
| 1 || IC5 || 78L05F || SOT89 || TS 78L05 ACY <br />
|-<br />
| 1 || IC1 || ATTINY1616 || SO20_T1616 || ATTINY1616-SN <br />
|-<br />
| 1 || D9 || BAT43WS || SOD323-W || BAT 43WS <br />
|-<br />
| 2 || X1, X2 || DG250-3.5-12P-1Y-00A || DG250-3.5-12P-1Y-00A || DG250 3,5-12 <br />
|-<br />
| 1 || IC3 || MAX481CSA || SO08 || MAX 481 CSA <br />
|-<br />
| 1 || D7 || P4SMAJ18CA || DO214AC || P4SMAJ18CA <br />
|-<br />
| 6 || D1, D2, D3, D4, D5, D6 || PESD1CAN || SOT23 || PESD 1CAN <br />
|-<br />
| 1 || LED1 || gn || SML0805 || SMD-LED 0805 GN <br />
|-<br />
| 1 || LED2 || rt || SML0805 || SMD-LED 0805 RT <br />
|}<br />
<br />
==Aufbau==<br />
Beim Bestücken der Leiterkarte sollten die Federkraftklemmen zumindest auf der Oberseite wirklich als letzte Bauteile bestückt werden, sonst wird es es ein sehr unangenehmes Unterfangen.<br />
<br />
Die Fuses für den Mikrocontroller sind in der Firmware "eingebacken". Es kommt ein wenig auf den Programmer an, ob die Sektion im ELF-File unterstützt wird. Für alle anderen Fälle, hier die Fuses fürs manuelle Schreiben und Prüfen:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Register !! Wert <br />
|-<br />
| WDTCFG || 0x02 <br />
|-<br />
| BODCFG || 0x06 <br />
|-<br />
| OSCCFG || 0x01 <br />
|-<br />
| TCD0CFG || 0x00 <br />
|-<br />
| SYSCFG0 || 0xC5 <br />
|-<br />
| SYSCFG1 || 0x30 <br />
|-<br />
| APPEND || 0x00 <br />
|-<br />
| BOOTEND || 0x00 <br />
|}<br />
<br />
=Software=<br />
==1-Wire==<br />
Lange habe ich mich gescheut, etwas mit 1-Wire zu machen. Hauptsächlich weil die meisten Bibliotheken das Timing mit Sleeps erzeugen und somit höchst inkompatibel mit Interrupt-getriebenen Anwendungen sind. Um es selbst mit Interrupts zu programmieren war die Not nicht groß genug.<br />
<br />
Offenbar hatte Peter Dannegger ähnliches im Sinn und es [https://www.mikrocontroller.net/topic/493064 auf clevere Weise gelöst].<br />
<br />
Der Code spricht allerdings nur mit einem Sensor an einem IO. Man könnte nun den Code zur Verwendung unterschiedlicher Pins umbauen, oder mehrere Sensoren pro Pin verwenden kann. Ersteres hätte jedoch die Nebenwirkung, dass das Auslesen in die Länge gezogen wird und das die Werte nicht synchron sind (was in den meisten Fällen jedoch zu verschmerzen wäre). Letzteres ist deutlich aufwändiger, da ohne die Kenntnis der Seriennummer der Busteilnehmer auch eine [https://www.analog.com/en/app-notes/1wire-search-algorithm.html Suchfunktion] implementiert werden muss, auch ist die eindeutige Zuordnung Sensor zu Pin nicht ohne Weiteres möglich (und zu guter Letzt wird auch die Registerzuordnung in Richtung Modbus etwas komplexer).<br />
<br />
Ob man nun auf einen Pin oder einen ganzen Port zugreift macht bei den meisten Mikrocontrollern keinen großen Unterschied, weshalb ich den Code dementsprechend umgebaut hab. Im Zuge dessen ist nun auch der IO-Zugriff etwas stärker von der Statemachine getrennt, was die Portierung auf andere Plattformen erleichtern dürfte. Auch die Methoden für die Kommunikation mit den DS18B20 wurde etwas stärker vom 1-Wire-Interface getrennt und eine kleine Statemachine gebaut, um den Lesezyklus zu vereinfachen - so muss man die Messung nur noch starten, periodisch eine Tick-Funktion aufrufen, die einem auch gleich sagt, ob Ergebnisse vorliegen. Die Temperatur der einzelnen Kanäle kann als signed fixed point gelesen werden.<br />
<br />
Da manche der DS18B20-Clones wohl die Eigenschaft haben, sich nach einer gewissen Anzahl an Lesezyklen selbst zu zerstören (kann die Quelle leider nicht mehr finden), geschieht das Auslesen nur auf Anfrage. Mehr dazu weiter unten.<br />
<br />
==I²C==<br />
Zum Auslesen des magnetischen Encoders wird I²C verwendet.<br />
<br />
Das Programm initialisiert den Chip sobald er erkannt wird und versetzt ihn in den Stromspar-Modus LPM1. Der Slow Filter wird (unnötigerweise) auf 16x konfiguriert, Der Fast Filter bleibt wie der Watchdog aus.<br />
<br />
Die Einstellungen lassen sich in config.h ändern.<br />
<br />
Neben dem Winkel lassen sich über Modbus auch die Statusregister auslesen. Mehr dazu unten.<br />
<br />
==Analogeingang==<br />
Ein Pin am AVR ist noch frei, eine Klemme am Klemmblock konnte freigeräumt werden und ich möchte eine Status-Lampe überwachen. Durch den ADC lässt sich eine größere Außenbeschaltung vermeiden und die Flexibilität per Software ist groß.<br />
<br />
Auch hier lässt sich die Konfiguration für die Wandlung in config.h ändern. Standardmäßig wird die 5V-Versorgungsspannung als Referenz verwendet und über 8 Samples akkumuliert.<br />
<br />
==Pulszähler==<br />
Für den Pulszähler braucht es eigentlich nur eine einigermaßen gute Entprellung bzw. vielmehr eine Qualifizierung der Gültigkeit der Länge eines Pulses.<br />
<br />
Dazu wird die Anzahl der Ticks nach einem Pegelwechsel gezählt. Der Teiler für die Ticks und die Anzahl der Ticks - also die Qualifikationszeit kann (ein gemeinsamer Wert für alle Eingänge) in config.h definiert werden.<br />
<br />
Neben den Sensoreingängen werden auch Pulse auf AIN gezählt.<br />
<br />
Aktuell werden nur die negativen Pulse per Modbus zur Verfügung gestellt.<br />
<br />
==Modbus==<br />
Da das Rad nicht neu erfunden werden muss, kommt für das Modbus-Interface [https://github.com/mbs38/yaMBSiavr yaMBSiavr] zum Einsatz. Die Bibliothek wurde für den avrtiny-1-Core angepasst (und natürlich ein Pull-Request erstellt). Zusätzlich gab es eine kleine Erweiterung: nun ist die Möglichkeit eingehackt, den Server zu identifizieren (nach Abschnitt 6.21 der [https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf V1.1b3 Spec]).<br />
<br />
Dreh- und Angelpunkt für die Kommunikation sind die Input- und Holding-Register, die im folgenden Abschnitt beschrieben ist:<br />
<br />
=Benutzung=<br />
==Konfiguration==<br />
Die Konfiguration findet vorwiegend in config.h statt.<br />
===Pin-Verwendung===<br />
Im ersten Block kann die Verwendung der 7 Sensor-Pins definiert werden. Aktuell wird lediglich zwischen <code>USAGE_NONE</code> und <code>USAGE_DS18B20</code> unterschieden. Der Pulszähler ist permanent aktiv, ADC wird momentan nur für AIN unterstützt.<br />
<br />
===Modbus===<br />
Die RS485-Schnittstelle läuft mit 19200 Baud 8N1 - die Baudrate kann über den Define <code>MODBUS_BAUDRATE</code> angepasst werden.<br />
<br />
Die Modbus-Adresse muss aktuell zur Kompilierzeit über <code>MODBUS_ADDRESS</code> festgelegt werden. Mit der nächsten Hardware-Revision wird mit an Sicherheit grenzender Wahrscheinlichkeit das Setzen per Dip-Schalter verfügbar sein.<br />
<br />
<code>MODBUS_ACT_DURATION</code> legt in 100 µs-Schritten fest, wie lange die Power-LED bei Busaktivität flackern soll.<br />
<br />
Die restlichen Defines in diesem Bereich sollten nicht verändert werden.<br />
<br />
===ADC===<br />
Mit <code>ADC0_REF</code> kann die Spannungsreferenz für den ADC konfiguriert werden, diese kann durch ein-/auskommentieren der jeweiligen Zeile verändert werden. Bitte an der Stelle beachten, dass der verbaute Pull-Up lediglich gegen VDD (5 Volt) verschaltet werden kann.<br />
<br />
<code>ADC0_ACCUMULATE</code> legt fest, wie viele Messungen für eine Rückgabe des ADC-Werts durchgeführt werden. Leichtes Signalrauschen vorausgesetzt kann dies die Auflösung erhöhen. Entsprechend der Akkumulation (1/2/4/8/16/32/64) steigt der maximal mögliche Wert der Ausgabe und die Samplingdauer erhöht sich dementsprechend.<br />
Die zu messenden Kanäle sind Kommasepariert über <code>ADC_SCANCHANNELS</code> zu definieren, wird aktuell jedoch noch nicht "offiziell" unterstützt.<br />
<br />
===Encoder===<br />
Über <code>ROTENC_UPDATE_INTERVAL</code> wird der Ausleseintervall des AS5600 in 100 µs-Schritten definiert.<br />
Mti den folgendenn Defines mit Präfiy <code>ROTENC_</code>... kann das Verhalten des Sensors beeinflusst werden, bitte dazu das Datenblatt lesen.<br />
<br />
===Pulsezähler===<br />
Last but not least, der Pulszähler. In diesem Bereich kann der Intervall der Auslesungen (<code>PULSECOUNTER_TICK_INTERVAL</code>) in 100 µs-Schritten eingestellt werden.<br />
<br />
Mit <code>PULSECOUNTER_L_THRESHOLD</code> wird eingestellt, wie viele dieser Ticks das entsprechende Signal low sein muss, um einen Puls zu qualifizieren.<br />
<br />
Mit<br />
<source lang="c"><br />
#define PULSECOUNTER_TICK_INTERVAL 5<br />
#define PULSECOUNTER_L_THRESHOLD 20<br />
</source><br />
wird also ein Intervall von 500 µs für das Sampling eingestellt, dementsprechend muss ein Signal mindestens 20 Samples zusammenhängend als low erkannt worden sein (also 10 ms), um registriert zu werden.<br />
<br />
==Anschluss==<br />
Easy. Pinöpel an den Federkraftklemmen drücken, Leitung (egal ob starr oder flexibel - auch ohne Aderendhülse) bis 0,82 mm² reinschieben, fertig.<br />
<br />
Da Masse und Versorgung für die Sensoren geteilt wird, kann es dann wie folgt aussehen:<br />
<br />
<gallery><br />
DS18B20Modbus_Anschlussklemmen.jpg | Beispiel der Anschlsussbelegung<br />
</gallery><br />
<br />
Fremdspannung wird nicht toleriert, also am besten nur durch das Modul versorgte Peripherie verwenden.<br />
<br />
==Kommunikation==<br />
In Python lässt sich die Kommunikation recht einfach mit [https://pypi.org/project/pymodbus/ pymodbus] bewerkstelligen.<br />
<br />
Für den Einstieg ein einfaches Beispiel:<br />
<source lang="python"><br />
from pymodbus.client import ModbusSerialClient<br />
import time<br />
<br />
client = ModbusSerialClient("COM2", baudrate=19200)<br />
client.connect()<br />
<br />
addr = 10 # modbus address of the device<br />
<br />
# write holding register to initiate readout<br />
client.write_register(0, 1, addr) <br />
<br />
# wait for the conversion to be done<br />
time.sleep(1.1)<br />
<br />
# read the input registers for temperature (and readout counter)<br />
ans = client.read_input_registers(0, 8, addr)<br />
<br />
# divide the temperature readings to °C (only works for positive temperatures)<br />
print([x / 100 for x in ans.registers[0:6]])<br />
<br />
print(f"the temperature sensors were read {ans.registers[7]} times")<br />
</source><br />
<br />
Startet die Konversion der Temperaturfühler und gibt die Messwerte sowie die Anzahl der Messungen aus.<br />
<br />
Nochmal einen Schritt zurück - die Register sind wie folgt definiert:<br />
<br />
===Holding-Register===<br />
<br />
Das Set an Holding-Registern ist sehr überschaubar:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Register !! B15 !! B14 !! B13 !! B12 !! B11 !! B10 !! B09 !! B08 !! B07 !! B06 !! B05 !! B04 !! B03 !! B02 !! B01 !! B00 <br />
|-<br />
| 0x0000 || || || || || || || || || || || || || || || colspan="2" | DS18B20-Status<br />
|}<br />
<br />
Über die zwei niederwertigsten Bits von Register 0x0000 kann über das Schreiben des Wertes 0x1 die Konversion der DS18B20 gestartet und der Status des Vorgangs ausgelesen werden:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Wert !! Status<br />
|-<br />
| 0x0 || Idle, noch keine Konversion durchgeführt<br />
|-<br />
| 0x1 || Konversion starten<br />
|-<br />
| 0x2 || Konversion läuft<br />
|-<br />
| 0x3 || Konversion abgeschlossen, Werte sind verfügbar<br />
|-<br />
|}<br />
<br />
Während die Konversion läuft, leuchtet die rote Status-LED.<br />
<br />
===Input-Register===<br />
<br />
{| class="wikitable" <br />
|-<br />
! Register !! Funktion !! B15 !! B14 !! B13 !! B12 !! B11 !! B10 !! B09 !! B08 !! B07 !! B06 !! B05 !! B04 !! B03 !! B02 !! B01 !! B00 <br />
|-<br />
| 0x0000<br />
| rowspan="8" style="writing-mode:sideways-lr;" | Temperatursensoren<br />
| colspan="16" style="text-align:center;" | Temperatursensor S1<br />
|-<br />
| 0x0001<br />
| colspan="16" style="text-align:center;" | Temperatursensor S2<br />
|-<br />
| 0x0002<br />
| colspan="16" style="text-align:center;" | Temperatursensor S3<br />
|-<br />
| 0x0003<br />
| colspan="16" style="text-align:center;" | Temperatursensor S4<br />
|-<br />
| 0x0004<br />
| colspan="16" style="text-align:center;" | Temperatursensor S5<br />
|-<br />
| 0x0005<br />
| colspan="16" style="text-align:center;" | Temperatursensor S6<br />
|-<br />
| 0x0006<br />
| colspan="16" style="text-align:center;" | Temperatursensor S7<br />
|-<br />
| 0x0007<br />
| colspan="16" style="text-align:center;" | Auslesezähler Temperatursensoren<br />
|-<br />
| 0x0008<br />
| rowspan="3" style="writing-mode:sideways-lr;" | Encoder<br />
| <br />
| <br />
| <br />
| <br />
| Sensor nicht gefunden<br />
| Magnet erkannt<br />
| Signal zu schwach<br />
| Signal zu stark<br />
| colspan="8" style="text-align:center;" | Magnetsensor Gain<br />
|-<br />
| 0x0009<br />
| <br />
| <br />
| <br />
| <br />
| colspan="12" style="text-align:center;" | Winkel<br />
|-<br />
| 0x000A<br />
| <br />
| <br />
| <br />
| <br />
| colspan="12" style="text-align:center;" | Signalstärke<br />
|-<br />
| 0x000B<br />
| style="writing-mode:sideways-lr;" | ADC<br />
| <br />
| <br />
| <br />
| colspan="13" style="text-align:center;" | AIN<br />
|-<br />
| 0x000C<br />
| rowspan="8" style="writing-mode:sideways-lr;" | Pulszähler<br />
| colspan="16" style="text-align:center;" | Negative Pulse S1<br />
|-<br />
| 0x000D<br />
| colspan="16" style="text-align:center;" | Negative Pulse S2<br />
|-<br />
| 0x000E<br />
| colspan="16" style="text-align:center;" | Negative Pulse S3<br />
|-<br />
| 0x000F<br />
| colspan="16" style="text-align:center;" | Negative Pulse S4<br />
|-<br />
| 0x0010<br />
| colspan="16" style="text-align:center;" | Negative Pulse S5<br />
|-<br />
| 0x0011<br />
| colspan="16" style="text-align:center;" | Netative Pulse S6<br />
|-<br />
| 0x0012<br />
| colspan="16" style="text-align:center;" | Netative Pulse S7<br />
|-<br />
| 0x0013<br />
| colspan="16" style="text-align:center;" | Negative Pulse AIN<br />
|}<br />
<br />
====Temperatursensoren====<br />
<br />
Für einen noch nicht ausgelesenen Temperatursensor wird als Temperaturwert 0x8000 zurückgegeben, für das [https://github.com/cpetrich/counterfeit_DS18B20/#solution-to-the-85-c-problem 85 °C-Problem] ist keine Fehlerbehandlung integriert.<br />
<br />
Der Auslesezähler gibt an, wie oft seit dem Neustart des Mikrocontrollers die Sensoren abgefragt wurden. Der Wert kann überlaufen.<br />
<br />
Zum Auslesen der Temperaturen gibt es zwei Vorgehensweisen: "Starten und warten" oder "Starten und anstupsen".<br />
<br />
Starten und warten wurde bereits im Beispiel weiter oben gezeigt, wenn auch etwas unvollständig - für negative Temperaturen muss der zurückgegebene Wert entsprechend des Zweierkomplements umgewandelt werden.<br />
Vorteil dieser Methode ist, dass die Buslast niedrig gehalten wird. Da die Konversionsdauer fest ist ist das vermutlich auch die sinnvollste Variante.<br />
<br />
Kann man es machen wie die Kinder im Auto: "sind wir schon da?" - im Endeffekt muss hier genauso gewartet werden, aber halt anders.<br />
<br />
Beispielcode:<br />
<br />
<source lang="python"><br />
def twos_comp(val, bits):<br />
if (val & (1 << (bits - 1))) != 0:<br />
val = val - (1 << bits)<br />
return val <br />
<br />
def read_temps_poll(client, addr):<br />
client.write_register(0x0000, 1, addr)<br />
done = False<br />
for _ in range(0, 15):<br />
hodl = client.read_holding_registers(0x0000, 1, addr)<br />
<br />
if hodl.registers[0] == 0:<br />
raise Exception("Conversion didn't start")<br />
if hodl.registers[0] == 3:<br />
done = True<br />
break<br />
time.sleep(0.1)<br />
if not done:<br />
raise Exception("Conversion didn't finish in time")<br />
<br />
ans = client.read_input_registers(0x0000, 7, addr)<br />
return [None if x == 0x8000 else (twos_comp(x, 16) / 100) for x in ans.registers]<br />
<br />
def read_temps_wait(client, addr):<br />
client.write_register(0x0000, 1, addr)<br />
time.sleep(1.1)<br />
<br />
ans = client.read_input_registers(0x0000, 7, addr)<br />
return [None if x == 0x8000 else (twos_comp(x, 16) / 100) for x in ans.registers]<br />
</source><br />
<br />
====Encoder====<br />
<br />
Das Auslesen des magnetischen Encoders ist sichtlich einfach. Die Werte sind im Endeffekt wie vom Sensor zur Verfügung gestellt. lediglich Bit 15 wird von der Firmware selbst erzeugt, wenn nicht auf das I²C-Device zugegriffen werden kann. Bitte beachten, dass es auch Winkeldaten gibt, wenn kein Magnet erkannt wurde. Dementsprechend rauschen die Werte.<br />
<br />
<source lang="python"><br />
ans = client.read_input_registers(0x0008, 3, addr)<br />
<br />
status = ans.registers[0] >> 8<br />
if status & 8 != 0:<br />
print("could not read sensor or sensor not detected")<br />
else:<br />
print(f"Angle: {ans.registers[1]}")<br />
print(f"Gain: {ans.registers[0] & 0xFF}")<br />
print(f"Magnitude: {ans.registers[2]}")<br />
if status & 4 != 0:<br />
print("magnet detected")<br />
if status & 2 != 0:<br />
print("magnet too weak")<br />
if status & 1 != 0:<br />
print("magnet too strong")<br />
</source><br />
<br />
====ADC====<br />
<br />
Das Auslesen des ADC ist sichtlich einfach:<br />
<br />
<source lang="python"><br />
ans = client.read_input_registers(0x000B, 1, addr)<br />
print(ans.registers[0])<br />
</source><br />
<br />
Je nach Konfiguration des Akkumulation ist der Wertebereich von 0 bis 1023/2046/4092/...<br />
<br />
====Pulszähler====<br />
<br />
Für die Pulszähler kann einfach das vorherige Beispiel herangezogen und die Register-Adresse angepasst werden.<br />
<br />
=Gehäuse=<br />
Kommt noch, wenn es besser ist.<br />
<br />
=Fehler/Verbesserungspotenzial=<br />
<br />
* Der Dip-Schalter für die Adresswahl sollte richtig angeschlossen werden bzw. das Ändern der Adresse per Modbus erfolgen können<br />
* Die Konfiguration der IOs per config.h ist noch unvollständig. Persistente Konfiguration per Modbus wäre noch etwas besser<br />
* Die Platzierung der Schraublöcher ist in Hinblick auf die Leitungen unglücklich<br />
<br />
=Downloads=<br />
Alle Projektdaten können auf [https://github.com/chris-heo/DS18B20_Modbus Github] heruntergeladen werden.<br />
<br />
[[Kategorie:Modbus]]<br />
[[Kategorie:Hausautomatisierung]]<br />
[[Kategorie:Heizung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:Haustechnik]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_bot_assy.png&diff=1882Datei:DS18B20Modbus v0.1 pcb bot assy.png2024-01-17T21:59:17Z<p>Chris: Chris lud eine neue Version von Datei:DS18B20Modbus v0.1 pcb bot assy.png hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_Anschlussklemmen.jpg&diff=1883Datei:DS18B20Modbus Anschlussklemmen.jpg2024-01-17T21:59:17Z<p>Chris: Chris lud eine neue Version von Datei:DS18B20Modbus Anschlussklemmen.jpg hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_bot.png&diff=1884Datei:DS18B20Modbus v0.1 pcb bot.png2024-01-17T21:59:17Z<p>Chris: Chris lud eine neue Version von Datei:DS18B20Modbus v0.1 pcb bot.png hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_cal_setup.jpg&diff=1885Datei:DS18B20Modbus cal setup.jpg2024-01-17T21:59:17Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_top.png&diff=1886Datei:DS18B20Modbus v0.1 pcb top.png2024-01-17T21:59:17Z<p>Chris: Chris lud eine neue Version von Datei:DS18B20Modbus v0.1 pcb top.png hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_aufgebaut.jpg&diff=1887Datei:DS18B20Modbus v0.1 aufgebaut.jpg2024-01-17T21:59:17Z<p>Chris: Chris lud eine neue Version von Datei:DS18B20Modbus v0.1 aufgebaut.jpg hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_top_assy.png&diff=1888Datei:DS18B20Modbus v0.1 pcb top assy.png2024-01-17T21:59:17Z<p>Chris: Chris lud eine neue Version von Datei:DS18B20Modbus v0.1 pcb top assy.png hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:LER_foto.jpg&diff=1881Datei:LER foto.jpg2024-01-17T21:59:16Z<p>Chris: Chris lud eine neue Version von Datei:LER foto.jpg hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:LER_sch.png&diff=1880Datei:LER sch.png2024-01-17T21:59:16Z<p>Chris: Chris lud eine neue Version von Datei:LER sch.png hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_bot_assy.png&diff=1875Datei:DS18B20Modbus v0.1 pcb bot assy.png2024-01-17T21:58:17Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_aufgebaut.jpg&diff=1876Datei:DS18B20Modbus v0.1 aufgebaut.jpg2024-01-17T21:58:17Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_bot.png&diff=1877Datei:DS18B20Modbus v0.1 pcb bot.png2024-01-17T21:58:17Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_top.png&diff=1878Datei:DS18B20Modbus v0.1 pcb top.png2024-01-17T21:58:17Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_pcb_top_assy.png&diff=1879Datei:DS18B20Modbus v0.1 pcb top assy.png2024-01-17T21:58:17Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:LER_sch.png&diff=1871Datei:LER sch.png2024-01-17T21:58:16Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:LER_foto.jpg&diff=1872Datei:LER foto.jpg2024-01-17T21:58:16Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_v0.1_sch.png&diff=1873Datei:DS18B20Modbus v0.1 sch.png2024-01-17T21:58:16Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:DS18B20Modbus_Anschlussklemmen.jpg&diff=1874Datei:DS18B20Modbus Anschlussklemmen.jpg2024-01-17T21:58:16Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=DS18B20-Modbus-Adapter&diff=1870DS18B20-Modbus-Adapter2024-01-17T21:57:35Z<p>Chris: Die Seite wurde neu angelegt: „Aufgebauter Leiterkarte (v0.1) Der Plan, der Heizung etwas genauer auf die Finger zu schauen, sie zu verstehen,…“</p>
<hr />
<div>[[Bild:DS18B20Modbus_v0.1_aufgebaut.jpg|thumb|Aufgebauter Leiterkarte (v0.1)]]<br />
Der Plan, der Heizung etwas genauer auf die Finger zu schauen, sie zu verstehen, Fehler möglichst früh zu erkennen und das System schlussendlich zu optimieren, nimmt (in kleinen Schritten) Form an.<br />
<br />
So werden die Messwerte der Solaranlage (inkl. ein paar Temperaturwerte der Heizung) und die Stromaufnahme der Wärmepumpe mittlerweile in eine InfluxDB geloggt, aber das soll nicht alles bleiben.<br />
<br />
Um besseren Einblick zu bekommen was rein und raus geht, sollen u. a. die Temperaturen für Vor- und Rückläufe, Mischerstellungen und Drücke erfasst werden. Ideal wäre natürlich auch, die Durchflussmenge zu messen (hier fehlt es aber noch an Zählern - dazu muss der Heizungsbauer ran...).<br />
<br />
Wenn man sich mit Automatisierung und deren Kommunikation beschäftigt, kommt man fast nicht um Modbus. Das Protokoll ist relativ einfach, robust und hat sich in der Industrie etabliert.<br />
<br />
Da dieser in Form von Stromzählern bereits Einzug ins Haus gefunden gefunden hat und dadurch eine Verkabelung vorhanden ist, ist es ein logischer Schritt, auf diesen Bus aufzubauen.<br />
<br />
Zwar kann man fertige Messwandler für Modbus kaufen, die können dann oft nur "Eines" und sind, gerade wenn sie aus dem Industrie-Umfeld sind, entsprechend teuer. Warum also nicht selber bauen?<br />
<br />
=Plan & Features=<br />
<br />
Der ATtiny1616 hat ein gutes Preis-/Leistungsverhältnis, verfügt über eine angenehme Anzahl an I/Os, ist einfach zu programmieren (man brauch nicht mehr als einen [https://github.com/mraardvark/pyupdi USB-UART-Adapter]) und die Verfügbarkeit ist gut.<br />
<br />
Als Temperaturfühler sollen, weil ebenfalls preiswert und einfach in der Verkabelung, Sensoren mit [[wpde:1-Wire|1-Wire]] zum Einsatz kommen. Genauer gesagt DS18B20 bzw. deren vielfältige [https://github.com/cpetrich/counterfeit_DS18B20/ Fakes/Clones/Nachahmer].<br />
<br />
Um die Stellung von Mischern oder analogen Manometern zu erfassen, soll ein magnetischer Encoder (genauer ein AMS AS5600) eingesetzt werden. Mit einem auf die Achse geklebten diametralen Magnet lässt sich so ohne nennenswerte Eingriffe die Position mit hoher Auflösung erfassen.<br />
<br />
Mehr ist natürlich immer besser:<br />
<br />
Da der Mikrocontroller über mehrere ADC-Kanäle verfügt, sollen diese ebenfalls zur Verfügung stehen können.<br />
<br />
Um Zählausgänge (zum Beispiel von Wasseruhren) zu erfassen, soll ebenfalls ein Pulszähler zu den Funktionen gehören.<br />
<br />
=Hardware=<br />
<br />
==Schaltplan==<br />
<br />
Der Schaltplan ist relativ straight forward:<br />
<br />
Da die externe Stromversorgung irgendwas sein kann, regelt ein 78(L)05. Für ein bisschen Flexibilität sind gleich 3 Footprints auf der Leiterkarte: im SOT89-Gehäuse (weil schön klein und gute thermische Anbindung), SO8-Gehäuse (weil davon sicher einer herumliegt) und im TO220-Gehäuse. Letzteren nicht, weil man ihn bräuchte, aber man kann bei Bedarf auch so etwas wie einen [[Mini-Schaltwandler]] einbauen.<br />
<br />
Für Modbus hängt ein MAX485 am UART des Mikrocontrollers, für DIR wird die XDIR-Funktionalität des Mikrocontroller ignoriert, weil die dafür verfügbaren Pins etwas blöd liegen (mehr dazu später).<br />
<br />
I²C ist ebenfalls einfach: zwei Pull-ups und fertig. <br />
<br />
Etwas aufgehoben, aber ehrlicherweise als erstes festgelegt: 1-Wire. Der Einfachheit halber soll jeder Sensor seinen eigenen Pin bekommen (auch wenn man mehrere Devices über einen Bus ansprechen kann). Da das Auslesen die CPU etwas länger blockieren kann und um die Werte synchron zu erhalten sollen alle Sensoren gleichzeitig angesprochen werden, dazu sollen möglichst viele Pins von einem Port genutzt werden - der ATtiny1616 hat 3 Ports mit unterschiedlich vielen IOs, wobei es eine relativ starke (wenn auch etwas flexible) Doppelbelegung besteht. PORTA ist mit 8 IOs am "breitesten", wobei PA0 als UPDI-Pin verwendet wird. Ohne HV UPDI, einem guten Bootloader oder dem Vertrauen, dass die Firmware fertig ist.<br />
<br />
Wie auch immer: 7 Kanäle sind noch immer besser als 6 (an PORTB). <br />
<br />
Um bei der Verwendung der Sensorkanäle flexibel zu sein, beinhaltet das Design Bestückungsoptionen für Serienwiderstände (per default überbrückt), Pull-Ups und Kondensatoren um Tiefpassfilter einzubauen. Zudem gibt es an allen nach außen geführten Leitungen ESD-Schutz. Darf auch mal sein.<br />
<br />
Als Anschlussklemmen gibt es zur Abwechslung mal keine Schraubklemmen, sondern Federkraftklemmen. Um nicht für jeden der Sensoren jeweils zwei Klemmen für die Versorgung zu spendieren (bei 7 Temperaturfühlern wären das immerhin 21 KIemmen), teilen sich zwei Sensoren ein Pärchen für die Versorgung, was die Klemmenanzahl auf 16. Mit zwei 12er-Klemmblöcken lässt sich so die Versorgung, RS485-Interface, 8 Sensoreingänge und ein I²C-Interface unterbringen.<br />
<br />
Zur Statusanzeige dienen zwei LEDs, die sich die IOs mit dem auf eine Stiftleiste herausgeführten SPI-Interface teilen.<br />
<br />
Die Stiftleiste stellt zugleich das Programmierinterface und den GPIO (der auch als Analogeingang genutzt werden kann) zur Verfügung.<br />
<br />
Der Plan, die Modbus-Adresse über ein Mäuseklavier zu konfigurieren scheiterte in der ersten Hardware-Revision. Ein analoges Signal auf einen der wenigen Pins zu führen, der nicht über einen ADC-Kanal verfügt ist immerhin auch eine Leistung ;)<br />
<br />
Viel Text, jetzt Butter bei die Fische - der Schaltplan:<br />
<br />
<gallery><br />
DS18B20Modbus_v0.1_sch.png | Schaltplan v0.1<br />
</gallery><br />
<br />
==Layout==<br />
Wie immer folgt das Layout dem Prinzip "So groß wie nötig, so klein wie möglich". Die Breite der Leiterkarte wird von den Federkraftklemmen vorgegeben, die Länge ergibt sich durch das Design.<br />
<br />
Um keinen einseitigen Wust an Leitungen zu haben, sind die Klemmen gegenüberliegend platziert, in der Mitte sitzt die ganze Logik.<br />
<br />
ESD-Schutz und (optionale Filter RC-Filter) liegen so nah wie möglich an den Klemmen.<br />
<br />
Da für die - wie sich im Nachhinein herausstellte - etwas zu knapp platzierten Schraublöchern ungenutzter Platz entstand, gibt es Beschriftungen für die Klemmblöcke.<br />
<br />
<gallery><br />
DS18B20Modbus_v0.1_pcb_top.png | Oberseite (Vollbestückung)<br />
DS18B20Modbus_v0.1_pcb_bot.png | Unterseite (Vollbestückung)<br />
DS18B20Modbus_v0.1_pcb_top_assy.png Oberseite (tatsächliche Bestückung)<br />
DS18B20Modbus_v0.1_pcb_bot_assy.png Oberseite (tatsächliche Bestückung)<br />
<br />
</gallery><br />
<br />
==BOM==<br />
{| class="wikitable"<br />
! Menge !! Referenz !! Wert !! Package !! Reichelt Bestellcode<br />
|-<br />
| 1 || SV2 || || MA04-1R || MPE 087-1-004 <br />
|-<br />
| 1 || SV1 || || MA08-1R || MPE 087-1-008 <br />
|-<br />
| 4 || C2, C3, C5, C14 || 0u1 || C0603 || KEM Y5V0603 100N<br />
|-<br />
| 1 || C1 || 0u1 || C0805 || KEM X7R0805 100N<br />
|-<br />
| 1 || C4 || 10u || C0805 || KEM X5R0805 10U <br />
|-<br />
| 1 || R24 || 120 || R0603 || RND 155HP03 AL <br />
|-<br />
| 1 || R14 || 1k5 || R0603 || SMD-0603 1,5K <br />
|-<br />
| 1 || R13 || 2k2 || R0603 || SMD-0603 2,2K <br />
|-<br />
| 2 || R10, R11 || 47k || R0603 || SMD-0603 47K <br />
|-<br />
| 1 || C9 || 47u/25V || E2,5-5 || HD-A 47U 25 <br />
|-<br />
| 9 || R1, R2, R3, R4, R5, R6, R7, R8, R18 || 4k7 || R0603 || SMD-0603 4,7K <br />
|-<br />
| 1 || R9 || 4k7 || R0603 || SMD-0603 47K <br />
|-<br />
| 1 || IC5 || 78L05F || SOT89 || TS 78L05 ACY <br />
|-<br />
| 1 || IC1 || ATTINY1616 || SO20_T1616 || ATTINY1616-SN <br />
|-<br />
| 1 || D9 || BAT43WS || SOD323-W || BAT 43WS <br />
|-<br />
| 2 || X1, X2 || DG250-3.5-12P-1Y-00A || DG250-3.5-12P-1Y-00A || DG250 3,5-12 <br />
|-<br />
| 1 || IC3 || MAX481CSA || SO08 || MAX 481 CSA <br />
|-<br />
| 1 || D7 || P4SMAJ18CA || DO214AC || P4SMAJ18CA <br />
|-<br />
| 6 || D1, D2, D3, D4, D5, D6 || PESD1CAN || SOT23 || PESD 1CAN <br />
|-<br />
| 1 || LED1 || gn || SML0805 || SMD-LED 0805 GN <br />
|-<br />
| 1 || LED2 || rt || SML0805 || SMD-LED 0805 RT <br />
|}<br />
<br />
==Aufbau==<br />
Beim Bestücken der Leiterkarte sollten die Federkraftklemmen zumindest auf der Oberseite wirklich als letzte Bauteile bestückt werden, sonst wird es es ein sehr unangenehmes Unterfangen.<br />
<br />
Die Fuses für den Mikrocontroller sind in der Firmware "eingebacken". Es kommt ein wenig auf den Programmer an, ob die Sektion im ELF-File unterstützt wird. Für alle anderen Fälle, hier die Fuses fürs manuelle Schreiben und Prüfen:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Register !! Wert <br />
|-<br />
| WDTCFG || 0x02 <br />
|-<br />
| BODCFG || 0x06 <br />
|-<br />
| OSCCFG || 0x01 <br />
|-<br />
| TCD0CFG || 0x00 <br />
|-<br />
| SYSCFG0 || 0xC5 <br />
|-<br />
| SYSCFG1 || 0x30 <br />
|-<br />
| APPEND || 0x00 <br />
|-<br />
| BOOTEND || 0x00 <br />
|}<br />
<br />
=Software=<br />
==1-Wire==<br />
Lange habe ich mich gescheut, etwas mit 1-Wire zu machen. Hauptsächlich weil die meisten Bibliotheken das Timing mit Sleeps erzeugen und somit höchst inkompatibel mit Interrupt-getriebenen Anwendungen sind. Um es selbst mit Interrupts zu programmieren war die Not nicht groß genug.<br />
<br />
Offenbar hatte Peter Dannegger ähnliches im Sinn und es [https://www.mikrocontroller.net/topic/493064 auf clevere Weise gelöst].<br />
<br />
Der Code spricht allerdings nur mit einem Sensor an einem IO. Man könnte nun den Code zur Verwendung unterschiedlicher Pins umbauen, oder mehrere Sensoren pro Pin verwenden kann. Ersteres hätte jedoch die Nebenwirkung, dass das Auslesen in die Länge gezogen wird und das die Werte nicht synchron sind (was in den meisten Fällen jedoch zu verschmerzen wäre). Letzteres ist deutlich aufwändiger, da ohne die Kenntnis der Seriennummer der Busteilnehmer auch eine [https://www.analog.com/en/app-notes/1wire-search-algorithm.html Suchfunktion] implementiert werden muss, auch ist die eindeutige Zuordnung Sensor zu Pin nicht ohne Weiteres möglich (und zu guter Letzt wird auch die Registerzuordnung in Richtung Modbus etwas komplexer).<br />
<br />
Ob man nun auf einen Pin oder einen ganzen Port zugreift macht bei den meisten Mikrocontrollern keinen großen Unterschied, weshalb ich den Code dementsprechend umgebaut hab. Im Zuge dessen ist nun auch der IO-Zugriff etwas stärker von der Statemachine getrennt, was die Portierung auf andere Plattformen erleichtern dürfte. Auch die Methoden für die Kommunikation mit den DS18B20 wurde etwas stärker vom 1-Wire-Interface getrennt und eine kleine Statemachine gebaut, um den Lesezyklus zu vereinfachen - so muss man die Messung nur noch starten, periodisch eine Tick-Funktion aufrufen, die einem auch gleich sagt, ob Ergebnisse vorliegen. Die Temperatur der einzelnen Kanäle kann als signed fixed point gelesen werden.<br />
<br />
Da manche der DS18B20-Clones wohl die Eigenschaft haben, sich nach einer gewissen Anzahl an Lesezyklen selbst zu zerstören (kann die Quelle leider nicht mehr finden), geschieht das Auslesen nur auf Anfrage. Mehr dazu weiter unten.<br />
<br />
==I²C==<br />
Zum Auslesen des magnetischen Encoders wird I²C verwendet.<br />
<br />
Das Programm initialisiert den Chip sobald er erkannt wird und versetzt ihn in den Stromspar-Modus LPM1. Der Slow Filter wird (unnötigerweise) auf 16x konfiguriert, Der Fast Filter bleibt wie der Watchdog aus.<br />
<br />
Die Einstellungen lassen sich in config.h ändern.<br />
<br />
Neben dem Winkel lassen sich über Modbus auch die Statusregister auslesen. Mehr dazu unten.<br />
<br />
==Analogeingang==<br />
Ein Pin am AVR ist noch frei, eine Klemme am Klemmblock konnte freigeräumt werden und ich möchte eine Status-Lampe überwachen. Durch den ADC lässt sich eine größere Außenbeschaltung vermeiden und die Flexibilität per Software ist groß.<br />
<br />
Auch hier lässt sich die Konfiguration für die Wandlung in config.h ändern. Standardmäßig wird die 5V-Versorgungsspannung als Referenz verwendet und über 8 Samples akkumuliert.<br />
<br />
==Pulszähler==<br />
Für den Pulszähler braucht es eigentlich nur eine einigermaßen gute Entprellung bzw. vielmehr eine Qualifizierung der Gültigkeit der Länge eines Pulses.<br />
<br />
Dazu wird die Anzahl der Ticks nach einem Pegelwechsel gezählt. Der Teiler für die Ticks und die Anzahl der Ticks - also die Qualifikationszeit kann (ein gemeinsamer Wert für alle Eingänge) in config.h definiert werden.<br />
<br />
Neben den Sensoreingängen werden auch Pulse auf AIN gezählt.<br />
<br />
Aktuell werden nur die negativen Pulse per Modbus zur Verfügung gestellt.<br />
<br />
==Modbus==<br />
Da das Rad nicht neu erfunden werden muss, kommt für das Modbus-Interface [https://github.com/mbs38/yaMBSiavr yaMBSiavr] zum Einsatz. Die Bibliothek wurde für den avrtiny-1-Core angepasst (und natürlich ein Pull-Request erstellt). Zusätzlich gab es eine kleine Erweiterung: nun ist die Möglichkeit eingehackt, den Server zu identifizieren (nach Abschnitt 6.21 der [https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf V1.1b3 Spec]).<br />
<br />
Dreh- und Angelpunkt für die Kommunikation sind die Input- und Holding-Register, die im folgenden Abschnitt beschrieben ist:<br />
<br />
=Benutzung=<br />
==Konfiguration==<br />
Die Konfiguration findet vorwiegend in config.h statt.<br />
===Pin-Verwendung===<br />
Im ersten Block kann die Verwendung der 7 Sensor-Pins definiert werden. Aktuell wird lediglich zwischen <code>USAGE_NONE</code> und <code>USAGE_DS18B20</code> unterschieden. Der Pulszähler ist permanent aktiv, ADC wird momentan nur für AIN unterstützt.<br />
<br />
===Modbus===<br />
Die RS485-Schnittstelle läuft mit 19200 Baud 8N1 - die Baudrate kann über den Define <code>MODBUS_BAUDRATE</code> angepasst werden.<br />
<br />
Die Modbus-Adresse muss aktuell zur Kompilierzeit über <code>MODBUS_ADDRESS</code> festgelegt werden. Mit der nächsten Hardware-Revision wird mit an Sicherheit grenzender Wahrscheinlichkeit das Setzen per Dip-Schalter verfügbar sein.<br />
<br />
<code>MODBUS_ACT_DURATION</code> legt in 100 µs-Schritten fest, wie lange die Power-LED bei Busaktivität flackern soll.<br />
<br />
Die restlichen Defines in diesem Bereich sollten nicht verändert werden.<br />
<br />
===ADC===<br />
Mit <code>ADC0_REF</code> kann die Spannungsreferenz für den ADC konfiguriert werden, diese kann durch ein-/auskommentieren der jeweiligen Zeile verändert werden. Bitte an der Stelle beachten, dass der verbaute Pull-Up lediglich gegen VDD (5 Volt) verschaltet werden kann.<br />
<br />
<code>ADC0_ACCUMULATE</code> legt fest, wie viele Messungen für eine Rückgabe des ADC-Werts durchgeführt werden. Leichtes Signalrauschen vorausgesetzt kann dies die Auflösung erhöhen. Entsprechend der Akkumulation (1/2/4/8/16/32/64) steigt der maximal mögliche Wert der Ausgabe und die Samplingdauer erhöht sich dementsprechend.<br />
Die zu messenden Kanäle sind Kommasepariert über <code>ADC_SCANCHANNELS</code> zu definieren, wird aktuell jedoch noch nicht "offiziell" unterstützt.<br />
<br />
===Encoder===<br />
Über <code>ROTENC_UPDATE_INTERVAL</code> wird der Ausleseintervall des AS5600 in 100 µs-Schritten definiert.<br />
Mti den folgendenn Defines mit Präfiy <code>ROTENC_</code>... kann das Verhalten des Sensors beeinflusst werden, bitte dazu das Datenblatt lesen.<br />
<br />
===Pulsezähler===<br />
Last but not least, der Pulszähler. In diesem Bereich kann der Intervall der Auslesungen (<code>PULSECOUNTER_TICK_INTERVAL</code>) in 100 µs-Schritten eingestellt werden.<br />
<br />
Mit <code>PULSECOUNTER_L_THRESHOLD</code> wird eingestellt, wie viele dieser Ticks das entsprechende Signal low sein muss, um einen Puls zu qualifizieren.<br />
<br />
Mit<br />
<source lang="c"><br />
#define PULSECOUNTER_TICK_INTERVAL 5<br />
#define PULSECOUNTER_L_THRESHOLD 20<br />
</source><br />
wird also ein Intervall von 500 µs für das Sampling eingestellt, dementsprechend muss ein Signal mindestens 20 Samples zusammenhängend als low erkannt worden sein (also 10 ms), um registriert zu werden.<br />
<br />
==Anschluss==<br />
Easy. Pinöpel an den Federkraftklemmen drücken, Leitung (egal ob starr oder flexibel - auch ohne Aderendhülse) bis 0,82 mm² reinschieben, fertig.<br />
<br />
Da Masse und Versorgung für die Sensoren geteilt wird, kann es dann wie folgt aussehen:<br />
<br />
<gallery><br />
DS18B20Modbus_Anschlussklemmen.jpg | Beispiel der Anschlsussbelegung<br />
</gallery><br />
<br />
Fremdspannung wird nicht toleriert, also am besten nur durch das Modul versorgte Peripherie verwenden.<br />
<br />
==Kommunikation==<br />
In Python lässt sich die Kommunikation recht einfach mit [https://pypi.org/project/pymodbus/ pymodbus] bewerkstelligen.<br />
<br />
Für den Einstieg ein einfaches Beispiel:<br />
<source lang="python"><br />
from pymodbus.client import ModbusSerialClient<br />
import time<br />
<br />
client = ModbusSerialClient("COM2", baudrate=19200)<br />
client.connect()<br />
<br />
addr = 10 # modbus address of the device<br />
<br />
# write holding register to initiate readout<br />
client.write_register(0, 1, addr) <br />
<br />
# wait for the conversion to be done<br />
time.sleep(1.1)<br />
<br />
# read the input registers for temperature (and readout counter)<br />
ans = client.read_input_registers(0, 8, addr)<br />
<br />
# divide the temperature readings to °C (only works for positive temperatures)<br />
print([x / 100 for x in ans.registers[0:6]])<br />
<br />
print(f"the temperature sensors were read {ans.registers[7]} times")<br />
</source><br />
<br />
Startet die Konversion der Temperaturfühler und gibt die Messwerte sowie die Anzahl der Messungen aus.<br />
<br />
Nochmal einen Schritt zurück - die Register sind wie folgt definiert:<br />
<br />
===Holding-Register===<br />
<br />
Das Set an Holding-Registern ist sehr überschaubar:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Register !! B15 !! B14 !! B13 !! B12 !! B11 !! B10 !! B09 !! B08 !! B07 !! B06 !! B05 !! B04 !! B03 !! B02 !! B01 !! B00 <br />
|-<br />
| 0x0000 || || || || || || || || || || || || || || || colspan="2" | DS18B20-Status<br />
|}<br />
<br />
Über die zwei niederwertigsten Bits von Register 0x0000 kann über das Schreiben des Wertes 0x1 die Konversion der DS18B20 gestartet und der Status des Vorgangs ausgelesen werden:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Wert !! Status<br />
|-<br />
| 0x0 || Idle, noch keine Konversion durchgeführt<br />
|-<br />
| 0x1 || Konversion starten<br />
|-<br />
| 0x2 || Konversion läuft<br />
|-<br />
| 0x3 || Konversion abgeschlossen, Werte sind verfügbar<br />
|-<br />
|}<br />
<br />
Während die Konversion läuft, leuchtet die rote Status-LED.<br />
<br />
===Input-Register===<br />
<br />
{| class="wikitable" <br />
|-<br />
! Register !! Funktion !! B15 !! B14 !! B13 !! B12 !! B11 !! B10 !! B09 !! B08 !! B07 !! B06 !! B05 !! B04 !! B03 !! B02 !! B01 !! B00 <br />
|-<br />
| 0x0000<br />
| rowspan="8" style="writing-mode:sideways-lr;" | Temperatursensoren<br />
| colspan="16" style="text-align:center;" | Temperatursensor S1<br />
|-<br />
| 0x0001<br />
| colspan="16" style="text-align:center;" | Temperatursensor S2<br />
|-<br />
| 0x0002<br />
| colspan="16" style="text-align:center;" | Temperatursensor S3<br />
|-<br />
| 0x0003<br />
| colspan="16" style="text-align:center;" | Temperatursensor S4<br />
|-<br />
| 0x0004<br />
| colspan="16" style="text-align:center;" | Temperatursensor S5<br />
|-<br />
| 0x0005<br />
| colspan="16" style="text-align:center;" | Temperatursensor S6<br />
|-<br />
| 0x0006<br />
| colspan="16" style="text-align:center;" | Temperatursensor S7<br />
|-<br />
| 0x0007<br />
| colspan="16" style="text-align:center;" | Auslesezähler Temperatursensoren<br />
|-<br />
| 0x0008<br />
| rowspan="3" style="writing-mode:sideways-lr;" | Encoder<br />
| <br />
| <br />
| <br />
| <br />
| Sensor nicht gefunden<br />
| Magnet erkannt<br />
| Signal zu schwach<br />
| Signal zu stark<br />
| colspan="8" style="text-align:center;" | Magnetsensor Gain<br />
|-<br />
| 0x0009<br />
| <br />
| <br />
| <br />
| <br />
| colspan="12" style="text-align:center;" | Winkel<br />
|-<br />
| 0x000A<br />
| <br />
| <br />
| <br />
| <br />
| colspan="12" style="text-align:center;" | Signalstärke<br />
|-<br />
| 0x000B<br />
| style="writing-mode:sideways-lr;" | ADC<br />
| <br />
| <br />
| <br />
| colspan="13" style="text-align:center;" | AIN<br />
|-<br />
| 0x000C<br />
| rowspan="8" style="writing-mode:sideways-lr;" | Pulszähler<br />
| colspan="16" style="text-align:center;" | Negative Pulse S1<br />
|-<br />
| 0x000D<br />
| colspan="16" style="text-align:center;" | Negative Pulse S2<br />
|-<br />
| 0x000E<br />
| colspan="16" style="text-align:center;" | Negative Pulse S3<br />
|-<br />
| 0x000F<br />
| colspan="16" style="text-align:center;" | Negative Pulse S4<br />
|-<br />
| 0x0010<br />
| colspan="16" style="text-align:center;" | Negative Pulse S5<br />
|-<br />
| 0x0011<br />
| colspan="16" style="text-align:center;" | Netative Pulse S6<br />
|-<br />
| 0x0012<br />
| colspan="16" style="text-align:center;" | Netative Pulse S7<br />
|-<br />
| 0x0013<br />
| colspan="16" style="text-align:center;" | Negative Pulse AIN<br />
|}<br />
<br />
====Temperatursensoren====<br />
<br />
Für einen noch nicht ausgelesenen Temperatursensor wird als Temperaturwert 0x8000 zurückgegeben, für das [https://github.com/cpetrich/counterfeit_DS18B20/#solution-to-the-85-c-problem 85 °C-Problem] ist keine Fehlerbehandlung integriert.<br />
<br />
Der Auslesezähler gibt an, wie oft seit dem Neustart des Mikrocontrollers die Sensoren abgefragt wurden. Der Wert kann überlaufen.<br />
<br />
Zum Auslesen der Temperaturen gibt es zwei Vorgehensweisen: "Starten und warten" oder "Starten und anstupsen".<br />
<br />
Starten und warten wurde bereits im Beispiel weiter oben gezeigt, wenn auch etwas unvollständig - für negative Temperaturen muss der zurückgegebene Wert entsprechend des Zweierkomplements umgewandelt werden.<br />
Vorteil dieser Methode ist, dass die Buslast niedrig gehalten wird. Da die Konversionsdauer fest ist ist das vermutlich auch die sinnvollste Variante.<br />
<br />
Kann man es machen wie die Kinder im Auto: "sind wir schon da?" - im Endeffekt muss hier genauso gewartet werden, aber halt anders.<br />
<br />
Beispielcode:<br />
<br />
<source lang="python"><br />
def twos_comp(val, bits):<br />
if (val & (1 << (bits - 1))) != 0:<br />
val = val - (1 << bits)<br />
return val <br />
<br />
def read_temps_poll(client, addr):<br />
client.write_register(0x0000, 1, addr)<br />
done = False<br />
for _ in range(0, 15):<br />
hodl = client.read_holding_registers(0x0000, 1, addr)<br />
<br />
if hodl.registers[0] == 0:<br />
raise Exception("Conversion didn't start")<br />
if hodl.registers[0] == 3:<br />
done = True<br />
break<br />
time.sleep(0.1)<br />
if not done:<br />
raise Exception("Conversion didn't finish in time")<br />
<br />
ans = client.read_input_registers(0x0000, 7, addr)<br />
return [None if x == 0x8000 else (twos_comp(x, 16) / 100) for x in ans.registers]<br />
<br />
def read_temps_wait(client, addr):<br />
client.write_register(0x0000, 1, addr)<br />
time.sleep(1.1)<br />
<br />
ans = client.read_input_registers(0x0000, 7, addr)<br />
return [None if x == 0x8000 else (twos_comp(x, 16) / 100) for x in ans.registers]<br />
</source><br />
<br />
====Encoder====<br />
<br />
Das Auslesen des magnetischen Encoders ist sichtlich einfach. Die Werte sind im Endeffekt wie vom Sensor zur Verfügung gestellt. lediglich Bit 15 wird von der Firmware selbst erzeugt, wenn nicht auf das I²C-Device zugegriffen werden kann. Bitte beachten, dass es auch Winkeldaten gibt, wenn kein Magnet erkannt wurde. Dementsprechend rauschen die Werte.<br />
<br />
<source lang="python"><br />
ans = client.read_input_registers(0x0008, 3, addr)<br />
<br />
status = ans.registers[0] >> 8<br />
if status & 8 != 0:<br />
print("could not read sensor or sensor not detected")<br />
else:<br />
print(f"Angle: {ans.registers[1]}")<br />
print(f"Gain: {ans.registers[0] & 0xFF}")<br />
print(f"Magnitude: {ans.registers[2]}")<br />
if status & 4 != 0:<br />
print("magnet detected")<br />
if status & 2 != 0:<br />
print("magnet too weak")<br />
if status & 1 != 0:<br />
print("magnet too strong")<br />
</source><br />
<br />
====ADC====<br />
<br />
Das Auslesen des ADC ist sichtlich einfach:<br />
<br />
<source lang="python"><br />
ans = client.read_input_registers(0x000B, 1, addr)<br />
print(ans.registers[0])<br />
</source><br />
<br />
Je nach Konfiguration des Akkumulation ist der Wertebereich von 0 bis 1023/2046/4092/...<br />
<br />
====Pulszähler====<br />
<br />
Für die Pulszähler kann einfach das vorherige Beispiel herangezogen und die Register-Adresse angepasst werden.<br />
<br />
=Gehäuse=<br />
Kommt noch, wenn es besser ist.<br />
<br />
=Fehler/Verbesserungspotenzial=<br />
<br />
* Der Dip-Schalter für die Adresswahl sollte richtig angeschlossen werden bzw. das Ändern der Adresse per Modbus erfolgen können<br />
* Die Konfiguration der IOs per config.h ist noch unvollständig. Persistente Konfiguration per Modbus wäre noch etwas besser<br />
* Die Platzierung der Schraublöcher ist in Hinblick auf die Leitungen unglücklich<br />
<br />
=Downloads=<br />
Alle Projektdaten können auf [https://github.com/chris-heo/DS18B20_Modbus Github] heruntergeladen werden.<br />
<br />
[[Kategorie:Modbus]]<br />
[[Kategorie:Hausautomatisierung]]<br />
[[Kategorie:Heizung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:Haustechnik]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=VBus-Decoder&diff=1869VBus-Decoder2023-08-25T21:09:56Z<p>Chris: /* Adapter für den Raspberry Pi */</p>
<hr />
<div>[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]<br />
Bei der Solaranlage meiner Eltern übernimmt ein Viessmann Vitosolic 200 die Regelung. <br />
Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de RESOL DeltaSol® M] handelt.<br />
<br />
Statt der RS-232-Schnittstelle hat das Teil einen Anschluss für den Viessmann-eigenen KM-Bus, zu dem mir keinerlei Informationen bekannt sind.<br />
<br />
Beim VBus sieht es deutlich besser aus. In der [http://www.mikrocontroller.net/topic/96431 Diskussion] auf Mikrocontroller.net bin ich auf den Beitrag von [http://www.mikrocontroller.net/topic/96431#1231974 Daniel Wippermann] gestoßen, woraufhin ich an die angegebene Adresse eine E-Mail geschickt habe. <br />
<br />
Keine zweieinhalb Stunden später habe ich die Dokumentation (inklusive der Erlaubnis zur Veröffentlichung, siehe Download) zum Protokoll erhalten.<br />
<br />
Irgendwann nach der Erstveröffentlichung dieses Artikels entstand eine deutlich erweiterte Dokumentation auf den [https://danielwippermann.github.io/resol-vbus/vbus-specification.html Github-Seiten von Daniel Wippermann]. Nicht nur das, sondern auch eine Implementierung des Protokolls in Javascript.<br />
<br />
=Hardware-Schnittstelle=<br />
[[Bild:Resol sch.png|thumb|Wo Rx und Tx ist, muss erraten werden ;)]]<br />
Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die - entgegen mancher Meinungen - überhaupt keine Ähnlichkeiten mit RS-485 hat.<br />
<br />
'''Bei ein paar Reglern scheint Resol eine RS-485-Schnittstelle mit VBus-Protokoll zu verwenden, die mit den hier vorgestellten Schaltungen nicht kompatibel ist. Bitte vor dem Nachbau der Hardware prüfen, um welches System es sich handelt. Dies kann entweder mit Hilfe des Handbuchs in Erfahrung gebracht werden (Angabe der Spannung und Strom, bei RS-485 ist üblicherweise keine Stromversorgung vorhanden) oder durch Messung ermittelt werden: An den VBus-Klemmen sollte eine (zappelnde) Spannung von ca. 8 V anliegen.'''<br />
<br />
Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2 V und 35 mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen.<br />
Mit der Schaltung auf Seite 5 des PDFs kann auf dem Bus sowohl gelesen, als auch geschrieben werden. Im Bild rechts meine Interpretation der Schaltung (in der noch die Abblockkondensatoren fehlen).<br />
<br />
Über die Buchse links kann man sich mit UART (nicht RS-232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.<br />
<br />
Der in meiner Schaltung verwendete FET für die bidirektionale Kommunikation ist übrigens ein BS170; wobei der Typ nicht kritisch ist, solange er den Bus kurzschließen kann, ohne dabei in Rauch aufzugehen.<br />
<br />
=Protokoll=<br />
Das Protokoll des VBus ist in seiner Version 1.0 ziemlich gut handzuhaben.<br />
<br />
Folgendes Daten habe ich zum Testen verwendet:<br />
<br />
<code><br />
<span class="he0"><span class="hb1">0xAA</span>, <span class="hb2">0x10, 0x00</span>, <span class="hb3">0x21, 0x73</span>, <span class="hb4">0x10</span>, <span class="hb5">0x00, 0x01</span>, <span class="hb6">0x12</span>, <span class="hb7">0x38</span></span>, <br /><br />
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39, <br /><br />
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B, <br /><br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br /><br />
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33, <br /><br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br /><br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37, <br /><br />
0x47, 0x00, 0x00, 0x00, 0x00, 0x38, <br /><br />
0x64, 0x64, 0x00, 0x00, 0x00, 0x37, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C, <br /><br />
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D, <br /><br />
0x01, 0x03, 0x60, 0x02, 0x04, 0x15, <br /><br />
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D, <br /><br />
</code><br />
<br />
Zu allererst wird ein <span class="he0">10 Byte langer Kopf</span> gesendet, der mit einem eindeutigen <span class="hb1">Sync-Wort (0xAA)</span> beginnt. Eindeutig heißt: An keiner anderen Stelle im Protokoll wird dieses Zeichen verwendet (bzw. das MSB belegt). Man kann sich also zu jedem beliebigen Zeitpunkt in den Bus einklinken!<br />
<br />
Gefolgt vom Sync-Wort kommen <span class="hb2">Ziel-</span> und <span class="hb3">Quelladresse</span> (<span class="hb2">0x0010</span> <= <span class="hb3">0x7321</span>), <span class="hb4">die Protokollversion (0x10)</span>, der <span class="hb5">ausgeführte Befehl (0x0100)</span> und die Anzahl der danach folgenden <span class="hb6">Nutzdatenframes (0x12)</span>. Abschließend wird eine <span class="hb7">Prüfsumme (0x38)</span> der zuvor gesendeten Daten übertragen.<br />
<br />
Im Anschluss an den Header wird die im Header angegebene <span class="hb6">Anzahl an Datenframes</span> mit je 6 Byte Länge geschickt (Auszug von oben):<br />
<br />
<code><br />
<span class="hb1">0x5E, 0x04, 0x5E, 0x01</span>, <span class="hb2">0x05</span>, <span class="hb3">0x39</span>,<br />
</code><br />
<br />
Die ersten 4 enthalten <span class="hb1">Nutzdaten</span>, im 5. wird ein <span class="hb2">Septett</span> geschickt und abschließend erfolgt wieder eine <span class="hb3">Prüfsumme</span>.<br />
<br />
Das Septett ist eine Ergänzung der zuvor gesendeten Nutzdaten. Da, wie oben erwähnt, das MSB nur im Sync-Wort vorkommen darf, ist es für die folgende Daten kein verboten - dieses findet sich jeweils in diesem zusätzlichen Byte.<br />
<br />
Die Prüfsumme der einzelnen Nachrichtenteile wird mittels CRC8 berechnet.<br />
<br />
Das ist auch schon das Gröbste.<br />
Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.<br />
<br />
==Adressen==<br />
Wie in vielen Bussystemen verwendet auch der VBus Pakete für die Nachrichten. Zu den Informationen in der PDF-Spezifikation sei an der Stelle auch auf die [https://danielwippermann.github.io/resol-vbus/#/vsf Paketbeschreibung] verwiesen.<br />
<br />
Die für den bei uns eingesetzten Regler lautet die Adresse 0x7321 (Vitosolic 200 [Regler]), die für das Logging relevanten Daten gehen an 0x0010 und werden in der Dokumentation lediglich als DFA beschrieben. Dabei handelt es sich nicht um eine komische Umschreibung für einen Broadcast, sondern um die Daten für ein zusätzliches Gerät - der Datenfernanzeige.<br />
<br />
An diese sendet der Regler alle von ihm gemessenen Werte. Neben der Regler-Identität hat der Vitosolic 200 noch die Identitäten WMZ1 und WM2 (Wärmemengenzähler).<br />
<br />
=Hardware=<br />
Im Laufe der Zeit haben sich mehrere Schaltungen ergeben. Um diesen Artikel übersichtlich zu halten, wurden die verschiedenen Varianten auf Unterseiten aufgeteilt:<br />
<br />
(Die Links zu den Unterseiten sind befinden sich jeweils in den Überschriften)<br />
<br />
==[[VBus-Decoder/Adapter für RS-232|Adapter für RS-232]]==<br />
Wenn man noch einen PC oder Adapter hat der RS-232 spricht, kann sich dieser Hardware bedienen.<br />
<br />
Der Zugriff ist nur lesend möglich und es gibt keine galvanische Trennung zwischen Bus und DTE.<br />
<br />
<gallery><br />
Bild:Vbus_rxo_brd.png|thumb|Layout der PC-Hardware<br />
</gallery><br />
<br />
==[[VBus-Decoder/Adapter Nano|Adapter Nano]]==<br />
Die vermutlich universellste Variante - schön klein, galvanische Trennung und funktioniert auf der Empfängerseite ab 3,3 V.<br />
<br />
<gallery><br />
resol_nano_0.1_assy.jpg|Bestückte Leiterkarte<br />
</gallery><br />
<br />
==[[VBus-Decoder/Adapter für den Raspberry Pi|Adapter für den Raspberry Pi]]==<br />
Wer Geräte ins Netzwerk bringen will, hat meistens auch einen Einplatinencomputer der Raspberry Pi Foudation auf der Liste.<br />
<br />
<gallery><br />
Vbuspi 1.0 bare.jpg | Unbestückte v1.0-Leiterkarte<br />
Vbuspi 1.1 assy zero.jpg | Bestückte v1.1-Leiterkarte auf einem Raspberry Pi Zero W<br />
Vbuspi 1.3 pers.jpg | v1.3-Bestückte Leiterkarte auf einem Raspberry Pi Zero W<br />
</gallery><br />
<br />
===Versionen===<br />
* [[VBus-Decoder/Adapter für den Raspberry Pi v1.0|Version 1.0/1.1]]: Der erste Versuch - "never trust a x.0"<br />
* [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.2|Version 1.2]]: Besser, aber noch nicht gut<br />
* '''[[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Version 1.3]]: Die beste Version, die man aktuell haben kann ;)'''<br />
<br />
==[[VBus-Decoder/Adapter für den ESP8266|Adapter für den ESP8266]]==<br />
Noch etwas kleiner als für den Raspberry Pi: Ein Adapter mit ESP8266-Modulen.<br />
<br />
<gallery><br />
vbusesp_top.jpg|Bestückte Leiterkarte<br />
</gallery><br />
<br />
==[[VBus-Decoder/Adapter_Nano#Troubleshooting|Troubleshooting]]==<br />
Für die Schaltung des Adapter Nano gibt es eine Troubleshooting-Anleitung, die in Teilen auch für die 5 V-Version der Raspberry-Pi-Variante gültig ist.<br />
<br />
=[[VBus-Decoder/FAQ|FAQ]]=<br />
(bitte auf die Überschrift klicken)<br />
<br />
=Software=<br />
==[[VBus-Decoder/AVR8-Software|AVR8]]==<br />
Zur Datenauswertung und für einfache, zusätzliche, Regelaufgaben (wie zum Beispiel Deaktivieren der Heizung, wenn die Solaranlage den Speicher belädt) - oder um die Anlage ins Internet of Things zu bekommen sind Mikrocontroller sehr geeignete Komponenten.<br />
<br />
Eine Implementierung für die [[VBus-Decoder/AVR8-Software|AVR8-Plattform]] findet sich auf der entsprechenden Unterseite.<br />
<br />
==Python==<br />
Nicki hat sich die Arbeit gemacht und einen Code zum Auswerten der Nachrichten in Python portiert. Ich hatte selbst noch keine gute Gelegenheit, ihn zu testen - daher ohne Garantie, Gewährleistung oder Support:<br />
<br />
* [[Datei:VBus-Python.zip]]<br />
<br />
Oliver hat basierend auf dem Code von Nicki eine Schnittstelle zur [https://www.volkszaehler.org/ Volkszähler]-Middleware gebaut:<br />
<br />
<pre><br />
Der Code nutzt die Resol-Decoder-Lib von Nicki, die ist auch mit dabei.<br />
In der config.py stellt man die Adresse der Middleware in seinem Netzwerk, <br />
sowie die UUID der Kanäle ein, damit man die Daten referenzieren kann.<br />
(Zum Test kann man auch simulierte Daten nutzen, oder die Ausgabe in ein File schreiben lassen)<br />
</pre><br />
<br />
* [[Datei:Vbus_volkszaehler.zip]]<br />
<br />
==Protokoll-Analysator==<br />
<br />
Da es mehrere Anfragen zur Untersuchung des Protokolls gab, habe ich vor einer Weile einen kleinen Protokollanalysator zusammengestrickt. Dieser unterstützt aktuell Protokollversion 1.0 und ist als "gefährliche Beta" anzusehen: [https://hobbyelektronik.org/tools/vbus-analyzer/ Resol Protocol Analyzer]<br />
<br />
=Downloads=<br />
* [[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009<br />
* (Die Downloads für die Hardware befindet sich auf der jeweiligen Unterseite)<br />
<br />
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''<br />
<br />
=Weblinks=<br />
* [http://www.mikrocontroller.net/topic/96431 Diskussion auf Mikrocontroller.net] (gleicher Link wie in der Einleitung)<br />
* [http://www.resol.de RESOL - Elektronische Regelungen GmbH]<br />
* [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de DeltaSol® M] Regler, der dem Viessmann Vitosolic 200 "alt" in ziemlich genau entspricht<br />
* [https://danielwippermann.github.io/resol-vbus Github-Seiten von Daniel Wippermann]<br />
<br />
[[Kategorie:AVR]]<br />
[[Kategorie:Energieerfassung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:VBus]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=VBus-Decoder/Adapter_f%C3%BCr_den_ESP8266&diff=1868VBus-Decoder/Adapter für den ESP82662023-08-25T20:33:12Z<p>Chris: Hinweis zu ESPHome hinzugefügt</p>
<hr />
<div>[[Bild:vbusesp_top.jpg|thumb|Aufgebauter Leiterkarte (v0.1)]]<br />
''Dies ist ein Unterartikel von [[VBus-Decoder]]. Auf der Hauptseite gibt es weitere Informationen zum Thema.''<br />
<br />
=Motivation=<br />
Wenn Basteln und IoT aufeinandertreffen, kommt man fast nicht an den Mikrocontrollern von Espressif vorbei.<br />
<br />
Genau aus diesem Grund hatte ich schon länger die Idee, ein Leiterkärtchen mit dem ESP8266 zu machen. Also warum nicht einfach den beliebten VBus ohne großes Strippenziehen ins Netzwerk bringen?<br />
<br />
=Schaltung=<br />
Die Schaltung für den VBus basiert auf der für den [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Raspi (v1.3)]], aufseiten des ESP habe ich mich von den verschiedenen Bastelboards inspirieren lassen und die Möglichkeit vorgesehen, sowohl die kleinen ESP01- als auch die etwas vielseitigeren ESP12-Module einzusetzen.<br />
<br />
Die Versorgung findet über eine Stiftleiste (bzw. angelötete Drähte) oder über eine Micro-USB-Buchse statt. <br />
Diese dient nur der Stromversorgung - mehr zum Programmieren des ESP weiter unten.<br />
<br />
Bei der Verwendung des ESP12-Moduls stehen zusätzlich zum VBus-Interface noch die GPIOs 12, 13, 14 und 16 sowie der ADC-Eingang und die 3,3V-Versorgung zur Verfügung. Hier kann weitere Peripherie wie Sensoren oder Displays angeschlossen werden.<br />
<br />
Für den Aufbau gibt es mehrere Varianten, die unten aufgeführt sind. Diese können über die Tabs ausgewählt und müssen beim Besorgen der Bauteile und selbstverständlich beim Zusammenbau kombiniert werden.<br />
<br />
Die theoretische Maximalbestückung sieht wie folgt aus:<br />
<br />
<gallery><br />
vbusesp_max_sch_1.png | Schaltplan VBus + Stromversorgung<br />
vbusesp_max_sch_2.png | Schaltplan ESP8266 und IO<br />
vbusesp_max_assy.png | Bestückungsplan<br />
</gallery><br />
<br />
=BOM=<br />
Möglichkeiten schaffen Komplexität. Wie bei den anderen Plattformen lässt sich der Adapter in verschiedenen Varianten aufbauen, wobei ich (auch wenn es gerade bei dieser anbietet) noch immer empfehle, die Optoisolierte aufzubauen.<br />
<br />
==Decoder==<br />
Neben Optoisoliert und Direkt gibt es noch die Variante ohne ESP - dank der Stiftleiste rechts oben auf der Leiterkarte lässt sich der VBus-Anteil komplett unabhängig vom ESP-Anteil verwenden. Mit Säge und Fingerspitzengefühl lässt sich die Größe auch noch ein gutes Stück reduzieren.<br />
<br />
Als ESP8266-Modul kann das ESP01 und ESP12(-F) verwendet werden. Getestet wurde bis jetzt nur das ESP12-F, wobei nichts gegen das 01 sprechen dürfte.<br />
<br />
<tabs><br />
<tab name="Optoisoliert"><br />
Empfohlene Bestückungsvariante.<br />
<gallery><br />
vbusesp_optiso_sch_1.png | Variantenschaltplan VBus<br />
vbusesp_optiso_sch_2.png | Variantenschaltplan ESP8266<br />
vbusesp_optiso_assy.png | Bestückungsplan<br />
</gallery><br />
<br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || SV4 || || MA05-2 || MPE 087-2-010 <br />
|-<br />
| 1 || SV3 || || MA07-1R || MPE 087-1-007 <br />
|-<br />
| 1 || JMP1 || 0R-JUMPA || A0R-JMP || RND 0805 1 0 <br />
|-<br />
| 1 || C11 || 100n || C0603 || X7R-G0603 100N <br />
|-<br />
| 3 || C2, C8, C14 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 4 || R18, R19, R22, R24 || 10k || R0805 || RND 0805 1 10K <br />
|-<br />
| 1 || R1 || 12k || R0805 || RND 1550805 DP <br />
|-<br />
| 3 || R2, R6, R8 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 5 || R9, R20, R21, R25, R28 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330 <br />
|-<br />
| 1 || C10 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U <br />
|-<br />
| 1 || OK1 || 6N136 || DIL08 || 6N 136 <br />
|-<br />
| 1 || S1 || 9305 || PHAP3301 || TASTER 9305 <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 2 || T1, T2 || BC848 || SOT23 || BC 848B SMD <br />
|-<br />
| 1 || U2 || ESP01 || ESP01 || DEBO ESP8266 <br />
|-<br />
| 1 || U1 || ESP12 || ESP12-SMD || DEBO ESP8266-12F <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|-<br />
| 1 || LED1 || or || CHIP-LED0805 || LED EL 0603 OR <br />
|}<br />
</tab><br />
<tab name="Direkt"><br />
<gallery><br />
vbusesp_direct_sch_1.png | Variantenschaltplan VBus<br />
vbusesp_direct_sch_2.png | Variantenschaltplan ESP8266<br />
vbusesp_direct_assy.png | Bestückungsplan<br />
</gallery><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || SV4 || || MA05-2 || MPE 087-2-010 <br />
|-<br />
| 1 || SV3 || || MA07-1R || MPE 087-1-007 <br />
|-<br />
| 3 || R10, R11, R15 || 0 || R1206 || RND 0805 1 0 <br />
|-<br />
| 1 || JMP1 || 0R-JUMPA || A0R-JMP || RND 0805 1 0 <br />
|-<br />
| 1 || C11 || 100n || C0603 || X7R-G0603 100N <br />
|-<br />
| 3 || C2, C8, C14 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 4 || R18, R19, R22, R24 || 10k || R0805 || RND 0805 1 10K <br />
|-<br />
| 5 || R2, R6, R8, R13, R14 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 4 || R20, R21, R25, R28 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330 <br />
|-<br />
| 1 || C10 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U <br />
|-<br />
| 1 || S1 || 9305 || PHAP3301 || TASTER 9305 <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 2 || T1, T2 || BC848 || SOT23 || BC 848B SMD <br />
|-<br />
| 2 || Q2, Q3 || BSS138 || SOT23 || BSS 138 SMD <br />
|-<br />
| 1 || U2 || ESP01 || ESP01 || DEBO ESP8266 <br />
|-<br />
| 1 || U1 || ESP12 || ESP12-SMD || DEBO ESP8266-12F <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|-<br />
| 1 || LED1 || or || CHIP-LED0805 || LED EL 0603 OR <br />
|}<br />
</tab><br />
<tab name="Optoisoliert (ohne ESP)"><br />
Wer keinen ESP8266 verwenden aber die Vorzüge der verbesserten Schaltung haben möchte, kann den ESP-Anteil vollständig weglassen.<br />
<br />
Hierfür wird auf dieser Leiterkarte keine Stromversorgung benötigt, da diese vom jeweilig verwendeten Interface (z. B. SBC, USB-UART-Wandler, ...) bezogen werden kann.<br />
<gallery><br />
vbusesp_optisonoesp_sch_1.png | Variantenschaltplan VBus<br />
vbusesp_optisonoesp_sch_2.png | Variantenschaltplan Interface<br />
vbusesp_optisonoesp_assy.png | Bestückungsplan<br />
vbusesp_vbusonly_pinout.png | Anschlussbelegung des UART<br />
</gallery><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || SV4 || || MA05-2 || MPE 087-2-010 <br />
|-<br />
| 1 || JMP1 || 0R-JUMPA || A0R-JMP || RND 0805 1 0 <br />
|-<br />
| 2 || C2, C8 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 1 || R1 || 12k || R0805 || RND 1550805 DP <br />
|-<br />
| 3 || R2, R6, R8 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 1 || R9 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330 <br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U <br />
|-<br />
| 1 || OK1 || 6N136 || DIL08 || 6N 136 <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|}<br />
</tab><br />
</tabs><br />
Egal welche Variante aufgebaut wird: bitte nicht vergessen, den Jumper (statt des 0R-Widerstandes kann auch eine Lötbrücke gesetzt werden) zu löten.<br />
<br />
==Stromversorgung==<br />
Für die Stromversorgung gibt es ebenfalls zwei Möglichkeiten: Entweder mit LDO oder Schaltwandler. Wer auf Nummer sicher gehen will, nimmt die billigere LDO-Variante, da ich noch keine Gelegenheit hatte letztere zu testen. Die etwas höhere Stromaufnahme dürfte wahrscheinlich nicht allzu sehr ins Gewicht fallen.<br />
<br />
<tabs><br />
<tab name="Linearregler"><br />
Empfohlene Bestückungsvariante.<br />
<br />
<gallery><br />
vbusesp_vregldo_sch_1.png | Variantenschaltplan Stromversorgung<br />
vbusesp_vregldo_assy.png | Bestückungsplan<br />
</gallery><br />
<br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || C15 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C13 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 1 || SV2 || MA02-1R || MA02-1R || MPE 087-1-002 <br />
|-<br />
| 1 || X2 || MIUSB-F5M-BB-UHS || MIUSB-F5M-BB-U_HANDSOLDER || MIC USB BBU <br />
|-<br />
| 1 || IC3 || REG1117 || SOT223 || NCP 1117 ST33T3G <br />
|}<br />
</tab><br />
<tab name="Schaltwandler"><br />
<gallery><br />
vbusesp_vregsmps_sch_1.png | Variantenschaltplan Stromversorgung<br />
vbusesp_vregsmps_assy.png | Bestückungsplan<br />
</gallery><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || C9 || 100n || C0603 || X7R-G0603 100N <br />
|-<br />
| 1 || C15 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C12 || 10p || C0603 || NPO-G0603 10P <br />
|-<br />
| 1 || R17 || 15k || R0603 || RND 0603 1 15K <br />
|-<br />
| 1 || L1 || 15u || 242408FPS || L-242408FPS 15µ <br />
|-<br />
| 1 || R16 || 47k || R0603 || RND 0603 1 47K <br />
|-<br />
| 1 || C13 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 1 || D6 || BAT43WS || SOD323-W || BAT 43WS <br />
|-<br />
| 1 || SV2 || MA02-1R || MA02-1R || MPE 087-1-002 <br />
|-<br />
| 1 || IC2 || MCP16301 || SOT23-6 || MCP 16301T-I/CHY <br />
|-<br />
| 1 || X2 || MIUSB-F5M-BB-UHS || MIUSB-F5M-BB-U_HANDSOLDER || MIC USB BBU <br />
|-<br />
| 1 || D4 || SS13L || SUBSMA || SS 13L <br />
|}<br />
</tab><br />
</tabs><br />
<br />
=Inbetriebnahme/Benutzung=<br />
==Flashing==<br />
Wird ein ESP8266 verwendet, muss natürlich erst einmal die Software auf den Mikrocontroller.<br />
<br />
Das Problem: Der Softwaredownload findet über den selben UART statt, der auch für das VBus-Interface statt.<br />
Nun könnte man mit Multiplexern arbeiten, was im Idealfall nur einmal benutzt werden würde und somit mit Kanonen auf Spatzen geschossen wäre. Aus dem gleichen Grund gibt es keinen USB-UART-Konverter auf dem Board: Braucht nur Platz und kostet.<br />
<br />
Deshalb wird für das erstmalige Flashen ein USB-UART-Adapter, der RTS/DTR anbietet, benötigt. Dieser sollte idealerweise mit 3,3 V arbeite, wobei der ESP wohl auch 5 V toleriert. Die beiden Transistoren für Reset und Bootloader nach WittyCloud/NodeMCU sind bereits vorhanden.<br />
<br />
Die 5 V-Stromversorgung muss entweder über den USB-Port oder der Stiftleiste SV2 kommen, die Anschlussbelegung des UART an SV4 ist wie folgt:<br />
<br />
{| class="wikitable"<br />
! Pin || Signal vom UART-Adapter<br />
|-<br />
| 1 || DTR<br />
|-<br />
| 3 || TX<br />
|-<br />
| 7 || RX<br />
|-<br />
| 9 || RTS<br />
|}<br />
<br />
<gallery><br />
vbusesp_prog_1.png | Anschlussbelegung für das Programmieren per UART<br />
vbusesp_prog_2.jpg | Verwendung des WittyCloud-USB-Wandlers<br />
</gallery><br />
<br />
Liegt das Trägerboard eines WittyCloud herum, müssen DTR und RTS gefädelt werden.<br />
<br />
==Betrieb==<br />
Ist die Firmware auf dem Chip und es sollen Daten vom VBus decodiert werden, muss ein Jumper zwischen Pin 3 und 4 an SV4 oder ein Lötpunkt auf SJ1 gesetzt werden:<br />
<br />
<gallery><br />
vbusesp_txjumper.png | UART-Verbindung zwischen VBus und ESP8266<br />
</gallery><br />
<br />
=Firmware=<br />
Zugegebenermaßen: ich habe zwar seit Jahren ein paar ESP8266-Module herumliegen, mich aber nie so richtig damit auseinandergesetzt.<br />
==Tasmota==<br />
Aber das macht nichts: [https://tasmota.github.io/docs/ Tasmota] unterstützt verschiedene [https://tasmota.github.io/docs/Smart-Meter-Interface/ Smart Metering]-Anbindungen, für die die Firmware allerdings angepasst selbst kompiliert werden muss.<br />
<br />
Michael hat sich (mit der Unterstützung aus der Tasmota-Community) daran gemacht und freundlicherweise die nötigen Anpassungen zur Verfügung gestellt:<br />
<br />
Folgendes muss in der Datei <code>tasmota/user_config_override.h</code> ergänzt werden:<br />
<source lang="C"><br />
#ifndef _USER_CONFIG_OVERRIDE_H_<br />
#define _USER_CONFIG_OVERRIDE_H_<br />
<br />
#ifndef USE_SCRIPT<br />
#define USE_SCRIPT<br />
#endif<br />
#ifndef USE_SML_M<br />
#define USE_SML_M<br />
#endif<br />
#ifdef USE_RULES<br />
#undef USE_RULES<br />
#endif<br />
#ifndef SML_REPLACE_VARS<br />
#define SML_REPLACE_VARS<br />
#endif<br />
#ifndef USE_SML_SCRIPT_CMD<br />
#define USE_SML_SCRIPT_CMD<br />
#endif<br />
#ifndef SML_MAX_VARS<br />
#define SML_MAX_VARS 20<br />
#endif<br />
#ifndef USE_SCRIPT_JSON_EXPORT<br />
#define USE_SCRIPT_JSON_EXPORT<br />
#endif<br />
#ifndef USE_SCRIPT_WEB_DISPLAY<br />
#define USE_SCRIPT_WEB_DISPLAY<br />
#endif<br />
</source><br />
<br />
===Konfiguration===<br />
Nach dem Flashen des Mikrocontrollers, was für fertige Builds auch über den Tasmotizer erfolgen kann, kann unter <code>Main-Menu -> Console -> Edit Script</code> das [https://tasmota.github.io/docs/Smart-Meter-Interface/#resol-deltasol-bs-plus-vbus Script ergänzt] werden.<br />
<br />
Mit dem Befehl <code>sensor53 d1</code> kann man den Header für die [https://tasmota.github.io/docs/Smart-Meter-Interface/#meter-metrics Meter Metrics] ermitteln und im Script entsprechend anpassen.<br />
<br />
Für die RemaSol B/2 sieht das wie folgt aus:<br />
<source><br />
r="1,aa10005d101000010a67"<br />
coltemp=0<br />
Byte1=0<br />
Byte2=0<br />
<br />
>S<br />
coltemp=sml[1]<br />
Byte1=coltemp>>8<br />
Byte2=coltemp&0xff<br />
if Byte1==0x00 {<br />
coltemp=coltemp&0xff<br />
}<br />
if Byte1==0xff {<br />
coltemp=(coltemp-0x10000)<br />
}<br />
coltemp=coltemp*0.1<br />
<br />
>B<br />
=>sensor53 r<br />
<br />
>M 1<br />
+1,3,v,0,9600,Solar<br />
%r%vo0uw@1,KollektorBase,°C,kolbase,2<br />
%r%vo0uw@10,KollektorOrg,°C,kolorg,2<br />
%r%vo2uw@10,Speicher unten,°C,spu,1<br />
%r%vo4uw@10,Speicher oben,°C,spo,1<br />
%r%vo8ub@1,Pumpe,%%,pump,0<br />
#<br />
<br />
>J<br />
,"Calculated":{"kol":%coltemp%}<br />
<br />
>W<br />
Kollektor berechnet: {m} %coltemp% °C<br />
</source><br />
Anmerkung: Hierbei handelt es sich um einen direkten Copy & Paste aus Michaels Script. Je nach Konfiguration der Anlage kann es Abweichungen geben.<br />
<br />
Um den Fragen zuvorzukommen - die Anpassung auf die Jeweilige Anlage beginnt in der ersten Zeile:<br />
<code><br />
r="1,<span class="hb1">aa</span><span class="hb2">1000</span><span class="hb3">5d10</span><span class="hb4">10</span><span class="hb5">0001</span><span class="hb6">0a</span><span class="hb7">67</span>"<br />
</code><br />
<br />
Die Farben entsprechen dem Beispiel von der [[VBus-Decoder#Protokoll|Artikelhauptseite]], kurzum:<br />
<br />
* <span class="hb1">aa</span>: Sync-Wort<br />
* <span class="hb2">1000</span>: Zieladresse<br />
* <span class="hb3">5d10</span>: Quelladresse<br />
* <span class="hb4">10</span>: Protokollversion<br />
* <span class="hb5">0001</span>: Befehl<br />
* <span class="hb6">0a</span>: Anzahl Nutzdatenframes<br />
* <span class="hb7">67</span>: Prüfsumme<br />
<br />
Die <span class="hb3">Quelladresse</span> kann in der [https://danielwippermann.github.io/resol-vbus/#/vsf VBus-Spezifikation nachgeschlagen werden]. Zu beachten ist hier die Endianness: was in der Doku als <code>0x1234</code> geschrieben ist, muss hier als <code>3412</code> angegeben werden.<br />
<br />
Anschließend muss man auf der [https://danielwippermann.github.io/resol-vbus/#/vsf oben genannten Seite] nach dem Command 0x0100 für den entsprechenden Regler suchen. Dazu am besten oben nach 0x0100 filtern und dann mit Strg+F die Quelladresse finden.<br />
<br />
Klickt man in der Zeile auf <code>Bytes</code> bekommt man die Länge der Nachricht, wobei man 1 addieren muss, da es sich um Offsets handelt. Beim RemaSol 1/2 (bzw. DeDietrich Sol Plus ER 709) ist der größte Offset 39, also 40 Bytes. Mit dem Wissen, dass ein Frame 4 Byte enthält, ergibt sich eine Länge von 10 Frames, was einem Hexadezimalwert von <span class="hb6">0x0A</span> entspricht.<br />
<br />
Nun muss man nur noch die Prüfsumme berechnen (oder durch Schnüffeln am UART ermitteln)<br />
<br />
Für die Feldzuordnung lohnt sich ein scharfer Blick und Vergleich der <code>Fields</code>-Seite für die [https://danielwippermann.github.io/resol-vbus/#/vsf/fields/00_0010_4221_10_0100 DeltaSol BS Plus] und dem Beispiel in der [https://tasmota.github.io/docs/Smart-Meter-Interface/#resol-deltasol-bs-plus-vbus dieses Reglers] in der Tasmota-Doku.<br />
<br />
==ESPHome==<br />
Auch ESPHome hat eine [https://esphome.io/components/vbus.html VBus-Komponente], die nicht unerwähnt bleiben soll.<br />
<br />
Von Stephan habe ich den Bericht erhalten, dass er diese Kombination erfolgreich in Betrieb genommen hat - und dass es im Zusammenhang mit HomeAssistant auch für Einsteiger tauglich ist.<br />
<br />
Eine Änderung hat er jedoch an der Hardware vorgenommen: Statt Rx von VBus auf GPIO3 zu verbinden, hat er GPIO5 gewählt, damit GPIO5 für Logging verwendet werden kann. Wird dann wohl eine Bestückungsoption für die nächste Version der Hardware :)<br />
<br />
=Leiterkarten=<br />
Es gibt noch unbestückte Leiterkärtchen. Wer eine will, kann sich gerne bei mir melden.<br />
<br />
Achtung: Es handelt sich um Version 0.1, auf der sich 3 kleine Fehler befinden, die sich allerdings mit Fädeldraht korrigieren lassen:<br />
<br />
==Hotfix für v0.1==<br />
Um die Leiterkarte Version 0.1 korrekt nutzen zu können, sind bis zu 3 Fixes nötig:<br />
<br />
===Bootloader-Schaltung===<br />
Die Beschaltung der Transistoren ist teilweise falsch. Um dies zu korrigieren, müssen 3 Leiterbahnen aufgetrennt werden und die Verbindungen mit Fädeldraht neu hergestellt werden.<br />
<br />
Das Auftrennen kann je nach Geschmack mit einem kleinen Trennschleifer (Vulgo Dremel) oder einem Messer erfolgen.<br />
Statt der zwei Drähte zum unteren der beiden Widerstände kann der Widerstand (im 0603-Gehäuse) auch zwischen die beiden Pads am Transistor gelegt werden und damit ein Schnitt und eine Drahtverbindung gespart werden.<br />
<br />
<gallery><br />
vbusesp_v01fix_transistor_rewire.png | Korrekturanleitung<br />
vbusesp_v01fix_transistor_prep1.jpg | mit dem Skalpell entfernt<br />
vbusesp_v01fix_transistor_prep2.jpg | mit dem Trennschleifer durchtrennt<br />
vbusesp_v01fix_transistor_done.jpg | Durchgeführte Korrektur<br />
</gallery><br />
<br />
===Beschaltung GPIO15 am ESP12===<br />
Diese Korrektur ist nur relevant, wenn man ein ESP12-Modul einsetzt.<br />
<br />
Der Mikrocontroller startet nur, wenn GPIO15 über einen Pull-down mit Masse verbunden ist.<br />
<br />
Dazu sollte ein 10k-Widerstand zwischen diese beiden Pins, wie unten dargestellt, eingebaut werden:<br />
<br />
<gallery><br />
vbusesp_v01fix_res.jpg | Durchgeführte Korrektur. Widerstand ist zweckvoll!<br />
</gallery><br />
<br />
===Pull-up an Q3===<br />
Wird die Tx-Funktionalität verwendet, blockiert der als Pull-down eingesetzte R14 den Bus.<br />
<br />
Um dies zu berichtigen muss das linke Pad getrennt und mit und mit VBUS_3V3 verbunden werden:<br />
<br />
<gallery><br />
vbusesp_v01fix_tx_pull.png | Korrekturanleitung<br />
</gallery><br />
<br />
=Bekannte Probleme=<br />
==Fehlerhafter Datenempfang==<br />
<br />
Carsten hat eine interessante Entdeckung bei seinem Aufbau gemacht, untersucht und dann auch gleich eine Lösung gefunden:<br />
<br />
<pre><br />
Nachdem ich den VBus Dekoder programmiert hatte, ist mir aufgefallen, dass die gesamte Kommunikation <br />
sehr stark mit Bitfehlern behaft ist. Nur etwa ein Drittel der VBus Frames kamen unversehrt in der <br />
Software an; das Ende langer Pakete war so gut wie immer kaputt. Wenn ich einen FTDI USB Konverter <br />
hinter den Optokoppler gehängt habe, wurden die Daten fehlerfrei auf dem PC empfangen, also musste <br />
das Problem mit dem ESP zusammenhängen. <br />
<br />
Daher habe ich mir in den UART Treiber einen Debug-Pin eingebaut, der bei jedem Frame-Fehler mein <br />
DSO getriggert hat und das war dann zu sehen:<br />
</pre><br />
<br />
<gallery><br />
Vbusesp_carsten_rx_issue_1.png | Oszi-Screenshot mit defekter und korrekter Nachricht<br />
</gallery><br />
<br />
<pre><br />
Irgendwie hat der ESP RX Eingang unter bestimmten Umständen den Pin so stark nach VCC gezogen, <br />
dass die Pegel kaputt gegangen sind. Warum er das scheinbar nur manchmal macht, ist mir allerdings <br />
noch immer ein Rätsel. Dann weiter im Sourcecode gesucht, wo die Pin-Konfiguration während der <br />
Initialisierung des UART gemacht wird. Hier bin ich dann in der Datei <br />
'core_esp8266_wiring_digital.cpp' fündig geworden:<br />
</pre><br />
<br />
<gallery><br />
Vbusesp_carsten_rx_issue_2.png | Codestelle des Fixes<br />
</gallery><br />
<br />
<pre><br />
Seitdem ich die Zeile 42 unschädlich gemacht habe, läuft die Kommunikation wie geschnitten Brot :-) <br />
Der Debug-Trigger hat auch nach mehreren Stunden nicht mehr zugeschlagen.<br />
Ich muss jetzt noch dazu sagen, dass ich die Software mit PlatformIO entwickele uns ich die <br />
Version 4.0.1 des ESP8266 Platform Package aktuell verwende. Das kann gut sein, dass es mit anderen <br />
IDEs und anderen/älteren Packages nicht passiert, weil der Pullup dort nicht eingeschaltet wird.<br />
</pre><br />
<br />
Wer die Stelle im Repo sucht: [https://github.com/esp8266/Arduino/blob/master/cores/esp8266/core_esp8266_wiring_digital.cpp#L41 hier ist sie].<br />
<br />
Ich bin zwar kein großer Freund, tief in Libs zu patchen, konnte aber nach einem Abend Erstkontakt mit den Tasmota-Sourcen keinen besseren Ort für eine Anpassung finden.<br />
<br />
Bleibt die Frage, warum der Pull-up aktiviert und deaktiviert wird - bei einer (kurzen) Suche ist mir im Code nichts aufgefallen. Kann natürlich sein, dass die CPU selbst das entsprechende Bit setzt/löscht, was aber merkwürdig wäre.<br />
<br />
Bleiben zwei Optionen: entweder selber nochmal forschen oder einen Issue in Github erstellen.<br />
<br />
=Downloads=<br />
* [[Datei:Vbusesp_0.2.zip]] EAGLE-Dateien Adapter v0.2 für den ESP8266<br />
==Archiv==<br />
* [[Datei:Vbusesp_0.1.zip]] EAGLE-Dateien Adapter v0.1 für den ESP8266<br />
<br />
[[Kategorie:ESP8266]]<br />
[[Kategorie:Energieerfassung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:VBus]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=VBus-Decoder&diff=1867VBus-Decoder2023-08-25T20:24:11Z<p>Chris: /* Adapter für den Raspberry Pi */</p>
<hr />
<div>[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]<br />
Bei der Solaranlage meiner Eltern übernimmt ein Viessmann Vitosolic 200 die Regelung. <br />
Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de RESOL DeltaSol® M] handelt.<br />
<br />
Statt der RS-232-Schnittstelle hat das Teil einen Anschluss für den Viessmann-eigenen KM-Bus, zu dem mir keinerlei Informationen bekannt sind.<br />
<br />
Beim VBus sieht es deutlich besser aus. In der [http://www.mikrocontroller.net/topic/96431 Diskussion] auf Mikrocontroller.net bin ich auf den Beitrag von [http://www.mikrocontroller.net/topic/96431#1231974 Daniel Wippermann] gestoßen, woraufhin ich an die angegebene Adresse eine E-Mail geschickt habe. <br />
<br />
Keine zweieinhalb Stunden später habe ich die Dokumentation (inklusive der Erlaubnis zur Veröffentlichung, siehe Download) zum Protokoll erhalten.<br />
<br />
Irgendwann nach der Erstveröffentlichung dieses Artikels entstand eine deutlich erweiterte Dokumentation auf den [https://danielwippermann.github.io/resol-vbus/vbus-specification.html Github-Seiten von Daniel Wippermann]. Nicht nur das, sondern auch eine Implementierung des Protokolls in Javascript.<br />
<br />
=Hardware-Schnittstelle=<br />
[[Bild:Resol sch.png|thumb|Wo Rx und Tx ist, muss erraten werden ;)]]<br />
Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die - entgegen mancher Meinungen - überhaupt keine Ähnlichkeiten mit RS-485 hat.<br />
<br />
'''Bei ein paar Reglern scheint Resol eine RS-485-Schnittstelle mit VBus-Protokoll zu verwenden, die mit den hier vorgestellten Schaltungen nicht kompatibel ist. Bitte vor dem Nachbau der Hardware prüfen, um welches System es sich handelt. Dies kann entweder mit Hilfe des Handbuchs in Erfahrung gebracht werden (Angabe der Spannung und Strom, bei RS-485 ist üblicherweise keine Stromversorgung vorhanden) oder durch Messung ermittelt werden: An den VBus-Klemmen sollte eine (zappelnde) Spannung von ca. 8 V anliegen.'''<br />
<br />
Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2 V und 35 mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen.<br />
Mit der Schaltung auf Seite 5 des PDFs kann auf dem Bus sowohl gelesen, als auch geschrieben werden. Im Bild rechts meine Interpretation der Schaltung (in der noch die Abblockkondensatoren fehlen).<br />
<br />
Über die Buchse links kann man sich mit UART (nicht RS-232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.<br />
<br />
Der in meiner Schaltung verwendete FET für die bidirektionale Kommunikation ist übrigens ein BS170; wobei der Typ nicht kritisch ist, solange er den Bus kurzschließen kann, ohne dabei in Rauch aufzugehen.<br />
<br />
=Protokoll=<br />
Das Protokoll des VBus ist in seiner Version 1.0 ziemlich gut handzuhaben.<br />
<br />
Folgendes Daten habe ich zum Testen verwendet:<br />
<br />
<code><br />
<span class="he0"><span class="hb1">0xAA</span>, <span class="hb2">0x10, 0x00</span>, <span class="hb3">0x21, 0x73</span>, <span class="hb4">0x10</span>, <span class="hb5">0x00, 0x01</span>, <span class="hb6">0x12</span>, <span class="hb7">0x38</span></span>, <br /><br />
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39, <br /><br />
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B, <br /><br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br /><br />
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33, <br /><br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br /><br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37, <br /><br />
0x47, 0x00, 0x00, 0x00, 0x00, 0x38, <br /><br />
0x64, 0x64, 0x00, 0x00, 0x00, 0x37, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br /><br />
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C, <br /><br />
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D, <br /><br />
0x01, 0x03, 0x60, 0x02, 0x04, 0x15, <br /><br />
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D, <br /><br />
</code><br />
<br />
Zu allererst wird ein <span class="he0">10 Byte langer Kopf</span> gesendet, der mit einem eindeutigen <span class="hb1">Sync-Wort (0xAA)</span> beginnt. Eindeutig heißt: An keiner anderen Stelle im Protokoll wird dieses Zeichen verwendet (bzw. das MSB belegt). Man kann sich also zu jedem beliebigen Zeitpunkt in den Bus einklinken!<br />
<br />
Gefolgt vom Sync-Wort kommen <span class="hb2">Ziel-</span> und <span class="hb3">Quelladresse</span> (<span class="hb2">0x0010</span> <= <span class="hb3">0x7321</span>), <span class="hb4">die Protokollversion (0x10)</span>, der <span class="hb5">ausgeführte Befehl (0x0100)</span> und die Anzahl der danach folgenden <span class="hb6">Nutzdatenframes (0x12)</span>. Abschließend wird eine <span class="hb7">Prüfsumme (0x38)</span> der zuvor gesendeten Daten übertragen.<br />
<br />
Im Anschluss an den Header wird die im Header angegebene <span class="hb6">Anzahl an Datenframes</span> mit je 6 Byte Länge geschickt (Auszug von oben):<br />
<br />
<code><br />
<span class="hb1">0x5E, 0x04, 0x5E, 0x01</span>, <span class="hb2">0x05</span>, <span class="hb3">0x39</span>,<br />
</code><br />
<br />
Die ersten 4 enthalten <span class="hb1">Nutzdaten</span>, im 5. wird ein <span class="hb2">Septett</span> geschickt und abschließend erfolgt wieder eine <span class="hb3">Prüfsumme</span>.<br />
<br />
Das Septett ist eine Ergänzung der zuvor gesendeten Nutzdaten. Da, wie oben erwähnt, das MSB nur im Sync-Wort vorkommen darf, ist es für die folgende Daten kein verboten - dieses findet sich jeweils in diesem zusätzlichen Byte.<br />
<br />
Die Prüfsumme der einzelnen Nachrichtenteile wird mittels CRC8 berechnet.<br />
<br />
Das ist auch schon das Gröbste.<br />
Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.<br />
<br />
==Adressen==<br />
Wie in vielen Bussystemen verwendet auch der VBus Pakete für die Nachrichten. Zu den Informationen in der PDF-Spezifikation sei an der Stelle auch auf die [https://danielwippermann.github.io/resol-vbus/#/vsf Paketbeschreibung] verwiesen.<br />
<br />
Die für den bei uns eingesetzten Regler lautet die Adresse 0x7321 (Vitosolic 200 [Regler]), die für das Logging relevanten Daten gehen an 0x0010 und werden in der Dokumentation lediglich als DFA beschrieben. Dabei handelt es sich nicht um eine komische Umschreibung für einen Broadcast, sondern um die Daten für ein zusätzliches Gerät - der Datenfernanzeige.<br />
<br />
An diese sendet der Regler alle von ihm gemessenen Werte. Neben der Regler-Identität hat der Vitosolic 200 noch die Identitäten WMZ1 und WM2 (Wärmemengenzähler).<br />
<br />
=Hardware=<br />
Im Laufe der Zeit haben sich mehrere Schaltungen ergeben. Um diesen Artikel übersichtlich zu halten, wurden die verschiedenen Varianten auf Unterseiten aufgeteilt:<br />
<br />
(Die Links zu den Unterseiten sind befinden sich jeweils in den Überschriften)<br />
<br />
==[[VBus-Decoder/Adapter für RS-232|Adapter für RS-232]]==<br />
Wenn man noch einen PC oder Adapter hat der RS-232 spricht, kann sich dieser Hardware bedienen.<br />
<br />
Der Zugriff ist nur lesend möglich und es gibt keine galvanische Trennung zwischen Bus und DTE.<br />
<br />
<gallery><br />
Bild:Vbus_rxo_brd.png|thumb|Layout der PC-Hardware<br />
</gallery><br />
<br />
==[[VBus-Decoder/Adapter Nano|Adapter Nano]]==<br />
Die vermutlich universellste Variante - schön klein, galvanische Trennung und funktioniert auf der Empfängerseite ab 3,3 V.<br />
<br />
<gallery><br />
resol_nano_0.1_assy.jpg|Bestückte Leiterkarte<br />
</gallery><br />
<br />
==[[VBus-Decoder/Adapter für den Raspberry Pi|Adapter für den Raspberry Pi]]==<br />
Wer Geräte ins Netzwerk bringen will, hat meistens auch einen Einplatinencomputer der Raspberry Pi Foudation auf der Liste.<br />
<br />
<gallery><br />
Vbuspi 1.0 bare.jpg|Unbestückte v1.0-Leiterkarte<br />
Vbuspi 1.1 assy zero.jpg|Bestückte v1.1-Leiterkarte auf einem Raspberry Pi Zero W<br />
Vbuspi_1.3_pers.jpg | v1.3-Bestückte Leiterkarte auf einem Raspberry Pi Zero W<br />
</gallery><br />
<br />
===Versionen===<br />
* [[VBus-Decoder/Adapter für den Raspberry Pi v1.0|Version 1.0/1.1]]: Der erste Versuch - "never trust a x.0"<br />
* [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.2|Version 1.2]]: Besser, aber noch nicht gut<br />
* '''[[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Version 1.3]]: Die beste Version, die man aktuell haben kann ;)'''<br />
<br />
==[[VBus-Decoder/Adapter für den ESP8266|Adapter für den ESP8266]]==<br />
Noch etwas kleiner als für den Raspberry Pi: Ein Adapter mit ESP8266-Modulen.<br />
<br />
<gallery><br />
vbusesp_top.jpg|Bestückte Leiterkarte<br />
</gallery><br />
<br />
==[[VBus-Decoder/Adapter_Nano#Troubleshooting|Troubleshooting]]==<br />
Für die Schaltung des Adapter Nano gibt es eine Troubleshooting-Anleitung, die in Teilen auch für die 5 V-Version der Raspberry-Pi-Variante gültig ist.<br />
<br />
=[[VBus-Decoder/FAQ|FAQ]]=<br />
(bitte auf die Überschrift klicken)<br />
<br />
=Software=<br />
==[[VBus-Decoder/AVR8-Software|AVR8]]==<br />
Zur Datenauswertung und für einfache, zusätzliche, Regelaufgaben (wie zum Beispiel Deaktivieren der Heizung, wenn die Solaranlage den Speicher belädt) - oder um die Anlage ins Internet of Things zu bekommen sind Mikrocontroller sehr geeignete Komponenten.<br />
<br />
Eine Implementierung für die [[VBus-Decoder/AVR8-Software|AVR8-Plattform]] findet sich auf der entsprechenden Unterseite.<br />
<br />
==Python==<br />
Nicki hat sich die Arbeit gemacht und einen Code zum Auswerten der Nachrichten in Python portiert. Ich hatte selbst noch keine gute Gelegenheit, ihn zu testen - daher ohne Garantie, Gewährleistung oder Support:<br />
<br />
* [[Datei:VBus-Python.zip]]<br />
<br />
Oliver hat basierend auf dem Code von Nicki eine Schnittstelle zur [https://www.volkszaehler.org/ Volkszähler]-Middleware gebaut:<br />
<br />
<pre><br />
Der Code nutzt die Resol-Decoder-Lib von Nicki, die ist auch mit dabei.<br />
In der config.py stellt man die Adresse der Middleware in seinem Netzwerk, <br />
sowie die UUID der Kanäle ein, damit man die Daten referenzieren kann.<br />
(Zum Test kann man auch simulierte Daten nutzen, oder die Ausgabe in ein File schreiben lassen)<br />
</pre><br />
<br />
* [[Datei:Vbus_volkszaehler.zip]]<br />
<br />
==Protokoll-Analysator==<br />
<br />
Da es mehrere Anfragen zur Untersuchung des Protokolls gab, habe ich vor einer Weile einen kleinen Protokollanalysator zusammengestrickt. Dieser unterstützt aktuell Protokollversion 1.0 und ist als "gefährliche Beta" anzusehen: [https://hobbyelektronik.org/tools/vbus-analyzer/ Resol Protocol Analyzer]<br />
<br />
=Downloads=<br />
* [[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009<br />
* (Die Downloads für die Hardware befindet sich auf der jeweiligen Unterseite)<br />
<br />
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''<br />
<br />
=Weblinks=<br />
* [http://www.mikrocontroller.net/topic/96431 Diskussion auf Mikrocontroller.net] (gleicher Link wie in der Einleitung)<br />
* [http://www.resol.de RESOL - Elektronische Regelungen GmbH]<br />
* [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de DeltaSol® M] Regler, der dem Viessmann Vitosolic 200 "alt" in ziemlich genau entspricht<br />
* [https://danielwippermann.github.io/resol-vbus Github-Seiten von Daniel Wippermann]<br />
<br />
[[Kategorie:AVR]]<br />
[[Kategorie:Energieerfassung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:VBus]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=VBus-Decoder/Adapter_f%C3%BCr_den_Raspberry_Pi_v1.3&diff=1866VBus-Decoder/Adapter für den Raspberry Pi v1.32023-08-25T20:22:36Z<p>Chris: Bilder hinzugefügt</p>
<hr />
<div>[[Bild:Vbuspi 1.3 pers.jpg|thumb|Aufgebauter Leiterkarte (v1.3)]]<br />
<br />
''Dies ist ein Unterartikel von [[VBus-Decoder]]. Auf der Hauptseite gibt es weitere Informationen zum Thema.''<br />
<br />
=Motivation=<br />
Who's perfect?<br />
<br />
Beim [[VBus-Decoder/Adapter_für_den_Raspberry_Pi|VBus-Adapter für den Raspberry Pi]] (und auch dem [[VBus-Decoder/Adapter_Nano|Nano]]) gibt es ein paar Unzulänglichkeiten, die jeweils ein Makeover der Leiterkarte erfordern.<br />
<br />
Da die Beliebtheit des Raspberry Pis deutlich größer als ein Arghduino für solche Anwendungen ist, gibt es hierfür zuerst (oder überhaupt) eine neue Version.<br />
<br />
Konkret handelt es sich um folgende Probleme, die mit der neuen Version behoben werden sollen:<br />
<br />
* Keine gestapelten Bauteile mehr<br />
* Hinreichend Eingangskapazität für mehr Zuverlässigkeit<br />
* Größere Bauteile zur einfacheren Bestückung<br />
* Rückkanal, um den Regler aktiv abfragen und parametrieren zu können<br />
<br />
=Änderungen=<br />
Aus dem MLCC-Kondensator wurde ein Elektrolyt, aktuell 100 µF, lässt sich bei Bedarf aber noch ein bisschen vergrößern.<br />
<br />
Dieser wird nun über einen Widerstand am Gleichrichter angebunden um den Ladestrom (und dadurch die Spannungseinbrüche auf dem Bus) zu verkleinern.<br />
Ob die Kombination aus 470 Ohm und 100 Mikrofarad gut ist, muss sich noch zeigen.<br />
<br />
Beim Spannungsregler ist der 3,3 V-Typ gekommen um zu bleiben. Dieser bietet neben dem etwas niedrigeren Preis den Vorteil, dass er auf der Eingangsseite einen größeren "Headroom" hat.<br />
<br />
Die Neudimensionierung der Spannungsteiler basiert auf den Berechnungen von [[Adapter_für_den_Raspberry_Pi_v1.2#Die Enttäuschung - Teil 2| Version 1.2b]].<br />
<br />
Als Bestückoption gibt es nun auch einen Jumper, mit dem die Versorgung des Komparators ausgewählt werden kann - sollten die Referenzspannungen nach dem 3,3 V-Regler doch zu knapp werden, kann die Eingangsspannung des LDO verwendet werden. Offen ist natürlich, ob der zu erwartende Ripple in die Suppe spuckt. <br />
<br />
Die diskreten Bauteile sind nun alle im 0805-Package, dadurch wurden weite Teile des Layouts umgeworfen. Wer möchte, kann natürlich auch welche im 0603-Package (oder mit ein bisschen Wollen sollte auch 1206 gehen) auf die Footprints packen.<br />
<br />
Gänzlich neu ist der Rückkanal, die Dimensionierung dessen Bauteile erfolgte mit dem feuchten Finger in den Wind gehalten. Es ist eigentlich nichts besonderes zu erwarten, bei Bedarf kann allerdings einfach mit den Bauteilen gespielt werden. <br />
<br />
Die Änderungen kommen allerdings mit ein paar Kompromissen:<br />
<br />
* Die Leiterkarte wurde ein bisschen größer<br />
* Die Power-LED für den VBus ist rausgefallen (kein Platz, unnötiger Verbraucher)<br />
* Bei der Nutzung des Rückkanals ist...<br />
** die Leiterkarte auf dem Pi Zero nur mit "Überhang" verwendbar<br />
** keine galvanische Trennung möglich<br />
<br />
<gallery><br />
Vbuspi_1.3_assy_sch.png | Schaltplan<br />
Vbuspi_1.3_assy_brd.png | Layout <br />
Vbuspi_1.3_top.jpg | aufgebaute Leiterkarte<br />
</gallery><br />
<br />
=BOM=<br />
<br />
<tabs><br />
<tab name="Optoisoliert"><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 2 || C2, C8 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 3 || R2, R6, R8 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 2 || R9, R28 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330<br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U<br />
|-<br />
| 1 || OK1 || 6N136 || DIL08 || 6N 136 <br />
|-<br />
| 1 || R1 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 1 || Q1 || BSS138 || SOT23 || BSS 138 SMD <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || X2 || RPI_UART+_CONDENSED || RPI_UNIV+_UART || RND 205-00655 <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|-<br />
| 1 || LED1 || or || CHIP-LED0805 || LED EL 0603 OR <br />
|}<br />
<gallery><br />
Vbuspi_1.3_assy_opto_sch.png | Bestückungsplan für optoisolierte Variante<br />
</gallery><br />
</tab><br />
<tab name="Direkt"><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 3 || R10, R11, R15 || 0 || R1206 || RND 0805 1 0 <br />
|-<br />
| 2 || C2, C8 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 5 || R2, R6, R8, R13, R14 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X3 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 1 || R28 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330<br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U<br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 3 || Q1, Q2, Q3 || BSS138 || SOT23 || BSS 138 SMD <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || X2 || RPI_UART+_CONDENSED || RPI_UNIV+_UART || RND 205-00655 <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|-<br />
| 1 || LED1 || or || CHIP-LED0805 || LED EL 0603 OR <br />
|}<br />
<br />
<gallery><br />
Vbuspi_1.3_assy_direct_sch.png | Bestückungsplan für unisolierte Variante<br />
</gallery><br />
</tab><br />
</tabs><br />
<br />
<br />
<br />
=Hinweise=<br />
* '''Bitte nur die Bauteile bestücken, die in der BOM für die jeweilige Variante angegeben sind. Mehr hilft nicht mehr, sondern kann zu Fehlfunktionen führen.'''<br />
* R14 in der Direktvariante sollte nicht bestückt werden oder zumindest in Pull-up-Konfiguration umgebaut werden. Sonst kann (und wird) es passieren, dass der VBus bei nicht angeschlossenem Tx dauerhaft kurzgeschlossen wird. (Danke an Heiko für den Hinweis!)<br />
* R1 sollte einen Wert ab ca. 12k haben, damit der Low-Pegel auch wirklich 0 erreicht.<br />
* Aktuell ist nur die optoisolierte Version getestet<br />
* selbst bei "nur" 1,2 mm dickem FR4 würde ich nicht empfehlen, die Leiterkarte an den perforierten Kanten zu brechen. Besser sägen oder mit einer Trennscheibe arbeiten.<br />
* Nicht vergessen, JMP1 zu bestücken oder zumindest die entsprechende Lötbrücke zu setzen.<br />
<br />
=Leiterkarten=<br />
Es gibt noch unbestückte Leiterkärtchen. Wer eine will, kann sich gerne bei mir melden.<br />
<br />
=Downloads=<br />
* [[Datei:Vbuspi_1.3.zip]] EAGLE-Dateien Adapter v1.3 für den Raspberry Pi<br />
<br />
[[Kategorie:Raspberry Pi]]<br />
[[Kategorie:Energieerfassung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:VBus]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Vbuspi_1.3_pers.jpg&diff=1864Datei:Vbuspi 1.3 pers.jpg2023-08-25T20:19:27Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Vbuspi_1.3_top.jpg&diff=1865Datei:Vbuspi 1.3 top.jpg2023-08-25T20:19:27Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Hobbyelektronik.org:Impressum&diff=1863Hobbyelektronik.org:Impressum2023-06-17T21:05:33Z<p>Chris: /* Urheberrecht */</p>
<hr />
<div>=Angaben gemäß § 5 TMG=<br />
<br />
Diese Homepage wird betrieben durch:<br />
<br />
Christof Rueß<br /><br />
St.-Wendelin-Str. 9<br /><br />
89264 Weißenhorn<br /><br />
<br />
==Kontakt==<br />
Bei Fragen bitte per E-Mail an mich wenden:<br />
<br />
E-Mail: chris at hobbyelektronik punkt org<br />
<br />
For those who don't speak German: feel free to write me in English! Für Zuschriften auf deutsch: Das "du" wird bevorzugt :)<br />
<br />
Im Normalfall antworte ich innerhalb von 1-3 Tagen. Solltest du innerhalb einer Woche keine Antwort bekommen, prüfe bitte deinen Spamfilter oder schicke eine Erinnerung, manchmal geht auch bei mir etwas unter.<br />
<br />
E-Mail via GPG: chris-crypt at hobbyelektronik punkt org [//hobbyelektronik.org/chris-crypt.asc Public Key]<br />
<br />
Bitte beachten: Wie die meisten bin ich kein aktiver Mailcrypto-User, zumal seit der Einrichtung im Schnitt nur eine Konversation in 2-3 Jahren verschlüsselt stattfindet. Die Wahrscheinlichkeit ist groß, dass ich erst mal wieder die Toolchain installieren und mich an das Passwort erinnern muss...<br />
<br />
Sollte E-Mail zur Kommunikation nicht ausreichen, kann auch eine Telefonnummer angefragt werden. Sollte dies nicht zwingend erforderlich sein, bitte ich jedoch Abstand davon zu nehmen.<br />
<br />
=Kommerzielle Anfragen=<br />
In den meisten Fällen lautet die Antwort schlicht "Nein". <br />
<br />
Wie weiter unten steht habe ich kein Interesse an Werbung oder "kommerzieller Kooperation". Entsprechende Anfragen werden ignoriert.<br />
<br />
Auch habe ich wenig Interesse, in meiner Freizeit an kommerziellen Projekten oder Produkten zu arbeiten. Dazu fehlen mir einfach Zeit und Ressourcen. Nicht unbedingt technisch, sondern vielmehr organisatorisch. Produkte auf den Markt zu bringen ist deutlich mehr als Hardware zusammenzuklatschen und vielleicht noch "ein bisschen" Software dafür zu entwickeln.<br />
<br />
=Fragen/Hilfe/Unterstützung=<br />
Bevor du eine Mail schreibst, bitte folgendes lesen und beachten:<br />
<br />
Ich mache das hier in meiner Freizeit und aus Spaß.<br />
<br />
Sollte es zu den Artikeln auf diesen Seiten Fragen, Hinweise oder Anmerkungen geben, freue ich mich über jede Mail. Genauso helfe ich - soweit es meine Zeit erlaubt - gerne, wenn es Probleme beim Auf- oder Nachbau oder Anpassung der hier vorgestellten Projekte gibt.<br />
<br />
Bitte jedoch zwei Dinge nicht zu verwechseln: Freie Hard-/Software und Freibier.<br />
<br />
Mir geht es darum, Wissen zu vermitteln und dich vorwärts zu bringen und nicht, dass du etwas "abgreifen" kannst.<br />
<br />
Ich kann dich nur unterstützen wenn du mir hilfst, dein Problem zu verstehen. Ich kenne dein Setup sowie die verfügbaren Mittel in aller Regel nicht und kann auch deine Fähigkeiten aus der Ferne meist nur sehr grob einschätzen.<br />
<br />
Deshalb ist es wichtig, dass du deinen Aufbau genau beschreibst (keine Salamitaktik!), meine Mails komplett liest und alle Fragen so weit wie möglich beantwortest - und nicht schon nach der ersten aufhörst und auf "Senden" drückst. Wenn etwas unklar ist, einfach nochmal nachfragen.<br />
<br />
Sollte ich merken, dass wenig eigene Motivation besteht, Probleme zu verstehen oder selbst an der Lösung (mit) zu arbeiten, werde ich meine Motivation dementsprechend anpassen.<br />
<br />
Bitte auch keine Mails im Messenger-Stil. Die E-Mail ruhig mal 5 Minuten länger offen lassen und noch nicht direkt losschicken statt nacheinander 3 Mails, die jeweils nur einen Punkt umfasst. Die Antwort kommt deswegen nicht schneller (im Gegenteil, solche Mails bleiben eher länger liegen). Bitte verwende Satzzeichen und diese idealerweise auch an der richtigen Stelle (siehe [[wpde:Plenk|Plenk]]).<br />
<br />
Bitte auch selbst kritisch denken. Jeder macht Fehler und je nach Tageszeit werden sie bei mir auch mal mehr. Versteh es einfach als Kompetenzübung und beachte den Haftungsausschluss.<br />
<br />
=Werbung=<br />
Was vielen auf dieser Homepage dank Werbeblocker wahrscheinlich gar nicht auffällt: Es gibt keine Werbung.<br />
<br />
Ich hab zwar schon ein-/zweimal mit dem Gedanken gespielt, welche zu schalten aber komme dann immer wieder auf einen Punkt zurück: ich/wir machen das aus Spaß und Werbung hat (zumindest bei mir) einen kommerziellen Charakter oder zumindest schalen Beigeschmack – das möchte ich nicht.<br />
<br />
Auch habe ich mittlerweile schon ein paar Mailanfragen für Kooperationen und „Sponsored Posts“ bekommen, auf die ich – obwohl es natürlich verlockend ist – nicht eingehe. Zum Einen aus den oben genannten Gründen, zum Anderen möchte ich das Ganze hier möglichst ehrlich und authentisch (mit allen Vor- und Nachteilen) halten.<br />
<br />
Heißt: ich vertrete meine Meinung und nicht die anderer. Wenn hier im Blog, im Wiki oder sonstwo steht, dass etwas toll oder bescheiden ist, handelt es sich um eine persönliche Meinung. Die muss zwar nicht unbedingt richtig sein, aber es wurde zumindest nichts durch finanzielle Mittel beeinflusst.<br />
<br />
=Spenden=<br />
Obwohl das Internet (auch oder vor allem im privaten Bereich - siehe "Influencer") immer kommerzieller wird, wird man beim genaueren Blick ins Blog oder ins Wiki bzw. hier im Impressum sehen: ich möchte hier ausdrücklich kein Geld verdienen.<br />
<br />
Als hier im Impressum der Hinweis für Agenturen bereits war und sie trotzdem geschrieben haben, habe ich immer wieder geantwortet, dass sie das Geld auch einem sinnvollen gemeinnützigen Verein spenden sollen. Passiert ist natürlich nichts. Auch wenn es wahrscheinlich nur verschwendete Zeit war: ich wollte zumindest nicht nichts tun.<br />
<br />
Die hier vorgestellten Basteleien, die Pflege der Homepage und alles andere darum ist Hobby - und per definitionem schließt das ein Einkommen aus. Nicht umsonst heißt es: "mit größtmöglichem Aufwand den kleinstmöglichen Nutzen erzielen".<br />
<br />
Da mich diejenigen, denen ich “übrige“ Leiterkarten der verschiedenen Basteleien hier geschickt habe fragten, wohin sie mir Geld überweisen sollen, konnte ich nur antworten, dass ich aufgrund verschiedener Umstände gar nicht annehmen darf (und will).<br />
<br />
Um jedoch trotzdem das 'schlechte Gewissen' zu beruhigen, entstand folgende Idee: Wer von mir etwas bekommt (oder was ich mache gut findet) ist aufgerufen einen Betrag - nach eigenem Ermessen - an eine sinnvolle gemeinnützige Organisation spenden.<br />
<br />
So entsteht eine ″Win-Win-Win-Situation″: Ich werde meine Leiterkarten los, der Empfänger bekommt etwas zu Basteln und gemeinsam wird auch noch etwas Gutes getan.<br />
<br />
Wer mir also etwas Gutes tun möchte: Spende an eine Organisation, die du für gut hältst, der Betrag ist mir egal, ich freue mich aber über (gerne auch anonymisierte) Spendenquittungen. Wenn du möchtest, kannst du auch auf q.hobbyelektronik.org/spenden verweisen. <br />
<br />
'''Bei den Leiterkarten möchte ich jedoch darauf hinweisen: Die fallen nicht vom Baum, auch kostet der Versand etwas.'''<br />
<br />
Wichtig ist mir, dass das Geld auch ankommt und möglichst wenig in der Verwaltung hängen bleibt.<br />
<br />
Wer überhaupt keine Idee hat wohin: Lokale (Kinder-)Hospize und (Kinder-)Palliativ-Stationen sind stark auf Spenden angewiesen.<br />
<br />
Wenn es technisch sein soll: Kleinere Hackerspaces oder Gruppen wie Freifunk sind auf Spenden angewiesen.<br />
<br />
Absolut richtig zu spenden ist natürlich nicht einfach, dennoch bitte ich folgendes in Erwägung zu ziehen´:<br />
<br />
* Einen etwas schalen Beigeschmack hatte ich bei einer Spende an die dt. Krеbshilfe, die offenbar nicht wenig ihrer Einnahmen in Werbung und „Bettelbriefe“ steckt.<br />
* Fragwürdig halte ich ebenfalls ΡeTA, die eher durch Desinformation und mittlerweile auch Verleumdungsvorwürfe auffallen.<br />
* Bitte von Spenden an die kath. Kіrche und deren Organisationen in meinem Namen Abstand nehmen, solange sie:<br />
** Ihre Finanzen nicht offenlegen<br />
** Sich stark durch den Staat finanzieren lassen, aber trotzdem das Sagen haben (und dabei durchaus diskriminieren)<br />
** Missbrauch tolerieren, billigen, vertuschen, nicht vernünftig aufarbeiten und sogar Strafverfolgung behindern<br />
** Frauen nicht gleichberechtigen<br />
** ...<br />
<br />
(Ich weiß: "aber, aber, aber..." - bitte nicht falsch verstehen: jeder darf und soll glauben was möchte, für mich sind Glaube und Κirche unterschiedliche Dinge.)<br />
<br />
=Nutzung von Inhalten=<br />
Wie in der Fußzeile zu sehen ist, unterliegen die Inhalte (sofern nicht anders angegeben) der Creative Commons-Lizenz [https://creativecommons.org/licenses/by-nc-sa/3.0/deed.de BY-NC-SA 3.0]. Inhalte dürfen also ausdrücklich unter Namensnennung (vorzugsweise einem Link auf hobbyelektronik.org) für nichtkommerzielle Angebote verwendet werden.<br />
<br />
Für die Verwendung in kommerziellen Angeboten ist vorab bitte Kontakt (siehe oben) mit dem Seitenbetreiber aufzunehmen.<br />
<br />
Eine direkte Einbindung der Ressourcen dieser Website (zum Beispiel Bilder mit <code>src="//hobbyelektronik.org/..."</code>) auf Fremdseiten ist nicht erwünscht und sollte daher unterlassen werden.<br />
Ausnahmen hierfür sind: RSS-Feeds oder persönliche Aggregatoren sowie Suchmaschinen, deren Zweck das Auffinden von Inhalten ist.<br />
<br />
=Haftungsausschluss=<br />
==Haftung für Inhalte==<br />
Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
Die auf dieser Homepage bereitgestellten Inhalte wurden nach bestem Wissen und Gewissen erarbeitet und recherchiert. Trotzdem können Fehler nicht ausgeschlossen werden und daher keine Garantie auf Vollständigkeit und Korrektheit der bereitgestellten Informationen gegeben.<br />
<br />
Ferner wird keine Haftung für direkte und indirekte Schäden übernommen, die durch das Lesen oder das Auf- bzw. Nachbauen von Schaltungen und Aufbauten oder deren Inbetriebnahme bzw. das Nachstellen von beschriebenen Vorgehensweisen oder Techniken entstehen können.<br />
<br />
Dies gilt insbesondere für Schaltungen oder Anordnungen, die für den Menschen gefährliche Einflussgrößen wie zum Beispiel elektrischen Strom, Spannungen, Chemikalien oder Strahlungen erfordern oder hervorbringen.<br />
<br />
==Haftung für Links==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
==Urheberrecht==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind ohne weitere Genehmigung nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
==Lizenz==<br />
Alle vom Seitenbetreiber erstellten Inhalte unterliegen, soweit nicht anders gekennzeichnet, der Lizenz Creative Commons - [https://creativecommons.org/licenses/by-nc-sa/3.0/de/ Attribution-NonCommercial-ShareAlike 3.0] (kurz: CC BY-NC-SA 3.0). <br />
<br />
=Datenschutzerklärung=<br />
==Datenschutz==<br />
Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung.<br />
<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Auf die Einbindung von Ressourcen von Drittservern wird bewusst vermieden und soweit wie möglich unterbunden, kann jedoch technisch nicht vollständig ausgeschlossen werden.<br />
<br />
Diese Homepage deren Dienste werden durch die "Hetzner Online GmbH" gehostet. Der Betreiber dieser Homepage hat keinen Einfluss auf Technik, Datenschutz und Datenintegrität des Hosters.<br />
<br />
==Cookies==<br />
Die Internetseiten verwenden teilweise so genannte Cookies. Cookies sind kleine Textdateien, die auf Ihrem Rechner abgelegt werden und die Ihr Browser speichert. Sie dienen dazu, unser Angebot nutzerfreundlicher, effektiver und sicherer zu machen.<br />
<br />
Die meisten der von uns verwendeten Cookies sind so genannte „Session-Cookies“. Sie werden nach Ende Ihres Besuchs automatisch gelöscht. Andere Cookies bleiben auf Ihrem Endgerät gespeichert, bis Sie diese löschen. Diese Cookies ermöglichen es uns, Ihren Browser beim nächsten Besuch wiederzuerkennen.<br />
<br />
Sie können Ihren Browser so einstellen, dass Sie über das Setzen von Cookies informiert werden und Cookies nur im Einzelfall erlauben, die Annahme von Cookies für bestimmte Fälle oder generell ausschließen sowie das automatische Löschen der Cookies beim Schließen des Browser aktivieren. Bei der Deaktivierung von Cookies kann die Funktionalität dieser Website eingeschränkt sein.<br />
<br />
==Server-Log-Files==<br />
Der Provider der Seiten erhebt und speichert automatisch Informationen in so genannten Server-Log Files, die Ihr Browser automatisch an uns übermittelt. Dies sind:<br />
<br />
* IP-Adresse<br />
* Username für Authentifikation<br />
* Uhrzeit der Serveranfrage<br />
* Methode der Anfrage (GET/POST/...)<br />
* Abgerufener Pfad und Query<br />
* Protokollversion<br />
* Statuscode des Servers<br />
* Ausgelieferte Dateigröße<br />
* Referrer URL<br />
* User Agent des verwendeten Browsers<br />
<br />
Diese Daten sind nicht bestimmten Personen zuordenbar. Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen. Wir behalten uns vor, diese Daten nachträglich zu prüfen, wenn uns konkrete Anhaltspunkte für eine rechtswidrige Nutzung bekannt werden.<br />
<br />
Ferner werden durch den Hoster Statistiken erstellt, die in aller Regel nur für diesen und den Betreiber der Website einsehbar sind. <br />
<br />
Die erfassten Daten werden - je nach verfügbarem Speicherplatz - zeitlich unbegrenzt gespeichert.<br />
<br />
==Kommentarfunktion==<br />
Einige Teile dieser Homepage ermöglichen das Hinzufügen von Kommentaren durch Besucher. Die dort vertretenen Aussagen und Meinungen entsprechen nicht zwangsläufig denen des Betreibers der Seite. Zum Zwecke der Vermeidung von Werbung, Spam und niedrigem Niveau findet eine Moderation der Kommentare statt. Sofern nötig behält sich der Betreiber das Recht vor, Wörter oder Textpassagen (unter Kenntlichmachung) zu entfernen. <br />
<br />
Zu diesem Zweck werden, neben den über das Formular eingegebene Daten, folgende Informationen dauerhaft gespeichert:<br />
<br />
* IP-Adresse<br />
* Datum und Uhrzeit<br />
* Browsertyp/Browserversion<br />
<br />
==E-Mails==<br />
E-Mails werden sowohl auf dem Mailserver als auch auf den Clients der Nutzer dieser Seite vorgehalten. Dies kann sowohl für ein- als auch ausgehende Nachrichten zeitlich begrenzt aber auch unbegrenzt erfolgen. Die Regelaufbewahrungszeit auf dem Server beträgt, sofern abgerufen, 30 Tage. Auf den Mailclients können die Nachrichten zeitlich unbegrenzt gespeichert, archiviert und in Backups gesichert werden.<br />
<br />
Durch den Kommunikationspartner angegebene Daten können ebenfalls dauerhaft und in schweigender Zustimmung in Adressbüchern abgelegt werden. Eine Datenhaltung in "Cloud-Diensten" wird ausdrücklich vermieden, kann aber nicht vollständig ausgeschlossen werden.<br />
<br />
Sollte eine dauerhafte Speicherung von Nachrichten nicht gewünscht sein, sind diese jeweils durch den Text "**NOARCHIVE**" im Betreff zu kennzeichnen. Ein späterer Bezug auf diese Nachrichten ist dann verständlicherweise nicht mehr möglich.<br />
<br />
Durch einen Befall durch Schadsoftware auf einen der genutzten Endgeräten kann es zum Versand von unerwünschten Nachrichten kommen. Bei Kenntniserlangung werden umgehend Abstellmaßnahmen eingeleitet und - soweit technisch möglich - die Empfänger dieser Nachrichten gewarnt.<br />
<br />
==Verschlüsselung==<br />
Diese Homepage wird vorzugsweise über HTTPS/TLS ausgeliefert. Ein Downgrade auf HTTP ist möglich, kann aber zu Darstellungsfehlern führen.<br />
<br />
Der Mailtransport über TLS wird angeboten, zusätzlich ist eine Mailverschlüsselung auf Basis von GPG (siehe oben) möglich.<br />
<br />
Quelle e-recht24.de (angepasst)</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Hobbyelektronik.org:Impressum&diff=1862Hobbyelektronik.org:Impressum2023-06-17T21:03:29Z<p>Chris: /* Kontakt */</p>
<hr />
<div>=Angaben gemäß § 5 TMG=<br />
<br />
Diese Homepage wird betrieben durch:<br />
<br />
Christof Rueß<br /><br />
St.-Wendelin-Str. 9<br /><br />
89264 Weißenhorn<br /><br />
<br />
==Kontakt==<br />
Bei Fragen bitte per E-Mail an mich wenden:<br />
<br />
E-Mail: chris at hobbyelektronik punkt org<br />
<br />
For those who don't speak German: feel free to write me in English! Für Zuschriften auf deutsch: Das "du" wird bevorzugt :)<br />
<br />
Im Normalfall antworte ich innerhalb von 1-3 Tagen. Solltest du innerhalb einer Woche keine Antwort bekommen, prüfe bitte deinen Spamfilter oder schicke eine Erinnerung, manchmal geht auch bei mir etwas unter.<br />
<br />
E-Mail via GPG: chris-crypt at hobbyelektronik punkt org [//hobbyelektronik.org/chris-crypt.asc Public Key]<br />
<br />
Bitte beachten: Wie die meisten bin ich kein aktiver Mailcrypto-User, zumal seit der Einrichtung im Schnitt nur eine Konversation in 2-3 Jahren verschlüsselt stattfindet. Die Wahrscheinlichkeit ist groß, dass ich erst mal wieder die Toolchain installieren und mich an das Passwort erinnern muss...<br />
<br />
Sollte E-Mail zur Kommunikation nicht ausreichen, kann auch eine Telefonnummer angefragt werden. Sollte dies nicht zwingend erforderlich sein, bitte ich jedoch Abstand davon zu nehmen.<br />
<br />
=Kommerzielle Anfragen=<br />
In den meisten Fällen lautet die Antwort schlicht "Nein". <br />
<br />
Wie weiter unten steht habe ich kein Interesse an Werbung oder "kommerzieller Kooperation". Entsprechende Anfragen werden ignoriert.<br />
<br />
Auch habe ich wenig Interesse, in meiner Freizeit an kommerziellen Projekten oder Produkten zu arbeiten. Dazu fehlen mir einfach Zeit und Ressourcen. Nicht unbedingt technisch, sondern vielmehr organisatorisch. Produkte auf den Markt zu bringen ist deutlich mehr als Hardware zusammenzuklatschen und vielleicht noch "ein bisschen" Software dafür zu entwickeln.<br />
<br />
=Fragen/Hilfe/Unterstützung=<br />
Bevor du eine Mail schreibst, bitte folgendes lesen und beachten:<br />
<br />
Ich mache das hier in meiner Freizeit und aus Spaß.<br />
<br />
Sollte es zu den Artikeln auf diesen Seiten Fragen, Hinweise oder Anmerkungen geben, freue ich mich über jede Mail. Genauso helfe ich - soweit es meine Zeit erlaubt - gerne, wenn es Probleme beim Auf- oder Nachbau oder Anpassung der hier vorgestellten Projekte gibt.<br />
<br />
Bitte jedoch zwei Dinge nicht zu verwechseln: Freie Hard-/Software und Freibier.<br />
<br />
Mir geht es darum, Wissen zu vermitteln und dich vorwärts zu bringen und nicht, dass du etwas "abgreifen" kannst.<br />
<br />
Ich kann dich nur unterstützen wenn du mir hilfst, dein Problem zu verstehen. Ich kenne dein Setup sowie die verfügbaren Mittel in aller Regel nicht und kann auch deine Fähigkeiten aus der Ferne meist nur sehr grob einschätzen.<br />
<br />
Deshalb ist es wichtig, dass du deinen Aufbau genau beschreibst (keine Salamitaktik!), meine Mails komplett liest und alle Fragen so weit wie möglich beantwortest - und nicht schon nach der ersten aufhörst und auf "Senden" drückst. Wenn etwas unklar ist, einfach nochmal nachfragen.<br />
<br />
Sollte ich merken, dass wenig eigene Motivation besteht, Probleme zu verstehen oder selbst an der Lösung (mit) zu arbeiten, werde ich meine Motivation dementsprechend anpassen.<br />
<br />
Bitte auch keine Mails im Messenger-Stil. Die E-Mail ruhig mal 5 Minuten länger offen lassen und noch nicht direkt losschicken statt nacheinander 3 Mails, die jeweils nur einen Punkt umfasst. Die Antwort kommt deswegen nicht schneller (im Gegenteil, solche Mails bleiben eher länger liegen). Bitte verwende Satzzeichen und diese idealerweise auch an der richtigen Stelle (siehe [[wpde:Plenk|Plenk]]).<br />
<br />
Bitte auch selbst kritisch denken. Jeder macht Fehler und je nach Tageszeit werden sie bei mir auch mal mehr. Versteh es einfach als Kompetenzübung und beachte den Haftungsausschluss.<br />
<br />
=Werbung=<br />
Was vielen auf dieser Homepage dank Werbeblocker wahrscheinlich gar nicht auffällt: Es gibt keine Werbung.<br />
<br />
Ich hab zwar schon ein-/zweimal mit dem Gedanken gespielt, welche zu schalten aber komme dann immer wieder auf einen Punkt zurück: ich/wir machen das aus Spaß und Werbung hat (zumindest bei mir) einen kommerziellen Charakter oder zumindest schalen Beigeschmack – das möchte ich nicht.<br />
<br />
Auch habe ich mittlerweile schon ein paar Mailanfragen für Kooperationen und „Sponsored Posts“ bekommen, auf die ich – obwohl es natürlich verlockend ist – nicht eingehe. Zum Einen aus den oben genannten Gründen, zum Anderen möchte ich das Ganze hier möglichst ehrlich und authentisch (mit allen Vor- und Nachteilen) halten.<br />
<br />
Heißt: ich vertrete meine Meinung und nicht die anderer. Wenn hier im Blog, im Wiki oder sonstwo steht, dass etwas toll oder bescheiden ist, handelt es sich um eine persönliche Meinung. Die muss zwar nicht unbedingt richtig sein, aber es wurde zumindest nichts durch finanzielle Mittel beeinflusst.<br />
<br />
=Spenden=<br />
Obwohl das Internet (auch oder vor allem im privaten Bereich - siehe "Influencer") immer kommerzieller wird, wird man beim genaueren Blick ins Blog oder ins Wiki bzw. hier im Impressum sehen: ich möchte hier ausdrücklich kein Geld verdienen.<br />
<br />
Als hier im Impressum der Hinweis für Agenturen bereits war und sie trotzdem geschrieben haben, habe ich immer wieder geantwortet, dass sie das Geld auch einem sinnvollen gemeinnützigen Verein spenden sollen. Passiert ist natürlich nichts. Auch wenn es wahrscheinlich nur verschwendete Zeit war: ich wollte zumindest nicht nichts tun.<br />
<br />
Die hier vorgestellten Basteleien, die Pflege der Homepage und alles andere darum ist Hobby - und per definitionem schließt das ein Einkommen aus. Nicht umsonst heißt es: "mit größtmöglichem Aufwand den kleinstmöglichen Nutzen erzielen".<br />
<br />
Da mich diejenigen, denen ich “übrige“ Leiterkarten der verschiedenen Basteleien hier geschickt habe fragten, wohin sie mir Geld überweisen sollen, konnte ich nur antworten, dass ich aufgrund verschiedener Umstände gar nicht annehmen darf (und will).<br />
<br />
Um jedoch trotzdem das 'schlechte Gewissen' zu beruhigen, entstand folgende Idee: Wer von mir etwas bekommt (oder was ich mache gut findet) ist aufgerufen einen Betrag - nach eigenem Ermessen - an eine sinnvolle gemeinnützige Organisation spenden.<br />
<br />
So entsteht eine ″Win-Win-Win-Situation″: Ich werde meine Leiterkarten los, der Empfänger bekommt etwas zu Basteln und gemeinsam wird auch noch etwas Gutes getan.<br />
<br />
Wer mir also etwas Gutes tun möchte: Spende an eine Organisation, die du für gut hältst, der Betrag ist mir egal, ich freue mich aber über (gerne auch anonymisierte) Spendenquittungen. Wenn du möchtest, kannst du auch auf q.hobbyelektronik.org/spenden verweisen. <br />
<br />
'''Bei den Leiterkarten möchte ich jedoch darauf hinweisen: Die fallen nicht vom Baum, auch kostet der Versand etwas.'''<br />
<br />
Wichtig ist mir, dass das Geld auch ankommt und möglichst wenig in der Verwaltung hängen bleibt.<br />
<br />
Wer überhaupt keine Idee hat wohin: Lokale (Kinder-)Hospize und (Kinder-)Palliativ-Stationen sind stark auf Spenden angewiesen.<br />
<br />
Wenn es technisch sein soll: Kleinere Hackerspaces oder Gruppen wie Freifunk sind auf Spenden angewiesen.<br />
<br />
Absolut richtig zu spenden ist natürlich nicht einfach, dennoch bitte ich folgendes in Erwägung zu ziehen´:<br />
<br />
* Einen etwas schalen Beigeschmack hatte ich bei einer Spende an die dt. Krеbshilfe, die offenbar nicht wenig ihrer Einnahmen in Werbung und „Bettelbriefe“ steckt.<br />
* Fragwürdig halte ich ebenfalls ΡeTA, die eher durch Desinformation und mittlerweile auch Verleumdungsvorwürfe auffallen.<br />
* Bitte von Spenden an die kath. Kіrche und deren Organisationen in meinem Namen Abstand nehmen, solange sie:<br />
** Ihre Finanzen nicht offenlegen<br />
** Sich stark durch den Staat finanzieren lassen, aber trotzdem das Sagen haben (und dabei durchaus diskriminieren)<br />
** Missbrauch tolerieren, billigen, vertuschen, nicht vernünftig aufarbeiten und sogar Strafverfolgung behindern<br />
** Frauen nicht gleichberechtigen<br />
** ...<br />
<br />
(Ich weiß: "aber, aber, aber..." - bitte nicht falsch verstehen: jeder darf und soll glauben was möchte, für mich sind Glaube und Κirche unterschiedliche Dinge.)<br />
<br />
=Nutzung von Inhalten=<br />
Wie in der Fußzeile zu sehen ist, unterliegen die Inhalte (sofern nicht anders angegeben) der Creative Commons-Lizenz [https://creativecommons.org/licenses/by-nc-sa/3.0/deed.de BY-NC-SA 3.0]. Inhalte dürfen also ausdrücklich unter Namensnennung (vorzugsweise einem Link auf hobbyelektronik.org) für nichtkommerzielle Angebote verwendet werden.<br />
<br />
Für die Verwendung in kommerziellen Angeboten ist vorab bitte Kontakt (siehe oben) mit dem Seitenbetreiber aufzunehmen.<br />
<br />
Eine direkte Einbindung der Ressourcen dieser Website (zum Beispiel Bilder mit <code>src="//hobbyelektronik.org/..."</code>) auf Fremdseiten ist nicht erwünscht und sollte daher unterlassen werden.<br />
Ausnahmen hierfür sind: RSS-Feeds oder persönliche Aggregatoren sowie Suchmaschinen, deren Zweck das Auffinden von Inhalten ist.<br />
<br />
=Haftungsausschluss=<br />
==Haftung für Inhalte==<br />
Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
Die auf dieser Homepage bereitgestellten Inhalte wurden nach bestem Wissen und Gewissen erarbeitet und recherchiert. Trotzdem können Fehler nicht ausgeschlossen werden und daher keine Garantie auf Vollständigkeit und Korrektheit der bereitgestellten Informationen gegeben.<br />
<br />
Ferner wird keine Haftung für direkte und indirekte Schäden übernommen, die durch das Lesen oder das Auf- bzw. Nachbauen von Schaltungen und Aufbauten oder deren Inbetriebnahme bzw. das Nachstellen von beschriebenen Vorgehensweisen oder Techniken entstehen können.<br />
<br />
Dies gilt insbesondere für Schaltungen oder Anordnungen, die für den Menschen gefährliche Einflussgrößen wie zum Beispiel elektrischen Strom, Spannungen, Chemikalien oder Strahlungen erfordern oder hervorbringen.<br />
<br />
==Haftung für Links==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
==Urheberrecht==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
==Lizenz==<br />
Alle vom Seitenbetreiber erstellten Inhalte unterliegen, soweit nicht anders gekennzeichnet, der Lizenz Creative Commons - [https://creativecommons.org/licenses/by-nc-sa/3.0/de/ Attribution-NonCommercial-ShareAlike 3.0] (kurz: CC BY-NC-SA 3.0). <br />
<br />
=Datenschutzerklärung=<br />
==Datenschutz==<br />
Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung.<br />
<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Auf die Einbindung von Ressourcen von Drittservern wird bewusst vermieden und soweit wie möglich unterbunden, kann jedoch technisch nicht vollständig ausgeschlossen werden.<br />
<br />
Diese Homepage deren Dienste werden durch die "Hetzner Online GmbH" gehostet. Der Betreiber dieser Homepage hat keinen Einfluss auf Technik, Datenschutz und Datenintegrität des Hosters.<br />
<br />
==Cookies==<br />
Die Internetseiten verwenden teilweise so genannte Cookies. Cookies sind kleine Textdateien, die auf Ihrem Rechner abgelegt werden und die Ihr Browser speichert. Sie dienen dazu, unser Angebot nutzerfreundlicher, effektiver und sicherer zu machen.<br />
<br />
Die meisten der von uns verwendeten Cookies sind so genannte „Session-Cookies“. Sie werden nach Ende Ihres Besuchs automatisch gelöscht. Andere Cookies bleiben auf Ihrem Endgerät gespeichert, bis Sie diese löschen. Diese Cookies ermöglichen es uns, Ihren Browser beim nächsten Besuch wiederzuerkennen.<br />
<br />
Sie können Ihren Browser so einstellen, dass Sie über das Setzen von Cookies informiert werden und Cookies nur im Einzelfall erlauben, die Annahme von Cookies für bestimmte Fälle oder generell ausschließen sowie das automatische Löschen der Cookies beim Schließen des Browser aktivieren. Bei der Deaktivierung von Cookies kann die Funktionalität dieser Website eingeschränkt sein.<br />
<br />
==Server-Log-Files==<br />
Der Provider der Seiten erhebt und speichert automatisch Informationen in so genannten Server-Log Files, die Ihr Browser automatisch an uns übermittelt. Dies sind:<br />
<br />
* IP-Adresse<br />
* Username für Authentifikation<br />
* Uhrzeit der Serveranfrage<br />
* Methode der Anfrage (GET/POST/...)<br />
* Abgerufener Pfad und Query<br />
* Protokollversion<br />
* Statuscode des Servers<br />
* Ausgelieferte Dateigröße<br />
* Referrer URL<br />
* User Agent des verwendeten Browsers<br />
<br />
Diese Daten sind nicht bestimmten Personen zuordenbar. Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen. Wir behalten uns vor, diese Daten nachträglich zu prüfen, wenn uns konkrete Anhaltspunkte für eine rechtswidrige Nutzung bekannt werden.<br />
<br />
Ferner werden durch den Hoster Statistiken erstellt, die in aller Regel nur für diesen und den Betreiber der Website einsehbar sind. <br />
<br />
Die erfassten Daten werden - je nach verfügbarem Speicherplatz - zeitlich unbegrenzt gespeichert.<br />
<br />
==Kommentarfunktion==<br />
Einige Teile dieser Homepage ermöglichen das Hinzufügen von Kommentaren durch Besucher. Die dort vertretenen Aussagen und Meinungen entsprechen nicht zwangsläufig denen des Betreibers der Seite. Zum Zwecke der Vermeidung von Werbung, Spam und niedrigem Niveau findet eine Moderation der Kommentare statt. Sofern nötig behält sich der Betreiber das Recht vor, Wörter oder Textpassagen (unter Kenntlichmachung) zu entfernen. <br />
<br />
Zu diesem Zweck werden, neben den über das Formular eingegebene Daten, folgende Informationen dauerhaft gespeichert:<br />
<br />
* IP-Adresse<br />
* Datum und Uhrzeit<br />
* Browsertyp/Browserversion<br />
<br />
==E-Mails==<br />
E-Mails werden sowohl auf dem Mailserver als auch auf den Clients der Nutzer dieser Seite vorgehalten. Dies kann sowohl für ein- als auch ausgehende Nachrichten zeitlich begrenzt aber auch unbegrenzt erfolgen. Die Regelaufbewahrungszeit auf dem Server beträgt, sofern abgerufen, 30 Tage. Auf den Mailclients können die Nachrichten zeitlich unbegrenzt gespeichert, archiviert und in Backups gesichert werden.<br />
<br />
Durch den Kommunikationspartner angegebene Daten können ebenfalls dauerhaft und in schweigender Zustimmung in Adressbüchern abgelegt werden. Eine Datenhaltung in "Cloud-Diensten" wird ausdrücklich vermieden, kann aber nicht vollständig ausgeschlossen werden.<br />
<br />
Sollte eine dauerhafte Speicherung von Nachrichten nicht gewünscht sein, sind diese jeweils durch den Text "**NOARCHIVE**" im Betreff zu kennzeichnen. Ein späterer Bezug auf diese Nachrichten ist dann verständlicherweise nicht mehr möglich.<br />
<br />
Durch einen Befall durch Schadsoftware auf einen der genutzten Endgeräten kann es zum Versand von unerwünschten Nachrichten kommen. Bei Kenntniserlangung werden umgehend Abstellmaßnahmen eingeleitet und - soweit technisch möglich - die Empfänger dieser Nachrichten gewarnt.<br />
<br />
==Verschlüsselung==<br />
Diese Homepage wird vorzugsweise über HTTPS/TLS ausgeliefert. Ein Downgrade auf HTTP ist möglich, kann aber zu Darstellungsfehlern führen.<br />
<br />
Der Mailtransport über TLS wird angeboten, zusätzlich ist eine Mailverschlüsselung auf Basis von GPG (siehe oben) möglich.<br />
<br />
Quelle e-recht24.de (angepasst)</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Hobbyelektronik.org:Impressum&diff=1861Hobbyelektronik.org:Impressum2023-06-17T21:01:34Z<p>Chris: </p>
<hr />
<div>=Angaben gemäß § 5 TMG=<br />
<br />
Diese Homepage wird betrieben durch:<br />
<br />
Christof Rueß<br /><br />
St.-Wendelin-Str. 9<br /><br />
89264 Weißenhorn<br /><br />
<br />
==Kontakt==<br />
Bei Fragen bitte per E-Mail an mich wenden:<br />
<br />
E-Mail: chris at hobbyelektronik punkt org<br />
<br />
For those who don't speak German: feel free to write me in English! Für Zuschriften auf deutsch: Das "du" wird bevorzugt :)<br />
<br />
Im Normalfall antworte ich innerhalb von 1-3 Tagen. Solltest du innerhalb einer Woche keine Antwort bekommen, prüfe bitte deinen Spamfilter oder schicke eine Erinnerung, manchmal geht auch bei mir etwas unter.<br />
<br />
E-Mail via GPG: chris-crypt at hobbyelektronik punkt org [//hobbyelektronik.org/chris-crypt.asc Public Key] (oder auf sks-keyservers.net suchen)<br />
<br />
Bitte beachten: Wie die meisten bin ich kein aktiver Mailcrypto-User, zumal seit der Einrichtung im Schnitt nur eine Konversation in 2-3 Jahren verschlüsselt stattfindet. Die Wahrscheinlichkeit ist groß, dass ich erst mal wieder die Toolchain installieren und mich an das Passwort erinnern muss...<br />
<br />
Sollte E-Mail zur Kommunikation nicht ausreichen, kann auch eine Telefonnummer angefragt werden. Sollte dies nicht zwingend erforderlich sein, bitte ich jedoch Abstand davon zu nehmen.<br />
<br />
=Kommerzielle Anfragen=<br />
In den meisten Fällen lautet die Antwort schlicht "Nein". <br />
<br />
Wie weiter unten steht habe ich kein Interesse an Werbung oder "kommerzieller Kooperation". Entsprechende Anfragen werden ignoriert.<br />
<br />
Auch habe ich wenig Interesse, in meiner Freizeit an kommerziellen Projekten oder Produkten zu arbeiten. Dazu fehlen mir einfach Zeit und Ressourcen. Nicht unbedingt technisch, sondern vielmehr organisatorisch. Produkte auf den Markt zu bringen ist deutlich mehr als Hardware zusammenzuklatschen und vielleicht noch "ein bisschen" Software dafür zu entwickeln.<br />
<br />
=Fragen/Hilfe/Unterstützung=<br />
Bevor du eine Mail schreibst, bitte folgendes lesen und beachten:<br />
<br />
Ich mache das hier in meiner Freizeit und aus Spaß.<br />
<br />
Sollte es zu den Artikeln auf diesen Seiten Fragen, Hinweise oder Anmerkungen geben, freue ich mich über jede Mail. Genauso helfe ich - soweit es meine Zeit erlaubt - gerne, wenn es Probleme beim Auf- oder Nachbau oder Anpassung der hier vorgestellten Projekte gibt.<br />
<br />
Bitte jedoch zwei Dinge nicht zu verwechseln: Freie Hard-/Software und Freibier.<br />
<br />
Mir geht es darum, Wissen zu vermitteln und dich vorwärts zu bringen und nicht, dass du etwas "abgreifen" kannst.<br />
<br />
Ich kann dich nur unterstützen wenn du mir hilfst, dein Problem zu verstehen. Ich kenne dein Setup sowie die verfügbaren Mittel in aller Regel nicht und kann auch deine Fähigkeiten aus der Ferne meist nur sehr grob einschätzen.<br />
<br />
Deshalb ist es wichtig, dass du deinen Aufbau genau beschreibst (keine Salamitaktik!), meine Mails komplett liest und alle Fragen so weit wie möglich beantwortest - und nicht schon nach der ersten aufhörst und auf "Senden" drückst. Wenn etwas unklar ist, einfach nochmal nachfragen.<br />
<br />
Sollte ich merken, dass wenig eigene Motivation besteht, Probleme zu verstehen oder selbst an der Lösung (mit) zu arbeiten, werde ich meine Motivation dementsprechend anpassen.<br />
<br />
Bitte auch keine Mails im Messenger-Stil. Die E-Mail ruhig mal 5 Minuten länger offen lassen und noch nicht direkt losschicken statt nacheinander 3 Mails, die jeweils nur einen Punkt umfasst. Die Antwort kommt deswegen nicht schneller (im Gegenteil, solche Mails bleiben eher länger liegen). Bitte verwende Satzzeichen und diese idealerweise auch an der richtigen Stelle (siehe [[wpde:Plenk|Plenk]]).<br />
<br />
Bitte auch selbst kritisch denken. Jeder macht Fehler und je nach Tageszeit werden sie bei mir auch mal mehr. Versteh es einfach als Kompetenzübung und beachte den Haftungsausschluss.<br />
<br />
=Werbung=<br />
Was vielen auf dieser Homepage dank Werbeblocker wahrscheinlich gar nicht auffällt: Es gibt keine Werbung.<br />
<br />
Ich hab zwar schon ein-/zweimal mit dem Gedanken gespielt, welche zu schalten aber komme dann immer wieder auf einen Punkt zurück: ich/wir machen das aus Spaß und Werbung hat (zumindest bei mir) einen kommerziellen Charakter oder zumindest schalen Beigeschmack – das möchte ich nicht.<br />
<br />
Auch habe ich mittlerweile schon ein paar Mailanfragen für Kooperationen und „Sponsored Posts“ bekommen, auf die ich – obwohl es natürlich verlockend ist – nicht eingehe. Zum Einen aus den oben genannten Gründen, zum Anderen möchte ich das Ganze hier möglichst ehrlich und authentisch (mit allen Vor- und Nachteilen) halten.<br />
<br />
Heißt: ich vertrete meine Meinung und nicht die anderer. Wenn hier im Blog, im Wiki oder sonstwo steht, dass etwas toll oder bescheiden ist, handelt es sich um eine persönliche Meinung. Die muss zwar nicht unbedingt richtig sein, aber es wurde zumindest nichts durch finanzielle Mittel beeinflusst.<br />
<br />
=Spenden=<br />
Obwohl das Internet (auch oder vor allem im privaten Bereich - siehe "Influencer") immer kommerzieller wird, wird man beim genaueren Blick ins Blog oder ins Wiki bzw. hier im Impressum sehen: ich möchte hier ausdrücklich kein Geld verdienen.<br />
<br />
Als hier im Impressum der Hinweis für Agenturen bereits war und sie trotzdem geschrieben haben, habe ich immer wieder geantwortet, dass sie das Geld auch einem sinnvollen gemeinnützigen Verein spenden sollen. Passiert ist natürlich nichts. Auch wenn es wahrscheinlich nur verschwendete Zeit war: ich wollte zumindest nicht nichts tun.<br />
<br />
Die hier vorgestellten Basteleien, die Pflege der Homepage und alles andere darum ist Hobby - und per definitionem schließt das ein Einkommen aus. Nicht umsonst heißt es: "mit größtmöglichem Aufwand den kleinstmöglichen Nutzen erzielen".<br />
<br />
Da mich diejenigen, denen ich “übrige“ Leiterkarten der verschiedenen Basteleien hier geschickt habe fragten, wohin sie mir Geld überweisen sollen, konnte ich nur antworten, dass ich aufgrund verschiedener Umstände gar nicht annehmen darf (und will).<br />
<br />
Um jedoch trotzdem das 'schlechte Gewissen' zu beruhigen, entstand folgende Idee: Wer von mir etwas bekommt (oder was ich mache gut findet) ist aufgerufen einen Betrag - nach eigenem Ermessen - an eine sinnvolle gemeinnützige Organisation spenden.<br />
<br />
So entsteht eine ″Win-Win-Win-Situation″: Ich werde meine Leiterkarten los, der Empfänger bekommt etwas zu Basteln und gemeinsam wird auch noch etwas Gutes getan.<br />
<br />
Wer mir also etwas Gutes tun möchte: Spende an eine Organisation, die du für gut hältst, der Betrag ist mir egal, ich freue mich aber über (gerne auch anonymisierte) Spendenquittungen. Wenn du möchtest, kannst du auch auf q.hobbyelektronik.org/spenden verweisen. <br />
<br />
'''Bei den Leiterkarten möchte ich jedoch darauf hinweisen: Die fallen nicht vom Baum, auch kostet der Versand etwas.'''<br />
<br />
Wichtig ist mir, dass das Geld auch ankommt und möglichst wenig in der Verwaltung hängen bleibt.<br />
<br />
Wer überhaupt keine Idee hat wohin: Lokale (Kinder-)Hospize und (Kinder-)Palliativ-Stationen sind stark auf Spenden angewiesen.<br />
<br />
Wenn es technisch sein soll: Kleinere Hackerspaces oder Gruppen wie Freifunk sind auf Spenden angewiesen.<br />
<br />
Absolut richtig zu spenden ist natürlich nicht einfach, dennoch bitte ich folgendes in Erwägung zu ziehen´:<br />
<br />
* Einen etwas schalen Beigeschmack hatte ich bei einer Spende an die dt. Krеbshilfe, die offenbar nicht wenig ihrer Einnahmen in Werbung und „Bettelbriefe“ steckt.<br />
* Fragwürdig halte ich ebenfalls ΡeTA, die eher durch Desinformation und mittlerweile auch Verleumdungsvorwürfe auffallen.<br />
* Bitte von Spenden an die kath. Kіrche und deren Organisationen in meinem Namen Abstand nehmen, solange sie:<br />
** Ihre Finanzen nicht offenlegen<br />
** Sich stark durch den Staat finanzieren lassen, aber trotzdem das Sagen haben (und dabei durchaus diskriminieren)<br />
** Missbrauch tolerieren, billigen, vertuschen, nicht vernünftig aufarbeiten und sogar Strafverfolgung behindern<br />
** Frauen nicht gleichberechtigen<br />
** ...<br />
<br />
(Ich weiß: "aber, aber, aber..." - bitte nicht falsch verstehen: jeder darf und soll glauben was möchte, für mich sind Glaube und Κirche unterschiedliche Dinge.)<br />
<br />
=Nutzung von Inhalten=<br />
Wie in der Fußzeile zu sehen ist, unterliegen die Inhalte (sofern nicht anders angegeben) der Creative Commons-Lizenz [https://creativecommons.org/licenses/by-nc-sa/3.0/deed.de BY-NC-SA 3.0]. Inhalte dürfen also ausdrücklich unter Namensnennung (vorzugsweise einem Link auf hobbyelektronik.org) für nichtkommerzielle Angebote verwendet werden.<br />
<br />
Für die Verwendung in kommerziellen Angeboten ist vorab bitte Kontakt (siehe oben) mit dem Seitenbetreiber aufzunehmen.<br />
<br />
Eine direkte Einbindung der Ressourcen dieser Website (zum Beispiel Bilder mit <code>src="//hobbyelektronik.org/..."</code>) auf Fremdseiten ist nicht erwünscht und sollte daher unterlassen werden.<br />
Ausnahmen hierfür sind: RSS-Feeds oder persönliche Aggregatoren sowie Suchmaschinen, deren Zweck das Auffinden von Inhalten ist.<br />
<br />
=Haftungsausschluss=<br />
==Haftung für Inhalte==<br />
Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
Die auf dieser Homepage bereitgestellten Inhalte wurden nach bestem Wissen und Gewissen erarbeitet und recherchiert. Trotzdem können Fehler nicht ausgeschlossen werden und daher keine Garantie auf Vollständigkeit und Korrektheit der bereitgestellten Informationen gegeben.<br />
<br />
Ferner wird keine Haftung für direkte und indirekte Schäden übernommen, die durch das Lesen oder das Auf- bzw. Nachbauen von Schaltungen und Aufbauten oder deren Inbetriebnahme bzw. das Nachstellen von beschriebenen Vorgehensweisen oder Techniken entstehen können.<br />
<br />
Dies gilt insbesondere für Schaltungen oder Anordnungen, die für den Menschen gefährliche Einflussgrößen wie zum Beispiel elektrischen Strom, Spannungen, Chemikalien oder Strahlungen erfordern oder hervorbringen.<br />
<br />
==Haftung für Links==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
==Urheberrecht==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
==Lizenz==<br />
Alle vom Seitenbetreiber erstellten Inhalte unterliegen, soweit nicht anders gekennzeichnet, der Lizenz Creative Commons - [https://creativecommons.org/licenses/by-nc-sa/3.0/de/ Attribution-NonCommercial-ShareAlike 3.0] (kurz: CC BY-NC-SA 3.0). <br />
<br />
=Datenschutzerklärung=<br />
==Datenschutz==<br />
Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung.<br />
<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Auf die Einbindung von Ressourcen von Drittservern wird bewusst vermieden und soweit wie möglich unterbunden, kann jedoch technisch nicht vollständig ausgeschlossen werden.<br />
<br />
Diese Homepage deren Dienste werden durch die "Hetzner Online GmbH" gehostet. Der Betreiber dieser Homepage hat keinen Einfluss auf Technik, Datenschutz und Datenintegrität des Hosters.<br />
<br />
==Cookies==<br />
Die Internetseiten verwenden teilweise so genannte Cookies. Cookies sind kleine Textdateien, die auf Ihrem Rechner abgelegt werden und die Ihr Browser speichert. Sie dienen dazu, unser Angebot nutzerfreundlicher, effektiver und sicherer zu machen.<br />
<br />
Die meisten der von uns verwendeten Cookies sind so genannte „Session-Cookies“. Sie werden nach Ende Ihres Besuchs automatisch gelöscht. Andere Cookies bleiben auf Ihrem Endgerät gespeichert, bis Sie diese löschen. Diese Cookies ermöglichen es uns, Ihren Browser beim nächsten Besuch wiederzuerkennen.<br />
<br />
Sie können Ihren Browser so einstellen, dass Sie über das Setzen von Cookies informiert werden und Cookies nur im Einzelfall erlauben, die Annahme von Cookies für bestimmte Fälle oder generell ausschließen sowie das automatische Löschen der Cookies beim Schließen des Browser aktivieren. Bei der Deaktivierung von Cookies kann die Funktionalität dieser Website eingeschränkt sein.<br />
<br />
==Server-Log-Files==<br />
Der Provider der Seiten erhebt und speichert automatisch Informationen in so genannten Server-Log Files, die Ihr Browser automatisch an uns übermittelt. Dies sind:<br />
<br />
* IP-Adresse<br />
* Username für Authentifikation<br />
* Uhrzeit der Serveranfrage<br />
* Methode der Anfrage (GET/POST/...)<br />
* Abgerufener Pfad und Query<br />
* Protokollversion<br />
* Statuscode des Servers<br />
* Ausgelieferte Dateigröße<br />
* Referrer URL<br />
* User Agent des verwendeten Browsers<br />
<br />
Diese Daten sind nicht bestimmten Personen zuordenbar. Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen. Wir behalten uns vor, diese Daten nachträglich zu prüfen, wenn uns konkrete Anhaltspunkte für eine rechtswidrige Nutzung bekannt werden.<br />
<br />
Ferner werden durch den Hoster Statistiken erstellt, die in aller Regel nur für diesen und den Betreiber der Website einsehbar sind. <br />
<br />
Die erfassten Daten werden - je nach verfügbarem Speicherplatz - zeitlich unbegrenzt gespeichert.<br />
<br />
==Kommentarfunktion==<br />
Einige Teile dieser Homepage ermöglichen das Hinzufügen von Kommentaren durch Besucher. Die dort vertretenen Aussagen und Meinungen entsprechen nicht zwangsläufig denen des Betreibers der Seite. Zum Zwecke der Vermeidung von Werbung, Spam und niedrigem Niveau findet eine Moderation der Kommentare statt. Sofern nötig behält sich der Betreiber das Recht vor, Wörter oder Textpassagen (unter Kenntlichmachung) zu entfernen. <br />
<br />
Zu diesem Zweck werden, neben den über das Formular eingegebene Daten, folgende Informationen dauerhaft gespeichert:<br />
<br />
* IP-Adresse<br />
* Datum und Uhrzeit<br />
* Browsertyp/Browserversion<br />
<br />
==E-Mails==<br />
E-Mails werden sowohl auf dem Mailserver als auch auf den Clients der Nutzer dieser Seite vorgehalten. Dies kann sowohl für ein- als auch ausgehende Nachrichten zeitlich begrenzt aber auch unbegrenzt erfolgen. Die Regelaufbewahrungszeit auf dem Server beträgt, sofern abgerufen, 30 Tage. Auf den Mailclients können die Nachrichten zeitlich unbegrenzt gespeichert, archiviert und in Backups gesichert werden.<br />
<br />
Durch den Kommunikationspartner angegebene Daten können ebenfalls dauerhaft und in schweigender Zustimmung in Adressbüchern abgelegt werden. Eine Datenhaltung in "Cloud-Diensten" wird ausdrücklich vermieden, kann aber nicht vollständig ausgeschlossen werden.<br />
<br />
Sollte eine dauerhafte Speicherung von Nachrichten nicht gewünscht sein, sind diese jeweils durch den Text "**NOARCHIVE**" im Betreff zu kennzeichnen. Ein späterer Bezug auf diese Nachrichten ist dann verständlicherweise nicht mehr möglich.<br />
<br />
Durch einen Befall durch Schadsoftware auf einen der genutzten Endgeräten kann es zum Versand von unerwünschten Nachrichten kommen. Bei Kenntniserlangung werden umgehend Abstellmaßnahmen eingeleitet und - soweit technisch möglich - die Empfänger dieser Nachrichten gewarnt.<br />
<br />
==Verschlüsselung==<br />
Diese Homepage wird vorzugsweise über HTTPS/TLS ausgeliefert. Ein Downgrade auf HTTP ist möglich, kann aber zu Darstellungsfehlern führen.<br />
<br />
Der Mailtransport über TLS wird angeboten, zusätzlich ist eine Mailverschlüsselung auf Basis von GPG (siehe oben) möglich.<br />
<br />
Quelle e-recht24.de (angepasst)</div>Chrishttps://hobbyelektronik.org/w/index.php?title=VBus-Decoder/Adapter_f%C3%BCr_den_ESP8266&diff=1860VBus-Decoder/Adapter für den ESP82662023-06-17T21:00:15Z<p>Chris: /* Decoder */</p>
<hr />
<div>[[Bild:vbusesp_top.jpg|thumb|Aufgebauter Leiterkarte (v0.1)]]<br />
''Dies ist ein Unterartikel von [[VBus-Decoder]]. Auf der Hauptseite gibt es weitere Informationen zum Thema.''<br />
<br />
=Motivation=<br />
Wenn Basteln und IoT aufeinandertreffen, kommt man fast nicht an den Mikrocontrollern von Espressif vorbei.<br />
<br />
Genau aus diesem Grund hatte ich schon länger die Idee, ein Leiterkärtchen mit dem ESP8266 zu machen. Also warum nicht einfach den beliebten VBus ohne großes Strippenziehen ins Netzwerk bringen?<br />
<br />
=Schaltung=<br />
Die Schaltung für den VBus basiert auf der für den [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Raspi (v1.3)]], aufseiten des ESP habe ich mich von den verschiedenen Bastelboards inspirieren lassen und die Möglichkeit vorgesehen, sowohl die kleinen ESP01- als auch die etwas vielseitigeren ESP12-Module einzusetzen.<br />
<br />
Die Versorgung findet über eine Stiftleiste (bzw. angelötete Drähte) oder über eine Micro-USB-Buchse statt. <br />
Diese dient nur der Stromversorgung - mehr zum Programmieren des ESP weiter unten.<br />
<br />
Bei der Verwendung des ESP12-Moduls stehen zusätzlich zum VBus-Interface noch die GPIOs 12, 13, 14 und 16 sowie der ADC-Eingang und die 3,3V-Versorgung zur Verfügung. Hier kann weitere Peripherie wie Sensoren oder Displays angeschlossen werden.<br />
<br />
Für den Aufbau gibt es mehrere Varianten, die unten aufgeführt sind. Diese können über die Tabs ausgewählt und müssen beim Besorgen der Bauteile und selbstverständlich beim Zusammenbau kombiniert werden.<br />
<br />
Die theoretische Maximalbestückung sieht wie folgt aus:<br />
<br />
<gallery><br />
vbusesp_max_sch_1.png | Schaltplan VBus + Stromversorgung<br />
vbusesp_max_sch_2.png | Schaltplan ESP8266 und IO<br />
vbusesp_max_assy.png | Bestückungsplan<br />
</gallery><br />
<br />
=BOM=<br />
Möglichkeiten schaffen Komplexität. Wie bei den anderen Plattformen lässt sich der Adapter in verschiedenen Varianten aufbauen, wobei ich (auch wenn es gerade bei dieser anbietet) noch immer empfehle, die Optoisolierte aufzubauen.<br />
<br />
==Decoder==<br />
Neben Optoisoliert und Direkt gibt es noch die Variante ohne ESP - dank der Stiftleiste rechts oben auf der Leiterkarte lässt sich der VBus-Anteil komplett unabhängig vom ESP-Anteil verwenden. Mit Säge und Fingerspitzengefühl lässt sich die Größe auch noch ein gutes Stück reduzieren.<br />
<br />
Als ESP8266-Modul kann das ESP01 und ESP12(-F) verwendet werden. Getestet wurde bis jetzt nur das ESP12-F, wobei nichts gegen das 01 sprechen dürfte.<br />
<br />
<tabs><br />
<tab name="Optoisoliert"><br />
Empfohlene Bestückungsvariante.<br />
<gallery><br />
vbusesp_optiso_sch_1.png | Variantenschaltplan VBus<br />
vbusesp_optiso_sch_2.png | Variantenschaltplan ESP8266<br />
vbusesp_optiso_assy.png | Bestückungsplan<br />
</gallery><br />
<br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || SV4 || || MA05-2 || MPE 087-2-010 <br />
|-<br />
| 1 || SV3 || || MA07-1R || MPE 087-1-007 <br />
|-<br />
| 1 || JMP1 || 0R-JUMPA || A0R-JMP || RND 0805 1 0 <br />
|-<br />
| 1 || C11 || 100n || C0603 || X7R-G0603 100N <br />
|-<br />
| 3 || C2, C8, C14 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 4 || R18, R19, R22, R24 || 10k || R0805 || RND 0805 1 10K <br />
|-<br />
| 1 || R1 || 12k || R0805 || RND 1550805 DP <br />
|-<br />
| 3 || R2, R6, R8 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 5 || R9, R20, R21, R25, R28 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330 <br />
|-<br />
| 1 || C10 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U <br />
|-<br />
| 1 || OK1 || 6N136 || DIL08 || 6N 136 <br />
|-<br />
| 1 || S1 || 9305 || PHAP3301 || TASTER 9305 <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 2 || T1, T2 || BC848 || SOT23 || BC 848B SMD <br />
|-<br />
| 1 || U2 || ESP01 || ESP01 || DEBO ESP8266 <br />
|-<br />
| 1 || U1 || ESP12 || ESP12-SMD || DEBO ESP8266-12F <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|-<br />
| 1 || LED1 || or || CHIP-LED0805 || LED EL 0603 OR <br />
|}<br />
</tab><br />
<tab name="Direkt"><br />
<gallery><br />
vbusesp_direct_sch_1.png | Variantenschaltplan VBus<br />
vbusesp_direct_sch_2.png | Variantenschaltplan ESP8266<br />
vbusesp_direct_assy.png | Bestückungsplan<br />
</gallery><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || SV4 || || MA05-2 || MPE 087-2-010 <br />
|-<br />
| 1 || SV3 || || MA07-1R || MPE 087-1-007 <br />
|-<br />
| 3 || R10, R11, R15 || 0 || R1206 || RND 0805 1 0 <br />
|-<br />
| 1 || JMP1 || 0R-JUMPA || A0R-JMP || RND 0805 1 0 <br />
|-<br />
| 1 || C11 || 100n || C0603 || X7R-G0603 100N <br />
|-<br />
| 3 || C2, C8, C14 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 4 || R18, R19, R22, R24 || 10k || R0805 || RND 0805 1 10K <br />
|-<br />
| 5 || R2, R6, R8, R13, R14 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 4 || R20, R21, R25, R28 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330 <br />
|-<br />
| 1 || C10 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U <br />
|-<br />
| 1 || S1 || 9305 || PHAP3301 || TASTER 9305 <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 2 || T1, T2 || BC848 || SOT23 || BC 848B SMD <br />
|-<br />
| 2 || Q2, Q3 || BSS138 || SOT23 || BSS 138 SMD <br />
|-<br />
| 1 || U2 || ESP01 || ESP01 || DEBO ESP8266 <br />
|-<br />
| 1 || U1 || ESP12 || ESP12-SMD || DEBO ESP8266-12F <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|-<br />
| 1 || LED1 || or || CHIP-LED0805 || LED EL 0603 OR <br />
|}<br />
</tab><br />
<tab name="Optoisoliert (ohne ESP)"><br />
Wer keinen ESP8266 verwenden aber die Vorzüge der verbesserten Schaltung haben möchte, kann den ESP-Anteil vollständig weglassen.<br />
<br />
Hierfür wird auf dieser Leiterkarte keine Stromversorgung benötigt, da diese vom jeweilig verwendeten Interface (z. B. SBC, USB-UART-Wandler, ...) bezogen werden kann.<br />
<gallery><br />
vbusesp_optisonoesp_sch_1.png | Variantenschaltplan VBus<br />
vbusesp_optisonoesp_sch_2.png | Variantenschaltplan Interface<br />
vbusesp_optisonoesp_assy.png | Bestückungsplan<br />
vbusesp_vbusonly_pinout.png | Anschlussbelegung des UART<br />
</gallery><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || SV4 || || MA05-2 || MPE 087-2-010 <br />
|-<br />
| 1 || JMP1 || 0R-JUMPA || A0R-JMP || RND 0805 1 0 <br />
|-<br />
| 2 || C2, C8 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C6 || 100p || C0805 || NPO-G0805 100P <br />
|-<br />
| 1 || C5 || 100u/16V || PANASONIC_D || VF 100/16 K-D <br />
|-<br />
| 1 || R1 || 12k || R0805 || RND 1550805 DP <br />
|-<br />
| 3 || R2, R6, R8 || 15k || R0805 || RND 0805 1 15K <br />
|-<br />
| 1 || X1 || 1751248 || 1751248 || AKL 059-02 <br />
|-<br />
| 1 || R9 || 1k || R0805 || RND 0805 1 1,0K <br />
|-<br />
| 1 || C4 || 1n || C0805 || NPO-G0805 1,0N <br />
|-<br />
| 2 || R4, R7 || 2k2 || R0805 || RND 0805 1 2,2K <br />
|-<br />
| 1 || R12 || 330 || R0805 || RND 0805 1 330 <br />
|-<br />
| 2 || R3, R5 || 4k7 || R0805 || RND 0805 1 4,7K <br />
|-<br />
| 1 || C3 || 4u7 || C0805 || KEM X5R0805 4,7U <br />
|-<br />
| 1 || OK1 || 6N136 || DIL08 || 6N 136 <br />
|-<br />
| 3 || D1, D2, D5 || BAV99 || SOT23 || BAV 99 NXP <br />
|-<br />
| 1 || IC4 || LM393D || SO08 || LM 393 D SMD <br />
|-<br />
| 1 || D3 || P6SMB 15A || SMBJ || P6SMB 15A SMD <br />
|-<br />
| 1 || IC1 || TS5205CX533 || SOT23-5 || TS 5205 CX533 <br />
|}<br />
</tab><br />
</tabs><br />
Egal welche Variante aufgebaut wird: bitte nicht vergessen, den Jumper (statt des 0R-Widerstandes kann auch eine Lötbrücke gesetzt werden) zu löten.<br />
<br />
==Stromversorgung==<br />
Für die Stromversorgung gibt es ebenfalls zwei Möglichkeiten: Entweder mit LDO oder Schaltwandler. Wer auf Nummer sicher gehen will, nimmt die billigere LDO-Variante, da ich noch keine Gelegenheit hatte letztere zu testen. Die etwas höhere Stromaufnahme dürfte wahrscheinlich nicht allzu sehr ins Gewicht fallen.<br />
<br />
<tabs><br />
<tab name="Linearregler"><br />
Empfohlene Bestückungsvariante.<br />
<br />
<gallery><br />
vbusesp_vregldo_sch_1.png | Variantenschaltplan Stromversorgung<br />
vbusesp_vregldo_assy.png | Bestückungsplan<br />
</gallery><br />
<br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || J1 || || JUMP || JUMPER 2,54 SW <br />
|-<br />
| 1 || C15 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C13 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 1 || SV2 || MA02-1R || MA02-1R || MPE 087-1-002 <br />
|-<br />
| 1 || X2 || MIUSB-F5M-BB-UHS || MIUSB-F5M-BB-U_HANDSOLDER || MIC USB BBU <br />
|-<br />
| 1 || IC3 || REG1117 || SOT223 || NCP 1117 ST33T3G <br />
|}<br />
</tab><br />
<tab name="Schaltwandler"><br />
<gallery><br />
vbusesp_vregsmps_sch_1.png | Variantenschaltplan Stromversorgung<br />
vbusesp_vregsmps_assy.png | Bestückungsplan<br />
</gallery><br />
{| class="wikitable"<br />
! Menge || Referenzen || Wert || Package || Reichelt Bestellcode<br />
|-<br />
| 1 || C9 || 100n || C0603 || X7R-G0603 100N <br />
|-<br />
| 1 || C15 || 100n || C0805 || X7R-G0805 100N <br />
|-<br />
| 1 || C12 || 10p || C0603 || NPO-G0603 10P <br />
|-<br />
| 1 || R17 || 15k || R0603 || RND 0603 1 15K <br />
|-<br />
| 1 || L1 || 15u || 242408FPS || L-242408FPS 15µ <br />
|-<br />
| 1 || R16 || 47k || R0603 || RND 0603 1 47K <br />
|-<br />
| 1 || C13 || 47u/16V || PANASONIC_D || FK-V 47U 16 <br />
|-<br />
| 1 || D6 || BAT43WS || SOD323-W || BAT 43WS <br />
|-<br />
| 1 || SV2 || MA02-1R || MA02-1R || MPE 087-1-002 <br />
|-<br />
| 1 || IC2 || MCP16301 || SOT23-6 || MCP 16301T-I/CHY <br />
|-<br />
| 1 || X2 || MIUSB-F5M-BB-UHS || MIUSB-F5M-BB-U_HANDSOLDER || MIC USB BBU <br />
|-<br />
| 1 || D4 || SS13L || SUBSMA || SS 13L <br />
|}<br />
</tab><br />
</tabs><br />
<br />
=Inbetriebnahme/Benutzung=<br />
==Flashing==<br />
Wird ein ESP8266 verwendet, muss natürlich erst einmal die Software auf den Mikrocontroller.<br />
<br />
Das Problem: Der Softwaredownload findet über den selben UART statt, der auch für das VBus-Interface statt.<br />
Nun könnte man mit Multiplexern arbeiten, was im Idealfall nur einmal benutzt werden würde und somit mit Kanonen auf Spatzen geschossen wäre. Aus dem gleichen Grund gibt es keinen USB-UART-Konverter auf dem Board: Braucht nur Platz und kostet.<br />
<br />
Deshalb wird für das erstmalige Flashen ein USB-UART-Adapter, der RTS/DTR anbietet, benötigt. Dieser sollte idealerweise mit 3,3 V arbeite, wobei der ESP wohl auch 5 V toleriert. Die beiden Transistoren für Reset und Bootloader nach WittyCloud/NodeMCU sind bereits vorhanden.<br />
<br />
Die 5 V-Stromversorgung muss entweder über den USB-Port oder der Stiftleiste SV2 kommen, die Anschlussbelegung des UART an SV4 ist wie folgt:<br />
<br />
{| class="wikitable"<br />
! Pin || Signal vom UART-Adapter<br />
|-<br />
| 1 || DTR<br />
|-<br />
| 3 || TX<br />
|-<br />
| 7 || RX<br />
|-<br />
| 9 || RTS<br />
|}<br />
<br />
<gallery><br />
vbusesp_prog_1.png | Anschlussbelegung für das Programmieren per UART<br />
vbusesp_prog_2.jpg | Verwendung des WittyCloud-USB-Wandlers<br />
</gallery><br />
<br />
Liegt das Trägerboard eines WittyCloud herum, müssen DTR und RTS gefädelt werden.<br />
<br />
==Betrieb==<br />
Ist die Firmware auf dem Chip und es sollen Daten vom VBus decodiert werden, muss ein Jumper zwischen Pin 3 und 4 an SV4 oder ein Lötpunkt auf SJ1 gesetzt werden:<br />
<br />
<gallery><br />
vbusesp_txjumper.png | UART-Verbindung zwischen VBus und ESP8266<br />
</gallery><br />
<br />
=Firmware=<br />
Zugegebenermaßen: ich habe zwar seit Jahren ein paar ESP8266-Module herumliegen, mich aber nie so richtig damit auseinandergesetzt.<br />
<br />
Aber das macht nichts: [https://tasmota.github.io/docs/ Tasmota] unterstützt verschiedene [https://tasmota.github.io/docs/Smart-Meter-Interface/ Smart Metering]-Anbindungen, für die die Firmware allerdings angepasst selbst kompiliert werden muss.<br />
<br />
Michael hat sich (mit der Unterstützung aus der Tasmota-Community) daran gemacht und freundlicherweise die nötigen Anpassungen zur Verfügung gestellt:<br />
<br />
Folgendes muss in der Datei <code>tasmota/user_config_override.h</code> ergänzt werden:<br />
<source lang="C"><br />
#ifndef _USER_CONFIG_OVERRIDE_H_<br />
#define _USER_CONFIG_OVERRIDE_H_<br />
<br />
#ifndef USE_SCRIPT<br />
#define USE_SCRIPT<br />
#endif<br />
#ifndef USE_SML_M<br />
#define USE_SML_M<br />
#endif<br />
#ifdef USE_RULES<br />
#undef USE_RULES<br />
#endif<br />
#ifndef SML_REPLACE_VARS<br />
#define SML_REPLACE_VARS<br />
#endif<br />
#ifndef USE_SML_SCRIPT_CMD<br />
#define USE_SML_SCRIPT_CMD<br />
#endif<br />
#ifndef SML_MAX_VARS<br />
#define SML_MAX_VARS 20<br />
#endif<br />
#ifndef USE_SCRIPT_JSON_EXPORT<br />
#define USE_SCRIPT_JSON_EXPORT<br />
#endif<br />
#ifndef USE_SCRIPT_WEB_DISPLAY<br />
#define USE_SCRIPT_WEB_DISPLAY<br />
#endif<br />
</source><br />
<br />
==Konfiguration==<br />
Nach dem Flashen des Mikrocontrollers, was für fertige Builds auch über den Tasmotizer erfolgen kann, kann unter <code>Main-Menu -> Console -> Edit Script</code> das [https://tasmota.github.io/docs/Smart-Meter-Interface/#resol-deltasol-bs-plus-vbus Script ergänzt] werden.<br />
<br />
Mit dem Befehl <code>sensor53 d1</code> kann man den Header für die [https://tasmota.github.io/docs/Smart-Meter-Interface/#meter-metrics Meter Metrics] ermitteln und im Script entsprechend anpassen.<br />
<br />
Für die RemaSol B/2 sieht das wie folgt aus:<br />
<source><br />
r="1,aa10005d101000010a67"<br />
coltemp=0<br />
Byte1=0<br />
Byte2=0<br />
<br />
>S<br />
coltemp=sml[1]<br />
Byte1=coltemp>>8<br />
Byte2=coltemp&0xff<br />
if Byte1==0x00 {<br />
coltemp=coltemp&0xff<br />
}<br />
if Byte1==0xff {<br />
coltemp=(coltemp-0x10000)<br />
}<br />
coltemp=coltemp*0.1<br />
<br />
>B<br />
=>sensor53 r<br />
<br />
>M 1<br />
+1,3,v,0,9600,Solar<br />
%r%vo0uw@1,KollektorBase,°C,kolbase,2<br />
%r%vo0uw@10,KollektorOrg,°C,kolorg,2<br />
%r%vo2uw@10,Speicher unten,°C,spu,1<br />
%r%vo4uw@10,Speicher oben,°C,spo,1<br />
%r%vo8ub@1,Pumpe,%%,pump,0<br />
#<br />
<br />
>J<br />
,"Calculated":{"kol":%coltemp%}<br />
<br />
>W<br />
Kollektor berechnet: {m} %coltemp% °C<br />
</source><br />
Anmerkung: Hierbei handelt es sich um einen direkten Copy & Paste aus Michaels Script. Je nach Konfiguration der Anlage kann es Abweichungen geben.<br />
<br />
Um den Fragen zuvorzukommen - die Anpassung auf die Jeweilige Anlage beginnt in der ersten Zeile:<br />
<code><br />
r="1,<span class="hb1">aa</span><span class="hb2">1000</span><span class="hb3">5d10</span><span class="hb4">10</span><span class="hb5">0001</span><span class="hb6">0a</span><span class="hb7">67</span>"<br />
</code><br />
<br />
Die Farben entsprechen dem Beispiel von der [[VBus-Decoder#Protokoll|Artikelhauptseite]], kurzum:<br />
<br />
* <span class="hb1">aa</span>: Sync-Wort<br />
* <span class="hb2">1000</span>: Zieladresse<br />
* <span class="hb3">5d10</span>: Quelladresse<br />
* <span class="hb4">10</span>: Protokollversion<br />
* <span class="hb5">0001</span>: Befehl<br />
* <span class="hb6">0a</span>: Anzahl Nutzdatenframes<br />
* <span class="hb7">67</span>: Prüfsumme<br />
<br />
Die <span class="hb3">Quelladresse</span> kann in der [https://danielwippermann.github.io/resol-vbus/#/vsf VBus-Spezifikation nachgeschlagen werden]. Zu beachten ist hier die Endianness: was in der Doku als <code>0x1234</code> geschrieben ist, muss hier als <code>3412</code> angegeben werden.<br />
<br />
Anschließend muss man auf der [https://danielwippermann.github.io/resol-vbus/#/vsf oben genannten Seite] nach dem Command 0x0100 für den entsprechenden Regler suchen. Dazu am besten oben nach 0x0100 filtern und dann mit Strg+F die Quelladresse finden.<br />
<br />
Klickt man in der Zeile auf <code>Bytes</code> bekommt man die Länge der Nachricht, wobei man 1 addieren muss, da es sich um Offsets handelt. Beim RemaSol 1/2 (bzw. DeDietrich Sol Plus ER 709) ist der größte Offset 39, also 40 Bytes. Mit dem Wissen, dass ein Frame 4 Byte enthält, ergibt sich eine Länge von 10 Frames, was einem Hexadezimalwert von <span class="hb6">0x0A</span> entspricht.<br />
<br />
Nun muss man nur noch die Prüfsumme berechnen (oder durch Schnüffeln am UART ermitteln)<br />
<br />
Für die Feldzuordnung lohnt sich ein scharfer Blick und Vergleich der <code>Fields</code>-Seite für die [https://danielwippermann.github.io/resol-vbus/#/vsf/fields/00_0010_4221_10_0100 DeltaSol BS Plus] und dem Beispiel in der [https://tasmota.github.io/docs/Smart-Meter-Interface/#resol-deltasol-bs-plus-vbus dieses Reglers] in der Tasmota-Doku.<br />
<br />
=Leiterkarten=<br />
Es gibt noch unbestückte Leiterkärtchen. Wer eine will, kann sich gerne bei mir melden.<br />
<br />
Achtung: Es handelt sich um Version 0.1, auf der sich 3 kleine Fehler befinden, die sich allerdings mit Fädeldraht korrigieren lassen:<br />
<br />
==Hotfix für v0.1==<br />
Um die Leiterkarte Version 0.1 korrekt nutzen zu können, sind bis zu 3 Fixes nötig:<br />
<br />
===Bootloader-Schaltung===<br />
Die Beschaltung der Transistoren ist teilweise falsch. Um dies zu korrigieren, müssen 3 Leiterbahnen aufgetrennt werden und die Verbindungen mit Fädeldraht neu hergestellt werden.<br />
<br />
Das Auftrennen kann je nach Geschmack mit einem kleinen Trennschleifer (Vulgo Dremel) oder einem Messer erfolgen.<br />
Statt der zwei Drähte zum unteren der beiden Widerstände kann der Widerstand (im 0603-Gehäuse) auch zwischen die beiden Pads am Transistor gelegt werden und damit ein Schnitt und eine Drahtverbindung gespart werden.<br />
<br />
<gallery><br />
vbusesp_v01fix_transistor_rewire.png | Korrekturanleitung<br />
vbusesp_v01fix_transistor_prep1.jpg | mit dem Skalpell entfernt<br />
vbusesp_v01fix_transistor_prep2.jpg | mit dem Trennschleifer durchtrennt<br />
vbusesp_v01fix_transistor_done.jpg | Durchgeführte Korrektur<br />
</gallery><br />
<br />
===Beschaltung GPIO15 am ESP12===<br />
Diese Korrektur ist nur relevant, wenn man ein ESP12-Modul einsetzt.<br />
<br />
Der Mikrocontroller startet nur, wenn GPIO15 über einen Pull-down mit Masse verbunden ist.<br />
<br />
Dazu sollte ein 10k-Widerstand zwischen diese beiden Pins, wie unten dargestellt, eingebaut werden:<br />
<br />
<gallery><br />
vbusesp_v01fix_res.jpg | Durchgeführte Korrektur. Widerstand ist zweckvoll!<br />
</gallery><br />
<br />
===Pull-up an Q3===<br />
Wird die Tx-Funktionalität verwendet, blockiert der als Pull-down eingesetzte R14 den Bus.<br />
<br />
Um dies zu berichtigen muss das linke Pad getrennt und mit und mit VBUS_3V3 verbunden werden:<br />
<br />
<gallery><br />
vbusesp_v01fix_tx_pull.png | Korrekturanleitung<br />
</gallery><br />
<br />
=Bekannte Probleme=<br />
==Fehlerhafter Datenempfang==<br />
<br />
Carsten hat eine interessante Entdeckung bei seinem Aufbau gemacht, untersucht und dann auch gleich eine Lösung gefunden:<br />
<br />
<pre><br />
Nachdem ich den VBus Dekoder programmiert hatte, ist mir aufgefallen, dass die gesamte Kommunikation <br />
sehr stark mit Bitfehlern behaft ist. Nur etwa ein Drittel der VBus Frames kamen unversehrt in der <br />
Software an; das Ende langer Pakete war so gut wie immer kaputt. Wenn ich einen FTDI USB Konverter <br />
hinter den Optokoppler gehängt habe, wurden die Daten fehlerfrei auf dem PC empfangen, also musste <br />
das Problem mit dem ESP zusammenhängen. <br />
<br />
Daher habe ich mir in den UART Treiber einen Debug-Pin eingebaut, der bei jedem Frame-Fehler mein <br />
DSO getriggert hat und das war dann zu sehen:<br />
</pre><br />
<br />
<gallery><br />
Vbusesp_carsten_rx_issue_1.png | Oszi-Screenshot mit defekter und korrekter Nachricht<br />
</gallery><br />
<br />
<pre><br />
Irgendwie hat der ESP RX Eingang unter bestimmten Umständen den Pin so stark nach VCC gezogen, <br />
dass die Pegel kaputt gegangen sind. Warum er das scheinbar nur manchmal macht, ist mir allerdings <br />
noch immer ein Rätsel. Dann weiter im Sourcecode gesucht, wo die Pin-Konfiguration während der <br />
Initialisierung des UART gemacht wird. Hier bin ich dann in der Datei <br />
'core_esp8266_wiring_digital.cpp' fündig geworden:<br />
</pre><br />
<br />
<gallery><br />
Vbusesp_carsten_rx_issue_2.png | Codestelle des Fixes<br />
</gallery><br />
<br />
<pre><br />
Seitdem ich die Zeile 42 unschädlich gemacht habe, läuft die Kommunikation wie geschnitten Brot :-) <br />
Der Debug-Trigger hat auch nach mehreren Stunden nicht mehr zugeschlagen.<br />
Ich muss jetzt noch dazu sagen, dass ich die Software mit PlatformIO entwickele uns ich die <br />
Version 4.0.1 des ESP8266 Platform Package aktuell verwende. Das kann gut sein, dass es mit anderen <br />
IDEs und anderen/älteren Packages nicht passiert, weil der Pullup dort nicht eingeschaltet wird.<br />
</pre><br />
<br />
Wer die Stelle im Repo sucht: [https://github.com/esp8266/Arduino/blob/master/cores/esp8266/core_esp8266_wiring_digital.cpp#L41 hier ist sie].<br />
<br />
Ich bin zwar kein großer Freund, tief in Libs zu patchen, konnte aber nach einem Abend Erstkontakt mit den Tasmota-Sourcen keinen besseren Ort für eine Anpassung finden.<br />
<br />
Bleibt die Frage, warum der Pull-up aktiviert und deaktiviert wird - bei einer (kurzen) Suche ist mir im Code nichts aufgefallen. Kann natürlich sein, dass die CPU selbst das entsprechende Bit setzt/löscht, was aber merkwürdig wäre.<br />
<br />
Bleiben zwei Optionen: entweder selber nochmal forschen oder einen Issue in Github erstellen.<br />
<br />
=Downloads=<br />
* [[Datei:Vbusesp_0.2.zip]] EAGLE-Dateien Adapter v0.2 für den ESP8266<br />
==Archiv==<br />
* [[Datei:Vbusesp_0.1.zip]] EAGLE-Dateien Adapter v0.1 für den ESP8266<br />
<br />
[[Kategorie:ESP8266]]<br />
[[Kategorie:Energieerfassung]]<br />
[[Kategorie:Solaranlage]]<br />
[[Kategorie:VBus]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Vbusesp_vbusonly_pinout.png&diff=1859Datei:Vbusesp vbusonly pinout.png2023-06-17T20:58:28Z<p>Chris: Chris lud eine neue Version von Datei:Vbusesp vbusonly pinout.png hoch</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Hauptseite&diff=1858Hauptseite2023-04-11T20:20:48Z<p>Chris: /* Neues & Änderungen */</p>
<hr />
<div>'''Willkommen auf hobbyelektronik.org!'''<br />
<br />
Auf diesen Seiten findest du [[Hobbyelektronik.org:Impressum|unsere]] Projekte rund um Elektronik und allem möglichen, was uns interessiert.<br />
<br />
Neben dem Wiki hier gibt es auch ein '''[//hobbyelektronik.org/b/ Blog]''', das sich nicht nur mit Elektronik und der Homepage beschäftigt. Dort kann - im Gegensatz zum Wiki hier - auch fleißig kommentiert werden, was an dieser Stelle aufgrund von massivem Spam deaktiviert werden musste.<br />
<br />
Aber nun wünsche ich viel Spaß beim stöbern auf den Seiten hier!<br />
<br />
Bitte benutze die Navigation links, um zu den [[Spezial:Alle Seiten|Artikeln]] zu kommen.<br />
=[//hobbyelektronik.org/b/ Blog]=<br />
<WPPlatest /><br />
<br />
=Neues & Änderungen=<br />
<div id="mw-latest-changes10"><br />
*11.04.2023 Pünktlich zu Ostern wird ein paar [[Freifunk-Rebooter|Freifunk-Routern]] in die... - ach, lassen wir das.<br />
*24.11.2022 Beim VBus-ESP8266-Adapter kann es [[VBus-Decoder/Adapter_für_den_ESP8266#Fehlerhafter_Datenempfang|Fehler beim Datenempfang]] geben<br />
*22.11.2022 Kleine Korrektur beim [[VBus-Decoder/Adapter_für_RS-232|VBus-Adapter für RS-232]]<br />
*11.11.2022 Weitere Informationen zu den [[Prozeda-Decoder#Display|Displaydaten]] beim [[Prozeda-Decoder]]<br />
*10.11.2022 Ein CitrinSolar CS 1.3 wurde [[Resol_-_Zerlegt#CitrinSolar_CS_1.3|zerlegt]] und [[Resol - Reparaturen|repariert]]<br />
*02.11.2022 Ein [[Resol 71005014 Schnittstellenadapter]] wurde repariert und verbessert<br />
*02.11.2022 Warum zur Abwechslung nicht einmal paar [[Resol - Zerlegt|Resol Geräte zerlegen]]<br />
*23.12.2021 Es wird heimelig zu Weihnachten: ein [[LED-Lagerfeuer]]<br />
*13.12.2021 Mal wieder ein VBus-Decoder - jetzt für den [[VBus-Decoder/Adapter_für_den_ESP8266|ESP8266]]<br />
*07.09.2021 Eine aktualisierte Untersuchung des [[ECL-Bus-Protokoll]]s<br />
*12.07.2021 Der Pythoncode der [[MCP-USB-Bridge]] ist auf GitHub umgezogen und spricht nun mit dem MCP2210 (SPI)<br />
*26.02.2021 Und noch ein Update für den VBus-Decoder: [[VBus-Decoder/Adapter_für_den_Raspberry_Pi#Die Enttäuschung - Teil 2| Version 1.2b]] und [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Version 1.3]], sowie einem einfachen [[VBus-Decoder#Protokoll-Analysator|Protokoll-Analysator]]<br />
*09.02.2021 Die Artikel [[VBus-Decoder]] und [[Prozeda-Decoder]] sind nun in Unterseiten aufgeteilt<br />
*10.05.2020 Mit irgendwelchen Tasten OBS steuern: [[Anykey x6]]<br />
*08.04.2020 Etwas für den Drucker: [[3D-Druck-Sammelsurium#Mikrofonarm_f.C3.BCr_den_Zoom_H2n|Mikrofonarm für den Zoom H2n]]<br />
*04.04.2020 [[Reparatur_R%26S_CMU200_Hintergrundbeleuchtung|Ein neues Backlight für eine CMU200]]<br />
*31.03.2020 Es geht auch günstiger: [[VBus-Decoder/Adapter_für_den_Raspberry_Pi#Kostenreduzierte_Variante.2Fv1.2|Costdown für den VBus-Decoder am Raspberry Pi]]<br />
*10.03.2020 Wer braucht es nicht: einen [[USB-Fußtaster]]<br />
*15.02.2020 Ein bisschen Modellpflege: [[MCP-USB-Bridge#USB-I.C2.B2C-Bridge_v1.1|MCP USB-I²C-Bridge v1.1]], ein [[VBus-Decoder/Adapter_Nano|VBus-Adapter für den Raspberry Pi]] und die VBus-Boards Nano-Boards sind wieder da :)<br />
*19.01.2020 [[Pirozeda]] Version 0.4 hat wohl Stabilitätsprobleme<br />
*19.01.2020 Update für die [[MCP-USB-Bridge|MCP2221-Python-Lib]] und Anmerkungen zu Datenblattfehlern<br />
*13.01.2020 Backplates für den [[3D-Druck-Sammelsurium#Diamex_AVR-Prog_Bodenplatte|Diamex AVR-Prog]] und die [[3D-Druck-Sammelsurium#USB-I.C2.B2C-Bridge_Bodenplatte|MCP USB-I²C-Bridge]] im [[3D-Druck-Sammelsurium]]<br />
*25.12.2019 [[3D-Druck-Sammelsurium]]<br />
*16.12.2019 Ein paar [[Softwaretools|Tools]] um die [[Softwaretools#SerialPlayer|serielle Schnittstelle zu bespaßen]] und [[Softwaretools#SaleaeTools|Daten aus Saleae Logic komfortabler verarbeiten zu können]]<br />
*10.11.2019 Für den VBus-Adapter Nano gibt es nun einen [[VBus-Decoder/Adapter_Nano#Troubleshooting|Troubleshooting-Guide]] und eine [[VBus-Decoder#Python-Implementierung|Python-Implementierung]]<br />
*17.09.2019 Für den MCP2221 und MCP2210 (USB I²C- & SPI-Interface) gibt es nun eine [[MCP-USB-Bridge#C.23-Lib|C#-Lib]]<br />
*07.05.2019 Ein Adapter für den Adapter: Der [[Atmel-ICE-Adapter]]<br />
*21.03.2019 Doku des [[Pirozeda-HAT]] korrigiert & aktualisiert<br />
*16.03.2019 Ein paar Infos und ein mechanischer Adapter für [[Ikea Trådfri]] (teilweise aus dem Blog übernommen)<br />
*11.02.2019 Der [[VBus-Decoder/Adapter_Nano|VBus-Adapter Nano]] ist nun aufgebaut und getestet<br />
*10.02.2019 Der [[EAGLE-BOM]]-Export kann nun auch JSON<br />
*03.01.2019 Auch für den VBus gibt es neue Hardware: [[VBus-Decoder/Adapter_Nano|VBus-Adapter Nano]]<br />
*03.01.2019 Langsam wird ein Hut draus: Der [[Pirozeda#Pirozeda-HAT|Pirozeda-HAT]] ist zwar noch nicht da, aber bald.<br />
*27.10.2018 [[MCP-USB-Bridge#Python-Lib|MCP-USB-Bridge]] es gibt nun eine Python-Lib, die die meisten Features des MCP2221 unterstützt<br />
*23.08.2018 [[MCP-USB-Bridge]] - billiges und einfaches I²C- & SPI-Interface für den PC<br />
*19.08.2018 EAGLE kann nun direkt [[EAGLE-BOM_für_MediaWiki|BOMs als MediaWiki-Tabelle]] exportieren<br />
*05.08.2018 [[Pirozeda]] Version 0.31. ...und nochmal ein Bugfix. Die Aktualisierung für die aktuellen Daten/Display und Statistik wurden nicht richtig aktualisiert<br />
*05.08.2018 [[Pirozeda]] Version 0.3. Ein paar Bugfixes und ein 3D-Diagramm für historische Daten<br />
*16.04.2018 Im Artikel des [[Prozeda-Decoder]] gibt es nun [[Prozeda-Decoder#Einblick_in_den_Regler|Einblick in den Regler]]<br />
*15.04.2018 Der [[Prozeda-Decoder]] ist nun mit einem Raspberry Pi verheiratet: [[Pirozeda]]<br />
*12.11.2017 [[Mini-LED-Treiber]]<br />
*17.04.2017 Update von MediaWiki, mehr im [//hobbyelektronik.org/b/?p=1556 Blog]<br />
*22.02.2017 Solaranlagen von Wagner-Solar bzw. [[Prozeda-Decoder|Prozeda]] können nun ausgelesen werden<br />
*31.12.2016 Dank [[Briefkasteninnenbeleuchtung]] ist mein Briefkasten innen beleuchtet<br />
*11.03.2016 Kleines Update für den [[VBus-Decoder]]: Es gibt nun [[VBus-Decoder/Adapter_für_RS-232|Hardware für den PC]]<br />
*19.04.2015 Ein Nachtrag bei der [[Kühlung_für_Zhongdi_ZD-939L#Nachtrag_19.04.2015|Kühlung für Zhongdi ZD-939L]]<br />
*10.04.2015 [[ASCII-Tabelle]]: Dez- & Hex-Angaben deutlicher, neue Druckformate.<br />
*10.05.2014 Neu: [[Kühlung für Zhongdi ZD-393L]]<br />
*02.02.2014 Neu: [[EAGLE-Bibliotheken]]<br />
*10.11.2013 Neu: [[Zeitraffer mit Linux]]<br />
*20.10.2013 [[EMR7370]] korrigiert. In main() war ein falscher Funktionsaufruf.<br />
*14.08.2013 Neu: [[Umbau Belkin Auto-USB-Lader]]<br />
*02.05.2013 Neu: [[Farnell-Assistent]]<br />
*16.01.2013 Neu: [[Halbleiterelektronik-Formelsammlung]]<br />
*11.10.2012 Neu: [[EAGLE-Toolbar]]<br />
*26.09.2012 Neu: [[Sony Dimmer]]<br />
*05.05.2012 Neu: [[Raspberry Pi IO]]<br />
*28.04.2012 [[EMR7370]] ergänzt. Der Quellcode ist nun verfügbar.<br />
*14.03.2012 Ein paar Bilder zum [[Kameratimer]] und dem [[SNES-Joypad]] hinzugefügt<br />
*12.03.2012 Neu: [[EMR7370]]<br />
*29.12.2011 Neu: [[Polizeiauto]]<br />
*03.10.2011 Neu: [[Audioslave]]<br />
*13.09.2011 Neu: [[Modellbau-Leuchtstofflampe]]<br />
*12.09.2011 Neu: [[Gartenbrunnen]]<br />
*12.06.2011 Neu: [[Maschinenleuchte]]<br />
*04.05.2011 Neu: [[ECL-Bus-Decoder]]<br />
*19.03.2011 [[What's next?]]: Zimmerbus<br />
*19.03.2011 Neu: [[Physik-Formelsammlung]]<br />
*15.01.2011 Neu: [[Belichtungsgeraet]]<br />
*09.12.2010 Neu: [[Energieerfassung/Solarleistung]]<br />
*21.11.2010 [[What's next?]]: Ein paar Infos zum Moodlight<br />
*21.11.2010 [[AVR-Doper]]: "Patch" für AVR-Studio<br />
*21.11.2010 [[Energieerfassung]]: Abschnitt [[Energieerfassung#Nerviges/Todo|Todo/Nerviges]] hinzugefügt<br />
*15.11.2010 [[Energieerfassung#Downloads|Energieerfassung ? Downloads]]: Die Firmware steht jetzt zum Download bereit<br />
*10.10.2010 [[Energieerfassung#Solaranlage|Energieerfassung ? Solaranlage]]: Die PT1000 haben nun doch ihren Zweck erfüllt<br />
*10.10.2010 Neu: [[Kameratimer]]<br />
*10.10.2010 [[Energieerfassung#Solaranlage|Energieerfassung ? Solaranlage]]: Die PT1000 haben nun doch ihren Zweck erfüll<br />
*31.08.2010 Neu: [[Energieerfassung]]<br />
*09.08.2010 Neu: [[AVR-NET-IO-Shield]]<br />
*15.07.2010 Neu: [[Nokia 5110 Displayadapter]]<br />
*09.07.2010 Neu: [[Sommerhitz]]<br />
*16.06.2010 Seiten in [[:Kategorie:AVR|Kategorie AVR]]: AVR Infobox hinzugefügt<br />
*13.06.2010 [[Touchlight]] (Abschnitt [[Touchlight#Praxis|Praxis]] hinzugefügt)<br />
*19.03.2010 [[What's next?]]: Zimmerbus<br />
*04.03.2010 Neu: [[VBus-Decoder]]<br />
*04.03.2010 [[SNES-Joypad]] (Autocal-Version & ATtiny2313-Version)<br />
*24.02.2010 Neu: [[UnitColor]]<br />
*12.02.2010 Neu: [[Panasonic-Zapper]]<br />
*09.01.2010 Neu: [[ASCII-Tabelle]]<br />
*27.12.2009 Neu: [[USBLotIO]]<br />
*04.07.2009 Neu: [[Touchlight]]<br />
*19.01.2009 Neu: [[Datenlogger]]<br />
*01.09.2008 Neu: [[Labornetzteil]]<br />
*09.08.2008 Neu: [[Cursor]]<br />
*08.08.2008 Neu: [[Image Resizer]]<br />
*14.03.2008 Neu: [[Platinenbohrmaschine]]<br />
<html><a id="showall" href="#Neues_.26_.C3.84nderungen" onclick="document.getElementById('mw-latest-changes10').className='all';">Alle Änderungen anzeigen</a></html><br />
</div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_v0.1.zip&diff=1857Datei:Ff rebooter v0.1.zip2023-04-11T20:18:26Z<p>Chris: </p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Freifunk-Rebooter&diff=1856Freifunk-Rebooter2023-04-11T20:18:12Z<p>Chris: /* Downloads */</p>
<hr />
<div>=Ausgangssituation=<br />
<br />
In unseren Flüchtlingsunterkünften stehen mehrere Xiaomi Mi Router 4A Gigabit Edition, die mit der Freifunk-München-Firmware bespielt sind. <br />
Wer Freifunk nicht kennt, kann und sollte am besten sich in der [[wpde:Freifunk|Wikipedia]] informieren.<br />
<br />
Was am Anfang noch recht gut funktionierte, wurde mit der Zeit immer instabiler. Ein Cronjob zum nächtlichen Neustart brachte zwar Besserung, aber nach ein paar Tagen gingen die Router in eine Bootloop.<br />
<br />
Um den Fehler besser zu verstehen, wurde zeitweise ein [https://hobbyelektronik.org/b/2022/10/uart-logging-mit-linux/ Raspberry Pi zum Protokollieren] abgestellt. Als jemand, der von Linux nur rudimentäres Wissen besitzt, sahen die Meldungen so aus, als könne der SoC einen der WLAN-Chips nicht mehr initialisieren und schoss sich ins Nirwana. Blöd: ein Reboot richtet das nicht, Dokumentation für die Chips hängt wohl hinter der NDA-Mauer und einen hard-reset scheint es nicht zu geben.<br />
<br />
Nach einem kurzen Austausch im Chat der Freifunker gab es ein Ticket bei OpenWRT und nach einigen paar Tagen auch eine Experimental-Firmware, die den Fehler beheben sollte. Sollte.<br />
<br />
Ein paar Tage später stand bei Grafana für die Knoten wieder "no data", dafür gab es Klagen aus der Unterkunft. Einer der Router steht hinter für die dauerhaft verschlossener Tür, der andere in einem Zimmer dessen Bewohner auch mal ein paar Tage nicht da sind (und absperren).<br />
<br />
=Lösungsansätze=<br />
<br />
Kurz den/die entsprechenden LS-Schalter zu werfen ist leider auch keine Option. Das genauere Warum habe ich nicht weiter hinterfragt, das muss man einfach als gegeben annehmen.<br />
<br />
Dabei ist Strom trennen einfach wie effektiv. Eine Zeitschaltuhr würde helfen, die billigeren haben aber recht grobe Zeitraster und dementsprechend lange Ausfallzeiten. Auch kann es natürlich gleich nach einem Zwangsneustart gleich wieder zu Problemen kommen und die Wartezeit zum nächsten Neustart wird unnötig lang.<br />
<br />
Zwischenstecker mit Tasmota o. ä. würden zwar das Problem mit der Ausschaltzeit lösen, hätten aber wenig Chancen gegen Problem 2. Zwar könnten diese checken, ob das WLAN wegfällt, die Unterkunft wird allerdings durch mehrere Freifunk-Router (mit gleicher SSID) versorgt. Unnötig viel Komplexität.<br />
<br />
=Die Idee=<br />
<br />
Man sieht es den Routern von außen an, wenn sie abschmieren – im Betrieb leuchtet die Power-LED permanent blau, bei einem Crash bzw. Bootloop blinkt sie orange vor sich hin. Mit ein bisschen Mustererkennung erkennt man sogar die Phasen.<br />
<br />
Warum also nicht einen kleinen Mikrocontroller auf die Status-LED(s) schauen lassen und das "have you tried to turn it off and on again"-Spiel spielen lassen?<br />
<br />
==Datensammeln==<br />
<br />
Am Anfang war die Beobachtung: In einem kleinen WhatsApp-Video bekam ich das unheilvolle orange blinken von einem Vereinsmitglied; ein paar Sekunden sind jedoch noch nicht die ganze Geschichte, deshalb holte ich mir einen der Router nach Hause und nahm ein Video von einem Kaltstart des Gerätes auf und wartete ein bisschen.<br />
<br />
Ein paar Tage am Netz und siehe da: ohne Zutun von außen blinkt die Power-LED orange. Also nochmal die Kamera raus, Aufnahme und einige Minuten laufen lassen.<br />
<br />
Als Referenz gab es dann noch ein Video von einem erfolgreichen Start:<br />
<br />
[[Datei:ff_rebooter_xiaomi_start.mp4]]<br />
<br />
Mit den Videos kann man sich die Mäusedisco nun wieder und wieder ansehen, Bild für Bild durchgehen und die Blinkzyklen aufschreiben, oder man ist faul und fragt ChatGPT, wie man mit Python die Farben von Pixeln in Videos ermittelt. Ok, das ist wirklich keine rocket science (und einfach nur in der Doku von OpenCV zu stöbern hätte gereicht), aber schon erstaunlich, was Wortstatistik auf Steroiden leisten kann.<br />
<br />
==Videoauswertung==<br />
<br />
Für den ersten Eindruck ist die Herangehensweise eher unakademisch - das Beispiel vom Chatbot wird angepasst, damit an zwei Punkten - Power- und Link-LED - die Farben ermittelt werden, diese werden als Zellenhintergrund für eine HTML-Tabelle ausgegeben. Einfach wie fatal.<br />
<br />
Um nicht nur einen Pixel zu sampeln, wird jeder Frame um den Faktor 16 dezimiert - statt 1280x720 wird also ein Bild der Größe 80x45 verwendet. Das macht den Prozess nicht schneller, dafür werden Rauschen und Überstrahlungseffekte etwas reduziert.<br />
<br />
<source lang="python"><br />
import cv2<br />
video = cv2.VideoCapture("S1040005.MP4")<br />
<br />
frame_decimation = 16<br />
frame_skip = 1<br />
probe_points = [[970, 173], [1039, 168]]<br />
<br />
framecnt = int(video.get(cv2.CAP_PROP_FRAME_COUNT))<br />
print(framecnt)<br />
<br />
print("<style> body { background-color: black; } td { width: 20px; height: 1px; } </style>")<br />
print("<table style=\"border-collapse: collapse;\">")<br />
<br />
for frame_number in range(0, framecnt, frame_skip):<br />
video.set(1, frame_number)<br />
<br />
# Read the frame<br />
success, frame = video.read()<br />
newsize = (int(frame.shape[1] / frame_decimation), int(frame.shape[0] / frame_decimation))<br />
resized = cv2.resize(frame, newsize, interpolation = cv2.INTER_AREA)<br />
<br />
# Get the color of the pixel at the given location<br />
cols = []<br />
for point in probe_points:<br />
(b, g, r) = resized[int(point[1]/frame_decimation), int(point[0] / frame_decimation)]<br />
cols.append(f"#{r:02X}{g:02X}{b:02X}")<br />
<br />
#print("\t".join(cols))<br />
print("<tr>" + "".join(map(lambda x : f"<td style=\"background-color: {x}\"> </td>", cols)) + "</tr>")<br />
<br />
print("</table>")<br />
video.release()<br />
</source><br />
<br />
Bei Videomaterial mit 25 fps (was zugegebenermaßen etwas wenig ist), sieht ein etwas längerer Ausschnitt des Videos oben wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_start.png | Start des Xiaomi-Routers<br />
</gallery><br />
<br />
Links, wie im Video oben, die Power-LED, rechts die Link-LED. Wie aus dem Quellcode ersichtlich sein sollte, entspricht bei frame_skip = 1 jedes Frame ein Pixel in y-Richtung bei 25 fps. "Misst" man die Pixel vom ersten Lebenszeichen der linken LED bis sie blau wird, "vergehen" 1840 Pixel und somit 73,6 s - nicht ganz. Weil HTML ist das was man eingibt nicht unbedingt das, was angezeigt wird. Laut Konsole ist jeder oben angegebene Pixel 2px in der Darstellung, somit beträgt die Boot-Zeit 36,8 s. <br />
<br />
Der Bootloop ist nicht spektakulärer, er ist lediglich die immerwährende Wiederholung des "orangen" Parts.<br />
<br />
=Umsetzung=<br />
==Hardware==<br />
Der erste Gedanke war, die Hardware minimalinvasiv aufzubauen: Nachdem es Dauerlicht nur gibt, wenn die Kiste läuft, ist die Farbe irrelevant. Blinkt etwas länger, ist etwas im Argen. Also warum nicht einfach einen Fototransistor anflanschen, die Helligkeit auswerten und wenn längeres Blinken herrscht denk Anker werfen?<br />
<br />
Es scheitert wie immer an der Realität. Die ersten Versuche waren aussichtsreich, mit Umgebungslicht und nicht exakt platziertem Fototransistor war die Freude aber recht schnell wieder vorbei.<br />
<br />
Für die ersten Versuche auf dem Breadboard hat es zumindest gereicht.<br />
<br />
Um nicht extra Teile bestellen zu müssen, wurde das eingeplant, was herum liegt, Herzstück ist ein (völlig überdimensionierter) ATmega8A, der Signale zweier Fototransistoren im SMD-Package, aber auch in der THT-Version in Form von BPW40 entgegennimmt.<br />
<br />
Um beide LEDs am Router erfassen zu können, sind diese im Abstand von 15 mm zueinander platziert.<br />
<br />
Auf der anderen Seite des Mikrocontrollers hängen p-Kanal FETs sowohl im SO-8- als auch SOT-23-Gehäuse, über die die Versorgung des Routers geschaltet wird.<br />
<br />
Um evtl. doch noch einen UART mit abweichender Spannung (und Domäne) anbinden zu können, noch zwei einfache Levelshifter dazu und ab auf eine Leiterkarte damit.<br />
<br />
Noch zwei Status-LEDs dazu und fertig ist der Lack.<br />
<br />
Recht viel Optionales, aber eine zweiten Leiterkarten-Spin zu fahren: #gerkeinbock<br />
<br />
Leiterkarten-Spin? Ja, mittlerweile bin ich echt zu faul, etwas auf Lochraster aufzubauen - zumal so gut wie alle Bauteile im SMD-Package daherkommen.<br />
<br />
Der zusammengeklöppelte Schaltplan, Layout und der Aufbau sehen wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_sch.png | Schaltplan<br />
ff_rebooter_pcb.png | Layout der Leiterkarte<br />
ff_rebooter_pcb_top.jpg | Bestückte Oberseite<br />
ff_rebooter_pcb_bot.jpg | Bestückte Unterseite<br />
</gallery><br />
<br />
===BOM & Nachbau===<br />
Nachdem die Hardware schnell-schnell zusammengeklöppelt wurde, ist aktuell keine BOM und genauere Details vorgesehen. Wer sie dennoch möchte, kann sie gerne aus den EAGLE-Daten erzeugen oder mich anschreiben.<br />
<br />
==Firmware==<br />
Die Software hat im Prinzip nur eine Aufgabe: Blinkt die Power LED länger als x Sekunden, wird die Stromversorgung für y Sekunden unterbrochen.<br />
<br />
"Genau das, nur etwas komplizierter!"<br />
<br />
Zunächst gilt die Frage zu klären: Wann blinkt was, wann ist es statisch an, wann aus?<br />
<br />
===ADC===<br />
<br />
Vorher muss aber erst noch geklärt werden: Wann ist eine LED überhaupt an?<br />
Mit den vorhin erwähnten Fototransistoren muss man das Umgebungslicht filtern. Ist die LED länger statisch und das Licht "außenrum" ändert sich, oder es verrutscht etwas leicht, verpasst man vielleicht, dass sich etwas ändert.<br />
<br />
Kann man filtern, kann man aber auch von Grund auf vermeiden. auch wenn die Elektronik dafür vorgesehen ist: man muss die optischen Sensoren nicht verwenden, sondern kann auch einfach auf die Ansteuerung der LEDs gehen. Diese erfolgt jedoch nicht mit boardähnlichen 5 V, sondern mit 3,3 V, was für die Eingänge etwas knapp werden kann. Also kommt doch der ADC zum Einsatz, wenn auch etwas vereinfacht: zwei Schwellenwerte, dazwischen eine Hysterese, fertig.<br />
<br />
Einen Schritt zurück: Der Analog zu Digital-Wandler durchläuft, nachdem das "Subsystem" getriggert wurde alle ausgewählten Kanäle, was etwa jede Millisekunde geschieht.<br />
<br />
Schwellenwertvergleich und ab mit einem true oder false in die LED-Detektion.<br />
<br />
===LED-Detektion===<br />
<br />
Diese schaut, ob sich was am Zustand des Einganges ändert und zählt die entsprechende Zeit. Wechselt der Zustand nach "0" (false) wird erst einmal blinkend angenommen, bleibt der Zustand für länger als <code>LEDDET_TIMEOUT</code> (750 ms) konstant, wird "statisch aus" respektive "an" angenommen.<br />
<br />
Das Ganze wird für die rote und blaue LED der "Power-LED" gemacht...<br />
<br />
===Zustandsautomat===<br />
... und im "Target"-Zustandsautomaten verwurstet, der zunächst auf Papier entstand und nach der Implementierung auf dem PC nachgezeichnet wurde:<br />
<br />
<gallery><br />
ff_rebooter_fsm.png | Zustandsautomat für das "Target"<br />
</gallery><br />
<br />
Nach dem Einschalten geht die Maschine zunächst in den Off-Zustand - hauptsächlich um die Realität abzubilden. Beim Startup wird die Stromversorgung für den Router eingeschaltet und die grüne LED blinkt vor sich hin.<br />
<br />
Sobald für länger als 2 Sekunden die orange LED des Routers erloschen ist und die blaue leuchtet, wird angenommen dass der Router läuft. Ist das nach 90 Sekunden am Strom nicht der Fall, wird ein Crash angenommen und ein harter Reboot eingeleitet (mehr dazu später).<br />
<br />
Im Zustand Running gibt es zwei Varianten für die eigenen Status-LEDs: In jedem Fall leuchtet die grüne LED dauerhaft, wurde vorher ein Crash "erkannt", blitzt zusätzlich die rote LED auf.<br />
<br />
Sollte nun am Router die orange LED an gehen oder blinken und die die blaue LED nicht an sein, gibt es einen Crashverdacht; allerdings erst, wenn dies für über 2 Sekunden mit "Waterlevel" der Fall ist. Mit Waterlevel ist gemeint, dass im "Verdachtszustand" ein Zähler hochgezählt wird. Ist der "Verdacht" vorbei, wird dieser Zähler nicht auf Null zurückgesetzt, sondern lediglich verringert. So kann ein instabiler Zustand etwas besser erkannt werden.<br />
<br />
Erhärtet sich der Crashverdacht, wird ein interner Zähler für die Verdachtsfälle hochgezählt, erreicht dieser die magische Anzahl 3 oder bleibt der Zustand für über 90 Sekunden, wird ein Neustart eingeleitet. "Fängt" sich der Router wieder, sprich: die blaue LED leuchtet konstant und die orange ist aus, wechselt der Zustand nach 5 Sekunden wieder nach Running. Allerdings hier ohne Waterlevel. Lieber einen harten Neustart als im Limbus zwischen Running und Crashed hängen bleiben.<br />
Da beim erhärteten Crashverdacht vermutlich nix mehr geht, darf nun die rote Status-LED blinken, die grüne bleibt dunkel.<br />
<br />
Beim Durchführen des Reboots wird die Stromversorgung zum Router unterbrochen und die rote Status-LED blinkt schnell. Nach 5 Sekunden beginnt der Lebenszyklus des Routers von Vorne (Off) und er darf wieder starten.<br />
<br />
Wozu der Aufwand?<br />
<br />
Der Router startet zwar recht schnell (etwa 40 Sekunden reine Bootzeit), benötigt im dümmsten Fall aber 1-2 Minuten, bis er wieder mit dem Freifunk-Netz verbunden ist.<br />
Daher sollen unnötige Reboots vermieden werden.<br />
<br />
Warum aber so lange Wartezeiten, bevor der Strom abgedreht wird?<br />
<br />
Auch hier: Vorsicht. Es gibt auch legitime Gründe, warum der Router einen "Crash" hinlegt. Dieser lässt sich nicht von einem (gewollten) Neustart unterscheiden, sei es ein Admin aus der Ferne oder ein Firmware-Update. Gerade letzteres sollte man nicht durch einen harten Neustart unterbrechen. Nach einem Test dauert der erste Start nach einem Update unter 90 Sekunden, mal hoffen, dass sich das auch so im Feld verhält - schließlich sitzen die Bewohner nicht gerne ohne Internet und ich stehe ungern vor verschlossenen Türen, wenn es etwas zu tun gibt.<br />
<br />
Damit nicht der Mikrocontroller zum Problemfall wird, ist der interne Watchdog permanent aktiviert und wird (mehr oder weniger sinnvoll) im Mainloop zurückgesetzt.<br />
<br />
==Einbau==<br />
Dafür, dass nach erstem Plan ein 3D-Druck-Gehäuse auf den Router geklebt werden sollte, hat sich ein fast idealer Platz im Gehäuse selbst gefunden - und auch für die Integration hatte Xiaomi ein Herz für Bastler. Oder zumindest beschlossen, dass ein 0-Ohm-Widerstand (R752) als Sicherung reicht. Mit dem nicht genutzten Verpolschutz (D12) gibt es auch ein Massepad direkt nebenan:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_input.jpg | Eingangsbeschaltung am Router<br />
</gallery><br />
<br />
An dieser Stelle sei angemerkt, dass man sicherlich auch den Enable/Shutdown-Pin des/der Regler hätte verwenden können, bei der unbekannten Beschaltung und den Widerständen im 0201-Gehäuse wawr es mir allerdings zu fummelig, dort einzugreifen.<br />
<br />
Den LEDs sieht man es mit scharfem Auge schon an, welche die orange und welche die blaue sein muss (wenn auch nicht unbedingt im Foto): Blaue LEDs haben (wie weiße) üblicherweise 2 Bond-Drähte, der ideale Abgriffpunkt ist zwischen Vorwiderstand und Kondensator:<br />
<br />
<gallery><br />
ff_rebooter_router_leds.jpg | Status-LEDs am Router<br />
ff_rebooter_router_leds_detail.jpg | Detail-Ansicht der Dual-LED<br />
ff_rebooter_router_leds_beschaltung.jpg | Abgriffpunkte für die LEDs<br />
</gallery><br />
<br />
Auf- und Eingebaut sieht es dann wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_einbau.jpg | Einbau des Rebooters im Router<br />
</gallery><br />
<br />
Im Foto fehlt noch der obligatorische Heißkleber. Der Kondensator des Implantates musste noch ein bisschen gebogen werden, damit er nicht mit dem Gehäusedeckel kollidiert. <br />
<br />
Die abgeschnittenen Drähte sind ein Überbleibsel der oben erwähnten Logging-Aktivitäten (und wurden noch gestutzt).<br />
<br />
Die verbaute supergrüne LED ist trotz niedrigem Strom recht hell - sie ist, obwohl nach unten gerichtet, durch das Gehäuse leicht sichtbar und projiziert einen deutlichen Lichtkeil unter den gelöcherten Gehäuseboden. Kann man auch als Feature betrachten.<br />
<br />
=Das Ergebnis=<br />
Die ersten Tests mit per Konsole abgesetzten Reboots und einem erzwungenen Update waren erfolgreich - bei der Gelegenheit wurde auch gleich die Debug-Ausgaben eines Lebenszyklus (leider ohne Timestamps) aufgezeichnet:<br />
<br />
<pre><br />
Built on: Apr 2 2023 21:47:12<br />
Target: off -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 1 crashes<br />
Target: crashed -> running<br />
Target: running, saw 1 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 2 crashes<br />
Target: crashed -> running<br />
Target: running, saw 2 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
Target: saw 3 crashes, reboot<br />
Target: crashed -> reboot<br />
LED bl: on<br />
Target: reboot -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
</pre><br />
<br />
Patient 1 ist zum Zeitpunkt der Erstellung dieses Artikels seit 7 Tagen im Einsatz, legte erst einmal einen Lauf von knapp 5 Tagen hin und brauchte dann in etwa in etwa alle 12-17 Stunden einen Tritt.<br />
Router 2 ist erst seit kurzer Zeit wieder am Netz und hat kurz nach dem Start mutmaßlich einen Crash auf dem anderen Router verursacht - zumindest gab es eine verdächtige Korrelation zwischen Einschalten von Router 2 und einem Crash von Router 1.<br />
<br />
Bei beiden Geräten wurden die Cronjobs für den nächtlichen Reboot deaktiviert.<br />
<br />
Andere Faktoren die Abstürze begünstigen sind mir aktuell nicht bekannt - bei beiden Geräten habe ich vor der Wiederinbetriebnahme ein Update erzwungen, bei einem auch manuell Caches geleert. Vielleicht bringt das was, vielleicht auch nicht.<br />
<br />
Auch gilt es noch WLAN-Mesh auf zumindest einem der Geräte zu deaktivieren, zumal beide über Kabel angebunden sind und Komplexität sicherlich nicht zur Stabilität beitragen.<br />
<br />
=Ausblick=<br />
Die Schaltung kann verkleinert und optimiert werden, alles Unnötige entfernt werden.<br />
Hintergedanke für den Levelshifter an der UART-Schnittstelle war, über die Menge an Ausgaben (oder Keywords) einen Absturz zu erkennen oder auch Rückmeldungen z. B. per HTTP-Request auf die Konsole zu injizieren.<br />
Geschadet hat das Vorsehen sicher nicht, dank der bisherigen Zuverlässigkeit der aktuellen Erkennungsmethode und Statistik-Tools von ffmuc ist das aber nicht nötig.<br />
<br />
Wenn die Geräte etwas länger wieder im Betrieb sind, wird es ein Update geben.<br />
<br />
Generell halte ich einen externen Watchdog für Geräte, auf die man keinen permanenten Zugriff hat, für essenziell. Besser wäre natürlich, wenn es gar nicht bräuchte - was ich nicht als Kritik an [https://ffmuc.net/ Freifunk München]/[https://github.com/freifunk-gluon/gluon Gluon]/[https://openwrt.org/ OpenWRT] meine. Die Projekte leben überwiegend von freiwilligen, die in ihrer Freizeit und Community mehr bewegen als manch kommerzielle Anbieter. <br />
<br />
=Downloads=<br />
* [[Datei:ff_rebooter_v0.1.zip]] Schaltplan & Layout im EAGLE-Format und Firmware als Microchip-Studio-Projekt<br />
<br />
[[Kategorie:AVR]]<br />
[[Kategorie:Netzwerk]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Freifunk-Rebooter&diff=1855Freifunk-Rebooter2023-04-11T20:17:39Z<p>Chris: /* Datensammeln */ das mit dem Video einbetten üben wir nochmal...</p>
<hr />
<div>=Ausgangssituation=<br />
<br />
In unseren Flüchtlingsunterkünften stehen mehrere Xiaomi Mi Router 4A Gigabit Edition, die mit der Freifunk-München-Firmware bespielt sind. <br />
Wer Freifunk nicht kennt, kann und sollte am besten sich in der [[wpde:Freifunk|Wikipedia]] informieren.<br />
<br />
Was am Anfang noch recht gut funktionierte, wurde mit der Zeit immer instabiler. Ein Cronjob zum nächtlichen Neustart brachte zwar Besserung, aber nach ein paar Tagen gingen die Router in eine Bootloop.<br />
<br />
Um den Fehler besser zu verstehen, wurde zeitweise ein [https://hobbyelektronik.org/b/2022/10/uart-logging-mit-linux/ Raspberry Pi zum Protokollieren] abgestellt. Als jemand, der von Linux nur rudimentäres Wissen besitzt, sahen die Meldungen so aus, als könne der SoC einen der WLAN-Chips nicht mehr initialisieren und schoss sich ins Nirwana. Blöd: ein Reboot richtet das nicht, Dokumentation für die Chips hängt wohl hinter der NDA-Mauer und einen hard-reset scheint es nicht zu geben.<br />
<br />
Nach einem kurzen Austausch im Chat der Freifunker gab es ein Ticket bei OpenWRT und nach einigen paar Tagen auch eine Experimental-Firmware, die den Fehler beheben sollte. Sollte.<br />
<br />
Ein paar Tage später stand bei Grafana für die Knoten wieder "no data", dafür gab es Klagen aus der Unterkunft. Einer der Router steht hinter für die dauerhaft verschlossener Tür, der andere in einem Zimmer dessen Bewohner auch mal ein paar Tage nicht da sind (und absperren).<br />
<br />
=Lösungsansätze=<br />
<br />
Kurz den/die entsprechenden LS-Schalter zu werfen ist leider auch keine Option. Das genauere Warum habe ich nicht weiter hinterfragt, das muss man einfach als gegeben annehmen.<br />
<br />
Dabei ist Strom trennen einfach wie effektiv. Eine Zeitschaltuhr würde helfen, die billigeren haben aber recht grobe Zeitraster und dementsprechend lange Ausfallzeiten. Auch kann es natürlich gleich nach einem Zwangsneustart gleich wieder zu Problemen kommen und die Wartezeit zum nächsten Neustart wird unnötig lang.<br />
<br />
Zwischenstecker mit Tasmota o. ä. würden zwar das Problem mit der Ausschaltzeit lösen, hätten aber wenig Chancen gegen Problem 2. Zwar könnten diese checken, ob das WLAN wegfällt, die Unterkunft wird allerdings durch mehrere Freifunk-Router (mit gleicher SSID) versorgt. Unnötig viel Komplexität.<br />
<br />
=Die Idee=<br />
<br />
Man sieht es den Routern von außen an, wenn sie abschmieren – im Betrieb leuchtet die Power-LED permanent blau, bei einem Crash bzw. Bootloop blinkt sie orange vor sich hin. Mit ein bisschen Mustererkennung erkennt man sogar die Phasen.<br />
<br />
Warum also nicht einen kleinen Mikrocontroller auf die Status-LED(s) schauen lassen und das "have you tried to turn it off and on again"-Spiel spielen lassen?<br />
<br />
==Datensammeln==<br />
<br />
Am Anfang war die Beobachtung: In einem kleinen WhatsApp-Video bekam ich das unheilvolle orange blinken von einem Vereinsmitglied; ein paar Sekunden sind jedoch noch nicht die ganze Geschichte, deshalb holte ich mir einen der Router nach Hause und nahm ein Video von einem Kaltstart des Gerätes auf und wartete ein bisschen.<br />
<br />
Ein paar Tage am Netz und siehe da: ohne Zutun von außen blinkt die Power-LED orange. Also nochmal die Kamera raus, Aufnahme und einige Minuten laufen lassen.<br />
<br />
Als Referenz gab es dann noch ein Video von einem erfolgreichen Start:<br />
<br />
[[Datei:ff_rebooter_xiaomi_start.mp4]]<br />
<br />
Mit den Videos kann man sich die Mäusedisco nun wieder und wieder ansehen, Bild für Bild durchgehen und die Blinkzyklen aufschreiben, oder man ist faul und fragt ChatGPT, wie man mit Python die Farben von Pixeln in Videos ermittelt. Ok, das ist wirklich keine rocket science (und einfach nur in der Doku von OpenCV zu stöbern hätte gereicht), aber schon erstaunlich, was Wortstatistik auf Steroiden leisten kann.<br />
<br />
==Videoauswertung==<br />
<br />
Für den ersten Eindruck ist die Herangehensweise eher unakademisch - das Beispiel vom Chatbot wird angepasst, damit an zwei Punkten - Power- und Link-LED - die Farben ermittelt werden, diese werden als Zellenhintergrund für eine HTML-Tabelle ausgegeben. Einfach wie fatal.<br />
<br />
Um nicht nur einen Pixel zu sampeln, wird jeder Frame um den Faktor 16 dezimiert - statt 1280x720 wird also ein Bild der Größe 80x45 verwendet. Das macht den Prozess nicht schneller, dafür werden Rauschen und Überstrahlungseffekte etwas reduziert.<br />
<br />
<source lang="python"><br />
import cv2<br />
video = cv2.VideoCapture("S1040005.MP4")<br />
<br />
frame_decimation = 16<br />
frame_skip = 1<br />
probe_points = [[970, 173], [1039, 168]]<br />
<br />
framecnt = int(video.get(cv2.CAP_PROP_FRAME_COUNT))<br />
print(framecnt)<br />
<br />
print("<style> body { background-color: black; } td { width: 20px; height: 1px; } </style>")<br />
print("<table style=\"border-collapse: collapse;\">")<br />
<br />
for frame_number in range(0, framecnt, frame_skip):<br />
video.set(1, frame_number)<br />
<br />
# Read the frame<br />
success, frame = video.read()<br />
newsize = (int(frame.shape[1] / frame_decimation), int(frame.shape[0] / frame_decimation))<br />
resized = cv2.resize(frame, newsize, interpolation = cv2.INTER_AREA)<br />
<br />
# Get the color of the pixel at the given location<br />
cols = []<br />
for point in probe_points:<br />
(b, g, r) = resized[int(point[1]/frame_decimation), int(point[0] / frame_decimation)]<br />
cols.append(f"#{r:02X}{g:02X}{b:02X}")<br />
<br />
#print("\t".join(cols))<br />
print("<tr>" + "".join(map(lambda x : f"<td style=\"background-color: {x}\"> </td>", cols)) + "</tr>")<br />
<br />
print("</table>")<br />
video.release()<br />
</source><br />
<br />
Bei Videomaterial mit 25 fps (was zugegebenermaßen etwas wenig ist), sieht ein etwas längerer Ausschnitt des Videos oben wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_start.png | Start des Xiaomi-Routers<br />
</gallery><br />
<br />
Links, wie im Video oben, die Power-LED, rechts die Link-LED. Wie aus dem Quellcode ersichtlich sein sollte, entspricht bei frame_skip = 1 jedes Frame ein Pixel in y-Richtung bei 25 fps. "Misst" man die Pixel vom ersten Lebenszeichen der linken LED bis sie blau wird, "vergehen" 1840 Pixel und somit 73,6 s - nicht ganz. Weil HTML ist das was man eingibt nicht unbedingt das, was angezeigt wird. Laut Konsole ist jeder oben angegebene Pixel 2px in der Darstellung, somit beträgt die Boot-Zeit 36,8 s. <br />
<br />
Der Bootloop ist nicht spektakulärer, er ist lediglich die immerwährende Wiederholung des "orangen" Parts.<br />
<br />
=Umsetzung=<br />
==Hardware==<br />
Der erste Gedanke war, die Hardware minimalinvasiv aufzubauen: Nachdem es Dauerlicht nur gibt, wenn die Kiste läuft, ist die Farbe irrelevant. Blinkt etwas länger, ist etwas im Argen. Also warum nicht einfach einen Fototransistor anflanschen, die Helligkeit auswerten und wenn längeres Blinken herrscht denk Anker werfen?<br />
<br />
Es scheitert wie immer an der Realität. Die ersten Versuche waren aussichtsreich, mit Umgebungslicht und nicht exakt platziertem Fototransistor war die Freude aber recht schnell wieder vorbei.<br />
<br />
Für die ersten Versuche auf dem Breadboard hat es zumindest gereicht.<br />
<br />
Um nicht extra Teile bestellen zu müssen, wurde das eingeplant, was herum liegt, Herzstück ist ein (völlig überdimensionierter) ATmega8A, der Signale zweier Fototransistoren im SMD-Package, aber auch in der THT-Version in Form von BPW40 entgegennimmt.<br />
<br />
Um beide LEDs am Router erfassen zu können, sind diese im Abstand von 15 mm zueinander platziert.<br />
<br />
Auf der anderen Seite des Mikrocontrollers hängen p-Kanal FETs sowohl im SO-8- als auch SOT-23-Gehäuse, über die die Versorgung des Routers geschaltet wird.<br />
<br />
Um evtl. doch noch einen UART mit abweichender Spannung (und Domäne) anbinden zu können, noch zwei einfache Levelshifter dazu und ab auf eine Leiterkarte damit.<br />
<br />
Noch zwei Status-LEDs dazu und fertig ist der Lack.<br />
<br />
Recht viel Optionales, aber eine zweiten Leiterkarten-Spin zu fahren: #gerkeinbock<br />
<br />
Leiterkarten-Spin? Ja, mittlerweile bin ich echt zu faul, etwas auf Lochraster aufzubauen - zumal so gut wie alle Bauteile im SMD-Package daherkommen.<br />
<br />
Der zusammengeklöppelte Schaltplan, Layout und der Aufbau sehen wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_sch.png | Schaltplan<br />
ff_rebooter_pcb.png | Layout der Leiterkarte<br />
ff_rebooter_pcb_top.jpg | Bestückte Oberseite<br />
ff_rebooter_pcb_bot.jpg | Bestückte Unterseite<br />
</gallery><br />
<br />
===BOM & Nachbau===<br />
Nachdem die Hardware schnell-schnell zusammengeklöppelt wurde, ist aktuell keine BOM und genauere Details vorgesehen. Wer sie dennoch möchte, kann sie gerne aus den EAGLE-Daten erzeugen oder mich anschreiben.<br />
<br />
==Firmware==<br />
Die Software hat im Prinzip nur eine Aufgabe: Blinkt die Power LED länger als x Sekunden, wird die Stromversorgung für y Sekunden unterbrochen.<br />
<br />
"Genau das, nur etwas komplizierter!"<br />
<br />
Zunächst gilt die Frage zu klären: Wann blinkt was, wann ist es statisch an, wann aus?<br />
<br />
===ADC===<br />
<br />
Vorher muss aber erst noch geklärt werden: Wann ist eine LED überhaupt an?<br />
Mit den vorhin erwähnten Fototransistoren muss man das Umgebungslicht filtern. Ist die LED länger statisch und das Licht "außenrum" ändert sich, oder es verrutscht etwas leicht, verpasst man vielleicht, dass sich etwas ändert.<br />
<br />
Kann man filtern, kann man aber auch von Grund auf vermeiden. auch wenn die Elektronik dafür vorgesehen ist: man muss die optischen Sensoren nicht verwenden, sondern kann auch einfach auf die Ansteuerung der LEDs gehen. Diese erfolgt jedoch nicht mit boardähnlichen 5 V, sondern mit 3,3 V, was für die Eingänge etwas knapp werden kann. Also kommt doch der ADC zum Einsatz, wenn auch etwas vereinfacht: zwei Schwellenwerte, dazwischen eine Hysterese, fertig.<br />
<br />
Einen Schritt zurück: Der Analog zu Digital-Wandler durchläuft, nachdem das "Subsystem" getriggert wurde alle ausgewählten Kanäle, was etwa jede Millisekunde geschieht.<br />
<br />
Schwellenwertvergleich und ab mit einem true oder false in die LED-Detektion.<br />
<br />
===LED-Detektion===<br />
<br />
Diese schaut, ob sich was am Zustand des Einganges ändert und zählt die entsprechende Zeit. Wechselt der Zustand nach "0" (false) wird erst einmal blinkend angenommen, bleibt der Zustand für länger als <code>LEDDET_TIMEOUT</code> (750 ms) konstant, wird "statisch aus" respektive "an" angenommen.<br />
<br />
Das Ganze wird für die rote und blaue LED der "Power-LED" gemacht...<br />
<br />
===Zustandsautomat===<br />
... und im "Target"-Zustandsautomaten verwurstet, der zunächst auf Papier entstand und nach der Implementierung auf dem PC nachgezeichnet wurde:<br />
<br />
<gallery><br />
ff_rebooter_fsm.png | Zustandsautomat für das "Target"<br />
</gallery><br />
<br />
Nach dem Einschalten geht die Maschine zunächst in den Off-Zustand - hauptsächlich um die Realität abzubilden. Beim Startup wird die Stromversorgung für den Router eingeschaltet und die grüne LED blinkt vor sich hin.<br />
<br />
Sobald für länger als 2 Sekunden die orange LED des Routers erloschen ist und die blaue leuchtet, wird angenommen dass der Router läuft. Ist das nach 90 Sekunden am Strom nicht der Fall, wird ein Crash angenommen und ein harter Reboot eingeleitet (mehr dazu später).<br />
<br />
Im Zustand Running gibt es zwei Varianten für die eigenen Status-LEDs: In jedem Fall leuchtet die grüne LED dauerhaft, wurde vorher ein Crash "erkannt", blitzt zusätzlich die rote LED auf.<br />
<br />
Sollte nun am Router die orange LED an gehen oder blinken und die die blaue LED nicht an sein, gibt es einen Crashverdacht; allerdings erst, wenn dies für über 2 Sekunden mit "Waterlevel" der Fall ist. Mit Waterlevel ist gemeint, dass im "Verdachtszustand" ein Zähler hochgezählt wird. Ist der "Verdacht" vorbei, wird dieser Zähler nicht auf Null zurückgesetzt, sondern lediglich verringert. So kann ein instabiler Zustand etwas besser erkannt werden.<br />
<br />
Erhärtet sich der Crashverdacht, wird ein interner Zähler für die Verdachtsfälle hochgezählt, erreicht dieser die magische Anzahl 3 oder bleibt der Zustand für über 90 Sekunden, wird ein Neustart eingeleitet. "Fängt" sich der Router wieder, sprich: die blaue LED leuchtet konstant und die orange ist aus, wechselt der Zustand nach 5 Sekunden wieder nach Running. Allerdings hier ohne Waterlevel. Lieber einen harten Neustart als im Limbus zwischen Running und Crashed hängen bleiben.<br />
Da beim erhärteten Crashverdacht vermutlich nix mehr geht, darf nun die rote Status-LED blinken, die grüne bleibt dunkel.<br />
<br />
Beim Durchführen des Reboots wird die Stromversorgung zum Router unterbrochen und die rote Status-LED blinkt schnell. Nach 5 Sekunden beginnt der Lebenszyklus des Routers von Vorne (Off) und er darf wieder starten.<br />
<br />
Wozu der Aufwand?<br />
<br />
Der Router startet zwar recht schnell (etwa 40 Sekunden reine Bootzeit), benötigt im dümmsten Fall aber 1-2 Minuten, bis er wieder mit dem Freifunk-Netz verbunden ist.<br />
Daher sollen unnötige Reboots vermieden werden.<br />
<br />
Warum aber so lange Wartezeiten, bevor der Strom abgedreht wird?<br />
<br />
Auch hier: Vorsicht. Es gibt auch legitime Gründe, warum der Router einen "Crash" hinlegt. Dieser lässt sich nicht von einem (gewollten) Neustart unterscheiden, sei es ein Admin aus der Ferne oder ein Firmware-Update. Gerade letzteres sollte man nicht durch einen harten Neustart unterbrechen. Nach einem Test dauert der erste Start nach einem Update unter 90 Sekunden, mal hoffen, dass sich das auch so im Feld verhält - schließlich sitzen die Bewohner nicht gerne ohne Internet und ich stehe ungern vor verschlossenen Türen, wenn es etwas zu tun gibt.<br />
<br />
Damit nicht der Mikrocontroller zum Problemfall wird, ist der interne Watchdog permanent aktiviert und wird (mehr oder weniger sinnvoll) im Mainloop zurückgesetzt.<br />
<br />
==Einbau==<br />
Dafür, dass nach erstem Plan ein 3D-Druck-Gehäuse auf den Router geklebt werden sollte, hat sich ein fast idealer Platz im Gehäuse selbst gefunden - und auch für die Integration hatte Xiaomi ein Herz für Bastler. Oder zumindest beschlossen, dass ein 0-Ohm-Widerstand (R752) als Sicherung reicht. Mit dem nicht genutzten Verpolschutz (D12) gibt es auch ein Massepad direkt nebenan:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_input.jpg | Eingangsbeschaltung am Router<br />
</gallery><br />
<br />
An dieser Stelle sei angemerkt, dass man sicherlich auch den Enable/Shutdown-Pin des/der Regler hätte verwenden können, bei der unbekannten Beschaltung und den Widerständen im 0201-Gehäuse wawr es mir allerdings zu fummelig, dort einzugreifen.<br />
<br />
Den LEDs sieht man es mit scharfem Auge schon an, welche die orange und welche die blaue sein muss (wenn auch nicht unbedingt im Foto): Blaue LEDs haben (wie weiße) üblicherweise 2 Bond-Drähte, der ideale Abgriffpunkt ist zwischen Vorwiderstand und Kondensator:<br />
<br />
<gallery><br />
ff_rebooter_router_leds.jpg | Status-LEDs am Router<br />
ff_rebooter_router_leds_detail.jpg | Detail-Ansicht der Dual-LED<br />
ff_rebooter_router_leds_beschaltung.jpg | Abgriffpunkte für die LEDs<br />
</gallery><br />
<br />
Auf- und Eingebaut sieht es dann wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_einbau.jpg | Einbau des Rebooters im Router<br />
</gallery><br />
<br />
Im Foto fehlt noch der obligatorische Heißkleber. Der Kondensator des Implantates musste noch ein bisschen gebogen werden, damit er nicht mit dem Gehäusedeckel kollidiert. <br />
<br />
Die abgeschnittenen Drähte sind ein Überbleibsel der oben erwähnten Logging-Aktivitäten (und wurden noch gestutzt).<br />
<br />
Die verbaute supergrüne LED ist trotz niedrigem Strom recht hell - sie ist, obwohl nach unten gerichtet, durch das Gehäuse leicht sichtbar und projiziert einen deutlichen Lichtkeil unter den gelöcherten Gehäuseboden. Kann man auch als Feature betrachten.<br />
<br />
=Das Ergebnis=<br />
Die ersten Tests mit per Konsole abgesetzten Reboots und einem erzwungenen Update waren erfolgreich - bei der Gelegenheit wurde auch gleich die Debug-Ausgaben eines Lebenszyklus (leider ohne Timestamps) aufgezeichnet:<br />
<br />
<pre><br />
Built on: Apr 2 2023 21:47:12<br />
Target: off -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 1 crashes<br />
Target: crashed -> running<br />
Target: running, saw 1 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 2 crashes<br />
Target: crashed -> running<br />
Target: running, saw 2 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
Target: saw 3 crashes, reboot<br />
Target: crashed -> reboot<br />
LED bl: on<br />
Target: reboot -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
</pre><br />
<br />
Patient 1 ist zum Zeitpunkt der Erstellung dieses Artikels seit 7 Tagen im Einsatz, legte erst einmal einen Lauf von knapp 5 Tagen hin und brauchte dann in etwa in etwa alle 12-17 Stunden einen Tritt.<br />
Router 2 ist erst seit kurzer Zeit wieder am Netz und hat kurz nach dem Start mutmaßlich einen Crash auf dem anderen Router verursacht - zumindest gab es eine verdächtige Korrelation zwischen Einschalten von Router 2 und einem Crash von Router 1.<br />
<br />
Bei beiden Geräten wurden die Cronjobs für den nächtlichen Reboot deaktiviert.<br />
<br />
Andere Faktoren die Abstürze begünstigen sind mir aktuell nicht bekannt - bei beiden Geräten habe ich vor der Wiederinbetriebnahme ein Update erzwungen, bei einem auch manuell Caches geleert. Vielleicht bringt das was, vielleicht auch nicht.<br />
<br />
Auch gilt es noch WLAN-Mesh auf zumindest einem der Geräte zu deaktivieren, zumal beide über Kabel angebunden sind und Komplexität sicherlich nicht zur Stabilität beitragen.<br />
<br />
=Ausblick=<br />
Die Schaltung kann verkleinert und optimiert werden, alles Unnötige entfernt werden.<br />
Hintergedanke für den Levelshifter an der UART-Schnittstelle war, über die Menge an Ausgaben (oder Keywords) einen Absturz zu erkennen oder auch Rückmeldungen z. B. per HTTP-Request auf die Konsole zu injizieren.<br />
Geschadet hat das Vorsehen sicher nicht, dank der bisherigen Zuverlässigkeit der aktuellen Erkennungsmethode und Statistik-Tools von ffmuc ist das aber nicht nötig.<br />
<br />
Wenn die Geräte etwas länger wieder im Betrieb sind, wird es ein Update geben.<br />
<br />
Generell halte ich einen externen Watchdog für Geräte, auf die man keinen permanenten Zugriff hat, für essenziell. Besser wäre natürlich, wenn es gar nicht bräuchte - was ich nicht als Kritik an [https://ffmuc.net/ Freifunk München]/[https://github.com/freifunk-gluon/gluon Gluon]/[https://openwrt.org/ OpenWRT] meine. Die Projekte leben überwiegend von freiwilligen, die in ihrer Freizeit und Community mehr bewegen als manch kommerzielle Anbieter. <br />
<br />
=Downloads=<br />
* [[ff_rebooter_v0.1.zip]] Schaltplan & Layout im EAGLE-Format und Firmware als Microchip-Studio-Projekt<br />
<br />
[[Kategorie:AVR]]<br />
[[Kategorie:Netzwerk]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Freifunk-Rebooter&diff=1854Freifunk-Rebooter2023-04-11T20:16:15Z<p>Chris: /* Datensammeln */</p>
<hr />
<div>=Ausgangssituation=<br />
<br />
In unseren Flüchtlingsunterkünften stehen mehrere Xiaomi Mi Router 4A Gigabit Edition, die mit der Freifunk-München-Firmware bespielt sind. <br />
Wer Freifunk nicht kennt, kann und sollte am besten sich in der [[wpde:Freifunk|Wikipedia]] informieren.<br />
<br />
Was am Anfang noch recht gut funktionierte, wurde mit der Zeit immer instabiler. Ein Cronjob zum nächtlichen Neustart brachte zwar Besserung, aber nach ein paar Tagen gingen die Router in eine Bootloop.<br />
<br />
Um den Fehler besser zu verstehen, wurde zeitweise ein [https://hobbyelektronik.org/b/2022/10/uart-logging-mit-linux/ Raspberry Pi zum Protokollieren] abgestellt. Als jemand, der von Linux nur rudimentäres Wissen besitzt, sahen die Meldungen so aus, als könne der SoC einen der WLAN-Chips nicht mehr initialisieren und schoss sich ins Nirwana. Blöd: ein Reboot richtet das nicht, Dokumentation für die Chips hängt wohl hinter der NDA-Mauer und einen hard-reset scheint es nicht zu geben.<br />
<br />
Nach einem kurzen Austausch im Chat der Freifunker gab es ein Ticket bei OpenWRT und nach einigen paar Tagen auch eine Experimental-Firmware, die den Fehler beheben sollte. Sollte.<br />
<br />
Ein paar Tage später stand bei Grafana für die Knoten wieder "no data", dafür gab es Klagen aus der Unterkunft. Einer der Router steht hinter für die dauerhaft verschlossener Tür, der andere in einem Zimmer dessen Bewohner auch mal ein paar Tage nicht da sind (und absperren).<br />
<br />
=Lösungsansätze=<br />
<br />
Kurz den/die entsprechenden LS-Schalter zu werfen ist leider auch keine Option. Das genauere Warum habe ich nicht weiter hinterfragt, das muss man einfach als gegeben annehmen.<br />
<br />
Dabei ist Strom trennen einfach wie effektiv. Eine Zeitschaltuhr würde helfen, die billigeren haben aber recht grobe Zeitraster und dementsprechend lange Ausfallzeiten. Auch kann es natürlich gleich nach einem Zwangsneustart gleich wieder zu Problemen kommen und die Wartezeit zum nächsten Neustart wird unnötig lang.<br />
<br />
Zwischenstecker mit Tasmota o. ä. würden zwar das Problem mit der Ausschaltzeit lösen, hätten aber wenig Chancen gegen Problem 2. Zwar könnten diese checken, ob das WLAN wegfällt, die Unterkunft wird allerdings durch mehrere Freifunk-Router (mit gleicher SSID) versorgt. Unnötig viel Komplexität.<br />
<br />
=Die Idee=<br />
<br />
Man sieht es den Routern von außen an, wenn sie abschmieren – im Betrieb leuchtet die Power-LED permanent blau, bei einem Crash bzw. Bootloop blinkt sie orange vor sich hin. Mit ein bisschen Mustererkennung erkennt man sogar die Phasen.<br />
<br />
Warum also nicht einen kleinen Mikrocontroller auf die Status-LED(s) schauen lassen und das "have you tried to turn it off and on again"-Spiel spielen lassen?<br />
<br />
==Datensammeln==<br />
<br />
Am Anfang war die Beobachtung: In einem kleinen WhatsApp-Video bekam ich das unheilvolle orange blinken von einem Vereinsmitglied; ein paar Sekunden sind jedoch noch nicht die ganze Geschichte, deshalb holte ich mir einen der Router nach Hause und nahm ein Video von einem Kaltstart des Gerätes auf und wartete ein bisschen.<br />
<br />
Ein paar Tage am Netz und siehe da: ohne Zutun von außen blinkt die Power-LED orange. Also nochmal die Kamera raus, Aufnahme und einige Minuten laufen lassen.<br />
<br />
Als Referenz gab es dann noch ein Video von einem erfolgreichen Start:<br />
<br />
[Datei:ff_rebooter_xiaomi_start.mp4]<br />
<br />
Mit den Videos kann man sich die Mäusedisco nun wieder und wieder ansehen, Bild für Bild durchgehen und die Blinkzyklen aufschreiben, oder man ist faul und fragt ChatGPT, wie man mit Python die Farben von Pixeln in Videos ermittelt. Ok, das ist wirklich keine rocket science (und einfach nur in der Doku von OpenCV zu stöbern hätte gereicht), aber schon erstaunlich, was Wortstatistik auf Steroiden leisten kann.<br />
<br />
==Videoauswertung==<br />
<br />
Für den ersten Eindruck ist die Herangehensweise eher unakademisch - das Beispiel vom Chatbot wird angepasst, damit an zwei Punkten - Power- und Link-LED - die Farben ermittelt werden, diese werden als Zellenhintergrund für eine HTML-Tabelle ausgegeben. Einfach wie fatal.<br />
<br />
Um nicht nur einen Pixel zu sampeln, wird jeder Frame um den Faktor 16 dezimiert - statt 1280x720 wird also ein Bild der Größe 80x45 verwendet. Das macht den Prozess nicht schneller, dafür werden Rauschen und Überstrahlungseffekte etwas reduziert.<br />
<br />
<source lang="python"><br />
import cv2<br />
video = cv2.VideoCapture("S1040005.MP4")<br />
<br />
frame_decimation = 16<br />
frame_skip = 1<br />
probe_points = [[970, 173], [1039, 168]]<br />
<br />
framecnt = int(video.get(cv2.CAP_PROP_FRAME_COUNT))<br />
print(framecnt)<br />
<br />
print("<style> body { background-color: black; } td { width: 20px; height: 1px; } </style>")<br />
print("<table style=\"border-collapse: collapse;\">")<br />
<br />
for frame_number in range(0, framecnt, frame_skip):<br />
video.set(1, frame_number)<br />
<br />
# Read the frame<br />
success, frame = video.read()<br />
newsize = (int(frame.shape[1] / frame_decimation), int(frame.shape[0] / frame_decimation))<br />
resized = cv2.resize(frame, newsize, interpolation = cv2.INTER_AREA)<br />
<br />
# Get the color of the pixel at the given location<br />
cols = []<br />
for point in probe_points:<br />
(b, g, r) = resized[int(point[1]/frame_decimation), int(point[0] / frame_decimation)]<br />
cols.append(f"#{r:02X}{g:02X}{b:02X}")<br />
<br />
#print("\t".join(cols))<br />
print("<tr>" + "".join(map(lambda x : f"<td style=\"background-color: {x}\"> </td>", cols)) + "</tr>")<br />
<br />
print("</table>")<br />
video.release()<br />
</source><br />
<br />
Bei Videomaterial mit 25 fps (was zugegebenermaßen etwas wenig ist), sieht ein etwas längerer Ausschnitt des Videos oben wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_start.png | Start des Xiaomi-Routers<br />
</gallery><br />
<br />
Links, wie im Video oben, die Power-LED, rechts die Link-LED. Wie aus dem Quellcode ersichtlich sein sollte, entspricht bei frame_skip = 1 jedes Frame ein Pixel in y-Richtung bei 25 fps. "Misst" man die Pixel vom ersten Lebenszeichen der linken LED bis sie blau wird, "vergehen" 1840 Pixel und somit 73,6 s - nicht ganz. Weil HTML ist das was man eingibt nicht unbedingt das, was angezeigt wird. Laut Konsole ist jeder oben angegebene Pixel 2px in der Darstellung, somit beträgt die Boot-Zeit 36,8 s. <br />
<br />
Der Bootloop ist nicht spektakulärer, er ist lediglich die immerwährende Wiederholung des "orangen" Parts.<br />
<br />
=Umsetzung=<br />
==Hardware==<br />
Der erste Gedanke war, die Hardware minimalinvasiv aufzubauen: Nachdem es Dauerlicht nur gibt, wenn die Kiste läuft, ist die Farbe irrelevant. Blinkt etwas länger, ist etwas im Argen. Also warum nicht einfach einen Fototransistor anflanschen, die Helligkeit auswerten und wenn längeres Blinken herrscht denk Anker werfen?<br />
<br />
Es scheitert wie immer an der Realität. Die ersten Versuche waren aussichtsreich, mit Umgebungslicht und nicht exakt platziertem Fototransistor war die Freude aber recht schnell wieder vorbei.<br />
<br />
Für die ersten Versuche auf dem Breadboard hat es zumindest gereicht.<br />
<br />
Um nicht extra Teile bestellen zu müssen, wurde das eingeplant, was herum liegt, Herzstück ist ein (völlig überdimensionierter) ATmega8A, der Signale zweier Fototransistoren im SMD-Package, aber auch in der THT-Version in Form von BPW40 entgegennimmt.<br />
<br />
Um beide LEDs am Router erfassen zu können, sind diese im Abstand von 15 mm zueinander platziert.<br />
<br />
Auf der anderen Seite des Mikrocontrollers hängen p-Kanal FETs sowohl im SO-8- als auch SOT-23-Gehäuse, über die die Versorgung des Routers geschaltet wird.<br />
<br />
Um evtl. doch noch einen UART mit abweichender Spannung (und Domäne) anbinden zu können, noch zwei einfache Levelshifter dazu und ab auf eine Leiterkarte damit.<br />
<br />
Noch zwei Status-LEDs dazu und fertig ist der Lack.<br />
<br />
Recht viel Optionales, aber eine zweiten Leiterkarten-Spin zu fahren: #gerkeinbock<br />
<br />
Leiterkarten-Spin? Ja, mittlerweile bin ich echt zu faul, etwas auf Lochraster aufzubauen - zumal so gut wie alle Bauteile im SMD-Package daherkommen.<br />
<br />
Der zusammengeklöppelte Schaltplan, Layout und der Aufbau sehen wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_sch.png | Schaltplan<br />
ff_rebooter_pcb.png | Layout der Leiterkarte<br />
ff_rebooter_pcb_top.jpg | Bestückte Oberseite<br />
ff_rebooter_pcb_bot.jpg | Bestückte Unterseite<br />
</gallery><br />
<br />
===BOM & Nachbau===<br />
Nachdem die Hardware schnell-schnell zusammengeklöppelt wurde, ist aktuell keine BOM und genauere Details vorgesehen. Wer sie dennoch möchte, kann sie gerne aus den EAGLE-Daten erzeugen oder mich anschreiben.<br />
<br />
==Firmware==<br />
Die Software hat im Prinzip nur eine Aufgabe: Blinkt die Power LED länger als x Sekunden, wird die Stromversorgung für y Sekunden unterbrochen.<br />
<br />
"Genau das, nur etwas komplizierter!"<br />
<br />
Zunächst gilt die Frage zu klären: Wann blinkt was, wann ist es statisch an, wann aus?<br />
<br />
===ADC===<br />
<br />
Vorher muss aber erst noch geklärt werden: Wann ist eine LED überhaupt an?<br />
Mit den vorhin erwähnten Fototransistoren muss man das Umgebungslicht filtern. Ist die LED länger statisch und das Licht "außenrum" ändert sich, oder es verrutscht etwas leicht, verpasst man vielleicht, dass sich etwas ändert.<br />
<br />
Kann man filtern, kann man aber auch von Grund auf vermeiden. auch wenn die Elektronik dafür vorgesehen ist: man muss die optischen Sensoren nicht verwenden, sondern kann auch einfach auf die Ansteuerung der LEDs gehen. Diese erfolgt jedoch nicht mit boardähnlichen 5 V, sondern mit 3,3 V, was für die Eingänge etwas knapp werden kann. Also kommt doch der ADC zum Einsatz, wenn auch etwas vereinfacht: zwei Schwellenwerte, dazwischen eine Hysterese, fertig.<br />
<br />
Einen Schritt zurück: Der Analog zu Digital-Wandler durchläuft, nachdem das "Subsystem" getriggert wurde alle ausgewählten Kanäle, was etwa jede Millisekunde geschieht.<br />
<br />
Schwellenwertvergleich und ab mit einem true oder false in die LED-Detektion.<br />
<br />
===LED-Detektion===<br />
<br />
Diese schaut, ob sich was am Zustand des Einganges ändert und zählt die entsprechende Zeit. Wechselt der Zustand nach "0" (false) wird erst einmal blinkend angenommen, bleibt der Zustand für länger als <code>LEDDET_TIMEOUT</code> (750 ms) konstant, wird "statisch aus" respektive "an" angenommen.<br />
<br />
Das Ganze wird für die rote und blaue LED der "Power-LED" gemacht...<br />
<br />
===Zustandsautomat===<br />
... und im "Target"-Zustandsautomaten verwurstet, der zunächst auf Papier entstand und nach der Implementierung auf dem PC nachgezeichnet wurde:<br />
<br />
<gallery><br />
ff_rebooter_fsm.png | Zustandsautomat für das "Target"<br />
</gallery><br />
<br />
Nach dem Einschalten geht die Maschine zunächst in den Off-Zustand - hauptsächlich um die Realität abzubilden. Beim Startup wird die Stromversorgung für den Router eingeschaltet und die grüne LED blinkt vor sich hin.<br />
<br />
Sobald für länger als 2 Sekunden die orange LED des Routers erloschen ist und die blaue leuchtet, wird angenommen dass der Router läuft. Ist das nach 90 Sekunden am Strom nicht der Fall, wird ein Crash angenommen und ein harter Reboot eingeleitet (mehr dazu später).<br />
<br />
Im Zustand Running gibt es zwei Varianten für die eigenen Status-LEDs: In jedem Fall leuchtet die grüne LED dauerhaft, wurde vorher ein Crash "erkannt", blitzt zusätzlich die rote LED auf.<br />
<br />
Sollte nun am Router die orange LED an gehen oder blinken und die die blaue LED nicht an sein, gibt es einen Crashverdacht; allerdings erst, wenn dies für über 2 Sekunden mit "Waterlevel" der Fall ist. Mit Waterlevel ist gemeint, dass im "Verdachtszustand" ein Zähler hochgezählt wird. Ist der "Verdacht" vorbei, wird dieser Zähler nicht auf Null zurückgesetzt, sondern lediglich verringert. So kann ein instabiler Zustand etwas besser erkannt werden.<br />
<br />
Erhärtet sich der Crashverdacht, wird ein interner Zähler für die Verdachtsfälle hochgezählt, erreicht dieser die magische Anzahl 3 oder bleibt der Zustand für über 90 Sekunden, wird ein Neustart eingeleitet. "Fängt" sich der Router wieder, sprich: die blaue LED leuchtet konstant und die orange ist aus, wechselt der Zustand nach 5 Sekunden wieder nach Running. Allerdings hier ohne Waterlevel. Lieber einen harten Neustart als im Limbus zwischen Running und Crashed hängen bleiben.<br />
Da beim erhärteten Crashverdacht vermutlich nix mehr geht, darf nun die rote Status-LED blinken, die grüne bleibt dunkel.<br />
<br />
Beim Durchführen des Reboots wird die Stromversorgung zum Router unterbrochen und die rote Status-LED blinkt schnell. Nach 5 Sekunden beginnt der Lebenszyklus des Routers von Vorne (Off) und er darf wieder starten.<br />
<br />
Wozu der Aufwand?<br />
<br />
Der Router startet zwar recht schnell (etwa 40 Sekunden reine Bootzeit), benötigt im dümmsten Fall aber 1-2 Minuten, bis er wieder mit dem Freifunk-Netz verbunden ist.<br />
Daher sollen unnötige Reboots vermieden werden.<br />
<br />
Warum aber so lange Wartezeiten, bevor der Strom abgedreht wird?<br />
<br />
Auch hier: Vorsicht. Es gibt auch legitime Gründe, warum der Router einen "Crash" hinlegt. Dieser lässt sich nicht von einem (gewollten) Neustart unterscheiden, sei es ein Admin aus der Ferne oder ein Firmware-Update. Gerade letzteres sollte man nicht durch einen harten Neustart unterbrechen. Nach einem Test dauert der erste Start nach einem Update unter 90 Sekunden, mal hoffen, dass sich das auch so im Feld verhält - schließlich sitzen die Bewohner nicht gerne ohne Internet und ich stehe ungern vor verschlossenen Türen, wenn es etwas zu tun gibt.<br />
<br />
Damit nicht der Mikrocontroller zum Problemfall wird, ist der interne Watchdog permanent aktiviert und wird (mehr oder weniger sinnvoll) im Mainloop zurückgesetzt.<br />
<br />
==Einbau==<br />
Dafür, dass nach erstem Plan ein 3D-Druck-Gehäuse auf den Router geklebt werden sollte, hat sich ein fast idealer Platz im Gehäuse selbst gefunden - und auch für die Integration hatte Xiaomi ein Herz für Bastler. Oder zumindest beschlossen, dass ein 0-Ohm-Widerstand (R752) als Sicherung reicht. Mit dem nicht genutzten Verpolschutz (D12) gibt es auch ein Massepad direkt nebenan:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_input.jpg | Eingangsbeschaltung am Router<br />
</gallery><br />
<br />
An dieser Stelle sei angemerkt, dass man sicherlich auch den Enable/Shutdown-Pin des/der Regler hätte verwenden können, bei der unbekannten Beschaltung und den Widerständen im 0201-Gehäuse wawr es mir allerdings zu fummelig, dort einzugreifen.<br />
<br />
Den LEDs sieht man es mit scharfem Auge schon an, welche die orange und welche die blaue sein muss (wenn auch nicht unbedingt im Foto): Blaue LEDs haben (wie weiße) üblicherweise 2 Bond-Drähte, der ideale Abgriffpunkt ist zwischen Vorwiderstand und Kondensator:<br />
<br />
<gallery><br />
ff_rebooter_router_leds.jpg | Status-LEDs am Router<br />
ff_rebooter_router_leds_detail.jpg | Detail-Ansicht der Dual-LED<br />
ff_rebooter_router_leds_beschaltung.jpg | Abgriffpunkte für die LEDs<br />
</gallery><br />
<br />
Auf- und Eingebaut sieht es dann wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_einbau.jpg | Einbau des Rebooters im Router<br />
</gallery><br />
<br />
Im Foto fehlt noch der obligatorische Heißkleber. Der Kondensator des Implantates musste noch ein bisschen gebogen werden, damit er nicht mit dem Gehäusedeckel kollidiert. <br />
<br />
Die abgeschnittenen Drähte sind ein Überbleibsel der oben erwähnten Logging-Aktivitäten (und wurden noch gestutzt).<br />
<br />
Die verbaute supergrüne LED ist trotz niedrigem Strom recht hell - sie ist, obwohl nach unten gerichtet, durch das Gehäuse leicht sichtbar und projiziert einen deutlichen Lichtkeil unter den gelöcherten Gehäuseboden. Kann man auch als Feature betrachten.<br />
<br />
=Das Ergebnis=<br />
Die ersten Tests mit per Konsole abgesetzten Reboots und einem erzwungenen Update waren erfolgreich - bei der Gelegenheit wurde auch gleich die Debug-Ausgaben eines Lebenszyklus (leider ohne Timestamps) aufgezeichnet:<br />
<br />
<pre><br />
Built on: Apr 2 2023 21:47:12<br />
Target: off -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 1 crashes<br />
Target: crashed -> running<br />
Target: running, saw 1 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 2 crashes<br />
Target: crashed -> running<br />
Target: running, saw 2 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
Target: saw 3 crashes, reboot<br />
Target: crashed -> reboot<br />
LED bl: on<br />
Target: reboot -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
</pre><br />
<br />
Patient 1 ist zum Zeitpunkt der Erstellung dieses Artikels seit 7 Tagen im Einsatz, legte erst einmal einen Lauf von knapp 5 Tagen hin und brauchte dann in etwa in etwa alle 12-17 Stunden einen Tritt.<br />
Router 2 ist erst seit kurzer Zeit wieder am Netz und hat kurz nach dem Start mutmaßlich einen Crash auf dem anderen Router verursacht - zumindest gab es eine verdächtige Korrelation zwischen Einschalten von Router 2 und einem Crash von Router 1.<br />
<br />
Bei beiden Geräten wurden die Cronjobs für den nächtlichen Reboot deaktiviert.<br />
<br />
Andere Faktoren die Abstürze begünstigen sind mir aktuell nicht bekannt - bei beiden Geräten habe ich vor der Wiederinbetriebnahme ein Update erzwungen, bei einem auch manuell Caches geleert. Vielleicht bringt das was, vielleicht auch nicht.<br />
<br />
Auch gilt es noch WLAN-Mesh auf zumindest einem der Geräte zu deaktivieren, zumal beide über Kabel angebunden sind und Komplexität sicherlich nicht zur Stabilität beitragen.<br />
<br />
=Ausblick=<br />
Die Schaltung kann verkleinert und optimiert werden, alles Unnötige entfernt werden.<br />
Hintergedanke für den Levelshifter an der UART-Schnittstelle war, über die Menge an Ausgaben (oder Keywords) einen Absturz zu erkennen oder auch Rückmeldungen z. B. per HTTP-Request auf die Konsole zu injizieren.<br />
Geschadet hat das Vorsehen sicher nicht, dank der bisherigen Zuverlässigkeit der aktuellen Erkennungsmethode und Statistik-Tools von ffmuc ist das aber nicht nötig.<br />
<br />
Wenn die Geräte etwas länger wieder im Betrieb sind, wird es ein Update geben.<br />
<br />
Generell halte ich einen externen Watchdog für Geräte, auf die man keinen permanenten Zugriff hat, für essenziell. Besser wäre natürlich, wenn es gar nicht bräuchte - was ich nicht als Kritik an [https://ffmuc.net/ Freifunk München]/[https://github.com/freifunk-gluon/gluon Gluon]/[https://openwrt.org/ OpenWRT] meine. Die Projekte leben überwiegend von freiwilligen, die in ihrer Freizeit und Community mehr bewegen als manch kommerzielle Anbieter. <br />
<br />
=Downloads=<br />
* [[ff_rebooter_v0.1.zip]] Schaltplan & Layout im EAGLE-Format und Firmware als Microchip-Studio-Projekt<br />
<br />
[[Kategorie:AVR]]<br />
[[Kategorie:Netzwerk]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Freifunk-Rebooter&diff=1853Freifunk-Rebooter2023-04-11T20:15:35Z<p>Chris: Seite erstellt</p>
<hr />
<div>=Ausgangssituation=<br />
<br />
In unseren Flüchtlingsunterkünften stehen mehrere Xiaomi Mi Router 4A Gigabit Edition, die mit der Freifunk-München-Firmware bespielt sind. <br />
Wer Freifunk nicht kennt, kann und sollte am besten sich in der [[wpde:Freifunk|Wikipedia]] informieren.<br />
<br />
Was am Anfang noch recht gut funktionierte, wurde mit der Zeit immer instabiler. Ein Cronjob zum nächtlichen Neustart brachte zwar Besserung, aber nach ein paar Tagen gingen die Router in eine Bootloop.<br />
<br />
Um den Fehler besser zu verstehen, wurde zeitweise ein [https://hobbyelektronik.org/b/2022/10/uart-logging-mit-linux/ Raspberry Pi zum Protokollieren] abgestellt. Als jemand, der von Linux nur rudimentäres Wissen besitzt, sahen die Meldungen so aus, als könne der SoC einen der WLAN-Chips nicht mehr initialisieren und schoss sich ins Nirwana. Blöd: ein Reboot richtet das nicht, Dokumentation für die Chips hängt wohl hinter der NDA-Mauer und einen hard-reset scheint es nicht zu geben.<br />
<br />
Nach einem kurzen Austausch im Chat der Freifunker gab es ein Ticket bei OpenWRT und nach einigen paar Tagen auch eine Experimental-Firmware, die den Fehler beheben sollte. Sollte.<br />
<br />
Ein paar Tage später stand bei Grafana für die Knoten wieder "no data", dafür gab es Klagen aus der Unterkunft. Einer der Router steht hinter für die dauerhaft verschlossener Tür, der andere in einem Zimmer dessen Bewohner auch mal ein paar Tage nicht da sind (und absperren).<br />
<br />
=Lösungsansätze=<br />
<br />
Kurz den/die entsprechenden LS-Schalter zu werfen ist leider auch keine Option. Das genauere Warum habe ich nicht weiter hinterfragt, das muss man einfach als gegeben annehmen.<br />
<br />
Dabei ist Strom trennen einfach wie effektiv. Eine Zeitschaltuhr würde helfen, die billigeren haben aber recht grobe Zeitraster und dementsprechend lange Ausfallzeiten. Auch kann es natürlich gleich nach einem Zwangsneustart gleich wieder zu Problemen kommen und die Wartezeit zum nächsten Neustart wird unnötig lang.<br />
<br />
Zwischenstecker mit Tasmota o. ä. würden zwar das Problem mit der Ausschaltzeit lösen, hätten aber wenig Chancen gegen Problem 2. Zwar könnten diese checken, ob das WLAN wegfällt, die Unterkunft wird allerdings durch mehrere Freifunk-Router (mit gleicher SSID) versorgt. Unnötig viel Komplexität.<br />
<br />
=Die Idee=<br />
<br />
Man sieht es den Routern von außen an, wenn sie abschmieren – im Betrieb leuchtet die Power-LED permanent blau, bei einem Crash bzw. Bootloop blinkt sie orange vor sich hin. Mit ein bisschen Mustererkennung erkennt man sogar die Phasen.<br />
<br />
Warum also nicht einen kleinen Mikrocontroller auf die Status-LED(s) schauen lassen und das "have you tried to turn it off and on again"-Spiel spielen lassen?<br />
<br />
==Datensammeln==<br />
<br />
Am Anfang war die Beobachtung: In einem kleinen WhatsApp-Video bekam ich das unheilvolle orange blinken von einem Vereinsmitglied; ein paar Sekunden sind jedoch noch nicht die ganze Geschichte, deshalb holte ich mir einen der Router nach Hause und nahm ein Video von einem Kaltstart des Gerätes auf und wartete ein bisschen.<br />
<br />
Ein paar Tage am Netz und siehe da: ohne Zutun von außen blinkt die Power-LED orange. Also nochmal die Kamera raus, Aufnahme und einige Minuten laufen lassen.<br />
<br />
Als Referenz gab es dann noch ein Video von einem erfolgreichen Start:<br />
<br />
[ff_rebooter_xiaomi_start.mp4]<br />
<br />
Mit den Videos kann man sich die Mäusedisco nun wieder und wieder ansehen, Bild für Bild durchgehen und die Blinkzyklen aufschreiben, oder man ist faul und fragt ChatGPT, wie man mit Python die Farben von Pixeln in Videos ermittelt. Ok, das ist wirklich keine rocket science (und einfach nur in der Doku von OpenCV zu stöbern hätte gereicht), aber schon erstaunlich, was Wortstatistik auf Steroiden leisten kann.<br />
<br />
==Videoauswertung==<br />
<br />
Für den ersten Eindruck ist die Herangehensweise eher unakademisch - das Beispiel vom Chatbot wird angepasst, damit an zwei Punkten - Power- und Link-LED - die Farben ermittelt werden, diese werden als Zellenhintergrund für eine HTML-Tabelle ausgegeben. Einfach wie fatal.<br />
<br />
Um nicht nur einen Pixel zu sampeln, wird jeder Frame um den Faktor 16 dezimiert - statt 1280x720 wird also ein Bild der Größe 80x45 verwendet. Das macht den Prozess nicht schneller, dafür werden Rauschen und Überstrahlungseffekte etwas reduziert.<br />
<br />
<source lang="python"><br />
import cv2<br />
video = cv2.VideoCapture("S1040005.MP4")<br />
<br />
frame_decimation = 16<br />
frame_skip = 1<br />
probe_points = [[970, 173], [1039, 168]]<br />
<br />
framecnt = int(video.get(cv2.CAP_PROP_FRAME_COUNT))<br />
print(framecnt)<br />
<br />
print("<style> body { background-color: black; } td { width: 20px; height: 1px; } </style>")<br />
print("<table style=\"border-collapse: collapse;\">")<br />
<br />
for frame_number in range(0, framecnt, frame_skip):<br />
video.set(1, frame_number)<br />
<br />
# Read the frame<br />
success, frame = video.read()<br />
newsize = (int(frame.shape[1] / frame_decimation), int(frame.shape[0] / frame_decimation))<br />
resized = cv2.resize(frame, newsize, interpolation = cv2.INTER_AREA)<br />
<br />
# Get the color of the pixel at the given location<br />
cols = []<br />
for point in probe_points:<br />
(b, g, r) = resized[int(point[1]/frame_decimation), int(point[0] / frame_decimation)]<br />
cols.append(f"#{r:02X}{g:02X}{b:02X}")<br />
<br />
#print("\t".join(cols))<br />
print("<tr>" + "".join(map(lambda x : f"<td style=\"background-color: {x}\"> </td>", cols)) + "</tr>")<br />
<br />
print("</table>")<br />
video.release()<br />
</source><br />
<br />
Bei Videomaterial mit 25 fps (was zugegebenermaßen etwas wenig ist), sieht ein etwas längerer Ausschnitt des Videos oben wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_start.png | Start des Xiaomi-Routers<br />
</gallery><br />
<br />
Links, wie im Video oben, die Power-LED, rechts die Link-LED. Wie aus dem Quellcode ersichtlich sein sollte, entspricht bei frame_skip = 1 jedes Frame ein Pixel in y-Richtung bei 25 fps. "Misst" man die Pixel vom ersten Lebenszeichen der linken LED bis sie blau wird, "vergehen" 1840 Pixel und somit 73,6 s - nicht ganz. Weil HTML ist das was man eingibt nicht unbedingt das, was angezeigt wird. Laut Konsole ist jeder oben angegebene Pixel 2px in der Darstellung, somit beträgt die Boot-Zeit 36,8 s. <br />
<br />
Der Bootloop ist nicht spektakulärer, er ist lediglich die immerwährende Wiederholung des "orangen" Parts.<br />
<br />
=Umsetzung=<br />
==Hardware==<br />
Der erste Gedanke war, die Hardware minimalinvasiv aufzubauen: Nachdem es Dauerlicht nur gibt, wenn die Kiste läuft, ist die Farbe irrelevant. Blinkt etwas länger, ist etwas im Argen. Also warum nicht einfach einen Fototransistor anflanschen, die Helligkeit auswerten und wenn längeres Blinken herrscht denk Anker werfen?<br />
<br />
Es scheitert wie immer an der Realität. Die ersten Versuche waren aussichtsreich, mit Umgebungslicht und nicht exakt platziertem Fototransistor war die Freude aber recht schnell wieder vorbei.<br />
<br />
Für die ersten Versuche auf dem Breadboard hat es zumindest gereicht.<br />
<br />
Um nicht extra Teile bestellen zu müssen, wurde das eingeplant, was herum liegt, Herzstück ist ein (völlig überdimensionierter) ATmega8A, der Signale zweier Fototransistoren im SMD-Package, aber auch in der THT-Version in Form von BPW40 entgegennimmt.<br />
<br />
Um beide LEDs am Router erfassen zu können, sind diese im Abstand von 15 mm zueinander platziert.<br />
<br />
Auf der anderen Seite des Mikrocontrollers hängen p-Kanal FETs sowohl im SO-8- als auch SOT-23-Gehäuse, über die die Versorgung des Routers geschaltet wird.<br />
<br />
Um evtl. doch noch einen UART mit abweichender Spannung (und Domäne) anbinden zu können, noch zwei einfache Levelshifter dazu und ab auf eine Leiterkarte damit.<br />
<br />
Noch zwei Status-LEDs dazu und fertig ist der Lack.<br />
<br />
Recht viel Optionales, aber eine zweiten Leiterkarten-Spin zu fahren: #gerkeinbock<br />
<br />
Leiterkarten-Spin? Ja, mittlerweile bin ich echt zu faul, etwas auf Lochraster aufzubauen - zumal so gut wie alle Bauteile im SMD-Package daherkommen.<br />
<br />
Der zusammengeklöppelte Schaltplan, Layout und der Aufbau sehen wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_sch.png | Schaltplan<br />
ff_rebooter_pcb.png | Layout der Leiterkarte<br />
ff_rebooter_pcb_top.jpg | Bestückte Oberseite<br />
ff_rebooter_pcb_bot.jpg | Bestückte Unterseite<br />
</gallery><br />
<br />
===BOM & Nachbau===<br />
Nachdem die Hardware schnell-schnell zusammengeklöppelt wurde, ist aktuell keine BOM und genauere Details vorgesehen. Wer sie dennoch möchte, kann sie gerne aus den EAGLE-Daten erzeugen oder mich anschreiben.<br />
<br />
==Firmware==<br />
Die Software hat im Prinzip nur eine Aufgabe: Blinkt die Power LED länger als x Sekunden, wird die Stromversorgung für y Sekunden unterbrochen.<br />
<br />
"Genau das, nur etwas komplizierter!"<br />
<br />
Zunächst gilt die Frage zu klären: Wann blinkt was, wann ist es statisch an, wann aus?<br />
<br />
===ADC===<br />
<br />
Vorher muss aber erst noch geklärt werden: Wann ist eine LED überhaupt an?<br />
Mit den vorhin erwähnten Fototransistoren muss man das Umgebungslicht filtern. Ist die LED länger statisch und das Licht "außenrum" ändert sich, oder es verrutscht etwas leicht, verpasst man vielleicht, dass sich etwas ändert.<br />
<br />
Kann man filtern, kann man aber auch von Grund auf vermeiden. auch wenn die Elektronik dafür vorgesehen ist: man muss die optischen Sensoren nicht verwenden, sondern kann auch einfach auf die Ansteuerung der LEDs gehen. Diese erfolgt jedoch nicht mit boardähnlichen 5 V, sondern mit 3,3 V, was für die Eingänge etwas knapp werden kann. Also kommt doch der ADC zum Einsatz, wenn auch etwas vereinfacht: zwei Schwellenwerte, dazwischen eine Hysterese, fertig.<br />
<br />
Einen Schritt zurück: Der Analog zu Digital-Wandler durchläuft, nachdem das "Subsystem" getriggert wurde alle ausgewählten Kanäle, was etwa jede Millisekunde geschieht.<br />
<br />
Schwellenwertvergleich und ab mit einem true oder false in die LED-Detektion.<br />
<br />
===LED-Detektion===<br />
<br />
Diese schaut, ob sich was am Zustand des Einganges ändert und zählt die entsprechende Zeit. Wechselt der Zustand nach "0" (false) wird erst einmal blinkend angenommen, bleibt der Zustand für länger als <code>LEDDET_TIMEOUT</code> (750 ms) konstant, wird "statisch aus" respektive "an" angenommen.<br />
<br />
Das Ganze wird für die rote und blaue LED der "Power-LED" gemacht...<br />
<br />
===Zustandsautomat===<br />
... und im "Target"-Zustandsautomaten verwurstet, der zunächst auf Papier entstand und nach der Implementierung auf dem PC nachgezeichnet wurde:<br />
<br />
<gallery><br />
ff_rebooter_fsm.png | Zustandsautomat für das "Target"<br />
</gallery><br />
<br />
Nach dem Einschalten geht die Maschine zunächst in den Off-Zustand - hauptsächlich um die Realität abzubilden. Beim Startup wird die Stromversorgung für den Router eingeschaltet und die grüne LED blinkt vor sich hin.<br />
<br />
Sobald für länger als 2 Sekunden die orange LED des Routers erloschen ist und die blaue leuchtet, wird angenommen dass der Router läuft. Ist das nach 90 Sekunden am Strom nicht der Fall, wird ein Crash angenommen und ein harter Reboot eingeleitet (mehr dazu später).<br />
<br />
Im Zustand Running gibt es zwei Varianten für die eigenen Status-LEDs: In jedem Fall leuchtet die grüne LED dauerhaft, wurde vorher ein Crash "erkannt", blitzt zusätzlich die rote LED auf.<br />
<br />
Sollte nun am Router die orange LED an gehen oder blinken und die die blaue LED nicht an sein, gibt es einen Crashverdacht; allerdings erst, wenn dies für über 2 Sekunden mit "Waterlevel" der Fall ist. Mit Waterlevel ist gemeint, dass im "Verdachtszustand" ein Zähler hochgezählt wird. Ist der "Verdacht" vorbei, wird dieser Zähler nicht auf Null zurückgesetzt, sondern lediglich verringert. So kann ein instabiler Zustand etwas besser erkannt werden.<br />
<br />
Erhärtet sich der Crashverdacht, wird ein interner Zähler für die Verdachtsfälle hochgezählt, erreicht dieser die magische Anzahl 3 oder bleibt der Zustand für über 90 Sekunden, wird ein Neustart eingeleitet. "Fängt" sich der Router wieder, sprich: die blaue LED leuchtet konstant und die orange ist aus, wechselt der Zustand nach 5 Sekunden wieder nach Running. Allerdings hier ohne Waterlevel. Lieber einen harten Neustart als im Limbus zwischen Running und Crashed hängen bleiben.<br />
Da beim erhärteten Crashverdacht vermutlich nix mehr geht, darf nun die rote Status-LED blinken, die grüne bleibt dunkel.<br />
<br />
Beim Durchführen des Reboots wird die Stromversorgung zum Router unterbrochen und die rote Status-LED blinkt schnell. Nach 5 Sekunden beginnt der Lebenszyklus des Routers von Vorne (Off) und er darf wieder starten.<br />
<br />
Wozu der Aufwand?<br />
<br />
Der Router startet zwar recht schnell (etwa 40 Sekunden reine Bootzeit), benötigt im dümmsten Fall aber 1-2 Minuten, bis er wieder mit dem Freifunk-Netz verbunden ist.<br />
Daher sollen unnötige Reboots vermieden werden.<br />
<br />
Warum aber so lange Wartezeiten, bevor der Strom abgedreht wird?<br />
<br />
Auch hier: Vorsicht. Es gibt auch legitime Gründe, warum der Router einen "Crash" hinlegt. Dieser lässt sich nicht von einem (gewollten) Neustart unterscheiden, sei es ein Admin aus der Ferne oder ein Firmware-Update. Gerade letzteres sollte man nicht durch einen harten Neustart unterbrechen. Nach einem Test dauert der erste Start nach einem Update unter 90 Sekunden, mal hoffen, dass sich das auch so im Feld verhält - schließlich sitzen die Bewohner nicht gerne ohne Internet und ich stehe ungern vor verschlossenen Türen, wenn es etwas zu tun gibt.<br />
<br />
Damit nicht der Mikrocontroller zum Problemfall wird, ist der interne Watchdog permanent aktiviert und wird (mehr oder weniger sinnvoll) im Mainloop zurückgesetzt.<br />
<br />
==Einbau==<br />
Dafür, dass nach erstem Plan ein 3D-Druck-Gehäuse auf den Router geklebt werden sollte, hat sich ein fast idealer Platz im Gehäuse selbst gefunden - und auch für die Integration hatte Xiaomi ein Herz für Bastler. Oder zumindest beschlossen, dass ein 0-Ohm-Widerstand (R752) als Sicherung reicht. Mit dem nicht genutzten Verpolschutz (D12) gibt es auch ein Massepad direkt nebenan:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_input.jpg | Eingangsbeschaltung am Router<br />
</gallery><br />
<br />
An dieser Stelle sei angemerkt, dass man sicherlich auch den Enable/Shutdown-Pin des/der Regler hätte verwenden können, bei der unbekannten Beschaltung und den Widerständen im 0201-Gehäuse wawr es mir allerdings zu fummelig, dort einzugreifen.<br />
<br />
Den LEDs sieht man es mit scharfem Auge schon an, welche die orange und welche die blaue sein muss (wenn auch nicht unbedingt im Foto): Blaue LEDs haben (wie weiße) üblicherweise 2 Bond-Drähte, der ideale Abgriffpunkt ist zwischen Vorwiderstand und Kondensator:<br />
<br />
<gallery><br />
ff_rebooter_router_leds.jpg | Status-LEDs am Router<br />
ff_rebooter_router_leds_detail.jpg | Detail-Ansicht der Dual-LED<br />
ff_rebooter_router_leds_beschaltung.jpg | Abgriffpunkte für die LEDs<br />
</gallery><br />
<br />
Auf- und Eingebaut sieht es dann wie folgt aus:<br />
<br />
<gallery><br />
ff_rebooter_xiaomi_einbau.jpg | Einbau des Rebooters im Router<br />
</gallery><br />
<br />
Im Foto fehlt noch der obligatorische Heißkleber. Der Kondensator des Implantates musste noch ein bisschen gebogen werden, damit er nicht mit dem Gehäusedeckel kollidiert. <br />
<br />
Die abgeschnittenen Drähte sind ein Überbleibsel der oben erwähnten Logging-Aktivitäten (und wurden noch gestutzt).<br />
<br />
Die verbaute supergrüne LED ist trotz niedrigem Strom recht hell - sie ist, obwohl nach unten gerichtet, durch das Gehäuse leicht sichtbar und projiziert einen deutlichen Lichtkeil unter den gelöcherten Gehäuseboden. Kann man auch als Feature betrachten.<br />
<br />
=Das Ergebnis=<br />
Die ersten Tests mit per Konsole abgesetzten Reboots und einem erzwungenen Update waren erfolgreich - bei der Gelegenheit wurde auch gleich die Debug-Ausgaben eines Lebenszyklus (leider ohne Timestamps) aufgezeichnet:<br />
<br />
<pre><br />
Built on: Apr 2 2023 21:47:12<br />
Target: off -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 1 crashes<br />
Target: crashed -> running<br />
Target: running, saw 1 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: recovered from crash state, saw 2 crashes<br />
Target: crashed -> running<br />
Target: running, saw 2 crashes<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
Target: running -> crashed<br />
Target: saw 3 crashes, reboot<br />
Target: crashed -> reboot<br />
LED bl: on<br />
Target: reboot -> off<br />
Target: off -> startup<br />
LED or: blinking<br />
LED bl: blinking<br />
LED bl: off<br />
LED or: on<br />
LED or: blinking<br />
LED or: off<br />
LED or: blinking<br />
LED or: off<br />
LED bl: on<br />
Target: startup finished<br />
Target: startup -> running<br />
Target: running, saw 0 crashes<br />
</pre><br />
<br />
Patient 1 ist zum Zeitpunkt der Erstellung dieses Artikels seit 7 Tagen im Einsatz, legte erst einmal einen Lauf von knapp 5 Tagen hin und brauchte dann in etwa in etwa alle 12-17 Stunden einen Tritt.<br />
Router 2 ist erst seit kurzer Zeit wieder am Netz und hat kurz nach dem Start mutmaßlich einen Crash auf dem anderen Router verursacht - zumindest gab es eine verdächtige Korrelation zwischen Einschalten von Router 2 und einem Crash von Router 1.<br />
<br />
Bei beiden Geräten wurden die Cronjobs für den nächtlichen Reboot deaktiviert.<br />
<br />
Andere Faktoren die Abstürze begünstigen sind mir aktuell nicht bekannt - bei beiden Geräten habe ich vor der Wiederinbetriebnahme ein Update erzwungen, bei einem auch manuell Caches geleert. Vielleicht bringt das was, vielleicht auch nicht.<br />
<br />
Auch gilt es noch WLAN-Mesh auf zumindest einem der Geräte zu deaktivieren, zumal beide über Kabel angebunden sind und Komplexität sicherlich nicht zur Stabilität beitragen.<br />
<br />
=Ausblick=<br />
Die Schaltung kann verkleinert und optimiert werden, alles Unnötige entfernt werden.<br />
Hintergedanke für den Levelshifter an der UART-Schnittstelle war, über die Menge an Ausgaben (oder Keywords) einen Absturz zu erkennen oder auch Rückmeldungen z. B. per HTTP-Request auf die Konsole zu injizieren.<br />
Geschadet hat das Vorsehen sicher nicht, dank der bisherigen Zuverlässigkeit der aktuellen Erkennungsmethode und Statistik-Tools von ffmuc ist das aber nicht nötig.<br />
<br />
Wenn die Geräte etwas länger wieder im Betrieb sind, wird es ein Update geben.<br />
<br />
Generell halte ich einen externen Watchdog für Geräte, auf die man keinen permanenten Zugriff hat, für essenziell. Besser wäre natürlich, wenn es gar nicht bräuchte - was ich nicht als Kritik an [https://ffmuc.net/ Freifunk München]/[https://github.com/freifunk-gluon/gluon Gluon]/[https://openwrt.org/ OpenWRT] meine. Die Projekte leben überwiegend von freiwilligen, die in ihrer Freizeit und Community mehr bewegen als manch kommerzielle Anbieter. <br />
<br />
=Downloads=<br />
* [[ff_rebooter_v0.1.zip]] Schaltplan & Layout im EAGLE-Format und Firmware als Microchip-Studio-Projekt<br />
<br />
[[Kategorie:AVR]]<br />
[[Kategorie:Netzwerk]]</div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_xiaomi_start.mp4&diff=1852Datei:Ff rebooter xiaomi start.mp42023-04-11T20:13:50Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_router_leds_beschaltung.jpg&diff=1844Datei:Ff rebooter router leds beschaltung.jpg2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_fsm.png&diff=1845Datei:Ff rebooter fsm.png2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_router_leds.jpg&diff=1846Datei:Ff rebooter router leds.jpg2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_pcb.png&diff=1847Datei:Ff rebooter pcb.png2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_pcb_bot.jpg&diff=1848Datei:Ff rebooter pcb bot.jpg2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_xiaomi_input.jpg&diff=1849Datei:Ff rebooter xiaomi input.jpg2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_pcb_top.jpg&diff=1850Datei:Ff rebooter pcb top.jpg2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_xiaomi_einbau.jpg&diff=1851Datei:Ff rebooter xiaomi einbau.jpg2023-04-11T20:13:33Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_router_leds_detail.jpg&diff=1841Datei:Ff rebooter router leds detail.jpg2023-04-11T20:13:32Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_xiaomi_start.png&diff=1842Datei:Ff rebooter xiaomi start.png2023-04-11T20:13:32Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chrishttps://hobbyelektronik.org/w/index.php?title=Datei:Ff_rebooter_sch.png&diff=1843Datei:Ff rebooter sch.png2023-04-11T20:13:32Z<p>Chris: Hochgeladen mit SimpleBatchUpload</p>
<hr />
<div></div>Chris