Heizungssteuerung: Daten auslesen

  • Ich hatte ATD hier kurz geantwortet, weil er sich viel Mühe gemacht hatte mit der Antennenwinkelberechnung und ich noch einige Tage brauchen würde, bis ich mir das näher anschauen kann. Dabei hatte ich erwähnt, daß ich momentan daran arbeite, die Netzwerkschnittstelle meiner neuen Heizungsanlage zu hacken, um die Daten mitschreiben zu können. Die darauf erfolgten Antworten von Idefix6 und domml wurden (freilich zu Recht) von Copperhead und ATD im dortigen Thread als off-topic bemängelt. Da ich die Hilfsangebote aber nicht einfach so ins Leere laufen lassen möchte, hier noch ein kurzer Nachtrag:


    Es handelt sich um einen "paradigma" Heizungsregler (Gasbrennwertkessel "Modula NT") mit "SystaComfort II" Steuerung. Diese schickt ihre Werte einmal pro Minute an den Server paradigma.remoteportal.de. Von dort kann man sich, soweit ich das verstanden habe, eine Auswertung der Daten über das Web holen und sich auch per Email benachrichtigen lassen, wenn eine Störung vorliegt. Allerdings muß man sich dafür dort erst anmelden und es kostet auch noch. Das mag für den "normalen" Benutzer ja ein netter Service sein, für mich ist es aber ein Unding, die Daten *meiner* Heizung erst irgendwo in die Welt zu schicken und dann auch noch dafür zu bezahlen, daß ich sie wieder bekomme ;-). Ich habe daher das (relativ simple) Protokoll nachgebildet und empfange die Daten nun selber, direkt auf meinem Server im Keller. Ich verstehe zwar nicht alle der 255 Werte, die da übertragen werden, aber zumindest alle interessanten Temperaturen und Relais-Stati. Mittels eines kleinen Perl-Scripts kann ich jetzt ein Diagramm wie im Anhang erzeugen. Die Innentemperatur messe ich mit einem "one-wire"-Fühler, da die Heizungssteuerung selber keinen Raumtemperaturfühler hat (haben die laut Aussage des Monteurs heute alle nicht mehr).


    Falls jemand auch so eine Steuerung hat und an dem Script interessiert ist, kann er sich ja bei mir melden.


    Klaus

  • Vielleicht kann mir (als totalem udev-Laien ;) hier jemand mit einem udev-Problem helfen.
    Wenn ich den "one-wire"-USB-Dongle einstecke, dann würde ich gerne über udev ein bestimmtes Script ausführen lassen, über das die Zugriffsrechte auf das entstehende /dev/ttyUSB0 passend gesetzt werden und mittels "owfs" ein Filesystem angelegt wird, über das die Werte des angeschlossenen Temperaturfühlers ausgelesen werden können. Ich habe hierzu im Web einige Vorschläge gefunden, aber nichts will wirklich funktionieren.


    Auf meinem Server läuft openSUSE 11.4 (x86_64) mit Kernel 2.6.37.
    'lsusb' liefert


    Code
    Bus 002 Device 006: ID 0403:ea90 Future Technology Devices International, Ltd Eclo 1-Wire Adapter


    In /etc/udev/rules.d/46-eclo-1wire.rules steht


    Code
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", GROUP="users", MODE="0666", RUN+="/etc/udev/eclo-1wire '%c'"


    und /etc/udev/eclo-1wire sieht so aus:



    Stecke ich den Dongle am USB-Bus ein, erscheint im Log...



    ...aber keinerlei Hinweis darauf, daß /etc/udev/eclo-1wire ausgeführt wird (es würde ja auf jeden Fall einen Log-Eintrag machen).


    Frage: was muß ich tun, damit mein Script beim Ein-(und möglichst auch Aus-)stecken des Dongles aufgerufen wird?


    Klaus

  • Das ist RRDTool. Prima Sache, um periodische Daten zu speichern und zu visualisieren.


    <edit>Sorry, doppelt</edit>


    Wolfgang

    MSI C847MS-E33, Cine S2 6.0, Zotac GT630 (GK208), dual boot
    Work: yaVDR 0.7 ansible Ubuntu 20.04. Backup: yaVDR 0.5 Ubuntu 12.06


  • Frage: was muß ich tun, damit mein Script beim Ein-(und möglichst auch Aus-)stecken des Dongles aufgerufen wird?


    Ich würde mal sowas als Minimal-Variante probieren:

    Code
    ACTION="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", +RUN="/usr/bin/logger Dongle eingesteckt"
    ACTION="remove", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", +RUN="/usr/bin/logger Dongle abgesteckt"


    Was sagt denn udev zu den Attributen des Dongle?

    Code
    udevadm info --query=all --attribute-walk --name=/dev/<Gerät>

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Ich würde mal sowas als Minimal-Variante probieren:

    Code
    ACTION="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", +RUN="/usr/bin/logger Dongle eingesteckt"
    ACTION="remove", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", +RUN="/usr/bin/logger Dongle abgesteckt"


    Die Syntax war wohl nicht ganz OK, ich habe es so zum Laufen gebracht:


    Code
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", RUN+="/usr/bin/logger Dongle eingesteckt"
    ACTION=="remove", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", RUN+="/usr/bin/logger Dongle abgesteckt"


    Stecke ich damit den Dongle ein und wieder aus, ergibt sich:



    Die Log-Meldungen aus RUN kommen aber nicht.


    Zitat


    Was sagt denn udev zu den Attributen des Dongle?

    Code
    udevadm info --query=all --attribute-walk --name=/dev/<Gerät>


    Das sagt:



    Klaus


  • Die Syntax war wohl nicht ganz OK, ich habe es so zum Laufen gebracht:


    Ja stimmt, ist ja ein Vergleich, keine Zuweisung


    Nach den udev-Attributen würde ich sagen, dass die originale Regel nicht greift, weil das SUBSYSTEM=="usb" nicht das Gerät erfasst (das müsste SUBSYSTEMS="usb" sein, wenn man auf das Attribut eines Parents hinaus wollte). So könnte es klappen:

    Code
    ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", RUN+="/usr/bin/logger Dongle eingesteckt"
    ACTION=="remove", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", RUN+="/usr/bin/logger Dongle abgesteckt"

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Nach den udev-Attributen würde ich sagen, dass die originale Regel nicht greift, weil das SUBSYSTEM=="usb" nicht das Gerät erfasst (das müsste SUBSYSTEMS="usb" sein, wenn man auf das Attribut eines Parents hinaus wollte). So könnte es klappen:

    Code
    ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", RUN+="/usr/bin/logger Dongle eingesteckt"
    ACTION=="remove", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ea90", RUN+="/usr/bin/logger Dongle abgesteckt"


    Leider keine Veränderung:



    Klaus

  • Hast du udev in der Zwischenzeit mal neu gestartet?


    Ich habe hier einen Arduino mit FTDI-Chip vor mir liegen, der sich so meldet:


    Und die udev-Regel funktioniert damit:

    Code
    ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/usr/bin/logger Arduino plugged in"

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hast du udev in der Zwischenzeit mal neu gestartet?


    Nein. Aber wenn ich einen Fehler in der Rules-Datei habe, dann meldet er den durchaus:

    Code
    Aug  4 14:42:48 dolphin udevd[417]: invalid ACTION operation
    Aug  4 14:42:48 dolphin udevd[417]: invalid rule '/etc/udev/rules.d/46-eclo-1wire.rules:1'
    Aug  4 14:42:48 dolphin udevd[417]: invalid ACTION operation
    Aug  4 14:42:48 dolphin udevd[417]: invalid rule '/etc/udev/rules.d/46-eclo-1wire.rules:2'
    Aug  4 14:43:05 dolphin udevd[417]: unknown key '+RUN' in /etc/udev/rules.d/46-eclo-1wire.rules:1
    Aug  4 14:43:11 dolphin udevd[417]: unknown key '+RUN' in /etc/udev/rules.d/46-eclo-1wire.rules:1
    Aug  4 14:43:11 dolphin udevd[417]: unknown key '+RUN' in /etc/udev/rules.d/46-eclo-1wire.rules:2


    Und das noch bevor ich den Dongle ein- oder abstecke.


    Wie starte ich denn udev neu?


    Klaus

  • Wie starte ich denn udev neu?


    Über dein Start-System (ich weiß nicht ob SuSE schon komplett von SysV Init zu systemd gewechselt ist)
    Regeln neu einlesen lassen geht prinzipiell so:

    Code
    udevadm control --reload-rules


    Und um den Daemon selbst neu zu starten hängt es davon ab was als Start-System genutzt wird

    Code
    #Ubuntu 
    service udev restart
    # Arch Linux
    systemctl systemd-udevd.service restart
    # Debian
    /etc/init.d/udev restart
    # Suse 11.1
    /etc/init.d/udev.boot restart

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Code
    /etc/init.d/udev.boot restart


    Danke, das habe ich jetzt mal gemacht, hat aber auch nichts gebracht:



    Klaus

  • Ich weiß ja nicht, ob das etwas zu sagen hat, aber udev Restart sieht bei mir so aus:


  • 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.


    Gruß
    e9hack

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo Klaus,


    Glückwunsch zur neuen Heizung!

    Zitat

    Die Innentemperatur messe ich mit einem "one-wire"-Fühler, da die
    Heizungssteuerung selber keinen Raumtemperaturfühler hat (haben die laut
    Aussage des Monteurs heute alle nicht mehr).

    Das ist aber eine sportliche Aussage deines Monteurs! :wand


    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?


    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.


    Hast Du einen Brauchwasserspeicher? Wie groß ist der?


    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.


    Gruß


    Gero

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!