Archiv der Kategorie: Allgemein

Allgemein

6. Node-RED vs. Python

Nun gab es ja diesen provisorischen minimalen Ansatz der Steuerung meiner Brandmeldeanlage in einem Node-RED-Flow, aber bevor ich nun versuche die gesamte Brandmeldezentrale in diesem Puzzle-Java zu bauen, wollte ich wieder zurück in die Python-Welt, denn Node-RED war ja nur als Visualisierung der Zustände und Ersatz für noch fehlende BMA-Hardware gedacht.

Klar ist die Idee charmant alles mit drag’n’drop in einem Browser-GUI zusammenzuklicken und ein bisschen Code in Funktionsblöcken unterzubringen. Ich möchte aber gerne die volle Kontrolle über das Geschehen haben und fühle mich mit Python einfach wohler als mit Java.

das BMZ-Skript (nodebma_bmz.py)

Es wird also Zeit das Herzstück der Brandmeldeanlage in Python zu schreiben. Um die Kommunikation mit dem I2C-Bus brauchen wir uns nicht mehr kümmern, das macht ja nodebma_interface.py bereits als systemd-Service im Hintergrund. Die BMZ muss jetzt „nur noch“ mit dem Broker sprechen und Entschiedungen treffen.

Auch hier wird nun paho-mqtt zur Kommunikation mit dem Broker genutzt. Das Skript hat im wesentlichen eine Callback-Funktion für die eingehenden MQTT-Nachrichten und eine Main-Loop, in der die Versorgung des FAT-Displays mit der aktuellen Uhrzeit sowie ein paar Logik-Prüfungen stattfinden,

Aus dem MQTT-Callback werden in Abhängigkeit vom erkannten Trigger dann Funktionen für die Alarmauslösung, Rücksetzung, Steuerung von Akustik und Übertragung sowie die Bedienung und Versorgung des FAT umgesetzt.

Was die Brandmeldezentrale leisten soll

werde ich im nächsten Teil versuchen zu umreißen 😉

Allgemein, Bastelei, Brandmeldeanlage

3. C++, der ARDUINO und ich

Wie bereits in der Einleitung geschrieben, soll das ganze ein „Schulungsprojekt“ sein – an dieser Stelle kommen die ersten Gehversuche mit einem Arduino Nano, der Arduino IDE und der Programmiersprache C++. Bisher waren meine Kontakte mit der Arduino-Welt auf das Flashen eines fertigen Projektes für unser Amateurfunk-Relais beschränkt. Auch gegen C++ habe ich mich über die Jahre immer gewehrt, da ich bisher immer mit VisualBasic, php, Javascript und Python irgendwie zum Ziel gekommen bin.

Also erstmal grundsätzlich mit der Materie Arduino vertraut machen und ein paar Zeilen Code zum Abfragen eines Einganges und Setzen eines Ausganges in C++ schreiben. Dank dem Internet und viel Ähnlichkeit zu anderen Hochsprachen kein Hexenwerk und dann in der IDE den Sketch hochladen … Fehlermeldung – Board antwortet nicht.

Nach einer Runde Google offenbarte dmesg, dass der USB-zu-Seriell-Chipsatz CH341 meinem Pi 3B nicht schmeckte. Mit Hilfe einer Anleitung aus dem Netz (finde sie leider nicht wieder) konnte ich einen neuen Treiber für den CH341-Chip kompilieren. Dann gleich der nächster Fallstrick: die originalen Nanos haben irgendwann einen neuen Bootloader bekommen und somit ist die IDE auch primär darauf eingestellt. Die China-Nanos haben wohl überwiegend den alten, also in der IDE umstellen und damit gelang dann auch das Flashen einer blinkenden LED nach Tastendruck am Arduino.

Nun aber schnell zurück zum Projekt … der Arduino soll ja Eingänge lesen und Ausgänge ansteuern und muss noch irgendwie mit dem Raspberry, der ja den MQTT bereitstellt und später die BMZ sein soll kommunizieren. Da neben dem Arduino und dem Raspberry auch noch ein Display und weitere GPIO-Ports benötigt werden, habe ich mich für den I2C-Bus entschieden …

weitere Infos

Treiber CH341SER von juliagoda | GitHub

Allgemein, Bastelei, Brandmeldeanlage

2. Raspberry Pi, Mosquitto und Node-RED

Ohne so richtig zu wissen, wie ich das Herzstück meiner Brandmeldeanlage mal gestalte, geht es im Wesentlichen ja erstmal um diverse Eingänge (Melder, Taster, Schalter) und Ausgänge (LEDs, Display, Relaiskontakte, die sinnvoll miteinander verknüpft werden wollen.

Da ich im Bereich der Lichtsteuerung zu Hause schon mit MQTT arbeite, fand ich es naheliegend auch hier dieses Konzept zur Kommunikation mit Ein- und Ausgängen zu nutzen. Großer Vorteil aus meiner Sicht ist die Option jederzeit extern über den Broker Vorgänge zu triggern bzw. Zustände mitzuverfolgen – gerade während der Entwicklung hilfreich – egal, wie und womit ich später die eigentliche BMZ programmiere. Also erstmal einen Pi Zero mit minimalem Raspbian aufgesetzt und Mosquitto, NodeRED und Python3 installieren – auf die Details gehe ich an dieser Stelle nicht weiter ein.

Mit Node-RED wollte ich eigentlich erstmal nur die diversen Ein- und Ausgänge der Brandmeldeanlage für den MQTT simulieren, aber dann habe ich neben ein paar Flows und Dashboards für FBF, FAT und Melder noch ein paar Grundfunktionen der BMZ in einem Flow zusammengebaut, so dass eine Alarmauslösung, Rückstellung, die Akustik-Abschaltung und die Steuerung der Übertragungseinheit möglich sind. Nach einer Nachtschicht, funktionierte die rudimentäre BMA schon soweit, dass man ein paar grundlegende Dinge probieren kann – weit weg von einer normalen und realitätsnahen Bedienung, aber dennoch beeindrucken, was mit Node-RED so alles machbar ist.

Wie bereits in der Einleitung geschrieben, soll das ganze ja ein Schulungsprojekt sein – nicht nur für die Feuerwehrleute, die den Umgang mit einer BMA üben sollen, sondern auch für mich, denn bei diesem Projekt sehe ich mehr Ein- und Ausgänge als mein Pi Zero GPIO-Pins hat – es braucht also wohl etwas mehr Elektronik und wohl damit verbunden auch eine Auseinandersetzung mit Dingen wie seriellen Bus-Lösungen und Mikroprozessoren.

Links zum Weiterlesen

MQTT | Wikipedia

Node-RED | Webseite

MQTT-Broker Mosquitto | Webseite

Allgemein

Raspberry Pi 4B – gesteuerter Lüfter

Wie ich in meinem Beitrag zum Pi4 als Desktop bereits ausgeführt habe, wir das aktive Kühlen beim Pi4 quasi zur Pflicht, wenn er nicht nur irgendwo in der Ecke steht und die allermeiste Zeit im „idle“ ist. Im Desktop-Betrieb mit LibreOffice oder Youtube per Webseite geht recht schnell die Temperatur hoch und der Lüfter muss laufen.

Ich hatte den 5V-Lüfter an einen 3,3V-Pin angeschlossen und die Masseleitung des Lüfters mit einer Drahtbrücke vom Steckbrett nach außen verlängert und dann bei Bedarf einfach die Brücke an die Masse am USB-Port gehängt. Das funktionierte prima, bis ich nun den Pi in einer Umräumaktion unter den Schreibtisch verlagert habe.

Hardware

Nun musste also was automatisches her und ich suchte aus der Bastelkiste einen Widerstand (4,7k) und einen Transistor (BC547). Für die Verbindung habe ich in Ermangelung einer Buchsenleiste 3 Steckbrücken geopfert.

Beim Anschluss habe ich wieder den 3.3V-Pin genommen (5V geht natürlich auch, ist aber deutlich lauter beim Lüften). Für die Ansteuerung habe ich GPIO2 (Pin3) genommen. Der liegt nach dem Boot auf HIGH und der Lüfter läuft ohne Steuerskript dauerhaft, was ich erstmal als „failsave“ betrachte.

Der GPIO2 geht nun über den 4,7k-Widerstand an die Basis vom Transistor. Die Masse wird auf den Emitter am Transistor geführt und geht von dort über den Kollektor weiter zum Lüfter. Die Verdrahtung ist mit Steckbrücken gebaut, so dass die Schaltung einfach zwischen den Lüfter und den GPIO gesteckt werden kann. Isoliert ist das ganze mit Schrumpfschlauch.

Software

Ich bin ein Freund von Python und daher kam für mich auch nix anderes in Frage. Das Skript wird einmalig gestartet und überwacht fortan die CPU-Temperatur. Ich habe mich dabei für einen Intervall von 5 Sekunden entschieden, weil ich glaube, dass das ausreichend sein sollte.

Beim Überschreiten der Schwelle von 70°C wird der Lüfter eingeschaltet und es wird „laut“ unter dem Schreibtisch. Beim Absinken der Temperatur unter 50°C wird der Lüfter wieder abgeschaltet und es herrscht wieder Ruhe.

cpu_cool.py
#!/usr/bin/python3

import RPi.GPIO as GPIO
from gpiozero import CPUTemperature
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(2, GPIO.OUT)

GPIO.output(2, GPIO.LOW)
cooler = 0

while True:
	ctemp = CPUTemperature().value * 100

	if ctemp > 70 and cooler == 0:
		GPIO.output(2, GPIO.HIGH)
		cooler = 1
	elif ctemp < 50 and cooler == 1:
		GPIO.output(2, GPIO.LOW)
		cooler = 0
	else:
		# wir lassen es so
		pass

	print('Temp:',round(ctemp,2),'Cooler:',cooler)
	time.sleep(5)

 

Grundlage

Tutorial im Raspi-Forum
https://forum-raspberrypi.de/forum/thread/774-lueftersteuerung-per-temperatur-einbauanleitung/

 

Allgemein, Raspberry

Projekt „Wachdisplay“ für das Feuerwehrhaus

Alarmdisplay Immer wieder gibt es den Wunsch, insbesondere bei den kleinen Feuerwehren, für die nach wie vor die Sirene der Hauptalarm darstellt, eine Anzeige der Alarmierung im Feuerwehrhaus zu haben, wohin es geht und welcher Auftrag dahinter steckt.

Quelle der Inspiration

Inspiriert durch eine Anzeige auf Basis eines Oelmann-Alarmempfängers in einem Feuerwehrhaus ging es an die ersten Überlegungen. Dazu erstmal ein Blick, wie das Oelmann-System grob funktioniert:

  • Empfang der Alarmierung über einen Steuerempfänger
  • Ausgabe der Meldung über eine serielle Schnittstelle
  • Umwandlung der Meldung über einen Seriell-VGA-Konverter
  • Darstellung auf einem Monitor

Soweit recht einfach und damit auch nahezu ausfallsicher konzipiert. Die Schwächen des Systems sollen aber nicht unerwähnt bleiben: es wird jede Meldung angezeigt, die im Steuerempfänger als Adresse hinterlegt ist, lange Meldungen werden umgebrochen, aber nicht durchgescrollt, so dass Meldungsteile fehlen  und die Meldungen bleiben dort bis zum Eingang einer neuen Meldung stehen.

Zielsetzung

Es sollte ein System werden, dass die Schwächen ausgleicht und im Sinne einer Vernetzung an mehreren Standorten genutzt werden kann, ohne dort einen eigenen Steuerempfänger zu installieren.

Die Auswertung der Alarmierung musste also irgendwo zentral erfolgen und eine differenzierte Ansteuerung mehrerer Monitore ermöglichen.

Meldungen sollten nach einer Ablaufzeit von der Anzeige verschwinden, da nicht selten sensible Daten in der Alarmmeldung enthalten sind und manchmal auch Nicht-Feuerwehrangehörige in den Gerätehäusern zu Gast sind.

Erste Umsetzung im Sommer 2018

Die Grundversion brauchte von der Idee zur Umsetzung rund ein Vierteljahr. Im Kern gibt es einen „Displayserver“ der über eine API die Meldungen für den jeweiligen Monitor entgegen nimmt und in einer Datenbank speichert. Über die selbe API melden sich die Monitore als „Client“ an und prüfen ob eine Meldung vorhanden ist.

Die Ansteuerung übernimmt dabei ein bereits seit 2015 in der Stadtfeuerwehr eingesetztes System, mit dem SMS- und Mail- und Push-Nachrichten auf Basis der im Landkreis eingesetzten POCSAG-Alarmierung erzeugt werden. So können zu jeder Alarmierung differenziert die Monitore angesteuert werden.

Auf der Clientseite läuft das ganze als HTML/Javascript-Kombination, die so mit verschiedenen Systemen und Browsern betrieben werden kann.

Zusammen mit einem Freund wurde noch eine Wetter/Unwetter-Leiste integriert. Im Ruhezustand zeigt sie Wetterdaten, bei ausgewählten Warnereignissen im Stadtgebiet verfärbt sich die Leiste entsprechend des DWD-Farbschemas und zeigt die Headline der Meldung an, so dass Kameraden wissen, was sie draußen noch erwarten könnte.

Die erste Testphase

Neben meinem Client auf einem Raspi 3b gab es noch einen auf einem Android-Tablet, einem Windows PC und einen weiteren Linux-PC – alle mit verschiedenen Broswern und Systemen.

Als Hardware im Feuerwehrhaus kam im ersten Test ein Raspberry Pi Zero W zum Einsatz, der aber durch die grafische Oberfläche mit Browser manchmal ins straucheln kam. Da stand schnell die Entscheidung weitere Clients nur noch als 3b auszurüsten.

Es wurden einige Fehler gefunden, neue Ideen gesammelt und so manche Stunde damit verbracht das System weiter zu optimieren.

Geocoding in 2019

Als wesentliche Neuerung gab es dann im Frühjahr 2019 das Geocoding-Routing. Der Displayserver versucht aus den Einsatztexten den Einsatzort rauszulesen und mit Hilfe der Google-Geocoding-API in eine Koordinate umzusetzen. Als Freund von freier Software habe ich zuvor die OSM-Variante getestet, musste aber feststellen, dass die Anzahl der falschen Georeferenzen sehr hoch war. Selbst mit der Google-API gibt es zuweilen Einsatzstellen in mehreren 100km Entfernung.

Die gewonnene Koordinate wird nun genutzt um eine kleine Karte mit Anfahrtsweg inkl. geschätzter Fahrzeit und Strecke anzuzeigen. Dazu gibt es eine Luftbildkarte der Einsatzstelle um einen Blick auf die Bebauung zu haben.

Mit diesen Kartenausschnitten und Informationen sollte auch eine Möglichkeit entstehen Einsatzdepeschen auszudrucken, jedoch ist aufgrund verschiedener Schwierigkeiten hier noch keine stabile Version entstanden. *to be continued*

Remote Control in 2019

Ein weiterer Punkt ist die Steuerung eigenen Monitors an der Wand. Der Raspi an sich wird ohne Maus und Tastatur betrieben. Im Alltag „heilt“ er sich durch Cronjobs selbst, wenn mal was abstürzt. Für die Administation gibt es einen Zugang über einen SSH-Tunnel vom Displayserver aus, so dass Updates vorgenommen und kleine Probleme headless behoben werden können.

Zum Nutzen der Client-Funktionen (Letzte Meldung, Reload, Signalton) brauchte es weiterhin mindestens eine Maus oder einen Touchscreen. Alternativ ist noch eine VNC-Verbindung aus dem selben LAN möglich.

Da wir hier über Feuerwehr sprechen, musste noch eine einfache Lösung her. Auf dem Client-PC wurde mittels eines Python-Skripts ein Mini-Webserver eingerichtet, der eine kleine Fernsteuerung anzeigt. Hier sind jetzt die Funktionen für Ausschalten des Displays, Neustart und letzte Meldung sowie eine Testfunktion einfach aus dem Netzwerk erreichbar.

Was noch fehlt und geplant ist

Es fehlt noch die stabile Funktion der Alarmdepesche, die auf dem lokalen bzw. Netzwerk-Drucker im Feuerwehrhaus landen soll. Ein Ansatz ist da, aber es fehlt noch der letzte Kniff.

Ein Relais-Ausgang via USB-Port wird auch von einigen erwartet, sei es um das Licht anzuknipsen oder eine Tür im Feuerwehrhaus zu öffnen. Auch hier gibt es einen Ansatz, aber es fehlt die Implementierung auf der Client-Seite.

Und einen ganz anderen Gedanken, banalen und ökologischen hat auch ein Kamerad zurecht geliefert: Warum muss der Monitor an sein, wenn gar keiner da ist? Hier gibt es auch verschiedene Möglichkeiten:

  • Monitor mit einem Bewegungsmelder ausstatten
  • Power-Management-Funktionen am HDMI-Ausgang nutzen. Dafür Bedarf es aber einer ähnlichen Implementierung wie beim Relais und der Depesche, denn das liegt außerhalb des HTML/Javascript-Universums.

Die Ideen und Wünsche gehen nicht aus – manchmal sind es ganz kleine Dinge, die aber eine komplexe Umsetzung erfordern.

Allgemein

VGA mit DualScreen am Raspi – zweiter Anlauf

Nachdem ich meinen Raspi irgendwann von Jessie auf Stretch aktualisiert habe, war mein USB2VGA-Adapter von DisplayLink nutzlos geworden. Der auf die armhf-Architektur portierte DisplayLink-Treiber steht für Stretch nicht zur Verfügung.

Ich hatte mich schon damit abgefunden, dass mein zweiter Monitor für immer dunkel bleiben würde, bis ich letzte Woche durch Zufall auf rasppishop.de das Gert VGA666-Board gesehen habe.

Gert VGA666-Board

Dort wurde die DualScreen-Funktionalität erwähnt und ich vertraute blind. Ein Bekannter warnte mich schon, dass er bei anderen Händlern gelesen hätte, dass es nicht so ohne weitere funktionierte.

Gestern konnte ich dann mein Gert VGA666 zusammenbauen, welches als Bausatz daher kommt. Man bekommt eine Platine, ein paar Widerstände und eine Buchsenleiste für die GPIO-Pins und natürlich eine DSub-VGA-Buchse. Man könnte das Gebilde auch komplett ohne den Bausatz nachbauen, denn die Schaltung ist kein Geheimnis. Infos gibts unter anderem über GitHub unter PiSupply. Das Löten erfordert keine besonders hohen Löterfahrungen und geht recht schnell mit Hilfe der Bestückungsanleitung aus dem Git.

Danach musste mein TekBerry-Gehäuse dran glauben, damit der VGA-Port seinen Weg nach draußen findet. Die notwendigen Treiber sind im Raspian bereits implementiert. Man muss das nur noch in der config.txt das DPI-Interface aktivieren und entsprechend einstellen. Jetzt kann man wahlweise HDMI, Composite oder eben VGA als primäre Anzeige verwenden. Mein Monitor am VGA lief sofort ohne Bildfehler, somit war meine Lötarbeit erfolgreich.

Nun kommt der schwierige Teil – nativ kann der der Raspberry auch im Jahr 2018 noch kein DualScreen. Man kann zwar zwischen Display per HDMI, SPI, DPI (VGA) und Composite wählen, aber es gibt in der Firmware per default nur ein Framebuffer-Device, sprich eine Adresse und einen Speicherbereich für die grafische Anzeige. Es gibt einen „workaround“ mit dem man wohl mittels omxplayer ein Video auf den zweiten Screen „zaubern“ kann, aber eben keinen Desktop. Wenn man sich in den Foren berichte zum Gert VGA666 durchließt, stößt man immer wieder an diese Grenze.

DualScreen am Raspi mit Beta-Firmware

Durch Zufall habe ich dann im Raspberry-Forum einen Beitrag von JamesH gefunden, der eben genau an dieser Problematik getüftelt hat, da auch mit den „originalen“ SPI-Touch-Displays kein DualScreen möglich ist. Er hat sich hingesetzt und die Firmware modifiziert, damit diese einen weiteren Framebuffer bereitstellen kann – also einen autarken zweiten Screen erzeugt, der dann über andere Software angesteuert werden kann.

Gesagt getan – Downgrade des Kernels auf meinem Raspi (es muss nämlich die Kernel-Umgebung exakt zur Firmware passen) und dann Kernel und Firmware von Jamesh in meinen Raspi gespielt. Ein paar Änderungen an der config.txt vorgenommen und dann den Raspi neu gestartet – jetzt wacht der zweite Monitor schon mal aus dem PowerSafe auf – bekommt also Signal aus dem Raspi.

Xorg – eine manuelle Konfig muss her

Nun blauäugig wie ich war habe ich meine „alte“ DualScreen-xorg.conf genommen und ein bißchen drin rumgeändert – aber es lief nicht. Der zweite Schirm bleibt schwarz – als primary Display zeigt er eine vermurkste  Grafik – irgendwas passt also nicht. Ein Test mit fbi (FrameBuffer Imageview) zeigt, dass ohne xorg beide Framebuffer sauber arbeiteten – aber warum klappt es mit meiner xorg.conf nicht?

Auch dieses Rätsel konnte ich heute nach nochmaligem Nachdenken und probieren rausfinden. Während USB2VGA-DisplayLink auf dem zweiten Monitor eine Farbtiefe von maximal 16-Bit erwartet, kam das Gert-Board damit nicht zurecht. Es möchte genau wie der HDMI-Port mit 24-Bit angesteuert werden. Nach Änderung der xorg.conf hat es sofort meinen zweiten Bildschirm erkannt und ich konnte (wie beim DisplayLink) dort einen zweiten Desktop mit zweitem Launcher und eigener Browserinstanz starten.

Wer, anders als ich, einen erweiterten Desktop nutzen möchte, kann in der xorg.conf Xinerama aktivieren. Alternativ dürfte auch Clone möglich sein, habe ich nicht getestet, weil ich es nicht brauche).

Nachtrag: ich nutze jetzt seit einigen Wochen Xinerama am Raspi mit HDMI und GERT-VGA – was soll ich sagen: ich bin sehr begeistert, denn es funktioniert tadellos und ohne merkliche Leistungseinbußen auf dem Raspi 3B+. 

Upgrade des Raspian-Systems

Damit bei einem Update des Systems der Bootloader und der Kernel im Beta-Status bleiben, muss man vor einer Systemaktualisierung die entsprechenden Pakete auf „hold“ setzen:

user@pi:~ $ sudo aptitude hold raspberrypi-bootloader
user@pi:~ $ sudo aptitude hold raspberrypi-kernel

Danach werden bei einem apt update und apt upgrade die beiden Pakete ausgelassen, aber das restliche System wird trotzdem aktuell gehalten.

Ich gehe davon aus, dass irgendwann der Kernel-Hack offiziell in das Raspbian einfließen wird.

Code-Schnipsel
config.txt
[...]

# GERT VGA666
dtoverlay=vga666
enable_dpi_lcd=1
#display_default_lcd=0    ## =1 macht den VGA-Ausgang zum primären Monitor
dpi_group=2
dpi_mode=35
start_x=1
max_framebuffers=2
framebuffer_priority=2   ## =2 macht den HDMI-Port zum primären Monitor wenn die Beta-Firmware eingespielt ist
xorg.conf
Section "Device"
 Identifier "hdmi"
 Driver "fbturbo"
 Option "fbdev" "/dev/fb0"
EndSection

Section "Device"
 Identifier "vga"
 Driver "fbturbo"
 Option "fbdev" "/dev/fb1"
EndSection

Section "Monitor"
 Identifier "Terra"
 Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync
 Option "PreferredMode" "1280x1024_60.00"
 Option "DPMS" "true"
EndSection

Section "Screen"
 Identifier "vga"
 Device "vga"
 Monitor "Terra"
 DefaultDepth 24
 SubSection "Display"
 Depth 24
 Modes "1280x1024"
 EndSubSection
EndSection

Section "Screen"
 Identifier "hdmi"
 Device "hdmi"
 Monitor "Terra"
 DefaultDepth 24
 SubSection "Display"
 Depth 24
 Modes "1280x1024"
 EndSubSection
EndSection

Section "ServerLayout"
 Identifier "default"
 Screen 0 "hdmi" 0 0
 Screen 1 "vga" RightOf "hdmi"
# Option "Xinerama" "on"
# Option "Clone" "on"
EndSection
Allgemein

NotrufSim (4) Optimierung Netzwerk

Fortsetzung von (3) WLAN-AP mit DHCP

Nachdem das WLAN als Accesspoint funktioniert steht nun das Finetuning an, denn auch kabelgebundene Geräte wie ein SIP-Telefon sollen sich am Pi anmelden können. Dafür müssen sie auch an der LAN-Schnittstelle (eth0) eine IP per DHCP bekommen.

Haken an der Sache, wenn man eth0 auch mit DHCP-Server konfiguriert, kann sich der Pi nicht mehr mit einem bestehenden Netzwerk verbinden um ggf. auf das Internet zugreifen zu können. Zudem gibt es Probleme, wenn man den Pi mit DHCP-Server auf eth0 an ein bestehendes LAN verbindet, denn dann gibt es höchstwahrscheinlich zwei DHCP-Server und das sorgt für unvorhersehbares Verhalten bei der IP-Vergabe. Aber nun erstmal zur grundsätzlichen Einrichtung. NotrufSim (4) Optimierung Netzwerk weiterlesen →

Allgemein

Wohin mit den Spenden?!

Als Ende August die ersten Außenstellen vom Lager Friedland in der Region belegt wurden, hatte Sascha Leibecke die Idee, dass der Elternbeirat der ev. Kindertagesstätte Schoningen eine Sachspendensammlung für die Flüchtlinge organisieren könnte. Sein Gedanke: Kita-Eltern haben vielleicht ein paar Spielzeuge die nicht mehr benötigt werden oder Bekleidung aus denen die Kinder rausgewachsen sind über, um damit ein paar Kinderherzen in den Flüchtlingsfamilien glücklich machen können.

Wohin mit den Spenden?! weiterlesen →