eBus->USB->Plugin->KNX

[Gast]

OT+ : @yuhu: da wirste schon etwas mehr details liefern müssen, der RPi ist für mich erstmal nur ein kurzer Hype - denn es gibt seit langem besser geeignete Geräte mit weniger Stromverbrauch usw. - die meisten sogar mit Gehäuse für unter 50€ - wenn man denn "basteln" will.. Die OpenWRT-TOH sagt es Makki

Ob RPi oder ein Stück Hardware aus dem OpenWRT-TOH (ich will aber keinen Router bauen)

Die Frage besteht dann immer noch. Wie kommen die Fühlerdaten in so einen mini PC?

[Fry]

Kurze Durchsage:
wieder zu Hause, gleich auf der Baustelle gewesen, am Poti der Schnittstelle gedreht, jetzt stimmen alle CRCs.

Learning: stellt man das Poti zu unempfindlich, kommen die Syncs (aa) nicht durch. Stellt man es zu empfindlich, stimmen die CRCs nicht mehr. In beiden Fällen ist die Kommunikation auf der physikalischen Schicht unmöglich.

Vielen Dank für eure Tipps und Hilfestellungen!
Fry

[makki]

Die Frage besteht dann immer noch. Wie kommen die Fühlerdaten in so einen mini PC?

OpenWRT ist nur eine weitere Distro und die HW auch nur ein PC (allerdings mit Gehäuse günstiger als jeder RPi )

Mit owfs - allerdings bestehen da, ich nenne es mal erhebliche Diskrepanzen - zwischen meiner Meinung wie z.B. ein owfs (200kB vs. 1,1MB bei 4MB freiem Flash) Dateigrösse auszusehen hat und dem/der Autoren/Maintainer
Sprich ich hab da halt alles rausgeXed, was ich nicht brauche, Upstream werden die Pakete seit 4J eh nicht angenommen, also mach ich meine Version davon, repo.wiregate.de durchklicken, ist nicht schön aber selten
Und die DS9490 werden vom owfs Upstream immernoch falsch angesprochen/Initialisiert
Das wird aufm RPi nicht besser, nur hat der Code für den I2C DS2483 nach meinen Hinweisen u.U weniger Fehler

Makki

Edit: bevor jemand quängelt, ein paar Links zum Beleg eingefügt..

[JuMi2006]

Das bezieht sich aber alles aufs owfs = 1-Wire.
Der bei Roland vorhandene Fühler ist aber ein PT100 - also wird es mit dem 1-Wire direkt nicht zum laufen zu bekommen sein.

Vielleicht wäre ja das mit dem Multisensor hinzubiegen?

Messumformer 0-10V für den PT100, das Ding an den Multisensor und den eben via Busmaster ins owfs.

Messumformer: Enda MU-Pt 100-I420 Temperatur-Messumformer für Pt 100 im Conrad Online Shop | 198829

Multisensor: Präziser Adv. Multisensor für Temperatur, rel. Luftfeuchte, 2 IO, 0-10 V und Umgebungslicht mit störsicherer Messwertübertragung über 1-Wire Bus

Busmaster: 1-Wire Busmaster / USB Hostadapter DS9490R inkl. Kabelsatz für die Steuerung von 1-Wire Sensornetzwerken für eine digitale störsicherer Messwertübertragung

[DerThommy]

Hallo zusammen,

bin ganz neu hier und habe gleich mal eine Frage. Ich lese nun auch schon bereits einige Daten aus meinem eBus aus, bekomme aber regelmäßig eine B5 11 02 03 ... Nachricht und kann damit nicht so recht viel anfangen.

Anbei mal ein Beispieltelegramm:

10 08 B5 11 02 03 00 1E 00 0A EA 01 27 06 D1 05 03 28 00 00 C0 00

Wisst ihr was für Daten hier enthalten sein können?

[JuMi2006]

EDIT: Das Telegramm ist schon richtig, mein Fehler. Ich bin über das 0A gestolpert weil die Anzahl der DatenBytes in BCD angeben wird.

Was darin verschlüsselt ist lässt sich nur raten bzw. durch längere Beobachtungen in unterschiedlichsten Betriebsmodi erarbeiten.
Ich hab mit den zyklischen Telegrammen bei Vaillant vorerst aufgehört.
Jeder Wert den man braucht lässt sich auch aktiv abfragen, daher macht das für mich dort wenig/keinen Sinn.

Gruß

[Fry]

Ich hab mit den zyklischen Telegrammen bei Vaillant vorerst aufgehört.
Jeder Wert den man braucht lässt sich auch aktiv abfragen, daher macht das für mich dort wenig/keinen Sinn.

Geben wir damit das Ziel auf, ein universelles Ebus-Tool zu schaffen?

Ein solches sollte nämlich beides tun, die zyklischen Telegramme mitlesen und aktiv Telegramme senden. (Theoretisch sogar als Slave auf Master-Slave-Telegramme reagieren, das ist aber wohl weniger wichtig, mir fällt auch gerade keine Anwendung dafür ein).

Kann der ebusd das eigentlich aktuell? (Mitlesen und zwischendurch auch mal senden).

VG, Fry

[JuMi2006]

Hallo Fry,

nein geben wir nicht auf, aber ganz ehrlich, wozu die Mühe machen wenn ich jeden Wert (bei Vaillant) aktiv abfragen kann? Thommy hat auch ne Vaillant und da macht es einfach wenig/keinen Sinn. Na gut es sei denn man hat zu viel Freizeit .

Grüße

[MarcusF]

Messumformer 0-10V für den PT100, das Ding an den Multisensor und den eben via Busmaster ins owfs.

Das ist aber schon ein wenig von hinten durch die Brust ins Auge

Alternative 1 - die PT100 durch 1-wire Sensoren ersetzen. Wenn man an die Stelle hinkommt, wo die Fühler sitzen, wahrscheinlich die beste Lösung.
Alternative 2 - Lötkolben zünden und diesen Messumformer bauen und dann mittels Analogeingang am Raspberry Pi direkt messen.

Marcus

[Fry]

Hallo Fry,
...
Na gut es sei denn man hat zu viel Freizeit .

Na dann bleibt es wohl beim WG-Plugin und der spezifischen WG-Lösung.
Für mich ok, schließlich ist die WG-Software ja frei verfügbar.
VG, Fry

[JuMi2006]

Hallo Fry,

ich glaube Du verstehst da was falsch oder es kommt einfach nur falsch an. Ich wünsche mir auch einen Daemon der vieles kann, bin aber in C eine absoluter DAU und momentan auch keine Zeit das Fass noch aufzumachen.

Roland würde sich sicherlich über Unterstützung in Sachen C-Daemon freuen ... bislang hat er das alles allein auf die Beine gestellt.

Das WireGate-Plugin ist für mich nicht mehr als ein erweiterter Funktionstest des ebus_send. Das es so gut funktioniert ist natürlich wunderbar aber bislang hat sich lediglich kleinklausi zu den Protokollen von Wolf geäußert.

Ich will das definitiv auf eigenen Beinen stehen haben und nicht von der Appliance WireGate abhängig sein, so sehr ich es auch schätze. Dazu zählt für mich auch der wiregated.pl, auch wenn er GPL ist. Aber jetzt fange ich an mich zu wiederholen.

Also wären wir wieder bei der Frage zum Pflichtenheft und den spezifischen Kommandos der Wolf/Kröschröder/IDM/whatever-Heizungen. Beides Fragen die bislang teils unbeantwortet sind und um die sich dann auch jemand kümmern muss.

Für den weiteren Funktionsumfang sind die Programmierer mit C-Kenntnissen dann gern gesehen.
Vielleicht schaffen wir es ja noch uns auf was zu einigen was Sinn macht und ohne 10.000 Abhängigkeiten daherkommt.

Grüße

[Fry]

Nachdem meine CRCs korrekt waren, d.h. die physikalische Schicht endlich "tat", habe ich ein kleines Skript in Perl geschrieben, das den ebusd nutzt und alle zyklischen Telegramme einfach entschlüsselt und auf den Schirm bringt. Da meine Anlage noch nicht komplett in Betrieb ist (zB Zirkulationspumpe für Frischwasser fehlt), war das relativ schnell fertig.

Als nächstes werde ich das Senden ausprobieren. Mal sehen, ob auch bei Wolf alle wesentlichen Parameter abfragbar sind. Wenn das funktioniert, baue ich ein WG-Plugin für die Ansteuerung/Auslesung der diversen Temperaturen (Außen, Kessel, Vorlauf...) und Pumpen (Frischwasserzirkulation, Heizungs-Umwälzpumpe). Vielleicht noch Datum/Uhrzeit setzen, damit im Falle eines Ausfalls meiner Heizungssteuerung ein Notbetrieb mit Bordmitteln problemlos anspringt.

Das würde meine primären Bedürfnisse erstmal erfüllen. Darüber hinaus: Ein Mitschneiden des gesamten Ebus-Traffics analog zu eib.log (das macht übrigens der wiregated, nicht der eibd) fände ich gut als Diagnosewerkzeug für etwaige Störungen.

VG, Fry

[Fry]

@yuhu: ich gehe gerade im wesentlichen in Jumis Fussstapfen. Habe ebus_send ausprobiert, zunächst an einem Master-Master-Telegramm:

ebus_send -a00 -r5 -t2 -w -d /dev/ttyUSBebus "0305020102"

Zwei praktische Probleme:

1. Sende ich es als Master-Master (-t2), so bekomme ich GAR keine Rückmeldung. Ein bissel Debugging zeigt, dass eb_send_data eine -1 zurückgibt, dies wiederum scheint im Master-Master-Fall immer der Fall zu sein (ebus.c Zeile 789, sollte hier nicht 0 zurückgegeben werden?). UPDATE: das bedeutet offenbar, dass kein ACK kommt. Seltsam...

2. Das o.g. Telegramm soll bewirken, dass der Brenner mit einer Antwort (als Master-Master-Telegramm) gewisse Daten schickt. Nur sehe ich die Antwort nicht, da ich unmittelbar nach ebus_send nicht auf dem Bus lesen kann. Wie lässt es sich (einfach) einrichten, die ersten X Bytes oder Telegramme nach dem Senden zu bekommen? (das wäre immerhin ein Behelf)

Danke für deine tolle Arbeit!

VG, Fry

PS. Ich muss Master-Master-Telegramme nutzen, da die spezifischen Master-Slave-Telegramme zum Auslesen einzelner Datensätze (50 23, 50 22 etc. bei Wolf nicht öffentlich zugänglich dokumentiert sind).

[Gast]

@DerThommy - bist Du im ip-symcon Forum mit dem gleichen Account aktiv?

@all - Danke für die Hardware Tipps. Ich schiebe das Ganze mal zeitlich nach hinten. Ich habe im Frühjahr sicher nicht Zeit dafür.

@Fry - ehrlich gesagt, habe ich das Master-Master Telegramm implementiert, aber nicht testen können. Dazu bräuchte ich ein MM-Tel für Vaillant, wo ich weiß was es macht.

Kannst du das Telegramm mal mit hterm oder so absetzen? (nur zum testen, ob es überhaupt funzt)

[makki]

Geben wir damit das Ziel auf, ein universelles Ebus-Tool zu schaffen?

Das wäre IMHO sehr schade, weil sich hier glaube ich gerade etwas sehr tolles entwickelt (ich hab sowas ja ned, aber..)

Das Thema 0-10V (was für so Elektronik-Idioten wie mich mit einem 250Ω übrigens dasselbe wie 4-20mA ist) sollten wir glaube ich (gerne!) in einem sep. Thread abhandeln..

Makki