Heizungssteuerung: Daten auslesen

Zitat von S:oren

Vielleicht ist der Dateiname fuer das udev-Rules-File nicht so gluecklich gewaehlt. Mit SuSe kenne ich mich nicht so aus, in Debian haette ich aber statt /etc/udev/eclo-1wire lieber /etc/udev/rules.d/99-eclo-1wire genommen.

Zitat von seahawk1986

Bei den neuen udev-Versionen sogar am besten mit einer .rules Dateiendung.
/etc/udev/rules.d/99-eclo-1wire.rules

Die Rules-Datei heißt /etc/udev/rules.d/46-eclo-1wire.rules. Die Datei /etc/udev/eclo-1wire ist das Script, das ich gerne beim Ein- uns Abstecken des Dongles ausführen möchte.

Klaus

Zitat von e9hack

Ich hab mal zwei Regeln für einen FTDI Chip definiert:

Code

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", RUN+="/bin/logger Dongle eingesteckt"
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", RUN+="/bin/logger Dongle abgesteckt"

Wenn ich ATTRS für add verwende, bekomme ich zwei Einträge im Log. Für die remove Regel kann man ATTR nicht verwenden, da die Einträge nicht mehr existieren. Man kann sich aber mit den Environment Variablen helfen.

Danke! Super! Damit klappt jetzt die Log-Ausgabe in beiden Fällen :-).

Jetzt möchte ich gerne anstatt des "logger"-Aufrufs mein eigenes Script aufrufen und diesem den aktuellen Namen des Devices (z.B. /dev/ttyUSB0) mitgeben (zumindest beim "add", denn beim "remove" brauche ich ja nur das owfs zu löschen).
Was müsste ich denn da für einen Platzhalter verwenden?
Ich habe mal '%p' probiert, aber da kommt "/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2".
Bei '$name' kommt "bus/usb/001/049" und bei '%N` kommt "/dev/bus/usb/001/051".
Ich bräuchte aber "/dev/ttyUSB0". Gibt es dafür auch einen Parameter, oder kommt man da sonst irgendwie ran?

Klaus

Zitat von jlp

Das ist aber eine sportliche Aussage deines Monteurs!

Tja, mich hatte es auch gewundert - aber widersprich da als Laie mal dem Fachmann ,-).

Zitat

Damit wäre deine Anlage ja rein Aussentemperatur gesteuert und kann Fremdwärmegewinne innerhalb des Hauses nicht erfassen. Diese entstehen, vor allem in den Übergangsmonaten durch Sonneneinstrahlung in die Wohnräume und sollten von der Heizungsregelung berücksichtigt werden. Warum soll die Anlage eine dann, viel zu hohe Vorlauftemperatur vorhalten, wenn diese durch den Bedarf einer, durch Sonne aufgeheizten Wohnung, gar nicht benötigt wird?

Da gebe ich dir vollkommen Recht.

Zitat

Die ideale Regelung, bezüglich Effizienz, hält immer nur die Temperatur im Heizsystem vor, welche vom Gebäude gerade benötigt wird, um die Wärmeverluste des Hauses auszugleichen. Wenn die gewünschte Innentemperatur erreicht ist, sollte die Anlage keine Wärme mehr nachschieben und sich sogar selbst ausschalten. Ohne Informationen über die Innentemperatur funktioniert das nicht.
Um den Brennwertnutzen zu maximieren gilt, je niedriger die Vorlauftemperatur, desto mehr Kondensation im Abgas, desto mehr Brennwertnutzen, desto mehr Spar ;-))

Die Räume sollten nicht über die Thermostatventile an den Heizkörpern geregelt werden. Im Idealfall stehen diese immer offen, und schließen nur bei spezifischer Übertemperatur des jeweiligen Raumes durch Fremdwärme (z.B Kamin, viele Menschen zu Besuch oder Kochen/Backofen in der Küche). Die Thermostate an den Heizkörpern sollen nicht eine allegemein zu hohe Vorlauftemperatur wegregeln, diese muss durch die Heizkurve passend zum Haus und durch die, durch die Regelung gemessene Innenraumtemperatur, eingestellt werden.

Wobei da ja aber doch immer nur die Temperatur *eines* Raumes gemessen wird (war zumindest bei meiner alten Heizung so). Wenn das dann das sonnendurchflutete Wohnzimmer ist und die Heizung deswegen die Vorlauftemperatur runterfährt, dann kann es im Badezimmer doch ziemlich "schattig" werden, oder?

Zitat

Hast Du einen Brauchwasserspeicher? Wie groß ist der?

Der hat 300 Liter.

Zitat

Die Speicherladung ist immer ineffektiv, da hier der Brenner eine hohe Übertemperatur erzeugen muss, zumeist 20K über der gewünschten Warmwassertemperatur. Hier gilt, so oft wie nötig aber so selten wie möglich. Anhand Deiner Grafik, lädst Du Deinen Speicher mehrmals am Tag. Möglicherweise könntest Du hier durch Programmierung von Ladezeiten, entsprechend eurer Nutzung und der Vergrößerung der Hysterese (jetzt anhand der Grafik scheinbar 5K, also unter 45 Grad wird nach geheizt), die Speicherladung optimieren. Oft reicht es, eine ausreichende Dimensionierung des Speichers vorausgesetzt, den Speicher nur einmal am Tag, vor Heizbeginn, aufladen zu lassen.

Unter anderem um solche Dinge zu optimieren möchte ich ja die Daten aufzeichnen. Da werde ich sicher noch einige Einstellungen vornehmen müssen. Im Moment möchte ich erstmal die Aufzeichnung sauber hinbekommen, insbesondere so, daß z.B. auch das owfs bei einem Rechner-Neustart oder dem Ab- und Einstecken des Dongles automatisch angelegt bzw. entfernt wird.

Klaus

Zitat von 3PO

So?

Code

SUBSYSTEMS=="usb", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", SYMLINK+="my-dongle", KERNEL=="ttyUSB[0123456789]", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", RUN+="/foo/bar/dongle_plug.sh"
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", RUN+="/foo/bar/dongle_unplug.sh"

Klappt prima!
Recht vielen Dank (auch an alle anderen, die mitgeholfen haben).

Klaus

Zitat von 3PO

Jetzt gibt es nur noch ein kleines Problem:

Die o.g. udev Regel wird bei jedem FTDI Device anspringen.

Mit etwas Glück ist Bei dem Dongle eine "iSerial" vergeben, die man in die udev Regel mit aufnehmen kann.

Code

lsusb -vvv |grep iSerial

Alles anzeigen

Ja, hat er: 04000080.

Ist aber kein wirkliches Problem, da ich eh nur *einen* solchen Dongle anschließen werde.
Aber trotzdem danke für den Hinweis.

Ein größeres Problem ist wohl der Symlink. Anscheinend wird der erst angelegt, *nachdem* mein Script aufgerufen worden ist.
Mit folgendem Script /etc/udev/eclo-1wire

#! /bin/sh
DEVICE=/dev/eclo-1wire
MOUNTPOINT=/tmp/eclo-1wire
case $1 in
     add) logger mounting $DEVICE at $MOUNTPOINT
          ls -l /dev | grep ttyU | logger
          mkdir -p $MOUNTPOINT
          /opt/owfs/bin/owfs -d $DEVICE -m $MOUNTPOINT > /tmp/owfs.log 2>&1
          ;;
     rem) logger unmounting $MOUNTPOINT
          /usr/bin/fusermount -u $MOUNTPOINT
          ;;
     *) echo invalid option!
        ;;
     esac

und dem Rule-File /etc/udev/rules.d/46-eclo-1wire.rules

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", SYMLINK+="eclo-1wire", KERNEL=="ttyUSB[0123456789]", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="ea90", RUN+="/etc/udev/eclo-1wire add"
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="ea90", RUN+="/etc/udev/eclo-1wire rem"

klappt es beim Einstecken des Dongles nicht. Rufe ich es aber danach von der Kommandozeile aus auf, funktioniert es.
Die Zeile "ls -l /dev | grep ttyU | logger" zeigt, daß zu diesem Zeitpunkt zwar /dev/ttyUSB0 da ist, aber /dev/eclo-1wire gibt es noch nicht (da müsste "eclo-1wire -> ttyUSB0" kommen).
Ändere ich das DEVICE nach /dev/ttyUSB0 kappt alles wunderbar. Es liegt also daran, daß der Link zu spät angelegt wird. Auch ein "sleep 5" vor dem owfs-Aufruf bringt nichts (hätte ja sein können, daß es einfach zu schnell geht).
Ich kann natürlich fest /dev/ttyUSB0 nehmen, aber die Lösung mit dem Symlink wäre halt schon schöner, weil allgemeingültig...

Klaus

Zitat von Dirk

mag ne Dumme Idee sein, aber wie wäre es mit einem

Code

sleep 1

am Anfang des Scripts?

Ich hatte zwar schon ein "sleep 5" unmittelbar vor dem owfs-Aufruf probiert, habe aber jetzt auch nochmal mit "sleep 1" ganz am Anfang getestet. Wie ich fast schon erwartet habe, macht das keinen Unterschied.

Klaus

Zitat von 3PO

kls,

damit sollte Dein Script funktionieren:

Code

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="ea90",SYMLINK+="eclo-1wire", RUN+="/etc/udev/eclo-1wire add"
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="ea90", RUN+="/etc/udev/eclo-1wire rem"

Tut es leider nicht. Auch damit ist, wenn das Script läuft, nur /dev/ttyUSB0 vorhanden.
Der Symlink entsteht damit überhaupt nicht mehr.

Klaus

Zitat von seahawk1986

Laut http://www.reactivated.net/wri…v_rules.html#external-run blockiert der Aufruf des Programms die weiteren Aktionen von udev - ändert sich was, wenn man den Programmaufruf mittels angehängtem "&" direkt in den Hintergrund schickt?

Ändert leider auch nichts.
Ich habe die add-Zeile nach

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="ea90", RUN+="/etc/udev/eclo-1wire add &"

geändert und im Script am Anfang ein "sleep 5" eingebaut. Wenn ich dann während das Script wartet immer wieder
"ls -l /dev | grep ttyU" mache, sehe ich folgendes:

root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
crw-------  1 root root    188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
lrwxrwxrwx  1 root root           7 Aug  6 10:36 eclo-1wire -> ttyUSB0
crw-rw-rw-  1 root dialout 188,   0 Aug  6 10:36 ttyUSB0
root@falcon:/etc/udev > ls -l /dev | grep ttyU
lrwxrwxrwx  1 root root           7 Aug  6 10:36 eclo-1wire -> ttyUSB0
crw-rw-rw-  1 root dialout 188,   0 Aug  6 10:36 ttyUSB0

Es wird also immer noch auf die Beendigung des Scripts gewartet.
Ich habe dann mal im Script

logger mounting $DEVICE at $MOUNTPOINT "$2"

gemacht und siehe da, es schreibt

Aug  6 10:37:37 falcon logger: mounting /dev/ttyUSB0 at /tmp/eclo-1wire &

ins Log. Das '&' in der udev-Rule greift also gar nicht, sondern wird als Parameter übergeben.

Ich bin dann mal hergegangen und habe im Script

(sleep 1; ls -l /dev | grep ttyU | logger) &

zu machen, und siehe da: damit geht es :-).

Vielen Dank für den Tipp mit dem '&'.

Klaus

Zitat von 3PO

So sollte es gehen, ohne "sleep" und "&".

Code

ACTION=="add", SUBSYSTEM=="usb", ATTRS{serial}=="04000080", SYMLINK+="eclo-1wire", RUN+="/etc/udev/eclo-1wire add"
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="ea90", RUN+="/etc/udev/eclo-1wire rem"

Sorry, leider kein Erfolg damit.
Mit dem "sleep 1" im Script kann ich durchaus leben, das ist kein Problem mehr.

Klaus

Zitat von Mreimer

Und um den Bogen zum VDR zurück zu spannen: Wie wäre es denn wenn der VDR in seiner "commands.conf", "reccmds.conf" und eventuell auch beim "--record" parameter ein "&" am Ende interpretieren würde? Du stolperst nämlich gerade über ein Problem, über welches Scriptprogrammierer im VDR-Umfeld regelmäßig stolpern. Das Verhalten vom VDR, auf Scripte zu warten, ist nur in ganz wenigen Fällen wirklich erwünscht. Das hat dann in der Vergangenheit zu unschönen Konstrukten der Form "echo blah | at now" geführt.

Halte ich mal fest.

Klaus