eBus Schaltung in Betrieb nehmen

[Reinhart]

@ansi7k3

Ich weiß zwar nicht genau warum du das unbedingt so machen willst, aber ich habe jetzt 2 Möglichkeiten für dich. Ob hier 2x eingetragen wird spielt letztlich für den Anwender keine Rolle, weder in den Plots noch in irgendwelchen Auswertungen.

1. Möglichkeit:
Du kannst einem Define ja mehrere Readings zuweisen, dann hast du alle deine Messwerte unter einem Define und einen gemeinsamen "state" (Event) auf den du immer noch reagieren kannst.

Code Auswählen Erweitern

define eBusdaten ECMDDevice bai00.class
attr eBusdaten IODev EBUS
attr eBusdaten group Vaillant
attr eBusdaten icon sani_supply_temp
attr eBusdaten room Vaillant

einen gemeinsamen Define anlegen, nennen wir ihn eBusdaten

alle Messwerte die du abholen willst, müssen nach wie vor in der bai.cfg definiert sein.
die Abfrage kann dann in etwa so ausschauen:

Code Auswählen Erweitern

define EBUS.Timer at +*00:15:00 get eBusdaten Aussentemp;;get eBusdaten Vorlauf;;get eBusdaten Ruecklauf;;get eBusdaten Fanspeed;;get eBusdaten PumpeWatt;;get eBusdaten HKurve;;get eBusdaten VorlaufSoll
du schreibst also alles in die eBusdaten und legst zu jedem Messwert ein Reading an. Ist irgendwie schöner übersichtlich, aber auch etwas komplexer zur Weiterverarbeitung.

Das Ergebnis ist dann so wie im Bild dargestellt.

2. Möglichkeit:
Wenn dir das noch nicht genügt weil du überhaupt keinen state haben willst, dann musst du alles in in GAEBUS definieren, der sieht genau so aus wie im Bild nur fehlt der state generell.

Doch vergiss nicht was amunra oben sehr schön beschrieben hat, ohne state kein Event!

LG
Reinhart

[ansi7k3]

@amunra, @Reinhart

Irgendwie habe ich gestern deine Nachricht, amunra, verpasst.  Sorry.

Jetzt wird mir klar was das Ganze soll Fhem erzeugt "state" automatisch und die andere Reading ist was wir letztendlich vom Device holen.

Ob hier 2x eingetragen wird spielt letztlich für den Anwender keine Rolle, weder in den Plots noch in irgendwelchen Auswertungen.

Das ist der Punk. Ich bin nicht aus Anwendersicht ausgegangen,  sondern aus einer des Datenbankadministrators. Wenn wir statt eine, zwei Zeilen mit fast identischem Inhalt speichern, dann ist es für mich nicht in Ordnung . Ich dachte fhem kann zwischen eine hypothetische Lampe mit "states" on/off und einem Sensor mit Werten unterscheiden. Und ein Event oder weiteres anhand der vorhandene oder Mangel an Input/Output generieren.

Mein Problem ist (war), das ich fhem in eine Oracle Datenbank schreiben lasse. Dabei habe ich den DBLog "gefixt". Ich habe da schreckliche dinge gesehen was die Programierung mit DBs angeht.   Z.B wenn man die Tabele oder Spalte mit einem Reserviertem Wort bennent, oder nimmt nicht in acht Char to Date    Umformatierung, etc... Dann habe ich Filelog angeschmissen, und sehe da das gleiche Bild - zwei Zeile pro Messung! Weiter gings mit Device Definition.. Ich dachte ich mache was falsch...

Wenn ich der fhem wäre, dann wird für mich eine Zeile an Daten vom Device ausreichen um es als "state" zu betrachten. Aber dafür kenne ich fhem nur seit Paar Wochen

Danke euch beiden. Entschuldigung für Starres Deutsch, die  Sprache ist für mich zwar sehr schön, aber fremd

Viellen Dank

PS: Aber ernst. Reinhart, wenn ich im FHEM die Maske  mit "Vorlauf.... Vorlauf..39.3" sehe, dann ist es für mich nicht in Ordnung. Das Wort "Vorlauf" soll vor der Temperatur verschwinden, weil es ist klar genug, dass es um "Vorlauf" geht.

Nachtrag:

Tipp: benutzt mindestens trim() beim postproc, dann sparen wir ganze Leerzeichen beim sprintf("%5.1f",$_) und zweistellige Zahl als Beispiel, und das ist es 1 Byte an bits was wir nicht umkippen müssen. Aus " 39.1" wird "39.1" Es spart nicht den Strom, aber Platz in der DB

Code Auswählen Erweitern


params message param
get StorageTemp cmd {"r -f %message %param\n"}
get StorageTemp expect "\d+\.\d+\n\n"
get StorageTemp postproc { trim(sprintf("%5.1f",$_)) }


[cs-online]

...ernsthaft ??

[ansi7k3]

...ernsthaft ??

trim()?  Klar ernsthaft.  Beim suchen in der DB muss man dann nicht die Leerzeichen ausfiltern... Es geht dann schneller. Aber natürlich für die Datenmengen spielt es keiner Rolle. Aber wenn man richtig machen will, dann schon. Es gibt slimmers. Z.B meine Kollegen aus Steuerungstechnik speichern pro Sekunde 100 Zeilen ab, und dabei Datum als String, Karl! Dann wundern sich sich warum Select so lange braucht. der Select macht aber to_date() für jede Zeile und so weiter. Unser Select wird aber trim() plus to_number() beim Suchen in der DB machen müssen.

Das DB-Model im FHEM ist sehr bescheiden. Ich würde die Zahlen nicht als Strings (Varchar) abspeichern. Und die Tabelle HYSTORY sollte man in zwei teilen, HYSTORY_READINGS und HYSTORY_STATES oder ähnliches. Aber so wie es ist funktioniert auch.

[Reinhart]

ich würde euch bitte ersuchen für die Datenbankdiskussionen einen eigenen Thread aufzumachen, denn die hat nichts mit dem eBus zu tun!
Es wird sonst schnell der Thread unübersichtlich.

PS: ich persönlich bin kein Freund von Datenbanken in einer Heimanwendung, man schafft sich hier schnell einen "Single Point of Failure" (eine korrupte Datenbank und alles ist weg).

LG

[Prof. Dr. Peter Henning]

Irgendwie scheint da jemand nicht lesen zu können. Wird gebeten, das an anderer Stelle zu diskutieren und macht einfach weiter.

pah

[Michael Schmidt]

So nun habe ich es endlich geschafft die Platinen zu löten.

Ich habe jedoch das seltsame Problem das wenn ich nach john´s Anleitung den ebusd starte und den raw mode aktiviere,
bekomme ich wenn ich den FTDI Adapter mit der Platine Verbinde bekomme ich folgendes zu sehen:

Code Auswählen Erweitern

[bus notice] signal aqquired
[bus notice] <00
[bus error] signal lost

wenn ich nun in sehr kurzen Abständen den FTDI mit der Platine verbinde bekomme ich auch durchaus mehr Daten aber sobal die Verbindung zwischen FTDI Adapter und ebus Platine bestehen bleibt gibt es Signal lost.

Der FTDI Adapter ist ein Sparkfun 5V

ich habe mal ein Multimeter bemüht, und 4,89V Gemessen.

- ist es egal auf welche Eingänge die Busleitungen bei der Platine kommen?
- was passiert auf dem ebus ich messe 0V mit kurzen wiederkehrenden 12-19V Spannungen (vermutlich Telegramme)?
- auf welchen Widerstand habt ihr das 20kohm Poti gestellt? (ich habe bei meinen 4 Platinen 1kohm und 2,53kohm gemessen nach den 26 Halbdrehungen rechts)

vielen Dank schonmal im Vorraus

Gruß
Michael 

[Reinhart]

- was passiert auf dem ebus ich messe 0V mit kurzen wiederkehrenden 12-19V Spannungen (vermutlich Telegramme)?

ich habe dir gerade per PN geantwortet weil ich den Post erst jetzt gesehen habe und die Vermutung mit den USB Problemen und dem Kernel geäußert. Wenn ich aber jetzt lese, dass du am eBus 0V misst, dann stimmt was nicht, das entspricht nicht den eBus Spezifikationen! Wie soll den der eBus eine Spannungsversorung (Speisung) realisieren wenn sie auf 0 Volt geht? Er soll ja zwischen 10 - 17 Volt shiften (logisch 0 und  1), siehe Wiki. Die 12-19V sind ok, aber auf 0 darf es nicht gehen!

Klemme die Platine ab und messe nochmals die eBus Spannung an der Therme, wenn dann alles ok ist, hast einen Fehler auf der Platine in Senderichtung (beim Senden Kurzschluß)!

LG

[Reinhart]

ich habe mir gerade nochmals die Schaltung angesehen, wenn du zeitweise auf 0 V kommst, dann kann eigentlich nur die Zenerdiode defekt sein (Kurzschluss). Gepolt ist sie schon richtig?

LG

[Michael Schmidt]

Hallo Reinhart

danke für die Infos,

Ich habe leider kein Oszilloskop nur 2 verschiedene Multimeter und das eine (digitale) misst nichts da die Spannung vermutlich zu schnell schwankt, und das zweite misst mal 0 mal 17V.
Aber vermutlich ist beides nicht sehr aussagekräftig

Ich habe nun die Platine abgeklemmt und es ändert sich nichts an den angezeigten Werten auf dem Bus.

Kernel Version ist 4.1.15-v7+

ich suche mal ob ich mit dem Kernel Ansatz was finde.

Die Zenerdiode dürfte es nicht sein, ich habe ja 4 Platinen und alle verhalten sich gleich.

Gruß
Michael

[Michael Schmidt]

Bein weiteren durchstöbern des threads sah ich das du für die alte Platine geschrieben hast TX mit TX verbinden und RX mit RX,

gilt das immernoch?
Dann ist das schonmal ein FEHLER meinerseits

hab das mal probehalber vertauscht und es sieht viel viel besser aus
Mist ich hatte den FTDI schon oft mit nem Ardupilot MEGA und arduinos in Benutzung da war immer TX-RX RX-TX

Gruß

[Reinhart]

ja zentis666 hat das absichtlich so beschriftet damit es für den Anwender logischer ist. Alle jene die sich mit RS232 aber auskennen haben damit nun Probleme das richtig zu interpretieren! Aber in diesem Fall TX mit TX!

Auch wenn es ein Digitalmultimeter ist sollte das nicht auf 0 gehen! Was ist das für ein Heizgerät und hat das auch wirklich Speisung am eBus vorgesehen? Es gibt auch eBus ohne Speisung (so wie unsere Platine).

Da sieht man wieder, nicht alles "moderne" ist auch wirklich besser (Digitalmultimeter). Ich habe zum Glück noch ein uraltes Zeigerinstrument herumliegen!

LG

[Michael Schmidt]

das war des Rätsels Lösung, bei 2kohm Poti Widerstand habe ich ein sauberes Signal.

habe nun noch einen seltsamen Fehler im Log:

Code Auswählen Erweitern


2016-02-18 19:30:07.242 [bus notice] signal acquired
2016-02-18 19:30:09.207 [bus notice] new master 77, master count 2
2016-02-18 19:30:19.794 [main error] unable to load scan config 7c: list files in /etc/ebusd/encon ERR: element not found


Ich habe mit deinem Installtool den ebusd und die configs dafür installiert funktioniert TOP.
Danke für die Mühe

Gruß

[Reinhart]

freut mich das es nun klappt, aber die Messung mit den 0 Volt kann nur ein Ablesefehler am Digitalinstrument sein.

Jetzt musst du beobachten (im Logfile) ob die broadcast schon aufgelöst werden. Hast du auch das Config Package geladen?

LG

[Michael Schmidt]

Ja das config package ist installiert.
ich finde in /etc/ebusd. die Ordner WOLF und VAILLANT und die 3 .csv Dateien

Die Sendeversuche aus deiner Anleitung z.B.

Code Auswählen Erweitern


ebusctl read -m 10 outsidetemp

werden mit

Code Auswählen Erweitern


ERR: element not found

quittiert

In der log Datei sieht es aber schon nicht schlecht aus da passiert zumindest etwas:

Code Auswählen Erweitern


2016-02-19 07:14:12.005 [main notice] ebusd 2.0.0ea7efc started
2016-02-19 07:14:12.053 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2016-02-19 07:14:12.062 [bus notice] signal acquired
2016-02-19 07:14:26.431 [bus notice] new master 77, master count 2
2016-02-19 07:14:34.497 [main error] unable to load scan config 7c: list files in /etc/ebusd/encon ERR: element not found
2016-02-19 07:22:04.974 [update notice] update broadcast ident QQ=77: ENCON;   " ;-;-
2016-02-19 07:22:06.013 [update notice] update broadcast error QQ=77: E111     


Ein ebusctl scan result ergibt:

Code Auswählen Erweitern

7c;ENCON;   " ;-;-

Das Gerät ist eine WOLF CWL 400 excellent.
Nach meinem Kenntnisstand ist der Hersteller Brink Climate Systems aus den Niederlanden.

hat jemand dafür möglicherweise bereits eine passende csv Datei?

Gruß
Michael