Netz39 - projects:2020

covid19

anonymous@undisclosed.example.com (Anonymous) — Tue, 14 Apr 2020 12:34:46 +0000

@@ -1 +1,14 @@
+ ====== Covid19 bezogene Space-Aktionen ======
  
+ ===== Schutzmasken =====
+ Anhang mit vier Maskenmodellen von Kris Jürgens siehe Mailingliste:
+ {{ :projects:2020:3d-druck_corona.7z |}}
+ 
+ 
+ ===== Face Shields =====
+ Werden aktuell diese gedruckt: https://www.prusaprinters.org/prints/27267/files
+ 
+ Material: PETG [bevorzugt], zur not geht auch PLA
+ 
+ ===== #MakerVsVirus =====
+ Orga aktuell via Slack: https://makervsvirus.slack.com

herd

anonymous@undisclosed.example.com (Anonymous) — Mon, 26 Oct 2020 20:42:22 +0000

@@ -1 +1,34 @@
+ ====== Neuer Herd ======
  
+ Laut [[:stammtisch:2019:2019-11-27|Plenum]] wollen wir einen neuen Herd.
+ 
+ Wir haben einen neuen Herd.
+ 
+ Projekt abgeschlossen, Huld an Peter.
+ 
+ ===== Anforderungen =====
+ 
+   * …
+ 
+ ===== Lokale Händler =====
+ 
+   * [[https://www.monsator-magdeburg.de/|monsator]]
+     * Zanussi ab 560 €
+     * Constructa ab 680 €
+     * Siemens, Miele, Neff, AEG, usw. **ab** 800–1000 € aufwärts
+     * Ausstellungsstücke werden nur zum Neupreis verkauft
+     * --- //[[alex+wiki@netz39.de|LeSpocky]] 2020-01-03 15:35//
+ 
+   * --- Peter --- 11.01.2020
+     * MediMax Angebot Siemens vom 13.01.2019 - 18.01
+       * https://www.medimax.de/p/1222714/eq211kv0v-he213abs0-ea645gn17-hz638300-hz531000
+       * EQ211KV0V (HE213ABS0+EA645GN17+HZ638300+HZ531000) - Edelstahl-Schwarz
+       * 599-€
+       * A
+     * Saturn
+       * https://www.saturn.de/de/product/_aeg-kombi-3025-p-2571966.html (A+ AEG KOMBI 3025 P, Einbauherdset 649,-)
+       * https://www.saturn.de/de/product/_gorenje-profiset-bop-in-bop637e301x-it640bx-2530241.html ( A+  GORENJE PROFISET BOP IN  649,- )
+ 
+ ===== ebay Kleinanzeigen =====
+   * [[https://www.ebay-kleinanzeigen.de/s-anzeige/top-aeg-herd-mit-restgarantie-zu-verkaufen-/1299095091-176-2228|AEG vom 2020-01-13]] für 350 Euro
+   * [[https://www.ebay-kleinanzeigen.de/s-anzeige/einbauherd/1290211522-176-2232|Whirlpool vom 2020-01-02]] für 100 Euro

i2c_foo

anonymous@undisclosed.example.com (Anonymous) — Sun, 07 Nov 2021 16:23:45 +0000

@@ -1 +1,72 @@
+ ====== I2C Foo ======
+ 
+   ? Maintainer: 
+   : [[:user:tux]]
+   ? Status
+   : Solved - kind of
+   
+ ===== Problem =====
+ 
+ RaspberryPi 2B und Attiny verstehen sich nicht per I2C.
+ 
+ Effekt: Der RPi erhält die Antwort auf die vorherige Anfrage. Es handelt sich nicht um ein Timing-Problem,  das Signal sieht gut aus und die Übertragung ist auf dem PHY sauber. Nur die Inhalte stimmen nicht.
+ 
+ ===== Lösung =====
+ 
+   * https://github.com/netz39/space_notification/pull/12
+   * Repeated Starts im I2C Frame führen dazu, dass die Bibliothek die Schwelle zwischen Schreiben zum Slave und Lesen vom Slave nicht mehr erkennt und den Callback zu spät ausführt, sodass die Puffer-Daten aus dem jeweils letzten Request zurückgelesen werden.
+   * Der aktuelle Workaround ist, nach dem Empfang des ersten Bytes mit der Verarbeitung zu beginnen.
+   * Der Blick auf das Direction Bit könnte ein generischer Marker sein. Diese Bibliothek nutzt aber in ihrer Implementierung die Zeit, die der Master mit dem Senden der Adresse für ein Read auf dem Bus verbringt, für die Berechnung. Diese Zeit fehlt dann und wahrscheinlich ist der µC damit nicht mehr schnell genug. Clock-Stretching wird nicht unterstützt.
+   * Optimal wäre, die Repeated Starts abzuschalten, dazu habe ich aber keinen Switch gefunden.
+ 
+   * PRs
+     * https://github.com/netz39/rollladensteuerung/pull/20
+     * https://github.com/netz39/space_notification/pull/12
+ 
+ ===== Logbuch des Wahnsinns =====
+   * RaspberryPi kann kein Clock Stretching
+   * Problem tritt auf RPi 2B, aber nicht auf RPi A auf
+   * Abstand zwischen den Abfragen ist nicht relevant, es können mehrere Minuten dazwischen liegen
+   * Start und Stop Condition werden vom Oszi nicht dekodiert (mit anderen Transfers gegenchecken)
+ 
+ ==== 2021-11-06 ====
+   * Offenbar sendet der RPi2 Repeated-Start-Conditions, die den AVR dazu veranlassen, sofort den Puffer zurückzugeben, ohne die Interrupt-Routine aufzurufen.
+   * Workaround: i2cget und i2cset trennen
+   * Besser wäre es, wenn der Kernel das schon auseinander nehmen könnte
+   * https://github.com/torvalds/linux/blob/master/drivers/i2c/algos/i2c-algo-bit.c#L552 → Unterscheidung Start/Stop oder Repeated Start
+   * https://github.com/thenaran/linux-rpi/blob/master/drivers/i2c/busses/i2c-bcm2708.c#L77
+     * Es gibt den Parameter "combined", über den festgelegt wird, ob Nachrichten über Repeated-Start zusammengefasst werden
+   * Für den relevanten Bus ist bcm-2835 zuständig … oder auch nicht. Es ist bcm2708
+   * Offenbar kommt das repeated-start aus dem Userspace
+   * Benutzt die USITWI-Library für den AVR die Stop-Condition, um das callback aufzurufen?
+     * Der Callback wird nicht in der ISR aufgerufen (was eig. sinnvoll ist)
+     * Ablauf wäre dann so:
+       * Master sendet Adresse und Parameter im ersten Block
+       * Parameter landet im Puffer
+       * Stop-Condition führt dazu, dass Callback (mit Parameter aus Puffer) ausgeführt wird
+       * Während der Master das Adress-Byte für den Read-Request schickt (USI ist Hardware-basiert, unterbricht also den Programmablauf nicht), führt der Prozessor den Callback auf dem Parameter aus dem Eingangspuffer aus und schreibt das Ergebnis in den Ausgangspuffer.
+       * Wenn der Master die das Adress-Byte geschrieben hat, liegt das Ergebnis zum Senden im Ausgangspuffer
+     * Beim Repeated Start fehlt die Stop-Condition
+       * Callback wird nicht nach Empfang des Eingangs-Parameters (erster Frame) aufgerufen
+       * d.g. beim Antworten liegen noch die Daten des vorherigen Requests im Ausgangspuffer
+       * Callback wird _nach_ dem gesamten Request/Response aufgerufen
+       * d.h. bei der nächsten Anfrage liegen dann die Daten der letzten Anfrage im Puffer und werden zurückgegeben
+ 
+ Lösung könnte sein:
+   * 1)
+     * Einen anderen Trigger verwenden (es gibt eine interne State Machine)
+   * 2) 
+     * I2C-Zugriff zentralisieren, wie das schon mal geplant war. 
+     * Bei der Gelegenheit könnte auch gleich der ganze I3C-Teil umgesetzt werden.
+     * Read/Write trennen, sodass der AVR auch definitiv genug Zeit für die Verarbeitung hat
+ ===== Linksammlung =====
+   * https://community.atmel.com/forum/e70-twi-master-read-communication-problem
+   * https://elinux.org/BCM2835_datasheet_errata#p35_I2C_clock_stretching
+   * http://ww1.microchip.com/downloads/en/AppNotes/doc8380.pdf
+   * https://hackaday.com/2016/07/19/what-could-go-wrong-i2c-edition/
+   * [[http://ww1.microchip.com/downloads/en/DeviceDoc/doc8006.pdf|Attiny Datasheet]]
+     * ab Seite 117 bzw. Seite 121
+   * [[https://electronicayciencia.github.io/wPi_soft_i2c/|Software emulated I2C for Raspberry Pi]]
+     * nur 8 bit built-in, den Rest muss man emulieren
+     * kann Clock Stretching

motorisierung_leinwand

anonymous@undisclosed.example.com (Anonymous) — Mon, 15 May 2023 09:10:42 +0000

@@ -1 +1,29 @@
+ ====== Motorisierung der Leinwand ======
  
+ ===== Project information =====
+   ? Maintainer: 
+   : [[:user:tux]] (Open for Adoption)
+   ? Status
+   : Planning
+ 
+ Die [[projects:2015:mediacenter|Leinwand in der Lounge]] soll motorisiert werden, damit sie automatisch mit Nutzung des Beamers aus- bzw. eingerollt werden kann.
+ 
+ ==== Nächste Schritte ====
+   * Leinwand wiegen
+     * Gesamtgewicht etwa 11kg
+     * Größe 240 x 180cm
+   * Notwendiges Drehmoment des Motors ausrechnen
+     * konservative Annahmen
+     * r = 0.05 m
+     * m = 11 kg
+     * F = 107,87 N
+     * M_t = 5.39 Nm
+   * Die Antriebsbaugruppe sollte nicht-selbsthemmend sein, um die Leinwand auch im unbestromten Zustand bewegen zu können.
+   * passenden Motor aussuchen
+   * passende Treiberschaltung zum Motor aussuchen
+ 
+ ==== Links ====
+   * http://www.zuendler.com/leinwandumbau.htm
+   * https://shop.watterott.com/SilentStepStick-TMC2100-5V
+   * https://www.omc-stepperonline.com/de/getriebe-schrittmotor/nema-14-stepper-l-52mm-w-hinterer-schaft-and-ubersetzungsverhaltnis-4-1-planetengetriebe.html
+   * [[https://www.ebay.de/itm/201887787519|201887787519]] – 120" Motor Leinwand 244x182 Beamerleinwand Beamer inkl FFB Heimkino 16:9 4:3 1:1 - 110€

thermostat_umbau

anonymous@undisclosed.example.com (Anonymous) — Fri, 26 Dec 2025 09:26:40 +0000

@@ -1 +1,61 @@
+ ====== Umbau der Heizungsthermostate (HR20) ======
+ Die 2 verbauten Heizungsthermostate HR20 von Honeywell sollen mit der openSource Firmware versehen werden und in die Space Hausautomatisierung eingebracht werden.
+ 
+   ? Maintainer: 
+   : [[user:d33pwat3r|Rick]]
+   ? Interessenten:
+   : [[user:tux|Tux]], [[user:mg-95|MaxG]]
+   ? Status
+   : in Arbeit
+ ===== ToDos =====
+   * <todo #holly:2020-06-02>JTAG Programmiergerät auftreiben</todo>
+   * <todo>Vorgehensweise klären</todo>
+   
+ ===== OpenHR20 =====
+ Die Thermostate sind mit einem Atmel ATmega 169 [1] versehen und können mit einer eigenen Firmware versehen werden.
+ Die Firmware "OpenHR20" [2] bietet diverse zusätzliche Möglichkeiten. Dazu gehört die Möglichkeit über die verfügbare Serielle Schnittstelle mit dem Thermostat zu kommunizieren.
+ 
+ ===== Anbindung in die Space Infrastruktur =====
+ Für die Anbindung an die Space Infrastruktur gibt es verschiedene Möglichkeiten, die hier aufgelistet und miteinander verglichen werden.
+ 
+ ==== Übertragung: RS232 (Seriell) ====
+ Wenn man kein Funk an den Thermostaten haben möchte, kann man die serielle Schnittstelle durch den Space zentral irgendwo hin verlegen. Damit die Kommunikation auch nach mehreren Metern noch zuverlässig ist, kann man aus dem TTL-Signal ein differentielles Signal machen, indem man z.B. auf RS232 zurückgreift. Dafür benötigt man an beiden Enden jeweils einen UART-zu-RS232 Wandler (z.B. MAX232).
+ 
+ ==== Funkübertragung: RFM12 ====
+ Die OpenHRM20 Firmware bietet die Möglichkeit einen Funkchip vom Typ RFM12 [3] intern oder extern an die frei Verfügbaren Pins zu montieren und darüber zu kommunizieren.
+ Für die Kommunikation wird noch ein Masterdevice benötigt, welches als Gateway zwischen Funk und Space-API dient.
+ 
+ 
+ ==== Funkübertragung: ESP8266 (Seriell) ====
+ Eine sehr einfache Möglichkeit wäre die Nutzung eines ESP8266, welcher auf einem kompatiblen 3V Level arbeitet und ohne weitere Hardware eine WLAN Kommunikation ermöglicht.
+ Das ESP-1 Modul ([[http://stefanfrings.de/esp8266/|Übersicht von ESP-Modulen ]]) wäre für unser Vorhaben mehr als ausreichend.
+ 
+ Das Problem beim ESP ist jedoch der relativ hohe Stromverbrauch mit jeweils Spitzen von knapp über 100mA.
+ Auch wenn der vorhandene Deep-Sleep Modus genutzt würde, sollte die Energieversorgung nicht vernachlässigt werden.
+ 
+ ==== Funkübertragung: NRF24L01+====
+ Der NRF24L01+ ist ein sehr beliebter Funkchip in der Maker-Szene, welcher über das SPI Protokoll angesprochen werden kann. Obwohl dieser 5V-Pin kompatibel ist, darf er maximal mit 3,6V betrieben werden. Genaueres kann auf der Projektseite von Mikrocontroller.net [4] eingesehen werden
+ 
+ === Direkt mit OpenHRM20 ===
+ Nach erster Recherche sollte es möglich sein den Funkchip direkt an die freien Pins anzuschließen und durch anpassen der Firmware zum laufen zu bekommen.
+ Das einarbeiten in die vorhandene Firmware und wie man genau den NRF24 sinnvoll verbinden kann, wird wohl ein wenig Zeit in Anspruch nehmen.
+ 
+ === Indirekt über eine MySensor Node (Seriell)===
+ Für den NRF24 gibt es unzählige Projekte und auch verschiedene gut dokumentierte Bibliotheken. Eines dieser Projekte ist das MySensor Projekt [5]. Das Ziel des MySensors-Projektes ist die einfache Herstellung von beliebigen Sensor (& Aktor)-Nodes. Bei dem genutzten Mikrocontroller wird der typische Arduino Controller (ATmega328p) genommen. Der Energieverbauch vom zusätzlichen ATmel Chip + NRF24 sollte gering genug sein, dass es die Laufzeit nicht großartig beschränkt.
+ 
+ Zur Anbindung an die Space-API kann ein ESP8266 mit einem NRF Chip versehen werden. Die Firmware für solch ein Gateway und die Plugins für unzählige Hausautomatisierungen (OpenHub, FHEM, NodeRed, ...) existieren bereits.
+ 
+ 
+ 
+ 
+ ===== Links =====
+   * [1] ATmega 169 [[https://www.microchip.com/wwwproducts/en/atmega169p|Datasheet]]
+   * [2] Projektseite auf [[https://www.mikrocontroller.net/articles/Heizungssteuerung_mit_Honeywell_HR20|mikrocontroller.net]]
+   * [3] RFM12 Beschreibung auf [[https://www.mikrocontroller.net/articles/RFM12|mikrocontroller.net]]
+   * [4] https://www.mikrocontroller.net/articles/NRF24L01_Tutorial
+   * [5] https://www.mysensors.org/
+   * http://svn.code.sf.net/p/openhr20/code/
+   * https://www2.htw-dresden.de/~wiki_sn/index.php/HR20
+   * https://www.hackerspace-bamberg.de/Cooperating_radiator_monitoring_114
+

unwritten_rules

anonymous@undisclosed.example.com (Anonymous) — Wed, 05 Feb 2020 11:20:41 +0000

@@ -1 +1,17 @@
+ ====== Unwritten Rules ======
+ 
+ Die Hackordnung soll durch so etwas ersetzt werden: https://img-9gag-fun.9cache.com/photo/aj5BLjQ_700bwp.webp
+ 
+   ? Maintainer: 
+   : [[user:tux|Tux]]
+   ? Interessenten:
+   : 
+   ? Status
+   : in Arbeit
+ 
+   * Besprochen und für gut befunden auf dem Plenum am [[stammtisch:2020:2020-01-15|2020-01-15]]
+   * Next Steps:
+     * Ben ansprechen, ob er mitwirken will
+ 
+ {{ :projects:2020:aj5bljq_700bwp.png?direct |}}

voc_sensor

anonymous@undisclosed.example.com (Anonymous) — Sun, 08 Jan 2023 22:36:07 +0000

@@ -1 +1,85 @@
+ ====== VOC-Sensor (Messung der Luftqualität) ======
+ 
+ ===== Project information =====
+   ? Maintainer: 
+   : [[user:mg-95|Max2]]
+   ? Interessenten:
+   : [[user:tux]], [[user:dkdent]]
+   ? Status
+   : Planning  
+   
+ 
+ ----
+ 
+ <markdown>
+ 
+ ## ESPHome Firmware
+ 
+ Verwendet diese esphome Firmware: https://git.unhb.de/smash/co2ampel
+ 
+ ## Vorhaben
+ 
+ Um zu Corona-Zeiten die Luftqualität im Netz39 messen zu können, wird geplant, einen VOC-Sensor zu verbauen.
+ 
+ Warum der VOC-Gehalt gemessen werden soll und eine CO2-Messung nicht ausreicht, kann man hier nachlesen: [PDF](https://sensortec.ch/wp-content/uploads/documents/de/%5B6%5DAllgemeine%20Infos%5Bgrey%5D/Unterschiede%20VOC%20und%20CO2%20Messung.pdf)
+ 
+ 
+ ### Related Work
+ 
+ [Watterot hat auch ne CO2 Ampel](https://github.com/watterott/CO2-Ampel), die kann man direkt kaufen, [wenn man reich ist](https://github.com/watterott/CO2-Ampel)
+ 
+ ### Sensor
+ In der Make-Zeitschrift 5/20 wird eine [CO2-Ampel](https://www.heise.de/select/make/2020/5/2022015381334973804) vorgestellt, die sowohl CO2 als auch VOC misst. 
+ 
+ Dort wurde für die VOC-Messungen der Sensor [BME680 von Bosch](https://www.bosch-sensortec.com/products/environmental-sensors/gas-sensors-bme680/) verwendet. Dieser ist ziemlich klein, für low-power-Anwendungen geeignet und lässt sich über I2C/SPI ansprechen. 
+ 
+ Der Sensor kann zusätzlich zu VOC-Messung außerdem die Temperatur, Luftfeuchtigkeit und Luftdruck messen. (Die drei Sachen werden benötigt, um die VOC-Messgenauigkeit zu gewährleisten)
+ 
+ #### Sensor-Firmwaretreiber
+ 
+ Bosch hat die Treiber für die Sensoren auf [github](https://github.com/BoschSensortec/BME680_driver) veröffentlicht.  
+ Bosch hat die Arduino-Bibliothek für die Sensorfusion als Binaryblob auf [github](https://github.com/BoschSensortec/BSEC-Arduino-library) veröffentlicht.
+ Von Adafruit gibts einen [Arduino](https://github.com/adafruit/Adafruit_BME680) und einen [CircuitPython](https://github.com/adafruit/Adafruit_CircuitPython_BME680) Treiber
+ 
+ ### Firmware
+ 
+ [Hier](https://github.com/24367dfa/bme680_esp32) bastelt David mit RIOTos an der Firmware auf einem esp32. Übertragung der Daten geplant per WiFi und MQTT.
+ 
+ [Arduino Code Beispiel](https://gist.github.com/JavanXD/e18d510216599d678d1f380f82a6841e) für die Berechnung eines AirQualityIndex
+ 
+ ### Datenübertragung
+ 
+ Die Übertragung kann über BLE geschehen, sofern der Sensor mit Batterien betrieben werden soll.
+ Bei einer festen Stromversorgung kann sie auch über ESP/WiFi oder CAN stattfinden.
+ 
+ 
+ ### Frontend
+ 
+ Die Daten sollen auf OpenHab gesammelt werden und dort ausgewertet werden und ggf. eine Statusmeldung zur Luftqualität im Space veröffentlicht werden.
+ * Openhab nutzt für Persistenz auch nur 3rd-Party-Datenbanken, z.B.
+   * https://www.openhab.org/addons/persistence/rrd4j/
+   * https://www.openhab.org/addons/persistence/influxdb/
+ * Wir könnten die Daten auch direkt in einer Influxdb abliefern. (Dann muss man nicht zwingend OpenHab haben.)
+ * MQTT → InfluxDB ist möglich
+   * http://nilhcem.com/iot/home-monitoring-with-mqtt-influxdb-grafana
+   * https://github.com/mhaas/mqtt-to-influxdb-forwarder
+ * D.h. letztendlich reicht es für den VOC-Sensor, Daten in einem MQTT-Topic abzuladen. Der Rest kann bequemer auf einem RPi oder in einem Docker-Container gemacht werden.
+ 
+ ### Diskussion
+ 
+ - [tux] Wie wäre es mit einem komponentenbasierten Design?
+   - eine Komponente ist der VOC-Sensor, der für alle gleich sein kann
+   - zweite Komponente: Steuerung/Kommunikation, z.B. BLE mit STM oder WiFi mit ESP
+   - dritte Komponente: Stromversorgung: Batteriebetrieben oder mit ext. Versorgung
+ - [maxD] Wollen wir RIOT OS benutzen? Das hat sogar schon einen Treiber dafür: [Externer Link](https://doc.riot-os.org/group__drivers__bme680.html)
+ 
+ ### ToDo-Liste
+ 
+ - Batteriebetrieb oder Kabelgebunden
+ - David hat Breakoutboards bestellt, sind angekommen
+ - Design der Platine
+ - Sammlung der Daten in OpenHab
+ - OpenHab-Indikator, dass gelüftet werden muss oder Luftfilter anwerfen
+ 
+ </markdown>