Temperatursteuerung
- Sr4l
- User
- Beiträge: 1091
- Registriert: Donnerstag 28. Dezember 2006, 20:02
- Wohnort: Kassel
- Kontaktdaten:
Ich möchte hier auch nochmal meinen Senf dazugeben, auch wenn ich nicht weiß ob der TE mittlerweile aufgegeben hat .
Das was du machst nennt sich "Zweipunktregler" und ist absolut üblich bei allem was mit Temperatur zutun hat.
Ich habe zwei "Raspberry PI 1"s im Dauereinsatz. Der eine ist nach ~2Jahre Betrieb immer mal wieder ausgefallen, Übertakten von "Modest" auf "None", hat das Problem gelöst. Ein Netzteil ist mir in den 3 Jahren kaputt gegangen. Und der Andere hat diesen Sommer immer wieder mal ein Temperatur Schock bekommen, behoben durch bessere Luftzufuhr und Kühlkörper. Also es ist alles recht stabil, aber es passiert gelegentlich auch mal etwas.
Ich würde für alle Regelungsaufgaben einen Mikrocontroller einsetzen. Und wenn bei der ganzen Sache auch noch Strom im Spiel ist der mir die Bude abfackeln kann, einen zweiten der nur Überwacht und der sollte dann einen Alarm erzeugen können und z.B alles Stromlos schalten.
Das ganze sollte dann auch nicht nur theoretisch funktionieren sondern getestet werden.
PS: Ich hatte es schon häufiger das sich Schalter oder Relais "fest gebacken" haben und obwohl Stromlos oder Geschaltet nicht mehr gelöst haben. An so etwas sollte man denken, wenn man etwas unüberwacht arbeiten lässt.
Das was du machst nennt sich "Zweipunktregler" und ist absolut üblich bei allem was mit Temperatur zutun hat.
Ich habe zwei "Raspberry PI 1"s im Dauereinsatz. Der eine ist nach ~2Jahre Betrieb immer mal wieder ausgefallen, Übertakten von "Modest" auf "None", hat das Problem gelöst. Ein Netzteil ist mir in den 3 Jahren kaputt gegangen. Und der Andere hat diesen Sommer immer wieder mal ein Temperatur Schock bekommen, behoben durch bessere Luftzufuhr und Kühlkörper. Also es ist alles recht stabil, aber es passiert gelegentlich auch mal etwas.
Ich würde für alle Regelungsaufgaben einen Mikrocontroller einsetzen. Und wenn bei der ganzen Sache auch noch Strom im Spiel ist der mir die Bude abfackeln kann, einen zweiten der nur Überwacht und der sollte dann einen Alarm erzeugen können und z.B alles Stromlos schalten.
Das ganze sollte dann auch nicht nur theoretisch funktionieren sondern getestet werden.
PS: Ich hatte es schon häufiger das sich Schalter oder Relais "fest gebacken" haben und obwohl Stromlos oder Geschaltet nicht mehr gelöst haben. An so etwas sollte man denken, wenn man etwas unüberwacht arbeiten lässt.
- DeaD_EyE
- User
- Beiträge: 1017
- Registriert: Sonntag 19. September 2010, 13:45
- Wohnort: Hagen
- Kontaktdaten:
Das liebe ich so. Man nimmt bestehenden Code, verbessert ihn um am Ende kommt etwas elegantes bei raus.kbr hat geschrieben: Kompakt und richtig wäre:
Code: Alles auswählen
def update(self, temp_heizmatte): if temp_heizmatte <= self.temp_heizmatte_min: self.state = True elif temp_heizmatte >= self.temp_heizmatte_max: self.state = False return self.state
Wenn keine der beiden Bedingungen erfüllt ist, wird einfach nur der letzte Status zurückgegeben, ohne die Variable vorher zu setzen.
Wenn eine der beiden Bedingungen erfüllt ist, wird die Variable gesetzt.
Ausgegeben wird der Status immer.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
@Zizibee: Triviale Getter und Setter machen ein Attribut ja letztlich public, auch wenn das eigentliche Attribut private wäre. Man benutzt diese Methoden in Python nicht weil man jederzeit `property()`\s aus den Attributen machen kann. Was zum Beispiel in Java nicht geht. Da müsste man dann jeden Zugriff ändern wenn man nicht über Accessor-Methoden gegangen ist. In Python ändert sich die API dagegen nicht durch so eine Änderung also sind triviale Getter/Setter einfach nur unnötige Schreibarbeit.
@Zizibee: Mal als (leicht konstruiertes) Beispiel eine abstrakte Basisklasse welche die `update()`-Methode bereit stellt und eine Bereitstellung von Unter- und Obergrenze von abgeleiteten Klassen erwartet, und zwei Varianten dies zu tun in Java, wo man die Getter benötigt, und zum Vergleich in Python wo man direkt auf die Attribute zugreifen kann oder Properties zur Verfügung stellt:
Code: Alles auswählen
abstract public class AbstractHysteresis {
private boolean state = false;
abstract public double getLow();
abstract public double getHigh();
public boolean update(double value) {
if (value <= getLow()) {
state = true;
} else if (value > getHigh()) {
state = false;
}
return state;
}
}
public class Hystersis extends AbstractHysteresis {
private final double low;
private final double high;
public Hystersis(double low, double high) {
this.low = low;
this.high = high;
}
@Override
public double getLow() {
return low;
}
@Override
public double getHigh() {
return high;
}
}
public class Hysteresis2 extends AbstractHysteresis {
private final double value;
private final double margin;
public Hysteresis2(double value, double margin) {
this.value = value;
this.margin = margin;
}
@Override
public double getLow() {
return value - margin;
}
@Override
public double getHigh() {
return value + margin;
}
}
Code: Alles auswählen
class BaseHysteresis(object):
def __init__(self):
self.state = False
def update(self, value):
if value <= self.low:
self.state = True
elif value > self.high:
self.state = False
return self.state
class Hysteresis(BaseHysteresis):
def __init__(self, low, high):
BaseHysteresis.__init__(self)
self.low = low
self.high = high
class Hysteresis2(BaseHysteresis):
def __init__(self, value, margin):
BaseHysteresis.__init__(self)
self.value = value
self.margin = margin
@property
def low(self):
return self.value - self.margin
@property
def high(self):
return self.value + self.margin
Dazu hätte ich jetzt zwei Fragen:
Ist es ein Unterschied, ob man
oder
schreibt?
Warum ist welche Schreibweise vorzuziehen?
Ich habe mich auf python-kurs.eu über property() informiert und da wird das irgendwie anders benutzt. Sind die Zeilen 29 - 31 von der Arbeitsweise so ähnlich wie das hier
nur etwas kürzer?
Ist es ein Unterschied, ob man
Code: Alles auswählen
class BaseHysteresis(object):
Code: Alles auswählen
class BaseHysteresis:
Warum ist welche Schreibweise vorzuziehen?
Ich habe mich auf python-kurs.eu über property() informiert und da wird das irgendwie anders benutzt. Sind die Zeilen 29 - 31 von der Arbeitsweise so ähnlich wie das hier
Code: Alles auswählen
def __get_low(self):
return self.value - self.margin
low = property(__get_low)
@Zizibee: In Python 2 muss man von `object` erben damit unter anderem Properties richtig funktionieren, weil man ohne von `object` abzuleiten eine „old style class“ bekommt. In Python 3 gibt es nur noch „new style classes“.
Der verlinkte Kurs kennt auch private Attribute (die es in Python so nicht gibt) und missbraucht das „name mangling“ bei zwei führenden Unterstrichen dazu. Und verwendet auch nicht die Python-Namenskonvention. Das sieht alles sehr nach Java oder C++ aus. Und durch die trivialen Getter/Setter ist das Attribut de fakto dann doch öffentlich, also ist das insgesamt viel unnötige Schreibarbeit. Wenigstens das sagt der Kurs, aber erst nach dem dieser ganze unnötige Zirkus präsentiert wird.
Die Schreibweise als Decorator mit @ ist seit Python 2.4, also seit 2004 = 13 Jahren, möglich. Ich würde das auch nicht mehr anders schreiben wollen.
Decorator sind eigentlich nur syntaktischer Zucker. Das hier:
ist äquivalent zu dem hier:
Und es geht nicht unbedingt um kürzer sondern eher um die Reihenfolge in der man das liest. Wenn der Funktionskörper von `spam()` zig Zeilen lang ist, sieht man erst viel später das `spam` noch mal umdefiniert wird, während man mit der Decorator-Syntax gleich ganz am Anfang sieht, das mit der Funktion danach noch etwas gemacht wird und das Ergebnis davon wieder an den Namen `spam` gebunden wird.
Der verlinkte Kurs kennt auch private Attribute (die es in Python so nicht gibt) und missbraucht das „name mangling“ bei zwei führenden Unterstrichen dazu. Und verwendet auch nicht die Python-Namenskonvention. Das sieht alles sehr nach Java oder C++ aus. Und durch die trivialen Getter/Setter ist das Attribut de fakto dann doch öffentlich, also ist das insgesamt viel unnötige Schreibarbeit. Wenigstens das sagt der Kurs, aber erst nach dem dieser ganze unnötige Zirkus präsentiert wird.
Die Schreibweise als Decorator mit @ ist seit Python 2.4, also seit 2004 = 13 Jahren, möglich. Ich würde das auch nicht mehr anders schreiben wollen.
Decorator sind eigentlich nur syntaktischer Zucker. Das hier:
Code: Alles auswählen
@(some_expression)
def spam():
pass
Code: Alles auswählen
def spam():
pass
spam = (some_expression)(spam)
-
- User
- Beiträge: 11
- Registriert: Montag 1. Mai 2017, 20:40
Hallo @all, sorry das ich mich jetzt erst melde, hatte ziemlich viel um die Ohren. Erst einmal herzlichen Danke für eure Unterstützung und die rege Diskussion zu meiner Frage. Ich habe bis gestern Abend bis spät in die Nacht eure Vorschläge getestet. Zum Schluss hatte ich dann eine Kombination aus dem Vorschlag von Melewo und DeaD_EyE. Damit läuft es so wie ich es mir vorgestellt hatte. Vielen Dank dafür. Ich habe es heut den ganzen Tag laufen lassen und die Ergebnisse in ein Log schreiben lassen. Alles bestens. Auf euch ist eben verlass. Ich werde es jetzt noch ein wenig anpassen um die Ergebnisse in die DB zu bekommen und dann ist alles super.
Schönen Abend an @all
Schönen Abend an @all