Läuft: Heizung mit eBus-Schnittstelle

Begonnen von Prof. Dr. Peter Henning, 29 November 2014, 13:36:59

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Keine Änderungen an der Schaltung, summt schön vor sich hin. Ich wünschte nur, ich hätte sie als Aufsatzplatine für den Raspberry gelötet - in dem Hutschienengehäuse ist nämlich noch massig Platz.

Klar ist der parallele Anschluss ok. Ich habe das getestet mit einem 10 m Fernmeldekabel (4 Adern geschirmt), tat bestens.

LG

pah

joachimS

Danke für die schnell Antwort pah,
Platz ist kein Problem, aber eigentlich wollte ich so eine Rasterplatine nehmen, die dürfte etwas gross als Pi Aufsatz sein
LG
Joachim
Gruss
Joachim

(fhem auf Synology DS209, CUL, FS20, FHT, EM, HM, Keymatic, Hue, OpenDTU)

Jojo11

Zitat von: Prof. Dr. Peter Henning am 26 Januar 2015, 05:45:15
Ich kann das Problem nicht nachvollziehen.

Bei mir ist das alles abgesichert - gestern habe ich z.B. zufällig einen meiner vier Raspberrys mit derselben IP-Adresse versehen, wie den Heizungs-Raspberry. Resultat ist natürlich, dass der ebusd nicht mehr erreichbar war.

Das merkt sofort ein notify:
define EBUS.N notify (EBUS.*DISCONNECTED.*)|(HK.Hz:Outside.T.*err) { EBUSrecover("notify EBUS.N",0)}
[...]
LG

pah

Hallo,

das ist ja soweit auch alles gut beschrieben und ich würde es gerne umsetzen. Allerdings scheitert es nicht am ebusd-raspi, sondern daran, dass mein fhem ein disconnect gar nicht mitbekommt. Es friert mit Status "connected" schon ein. Ich habe einen timer, der jede Minute "einige" Werte abruft. Das waren 27. Habe das jetzt mal testweise komplett entfernt, was aber nicht geholfen hat. Es wird also zum Zeitpunkt des Stoppens kein Wert abgerufen. Selbst ein Restart des ebusd hilft nicht. Kaum hatte ich zur Fehlersuche mal global verbose auf 5 gesetzt, lief es ohne Absturz. Dann wieder verbose 2, Absturz. Ok, das wird jetzt wohl eher nichts damit zu tun haben, aber es scheint so, als würde es mal gehen und mal nicht.
Ich teste mal weiter.

schöne Grüße
Jo

john30

Hallo ebusd Fans,
ich habe eine Bitte an die RPi User, bei denen der ebusd auf nem RPi läuft:
In meinem fork auf github (https://github.com/john30/ebusd.git) habe ich das Logging vom ebusd schlanker und direkter gemacht und ich würde nun gerne wissen, wie sich das auf dem RPi bemerkbar macht. Mir fehlt leider die Zeit, meinem die notwendige HW für den Buszugriff und das passende Image auf SD zu spendieren.
Insofern wäre es super, wenn das der ein oder andere mal compilieren und nen Tag lang laufen lassen könnte.

Noch was anderes zu einem älteren Beitrag:
"BADID" stammt definitiv nicht aus den Internas vom ebusd, sondern schlicht aus dem Register des adressierten Slaves. Es wurde ja gemunkelt, dass das evtl. eine ungültige CRC oder sowas sein könnte. Das ist es sicher nicht, da bei einer falschen CRC laut eBUS Protokoll der Transfer höchsten ein Mal wiederholt wird und beim erneuten CRC Fehler wird die Nachricht als nicht übermittelt eingestuft. Darauf nimmt ebusd ja Rücksicht.

Nachdem hier auch über Zugriffsrechte und potentielle Beschädigung der Komponenten durch fehlerhafte Writes auf dem Bus geredet wurde:
Ich überlege, ob es sinvoll wäre, jeder Nachricht einer CSV Config Datei eine Sicherheitsstufe zu verpassen. So könnte bspw. "0" (oder keine Stufe) für "das darf jeder" stehen, "1" für Zugriff erst nach Übermittlung der PIN in der Client-Connection zum ebusd (oder so ähnlich). Somit hätte man zumindest ein bisschen Sicherheit und wer keinerlei Nachrichten einer Stufe>0 haben will, könnte diese per Kommandozeilen Option vom ebusd ganz aus der Config nehmen lassen.
author of ebusd

MilanK

@john30: ich kann irgendwohin die binary data (raw dump file) uploaden,  dann kann man ebusfeed benutzen. Gib mir ein Bescheid.

Jojo11

Hallo,

irgendwie schaffe ich es nicht, einen nicht-numerischen Rückgabewert des ECMDDevices per ReadingsVal zu erfassen.
Folgendes passiert z.B. im event Monitor:

2015-01-28 19:52:53.632 ECMDDevice HK.Hz BAI00.HCCirculationPump off
2015-01-28 19:52:53.830 ECMDDevice HK.Hz BAI00.HCPowerInteralPump: 15.00 W


Daraufhin habe ich folgendes notify erstellt:

define n_HCInternalPump notify HK.Hz:.* {\
if (ReadingsVal("HK.Hz", "BAI00.HCCirculationPump", "") eq "off"){\
...


Das event wird erkannt, aber die if-Bedingung wird ignoriert. Hat dazu jemand eine Idee? Liegt es am fehlenden Doppelpunkt im event?

schöne Grüße
Jo

amunra

#366
Hallo Jojo11,
wie sehen die Readings bzw. der Reading-Wert BAI00.HCCirculationPump am HK.Hz Device aus? (->list).
Wie geht dein Noftify weiter? Ich sehe nur {if(){ ... damit fehlt etwas...
Beachte auch, dass der Reading-Wert evtl. "\n" beinhaltet - ist deine classdef sauber (habe da bisher keine Erfahrung mit ECMD).
Vielleicht hilft es.
VG

Jojo11

Danke für die Hinweise, das werde ich mal testen. Der Zeilenumbruch könnte es sein.

schöne Grüße
Jo


Prof. Dr. Peter Henning

Ich empfehle doch sehr, die ECMD-Returns nicht in einem FHEM-Skript, sondern in einem echten Perl-Unterprogramm abzuarbeiten und dort den Rückgabewert vor der Verarbeitung von solchem Kram zu befreien.

LG

pah

Jojo11

Es war der doppelte Umbruch. Danke nochmal! Mangels Zeit und Erfahrung muss ich das im Moment leider in fhem machen, auch wenn Du natürlich recht hast. Wenn erstmal alles grob läuft werde ich das mal angehen.

schöne Grüße
Jo


Reinhart

@john30

Danke für die neuen Sourcen. Ich habe alles auf meinen Raspberry installiert und setze nun den neuen ebusd ein. Ich lasse da so wie von dir gewünscht nun ein paar Tage laufen. Es laufen zyklische Abfragen und auch mehrmals täglich Befehle aus Fhem (Heizkurve) darüber.

Ich muss aber sagen, dass ich bisher auch keine Probleme mit der Betaversion gehabt habe, solange ich den ebusd bei laufendem Fhem nicht ständig stoppe und wieder starte.

Die neue Binary ist nun statt 2,7 Mb nur mehr 2,3 Mb groß.
Falls wer nicht alles neu compilieren und installieren möchte, hänge ich nur die (Test) ebusd von john30 seine Sourcen hier mit an, ich hoffe das passt so. Compiliert am Raspberry B+.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

amunra

#371
Zitat von: Jojo11 am 28 Januar 2015, 22:02:26
Es war der doppelte Umbruch. Danke nochmal! Mangels Zeit und Erfahrung muss ich das im Moment leider in fhem machen, auch wenn Du natürlich recht hast. Wenn erstmal alles grob läuft werde ich das mal angehen.

schöne Grüße
Jo

$result =~ s/\n//g;

sollte eigentlich schon helfen alle Umbrüche (ebusd liefert mehrere) zu entfernen (das verwende ich in meinem EBUS Modul - bisher zuverlässig - bevor ich die readings schreibe).
VG

Reinhart

Ich habe jetzt meinen eBus Heizkurvenregler schon einige Zeit in Betrieb und es funktioniert alles sehr gut.
Basiswert ist die Wichtung "Valves" und über Setlist wird ein Schwellwert (bei mir 95) vorgegeben ab wo die Steuerung eingreifen soll. Mit einfachen IF Abfragen wird der Schwellwert alle 30 Minuten überprüft und gegebenenfalls via eBus die Heizkurve angehoben bzw. abgesenkt.
Die Heizkurve wird zwischen 0.9 bis 1.2 automatisch den Ventilanforderungen (Valves/Wichtung) angepasst.

Früher hatte ich eine fixe Heizkurve mit 1.1 eingestellt, was natürlich einen höheren Gasverbrauch mit sich brachte. Ich spare jetzt (nach einer Woche Beobachtung) mit Hilfe des automatischen eBus Reglers bis zu 2 m³ Gas pro Tag.

Somit ist für mich der eBus und dieses Projekt eine ganz tolle Sache die wirklich was bringt!

Während der gesamten Testphase (ab dem Zeitpunkt wo ich nicht mehr ständig stoppe/starte) läuft er sehr stabil und ich hatte keinen einzigen Freeze von Fhem mehr. Ich kann aber die Probleme von heikoh sehr gut nachvollziehen, denn selbst ein Watchdog kann da keine Abhilfe mehr schaffen.

Unten im Bild sieht man schön wie sich die automatische Vorlaufregelung (Heizkurve) der Ventilstellung der Heizkörper anpasst und entgegen wirkt. Ab 4:30 Uhr wir die Therme hochgefahren und die erforderliche Leistung ab dann optimal nachgeregelt.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Jojo11

Hallo,

was ich nicht verstehe: Warum variierst Du nicht die Solltemperatur? Das entspricht einer Parallelverschiebung der Heizkurve bei gleichbleibender Steigung.

schöne Grüße
Jo

Reinhart

@Jojo11

im Prinzip habe ich eine Parallelverschiebung vorher gehabt. In Zeiten wo man den eBus noch nicht auslesen konnte, da habe ich im Außentemperaturfühler per FS20 einen Widerstand mit 100  Ohm vorgeschaltet, somit täuschte ich eine tiefere Außentemperatur vor und die Kurve verschob sich.
Ich glaube (vielleicht bilde ich mir das aber nur ein) das ich mit der direkten Steuerung der Heizkurve besser abschneide, weil ich somit die Kurve abflache und somit noch weniger Energie bei angenommener gleichbleibender Außentemperatur benötige.
Ein Heizkurvenwert von 0.9 wäre bei meinem 3-stöckigen Wohnhaus nicht möglich, aber mit Hilfe der automatischen Heizkurvenverstellung geht das nun leicht.

Genaue Aussagen über die tatsächliche Einsparung sind nur über längerem Zeitraum möglich, da sie sehr viel von den Umweltbedingungen abhängt. Im Augenblick ist es sehr günstig, da wir seit einer Woche in etwa die gleichen Bedingungen haben, in der Nacht unter Null und am Tag bis zu 4 Grad bei schwachem Wind.

Aber ich kann auch einmal deine vorgeschlagene Methode testen ob hier noch Unterschiede betreffend Einsparung sind.

schöne Grüße
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa