• Du musst dich registrieren, bevor du Beiträge verfassen kannst. Klicke auf Jetzt registrieren!, um den Registrierungsprozess zu starten. Registrierte User surfen werbefrei, können Suchen durchführen und sehen die volle Darstellung des Forums mit vielen anderen Unterforen!!!

WLAN-Thermometer selbst bauen mit Raspberry Pi

Hallo Phantomias,

Wow so soll es sein!
@Armin nichts für ungut ;-)

Hab mir soeben auch ein paar davon geschossen...

:wow:

Joe

PS: Servo blaster läuft mit zwei Servos....
 
Freut mich dass es euch gefällt :anstoßen:

Unter dem IC sind noch 2 drahtbrücken
1x sin die zwei GND verbunden
1x sind die zwei VCC verbunden

Falls ihr noch detailaufnahmen wollt kann ich noch welche erstellen...
Aber im Prinzip müsst ihr nur mehr löcher zählen :ks:
 
Hallo,

ich habe soeben das Servoblaster Modul am laufen und zwei GPIO in PWM umgewandelt daran habe ich einen Servo und den zweiten mit einem Thor 15 Regler und einem 12V Ventilator und muss sagen es läuft super!

Somit steht einer Verwendung im WLANThermo nichts mehr im wege!

:anstoßen:

Joe

PS: Wo bleiben meine Humble PI's!
 
@Joe

Das mit PWM hört sich sehr gut an ;-)
Ich wollte einen Schrittmotor anschließen und damit den Q300 über den gasdruckminderer regulieren...
Kannst du das mi den Servo mal genauer erleutern und ein paar pic's hochladen?
 
Hallo Phantomias,

das Servoblaster Modul ist relativ einfach hole dir dazu
Code:
git clone git://github.com/richardghirst/PiBits.git

Und stelle in der servod.c die Anzahl und Zuordnung der GPIO Pins ein
Code:
static uint8_t servo2gpio[] = {
        4,      // P1-7
        17,     // P1-11
/*      18,     // P1-12
        21,     // P1-13
        22,     // P1-15
        23,     // P1-16
        24,     // P1-18
        25,     // P1-22*/
};
Für nur 2 Servos...

und dann erstelle eine servod mit
Code:
make servod

Diese servod musst du dann mit
Code:
chmod +x servod
Ausführbar machen.

Wenn du diese dann startest
Code:
./servod

Dann läuft ein Prozess im Hintergrund welcher auf die Fahrbefehle wartet.
Ein fahrbefehl schaut z.B. so aus:
Code:
echo 0=150 > /dev/servoblaster
0 wäre das erste Servo und 150 die Position (mitte) 50 ist eine Seite und 250 die andere Seite aber das ist je nach Servo etwas verschieden.

Du siehst also es ist eigentlich ganz einfach ich habe mir +5V, GND und den GPIO direkt vom PI geholt und es läuft...

Wenn du stärkere Servos anbindest vergiss nicht diesen direkt Stromzuversorgen und die Masse zu verbinden....

LG

Joe
 
Hi Joe,

Also das gefällt mir aufn ersten Blick ganz gut :anstoßen:
Brauche aber einen Servo mit ca. 270Grad drehwinkel.
Muss mal schauen ob ich so einen finde bzw. ein paar Zahnräder solltens auch tun :hammer:

Auf dein script zum steuern bin ich gespannt...
Hast du dir diesbezüglich schon gedanken gemacht?
Willst du alle 5min regulieren oder wie stellst du dir das vor?

Lg
 
Hallo Phantomias,

ok dafür würde ich eher einen Stepper nehmen, ich hab da günstige gefunden die sind zwar schon unterwegs zu mir aber das wird noch ca. 2 Wochen dauern bis die da sind dann kann ich dir genaueres wegen der Kraft sagen die diese haben. Und die Steuerplatine ist von RPI mit 4 GPIO's direkt verwendbar...

Bestellt bei Dealextreme kostenloser Versand nur die Lieferung dauert ca 3 Wochen. Der Motor hat schon ein treiber Board dabei und eine Untersetzung von 65:1 ich möchte damit ein "Proof of concept" für mein nächstes Projekt CNC Fräße mit linuxcnc (natürlich auch ein RPI) machen...

Sonst gibt es noch den Thor 15 Regler als Servoelektronik, d. h. der Fahrenregler hat ein Drehpodi und agiert als Servo nur halt mit stärkeren Motoren, wenn du hier ein anderes drehppodi mit einem größeren Bereich verwendest kannst du Mechanisch fast alles bewegen!

LG

Joe
 
Zuletzt bearbeitet:
Hallo an alle die sich mit dem Code beschäftigen,
Was haltet ihr davon die WLANThermo.conf ebenfalls über die GUI zu ändern? Dann müßte man nicht mehr mit einem Editor die Datei anfassen und evtl. Schrott reinschreiben, so dass nix mehr oder nur noch falsch funktioniert.

Grüße Marco
 
Hallo Grillprophet,

gute Idee vor allem die Sensorauswahl per GUI wäre super, damit diese aber auch übernommen wird muss vom GUI aus der Python Dienst im Hintergrund neu gestartet werden.
Im Moment lauf das ganze aus der Sicherheitsperspektive gesehen sehr unsauber da php in Verzeichnisse schreiben darf was normal nicht gut ist.

Also kann ich jeden nur davon abraten den WLANThermo direkt (Ohne Apache reverse Proxy mit SSL Auth auf einem anderen Server ) ins Internet zu hängen!

Die Umsetzung von Phantomias den Gui Dynamisch was die Anzahl der Sensoren angeht zu machen finde ich super --> der GUI Zeigt einfach die an die einen Plausiblen Wert haben!
Das in Kombination mit einem Einstellungsdialog auf Pop Up basis der auch die Grundeinstellungen abdeckt (WLANThermo.conf) und einer Temperaturregelung sollte das Projekt vom Umfang her recht brauchbar machen ;-)

@Alle: Kennt sich jemand von euch bei der Temperaturregelung aus?

Mein Plan ist es mit 2 GPIO's einen für den Drehzahlregler (Gebläse) und einen zweiten für einen Servo (Drosselklappe) auf den Joe 16" Aufzubauen um damit die Garraum Temperatur konstant zu halten.

@Armin u. Phantomias: machen wir hier Arbeitsteilung bzw. was haltet ihr vom Umfang?

Bitte um Rückmeldung ich würde gerne mit euch an dem Projekt weiterarbeiten und nicht nur eine Individuallösung nur für mich machen.

LG

Joe
 
Hallo, das Script im Hintergrund neu starten ist natürlich der richtige Weg. Ein einfaches Stecker raus, Stecker rein sollte es aber genauso tun. Das Linux und die WLAN Software sollte das ankönnen. Allein schon weil die wenigsten ihren Raspi nach erreichen der KT des Garguts mit "sudo halt" runterfahren.

Vielleicht wäre ja eine Alternative, nach dem schreiben der Config noch eine "flag"-Datei anzulegen. Das Script pollt bei jedem Messdurchlauf nach dem flagfile und liest bei dessen Vorhandensein die Config neu ein. Danach wird das flagfile wieder gelöscht.

Grüße Marco
 
@Joe, @grillprophet,

Das mit den Einstellungen bezüglich der Sensoren schwirrt mir auch schon einige Zeit im Kopf herum...

Über "shellexec" können wir sehrwohl das script neu starten nur aus Sicherheitsgründen muss ich Joe recht geben wobei mir die Lösung mit der Flag schon gut gefällt.

Entweder baut das Armin mitein und Lagert die Sensorconfig aus oder wir startet einen 2ten Dienst der das setzen des Flag's erkennt und das script neu startet.

Ich wäre so wie Joe für eine Arbeitsaufteilung!
Wobei ich euch im bereich Python nicht sehr behilflich sein kann.

Vom Umfang her wäre ich für eine Modul ähnliche struktur.
Weil nicht jeder alles braucht bzw. der eine oder andere diverse 'speziallösungen' benötigt. Demnach würde ich die Steuerung auf jeden Fall auslagern von den normalen Python script. Mit den richtigen Schnittstellen seitens Python und PHP sollte das ganze kein großes Problem darstellen.

Also das Hauptpgrogramm würde nur die Messung der Temp's beinhalten. So wie es jetzt schon läuft.Für 80% der nutzer vermutlich vollkommend ausreichend. Für Joe's steuerung der Lüfter und Klappen z.B. wäre ich für ein 2tes .py script was diesen Job erledigt. In Php hätte ich gesagt dass wir das ganze script so auslegen dass er automatisch erkennt wenn im Verzeichnis /module eine Datei namens "joestempregler.php" liegt und diese automatisch includiert und Werte etc. automatisch anzeigt. Ähnlich wie es mit den Tempfühlern der Fall ist. Vorteil ist dass der eine (wie Joe z.B.:) Einen Servo und einen Lüfter verwenden kann und ich z.B. einen Schrittmotor für den gasdruckregler... Und nicht jeder alles stunden lang anpassen muss bei einer Aktualisierung.

Lg
 
Zuletzt bearbeitet:
@Joe, @grillprophet,
Vorteil ist dass der eine (wie Joe z.B.:) Einen Servo und einen Lüfter verwenden kann und ich z.B. einen Schrittmotor für den gasdruckregler... Und nicht jeder alles stunden lang anpassen muss bei einer Aktualisierung.

super, dass ihr euch da so reinhängt. wäre noch schön, wenn ein zusätzliches modul für alle uds user eingefügt wird in dem nur ein lüfter angesteuert wird.
das wäre dann ja nur eine abgespeckte version von Joe!s plan. ist das möglich?
 
Hellole,

ich melde mich mal zu Wort.

1. PHP-Script für die Config fände ich super! Den Service kann man ja ganz einfach mit "service WLANThermo restart" neu starten. Allerdings wird bei einem Restart eine neue Log-Datei erzeugt. Man könnte natürlich in der Sektion "Logging" einen Conf-Parameter "Log_File_on_restart" mit den Werten "Create" und "Append" anlegen und auswerten. Da kann man im laufenden Betrieb umkonfigurieren, ohne das Log-File zu splitten.

2. Für die Regelung einen zweiten Dienst halte ich für notwendig, da die Regelung ja unhabhängig vom Messen zuschlagen muss. Ich habe keine Ahnung, ob man in Python innerhalb eines Programmes Multithreading machen kann, glaube ich aber eher nicht. Also macht man zwei Dienste und das Betriebssystem kümmert sich um das Threading.

3. So eine "Ich blas dem UDS eine!"-Regelung fände ich persönlich sehr cool. Hätte ich gestern gut brauchen können - hab dann einen Fön genommen! :bodenlieglachgabud: Das sollte mit einer Transistorstufe problemlos machbar sein. Wahrscheinlich brauch man aber ein extra Netzteil dafür. Müsste man mal testen, ob ein normaler 5V-Lüfter noch mit laufen kann, ohne dass das Steckernetzteil in die Knie geht.

4. Sicherheit
Joe, wenn Du einen Vorschlag hast, wie man das Teil sicherer machen kann, her damit. Da bin ich absolut kein Crack drin. Ich weiß aber, dass der Raspi mit Apache prima läuft. Ich hatte den mal installiert und später den Lighty und vergessen, dass noch der Apache läuft! :D Ging alles bene!

5. Knapp werdende GPIO
Wenn ihr die 2.0 Version des Raspi habt, hätte ich noch 4 GPIO extra für euch:

Raspberry Pi P5 Header | Raspberry Pi Spy

Nur die 8-polige Pfostenleiste einlöten und los geht's!


6. Graph erstellen
Bei meiner PB-Aktion am Wochenende habe ich ja wieder mein Plot-Script eingesetzt. Dank des Inputs von Germes sieht das doch schon sehr ansprechend aus. Mein Ansatz ist wieder ganz einfach gewesen:

Edith sagt: Erst GNUPLOT installieren:

Code:
apt-get update
apt-get install gnuplot

Ich habe einen Dienst Plot gebastelt:

unter /etc/init.d wird eine Datei "plot" erzeugt:

Code:
#!/bin/sh
# Starts and stops Plot-Service for WLANThermo
#
### BEGIN INIT INFO
# Provides:          plot
# Required-Start:    
# Required-Stop:     
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Startet Thermoplotter Dienst
# Description:       Startet Thermoplotter Dienst
### END INIT INFO

case "$1" in
start)

    /usr/sbin/plot.sh >/dev/null &
    echo "Starting Thermo-Plotter"    
    
;;

stop)
    

    killall plot.sh
    echo "Stopping Thermo-Plotter"

;;

restart)
    $0 stop
    $0 start
;;


*)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac
Unter /usr/sbin habe ich das script plot.sh (755) und die Befehlsdatei plotter für GNUPPLOT plaziert:

plot.sh

Code:
#!/bin/sh

while true; do
gnuplot /usr/sbin/plotter

echo 'geplottet!'
sleep 10
done
plotter

Code:
reset
set encoding locale
set terminal png size 1280,900
set title "WLAN-Thermometer-Plot"
set datafile separator ','
set output "/var/www/temperaturkurve.png"
set key box
unset grid

set xdata time
set timefmt "%d.%m.%y %H:%M:%S"
set format x "%H:%M"
set xlabel "Uhrzeit"

set ylabel "Temperatur [°C]"
set yrange [0:130]

set xtics nomirror
set ytics nomirror

plot '/var/log/WLAN_Thermo/TEMPLOG.csv' every ::1 using 1:2 with lines lc rgb "green" t 'Kanal 0', '/var/log/WLAN_Thermo/TEMPLOG.csv' every ::1 using 1:3 with lines lc rgb "red" t 'Kanal 1', '/var/log/WLAN_Thermo/TEMPLOG.csv' every ::1 using 1:4 with lines lc rgb "blue" t 'Kanal 2'
Mit einem

Code:
update-rc.d plot defaults
ist der Dienst im System verankert und kann gestartet und gestoppt werden.

Cool wäre jetzt ein PHP-Script, was die folgenden Plot-Parameter in eine Datei plot.conf schreibt:
Code:
Sektion "Head"
Titel String

Sektion "Channels"

Plot_Kanal_0 Boolean
Plot_Kanal_1 Boolean
Plot_Kanal_2 Boolean
Plot_Kanal_3 Boolean
Plot_Kanal_4 Boolean
Plot_Kanal_5 Boolean
Plot_Kanal_6 Boolean
Plot_Kanal_7 Boolean

Bezeichnung_Kanal_0 String
Bezeichnung_Kanal_1 String
Bezeichnung_Kanal_2 String
Bezeichnung_Kanal_3 String
Bezeichnung_Kanal_4 String
Bezeichnung_Kanal_5 String
Bezeichnung_Kanal_6 String
Bezeichnung_Kanal_7 String

Sektion "Range"

Temp_Y-Achse_Min Integer
Temp_Y-Achse_Max Integer
6. Ihr habt euch noch nicht auf die Schnittstellendatei geeinigt, die ich euch erzeugen soll! :D




Grüßle und Tschöh!

Armin
 
Zuletzt bearbeitet:
Hallo Armin,

Super, gut das ich nicht selber gerade an einem Graphen gebastelt habe ;-)

Ich habe soeben versucht deinen WLANthermo dienst aus dem GUI (php) neu zu starten und es ist mir nicht gelungen, das ist in debian 7 sicher aus Sicherheitsgründen nicht möglich weil mit shell_exec kann ich z.B. die Prozess ID lesen aber keinen Service sogar mit sudo nicht. Ein vielleicht Möglichkeit mit shell_exec('echo rootpassword | sudo - service WLANthermo stop'); kommt aber nicht in frage denn ich würde das root password nie in den quellcode einer webseite schreiben...
Ich glaube deshalb wir werden sogar einen dritten Dienst brauchen der neben dem Temperatur Service und dem Regel Service die anderen beiden Überwacht und vor allem über Flags in der konfig neu starten kann.
Gerade aus Sicherheitstechnischer betrachtungsweise ist dies der beste und vor allem sicherste weg wenn so viel als möglich hardcodiert in dem service steht also kein name des dienstes als parameter oder über die config übergeben wird!
Auch wäre es viel sicherer wenn die /etc/WLANThermo/WLANThermo.conf nicht von PHP direkt geschrieben sondern auch von diesem Dienst quasi Übernommen (kopiert) wird und PHP nur ins webverzeichnis schreiben soll / darf.
Dann könnte man dem www-data Benutzer wieder sicherer machen und vor allem bei einer neuinstallation muss der Benutzer www-data keine weiteren gruppen / rechte bekommen.
Das schreiben der config hingegen Funktioniert ohne probleme also kann ich die Parameter aus dem GUI Erweitern.

Zum Thema logging, warum wird das log nicht immer angefügt und nur Zyklisch z.B. jeden Tag neu erstellt?

Temperaturregelung / Drehzahlsteuerung ist mit dem Servoblaster Modul einem freien GPIO und Modellbau Fahrtenregler möglich. Das würde ich gerne in angrif nehmen sobald klar ist welche Basisarbeiten noch zu machen sind und wie sich der code inzwischen verändert hat.

Gerade was GPIO "sparen" angeht würde ich gerne die gelbe und rote Led "opfern" da die Anzeige ja in Zukunft vom LCD gemacht wird oder?

Auch sollten wir überlegen die Daten die permanent generiert werden wie das log und nun den Graphen in ein RAM Drive wie es Grillprophet schon vorgeschlagen hat) statt auf die Speicherkarte zu schreiben, die halten nicht ewig und ich kann jeden nur raten eine möglichst große karte zu verwenden (ich verwende mit dem PI keine unter 8GB) da es einen Algorythmus beim schreiben auf eine SD KArte gibt der alle Speicherblöcke gleichmäßig verwendet also desto mehr freier speicher desto länger hält die karte durch.

@Armin
  • die von dir benötigte plott.conf soll wo abgelegt werden? Es geht dir scheinbar um die Namen der Kanäle und die Anzahl oder nur die Namen?
  • gibt es eine neue Version mit deinen Änderungen dann kann ich darauf weitermachen!
  • Schnittstelle ist erst ein Thema wenn wir uns auf einen GUI geeinigt haben.

@Armin, Phantomias wollt ihr das gemeinsam mit mir machen?
Mein Vorschlag wäre:
  • Konzept --> Drei Services -> Armin wlt_2_comp.py und Joe die beiden anderen
  • GUI --> Phantomias verwendet seinen GUI mit dem Plot von Armin und dem PopUp von mir.
  • SERVICE WLANThermo --> Log Täglich neu erstellen.
  • SERVICE WLANRegelung --> Neu von Joe
  • SERVICE WLANT_WT --> Neu von Joe

Ich würde es schade finden wenn wegen unserer Komunikations defizite das Super Projekt von Armin leiden würde denn ich denke ich habe durch Armins Arbeit hier im Forum neue Freunde gefunden :anstoßen:!

LG

Joe
 
Zuletzt bearbeitet:
Also ich bin dabei beim Projekt soweit ich euch unterstützen kann ;-)

Von meiner seite hat sich nichts geändert derzeit am script weil wir ja noch nicht schlüssig sind...

Zwecks datenschnittstelle da lass ich Joe den vortritt.
Joe such dir was aus :-P

Bezüglich der LED's

Da bin ich Joe's ansicht.Ich habe die nicht angeschlossen weil ich die nicht Wirklich brauche. Wir könnten aber auch das Display auf i2c umstellen...
Da sparen wir auch den einen oder anderen IO
Ich würde aber lieber einen Taster fürs deaktivieren des summers haben statt 4LED's... Nur mal ein kleiner Gedankenanstoß....

Lg
 
Hallo,

Mensch Armin, jetzt kommst du mit zusätzlichen GPIO ums Eck.:motz:

Gestern abend hab ich meine Platine mal als Piggyback fertiggestellt und als Prototyp in Auftrag gegeben.


Raspitherm_PWM.jpg


3D-Ansicht_PCB.jpg


IMG_5450.jpg





Bisher hatte ich das hier aus den Beiträgen herausgelesen, dass doch verstärkt das Interesse an einem LCD besteht. Deswegen sind die Anschlüße dafür in einem eigenen Stecker herausgeführt.
Durch das LCD sind mMn die LED überflüssig geworden. Darum hab ich die garnicht mehr eingezeichnet.
Zu guter letzt sind die frei gewordenen GPIO zusammen auf einem weiteren Stecker zusammengefasst. Duch die fehlenden LED hat sich deren Zahl jetzt auf sechs erhöht.

Ihr könnt euch also richtig austoben...
 

Anhänge

  • Raspitherm_PWM.jpg
    Raspitherm_PWM.jpg
    32,7 KB · Aufrufe: 2.516
  • 3D-Ansicht_PCB.jpg
    3D-Ansicht_PCB.jpg
    73,9 KB · Aufrufe: 2.414
  • IMG_5450.jpg
    IMG_5450.jpg
    37,6 KB · Aufrufe: 2.457
Zuletzt bearbeitet:
@grillprophet

Sieht super aus !
Bin mal auf deinem Prototypen gespannt im Betrieb...

@Joe

Mit deinem Arbeitsplan ansich wäre ich einverstanden.
Ich werd mir Morgen mal das von Armin vorgeschlagene gnuplot vom post
Anschaun...
Wo soll diese Graphic denn angezeigt werden?
Auf einer eigenen Seite mit symbol oben oder direkt über/unter den temp Werten?
 
Zuletzt bearbeitet:
Zurück
Oben Unten