Kuschelig2.0: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 32: | Zeile 32: | ||
* Der Boost wird nicht wie erwartet alle 6 Minuten sondern eher im 10-Minuten-Takt ausgelöst. Es dauert also länger, bis die Zieltemperatur erreicht ist, wenn sie überhaupt erreicht werden kann. Keine Ahnung warum. In der crontab von root steht das <code>boostiftoocold</code>-Skript so drin, dass es alle 6 Minuten gestartet werden müsste. | * Der Boost wird nicht wie erwartet alle 6 Minuten sondern eher im 10-Minuten-Takt ausgelöst. Es dauert also länger, bis die Zieltemperatur erreicht ist, wenn sie überhaupt erreicht werden kann. Keine Ahnung warum. In der crontab von root steht das <code>boostiftoocold</code>-Skript so drin, dass es alle 6 Minuten gestartet werden müsste. | ||
Das Problem war das ein von /bin/therm-boost-fg angelegtes lockfile für 9 minuten existierte obwohl es eigentlich nur 5minuten 30 sekunden leben | |||
sollte. | |||
Das Problem müsste behoben sein ich habe es aber noch nicht getestet. | |||
* Der Bot fliegt noch regelmäßig aus dem MUC raus. Möglicherweise bekommt der Bot vom MUC eine Nachricht, die er nicht parsen kann (hab da eine Fehlermeldung in der screen-Session gesehen, die auf ein fehlendes Anführungszeichen hindeutet) und will dies als Fehlermeldung dem MUC berichten, welcher darauf den Bot rausschmeißt. | * Der Bot fliegt noch regelmäßig aus dem MUC raus. Möglicherweise bekommt der Bot vom MUC eine Nachricht, die er nicht parsen kann (hab da eine Fehlermeldung in der screen-Session gesehen, die auf ein fehlendes Anführungszeichen hindeutet) und will dies als Fehlermeldung dem MUC berichten, welcher darauf den Bot rausschmeißt. | ||
Ich denke der fehler müsste erstmal behoben sein ich habe in /lib/python3.4/site-packages/sleekxmpp/stanza/rootstanza.py die Zeilen 75-79 auskommentiert | |||
so das der bot keine Fehlermeldung mehr sendet wenn er eine Nachricht für ungültig hält. | |||
Eigentlich müsste es aber eine schönere Lösung für das Problem geben. | |||
* Bessere Fehlerbehandlung: Beispielsweise wird die Abschaltautomatik ohne irgendeine Art der Beschwerde ausgehebelt, wenn der Türstatus-Service nicht läuft. Wir müssten uns mal überlegen, wie wir solche Fehler sichtbar machen können. | * Bessere Fehlerbehandlung: Beispielsweise wird die Abschaltautomatik ohne irgendeine Art der Beschwerde ausgehebelt, wenn der Türstatus-Service nicht läuft. Wir müssten uns mal überlegen, wie wir solche Fehler sichtbar machen können. |
Version vom 10. November 2014, 23:17 Uhr
Kuschelig 2.0 soll die alte Heizungssteuerung ersetzen und auf einem Raspberry Pi laufen. Zur Ansteuerung der Thermostate und zum auslesen der Temperatursensoren werden Linux Kernelmodule für Onewire verwendet. Die Steuerung soll weiterhin mit einem Jabberbot möglich sein. Dieser soll aber direkt auf dem Raspberry Pi laufen und ist mit SleekXMPP in Python implementiert.
Heizungssteuerung
Die Heizung kann über den Jabber bot mit der Jabber ID bot@paws.de oder alternativ aus dem MUC gesteuert werden. Die für die Heizungssteuerung relevanten befehle sind !kuschelig und !status.
Kuschelig nimmt eine Gleitkommazahl zwischen 8 und 24 als Argument und setzt diesen Wert (in °C) als Zielwert für die Heizungssteuerung ein. Status gibt die aktuelle Temperatur im Space und die eingestellte Zieltemperatur zurück. Momentan ist keine Authentifizieren nötig um die Heizung zu steuern das wird sich aber in Zukunft vielleicht ändern.
Solange die Raumtemperatur geringer als die Zieltemperatur ist wird die Heizung in 6 Minuten Intervallen für 5 Minuten voll aufgedreht. Die Raumtemperatur wird an dem Temperatursensor gemessen der über dem Tisch von der decke hängt.
Wenn die Tür vom Noklab abgeschlossen wird (nicht wenn sie bereits abgeschlossen ist) wird die Zieltemperatur auf 14°C gesetzt. Dies erfordert allerdings, dass auf der entsprechende Türstatus-Abfrage Service auf brickme läuft. Fällt der aus, wird der Space immer als geschlossen interpretiert, was die automatische Abschaltung beim Übergang von offen nach geschlossen aushebelt.
Elektronik
Die Heizung wird von einem Raspberry-Pi über Onewire gesteuert dabei werden die Sensoren und das Thermostat verwendet die schon bei Kuschelig zum Einsatz kamen. Sowohl das Thermostat und die Sensoren als auch der Raspberry-Pi werden über die 5-Volt und Masse Leitung der Onewire-Verbindung mit Strom versorgt.
Software
Türstatus-, Sensorabfrage und -Logging sowie die Auslösung der Boost-Funktion des Heizungsventils geschieht über die Skripte /bin/boostiftoocold
, /bin/therm*
auf pyro, die über die crontab vom Benutzer root regelmäßig gestartet werden. Auf pyro läuft auch der XMPP-Bot unter der User ID nokbot
. Der Bot wird aktuell manuell in einer screen
-Session über das im Heimverzeichnis von nokbot
liegende start.sh
-Skript gestartet.
TODO
- Der Boost wird nicht wie erwartet alle 6 Minuten sondern eher im 10-Minuten-Takt ausgelöst. Es dauert also länger, bis die Zieltemperatur erreicht ist, wenn sie überhaupt erreicht werden kann. Keine Ahnung warum. In der crontab von root steht das
boostiftoocold
-Skript so drin, dass es alle 6 Minuten gestartet werden müsste.
Das Problem war das ein von /bin/therm-boost-fg angelegtes lockfile für 9 minuten existierte obwohl es eigentlich nur 5minuten 30 sekunden leben sollte. Das Problem müsste behoben sein ich habe es aber noch nicht getestet.
- Der Bot fliegt noch regelmäßig aus dem MUC raus. Möglicherweise bekommt der Bot vom MUC eine Nachricht, die er nicht parsen kann (hab da eine Fehlermeldung in der screen-Session gesehen, die auf ein fehlendes Anführungszeichen hindeutet) und will dies als Fehlermeldung dem MUC berichten, welcher darauf den Bot rausschmeißt.
Ich denke der fehler müsste erstmal behoben sein ich habe in /lib/python3.4/site-packages/sleekxmpp/stanza/rootstanza.py die Zeilen 75-79 auskommentiert so das der bot keine Fehlermeldung mehr sendet wenn er eine Nachricht für ungültig hält. Eigentlich müsste es aber eine schönere Lösung für das Problem geben.
- Bessere Fehlerbehandlung: Beispielsweise wird die Abschaltautomatik ohne irgendeine Art der Beschwerde ausgehebelt, wenn der Türstatus-Service nicht läuft. Wir müssten uns mal überlegen, wie wir solche Fehler sichtbar machen können.