eBUS Adapter 3.0 Inbetriebnahme

Begonnen von Reinhart, 25 Januar 2021, 09:00:45

Vorheriges Thema - Nächstes Thema

Reinhart

Hallo!

Schön das du dich schon eingearbeitet hast, j die infois sind durch die verschiedenen Versionen schon recht vile, wobei alles was Konfiguration für Fhem ist ist ja nach wie vor einsatzbar.


       
  • Ist irgendwo beschrieben, wie die Blinkcodes der blaue Wemos-LED definiert sind? Ich finds nicht...
  • ja hier.

  • Wenn man sich beim Wemos, mal verkonfiguriert hat: wie kann ich den am einfachsten auf die Werkseinstellungen zurücksetzen, so dass er anschließend wieder ein WLAN aufspannt, über das ich eine neue Konfiguration vornehmen kann?
einfach neu flashen

   
  • Es ist superpraktisch, dass die csv-Dateien automatisch von http://ebusd.eu/config/ geladen werden. Allerdings ist mir nicht klar, wann genau sie gebraucht werden (nur für die Inbetriebnahme, oder auch im Betrieb), bzw. was passiert, wenn sie irgendwann mal nicht mehr dort liegen, oder einfach nur die Internet-Verbindung gestört ist. Daher meine Frage: werden vielleicht automatisch lokale Kopien angelegt, nachdem die automatische Zuordnung vorgenommen wurde? Macht es vielleicht Sinn, nach erfolgreicher Inbetriebnahme zumindest die relevanten csv-Dateien lokal abzulegen?
wenn du selber daran bastelst empfiehlt sich ohnehin die lokal zu laden.

   
  • Bei den Templates ist mir nicht ganz klar, wo eigentlich die aktuellen offiziell abgelegt sind. Ich hab zwei Versionen: eine, wo die Template-Namen ein vorangestelltes E_ haben und eine ohne. Eigentlich hätte ich erwartet, dass ich die versionierten Templates im fhem-Repo finde, aber da sind sie anscheinend nicht. Was ist denn jetzt aktuell?
da bei den Templates im allgemeinen kein oder wenig Interesse herrscht habe ich da auch nicht mehr weiter gemacht. Es ist auch schwer die Templates für alle Geräte einheitlich zu gestallten.

   
  • Ich fänd auch eine Übersicht gut, was es alles an relevanten Templates gibt. Da gibt's zwar den Mechanismus mit dem automatischen Nachladen, aber das find ich irgendwie zu spooky und würd das eigentlich viel lieber selbst beeinflussen können, welche Tempates ich haben möchte. Aber dafür bräuchte man eben ein Repo o.ä., damit man sieht was es gibt, und auch Änderungen nachvollziehen kann. Gibt's da was?
  • Und noch was ganz konkretes: Meine Heizung besteht aus Therme ecoTEC plus VC DE 206/5-5 R2,  Mischermodul VR61 und Regler calorMATIC 470f mit Funk-Außensensor. Der Scan findet alle drei:
    08;Vaillant;BAI00;0606;5502;21;14;51;0010011643;0001;009366;N3
    15;Vaillant;F4700;0114;6102;21;13;03;0020108134;0082;005047;N0
    50;Vaillant;V6100;0418;1902;21;14;47;0020139849;0082;011507;N0
    Fhem legt aber nur zwei devices an: MQTT2_ebusd_bai und MQTT2_ebusd_mc. Kann ich fhem irgendwie triggern auch das Device für den Regler anzulegen? Und müßte der Außensensor auch gefunden werden, oder ist der Teil des Regler-Devices?
genau, der Außenfühler ist beim 470f dabei und dieser müsste angelegt werden.
[/list]
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

beaune

Vielen Dank schon mal für Eure Hinweise. Ich komme tatsächlich gut voran.

Konkret bei meiner Heizungsanlage hab ich aber noch zwei Fragen, wo mich interessieren würde, ob das jemand hier schon mal herausgefunden hat:

  • Ich verwende das Vaillant Mischermodul VR61, hab also zwei Heizkreise. In der csv-Datei 15.f47.csv sind für viele Parameter nur die Daten für den ersten Heizkreis hinterlegt, z.B. für Hc1HeatCurve. Ich möchte jedoch auch auf Hc2HeatCurve zugreifen. Müßte ich also in der csv ergänzen. Die Frage ist: wie geht man da vor? Gibts irgendwo Hinweise, welche IDs dahinter stehen können? Hat vielleicht schon jemand eine erweiterte csv gebaut, wo weitere Parameter drin sind?
  • Was mich persönlich auch interessieren würde ist, ob der Brenner gerade läuft oder nicht. Das ist doch bestimmt auch über einen eBUS-Parameter zu ermitteln, aber über welchen?

chris371

Zitat von: beaune am 17 Juni 2021, 16:32:57

  • Was mich persönlich auch interessieren würde ist, ob der Brenner gerade läuft oder nicht. Das ist doch bestimmt auch über einen eBUS-Parameter zu ermitteln, aber über welchen?
Ich habe eine ganz andere Vaillant-Anlage als Du und daher weiß ich nicht, ob das vergleichbar ist, aber ein paar Informationen über den Brenner kann ich mit polling einiger "bai"-Werte (was immer das heißen mag) herausbekommen:
mqtt.0.ebusd.bai.Flame
on|off Flammensignal

mqtt.0.ebusd.bai.GasvalveUC
on|off Gasventil

mqtt.0.ebusd.bai.FanSpeed
{     "0": {"name": "", "value": 2217}}
0.value = Lüfterdrehzahl in U/min  (0 bei Brenner aus)

mqtt.0.ebusd.bai.FlowTempDesired
{     "temp": {"value": 0.00}}
temp.value = Vorlauftemperatur SOLL in °C  (0 bei Brenner aus)



"FlowTempDesired" stimmt bei mir aber leider nur im Heizungsbetrieb. Wenn der Brenner den Bereich für Heißwasser aufheizt, bleibt der Wert leider weiterhin auf 0

beaune

Super, danke! Hab die ersten 3 Parameter probiert und kann sie auch alle lesen. Da wär jetzt höchstens noch zu überlegen, ob es egal ist, welchen man nimmt, wenn man nur die an/aus-Information haben will. Ist wahrscheinlich egal.

Meinen zweiten Punkt hab ich selbst rausgefunden: In den csv-Files ist versucht worden, eine logische Zuordnung der Parameter zu den Devices vorzunehmen. Das finde ich etwas gewöhnungsbedürftig:

  • Man stellt die Werte für beide Heizkreise am Bedienterminal ein, das gleichzeitig Regler ist.
  • Da der Heizkreis2-Wert aber auf den Mischer wirkt, sind die Parameter offenbar dort zugeordnet. Kann man so machen, hätte ich aber nicht so erwartet.
  • Unglücklich finde ich auch, dass die Benennung total verschieden ist: "Hc1HeatCurve" heißt z.B. "HeatingCurve", anstatt des erwarteten Namens "Hc2HeatCurve".
Ist niht schlimm, wenn man es weiß, aber da ich einige Zeit gebraucht habe, dass zu verstehen, schreib ichs mal auf...

Was mich jetzt noch interessieren würde: Es gibt ja einige Werte, die anscheinend per Broadcast zyklisch übertragen werden. Die kriegt man in fhem dann automatisch mit. Braucht man andere Werte, muß man das zyklische Lesen anscheinend explizit programmieren. Allerdings hat ebusctl offenbar auch einen Cache, den man auslesen kann, wenn man nicht mit der Option -f arbeitet. Meine Frage: wo ist festgelegt, welche Werte vom Dämon zyklisch im Hintergrund gelesen werden? Ist diese Broadcast-Eigenschaft eine feste Parametereigenschaft, oder kann man das irgendwo konfigurieren? Dann könnte man die Poll-Aufgabe dem Dämon überlassen, und für den jeweiligen Einsatzfall unwichtige Daten auch rausnehmen, um den Bus zu entlasten.

chris371

Zitat von: beaune am 18 Juni 2021, 16:06:15
Es gibt ja einige Werte, die anscheinend per Broadcast zyklisch übertragen werden. Die kriegt man in fhem dann automatisch mit. Braucht man andere Werte, muß man das zyklische Lesen anscheinend explizit programmieren. Allerdings hat ebusctl offenbar auch einen Cache, den man auslesen kann, wenn man nicht mit der Option -f arbeitet. Meine Frage: wo ist festgelegt, welche Werte vom Dämon zyklisch im Hintergrund gelesen werden? Ist diese Broadcast-Eigenschaft eine feste Parametereigenschaft, oder kann man das irgendwo konfigurieren? Dann könnte man die Poll-Aufgabe dem Dämon überlassen, und für den jeweiligen Einsatzfall unwichtige Daten auch rausnehmen, um den Bus zu entlasten.
Möglicherweise vermischt Du in der Frage zwei Dinge, die eigentlich nichts miteinander zu tun haben:

Die Broadcasts und der "normale" Nachrichtenaustausch über den Bus wird von Deiner Heizung selbst gesteuert. Der ebusd hat damit nichts zu tun und hört lediglich zu, um aus den ausgetauschen Informationen die interessanten Daten mitzulesen. An der Stelle ist also nichts zu konfigurieren.

Wenn Du möchtest, dass der ebusd selbst im Hintergrund bestimmte Daten aktiv liest, musst Du das in der Tat über das sogenannte "polling" konfigurieren. Das erfolgt im Zusammenspiel der Start-Option --pollinterval (die legt das grundlegende Zeitraster in Sekunden fest) und dem TYPE-Feld der Message-Definition in den csv-Dateien (die bestimmen welche Messages wie oft gepollt werden sollen). Zu beachten ist aber, dass der ebusd damit durch die Aktive Nutzung den Bus eine Zeitlang belegt, und damit zumindest theoretisch die Kommunikation der Heizungskomponenten stören könnte. Deshalb ist es vermutlich das beste, nur die wirklich nötigen Werte zu pollen, und das auch nur so schnell wie nötig.

Gut zu wissen ist an dieser Stelle noch:

  • Die Poll-Priorität der Messages [1...9] gibt an, wieviele --pollinterval Intervalle vergehen dürfen, bis diese Message spätestens gepollt wird. 1=in jederm Intervall, 2=in jedem zweiten Interval, etc.. Sollte es in einem Intervall aber mal keine unbedingt zu pollenden Messages geben, rücken die mit höherer Intervaleinstellung nach. Konfigurierst Du beispielsweise nur eine einzelne Message fürs Polling, wirkt sich die angegebene Priorität gar nicht aus; die Message würde in jedem Intervall gepollt werden.
  • Im aktuellen Stand der Config-Files ist für die "YieldThisYear"-Message eine Poll-Priorität von r9 angegeben. Das führt zusammen mit dem Default-Wert für --pollinterval von 5 Sekunden meiner Meinung nach eigentlich zu unnötig viel Aktivität auf dem Bus.

beaune

Hallo,

sehr interessant...wenngleich auch verwirrend. Mir war z.B. gar nicht bewußt, dass defaultmäßig ein Pollintervall eingestellt ist. Allerdings habe ich tatsächlich auch in den für mich relevanten csv-Dateien keine einzige Variable außer der genannte YieldThisYear gefunden, wo eine entsprechende Prio-Angabe in den csv-Dateien enthalten ist und das Polling dementsprechend Auswirkungen haben könnte. Und konkret bei dieser ist auch seltsam, dass sie offenbar mal gelesen wurde (readings sind angelegt), aber nicht mehr aktualisiert wird. Das passt irgendwie nicht zusammen, der Dämon läuft aber und aktualisiert z.B. die Variablen, für die ich explizite Aufrufe als AT unter fhem angegeben habe.

Heißt in der Konsequenz dann also wohl, dass man den Poll-Mechanismus des Dämons lieber nicht nutzt, wenn man nicht alle csv-Dateien lokal ablegen und inhaltlich durcharbeiten will, und lieber ATs dafür anlegt. Oder sieht jemand größere Performanznachteile?

Ne andere Frage, die sich mir aufgrund der Diskussion sofort stellt ist dieses Thema:
Zitat von: chris371 am 21 Juni 2021, 17:07:48
Zu beachten ist aber, dass der ebusd damit durch die Aktive Nutzung den Bus eine Zeitlang belegt, und damit zumindest theoretisch die Kommunikation der Heizungskomponenten stören könnte. Deshalb ist es vermutlich das beste, nur die wirklich nötigen Werte zu pollen, und das auch nur so schnell wie nötig.
Hat denn schon mal jemand eine solche Störung des eBUS bemerkt? Wie macht sie sich bemerkbar? Und ab wievielen Parameterabfragen wird es kritisch? Mir fehlt hier bislang jedes Gefühl. Optimal wäre es natürlich, wenn man irgendwie die Busauslastung feststellen könnte. Gibts dazu Ansätze?

hallozuerich

Hallo zusammen,

Bei mir hat es jetzt funktioniert mit der Manuelen einlesung des Konfigurationsfile.

Wie kann ich sicherstellen, dass beim erstmaligen Verbinden keine wichtigen Parameter überschrieben werden? Oder das überhaupt nur gelesen wird?

Gruss Dario

rellla

#277
Wenn du nirgendwo aktiv einen Schreibbefehl absetzt, wird auch nichts geschrieben. Falls du meine Configs nutzt, da sind sowieso nur 4 Schreibkommandos enthalten:
Globalpasswort setzen, Warmwassertemperatur setzen, Zirkulation ein/aus und Behaglichkeit.

Ansonsten kannst du ebusd mit -r im readonly Modus starten -> https://github.com/john30/ebusd/wiki/2.-Run . Ich bin mir aber nicht mehr sicher, ob das nicht zu Einschränkungen führt. Ich meine mich dunkel an was zu erinnern...

Gruß
Andreas

chris371

Zitat von: beaune am 22 Juni 2021, 14:09:09
Ne andere Frage, die sich mir aufgrund der Diskussion sofort stellt ist dieses Thema:Hat denn schon mal jemand eine solche Störung des eBUS bemerkt? Wie macht sie sich bemerkbar? Und ab wievielen Parameterabfragen wird es kritisch? Mir fehlt hier bislang jedes Gefühl. Optimal wäre es natürlich, wenn man irgendwie die Busauslastung feststellen könnte. Gibts dazu Ansätze?
Ich hatte hier schon mal etwas zu dem Thema geschrieben... Wenn alle mitspielenden Parteien keine Fehler eingebaut haben, dürfte eigentlich auch bei hoher Busbelastung nichts durcheinanderkommen.

Eine so ausgelöste Störung zu bemerken ist vermutlich schwierig, weil ja irgendwas unvorhersehbares passiert. Ich hatte kurz nach Einbau des Adapters erstmalig den Fall, dass das Vaillant ecoTEC Brennwertgerät in einen Fehlerzustand ging, der erst manuell am Gerät quittiert werden musste, bevor es dann aber normal weiterlief. Keine Ahnung, ob das einen Zusammenhang hatte (vermute aber eher nicht). Kam auch seitdem nicht wieder vor. Leider weiß ich auch nicht mehr, ob das noch zu einer Zeit war, wo das YieldThisYear von mir damals noch unbemerkt alle 5 Sekunden gepollt wurde.

Was das Gefühl angeht: ich war überrascht, wie viel normalerweise schon auf dem Bus los ist (zu sehen an der grünen LED des Adapters). Schreiboperationen (rote LED) würde ich dann gern nur sporadisch und vergleichsweise kurz sehen. Ich bin allerdings vermutlich auch etwas überängstlich, was eine mögliche Störung angeht, weil ich bei mehreren Gelegenheiten persönlich mitbekommen habe, dass selbst namhafte Firmen ihre Software eher nach dem Prinzip "wenn's in den normalen Betriebssituationen funktioniert, ist's fertig" entwickeln. Ob das bei Vaillant auch der Fall sein könnte, weiß ich aber nicht.

beaune

Jetzt in ich an einem Punkt angekommen, wo mir Parameter in den csv-Dateien fehlen. Ich suche beim Vaillant-Regler Calormatic 470f die Zeitprogramme für den Heizkreis2 , den ich für meine Fussbodenheizung nutze. Es gibt include-Dateien für Heizkreis1, sowie Warmwasserbereitung und Warmwasserzirkulation, und damit kann ich auch die Werte lesen, die ich mit dem Regler eingestellt habe. Aber für Heizkreis2 hab ich nichts gefunden.

Hat das schon mal jemand gemacht bzw. die Daten herausgefunden? Oder hat jemand nen Tipp, wo man sowas nachschauen könnte?

treverer

Hallo Zusammen,

mein Adapter ist jetzt auch da und ich wollte ihn gerade in Betrieb nehmen.

Ich habe den Adapter per USB an den PI 4 angeschlossen (Jumper stehen beide auf USB).
Der Adapter wird aber nicht als ttyUSB0 oder ähnliches erkannt. Ich habe aber ein ttyAMA0.
Wen ich auf das ttyAMA0 in der Config Zugriff bekomme ich leider keine Verbindung.

Kann mir hier jemand helfen?

pi@raspberrypi:/dev $ ebusctl i
version: ebusd 21.2.v21.2-36-gfb5ab14
update check: revision v21.2 available
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd


Config:
EBUSD_OPTS="-d /dev/ttyAMA0 --httpport=8889 --scanconfig=full --enablehex --latency=0 --configpath=http://ebusd.eu/config/ -l /var/log/ebusd.log"

Was kann ich tun das der Adapter sich verbindet?

Reinhart

wenn du mit "lsusb" nix siehst, dann kann es nur das Kabel sein. Zwischen dem Adapter und dem Raspi ist ja nur das Kabel und der Uart des Konverters. Es gibt USB Kabel die nur Power liefern und entsprechend abgespeckt verdrahtet sind!

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

guinnes

#282
Hallo
Ich wollte meine Adapter 3 auch in Betrieb nehmen, habe aber Probleme :
Ich betreibe den Adapter mit einem Wemos, wenn ich den Jumper auf J12 zwischen 7 und 8 stecke ( enhanced Protokoll ) bekommt eBusD keine Verbindung :
2021-07-09 13:15:47.732 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device 192.168.178.30:9999
2021-07-09 13:15:48.095 [bus notice] bus started with own address 31/36
2021-07-09 13:15:48.102 [bus notice] device status: reset
2021-07-09 13:16:22.944 [main notice] direct cmd: 7f08b509030dcd00
2021-07-09 13:16:23.145 [bus error] send to 08: ERR: no signal, give up
2021-07-09 13:16:23.145 [main error] direct: ERR: no signal

Die Fehler gehen immer so weiter
Steckt der Jumper zwischen 6 und 7 hat eBusD zwar eine Verbindung, aber das angeschlossene Openhab meldet ständig Fehler :
2021-07-09 15:42:54.695 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2021-07-09 15:42:54.696 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2021-07-09 15:43:19.510 [INFO ] [lipse.smarthome.model.script.KinoCO2] - Kino CO2 Create Timer
2021-07-09 15:43:46.191 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
de.csdev.ebus.core.EBusDataException: Unable to send telegram 7F 08 B5 09 03 0D 09 00 96 after 2 attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: 7F 08 B5 09 03 0D 09 00 96]
at de.csdev.ebus.core.EBusQueue.checkSendStatus(EBusQueue.java:117) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController$EBusSenderThread.run(EBusEbusdController.java:112) [bundleFile:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_292]
2021-07-09 15:43:46.195 [ERROR] [.csdev.ebus.core.EBusEbusdController] - Error while parsing ebusd response: :ERR: invalid numeric argument
2021-07-09 15:43:46.208 [ERROR] [.csdev.ebus.core.EBusEbusdController] - Error Trace!
java.lang.NumberFormatException: For input string: "0:"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:1.8.0_292]
at java.lang.Integer.parseInt(Integer.java:580) ~[?:1.8.0_292]
at java.lang.Integer.valueOf(Integer.java:740) ~[?:1.8.0_292]
at de.csdev.ebus.utils.EBusUtils.toByteArray2(EBusUtils.java:323) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.parseLine(EBusEbusdController.java:218) [bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:284) [bundleFile:?]

Die Fehler kriege ich nicht, wenn ich das Binding im Openhab ohne eBusD sondern mit TCP betreibe

Kann mir jemand helfen ?

Danke
Guinnes

rob

Moinsen.

Ich möchte eine Frage zum ebus Dockercontainer stellen. Passt aber eigentlich nicht hierher. Nur wo stelle ich die rein? Klar, neuer Fred, aber unter welcher Rubrik?
Irgendwie fehlt mir eine Rubrik "Docker" (ist ja ein Querschnittthema)  :o
Soll ich einfach hier fragen und zur Not verschieben?

Vielen Dank und beste Grüße
rob

ioAndreas

Hallo zusammen,
ich habe seit einigen Tagen den Adapter3 (USB) bekommen (Danke!!) und habe doch einige Probleme, ihn ans Laufen zu bekommen. (Bin relativ Linux-unerfahren, deswegen können durchaus einige Verständnisprobleme/Logikfehler in meinem bisherigen Weg sein...)
Ich habe eine Vaillant VWS geoTHERM plus /2. Habe den ebus dort parallel abgegriffen und an die Platine angeschlossen. Weiter gehts per USB an einen Raspi3 mit Debian. ebusd habe ich installiert und folgende Config benutzt:

EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888  --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log  --scanconfig=full  --httpport=8889 --htmlpath=/var/ebusd/html"


"ebusd i" zeigt mir folgendes an:
pi@raspberrypi:~ $ ebusctl i
version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 31
max symbol rate: 110
reconnects: 1
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd


Problem:  die grüne LED auf dem Adapter blinkt lustig vor sich hin (wenn ich das richtig verstanden habe, ist das ein gutes Zeichen), aber ich habe den schweren Verdacht, dass meine Wärmepumpe noch gar nicht erkannt worden ist.

Rufe ich die HTML-Seite, Port 8889 auf, bekomme ich folgende Daten:
{
"broadcast": {
  "messages": {
   "datetime": {
    "name": "datetime",
    "passive": true,
    "write": false,
    "lastup": 0
   },
   "error": {
    "name": "error",
    "passive": true,
    "write": false,
    "lastup": 0
   },
   "id-u": {
    "name": "id",
    "passive": true,
    "write": false,
    "lastup": 0
   },
   "signoflife": {
    "name": "signoflife",
    "passive": true,
    "write": false,
    "lastup": 0
   }
  }
},
"global": {
  "version": "21.2.v21.2",
  "updatecheck": "OK",
  "signal": true,
  "symbolrate": 36,
  "maxsymbolrate": 110,
  "qq": 49,
  "reconnects": 1,
  "masters": 1,
  "messages": 11,
  "lastup": 0
}
}


Gibt es bereits jetzt schon Fehler, die ich gemacht oder Dinge, die ich vergessen habe? Neustart von Raspi und WP habe ich bereits gemacht, ohne Änderung.

Ich bin dankbar für jeden Hinweis.
VG Andreas