LED Temperaturanzeige durchschleifen möglich

[Borsti84]

Hallo Liebe Braufreunde.

Vor meinem nächsten Brautag soll meine Brausteuerung noch etwas gepimpt werden. Ich habe folgendes vor.
Ich nutze als Brausoftware entweder die Brausoftware von Samba & Bier oder die Brauerei von Emilio über meinen LapTop mit Win 7. Gesteuert über Parallelport- oder USB-Relaisplatine(Denkovi). Als Temperatursensor nutze ich einen DS18b20 über USB9097 Adapter. Jetzt möchte ich an meinem Braubedienpult so eine LED Temperaturanzeige integrieren.

Hier soll oben links die LED Temperaturanzeige eingebaut werden.

Hier das Bedienpult nochmal von hinten

Jetzt habe ich in einer 30cm Tauchhülse einen DS18b20 sensor mit Wärmeleitpaste schön eingelassen. Dieser soll da auch bleiben. Möchte also nur einen DS18b20 sensor nutzen. Jetzte ist meine Frage ob man quasi den einen Temperaturfühler irgendwie erst am LED Display anschließt und anschließend zum USB9097 durchschleift? Hat so etwas schon mal jemand probiert bzw. ist so etwas mit ONE WIRE überhaupt möglich?

[hoggel1]

Hallo Sebastian,

ich nutze zwar nicht Samba und Bier, aber ich glaube nicht, das es so einfach möglich ist. Sowohl Samba und Bier, wie auch die Temperaturanzeige benötigen exklusiven zugriff auf den Temperatursensor.

Was gehen müsste, wäre eine externe Anzeige von Samba und Bier, ob das vom Programm unterstützt wird, weis ich nicht. Ich denke, du kommst um einen 2. Sensor nicht drum herum.

MfG
Thomas

[Borsti84]

OK Danke schonmal für die Antwort.
Einen zweiten Sensor möchte ich mir auf jedenfall sparen. Die Brausoftware startet ja Digitemp und schreibt den Temperaturwert in eine Log-Datei. Die Braussoftware bezieht dann den Temp.wert aus dieser Log-Datei.
Wenn ich so eine LED anzeige über USB anschließen und diese dann die Temperatur über die Log-Datei holt wäre natürlich auch ne gute sache. Nur fertig habe ich so etwas noch nicht gesehen. Kennt sich jemand mit so etwas genauer aus?

[giggls]

Was gehen müsste, wäre eine externe Anzeige von Samba und Bier, ob das vom Programm unterstützt wird, weis ich nicht. Ich denke, du kommst um einen 2. Sensor nicht drum herum.

Ich kenne jetzt "Samba und Bier" nicht, aber wenn das owfs nutzt, dann ist es relativ einfach einen Sensor für mehrere Applikationen zu multiplexen.

Meine eigene Software hat übrigens fertigen Support für eine externe 7-segment Temperaturanzeige drin.

Gruss

Sven

[alexbrand]

S&B nutzt nicht das owfs. Ich habe da damals mit Thomas Brian Lanes Digitemp integriert. Letztlich sind aber alle Messmethoden und Sensoren erlaubt, die ein Logfile anlegen, das bestimmte Kriterien erfüllt. Es muß nämlich genau so aussehen, wie das Original. ;-)

Gruß

Alex

[emilio]

Ich bastel in meinem Programm an einer Dispalyschnittstelle welche alle Informationen auf einem Arduino Uno Display darstellt. In meiner letzten Version ist das Programm welches die Informationen über die USB-Schnittstelle zum Arduino überträgt bereits enthalten. Eigentlich funktioniert das auch schon.
Soll dann mal so aussehen...

[giggls]

S&B nutzt nicht das owfs. Ich habe da damals mit Thomas Brian Lanes Digitemp integriert. Letztlich sind aber alle Messmethoden und Sensoren erlaubt, die ein Logfile anlegen, das bestimmte Kriterien erfüllt. Es muß nämlich genau so aussehen, wie das Original. ;-)

OK, dann funktioniert das im Prinzip. Man lässt einen owserver als Multiplexer laufen, dann baut man sich zwei Programme:

• Einen digitemp simulator auf owfs basis in der Programmiersprache der Wahl
• Ein zweites Programm, das zyklisch die Temperatur vom owserver liest und auf der 7-Segmentanzeige ausgibt

Schön ist das aber nicht, was man eigentlich machen sollte ist owfs-support direkt in das S&B Programm einzubauen. Ist das eigentlich Open Source?

Gruss

Sven

[giggls]

Ich bastel in meinem Programm an einer Dispalyschnittstelle welche alle Informationen auf einem Arduino Uno Display darstellt.

Sieht dann doch recht ähnlich aus wie unsere Hardware :)

Bild hab ich mal angehängt. Ist aber auch nicht neu für dieses Forum. Unser Zeug läuft auf Raspberry Pi als client für Web 2.0 mash und steuert deshalb die Hardware direkt über GPIO an.

Gruss

Sven

[Borsti84]

Danke erstmal für eure Hilfe.
Also wird das nicht so einfach werden. Meinen Raspberry habe ich verkauft. Habe zwar mashit, web2mash usw. mit raspberry ausprobiert aber wie schonmal gesagt ist windows für meine Braukollegen immer noch am einfachsten zu bedienen.
Wenn Emilio natürlich dabei ist ein Display in sein Programm zu integrieren ist das naturlich echt spitze. Da würde ich dann doch noch etwas warten und dann damit durchstarten

Schönen 3. Advent wünsche ich euch!!!!

[giggls]

D
Also wird das nicht so einfach werden. Meinen Raspberry habe ich verkauft. Habe zwar mashit, web2mash usw. mit raspberry ausprobiert aber wie schonmal gesagt ist windows für meine Braukollegen immer noch am einfachsten zu bedienen.

Die ist aber schon klar, dass der reine Bediener bei Web 2.0 Mash überhaupt nicht merkt, dass da ein Linux drunter läuft? Du merkst ja auch bei Hobbybrauer.de nicht, dass da ein linux läuft oder?

Das ist hier wie da doch einfach nur eine Weboberfläche. Wie die aussieht siehst Du auf meiner Demo Webseite das ist 1:1 die selbe Software nur ohne echte Sensoren und Aktoren. Unser Maschinenbauer hat sich jedenfalls noch nicht über den Bedienkomfort beschwert ;)

Das Einzige wo Linuxkenntnisse natürlich helfen ist beim Einrichten des Programms, aber das ist ja nun nichts was man mehr als einmal machen muss.

Gruss

Sven

[rmax]

Hier noch ein Gedankenansatz, wie man das Problem lösen könnte:

Ein Mikrocontroller wird in die Leitung zwischen DS18B20 und PC-Interface eingeschleift. An einem Pin implementiert er einen 1-Wire-Master, der den DS18B20 in kurzen Abständen ausliest und die Temperatur auf dem Display darstellt. An einem anderen Pin implementiert er einen 1-Wire-Slave, der sich gegenüber dem PC wie ein DS18B20 verhält und jeweils das letzte Meßergebnis weitergibt.

Edit: Ich sehe gerade, das angestrebte Display ist selbst ein 1-Wire-Master. In dem Fall würde der Mikrocontroller einfach zwei Slaves zur Verfügung stellen, die jeweils den neuesten Meßwert weiterreichen.

[giggls]

Hier noch ein Gedankenansatz, wie man das Problem lösen könnte

OMG, das ist die denkbar komplizierteste Lösung überhaupt. Ich habe bereits einen Lösungsansatz mit owfs beschrieben

Gruss

Sven

[rmax]

OMG, das ist die denkbar komplizierteste Lösung überhaupt.

Als ich den ersten Teil geschrieben habe, hatte ich mir das "Display" noch nicht angeschaut und dachte, es wäre ohnehin ein Mikrocontroller nötig, um die Daten vom DS18B20 auf ein Standard-Display zu bekommen.

Ich habe bereits einen Lösungsansatz mit owfs beschrieben

Nein, beschrieben hast Du das nicht, nur umrissen. Kann denn owfs auch 1-Wire-Slave (und kann es die hier eingesetzte Interface-Hardware), so daß der PC über owfs die Sensorwerte an das Display weiterleiten kann?

Übrigens: Nachdem die Datenleitung bei 1-Wire ja mit Open Drain arbeitet, müßte es sogar möglich sein, zwei Master an einen Slave anzuschließen, vorausgesetzt die Master fragen nicht zu oft an und kommen mit gelegentlichen Kollisionen klar.

[giggls]

Kann denn owfs auch 1-Wire-Slave (und kann es die hier eingesetzte Interface-Hardware), so daß der PC über owfs die Sensorwerte an das Display weiterleiten kann?

Eine Slavefunktion ist mir nicht bekannt, aber die braucht man in diesem Fall auch nicht. Der owserver kann als Multiplexer für den 1-wire bus fungieren d.h. man kann einfach mit zwei Programmen abwechselnd den selben Sensor abfragen indem man über den owserver geht statt direkt auf den Bus.

Wenn man zudem die cachingfunktion von owfs nutzt wird der Sensor nicht mal physikalisch doppelt so oft angesprochen sondern es wird der Wert genommen, der bei der letzten Abfrage des Sensors ausgelesen wurde.

Ursprünglich wollte ich die 7-Segment Anzeige bei Web 2.0 Mash sogar genau so implementieren, habe mich dann aber dafür entschieden die Anzeige doch direkt über den mashctld zu machen und nur mit einem Programm auf den Bus zuzugreifen. Das hat bei mir den Vorteil, dass ich keinen owserver brauche sondern direkt ohne Multiplexer mit owfs auf den Bus zugreifen kann.

Zurück zum Problem des OP:

Man baut ein Programm, das den Temperaturwert über owfs liest und dann auf einem irgendwie am Rechner angeschlossenen Display als Zahl ausgibt. Wenn der Rechner ein PC ist, wie beim OP, hat man leider den Nachteil, dass es keine direkten GPIO oder I2C gibt und man wohl notgedrungen USB nehmen muss.

Ich hatte meine ursprüngliche Temperaturanzeige für ein Adafruit I2C 7-segment Display gebaut.
Das wäre z.B. das hier: http://www.adafruit.com/products/878

Beim Raspi halt einfacher als bei einem PC weil man da direkt I2C hat.

Den Code kann man superleicht auf dierekten owfs Zugriff umbauen. Wie gesagt momentan frage ich den Temperaturwert beim mashctld ab, weil der Ohnezhin schon mehrere gleichzeitig zugreifende clients unterstützt.

Gruss

Sven

[rmax]

Das ist aber keineswegs weniger kompliziert als mein Vorschlag, die Komplexität findet sich nur an anderer Stelle wieder. ;)

[giggls]

Das ist aber keineswegs weniger kompliziert als mein Vorschlag, die Komplexität findet sich nur an anderer Stelle wieder. ;)

Das wird natürlich immer ein wenig subjektiv sein. Komplex ist was man nicht kennt :)

Wenn man owfs noch nie benutzt hat braucht man dafür natürlich ein wenig Einarbeitungszeit.

Deine Lösung ist IMO nur dann vom Aufwand her überschaubar, wenn es die 1-wire Protokollstacks für client und server für den Microcontroller schon fertig gibt. Ich habe mir sagen lassen, dass das Protokoll ziemlich kompliziert ist.

Der Vorteil von owfs ist halt, dass es schon alles kann was man für den Buszugrif braucht und man keine 1-wire low-level Programmierung selbst machen muss. Die Unterstützung für alle möglichen Busmaster kriegt man quasi geschenkt.

BTW um auf die Frage nochmal zurückzukommen, die mir bisher noch niemand beantwortet hat. Ist S&B eigentlich Open Source? Wäre sicher die eleganteste Methode die Software direkt auf owfs umzustellen.

Sven

[rmax]

Wenn man owfs noch nie benutzt hat braucht man dafür natürlich ein wenig Einarbeitungszeit.

Ich sehe bei Deiner Variante die Komplexität nicht im owfs selbst, sondern in der Anbindung vom Display an den PC (Hard- und Software).

Deine Lösung ist IMO nur dann vom Aufwand her überschaubar, wenn es die 1-wire Protokollstacks für client und server für den Microcontroller schon fertig gibt.
Ich habe mir sagen lassen, dass das Protokoll ziemlich kompliziert ist.

Ich habe nochmal ein bißchen nachgelesen und festgestellt, daß es doch etwas zeitkritischer ist, als ich in Erinnerung hatte, aber es gibt z.B. für den AVR sowohl Master- als auch Slave-Implementierungen.

Der Vorteil von owfs ist halt, dass es schon alles kann was man für den Buszugrif braucht und man keine 1-wire low-level Programmierung selbst machen muss. Die Unterstützung für alle möglichen Busmaster kriegt man quasi geschenkt.

Klar, aber mangels Slave-Fähigkeiten von owfs hat man wie gesagt für den Weg vom PC zum Display mehr Aufwand.

Außerdem funktioniert die Temperaturanzeige bei mir auch dann, wenn der PC aus ist. ;)

[alexbrand]

Schön ist das aber nicht, was man eigentlich machen sollte ist owfs-support direkt in das S&B Programm einzubauen. Ist das eigentlich Open Source?

Nein, bislang ist es das wohl nicht. Aber einfach mal Thomas fragen...

Gruß

Alex

[giggls]

Klar, aber mangels Slave-Fähigkeiten von owfs hat man wie gesagt für den Weg vom PC zum Display mehr Aufwand.

Jo PC ist halt leider unflexibel was Hardwareansteuerung betrifft. Deshalb verwende ich ja auch einen Raspberry Pi.

Gruss

Sven

[giggls]

Nein, bislang ist es das wohl nicht. Aber einfach mal Thomas fragen...

Na ja wenn das offen wäre hätte ich vielleicht mal reingeschaut wie einfach das auf owfs portierbar ist aber mehr auch nicht.

Ich habe ja meine eigene Software die tut was ich brauche und fasse Windows ohnehin nur mit spitzen Fingern an.

Gruss

Sven

[emilio]

Ich hab gestern auch noch etwas gebastelt. Ich werden wohl auch eine Arduino Uno Lösung zusammenstellen. Die soll dann wahlweise die Relais schalten, mit NTC oder DS18B20 messen oder auch nur als Anzeigeteil für das Brauprogramm dienen. Das 4 Zeilige I²C-Bus-LCD-Display sieht klasse aus. Das werd ich mir auch mal besorgen. Auf 2x16 ist einfach zu wenig Platz. Am Rechner wäre dann nur noch der Arduino angeschlossen.

Grüße, Andreas

[giggls]

Das 4 Zeilige I²C-Bus-LCD-Display sieht klasse aus

Das ist in meinem Fall nicht über i2c angeschlossen sondern direkt an den GPIO des Raspberry Pi. Wobei ich das ehrlich gesagt inzwischen auch eher über i2c machen würde. Die GPIO Lösung ist zu EMV anflällig.

Meine Brausteuerung lässt sich komplett über das 4x20 Display bedienen, das ist keine reine An zeige.

Die Software kommuniziert analog zum Webbrowser per http mit dem daemon.

Sven