@ schneiderre
Ich spiele auch ab und zu (wenn auch unter völlig anderen Rahmenbedingungen) mit einer Heizmatte rum. Dabei ist mir mal unbemerkt ein Relais kaputt gegangen und "plötzlich" war meine Heizplatte über 120°C warm, Tendenz steigend...
Damit will ich auch nur sagen, dass noch schlimmere Sachen passieren können, als dass sie nur nicht mehr heizt...
Temperatursteuerung
@Melewo: Ergänzend: Der Code ist nicht nur keine Hysterese sondern auch überkompliziert und funktioniert analog zu:
Kompakt und richtig wäre:
Code: Alles auswählen
def update(self, temp_heizmatte):
return temp_heizmatte <= self.temp_heizmatte_min
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
@kbr: Ist beides nicht richtig. Es geht ja darum, dass die weniger oft anspringt und weniger oft schaltet. Und somit bei 3 bei 26 bis 29 Grad weiterläuft, falls gerade am Laufen und aus bleibt, falls nicht gerade am Laufen. Nur soweit habe ich heute Morgen noch nicht gedacht. Der aktuelle Stand, ob am Laufen oder nicht, müsste somit mit verglichen werden.
Ich behaupte jetzt einfach mal, dass das Programm von kbr genau das machtMelewo hat geschrieben:@kbr: Ist beides nicht richtig. Es geht ja darum, dass die weniger oft anspringt und weniger oft schaltet. Und somit bei 3 bei 26 bis 29 Grad weiterläuft, falls gerade am Laufen und aus bleibt, falls nicht gerade am Laufen. Nur soweit habe ich heute Morgen noch nicht gedacht.
Ich denke eher das von DeaD_EyE. Zumindest findet bei kbr keine Prüfung statt, ob die Heizung gerade läuft oder nicht und der aktuelle Stand müsste ja zwischengespeichert werden.Zizibee hat geschrieben:Ich behaupte jetzt einfach mal, dass das Programm von kbr genau das macht
Zuletzt geändert von Melewo am Mittwoch 26. Juli 2017, 10:35, insgesamt 1-mal geändert.
Es wird nur die Temperatur verglichen, nicht ob die Heizung läuft oder nicht.Zizibee hat geschrieben:Melewo hat geschrieben:Wo liegt der Unterschied zwischen den Programmen von DeaD_EyE und kbr? Machen die nicht das gleiche?
Habe jetzt nicht alle Varianten durchgespielt, eigentlich nur eine probiert, doch so könnte ich mir das eher vom Prinzip vorstellen.
Code: Alles auswählen
class Hysterese:
def __init__(self, temp_heizmatte_min, temp_heizmatte_max):
self.state = False
self.temp_heizmatte_min = temp_heizmatte_min
self.temp_heizmatte_max = temp_heizmatte_max
def update(self, temp_heizmatte, status):
# 24 25
if temp_heizmatte <= self.temp_heizmatte_min:
self.state = True
return self.state
# 31 30
elif temp_heizmatte >= self.temp_heizmatte_max:
self.state = False
return self.state
# 25 von 26 bis 29 30
elif self.temp_heizmatte_min < temp_heizmatte < self.temp_heizmatte_max:
if status is "on":
self.state = True
elif status is "off":
self.state = False
return self.state
status = "on"
# status = "off"
hyst = Hysterese(25, 30)
print(hyst.update(27, status)) # False bei 27 und "off" | # True bei 27 und "on"
@Melewo: Die Heizung weiss ja selber ob sie läuft oder nicht beziehungsweise das ist `state`. Deins wird immer komplizierter — unnötig. Zumal Du jetzt auch noch mit globalen Variablen anfängst. Was genau funktioniert denn an kbr's letzter Lösung nicht?
Oh, und Deins hat einen Riesenfehler: ``is``. Das ist nicht das selbe wie ``==``.
Oh, und Deins hat einen Riesenfehler: ``is``. Das ist nicht das selbe wie ``==``.
Code: Alles auswählen
In [13]: a == b
Out[13]: True
In [14]: a is b
Out[14]: False
In [15]: a
Out[15]: 'böse Falle'
In [16]: b
Out[16]: 'böse Falle'
@Melewo: Die Information, ob die Heizung laufen soll oder nicht, steckt in der Instance-Variablen 'state'. Der ursprüngliche, und von mir übernommene, Methoden-Name 'update' ist irreführend und sollte besser in etwas wie 'should_heat' umbenannt werden, was mit dem boolschen Rückgabewert sinnvoll in Beziehung gebracht werden kann.
Genau ob sie laufen soll oder nicht, ist für mich auch in state, so sehe ich das auch. Doch ob sie gerade läuft oder nicht, ist doch nicht in state, sondern in der Datenbank als letzter Wert oder soll abgefragt werden und das sollte zwischen 26 und 29 berücksichtigt werden.
Bei 27 Grad, Heizung läuft, dann laufe weiter.
Bei 27 Grad, Heizung läuft nicht, dann bleibe aus.
Was kommt da sonst aus der DB?schneiderre hat geschrieben:Die Werte kommen aus einer DB.
Bei 27 Grad, Heizung läuft, dann laufe weiter.
Bei 27 Grad, Heizung läuft nicht, dann bleibe aus.
@Melewo: Aus der Datenbank kommen die Werte wann geschaltet werden sollte.
Noch mal: Ob sie gerade läuft weiss die Heizung selbst und das ist völlig egal, weil das zur Entscheidung nicht benötigt wird. Noch mal: Was an kbr's Lösung funktioniert denn Deiner Meinung nach nicht? Gib mal einen Beispielverlauf der nicht das macht was er soll!
Noch mal: Ob sie gerade läuft weiss die Heizung selbst und das ist völlig egal, weil das zur Entscheidung nicht benötigt wird. Noch mal: Was an kbr's Lösung funktioniert denn Deiner Meinung nach nicht? Gib mal einen Beispielverlauf der nicht das macht was er soll!
@ Melewo: Da "state" nicht vom Threadersteller sondern von DeaD_EyE eingeführt wurde, ist es wenig wahrscheinlich, dass sie in der ursprünglichen Datenbank auftaucht...
Mal eine Frage, die etwas OT ist:
Sehe ich das anhand der Beispiele richtig, das einfache get- und set- Methoden in Python nicht benutzt werden, da sie schlicht nicht gebraucht werden, da die Objektvariablen nicht privat sind?
Mal eine Frage, die etwas OT ist:
Sehe ich das anhand der Beispiele richtig, das einfache get- und set- Methoden in Python nicht benutzt werden, da sie schlicht nicht gebraucht werden, da die Objektvariablen nicht privat sind?
@Melewo: Mehr als einen Rechner und Python brauchst Du nicht um das auszuprobieren. Der Zustand der Heizung ist immer der von `state`, denn nach `state` richtet sich ja der Pin für den Schalter — der hat immer den gleichen Wert, also reicht die Klasse alleine zum Testen völlig aus.
- 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: 1012
- 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.