WOLF eBus Allgemein

[uxtuner]

cool! 

[alpha1974]

Liebe Wölfe,

für weitere Denkanstöße anbei meine csv-Files für eine CGB-2 mit BM2. Die Files sind bei mir unter /etc/ebus/wolfd/ gespeichert.
Außerdem habe ich die Datei ebus_hz.cfg angehängt. Diese Datei ist  bei mir unter /opt/fhem/FHEM/ gespeichert. Unter FHEM wird in dem EBUS-Device darauf verwiesen mit dem Attribut classdefs mit "ebus_hz.class=/opt/fhem/FHEM/ebus_hz.cfg".

Die csv-Dateien sind sicherlich nicht perfekt und die Einbindung einiger Befehle über die Datei ebus_hz.cgf ließe sich vermutlich noch eleganter über csv-Files lösen. Die Benennung der csv-Dateien müsste ich wohl auch mal an die neuesten ebusd-Konventionen anpassen...

Aber und das ist für mich entscheidend: Meine Installation läuft mit diesen Dateien seit langem problemlos und ich kann das BM2-Heizprogramm darüber fernsteuern.  Vielleicht ist das ja für den ein oder anderen Wolf-Besitzer hilfreich.

[burkhard6]

Liebe Wölfe,

für weitere Denkanstöße anbei meine csv-Files für eine CGB-2 mit BM2. Die Files sind bei mir unter /etc/ebus/wolfd/ gespeichert.
Außerdem habe ich die Datei ebus_hz.cfg angehängt. Diese Datei ist  bei mir unter /opt/fhem/FHEM/ gespeichert. Unter FHEM wird in dem EBUS-Device darauf verwiesen mit dem Attribut classdefs mit "ebus_hz.class=/opt/fhem/FHEM/ebus_hz.cfg".

Die csv-Dateien sind sicherlich nicht perfekt und die Einbindung einiger Befehle über die Datei ebus_hz.cgf ließe sich vermutlich noch eleganter über csv-Files lösen. Die Benennung der csv-Dateien müsste ich wohl auch mal an die neuesten ebusd-Konventionen anpassen...

Aber und das ist für mich entscheidend: Meine Installation läuft mit diesen Dateien seit langem problemlos und ich kann das BM2-Heizprogramm darüber fernsteuern.  Vielleicht ist das ja für den ein oder anderen Wolf-Besitzer hilfreich.

Hallo alpha1974
irgendwie habe ich ein gewaltiges Brett vorm Kopf
Ich komme mit den Verzeichnissen, Namen etc der CSV Dateien nicht ganz klar.
Wenn Du schreibst, daß Du die Dateien unter /etc/ebus/wolfd/ abgelegt hast, verstehe ich nicht, wie John dann in wolfd sucht.
Ich dachte immer, daß er aufgrund des Absenders (MF=Wolf,Kromschroeder etc) in die Unterverzeichnisse geht und dort sucht.
Wie bringst Du ihn dazu, in der Datei CGB-2 zu suchen. Gibt es da irgendwo ein Alias dafür?
Die Broadcast.csv bleibt in  /etc/ebus/wolfd und ist zusätzlich zur  Datei in /etc/ebus wirksam, oder ersetzt sie die dortige Datei?
Muss ich Das Verzeichnis Wof weiterhin mit Inhalt behalten? Es wurden mal Dateien von dort in ein Verzeichnis Kromschroeder kopiert.....
Hier mal meine Topologie :

masters: 6
messages: 23
conditional: 0
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Wolf;ID= !;SW=6001;HW=0000", loaded "wolf/08.csv"
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Wolf;ID=;SW=0204;HW=0000"
address 36: slave #8, ebusd
address 51: slave, scanned "MF=Kromschroeder;ID=  ;SW=0208;HW=-"
address 70: master #4
address 71: master #9
address 75: slave #4, scanned "MF=Kromschroeder;ID=  ;SW=0208;HW=-"
address 76: slave #9, scanned "MF=Kromschroeder;ID=  ;SW=0228;HW=-"
address f1: master #10

Vielleicht hat jemand noch ein paar klärende Worte für mich übrig 
Gruß
Burkhard

[alpha1974]

Hallo alpha1974
irgendwie habe ich ein gewaltiges Brett vorm Kopf
Ich komme mit den Verzeichnissen, Namen etc der CSV Dateien nicht ganz klar.
Wenn Du schreibst, daß Du die Dateien unter /etc/ebus/wolfd/ abgelegt hast, verstehe ich nicht, wie John dann in wolfd sucht.
Ich dachte immer, daß er aufgrund des Absenders (MF=Wolf,Kromschroeder etc) in die Unterverzeichnisse geht und dort sucht.
Wie bringst Du ihn dazu, in der Datei CGB-2 zu suchen. Gibt es da irgendwo ein Alias dafür?
Die Broadcast.csv bleibt in  /etc/ebus/wolfd und ist zusätzlich zur  Datei in /etc/ebus wirksam, oder ersetzt sie die dortige Datei?
Muss ich Das Verzeichnis Wof weiterhin mit Inhalt behalten? Es wurden mal Dateien von dort in ein Verzeichnis Kromschroeder kopiert.....
Hier mal meine Topologie :

masters: 6
messages: 23
conditional: 0
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Wolf;ID= !;SW=6001;HW=0000", loaded "wolf/08.csv"
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Wolf;ID=;SW=0204;HW=0000"
address 36: slave #8, ebusd
address 51: slave, scanned "MF=Kromschroeder;ID=  ;SW=0208;HW=-"
address 70: master #4
address 71: master #9
address 75: slave #4, scanned "MF=Kromschroeder;ID=  ;SW=0208;HW=-"
address 76: slave #9, scanned "MF=Kromschroeder;ID=  ;SW=0228;HW=-"
address f1: master #10

Vielleicht hat jemand noch ein paar klärende Worte für mich übrig 
Gruß
Burkhard

Tippfehler ich gemacht hatte, sorry: Das Unterverzeichnis heißt natürlich nicht wolfd, sondern wolf (ohne d).

Gesendet von meinem Nexus 5X mit Tapatalk

[burkhard6]

Hallo Alpha1974,
die CSV läuft jetzt ganz gut.
Jetzt stellt sich mir die Frage,wie ich die Befehle aus der ebus_hz.cfg in FHEM verwenden kann.
Bin im FHEM absoluter ANfänger. 
Hab ein device EBUS angelegt und mit
classdefs ebus_hz.class=/opt/fhem/FHEM/ebus_hz.cfg sie attribute gesetzt.

Weiterhin habe ich den Room heizung mit dem device Kesseltemp vom typ Dummy angelegt.
Wie könnte ich jetzt mit dem  Dummy Kesseltemp die Temperatur anzeigen?
Muss ich jetzt irgendwo # Kesseltemperatur eingeben oder sonst eine Verknüpfung machen ?

[alpha1974]

Ob das mit einem Dummy-Device klappt, weiß ich nicht...

Ich habe für jeden Einzelwert ein ECMDDevice angelegt. Für die Kesseltemp sieht das z.B. so aus:

Code Auswählen Erweitern

Internals:
   DEF        ebus_hz.class
   IODev      EBUS
   NAME       Kesseltemp
   NR         148
   STATE       44.5
   TYPE       ECMDDevice
   Helper:
     DBLOG:
       Kesseltemp:
         logdb_mysql:
           TIME       1517813604.94229
           VALUE       44.5
       state:
         logdb_mysql:
           TIME       1517813604.94229
           VALUE      Kesseltemp  44.5
   READINGS:
     2018-02-05 07:53:24   Kesseltemp       44.5
     2018-02-05 07:53:24   state           Kesseltemp  44.5
   fhem:
     classname  ebus_hz.class
     cache:
       specials:
         %NAME      Kesseltemp
         %TYPE      ECMDDevice
Attributes:
   IODev      EBUS
   group      Wolf_Heizung
   icon       sani_supply_temp
   room       Heizung
   stateFormat {ReadingsVal($name,"Kesseltemp",0)}

Für alle anderen für mich relevanten Werte habe ich entsprechende ECMDDevices angelegt.

Um die Werte zu aktualisieren, gibt es ein at-Device, das alle 5 Minuten ein get-Kommando ausführt, für die Kessetemp also
"get Kesseltemp Kesseltemp".

Die vollständige Def-Zeile für das at-Device sieht dann bei mir so aus:

Code Auswählen Erweitern


+*00:05:00 get Kesseltemp Kesseltemp; get Ruecklauftemp Ruecklauftemp; get SollwertStatus SollwertStatus; get FeuerungZustand FeuerungZustand; get FeuerungStatus FeuerungStatus; get LeistungBrenner LeistungBrenner; get LeistungPumpe LeistungPumpe; get Pressure Pressure; get Heizprogramm Heizprogramm; get Raumtemp Raumtemp; get Tagtemp Tagtemp

[smartstart]

Guten Morgen zusammen,

nachdem wir auch eine solche Gastherme bekommen habe ich mich hier umgeschaut. (Bin neu hier.)
Wir bekommen Therme: CGB-20, kein extra Bedienmodul und Solarmodul mit Puffer.

Kurze Frage: Wieso benutzt ihr alle das ISM7i wenn es die Version 8 und auch 9 inzwischen gibt?
Oder nur weil ihr schon länger dabei seid?

Freue mich über eine Antwort!
Lieben Dank!

[alpha1974]

Kurze Frage: Wieso benutzt ihr alle das ISM7i wenn es die Version 8 und auch 9 inzwischen gibt?
Oder nur weil ihr schon länger dabei seid?

Weder noch: Ich z.B. nutze Version 1.6 und 2.0. Allerdings nicht ISM, sondern die von sachkundigen Forumsmitgliedern entwickelte Adapter-Platine. Läuft tadellos und ist DEUTLICH günstiger als das Wolf-Zubehör.

[burkhard6]

Ich habe für jeden Einzelwert ein ECMDDevice angelegt. Für die Kesseltemp sieht das z.B. so aus:

Code Auswählen Erweitern

Internals:
   DEF        ebus_hz.class
   IODev      EBUS
   NAME       Kesseltemp
   NR         148
   STATE       44.5
   TYPE       ECMDDevice
   Helper:
     DBLOG:
       Kesseltemp:
         logdb_mysql:
           TIME       1517813604.94229
           VALUE       44.5
       state:
         logdb_mysql:
           TIME       1517813604.94229
           VALUE      Kesseltemp  44.5
   READINGS:
     2018-02-05 07:53:24   Kesseltemp       44.5
     2018-02-05 07:53:24   state           Kesseltemp  44.5
   fhem:
     classname  ebus_hz.class
     cache:
       specials:
         %NAME      Kesseltemp
         %TYPE      ECMDDevice
Attributes:
   IODev      EBUS
   group      Wolf_Heizung
   icon       sani_supply_temp
   room       Heizung
   stateFormat {ReadingsVal($name,"Kesseltemp",0)}

Für alle anderen für mich relevanten Werte habe ich entsprechende ECMDDevices angelegt.

Hallo alpha1974
ich habe jetzt mal die ECMDDevices analog zu Deiner Beschreibung angelegt.
Leider kommen keine Antworten vom EBUSD-

Hier der Log Auszug:
2018.02.08 17:18:54 0: Featurelevel: 5.8
2018.02.08 17:18:54 0: Server started with 18 defined entities (fhem.pl:16050/2018-01-30 perl:5.024001 os:linux user:fhem pid:508)
2018.02.08 17:19:51 1: 192.168.2.46:8889 reappeared (EBUS)
2018.02.08 17:23:50 2: EBUS: first attempt to read timed out, trying to close and open the device.
2018.02.08 17:23:50 3: Opening EBUS device 192.168.2.46:8889
2018.02.08 17:23:50 3: EBUS device opened
2018.02.08 17:23:53 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2018.02.08 17:23:53 1: EBUS: no answer received (wrote r -m 9 -c betrd_bm2 temp_burner\n (\162\040\055\155\040\071\040\055\143\040\142\145\164\162\144\137\142\155\062\040\164\145\155\160\137\142\165\162\156\145\162\012), expected \d+\.\d+\n\n)
2018.02.08 17:23:53 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 23) line 1.
2018.02.08 17:23:53 3: eval: { sprintf("%5.1f",$_) }
2018.02.08 17:23:53 3: EBUS.Timer: Kesseltemp   0.0

Auf dem Raspberry mit ebusctl folgende Antwort:
pi@raspberrypi3:~ $ ebusctl r -m 9 -c betrd_bm2 temp_burner
62.4

Der Eintrag in der ebus_hz-cfg:

# Kesseltemperatur
get Kesseltemp cmd {"r -m 9 -c betrd_bm2 temp_burner\n"}
get Kesseltemp expect "\d+\.\d+\n\n"
get Kesseltemp postproc { sprintf("%5.1f",$_) }

#ebus definitionen

Generelle Definintion für EBUS

define EBUS ECMD telnet 192.168.2.46:8889
attr EBUS classdefs ebus_hz.class=/opt/fhem/FHEM/ebus_hz.cfg
attr EBUS group Infrastruktur
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room Heizraum

define EBUS.Timer at +*00:05:00 get Kesseltemp Kesseltemp
attr EBUS.Timer group Infrastruktur
attr EBUS.Timer icon time_timer
attr EBUS.Timer room Heizraum

Definition der Kesseltemp in FHEM-cfg

define Kesseltemp ECMDDevice ebus_hz.class
attr Kesseltemp IODev EBUS
attr Kesseltemp group Kessel
attr Kesseltemp icon sani_boiler_temp
attr Kesseltemp room Heizraum
attr Kesseltemp stateFormat {ReadingsVal($name,"Kesseltemp",0)}


Vielleicht sieht jemand die Ursache, ich dachte EBUSCTL auf dem Raspi und ECMDDEV in FHEM sind identisch in der Syntax.

Gruß
Burkhard

[Reinhart]

und du bist dir sicher, das diese Adresse der Dämon (Rasperry) auf dem Port 8889 ist? Der Defaultport ist 8888, außer du hast den bewusst so eingestellt. Das ist NICHT die IP des Wemos und dessen IP Port. Ansonsten poste einmal deine Opts.

Code Auswählen Erweitern

Opening EBUS device 192.168.2.46:8889

Ich habe das hier einmal erklärt, da es hier mit der IP und dem Port oft zu Verwechslungen kommt!


LG

[burkhard6]

Hall Reinhart,

Manchmal sieht man den Wald vor lauter Bäumen nicht
Ich muss ja den EBUSD adressieren und nicht den WEMOS....
Da wird mir einiges klarer und ich kann mich jetzt dem nächsten grossen Thema widmen, den Konfig-Files und deren Anordnung in den Unterverzeichnissen
(Gibt es für jeden Master/slave egene Broadcast.csv oder habe ich durch das Umkopieren von wolf in Kromschroeder Duplikate erzeugt)
Ich denke das wird mir durch try and error verständlicher und vielleicht bekomme ich dann noch einige in den Konfigs unbekannte Telegramme(Solarertrag etc.)
einsortiert. Da gibt es Konfig-Files für ein Windows-Programm von Berhard Hopf, deren Struktur ich noch nicht ins ebusd-Format übersetzt bekommen hab.

Danke für die Hilfe und Eure Wahnsinnsarbeit beim Support des Adapters.

Jetzt fängt es wieder an Spass zu machen.
Gruß
Burkhard

[lichtimc]

Mein Adapter ist gelötet, und funktioniert auch soweit. (Ich kann die e-bus-Kommunikation in den Logs sehen.)
Verwaltet wird der Dienst mittels systemctl und config-files liegen unter /etc/ebusd .

... ich kann mich jetzt dem nächsten grossen Thema widmen, den Konfig-Files und deren Anordnung in den Unterverzeichnissen

Burkhard, läuft bei dir alles mit den csv-Files?
Falls ja, könntest du eventuell posten, wo du was konfiguriert hast und welche Datei wohin kopiert wurde, damit es richtig mit unseren Wolf-Heizungen funktioniert?
Hast du vielleicht auch schon weitere Befehle zuordnen können (und daher eine "aktuellere" csv-Datei?)

Das würde mir sehr helfen.

Danke und lg

[burkhard6]

Hallo lichtimc,
sorry für die späte Antwort.

habe leider noch keine vernünftigen Dateien.
Hatte scheinbar Netzteilprobleme und ein relativ schwaches WLAN im Keller, die keine zuverlässigen Tests ermöglichten.
Nun läuft es so lala, aber ich habe immer wieder timeouts, die dann zum Wert 0 für die Variable führen.

Hier mal der Log-Auszug:

2018.02.28 16:55:19 1: EBUS: unexpected answer ERR: read timeout\n\n (\105\122\122\072\040\162\145\141\144\040\164\151\155\145\157\165\164\012\012) received (wrote r -m 9 -c betrd_bm2 temp_burner\n (\162\040\055\155\040\071\040\055\143\040\142\145\164\162\144\137\142\155\062\040\164\145\155\160\137\142\165\162\156\145\162\012), expected \d+\.\d+\n\n)
2018.02.28 16:55:19 1: PERL WARNING: Argument "ERR: read timeout\n\n" isn't numeric in sprintf at (eval 1382) line 1.
2018.02.28 16:55:19 3: eval: { sprintf("%5.1f",$_) }
2018.02.28 16:55:22 3: EBUS.Timer: Kesseltemp   0.0

Der zugehörige Auszug aus der ebus_hz.cfg:

Kesseltemperatur
get Kesseltemp cmd {"r -m 9 -c betrd_bm2 temp_burner\n"}
get Kesseltemp expect "\d+\.\d+\n\n"
get Kesseltemp postproc { sprintf("%5.1f",$_) }

Ich weiss nicht , wie man den String read timeout abfangen kann und die Werte nur über den postprocessor laufen lassen kann, wenn eine gültige Antwort kommt.
Ansonsten würde ich gerne den alten Wert nicht überschreiben.

Bin leider auf dem Gebiet der Pearl-scripte nicht fit genug. Vielleicht hat ja jemand noch nen guten tip dazu.
Vielleicht muss man die reads auch zeitlich etwas entzerren.

Gruß
Burkhard

[Reinhart]

wenn du wirklich so ein schlechtes WLAN im Keller hast wird das Problem nicht so einfach in den Griff bekommen zu sein.

Du könntest versuchen einen Wemos mit Antenne zu kaufen, das könnte die Situation erheblich verbessern.
Eine andere Überlegung wäre den Uart zu verwenden und an einen Raspi anschließen. Den Raspi kannst du dann mit einem WLAN-Client mit Lan Anschluß versehen. Auch hier hast du die Möglichkeit mit Antennen zu arbeiten, kostet aber wesentlich mehr als die erste Variante.


Einfach einen Draht als Antennenersatz an den jetzigen Wemos anlöten bringt nicht viel, weil die schlechte Antennenanpassung (nämlich gar keine) dann alles wieder vernichtet. Dazwischen einen Repeater setzen ist in diesem Fall auch nicht gut, weil der die Latenzen wieder erhöht, beim Raspi wäre das allerdings egal weil da die Latenz keine Rolle mehr spielt.


LG

[burkhard6]

Hallo
ich habe es auch vorher mit dem uart probiert, da gabs noch Probleme mit dem Netzteil.
Jetzt habe ich mit der ebus_hz.cfg im Wesentlichen das Problem, dass die timeouts die Zeile mit dem expect und anschliessendem parsen
durcheinander bringen. Ich weiss nicht, ob man die Zeile mit dem postproc bedingt aktivieren kann.
Gehen solche STrukturen wie

get Kesseltemp cmd {"r -m 9 -c betrd_bm2 temp_burner\n"}
get Kesseltemp expect "\d+\.\d+\n\n"
If ( Kesseltemp != "ERR: read timeout\n\n")
{
    get Kesseltemp postproc { sprintf("%5.1f",$_) }
}

oder wie kann ich bei Timeout die Variable auf dem alten Stand behalten?