Dieser Thread dient als Hilfe für die Inbetriebnahme und sammelt alle Informationen über den Adapter V3!
Schon bei den vorherigen Versionen hat es sich bewährt die Infos in einem Thread zu sammeln.
Configs der verschiedenen Varianten
USB
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20 -d enh:/dev/ttyUSB0 --address=ff"
RPI
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=40 -d enh:/dev/ttyAMA0 --address=ff"
WEMOS
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=100 -d enh:ip_vom_wemos:9999 --address=ff"
ETHERNET (W5500)
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20 -d enh:ip_vom_W5500:9999 --address=ff
Universaladapter
Der Universaladapter bietet alle Versionen wie USB, RPI, Wlan und Lan und werden von uns mit allen Komponenten ausgeliefert.
Alle benötigten Buchsen- und Stiftleisten sind vorhanden und es kann mittels Jumper jeder der 4 Betriebsarten konfiguriert werden. Wer keinen Universaladapter hat, kann aber dennoch durch einlöten der Buchsenleisten auf eine andere Betriebsart wechseln und die benötigten Komponenten wie Wemos oder W5500 nachkaufen. Die Platinen unterscheiden sich zwischen den Varianten nicht!
Der am letzten Bild abgebildete Bauteil ist der Abstandhalter für die Version RPI. Er dient zur Auflage am Raspberry damit der Adapter nicht durchgedrückt werden kann. Diesen einfach durch das Loch am Adapter von unten einklicken, dass er nach unten wegsteht!
Wichtige Links:
Reservierungsliste/Bestellthread Adapter V3 (https://forum.fhem.de/index.php/topic,117350.msg1117256.html#msg1117256)
Adapter V3 Wiki (https://adapter.ebusd.eu/)
Jumper setzen Wiki (https://adapter.ebusd.eu/#jumper)
ebuspicloader Github (https://github.com/john30/ebusd/tree/enhanced_device/src/tools)
Pic Firmware Wiki (https://adapter.ebusd.eu/picfirmware)
WLAN Wiki (https://adapter.ebusd.eu/wemosebus.html)
RPI am Raspi2, 3, 4, und Zero einrichten Wiki (https://adapter.ebusd.eu/raspberrypi.html)
ebusd Released Images Github (https://github.com/john30/ebusd/releases/tag/v21.1)
1-wire Sensor DS18b20 (https://forum.fhem.de/index.php/topic,116418.msg1110105.html#msg1110105)
Temperaturerfassung am ADC des Wemos (https://forum.fhem.de/index.php/topic,116418.msg1111643.html#msg1111643)
Fehlermeldungen und deren Bedeutung (https://forum.fhem.de/index.php/topic,116418.msg1110775.html#msg1110775)
Hinweise Vaillant VR350 (https://forum.fhem.de/index.php/topic,118143.msg1140632.html#msg1140632)
Hinweise für IOBroker (https://forum.fhem.de/index.php/topic,118143.msg1143699.html#msg1143699)
Infos aus dem Betatest (https://forum.fhem.de/index.php/topic,116418.0.html)
Visualisierung via ECMD (https://wiki.fhem.de/wiki/EBUS-ECMD)
Einrichten ECMD (https://forum.fhem.de/index.php/topic,46098.msg381563.html#msg381563)
Visualisierung via MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2)
Visualisierung via GAEBUS (https://forum.fhem.de/index.php/topic,41064.msg332654.html#msg332654)
Visualisierung Heizenergie anzeigen mit svg (https://forum.fhem.de/index.php/topic,116836.msg1111936.html#msg1111936)
Visualisierung bunte Icons mit Ringfunktion (https://forum.fhem.de/index.php/topic,118329.0.html)
Visualisierung eBus komplett mit icon_ring (https://forum.fhem.de/index.php/topic,118143.msg1130686.html#msg1130686)
Einrichten GAEBUS (https://forum.fhem.de/index.php/topic,46098.msg381580.html#msg381580)
3D-Modell 3.0 Basis (https://a360.co/3nr9HqS)
3D-Modell USB (https://a360.co/3r5xTRA)
3D-Modell RPI (https://a360.co/38dPTR8)
3D-Modell Ethernet (https://a360.co/3gSLwz2)
3D-Modell WIFI (https://a360.co/2LDUdlb)
LG
Das eBus Team
Montage des Abstandhalter für die Variante RPI
Der mitgelieferte Abstandhalter dient zur Abstützung des Adapters damit die Platine nicht auf den Raspberry durchgedrückt werden kann. Sie wird von unten durch das Loch am Adapter eingeklickt und stützt somit den Adapter gegen Druck von oben ab.
Obwohl ich den Adapter noch nicht habe, mal eine Frage dazu:
Ich bekomme die WEMOS Variante, also mit WiFi.
Läuft der ebusd auf dem WEMOS?
Vielen Dank!
Laut Sendungsverfolgung kommt mein Adapter am 29.01. bei mir an; schönes Geburtstagsgeschenk. Vielen Dank!!! 8)
Aber mal kurz eine Frage im Vorfeld:
Ist der Anschluss des eBus an den Adapter verpolungssicher oder muss ich auf etwas bestimmtes achten bzw. im Vorfeld in Erfahrung bringen?
@Mitch: Nein, da brauchst du schon noch einen Linux Rechner.
@Wolle02: Ja, ist verpolungssicher.
Mein Adapter ist heute gekommen. Ging erst nachdem ich wie in der Konfig von Reinhart unten beschrieben die Latency hinzugefügt habe. Der 2.2 Adapter ging auch so.
Im Log habe ich ein paar Fehler die vorher so auch nicht da waren - hat jemand eine Idee was das Problem ist, bzw ob es ein Problem ist?
Die Meldungen im Log:
2021-01-28 15:48:02.349 [bus error] device status: eBUS comm error: framing
2021-01-28 15:48:02.349 [bus error] arbitration start error
edit: Hab im Betatest Thread gefunden, dass das "normale" Meldungen sind und evtl. auch noch runtergestuft wird.
Danke auch noch an das eBus(-Adapter) Team, tolle Arbeit!
Viele Grüße
Kalle
Danke, dachte ich mir schon. VM ist schon fertig und wartet ;D
Zitat von: kalled am 28 Januar 2021, 17:30:38
Im Log habe ich ein paar Fehler die vorher so auch nicht da waren - hat jemand eine Idee was das Problem ist, bzw ob es ein Problem ist?
2021-01-28 15:48:02.349 [bus error] device status: eBUS comm error: framing
2021-01-28 15:48:02.349 [bus error] arbitration start error
edit: Hab im Betatest Thread gefunden, dass das "normale" Meldungen sind und evtl. auch noch runtergestuft wird.
genau, das neue Deivce ist durch das enhanced Protkoll auch etwas gesprächiger und arbitration errors sind auch Normalzustand in einem Multi-Master Bus
I recently received the eBus adapter 3 and would like to share with you my experience so far.
Heating system is composed of a Vaillant EcoTEC plus VC 306/5-5, Unistor VIH R 150 HA, VRC 470f, hot water circulation circuit, 13 radiators with Netatmo smart valves. As Netatmo doesn't provide eBus connectivity but only on/off it's always been a struggle to optimise the overall system operation which I had done so far by adjusting timings but it was not effective enough. Now that I can play with the eBus data I'm able to control the central heating demand by identifying if smart valves detect a need for heat and pilot the VRC 470f to change Hc1OPMode to day or night and adjust either Hc1DayTemp or Hc1NightTemp depending on temperature differentials reported by the smart valves. Just took me a few hours to setup thanks to MQTT and json integration of Ebusd which allowed me to quickly implement the logic above in NodeRed. Tested over 2 days now and it's working great.
Also by injecting the MQTT data though a telegraf plugin into an InfluxDB instance I also gathered some very interesting datapoints, for example I noticed that the static heat loss in the Unistor VIH R 150 HA was 3 times what I had initially anticipated (with circulation pump off), I will have to check how to better insulate this part of the system.
Now for the hardware installation that was quite tricky and will definitely have to work on it a bit more. Initially I connected the eBus adapter close to the VRC 470f base, which is about 15 meters away from the EcoTEC, but the adapter was getting lots of connection errors, missing datapoints, and sometimes was disconnecting from the eBus and recovery of the connection was impossible (it didn't see any devices but itself anymore). I changed the connection to plug it into the bus port of the EcoTEC directly and data quality was much better. But then I experienced some transient issues with the ESP8266 plugged to the board, maybe due to a power issue or weak WiFi signal (didn't troubleshoot it further). Also the Ebusd docker instance was sometimes losing its connection to the mqtt server and didn't reconnect. So I completely changed the setup, built ebusd from sources on a fresh Raspberry OS instance and connected directly the adapter on RPI through USB, so far this setup is stable. In the next few days I will migrate again and troubleshoot at each step from USB to ESP/WiFi, then from raspberry PI to the docker server to streamline the setup of all my home automation software.
Thanks a lot to all the contributors to this project, on hardware and software sides, who make this all possible.
Hi zusammen,
traue ich mich auch mal an meinen ersten Post. Ich lese schon länger mit, aber mir fehlt noch ein grundsätzlicher Punkt (und auch bei der Recherche habe ich nichts finden können):
Steht irgendwo beschrieben, wie das 2 Draht Kabel z.B. an eine Vaillant Recovair angeschlossen werden muss?
Und wo habt ihr euren Adapter platziert? Direkt am Gerät oder wäre es auch möglich das 2 Draht Kabel über 5m zum Serverschrank zu verlegen?
Ich hoffe, das passt hier rein..
Beste Grüße,
Arne
Hallo, Arne
bin zwar kein Spezialist, aber ich kann ja mal berichten, was bei mir funktioniert. Ich haben einfach eine verdrillte Litze an einen (bereits belegten) Anschluss angeschlossen. Funktioniert problemlos. 5 m sind auch kein Problem. Der Ebus ist was den Draht und die Länge angeht eher unproblematisch.
Viele Grüße, Claus
Tabletui3 zur Visualisierung des Adapters V3
Ich habe heute einmal eine Mobile UI mit Hilfe des neu entwickelten Tablet-UI3 (https://forum.fhem.de/index.php/topic,115259.0.html) getestet. Die Entwickler sind zwar noch mitten drinnen, aber es lassen sich schon tolle Ergebnisse darstellen. Zum Unterschied der alten Tablet-UI2 gibt es hier wesentlich mehr Möglichkeiten und alles wird aufgepeppt!
Ich habe hier zunächst nur eine Seite gemacht und noch ohne Menüführung um die neuen Möglichkeiten auszuloten, aber es lassen sich tolle Effekte darstellen. Wer hier testen will, einfach die Tablet-UI3 installieren (https://github.com/knowthelist/ftui) (sind nur 3 Zeilen) und die unten angehängte index.html in /opt/fhem/www/ftui austauschen. Der Aufruf erfolgt dann mit
http://IP_von_Fhem:8083/fhem/ftui/index.html
oder einfach ins FHEM-Menü hinzufügen
define tablet_ui3 FTUISRV ftui/ ./www/ftui/ Tablet-UI3
LG
Reinhart
eBus Anzeige mit "icon_ring" und "icon_temp_ring" aufpeppen!
Damian hat ja sein DOIF mit svg-Funktionen (https://forum.fhem.de/index.php/topic,118329.0.html) nun so weit weiter entwickelt, dass sich auch in Fhem schöne dynamische Icons mit Farbring darstellen lassen. Wie man sieht gibt es immer wieder colle Ideen zur Verschönerung eurer GUI.
dazu einfach definieren.
defmod eBus_Vaillant DOIF ##
und dann das Attribut "uiTable" mit folgendem Inhalt setzen:
{package ui_Table}
"Temperaturen"|icon_temp_ring((([Fanspeed:Fanspeed]) >=0?"sani_boiler_temp\@red":""),[VorlaufSoll:VorlaufSoll:d1],20,60,120)|
icon_temp_ring("sani_supply_temp",[Vorlauf:Vorlauf],20,60,120)|
icon_temp_ring("sani_return_temp",[Ruecklauf:Ruecklauf],20,60,120)|
icon_temp_ring ("sani_water_hot",[WarmW.Temp.:WarmW.Temp.],20,60,120)
"Status Therme"|icon_ring((([Fanspeed:Fanspeed]) >=10?"vent_ventilation_level_3\@red":"vent_ventilation_level_0\@gray"),[Fanspeed:Fanspeed],0,3000,140,0,"upm",0,120)|
icon_ring((([PumpeWatt:PumpeWatt]) >=10?"sani_pump\@red":"sani_pump\@gray"),[PumpeWatt:PumpeWatt],0,100,120,0,"Watt",0,120)|
icon_ring ("weather_barometric_pressure",[Druck:Druck],0,2,120,0,"Bar",1,120)|
icon_ring ("temp_control",[HKurve:HKurve],0,2,120,0,"Curve",1,120)
Ich hab's hier beim Ventilator und der Umwälzpumpe so definiert, dass wenn diese nicht laufen das Icon grau wird. Die Readings müssen durch eure Werte ausgetauscht werden, zB: Fanspeed oder Druck.
Es geht auch wie im 2. Bild auch ein zweiter Ring, somit erhöht sich die Packungsdichte der Anzeige. Im rechten Icon wir Vorlauf und Rücklauf im Ring dargestellt, leider hat das Icon dann keinen Platz mehr und muss der Beschriftung weichen. Mir persönlich gefällt daher die Variante mit einem Ring besser, da sich hier ein Icon und der Messwert noch schön unterbringen lassen!
Im vorletzten Bild dann noch passend zum Thema Heizung ein paar HM-Regler auch mit "icon_ring" dargestellt.
{package ui_Table;;
$TC{0..4}="align='center'";;}
icon_temp_ring((([Fanspeed:Fanspeed]) >=0?"sani_boiler_temp\@red":""),[VorlaufSoll:VorlaufSoll:d1],20,60,120),"SollTemp"|
icon_temp_ring("sani_supply_temp",[Vorlauf:Vorlauf],20,60,120),"Vorlauf"|
icon_temp_ring("sani_return_temp",[Ruecklauf:Ruecklauf],20,60,120),"Rücklauf"|
icon_temp_ring ("sani_water_hot",[WarmW.Temp.:WarmW.Temp.],20,60,120),"Warmw."|
WID([WarmWasserEinstellen:state],"selectnumbers,55,0.5,60,1,lin","set"),"Warmw."
" ",icon_ring((([Fanspeed:Fanspeed]) >=10?"vent_ventilation_level_3\@red":"vent_ventilation_level_0\@gray"),[Fanspeed:Fanspeed],0,3000,140,0,"upm",0,120),"Ventilator"," "|
" ",icon_ring((([PumpeWatt:PumpeWatt]) >=10?"sani_pump\@red":"sani_pump\@gray"),[PumpeWatt:PumpeWatt],0,100,120,0,"Watt",0,120),"Pumpe"|
" ",icon_ring ("weather_barometric_pressure",[Druck:Druck],0,2,120,0,"Bar",1,120),"Druck"|
" ",icon_ring ("temp_control",[HKurve:HKurve],0,2,120,0,"Curve",1,120),"Hkurve"|
" ",WID([HeizkurveEinstellen:state],"0.20,0.40,0.50,0.60,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70","set"),"Heizkurve"
" ",switch([Kasa1:state],"sani_pump\@green","sani_pump\@grey","on","off"),"PumpeUG"|
" ",switch([PumpeEG:state],"sani_pump\@green","sani_pump\@grey","on","off"),"PumpeEG"|
" ",switch([Kueche:state],"sani_pump\@green","sani_pump\@grey","on","off"),"FBKueche"|
" ",switch([Wohnzimmer:state],"sani_pump\@green","sani_pump\@grey","on","off"),"FBWohnz"|
" ",switch([HM_6C9670:state],"sani_pump\@green","sani_pump\@grey","on","off"),"FBBad"
" ",icon_ring ("time_graph",[WichtungAll:state],0,2,120,0,"%",1,120),"Wichtung"|
" ",switch([Therme:state],"ios_off_fill\@green","ios_on_fill\@grey","on","off"),"Therme"|
" ",switch([Winter:state],"ios_off_fortimer_fill\@green","ios_on_fortimer_fill\@grey","on","off"),"Winter"|
" ",switch([AutoHeizkurve:state],"ios_off_till_fill\@green","ios_on_till_fill\@grey","on","off"),"AutoHc"|
" ",WID([Tagschaltung:state],"4,4.5,5","set"),"TagSchaltung"
Beispielcode für eine komplette eBus Anzeige aller relevanten Daten im letzten Bild. Die untersten 2 Reihen sind schaltbar durch anklicken auf das Icon (Pumpe, Switch).
Ebenso gibt es auch schöne Säulendiagramme (https://forum.fhem.de/index.php/topic,118329.msg1131149.html#msg1131149) in allen Varianten, zB. zur Energieanzeige!
Viel Spaß beim experimentieren!
Achtung
Es erreichen mich immer wieder per Mail oder PN Anfragen das der Adapter zwar soweit funktioniert aber nur spärlich Daten liefert!
Das ist auch richtig so, das Heizgerät liefert nur ein paar Broadcast Daten automatisch, warum sollte es am Bus auch mehr übertragen wenn es die zur internen Steuerung nicht braucht! Je mehr Geräte wie Calormartic etc. miteinander kommunizieren, desto mehr wird am Bus sichtbar werden, aber mit dem Adapter wird keiner von selbst kommunizieren, dieser lauscht lediglich am Bus alles mit!
Wer sich nun die Broadcast Daten genauer anschaut wird aber feststellen das hier schon gut brauchbare Messdaten enthalten sind:
,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
diese Daten kommen regelmäßig als Broadcast und müssen nicht extra angefragt werden, alles weitere muss vom Benutzer am Bus abgefragt werden!
Beispiel im der Console:
pi@eBus:~ $ ebusctl r -f FlowTemp
54.44;ok
Es gibt dazu verschiedene Ansätze:
- polling über Dämon
- Abfrage über ECMD
- Abfrage über MQTT via "get"
- oder GAEBUS einrichten, dass ist für Anfänger die einfachste Art da hier auch die Polling Steuerung mit enthalten ist und ihr euch nicht weiter kümmern müsst.
Alle Links zu den Infos sind im ersten Post enthalten und sollen euch bei den ersten Schritten weiter helfen und wenn das nicht hilft, dann bitte hier eure Fragen posten! Per PN oder Mail hat das wenig Sinn, dazu ist das Forum da!
LG
Reinhart
Kleine Info für alle, die auch die ersten Gehversuche mit ebus machen (so wie ich).
Mein Setup: ebus Adpater über wifi.
Zuerst wollte der ebusd ( läuft auf nem NAS (arm) ) keine Daten vom esp holen.
~# ebusctl info
version: ebusd 21.2.v21.2
access: *
signal: no signal
reconnects: 0
masters: 0
messages: 11
conditional: 0
poll: 0
update: 4
Auf dem esp habe ich dann nochmal alle Felder im webgui geprüft.
Wer lesen kann, ist wie immer klar im Vorteil. :-[ :D
Es fehlten wohl die Klicks auf "Check & Update" und "Save & Reset" ( hier kam der Hinweis: https://github.com/john30/ebusd-esp )
Ich habe dann den "Device String" aus dem Status für die Verbindung genommen.
eBUS adapter 3
Build: 20201122
ebusd device string: enh:172.16.1.212:9999
WiFi signal: 100% (-38dBm)
Und damit den ebusd neu gestartet:
~ # ebusd --loglevel=debug -d enh:172.16.1.212:9999 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=ff --readonly --accesslevel=*
Jetzt scheint er auch Daten zu bekommen, zumindest findet er andere Bus-Teilnehmer!
~ # ebusctl info
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 24
max symbol rate: 63
reconnects: 0
masters: 5
messages: 16
conditional: 0
poll: 0
update: 4
address 03: master #11
address 07: master #16
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=0202;HW=5103"
address 30: master #3
address 70: master #4
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=0202;HW=5103"
Kromschroeder ist vermutlich falsch, ich habe eine Weishaupt Anlage. Ich probier mal, ob ich mit https://github.com/J0EK3R/ebusd-configuration-weishaupt weiterkomme.
Danke an alle, die diesen Adapter möglich gemacht haben!
Danke für deinen Beitrag, solche Berichte helfen sicher einigen bei den ersten Versuchen gut weiter!
Aber wie man sieht, ganz ohne einzulesen funktionieren solche Projekte leider nicht!
Suche mal "Kromschroeder" in der Boardsuche, da gibts einige User die solche Geräte haben und darüber berichten.
LG
Reinhart
Hallo.
Ich habe auch eine Weishaupt und warte schon gespannt auf die Lieferung. Vorab schon einmal ein großes Dankeschön und ein fettes "Respekt" für die ganze Arbeit (schon allein die Bestellinfrastruktur - ist das noch basteln?).
Wenn ich das bzgl. config. zur Weishaupt alles so überfliege, bekomme ich doch kalte Füße. Verstehe ich richtig, dass ich erst diese ganzen CSV-Files begriffen haben muss bevor ich den Adapter in Betrieb nehme? :o
Es steht im Wiki ja eindeutig, dass ansonsten die Anlage beschädigt werden kann, wenn man nicht weiß was es tut.
Ich dachte ganz naiv: ebusd via docker starten, mit MQTT sprechen lassen und Adapter dran = über Readings freuen. So einfach ist es dann wohl doch nicht.
Den Adapter HW2.2 hatte ich testweise mal für 10 Min dran und bekam ein paar Temperaturwerte für außen. Mit CSV hatte ich dafür noch nichts gemacht - einfach nur mal schnell testen. Viele Wochen später hatte die Anlage ein paar Fehlermeldungen - jetzt sehe ich da doch einen Zusammenhang...
Gibt es eine gute Quelle, wo ich mich in den CSV-Krams gebündelt einlesen sollte oder bleiben allein die Threads?
Vielen Dank und beste Grüße
rob
Hello All!
I receive my rpi-board v3.
THANK YOU for creating the board.
I am trying to connect to my WOLF CGS24 (v1) using ebusd on rpi-v2 with newest OS (Raspbian GNU/Linux 10 (buster)).
WOLF CGS24 is a gas condensing furnace.
The board/ebusd does not recognize my WOLF.
In my logs I can see Kromschroeder.
I do not see WOLF.
Is there someone who managed to run the new board + ebusd + WOLF CGS?
My /etc/default/ebusd
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 --device=enh:/dev/ttyAMA0 --address=0 --loglevel=debug"
Some logs with scan results:
cat /var/log/ebusd.log | grep -v "received unknow\|received BC cmd\|performing regular tasks\|received MM cmd:\|ERR: read timeout during receive command ACK"
...
2021-03-10 14:53:17.926 [bus notice] scan f6: ;Kromschroeder; ;0204;0184
2021-03-10 14:53:17.926 [update notice] store f6 ident: done
2021-03-10 14:53:17.926 [update notice] sent scan-read scan.f6 QQ=00: Kromschroeder; ;0204;0184
2021-03-10 14:53:17.927 [bus debug] notify request: done
2021-03-10 14:53:17.927 [bus notice] scan f6: ;Kromschroeder; ;0204;0184
2021-03-10 14:53:17.927 [bus debug] switching from send response ACK to send SYN
2021-03-10 14:53:17.939 [bus debug] send/receive symbol latency 11 ms
2021-03-10 14:53:18.085 [main error] unable to load scan config f6: list files in kromschroeder ERR: element not found
2021-03-10 14:53:18.085 [main error] scan config f6: ERR: element not found
2021-03-10 14:53:59.888 [update error] unable to parse update-read broadcast datetime from 30fe070009008014561400000300 / : ERR: argument value out of valid range
2021-03-10 14:54:57.479 [update error] unable to parse update-read broadcast datetime from 30fe070009008011571400000300 / : ERR: argument value out of valid range
2021-03-10 14:55:20.240 [main notice] update check: OK
2021-03-10 14:55:48.574 [update notice] received update-read broadcast id QQ=30: Kromschröder; ;0208;0186
2021-03-10 14:55:48.776 [update notice] received update-read broadcast id QQ=70: Kromschröder; ;0208;0186
2021-03-10 14:55:48.940 [update notice] received update-read broadcast id QQ=30: Kromschröder; ;0204;0184
2021-03-10 14:55:52.625 [update notice] received update-read broadcast id QQ=70: Kromschröder; ;0204;0184
...
Some other logs.
2021-03-10 14:58:10.251 [main debug] performing regular tasks
2021-03-10 14:58:10.359 [update info] received BC cmd: f1fe050308010540ff84ff0004
2021-03-10 14:58:10.360 [update notice] received unknown BC cmd: f1fe050308010540ff84ff0004
2021-03-10 14:58:13.810 [update info] received MM cmd: 10030800084d2f000480030032
2021-03-10 14:58:13.810 [update notice] received unknown MM cmd: 10030800084d2f000480030032
2021-03-10 14:58:14.997 [update info] received BC cmd: f1fe080008662fe60200090032
2021-03-10 14:58:14.998 [update notice] received unknown BC cmd: f1fe080008662fe60200090032
2021-03-10 14:58:16.273 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:17.542 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:18.790 [update info] received MM cmd: 1003050709bb03f8020100ff64ff
2021-03-10 14:58:18.790 [update notice] received unknown MM cmd: 1003050709bb03f8020100ff64ff
2021-03-10 14:58:19.311 [update info] received BC cmd: 03fe050308010040007c3c2304
2021-03-10 14:58:19.311 [update notice] received unknown BC cmd: 03fe050308010040007c3c2304
2021-03-10 14:58:20.011 [update info] received BC cmd: f1fe050308010540ff7cff0004
2021-03-10 14:58:20.011 [update notice] received unknown BC cmd: f1fe050308010540ff7cff0004
2021-03-10 14:58:20.252 [main debug] performing regular tasks
2021-03-10 14:58:23.783 [update info] received MM cmd: 1003080008802f000480030032
2021-03-10 14:58:23.784 [update notice] received unknown MM cmd: 1003080008802f000480030032
2021-03-10 14:58:24.972 [update info] received BC cmd: f1fe0800081a2fe60200090032
2021-03-10 14:58:24.974 [update notice] received unknown BC cmd: f1fe0800081a2fe60200090032
2021-03-10 14:58:26.249 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:27.517 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 14:58:28.813 [update info] received MM cmd: 1003050709bb02f8020100ff64ff
2021-03-10 14:58:28.814 [update notice] received unknown MM cmd: 1003050709bb02f8020100ff64ff
2021-03-10 14:58:30.002 [update info] received BC cmd: f1fe050308010540ff7cff0004
2021-03-10 14:58:30.004 [update notice] received unknown BC cmd: f1fe050308010540ff7cff0004
...
2021-03-10 15:01:58.813 [update info] received BC cmd: 30fe070009008013041500000300
2021-03-10 15:01:58.814 [update error] unable to parse update-read broadcast datetime from 30fe070009008013041500000300 / : ERR: argument value out of valid range
2021-03-10 15:02:00.088 [bus debug] ERR: read timeout during receive command ACK, switching to skip
Errors:
cat /var/log/ebusd.log | grep "ERR" | tail -n 20
2021-03-10 15:17:27.583 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:36.252 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:37.523 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:46.385 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:47.622 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:47.694 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:47.766 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:50.281 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:51.519 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:51.591 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:51.662 [bus debug] ERR: SYN received during receive command ACK, switching to ready
2021-03-10 15:17:57.820 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:17:59.093 [update error] unable to parse update-read broadcast datetime from 30fe070009008013201500000300 / : ERR: argument value out of valid range
2021-03-10 15:18:00.367 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:06.520 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:07.791 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:16.319 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:17.590 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:26.259 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-03-10 15:18:27.530 [bus debug] ERR: read timeout during receive command ACK, switching to skip
Some errors from the scan:
cat /var/log/ebusd.log | grep "ERR" | grep -v skip
2021-03-10 14:53:08.778 [main error] unable to load scan config 08: list files in kromschroeder ERR: element not found
2021-03-10 14:53:08.778 [main error] scan config 08: ERR: element not found
2021-03-10 14:53:11.078 [main error] unable to load scan config 15: list files in kromschroeder ERR: element not found
2021-03-10 14:53:11.078 [main error] scan config 15: ERR: element not found
2021-03-10 14:53:13.388 [main error] unable to load scan config 35: list files in kromschroeder ERR: element not found
2021-03-10 14:53:13.389 [main error] scan config 35: ERR: element not found
2021-03-10 14:53:15.724 [main error] unable to load scan config 75: list files in kromschroeder ERR: element not found
2021-03-10 14:53:15.725 [main error] scan config 75: ERR: element not found
2021-03-10 14:53:18.085 [main error] unable to load scan config f6: list files in kromschroeder ERR: element not found
2021-03-10 14:53:18.085 [main error] scan config f6: ERR: element not found
Zitat von: rob am 10 März 2021, 13:09:33
Hallo.
Ich habe auch eine Weishaupt und warte schon gespannt auf die Lieferung. Vorab schon einmal ein großes Dankeschön und ein fettes "Respekt" für die ganze Arbeit (schon allein die Bestellinfrastruktur - ist das noch basteln?).
Wenn ich das bzgl. config. zur Weishaupt alles so überfliege, bekomme ich doch kalte Füße. Verstehe ich richtig, dass ich erst diese ganzen CSV-Files begriffen haben muss bevor ich den Adapter in Betrieb nehme? :o
Es steht im Wiki ja eindeutig, dass ansonsten die Anlage beschädigt werden kann, wenn man nicht weiß was es tut.
Ich dachte ganz naiv: ebusd via docker starten, mit MQTT sprechen lassen und Adapter dran = über Readings freuen. So einfach ist es dann wohl doch nicht.
Den Adapter HW2.2 hatte ich testweise mal für 10 Min dran und bekam ein paar Temperaturwerte für außen. Mit CSV hatte ich dafür noch nichts gemacht - einfach nur mal schnell testen. Viele Wochen später hatte die Anlage ein paar Fehlermeldungen - jetzt sehe ich da doch einen Zusammenhang...
Gibt es eine gute Quelle, wo ich mich in den CSV-Krams gebündelt einlesen sollte oder bleiben allein die Threads?
Vielen Dank und beste Grüße
rob
Hoi,
solange du nichts auf den BUS schreibst, machst du eigentlich auch nichts kaputt.
Die CSV Dateien werden benötigt, um die ebus-Telegramme zu dekodieren, soweit ich das verstanden habe - also aus einer Geräte ID wird dann ein sprechender Name. Das kann per "--configpath" eingebunden werden. BIn da aber noch nicht viel weiter mit gekommen.
Vielleicht lagern wir die Weishaupt-Diskussion in einen separaten Thread aus?
Das Problem mit den csv bei Wolf, Weishaupt, Kromschröder ist ja, das es keine csv Files am Server gibt. Ihr müsst deshalb den "configpath" auf lokale Umgebung stellen die Files dort hin kopieren, sonst versucht er sie vom Server zu holen wo es sie nicht gibt. Legt dazu einfach ein Verzeichnis /etc/ebusd/de/wolf (https://forum.fhem.de/index.php/topic,64039.msg1086383.html#msg1086383) o.ä an und kopiert die csv dort hinein. Schaut euch dazu einfach die Links unten genauer durch, es gibt dort wertvolle Hinweise zu euren Problemen.
--configpath=/etc/ebusd
JOEK3R hat hier schon sehr wertvolle Arbeit geleistet und seine Files hier (https://forum.fhem.de/index.php/topic,61017.0.html) zur Verfügung gestellt.
hier einige Links zu dem Thema:
Wolf mit configs (https://forum.fhem.de/index.php/topic,95173.msg1096693.html#msg1096693)
ebusd bei Wolf (https://forum.fhem.de/index.php/topic,70139.0.html)
Weishaupr am ebusd (https://forum.fhem.de/index.php/topic,61017.0.html)
Wolf ebus allgemein (https://forum.fhem.de/index.php/topic,61017.0.html)
Wolf cbg-k-24 (https://forum.fhem.de/index.php/topic,61017.0.html)
Die Erkennung ob Wolf, Kromschroeder etc. erfolgt ja durch auslesen der Hersteller ID und wenn sich euer Gerät so ausgibt dann sind auch die csv so aufgebaut.
r;b,,id,Identifikation,,,0704,,manufacturer,,UCH,0x06=Dungs;0x0f=FH Ostfalia;0x10=TEM;0x11=Lamberti;0x14=CEB;0x15=Landis-Staefa;0x16=FERRO;0x17=MONDIAL;0x18=Wikon;0x19=Wolf;0x20=RAWE;0x30=Satronic;0x40=ENCON;0x50=Kromschröder;0x60=Eberle;0x65=EBV;0x75=Grässlin;0x85=ebm-papst;0x95=SIG;0xa5=Theben;0xa7=Thermowatt;0xb5=Vaillant;0xc0=Toby;0xc5=Weishaupt;0xfd=ebusd.eu,,Geräte-Hersteller,,,id,,,Geräte-ID,software,,PIN,,,Software-Version,hardware,,PIN,,,Hardware-Version
Da keiner von uns ein derartiges Gerät besitzt, können wir da auch nicht so gut unterstützen.
LG
Reinhart
Zitat von: rob am 10 März 2021, 13:09:33
Gibt es eine gute Quelle, wo ich mich in den CSV-Krams gebündelt einlesen sollte oder bleiben allein die Threads?
die Grundlagen dazu hat John im Wiki (https://github.com/john30/ebusd/wiki/4.1.-Message-definition) zusammen gefasst. Das Thema ist aber doch sehr umfangreich und setzt viel Experimentierfreudigkeit voraus! Das Beste ist das bereits gesammelte auszunutzen, was leider sehr verstreut hier zu finden ist. Aber es gibt die Boardsuche die weiter helfen kann.
LG
Reinhart
Zitat von: stefan_d am 10 März 2021, 15:22:38
Vielleicht lagern wir die Weishaupt-Diskussion in einen separaten Thread aus?
ja, das ist eine gute Idee, es geht ja nicht um den Adapter selbst sondern allgemein um die Dekodierung bzw. csv Files für die spezifischen Geräte.
Ich habe oben schon ein paar Threads verlinkt, vielleicht passt eh schon einer zum Thema.
Hier möchten wir über den Adapter selber diskutieren, Inbetriebnahme Fehlermeldungen etc. damit die Sache übersichtlich bleibt.
LG
Zitat von: Reinhart am 09 Februar 2021, 18:36:52
Achtung
Es erreichen mich immer wieder per Mail oder PN Anfragen das der Adapter zwar soweit funktioniert aber nur spärlich Daten liefert!
Das ist auch richtig so, das Heizgerät liefert nur ein paar Broadcast Daten automatisch, warum sollte es am Bus auch mehr übertragen wenn es die zur internen Steuerung nicht braucht! Je mehr Geräte wie Calormartic etc. miteinander kommunizieren, desto mehr wird am Bus sichtbar werden, aber mit dem Adapter wird keiner von selbst kommunizieren, dieser lauscht lediglich am Bus alles mit!
Wer sich nun die Broadcast Daten genauer anschaut wird aber feststellen das hier schon gut brauchbare Messdaten enthalten sind:
,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
diese Daten kommen regelmäßig als Broadcast und müssen nicht extra angefragt werden, alles weitere muss vom Benutzer am Bus abgefragt werden!
Beispiel im der Console:
pi@eBus:~ $ ebusctl r -f FlowTemp
54.44;ok
Es gibt dazu verschiedene Ansätze:
- polling über Dämon
- Abfrage über ECMD
- Abfrage über MQTT via "get"
- oder GAEBUS einrichten, dass ist für Anfänger die einfachste Art da hier auch die Polling Steuerung mit enthalten ist und ihr euch nicht weiter kümmern müsst.
Alle Links zu den Infos sind im ersten Post enthalten und sollen euch bei den ersten Schritten weiter helfen und wenn das nicht hilft, dann bitte hier eure Fragen posten! Per PN oder Mail hat das wenig Sinn, dazu ist das Forum da!
LG
Reinhart
Hallo Reinhart,
leider muss auch ich sagen, es werden weniger Daten geliefert.
Bin von ebus v1 auf v3 umgestiegen. Habe also einfach den ebus Adapter gewechselt.
Das Device in fhem ist gleich geblieben. Leider fehlen ganz viele Readings, auch meine GETs und SETs gehen dadurch nicht mehr.
Sehr unschön.
hast du die config auf enhanced angepasst?
Wenn ja, dann poste bitte ein "ebusctl i".
das oben geschriebene gilt ja nur allgemein, weil einige Anwender hunderte von Datensätzen erwarten die durch den Adapter ins Fhem hereinrieseln, von selbst tut der nix. Du hast eh geschrieben, die müssen durch get oder set abgeholt werden. Wenn das bei dir nicht mehr funktioniert, dann vermute ich das die csv geändert (Server) oder nicht mehr geladen werden.
LG
was meinst du mit enhanced?
-d enh:ip:port habe ich dazu gefügt.
ein ebusctl i liefert:
version: ebusd 21.1.v21.1-12-gccfc025
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
ok, Version hast du die richtige, denn kleiner als V21 kann kein enhanced.
Dein Adapter hat aber gar kein Signal und kann eigentlich gar nicht funktionieren!
signal: no signal
hast du den alten Adapter auch noch parallel in Betrieb, das es zu einer Adress Kollision kommt?
Jumper auf der V3 hast du gecheckt, J12 1-2 steckt oder kann auxch entfernt werden, das ist der "enhanced" Modus.
Kannst du noch deine config posten?
LG
Da hatte ich gerade einen Fehler gemacht. Hab auch noch schnell einen Update gemacht. Jetzt passt es:
version: ebusd 21.2.v21.2
access: *
signal: acquired
symbol rate: 26
max symbol rate: 101
min arbitration micros: 4
max arbitration micros: 60
min symbol latency: 9
max symbol latency: 59
reconnects: 0
masters: 3
messages: 431
conditional: 19
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004279']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address ff: master #25, ebusd
Jumper sind so, wie das Ding angekommen ist. Müsste ich jetzt mal auf den Dachboden gehen.
Der alte ebus ist natürlich nicht mehr dran.
ja das sieht besser aus es werden auch die csv geladen, nur woher weiß ich noch nicht? Hast du die lokal genutzt oder vom Server, das sieht man nur aus der config.
Ich vermute das du jetzt die csv vom Server holst und hast vorher die lokalen benutzt und die sind nicht gleich.
Übrigens, du hast die gleiche Umgebung wie ich mit der Calormatic 430.
ich würde einmal bei einem Wert der jetzt nicht mehr funktioniert, wie der in der bai00.cfg ( oder wie immer die bei dir heißt) definiert ( Bezeichnung) steht. Und dann schaue mit ebusctl r -f Namen ob das noch passt, ich glaube nicht!
LG
Ne, eigentlich hatte ich die Config auch online genutzt.
So sah es in der alten ebusd config aus:
EBUSD_OPTS="--scanconfig --accesslevel=* --mqttport=1887 --mqttjson --mqtthost=192.168.0.202 --mqtttopic=ebusd/%circuit/%name --mqttclientid=ebusd --mqttchanges
so sieht es in der neuen aus:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:10.11.0.75:9999 --loglevel=debug --address=ff --mqttport=1887 --mqttjson --mqtthost=192.168.0.202 --mqtttopic=ebusd/%circuit/%name --mqttclientid=ebusd
wenn vorher online war und jetzt muss es passen. Ich würde aber trotzddem eine Abfrage so wie in der bai00.cfg definiert mit einer direkten in der Console vergleichen, es kann nur da der Fehler liegen weil es werden ja bei dir 431 Definitionen geladen! Nur die Bezeichnungen müssen noch passen.
ah ich sehe grad in deiner config, du benutzt WIFI.
Hast du auch die Software im Wemos auf esp3 upgedatet, sonst kann die nicht mit dem V3 sprechen.
Die Jumper müssen dann an der V3 auch angepasst werden, J1=RPI, J4=RPI, J12 4-5 verbinden.
Im Webif des Wemos musst auch einiges einstellen, siehe Wiki (https://github.com/john30/ebusd-esp).
Ja, das war schon alles passend drauf.
Bin jetzt auch einen Schritt weiter und kann wieder fast alles abrufen.
Eine bai00.cfg brauche ich übrigens nicht, nutze ja MQTT.
Gerade habe ich nochmal probiert, QuickVeto Temp abzurufen oder zu verstellen.
Geht beides nicht.
Wenn ich aber auf meine ebusd eingebe ebusctl r -m 10 Hc1QuickVetoTemp
Kommt 22.0 (was stimmt)
d.h. die csv passen so wie sie sind und per Console passt es. Laut deiner config ist auch die Topic gleich. Kannst einmal in FHEM den MQTT Server/Client auf verbose 5 stellen damit man im Log das sieht was da an MQTT ankommt.
Eventuell dann ein Get absetzen, das sollte dann gelogt werden.
set ebusMQTT publish ebusd/430/Hc1QuickVetoTemp/get
LG
Danke schonmal, werde ich morgen angehen.
ok melde dich wennst noch was brauchst!
Ich schätze das die Telegramme vom MQTT nicht richtig ankommen, bzw. etwas anders aussehen als erwartet.
Ich muss dann aber noch wissen wie du MQTT kommunizierst. Mit dem Mosquito als Broker oder schon den MQTT2 Server. Ich nutze MQTT2 Server und hab da ab und zu das Problem das plötzlich MQTT aussetzt, starte ich dann den eBus Dämon sauber geht wieder alles. Woher das kommt weiß ich noch nicht, da ich aber alle Adapter am Bus teste ist da schon ein wenig Wirwar bei mir.
hänge dir hier noch ein Beispiel an, wie die MQTT Abfrage bei mir im Log aussieht.
set ebusMQTT publish ebusd/430/HwcTempDesired/get
diese Abfrage ergibt im Log:
2021.03.10 21:49:13 5: in: PUBLISH: 0:(0)(24)ebusd/430/HwcTempDesired{(10) "temp1": {"value": 58.0}}
2021.03.10 21:49:13 4: ebusMQTT_10.0.0.6_46418 ebusd_21.1_394 PUBLISH ebusd/430/HwcTempDesired:{
"temp1": {"value": 58.0}}
2021.03.10 21:49:13 5: ebusMQTT_10.0.0.6_46418 ebusd_21.1_394 => ebusd/430/HwcTempDesired:{
"temp1": {"value": 58.0}}
2021.03.10 21:49:13 5: out: PUBLISH: 0:(0)(24)ebusd/430/HwcTempDesired{(10) "temp1": {"value": 58.0}}
2021.03.10 21:49:13 5: ebusMQTT: dispatch autocreate=complex\000ebusd_21.1_394\000ebusd/430/HwcTempDesired\000{\n "temp1": {"value": 58.0}}
Ich nutze nur MQTT2 Server.
Habe gestern Nacht nochmal neu eingerichtet (eigener MQTT2 Server nur für ebus) und laufen lassen.
Mal davon abgesehen, dass der ebus Adapter um 23:45 gemeint hat, er mag nicht mehr, kamen Daten an.
Was mir auffällt, wenn ich ein GET mache oder auch SET, dann geht es immer erst beim zweiten Mal.
Wie wenn das ganze "Konstrukt" erstmal aufgeweckt werden muss.
Die Schaltung ist angekommen und läuft - Besten Dank John. 8)
2 Fragen wären da noch:
pi@raspberrypi:/opt/fhem $ ebusctl i
version: ebusd 21.2.v21.2-11-gaf09988
update check: revision v21.2 available
access: *
signal: acquired
symbol rate: 39
max symbol rate: 141
min arbitration micros: 3
max arbitration micros: 10
min symbol latency: 10
max symbol latency: 20
reconnects: 4
masters: 4
messages: 485
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU01;SW=0304;HW=8802", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0111;HW=0103"
address e8: slave, scanned "MF=Vaillant;ID=FMU00;SW=0203;HW=6502"
address ff: master #25, ebusd
Wie komme ich zu einer csv für VWZ MEH61 und Arotherm 115/2? Sind das die IDs 76 und e8? Und dann?
2. Frage
pi@raspberrypi:/opt/fhem $ ebusctl find
700 AdaptHeatCurve = no data stored
700 BankHolidayEndPeriod = no data stored
700 BankHolidayStartPeriod = no data stored
700 ccTimer.Friday = no data stored
700 ccTimer.Monday = no data stored
700 ccTimer.Saturday = no data stored
700 ccTimer.Sunday = no data stored
700 ccTimer.Thursday = no data stored
700 ccTimer.Tuesday = no data stored
700 ccTimer.Wednesday = no data stored
700 ContinuosHeating = no data stored
700 currenterror = no data stored
700 CylinderChargeHyst = no data stored
700 CylinderChargeOffset = no data stored
700 Date = no data stored
700 DisplayedOutsideTemp = 11.9375
700 errorhistory = no data stored
700 FrostOverRideTime = no data stored
700 Hc1ActualFlowTempDesired = no data stored
700 Hc1AutoOffMode = no data stored
700 Hc1CircuitType = no data stored
700 Hc1ExcessTemp = no data stored
700 Hc1FlowTemp = no data stored
und so weiter
Ist es richtig, daß so oft no data stored dort steht?
Wenn man aber einen Wert abfragt, dann ändert sich die Ausgabe von find
pi@raspberrypi:/opt/fhem $ ebusctl r -f AdaptHeatCurve
no
pi@raspberrypi:/opt/fhem $ ebusctl find
700 AdaptHeatCurve = no
700 BankHolidayEndPeriod = no data stored
700 BankHolidayStartPeriod = no data stored
700 ccTimer.Friday = no data stored
700 ccTimer.Monday = no data stored
700 ccTimer.Saturday = no data stored
700 ccTimer.Sunday = no data stored
Ist das so richtig?
Zitat von: DerFranke am 11 März 2021, 21:34:47
Wie komme ich zu einer csv für VWZ MEH61 und Arotherm 115/2? Sind das die IDs 76 und e8? Und dann?
Du kannst mal schauen, ob es andere bzw. ähnliche Geräte mit diesen Adressen schon ein CSV gibt und das einfach mal probieren - natürlich mit entsprechender Vorsicht, also erstmal keine writes auslösen.
Parallel dazu mal schauen, was so an messages an diese Geräte vom Controller vorbei kommen (Stichwort grab und grab result).
Zitat von: DerFranke am 11 März 2021, 21:34:47
2. Frage
pi@raspberrypi:/opt/fhem $ ebusctl find
700 AdaptHeatCurve = no data stored
und so weiter
Ist es richtig, daß so oft no data stored dort steht?
Wenn man aber einen Wert abfragt, dann ändert sich die Ausgabe von find
ja das ist richtig so. ebusd macht von sich aus nur wenige Abfragen auf dem Bus, um diesen weder zu belasten noch zu stören. Das find Kommando zeigt sowieso nur gecachede Werte, man kann aber mittels Parametern den Cache Zeitraum auch vergrößern.
Zitat von: Mitch am 11 März 2021, 20:30:30
Ich nutze nur MQTT2 Server.
Habe gestern Nacht nochmal neu eingerichtet (eigener MQTT2 Server nur für ebus) und laufen lassen.
Mal davon abgesehen, dass der ebus Adapter um 23:45 gemeint hat, er mag nicht mehr, kamen Daten an.
Was mir auffällt, wenn ich ein GET mache oder auch SET, dann geht es immer erst beim zweiten Mal.
Wie wenn das ganze "Konstrukt" erstmal aufgeweckt werden muss.
sehr gut wenn du den MQTT2 benutzt! Dazu habe ich ja schon templates (https://wiki.fhem.de/wiki/EBUS-MQTT2#eBus_-_MQTT2) für die visuelle Anzeige veröffentlicht, oder hier (https://forum.fhem.de/index.php/topic,79600.msg878716.html#msg878716), die sind aber eher für Neueinsteiger gedacht um zu zeigen wie sowas konfiguriert wird.
Die Sache mit dem 2.mal hatte ich auch schon einmal, ich weiß aber nicht mehr wie ich das gefixt habe. Wie ich sehe, hast du sogar "--mqttchanges" aktiviert was ja grundsätzlich gut ist und den Traffic minimiert. Eventuell ist auch hier der Hund begraben wenn sich der Wert nicht ändert, schalte es zum testen einfach mal ab. Es wäre auch gut zu wissen ob der "Get" nicht weggeht oder die Antwort nicht ankommt, dazu auch verbose 5 auf den Server und mitlogen. Dann siehst du den Verkehr schön und findest wer der Übeltäter ist.
Wenn der Adapter aufhört Daten zu liefern, wäre es gut zu schauen ob im Log was auftaucht, bzw. auf jeden Fall einen Watchdog einzurichten. Der Adapter selbst wird es ja nicht sein sondern ist irgendwo am Übertragungsweg zu suchen. Daher ist auch das Log anzusehen wo der Dämon läuft.
Ich fahre ja parallel, also ECMD und MQTT, das brauche ich aber hauptsächlich nur im in solchen Fällen auch mitreden zu können. Auf der anderen Seite erleichtert es die Fehlersuche sehr, weil ich die Zeitpunkte exakt kenne und in den Logs dazu die richtigen Einträge schnell finde und zuordnen kann. MQTT2 ist im allgemeinen etwas schwieriger zu logen, aber geht genau so. Im Mosquitto Broker war das übersichtlicher, aber es geht auch genau so mit 2 Fhem Sitzungen, im einen läuft das Monitoring und im anderen setzt du Befehle ab.
Du bist ja mit der Sache eh schon gut vertraut, wäre schön wenn du uns am laufenden halten würdest was du da heraus gefunden hast. Ich helfe dir gerne, wenn ich dazu was beitragen kann.
LG
So, Adapter angekommen.
Setup:
- Wolf Brennwerttherme mit BM, Solarmodul
- ebus Adapter 3.0 mit LAN
- Homeassistant auf Raspberry Pi 4, MQTT Broker
- Docker auf Synology
Probleme beim Einrichten:
- ebus bei Wolf ist mit +/- Polung, hatte beim Wiederanschluss der Drähte das vertauscht, dann ging erstmal die Heizung nicht
- ebus Adapter nach Anleitung auf der ebus-Seite eingerichtet, könnte schwören da Stand Port 10000. Adapter nicht gefunden. Port 9999 und enh: statt udp: lief dann.
- ebusd hatte erst nach Adapter-Neustart per Stromanschluss erfolgreich wieder mit dem Ding reden können
Wichtiger Hinweis: wer per Synology den Adapter einrichten will, muss die '=' für den Docker Einstiegspunkt escapen:
-f --scanconfig -d enh:aebus.fritz.box:9999 --latency\=20000 --mqtttopic\=ebusd/%circuit/%name --mqtthost\=homeassistant.fritz.box --mqttport\=1883 --mqttuser\=user --mqttpass\=pass --mqttlog --accesslevel\=* --loglevel\=debug --address\=ff
Empfängt Telegramme von ebus, kann aber bisher damit nichts anfangen und sendet daher wohl auch nichts an MQTT. Meine nächste Baustelle.
Heute Nacht ist der Adapter wieder ausgestiegen.
Da hilft nur ein Neustart.
Einstellungen sind genau wie im Wiki.
Defekter Adapter?
leuchtet dann die blaue Led am Adapter?
blinkt die grüne Led am Adapter weiter?
LG
Ja und ja.
Aber gerade läuft er ja.
Wenn er sich wieder aufhängt, schau ich mir die LEDs an, bevor ich einen Reboot mache
Zitat von: Gurker am 12 März 2021, 09:39:50
Empfängt Telegramme von ebus, kann aber bisher damit nichts anfangen und sendet daher wohl auch nichts an MQTT. Meine nächste Baustelle.
von selbst sendet da nichts, außer deine Applikation macht das!
Du kannst aber für die ersten Test in der Console Abfragen absetzen.
poste bitte mal ein "ebusctl i" damit man sieht was da erfasst wird bzw. welche csv geladen werden!
LG
Zitat von: Reinhart am 12 März 2021, 10:56:56
von selbst sendet da nichts, außer deine Applikation macht das!
Du kannst aber für die ersten Test in der Console Abfragen absetzen.
poste bitte mal ein "ebusctl i" damit man sieht was da erfasst wird bzw. welche csv geladen werden!
LG
Gern, meinte mit dem Senden an MQTT. Das der Adapter erstmal nur hört habe ich gelesen. Denke aber der ebusd wird bei MQTT config bei erfolgreicher Config auch dann auch MQTT bedaten
root@john30-ebusd1:/# ebusctl
localhost: info
version: ebusd 21.1.v21.1-3-g62221bb
update check: invalid request
access: *
signal: acquired
symbol rate: 22
max symbol rate: 144
min arbitration micros: 1
max arbitration micros: 6
min symbol latency: 6
max symbol latency: 8
reconnects: 0
masters: 7
messages: 18
conditional: 0
poll: 0
update: 4
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Kromschroeder;ID= 3B ;SW=" error: ERR: argument value out of valid range
address 10: master #2
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address 51: slave, scanned "MF=Kromschroeder;ID= ;SW=0229;HW=-"
address 70: master #4
address 71: master #9
address 75: slave #4, scanned "MF=Kromschroeder;ID= ;SW=0229;HW=-"
address 76: slave #9, scanned "MF=Kromschroeder;ID= ;SW=0227;HW=-"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address ff: master #25, ebusd
ah ich sehe der Adapter funktioniert soweit aber es werden keine csv-Files geladen, weil er die Hard und Softwareversion deines Gerätes nicht auslesen kann.
address 08: slave #11, scanned "MF=Kromschroeder;ID= 3B ;SW=" error: ERR: argument value out of valid range
kommt das jedesmal so wenn du einen scan machst?
Der Dämon kann ja die empfangenen Daten erst dekodieren wenn er die csv als Basis hat und bildet dann das MQTT Telegramm, entweder im Json Format oder ohne.
LG
Zitat von: Reinhart am 12 März 2021, 13:03:04
ah ich sehe der Adapter funktioniert soweit aber es werden keine csv-Files geladen, weil er die Hard und Softwareversion deines Gerätes nicht auslesen kann.
address 08: slave #11, scanned "MF=Kromschroeder;ID= 3B ;SW=" error: ERR: argument value out of valid range
kommt das jedesmal so wenn du einen scan machst?
Der Dämon kann ja die empfangenen Daten erst dekodieren wenn er die csv als Basis hat und bildet dann das MQTT Telegramm, entweder im Json Format oder ohne.
LG
Macht er jedesmal. Braucht es dann weitere Logfiles um zu dekodieren welche Information meine Teile senden?
root@john30-ebusd1:/# ebusctl
localhost: scan
done
localhost: info
version: ebusd 21.1.v21.1-3-g62221bb
update check: invalid request
access: *
signal: acquired
symbol rate: 22
max symbol rate: 144
min arbitration micros: 1
max arbitration micros: 90
min symbol latency: 6
max symbol latency: 8
reconnects: 0
masters: 7
messages: 18
conditional: 0
poll: 0
update: 4
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Kromschroeder;ID= 3B ;SW=" error: ERR: argument value out of valid range
address 10: master #2
address 15: slave #2, scanned "MF=Kromschroeder;ID= ;SW=0229;HW=-"
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address 51: slave, scanned "MF=Kromschroeder;ID= ;SW=0229;HW=-"
address 70: master #4
address 71: master #9
address 75: slave #4, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address 76: slave #9, scanned "MF=Kromschroeder;ID= ;SW=0227;HW=-"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address ff: master #25, ebusd
Soll ich folgende/n Lösung/Ansatz mal ausprobieren? https://github.com/john30/ebusd-configuration/issues/71
Nachtrag zum Ansatz aus dem issue: hier muss ich mich noch einmal einlesen, anscheinend bin ich bisher zu doof die config per Hand anzugeben, oder die config ist nicht für die Version des ebusd kompatibel. Ich gebe dem ganzen noch mehr Zeit und eine Mütze Schlaf.
ja das geht in die richtige Richtung, aber zunächst sollte die HW Version erkannt werden, damit die csv dann ausgewählt werden können.
Es liest hier auch John mit, der kann über die Nichterkennung sicher mehr sagen.
LG
Zitat von: Reinhart am 12 März 2021, 18:57:48
ja das geht in die richtige Richtung, aber zunächst sollte die HW Version erkannt werden, damit die csv dann ausgewählt werden können.
Es liest hier auch John mit, der kann über die Nichterkennung sicher mehr sagen.
LG
Danke Reinhart,
_welche_ Ordner ich kopiere war wichtig. Habe jetzt Werte der Anlage, und einige unbekannte Kommandos.
z.B.
{
"kesselsolltemp": {"value": 40.602},
"aussentemp": {"value": 7.898},
"leistungszwang": {"value": 0},
"status": {"value": "00"},
"brauchwassersolltemp": {"value": 10.000}
}
oder
{
"status": {"value": 1},
"zustand": {"value": "30"},
"stellgrad": {"value": null},
"kesseltemp": {"value": 39.0},
"ruecklauftemp": {"value": null},
"boilertemp": {"value": 41},
"aussentemp": {"value": 9}
}
Der Adapter scheint bisher unterbrechungsfrei zu laufen, ich muss jetzt "nur" noch schauen welche Komponenten und wie die fehlenden Befehle sind. Gerade mein Solarmodul wäre sehr interessant.
sei doch bitte so nett und poste wie du es gelöst hast, es gibt ja hier mehrere Anwender die gleiche oder ähnliche Geräte Probleme haben und denen kann das sehr hilfreich sein.
-f -c /home/config -d enh:aebus.fritz.box:9999 --latency\=20000 --mqtttopic\=ebusd/%circuit/%name --mqtthost\=homeassistant.fritz.box --mqttport\=1883 --mqttuser\=user --mqttpass\=pass --mqttlog --mqttjson --accesslevel\=* --loglevel\=debug --address\=ff
Damit den ebusd im docker gestartet. Unter dem issue von oben war ja noch checkconfig. Der Parameter überprüft ja nur, weswegen sich der Dienst dann gleich wieder schließt.
Und /home/config/ liegt der Inhalt von https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de/, aber nur die Basisfiles mit dem Koschroeder Unterordner. Vaillant ist gelöscht.
Damit kommen dann Daten. Was mich wundert: für mein SM1 gibt es aus dem GitHub repo keine passende config, oder die CSvs müssen noch manipuliert werden. Ist das echt so selten?
Zitat von: Gurker am 13 März 2021, 23:10:34
Damit kommen dann Daten. Was mich wundert: für mein SM1 gibt es aus dem GitHub repo keine passende config, oder die CSvs müssen noch manipuliert werden. Ist das echt so selten?
Du meinst vom webservice, richtig? Dort ist im Moment nur das abrufbar, was im "Latest" Link im github (https://github.com/john30/ebusd-configuration/blob/master/latest) verlinkt ist.
Der Plan ist natürlich, hier so viele Geräte wie möglich zu unterstützen. Die Wolf/Komschroeder Geräte sind leider nicht besonders auskunftfreudig in ihrer Antwort auf den Scan, insofern eher etwas unschön.
Ich arbeite auch an einem UI, um die CSVs via ebusd bearbeiten zu können. Das dauert noch ne Weile, bis es sinnvoll nutzbar ist, aber dann sollte das unvergleichbar leichter klappen.
Zitat von: john30 am 14 März 2021, 09:27:37
Du meinst vom webservice, richtig? Dort ist im Moment nur das abrufbar, was im "Latest" Link im github (https://github.com/john30/ebusd-configuration/blob/master/latest) verlinkt ist.
Der Plan ist natürlich, hier so viele Geräte wie möglich zu unterstützen. Die Wolf/Komschroeder Geräte sind leider nicht besonders auskunftfreudig in ihrer Antwort auf den Scan, insofern eher etwas unschön.
Ich arbeite auch an einem UI, um die CSVs via ebusd bearbeiten zu können. Das dauert noch ne Weile, bis es sinnvoll nutzbar ist, aber dann sollte das unvergleichbar leichter klappen.
Vielleicht liegt es auch an den unterschiedlichen Sichtweisen/Detailtiefen, aber meine damit, dass die Signale meines SM1 bisher wenig/nichts ausgeben auch wenn die Daten auf dem Bus wohl erfolgreich liegen. Ich sehe unter latest auch keinen Ordner/Link für Wolf mehr, aber die andere geht ja für den Brenner.
Schaue mal ob in den Communities bei OpenHab oder woanders jemand schon mehr Daten gesammelt hat. Bin aktuell an Ertrag/Laufzeit interessiert, weil mein System immer wieder Druckprobleme hat, weshalb ich reale und geschätze Erträge abgleichen will. Druckmessung kommt dann über ein anderes MQTT Device.
Wow – das ist grandios! Ein ganz herzliches Dankeschön, an chons, Galileo, John30 und Reinhart! 8)
Mein Universaladapter ist angekommen und ich war sprachlos. Der Adapter sieht nicht nur hervorragend verarbeitet aus und alles funktioniert, ich frage mich auch, wie es möglich ist, diese Qualität als gemeinsames Projekt so hinzubekommen. Herzlichen Glückwunsch!
Die Anleitung zum Raspberry, zum USB-Mode und auch zur Ethernetversion finde ich sehr einsichtig, wichtiges ist mit Bilder noch einmal gezeigt und ich meine gemerkt zu haben, mit wie viel Umsicht für und Einsicht in den auch nicht so belesenen User diese Anleitungen geschrieben wurden. Beeindruckt hat mich, wie klein die Latenz bei der Ethernetversion ist – dies ermöglicht ganz neue Möglichkeiten, wo der Rechner und wo der Adapter seinen Platz hat.
Auch die Wifi-Wemos-Variante habe ich mit der Anleitung hinbekommen, ich möchte zwei Hinweise geben, in der Hoffnung andere damit zu unterstützen:
Beim ersten Einschalten baut der Wemos ein eigenes Wlan (Name EBUS) als Station auf. Ein Rechner kann sich nun in dieses vom Wemos aufgebaute Wlan einbuchen. Vom Rechner aus kann auf die Webconfiguration des Wemos auf IP 192.168.4.1 zugegriffen werden. Gerne zitiere ich stefan_d, der hier im Forum bereits auf die Wichtigkeit des Hinweises in der Anleitung hingewiesen hat, dass in der Web-Oberfläche die neu eingetragen Werte sowohl mit dem Button ,,Check &Update" als auch mit dem Button "Save & Reset" gespeichert werden müssen. Vielen Dank stefan_d!
Nach der Konfiguration der SID, des secrets, Check & Update, Save&Reboot baut der Wemos nun kein eigenes Wlan mehr auf, folglich kann der Rechner auch keine Wlan des Wemos mehr finden. Vielmehr bucht sich der Wemos in ein bereits bestehendes Wlan mit der in der Konfiguration eingetragenen SID / secret ein. Dies kann z.B. das von einem Router aufgebaute Wlan sein. Über diesen Router kann man dann erneut auf die Konfiguration des Wemos bzw. auf den ebus-Adapter zugreifen.
Mein Denkfehler war, dass ich davon ausgegangen war, der Wemos würde auch nach der Konfiguration als ,,Station" die konfigurierte SID senden und ich könnte mich in dieses Wlan dann wie vorher mit meinem Rechner einbuchen und so den Adapter mit meinen ebusd auf dem Rechner nutzen. Die im Wemos programmierte Variante hat sicher Vorteile, denn im Keller in der Nähe der Heizung befindet sich eher ein Router als ein Rechner. Beim Ausprobieren auf dem Schreibtisch (Wemos neben Rechner) wurde mir das allerdings nicht sofort klar. Wenn es dann funktioniert ist es einsichtig, dass die programmierte Variante sinnvoller ist. Vielleicht erspart dieser Post dem einen oder anderen Sucharbeit. Auch bei der Wemos-Variante ist die Latenz erfreulich sehr klein.
Nochmals besten Dank!
zum Thema Wemos sei noch gesagt das diese nur im 2,4GHz Netz arbeiten, 5Ghz geht nicht! Es soll sogar Geräte geben wo während der Einrichtung 5Ghz abgeschhaltet werden muss, aber bei den Wemos ist mir das noch nicht aufgefallen.
Und ja das ist korrekt, wenn der Wemos geflasht wurde spannt er zunächst einen eigen AP auf der nur zum konfigurieren fürs eigene Netz dient, ab diesen Zeitpunkt arbeitet er dann als Client ( wenn dies erfolgreich war ) . Das ist aber bei allen 8266 so. Die Latenz spielt in der Version 3 keine wesentliche Rolle mehr, weil der Mikroprozessor ( PIC ) auf der Platine das erledigt, somit können auch noch schwächere Funkstrecken erfolgreich sein!
Dokumentiert ist eigentlich alles, aber in der Flut an Informationen geht manches auch unter, hier die Beschreibung des Vorgangs beim ersten einloggen unter Configuration with HTML frontend (https://github.com/john30/ebusd-esp).
ZitatConfiguration with HTML frontend
After flashing, the device acts as an WIFI access point with SSID "EBUS", no password, and IP address "192.168.4.1".
The HTTP TCP port is set to port 80 by default. By entering the IP address of the device in a web browser, a status page like this is shown:
Und danke für deinen Bericht, sowas hilft vielen Einsteigern weiter.
Zitat von: Reinhart am 12 März 2021, 10:50:01
leuchtet dann die blaue Led am Adapter?
blinkt die grüne Led am Adapter weiter?
LG
Heute Nacht ist er wieder ausgestiegen.
Die orange LED leuchtet und die grüne blinkt.
Sieht so aus, als ob der ebus Adapter noch läuft, aber der WEMOS tot ist.
ja genau, hast du denn eine so halbwegs stabile Funkverbindung? Welchen RSSI hast du denn?
Eventuell hilft dir ein Wemos mit angesetzter Antenne (https://forum.fhem.de/index.php/topic,116418.msg1111145.html#msg1111145). Bei den ersten Bestellern die nur WIFI bei mir bestellten habe ich solche Wemos mit Antenne beigepackt, die verbessern die Verbindung enorm!
LG
WiFi signal: 60% (-70dBm)
Nicht das Beste, sollte aber locker reichen.
Am gleichen Standort sind noch zwei weitere, die machen gar keine Probleme.
Irgendwie kommt mir das wie ein Montagsgerät vor.
Zitat von: Mitch am 14 März 2021, 16:22:37
WiFi signal: 60% (-70dBm)
Nicht das Beste, sollte aber locker reichen.
Am gleichen Standort sind noch zwei weitere, die machen gar keine Probleme.
Irgendwie kommt mir das wie ein Montagsgerät vor.
Die Wemos sind generell nicht besonders gut wegen der mickrigen Antenne, die ne mittlere Katastrophe ist. Ich hab bei mir lange getestet und mit high power und allem rumprobiert, aber die einzig wirkliche Verbesserung hat das Ersetzen der Antenne durch einen 6cm langen Draht gebracht. Und 60% sind nicht unbedingt üppig, da ist bei mir zumindest die Verbindung nicht sonderlich stabil.
Zitat von: Mitch am 14 März 2021, 16:22:37
WiFi signal: 60% (-70dBm)
Nicht das Beste, sollte aber locker reichen.
Am gleichen Standort sind noch zwei weitere, die machen gar keine Probleme.
Irgendwie kommt mir das wie ein Montagsgerät vor.
wenn du meinen oberen Link gelesen hast, dann wirst du auch gesehen haben das die neueren Wemos nicht mehr die Empfindlichkeit haben als die älteren! -70 dBm ist schon hart an der Grenze, aber wenn du nicht herunter steigst das der Adapter an allem schuld ist und ein Montagsgerät ist dann verkaufe ihn doch hier im Forum, es gibt genug die auf einen warten! Bei einer schlechten Funkverbindung kann auch das enhanced Protokoll nicht zaubern und wenn du nicht gewillt bist den Empfang zu verbessern wirst du da nicht recht zu einer Lösung kommen.
- ein Stück Draht anlöten
- den Wemos gegen einen mit Antenne tauschen
- einen zusätzlichen AP setzen
- am Standort des Wemos variieren
- usw.
LG
Kein Grund auf mich los zu gehen!
Habe nie gesagt, dass ich da nichts tun werde.
Externe Antenne geht aber nicht, ist ja ein Mini.
Werde einen Pro probieren.
Mal davon abgesehen, kommt im Moment z.B. kein Druck an.
Das liegt dann eher am ebus Adapter, als am Wemos.
Insgesamt ist das ganze sehr ,,fragil".
Und nur mal um das klar zu stellen, warum soll ich den Adapter verkaufen?
Ich gehen mal ganz stark davon aus, das ,,ihr" den kostenlos austauscht, falls er defekt ist.
Nichts für ungut, aber du musst mich nicht anpflaumen!
ich gehe nicht los auf dich, ich zeige dir nur die Möglichkeiten die du hast um den Fehler zu beseitigen oder einzudämmen.
So nach deinen Angaben bin ich nicht überzeugt das der Adapter defekt ist ( grüne Led blinkt weiter, also läuft der PIC und die Signalerkennung ) , aber um das wirklich genau feststellen zu können müsstest du es irgendwie schaffen den Adapter mal ein paar Tage mit USB zu betreiben. Dazu müsstest einen Testraspi haben und diesen mit Wlan verbinden und dann ganz normal den Adapter an USB anhängen.
Wenn dann alles funktioniert ist es die Funkstrecke mit dem Wemos, gehts immer noch nicht zufriedenstellen ist es der Adapter. ich habe mit diesem Wemos+Antenne (https://de.aliexpress.com/item/32909297583.html?spm=a2g0o.productlist.0.0.6062181bQUeDlg&algo_pvid=c7499575-f900-4c2e-8bf3-8e2e76972e3b&algo_expid=c7499575-f900-4c2e-8bf3-8e2e76972e3b-0&btsid=0b0a556316157520507755135e09e1&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_) getestet und sehr gute Ergebnisse erzielt. Ich habe beim Wemos Mini festgestellt ( bei den neuen, die alten waren besser ), dass schon Personen die sich im Raum bewegen die Feldstärke beeinflussen und auch sonst das Signal nicht konstant bleibt. Unterschreitet die Feldstärke dann den kritischen Wert bricht die Übertragung zusammen, wo dann meist eine Dämon restart notwendig wird damit dieser wieder synchronisiert. Ich habe den Alpha Adapter der noch handgefädelt war ein Jahr über Wifi betrieben und dieser war bei gutem RSSI stabil.
Auch beim Wemos Mini kannst einen Draht mit etwa 6 cm anlöten, dazu musst du allerdings die 2. Leiterbahn zum Chip aufkratzen, daduch wird die integrierte Antenne deaktivert und auf der Seite zum Chip wird der Draht aufgelötet. Das steigert sofort den RSSI Wert, aber externe Antenne ist noch weit besser.
LG
Okay, sorry, dann habe ich das falsch verstanden bzw. in den falschen Hals bekommen.
Entschuldigung hierfür!
Ich teste gerade nochmal mit anderen Positionen, habe jetzt 75% Wifi.
Mal sehen.
Hab hier noch einen Pro liegen, den ich auch testen kann.
Danke Reinhard für den Adapter. Da habt ihr tolle Arbeit geleistet! Kann ihn zur Zeit leider noch nicht testen da der EBUS 300km entfernt ist.
Eine Frage zur Einrichtung: Braucht man jetzt bei Nutzung der RPI-Ports noch ttyebus wie in der Vorgänger-HW- und SW-Version?
LG, Michael
Nein, bitte keinen ttyebus mehr installieren! Aber darauf achten, das die serielle Schnittstelle bei boot Einstellungen weg ist und kein serielles loggen! Dazu unter /boot die cmdline.txt und config.txt kontrollieren.
Im Raspi-config unter Interface Options das login shell via seriell abschalten und serial port hardware aufdrehen.
LG
Hallo Zusammen,
Adapter ist angekommen und sieht super aus!
Variante: USB
Angeschlossen an: RPI3B
Also gemacht:
- ebusd aus dem Debian Repositoiry installiert
- /etc/default/ebusd: EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyUSB0 --loglevel=debug --address=ff"
- serial console off, uart on: enable_uart=1 ... dtoverlay=disable-bt
Doch leider zeigt das Log:
2021-03-15 15:01:27.682 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device /dev/ttyUSB0
2021-03-15 15:01:27.682 [main info] loading configuration files from http://ebusd.eu/config/
2021-03-15 15:01:27.731 [main info] reading templates /
2021-03-15 15:01:27.779 [main info] read templates in /
2021-03-15 15:01:27.779 [main info] reading file memory.csv
2021-03-15 15:01:27.826 [main info] successfully read file memory.csv
2021-03-15 15:01:27.826 [main info] reading file broadcast.csv
2021-03-15 15:01:27.874 [main info] successfully read file broadcast.csv
2021-03-15 15:01:27.874 [main info] read config files
2021-03-15 15:01:27.878 [bus notice] bus started with own address ff/04
2021-03-15 15:01:27.878 [main info] registering data handlers
2021-03-15 15:01:27.879 [main info] registered data handlers
2021-03-15 15:01:27.892 [bus notice] signal acquired
2021-03-15 15:01:27.930 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:28.181 [bus notice] device status: reset
2021-03-15 15:01:28.204 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:28.404 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:28.579 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:28.804 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:28.991 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:29.216 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:29.366 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:29.642 [bus error] device status: eBUS comm error: framing
2021-03-15 15:01:29.854 [bus error] device status: eBUS comm error: framing
Mit RAWLOG:
2021-03-15 15:11:37.127 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:37.327 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:37.469 [bus notice] ...<f8f28ef0f0ce8ff2f0f8f28ef0f2cef8f38ff2eecffedededcfefededeceee...
2021-03-15 15:11:37.553 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:37.839 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:37.865 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:37.947 [bus notice] ...<cefecedecefec78ef0cef0f0f0f3f38ff28ef8f0f38e8ff0f2eeceee9cceee...
2021-03-15 15:11:38.395 [bus notice] ...<e38ef0f8f0f3f3cfeecfcecececececececececeeefc8ff38ff8f2eecffece...
2021-03-15 15:11:38.578 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:38.627 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:38.665 [bus notice] ...<dedcfefecedeceeecedecefe8edec7eeceee9cceeee38ef3f0cef08ff2eece...
2021-03-15 15:11:38.840 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:38.975 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:38.997 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:39.027 [bus notice] ...<ee9cceeee38ef2f0f2f0cef3f38ff2f2eecffecedefefececeeeceeeceeece...
2021-03-15 15:11:39.090 [bus error] device status: eBUS comm error: framing
2021-03-15 15:11:39.115 [bus error] device status: eBUS comm error: framing
root@raspberrypi:~# ebusctl i
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 15
max symbol rate: 90
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
Gelbe LED ist an, Blaue LED dimmt auf hell, grüne LED blinkt so lustig vor sich hin.
Habe ich Tomaten vor den Augen oder fehlt noch was?
Meine Heizung ist BOSCH Wärmepumpe 7400 mit AWMB, angeschlossener Raumtemperaturregler geht parallel zu EBUS-Adapter problemlos.
Vielen Dank, bleibt gesund und ciao
Harvey
wenn die blaue Led normal hell ( und nicht extra hell ) ist, ist das ok!
versuche doch bitte einmal und stelle den Jumper auf "normal" ( Jumper J12 auf 2-3 ), also non-enhanced und stelle die config dazu auch um.
/etc/default/ebusd: EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d /dev/ttyUSB0 --loglevel=debug --address=ff"
also hier das enh: entfernen und berichte nochmals.
Ansonsten wird das Bussignal ja erkannt, aber außer dem Adapter selbst wird kein anderes Gerät gefunden. Dein Bosch Gerät ist mir unbekannt und kann daher nichts dazu sagen, aber wenns einen eBus hat sollte das schon klappen.
Zitat von: harvey637 am 15 März 2021, 15:26:18
Meine Heizung ist BOSCH Wärmepumpe 7400 mit AWMB, angeschlossener Raumtemperaturregler geht parallel zu EBUS-Adapter problemlos.
bist du denn sicher, dass die WP wirklich eine eBUS Schnittstelle hat?
Denn das hier
Zitat von: harvey637 am 15 März 2021, 15:26:18
2021-03-15 15:11:37.469 [bus notice] ...<f8f28ef0f0ce8ff2f0f8f28ef0f2cef8f38ff2eecffedededcfefededeceee...
sieht so ganz und gar nicht nach eBUS Traffic aus...
EDIT: laut Installationsanleitung hat diese WP einen CAN-, einen MOD-, und einen EMS-Bus, aber keinen eBUS.
Hi,
Ich habe gestern meinen Ebus 3.0 Adapter bekommen. Vielen Dank an das ganze Team, und insbesondere an Reinhart.
Leider habe ich ein paar Probleme mit der Inbetriebnahme und würde mich freuen wenn jemand dabei helfen könnte.
Meine Anlage besteht aus Vaillant EcoVIT VKK IT 286/2 und VKK SWE 366/4, mit VR6112 Mischer und VRC430 Thermostat + AussentemperaturSonde (Referenz unbekannt)
ebusd läuft mit
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:192.168.xxx.yyy:9999 --loglevel=debug --address=ff --mqtthost=192.168.xxx.zzz --mqttport=1883 --mqttuser=******* --mqttpass=*********** --mqtttopic=ebus --mqttjson"
Über MQTT bekomme ich nur Nachrichten dieser Art::
ebus/global/version "ebusd 21.2.p20210315"
ebus/global/running true
ebus/global/scan "running"
ebus/global/updatecheck "revision v21.2 available"
ebus/global/signal true
ebus/scan.50/ {
"MF": {"value": "Vaillant"},
"ID": {"value": "V6100"},
"SW": {"value": "0211"},
"HW": {"value": "1902"}}
ebus/broadcast/vdatetime {
"time": {"value": "09:17:22"},
"date": {"value": "16.03.2021"}}
ebus/broadcast/outsidetemp {
"temp2": {"value": 4.938}}
"0": {"name": "error", "value": null},
"1": {"name": "error", "value": null},
"2": {"name": "error", "value": null},
"3": {"name": "error", "value": null},
"4": {"name": "error", "value": null}}
ebus/global/uptime 3168
ebus/broadcast/vdatetime {
"time": {"value": "09:17:22"},
"date": {"value": "16.03.2021"}}
"0": {"name": "error", "value": null},
"1": {"name": "error", "value": null},
"2": {"name": "error", "value": null},
"3": {"name": "error", "value": null},
"4": {"name": "error", "value": null}}
ebus/global/uptime 3184
ebus/global/scan "finished"
"0": {"name": "error", "value": null},
"1": {"name": "error", "value": null},
"2": {"name": "error", "value": null},
"3": {"name": "error", "value": null},
"4": {"name": "error", "value": null}}
ebus/broadcast/outsidetemp {
"temp2": {"value": 4.938}}
Im Logfile sind viele Fehler:
2021-03-16 09:25:39.360 [update info] received MS cmd: 1008b5040100 / 0a00421205ffffffff2005
2021-03-16 09:25:39.360 [update notice] received unknown MS cmd: 1008b5040100 / 0a00421205ffffffff2005
2021-03-16 09:25:39.580 [update info] received BC cmd: 10feb505020400
2021-03-16 09:25:39.581 [update notice] received unknown BC cmd: 10feb505020400
2021-03-16 09:25:41.354 [update info] received MS cmd: 1050b5040126 / 070202002b014701
2021-03-16 09:25:41.354 [update notice] received unknown MS cmd: 1050b5040126 / 070202002b014701
2021-03-16 09:25:41.612 [update info] received MS cmd: 1050b5040118 / 06262500500215
2021-03-16 09:25:41.612 [update notice] received unknown MS cmd: 1050b5040118 / 06262500500215
2021-03-16 09:25:43.417 [update info] received MS cmd: 1050b503020003 / 0affffffffffffffffffff
2021-03-16 09:25:43.417 [update notice] received unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2021-03-16 09:25:43.646 [update info] received MS cmd: 1050b509040e010000 / 00
2021-03-16 09:25:43.646 [update notice] received unknown MS cmd: 1050b509040e010000 / 00
2021-03-16 09:25:43.911 [update info] received MS cmd: 1050b509040e200000 / 00
2021-03-16 09:25:43.911 [update notice] received unknown MS cmd: 1050b509040e200000 / 00
2021-03-16 09:25:44.171 [update info] received MS cmd: 1008b5100900004c6effff44ff00 / 0101
2021-03-16 09:25:44.172 [update notice] received unknown MS cmd: 1008b5100900004c6effff44ff00 / 0101
2021-03-16 09:25:44.410 [update info] received MS cmd: 1050b505021800 / 00
2021-03-16 09:25:44.410 [update notice] received unknown MS cmd: 1050b505021800 / 00
2021-03-16 09:25:45.419 [update info] received MS cmd: 1050b505023001 / 0101
2021-03-16 09:25:45.419 [update notice] received unknown MS cmd: 1050b505023001 / 0101
2021-03-16 09:25:47.437 [update info] received MS cmd: 1050b503020001 / 0affffffffffffffffffff
2021-03-16 09:25:47.438 [update notice] received read mc currenterror QQ=10: -;-;-;-;-
2021-03-16 09:25:47.705 [update info] received MS cmd: 1008b5110101 / 0954ff2005004e0000ff
2021-03-16 09:25:47.705 [update notice] received unknown MS cmd: 1008b5110101 / 0954ff2005004e0000ff
2021-03-16 09:25:49.045 [main debug] performing regular tasks
2021-03-16 09:25:49.045 [bus info] scan 08 cmd: ff08070400
2021-03-16 09:25:49.426 [update info] received MS cmd: 1050b505053c3f014701 / 00
2021-03-16 09:25:49.426 [update notice] received unknown MS cmd: 1050b505053c3f014701 / 00
2021-03-16 09:25:51.417 [update info] received MS cmd: 1050b5040118 / 062625004f0215
2021-03-16 09:25:51.417 [update notice] received unknown MS cmd: 1050b5040118 / 062625004f0215
2021-03-16 09:25:52.059 [mqtt debug] publish ebus/global/uptime 3760
2021-03-16 09:25:53.476 [update info] received MS cmd: 1050b503020003 / 0affffffffffffffffffff
2021-03-16 09:25:53.476 [update notice] received unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2021-03-16 09:25:53.721 [update info] received MS cmd: 1050b509040e010000 / 00
2021-03-16 09:25:53.721 [update notice] received unknown MS cmd: 1050b509040e010000 / 00
2021-03-16 09:25:53.969 [update info] received MS cmd: 1050b509040e200000 / 00
2021-03-16 09:25:53.969 [update notice] received unknown MS cmd: 1050b509040e200000 / 00
2021-03-16 09:25:54.262 [update info] received MS cmd: 1008b5100900004c6effff44ff00 / 0101
2021-03-16 09:25:54.263 [update notice] received unknown MS cmd: 1008b5100900004c6effff44ff00 / 0101
2021-03-16 09:25:54.501 [update info] received MS cmd: 1050b505021800 / 00
2021-03-16 09:25:54.501 [update notice] received unknown MS cmd: 1050b505021800 / 00
2021-03-16 09:25:55.506 [update info] received MS cmd: 1050b505023001 / 0101
2021-03-16 09:25:55.506 [update notice] received unknown MS cmd: 1050b505023001 / 0101
Nach meinem Verständnis fehlen da ein paar CSV-Dateien.
Unklar ist mir wie ich das beheben kann.
Dank im Voraus
Gruss
Michael
Heute nacht ist er wieder ausgefallen.
WiFi ist bei 75% und stabil, sehe ich auch in meinem Unifi Controller.
Wemos meldet:
Chip ID: 00764dcf
Hostname: ebus3
Up time: 25161
Free heap: 34920
ebusd connected: no
eBUS signal: no signal
Nach 3x Reboot geht es wieder
Allerdings gehen jetzt wieder ein paar GETs nicht :(
@Mitch
ich nehme an du hast den Adapter von John bekommen, nimm bitte per PN mit John Kontakt auf ob er noch welche Adapter hat und ihr einen Tausch vereinbaren könnt!
Musst aber schnell sein, denn diese Lieferung geht zur Neige!
LG
Hi,
vielen Dank für eure Hilfe!
Wahrscheinlich bin ich nur von der VVielzahl an verschiedenen Bezeichnungen für das Bussystem verwirrt worden, aber es ist wohl wirklich ein EMSBUS und kein E-BUS :-(
Warum muss auch JEDER Hersteller was anderes verwenden und sich dazu ständig neue Namen ausdenken .... grrrrrr
Daher habe ich einen Adapter 3.0 Variante USB übrig, den ich gerne zum Verkauf anbiete. Der erste gewinnt, bitte Versand einrechnen, danke.
Bleibt gesund und ciao
Harvey
Zitat von: Scooby am 16 März 2021, 09:29:12
Hi,
Ich habe gestern meinen Ebus 3.0 Adapter bekommen. Vielen Dank an das ganze Team, und insbesondere an Reinhart.
Leider habe ich ein paar Probleme mit der Inbetriebnahme und würde mich freuen wenn jemand dabei helfen könnte.
Meine Anlage besteht aus Vaillant EcoVIT VKK IT 286/2 und VKK SWE 366/4, mit VR6112 Mischer und VRC430 Thermostat + AussentemperaturSonde (Referenz unbekannt)
Nach meinem Verständnis fehlen da ein paar CSV-Dateien.
Unklar ist mir wie ich das beheben kann.
Das ist soweit in Ordnung, aber du hast recht es fehlen die CSV. Poste bitte einmal "ebusctl i" in der Console!
Es herrscht hier leider immer wieder das Missverständnis, dass der Adapter nun hunderte Messdaten liefert. Das tut er, aber nur auf Anfrage!
Bei einem typischen ESP8266 wie Sonoff oder ähnlichen mit Tasmota oder ESPEasy Software läßt sich ja die "Telemetry Period" einstellen. Das ist ebenfalls ein Timer, der dann in diesen Zeitabständen Messages erzeugt und die Messdaten übermittelt.
Du musst dir also einen Timer definieren, der zB: alle 10 Minuten die Messwerte holt die du wünschst. Du kannst auch mehrere Timer definieren, die dann als Beispiel nur 2x täglich Werte abholen, wie Wasserdruck oder Zählerstände etc. Die wenigen Messdaten die jetzt schon kommen sind Broadcasts, die kommen auch ohne Timer!
define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/bai/WaterPressure/get;;\
set ebusMQTT publish ebusd/bai/FlowTemp/get;;\
set ebusMQTT publish ebusd/bai/ReturnTemp/get;;\
set ebusMQTT publish ebusd/bai/FanSpeed/get;;\
set ebusMQTT publish ebusd/bai/WPPWMPower/get;;\
set ebusMQTT publish ebusd/bai/Status02/get;;\
set ebusMQTT publish ebusd/bai/HcHours/get;;\
set ebusMQTT publish ebusd/bai/HwcStarts/getMuster einer zeitgesteuerten Abfrage, die alle 10 Minuten Daten abholt.
Die Namen die hier verwendet wurden, kannst du aus den entsprechenden csv entnehmen die geladen wurden.
Daher musst du zuerst einmal checken warum die nicht geladen werden, daher die "ebusctl i".
Das was du jetzt als Fehler festgestellt hast ( im letzten Log ) , sind alles Messdaten die jedoch noch nicht dekodiert wurden weil offensichtlich eine csv fehlt ( Calormatic 430 ? ). So sehen die eigentlichen Rohdaten aus.
Ich hänge dir hier so eine csv ( 430 ) an, damit du einmal siehst was da alles an Daten vorhanden sind und genau diese csv sollte auch bei dir geladen werden.
LG
Reinhart
Zitat von: harvey637 am 16 März 2021, 12:12:07
Hi,
vielen Dank für eure Hilfe!
Wahrscheinlich bin ich nur von der VVielzahl an verschiedenen Bezeichnungen für das Bussystem verwirrt worden, aber es ist wohl wirklich ein EMSBUS und kein E-BUS :-(
Warum muss auch JEDER Hersteller was anderes verwenden und sich dazu ständig neue Namen ausdenken .... grrrrrr
Daher habe ich einen Adapter 3.0 Variante USB übrig, den ich gerne zum Verkauf anbiete. Der erste gewinnt, bitte Versand einrechnen, danke.
Bleibt gesund und ciao
Harvey
oh ja das ist ein leidiges Problem, denke mal wie das mit Can Bus im Auto war, jeder kocht halt sein eigenes Süppchen! Das gleiche gilt ja auch im Haushalt wie die Geräte kommunizieren, jeder meint sein Protokoll sei der Standard. Oft sind auch die Anforderungen verschieden.
Du wirst den sofort verkaufen können, mach aber bitte am Marktplatz einen Post auf, wenn er nicht schon weg ist!
LG
Hallo, ich habe meinen Adapter nun auch endlich bekommen! :)
Schickes Design auf jeden Fall! 👍
Jetzt habe ich gerade mal meine Therme (Vaillant atmotec exclusive) geöffnet und gesehen, dass dort bereits der Raumtemperaturregler am eBUS hängt (siehe Bild).
Kann ich den eBUS Adapter einfach zusätzlich dort anschließen oder muss ich erst den Temperaturregler trennen, wenn ich den Adapter verwenden will?
ja, einfach parallel dazu klemmen!
LG
Da ich des Öfteren gefragt werde wie denn das mit der Konsole geht.
Das ist eine SSH Verbindung zu eurem Raspi wo der Dämon installiert ist! Von dieser Konsole könnt ihr dann Kommandos absetzen um zu testen und probieren. Siehe Bild 1 console.jpg.
Es kann jeder beliebige SSH Client verwendet werden, der bekannteste ist wohl Putty (https://www.putty.org/). Nach der Installation mit diesem eine Verbindung einrichten und das wars ( Bild 2 ) !
Ebenso taucht oft die Frage auf: ich habe einen Adapter nur für USB, kann ich den erweitern für WIFI?
Ja, einfach einen Wemos (https://de.aliexpress.com/item/32630518881.html?spm=a2g0o.productlist.0.0.43b55dcdoJPlrp&algo_pvid=3af6f49c-2e4a-494c-930f-cb04d6e09c16&algo_expid=3af6f49c-2e4a-494c-930f-cb04d6e09c16-1&btsid=0bb0623e16158974979787698e6cf6&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_) bestellen, diesen mit esp3 flashen (https://github.com/john30/ebusd-esp), die Buchsenleisten am Adapter einlöten, den Wemos (https://de.aliexpress.com/item/32630518881.html?spm=a2g0o.productlist.0.0.43b55dcdoJPlrp&algo_pvid=3af6f49c-2e4a-494c-930f-cb04d6e09c16&algo_expid=3af6f49c-2e4a-494c-930f-cb04d6e09c16-1&btsid=0bb0623e16158974979787698e6cf6&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_) draufstecken und die Config anpassen. Das gleiche gilt auch für eine Erweiterung mit dem W5500 (https://de.aliexpress.com/item/32598706957.html?spm=a2g0o.productlist.0.0.62e71143J2oJJL&algo_pvid=43110e98-5a26-4a1e-a5c0-a71dd15ac4aa&algo_expid=43110e98-5a26-4a1e-a5c0-a71dd15ac4aa-4&btsid=0bb0623e16158975579928488e6cf6&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_).
LG
Zitat von: schneivo am 16 März 2021, 13:09:19
Hallo, ich habe meinen Adapter nun auch endlich bekommen! :)
Schickes Design auf jeden Fall! 👍
Jetzt habe ich gerade mal meine Therme (Vaillant atmotec exclusive) geöffnet und gesehen, dass dort bereits der Raumtemperaturregler am eBUS hängt (siehe Bild).
Kann ich den eBUS Adapter einfach zusätzlich dort anschließen oder muss ich erst den Temperaturregler trennen, wenn ich den Adapter verwenden will?
einfach dazu klemmen
Moin
Korrigiert mich bitte. Aber der Regler muss sogar dran bleiben. Sonst kann der Daemon sich gar nicht das passende CSV holen!?
russ Christoph
Zitat von: Reinhart am 16 März 2021, 12:17:24
Das ist soweit in Ordnung, aber du hast recht es fehlen die CSV. Poste bitte einmal "ebusctl i" in der Console!
Es herrscht hier leider immer wieder das Missverständnis, dass der Adapter nun hunderte Messdaten liefert. Das tut er, aber nur auf Anfrage!
Bei einem typischen ESP8266 wie Sonoff oder ähnlichen mit Tasmota oder ESPEasy Software läßt sich ja die "Telemetry Period" einstellen. Das ist ebenfalls ein Timer, der dann in diesen Zeitabständen Messages erzeugt und die Messdaten übermittelt.
Du musst dir also einen Timer definieren, der zB: alle 10 Minuten die Messwerte holt die du wünschst. Du kannst auch mehrere Timer definieren, die dann als Beispiel nur 2x täglich Werte abholen, wie Wasserdruck oder Zählerstände etc. Die wenigen Messdaten die jetzt schon kommen sind Broadcasts, die kommen auch ohne Timer!
define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/bai/WaterPressure/get;;\
set ebusMQTT publish ebusd/bai/FlowTemp/get;;\
set ebusMQTT publish ebusd/bai/ReturnTemp/get;;\
set ebusMQTT publish ebusd/bai/FanSpeed/get;;\
set ebusMQTT publish ebusd/bai/WPPWMPower/get;;\
set ebusMQTT publish ebusd/bai/Status02/get;;\
set ebusMQTT publish ebusd/bai/HcHours/get;;\
set ebusMQTT publish ebusd/bai/HwcStarts/get
Muster einer zeitgesteuerten Abfrage, die alle 10 Minuten Daten abholt.
Die Namen die hier verwendet wurden, kannst du aus den entsprechenden csv entnehmen die geladen wurden.
Daher musst du zuerst einmal checken warum die nicht geladen werden, daher die "ebusctl i".
Das was du jetzt als Fehler festgestellt hast ( im letzten Log ) , sind alles Messdaten die jedoch noch nicht dekodiert wurden weil offensichtlich eine csv fehlt ( Calormatic 430 ? ). So sehen die eigentlichen Rohdaten aus.
Ich hänge dir hier so eine csv ( 430 ) an, damit du einmal siehst was da alles an Daten vorhanden sind und genau diese csv sollte auch bei dir geladen werden.
LG
Reinhart
Hi Reinhart,
Vielen Dank für die sehr ausführliche Erklärung.
Hier ist das Ergebnis von ebusctl i:
~ $ ebusctl i
version: ebusd 21.2.p20210315
update check: revision v21.2 available
access: *
signal: acquired
symbol rate: 26
max symbol rate: 197
reconnects: 8
masters: 3
messages: 14
conditional: 0
poll: 0
update: 4
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11
address 10: master #2
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0211;HW=1902"
address ff: master #25, ebusd
Tatsächlich fehlt hier der CalorMATIC VRC430 bei Adresse 15 ... Dennoch ist das Teil angeschlossen und funktionniert.
Hast du eventuell eine Idee woran das liegen kann ?
Gruß
Michael
Habe auch die CalorMATIC VRC430.
Die wird leider nur jedes zweite Mal gefunden.
Starte mal den ebusd Service neu und probiere es wieder. Gerne auch ein paar Mal.
Zitat von: Reinhart am 16 März 2021, 13:16:15
ja, einfach parallel dazu klemmen!
LG
Zitat von: john30 am 16 März 2021, 13:43:54
einfach dazu klemmen
Danke euch! Werde ich machen.
Noch eine Frage zum Thema Stromversorgung: Gibt es da irgendwelche Mindestanforderungen? Ein Handy-Netzteil, mit dem ein Raspberry Pi läuft müsste reichen oder?
Zitat von: Mitch am 16 März 2021, 16:25:29
Habe auch die CalorMATIC VRC430.
Die wird leider nur jedes zweite Mal gefunden.
Starte mal den ebusd Service neu und probiere es wieder. Gerne auch ein paar Mal.
Ja stimmt, bei einem scan ist das Teil mal kurz aufgetaucht.
Aber ich muss einen Weg finden den ebusd zuverlässig zu starten.
Gibt's eine möglichkeit mit ebusd eine CSV explizit zu laden ?
Sowas wie:
load "vaillant/15.430.csv" ?
@Scooby
Eventuell die latency noch etwas höher setzen?
Ohne bekomme ich bei mir meine Geräte fast gar nicht identifiziert.
Zitat von: Scooby am 16 März 2021, 20:43:21
Ja stimmt, bei einem scan ist das Teil mal kurz aufgetaucht.
Aber ich muss einen Weg finden den ebusd zuverlässig zu starten.
Gibt's eine möglichkeit mit ebusd eine CSV explizit zu laden ?
Sowas wie:
load "vaillant/15.430.csv" ?
gleicher Fehler wie bei Mitch?
Ich stell das jetzt nach und teste das durch!
LG
Ich habe den eBUS Adapter nun zum Testen mal im Wemos-Modus an den Vaillant Temperaturregler gehängt. Das Netzteil von meinem Amazon Fire TV Stick scheint zu reichen. ;)
Eigentlich wollte ich ihn erst direkt an den eBUS der Therme anschließen, aber ich dachte mir, dass das ja bestimmt keine Rolle spielt, ob er nun direkt dran hängt oder am anderen Ende des Kabels, am Regler.
Am Adapter leuchtet die gelbe LED durchgehend. Die grüne LED flackert die ganze Zeit schnell in gleicher Frequenz und mit relativ geringer Helligkeit. Ab und zu blinkt sie kurz mal etwas heller auf.
Auf der Web-Oberfläche vom Wemos unter "Status" steht dauerhaft "eBUS signal: no signal". Das ist vermutlich schlecht oder?
Könnte es sein, dass das Signal beim Regler zu schwach ist und ich den Adapter daher doch lieber direkt am eBUS der Therme anschließen sollte?
Den ebus-daemon habe ich noch nicht eingerichtet, weshalb ich aktuell nur die Infos aus der Wemos Web-Oberfläche habe.
ohne Dämon bekommst du keinen "connect".
LG
@Mitch
@Scooby
ist euch aufgefallen, das ebusctl i sehr lange dauert? Wo kommt der Fehler, Normal Modus oder Enhanced?
LG
Zitat von: schneivo am 16 März 2021, 21:24:32
Am Adapter leuchtet die gelbe LED durchgehend. Die grüne LED flackert die ganze Zeit schnell in gleicher Frequenz und mit relativ geringer Helligkeit. Ab und zu blinkt sie kurz mal etwas heller auf.
das ist richtig so
Zitat von: schneivo am 16 März 2021, 21:24:32
Auf der Web-Oberfläche vom Wemos unter "Status" steht dauerhaft "eBUS signal: no signal". Das ist vermutlich schlecht oder?
ja das sollte nicht sein.
Wie ist der Wemos denn auf der Oberfläche konfiguriert? Also ist er bei eBUS RX+TX auf "Adapter 3 RX+TX" eingestellt? Falls nicht, kann er kein Signal feststellen.
Und hast Du die Stromversorgung am Wemos angelegt oder am Adapter J2?
Zitat von: schneivo am 16 März 2021, 21:24:32
Könnte es sein, dass das Signal beim Regler zu schwach ist und ich den Adapter daher doch lieber direkt am eBUS der Therme anschließen sollte?
unwahrscheinlich, sonst würde die grüne LED nicht blinken
Zitat von: hErMeS am 16 März 2021, 21:02:35
@Scooby
Eventuell die latency noch etwas höher setzen?
Ohne bekomme ich bei mir meine Geräte fast gar nicht identifiziert.
Ich habe die latency auf 40000 gestellt, jedoch ohne Verbesserung.
Zitat von: Reinhart am 16 März 2021, 21:05:13
gleicher Fehler wie bei Mitch?
Ich stell das jetzt nach und teste das durch!
Ich habe nicht so richtig verfolgt was bei Mitch der Fehler war, aber bei mit ist klar der Fall, daß der VRC430 im scan nicht (oder nur äußerst selten) erscheint und deshalb die CSV nicht geladen wird.
Zitat von: Reinhart am 16 März 2021, 21:27:50
@Mitch
@Scooby
ist euch aufgefallen, das ebusctl i sehr lange dauert? Wo kommt der Fehler, Normal Modus oder Enhanced?
LG
Ja "ebusctl i" und "ebusctl scan" dauern sehr lange. Kann aber leider nicht sagen ob das normal ist oder nicht, da ich ertst seit gestern erfahrung mit dem ebus habe :)
Ich benutze den Enhanced Modus.
I habe gerade udp und tcp getestet, aber in diesem Modus findet der ebusd nichts:
~ $ ebusctl scan
empty
~ $ ebusctl scan result
done
~ $ ebusctl scan 15
ERR: no signal
~ $ ebusctl i
version: ebusd 21.2.p20210315
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 12
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
Gruß
Michael
Zitat von: Reinhart am 16 März 2021, 21:26:42
ohne Dämon bekommst du keinen "connect".
LG
Zitat von: john30 am 16 März 2021, 21:30:19
das ist richtig so
ja das sollte nicht sein.
Wie ist der Wemos denn auf der Oberfläche konfiguriert? Also ist er bei eBUS RX+TX auf "Adapter 3 RX+TX" eingestellt? Falls nicht, kann er kein Signal feststellen.
Und hast Du die Stromversorgung am Wemos angelegt oder am Adapter J2?
unwahrscheinlich, sonst würde die grüne LED nicht blinken
Inzwischen läuft es. :)
In der Weboberfläche steht jetzt:
ebusd connected: yes (inactive)
eBUS signal: acquired
eBUS initial signal: yesIch dachte halt, dass der Status in der Web-Oberfläche anzeigt, dass es ein Problem mit der Verbindung zum eBUS des Reglers gibt, aber letztendlich lag es einfach nur daran, dass ebusd noch nicht lief. :D
Damit hatte ich zuerst auch ein paar Startschwierigkeiten.
Zum Testen habe ich eine VM mit Ubuntu aufgesetzt und dort dann wie im Wiki beschrieben (https://github.com/john30/ebusd/wiki/1.-Build-and-install) ebusd installiert. Wobei ich alle Befehle mit "sudo" ausgeführt habe und vermute, dass meine Problem eventuell dadurch gekommen sind.
Jedenfalls habe ich nach der Installation noch den automatischen Start aktiviert (ebenfalls wie im Wiki beschrieben) und danach dann einfach folgendes Kommando ausgeführt (natürlich habe ich die korrekte IP vom Wemos eingetragen ;)):
sudo ebusd --scanconfig --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ffIn den logs unter
/var/log/ebusd.log kam allerdings ständig folgende Fehlermeldung:
2021-03-17 00:53:12.718 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2021-03-17 00:53:12.718 [bus notice] device invalidDann habe ich mal ebusd im Vordergrund mit der Flag -f gestartet, also so:
sudo ebusd --scanconfig --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ff -f
Und siehe da, die Verbindung klappt einwandfrei! :)
Im System-Monitor von Ubuntu sehe ich nun allerdings 2 laufende ebusd Prozesse. Einmal den mit meinen Optionen und der zweite ist:
/usr/bin/ebusd --scanconfigIch schätze mal, dass das der automatisch gestartete Prozess ist und der ist wohl auch verantwortlich für die oben besagten logs.
Wo die logs von meinem anderen ebusd hingeschrieben werden, weiß ich nicht, aber die Ausgaben kann ich ja auch direkt im Terminal sehen.
Ich bin auf jeden Fall schon mal sehr froh, dass das mit der Verbindung zum Adapter alles zu funktionieren scheint. :)
Als nächstes versuche ich herauszufinden wie ich Werte der Therme auslesen kann.
Edit:
Hier noch die Ausgabe von
ebusctl info:
tester@tester-VirtualBox:~$ ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
update check: revision v21.2 available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 146
min arbitration micros: 2
max arbitration micros: 25
min symbol latency: 9
max symbol latency: 48
reconnects: 0
masters: 3
messages: 232
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address ff: master #25, ebusd
du musst in der config ganz oben die hier rot dargestellte Zeile entfernen, bzw. mit Raute sperren!
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# EBUSD_OPTS="--scanconfig"
LG
ich habe gestern noch den (WIFI) Fehler von Mitch in Scooby nachstellen können und wir analysieren gerade woher das kommt.
Der USB/RPI Betrieb funktioniert und ist davon nicht betroffen.
John ist allerdings auswärts und kann erst am Wochenende genauer drüber schauen, bitte um etwas Geduld!
LG
Reinhart
Danke Reinhart!
Ich danke ebenso Reinhart. Keine Eile :)
Ich wollte nur noch mitteilen (falls das einen Einfluss haben sollte) daß bei mir der VRC430 mit 10m Kabel am Bus hängt, was möglicherweise Latenz und Signalschwäche mit sich zieht.
Gruß
Michael
Zitat von: Reinhart am 17 März 2021, 09:57:56
du musst in der config ganz oben die hier rot dargestellte Zeile entfernen, bzw. mit Raute sperren!
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# EBUSD_OPTS="--scanconfig"
LG
Jo danke, ich hatte gestern noch ein bisschen weiter herumprobiert und bin dann auch auf diese Config gestoßen womit es dann auch mit dem Autostart lief. :)
Danach kam dann das nächste Problem. Der Raumtemperaturregler antwortete bei fast allen Anfragen mit:
ERR: invalid position in decodeIch bin dann auf diesen Github-Issue gestoßen: https://github.com/john30/ebusd/issues/196
Dort hatte der User sagittarius0815 das gleiche Problem und meinte, dass die CSV vom VRT 370 mit dem VRT 350 funktionierte.
Das hat bei mir dann auch geklappt. Vielleicht sollte man die CSVs mal updaten.
Mit der neuen CSV konnte ich dann auch verschiedene Werte mit folgenden Befehlen erfolgreich ändern:
# Datum ändern
ebusctl w -c 350 Date 17.03.2021
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Date
# Zeit ändern
ebusctl w -c 350 Time 14:15:00
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Time
# Tag Modus einschalten
ebusctl w -c 350 Hc1OPMode on
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Hc1OPMode
# Sommer Modus einschalten
ebusctl w -c 350 Hc1OPMode summer
# Prüfen ob es geklappt hat
ebusctl r -c 350 -f Hc1OPModeIch bin auf jeden Fall beeindruckt wie gut das alles läuft! :)
Als nächstes werde ich dann mit ebusd auf einen Raspberry Pi umziehen und versuchen die Werte in einem UI anzuzeigen und zu bearbeiten.
Edit:
Ach so, falls noch jemand Probleme mit dem VRT 350 haben sollte, hier nochmal meine Schritte:
1. ebusd-configuration Repository herunterladen
git clone https://github.com/john30/ebusd-configuration.git2. den Inhalt aus dem Ordner
ebusd-configuration/ebusd-2.1.x/de nach
/etc/ebusd kopieren
cd Downloads/ebusd-configuration/ebusd-2.1.x/de
sudo cp -r * /etc/ebusd/3. ein Backup der VRT 350 CSV erstellen und sie dann durch die VRT 370 CSV austauschen
cd /etc/ebusd/vaillant/
sudo cp 15.350.csv 15.350.csv_BACKUP
sudo rm 15.350.csv
sudo cp 15.370.csv 15.350.csv4. die ebusd Start-Config (
/etc/default/ebusd) anpassen, damit sie die lokale Config lädt
EBUSD_OPTS="--scanconfig --configpath=/etc/ebusd/ --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ff"5. die ebusd Configs neu laden
ebusctl reload
danke für deinen ausführlichen Hinweise!
daran denken, wenn alles läuft den --loglevel wieder entfernen, ist sonst unnützer Ballast.
LG
zum Wifi Thema:
es scheint in der Kommunikation zwischen ebusd und dem Wemos (und evtl. dann zum PIC) ein Timingproblem zu geben. Das muss ich erst noch genau analysieren und komme frühestens am Wochenende dazu.
Bis dahin schafft ein extra "--latency=80" in den EBUSD_OPTS anscheinend Abhilfe.
Danke @Reinhart, dass ich Deine Anlage zur ersten Analyse nutzen durfte!
Hallo.
Habe meine LAN-Variante auch vorgestern dankend erhalten. Schön kompakt das kleine Scheißerchen ;D
Eine Frage: Die Jumper-Config im Wiki ist für die LAN-Kombi verifiziert (J1=RPI; J4=USB; J12=5-6)? Ich meine ja (Foto und 3D-Bild decken sich damit). Doch bevor ich Spannung anlege, frage ich lieber sicherheitshalber, weil bei mir noch J1=USB gesteckt ist. Könnte ja sein, dass bei der Menge an Arbeit eine Kleinigkeit durchgerutscht ist (wenn auch unwahrscheinlich :) ).
Viele Grüße
rob
Hallo!
Bin gerade bei der Inbetriebname von meinem Adapter (direkt auf RPi aufgesteckt) für meine Luftwärmepumpe AroTherm Split VWL75 mit Systemregler VCR700.
Ich bekomme aber nur ein paar Daten.
Laut meinen Daemon habe ich sehr viele "received unknown MS cmd".
Desweiteren lese ich auch, dass er die Config 76 nicht hat.
Wenn ich "ebusctl i" ausführe dann sehe ich, dass ich kein Signal habe obwohl ein paar Daten reinkommen.
pi@raspberrypi4host:~ $ ebusctl i
version: ebusd 21.2.v21.2
update check: OK
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
pi@raspberrypi4host:~ $ sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name
2021-03-18 10:01:57.457 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device /dev/ttyAMA0
2021-03-18 10:01:57.703 [bus notice] bus started with own address 31/36
2021-03-18 10:01:57.710 [mqtt notice] connection established
2021-03-18 10:01:57.751 [bus error] device status: unexpected available enhanced following byte 1
2021-03-18 10:01:57.751 [bus notice] signal acquired
2021-03-18 10:01:58.344 [bus notice] device status: reset
2021-03-18 10:01:58.925 [bus notice] new master 71, master count 2
2021-03-18 10:01:58.985 [bus notice] new master 03, master count 3
2021-03-18 10:01:58.985 [update notice] received unknown MS cmd: 7108b5110107 / 0a16ce0001083f00000000
2021-03-18 10:02:02.414 [update notice] received unknown MS cmd: 7108b5110107 / 0a16ce0001083f00000000
2021-03-18 10:02:04.152 [update notice] received unknown MS cmd: 7108b5120e11cb019201b601d1011500040000 / 020237
2021-03-18 10:02:05.546 [bus notice] new master 10, master count 4
2021-03-18 10:02:05.602 [update notice] received unknown MS cmd: 1008b5110101 / 0939320080ffff0100ff
2021-03-18 10:02:05.855 [update notice] received unknown MS cmd: 7108b5110107 / 0a16ce0001083f00000000
2021-03-18 10:02:05.907 [update notice] received unknown MS cmd: 1076b5110101 / 0938329404ff5f0000ff
2021-03-18 10:02:06.177 [update notice] received unknown MS cmd: 1076b512030f0201 / 07fd0200c20115ff
2021-03-18 10:02:06.445 [update notice] received unknown MS cmd: 1008b51009000036ffffff060000 / 0101
2021-03-18 10:02:06.709 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2021-03-18 10:02:07.887 [bus notice] scan 08: ;Vaillant;HMU00;0405;5103
2021-03-18 10:02:07.887 [update notice] store 08 ident: done
2021-03-18 10:02:07.887 [update notice] sent scan-read scan.08 QQ=31: Vaillant;HMU00;0405;5103
2021-03-18 10:02:07.887 [bus notice] scan 08: ;Vaillant;HMU00;0405;5103
2021-03-18 10:02:08.138 [main notice] read common config file vaillant/scan.csv
2021-03-18 10:02:08.199 [main notice] read common config file vaillant/general.csv
2021-03-18 10:02:08.254 [main notice] read common config file vaillant/broadcast.csv
2021-03-18 10:02:08.313 [main notice] read scan config file vaillant/08.hmu.csv for ID "hmu00", SW0405, HW5103
2021-03-18 10:02:08.427 [main notice] found messages: 61 (0 conditional on 0 conditions, 0 poll, 10 update)
2021-03-18 10:02:08.645 [update notice] sent unknown MS cmd: 3108b5090124 / 09003231313933343030
2021-03-18 10:02:08.834 [update notice] sent scan-read scan.08 id QQ=31:
2021-03-18 10:02:09.020 [update notice] sent scan-read scan.08 id QQ=31:
2021-03-18 10:02:09.208 [update notice] sent scan-read scan.08 id QQ=31: 21;19;34;0010021619;1610;005437;N1
2021-03-18 10:02:09.208 [bus notice] scan 08: ;21;19;34;0010021619;1610;005437;N1
2021-03-18 10:02:11.413 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2021-03-18 10:02:11.413 [update notice] store 15 ident: done
2021-03-18 10:02:11.413 [update notice] sent scan-read scan.15 QQ=31: Vaillant;70000;0613;6903
2021-03-18 10:02:11.413 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2021-03-18 10:02:11.601 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313933343030
2021-03-18 10:02:11.787 [update notice] sent scan-read scan.15 id QQ=31:
2021-03-18 10:02:11.976 [update notice] sent scan-read scan.15 id QQ=31:
2021-03-18 10:02:12.164 [update notice] sent scan-read scan.15 id QQ=31: 21;19;34;0020266797;0082;045585;N0
2021-03-18 10:02:12.164 [bus notice] scan 15: ;21;19;34;0020266797;0082;045585;N0
2021-03-18 10:02:12.349 [main notice] read scan config file vaillant/15.700.csv for ID "70000", SW0613, HW6903
2021-03-18 10:02:12.410 [main notice] found messages: 481 (0 conditional on 0 conditions, 0 poll, 10 update)
2021-03-18 10:02:12.734 [update notice] received read hmu State QQ=71: 22;206;on;8
2021-03-18 10:02:14.614 [bus notice] scan 76: ;Vaillant;VWZ00;0517;5103
2021-03-18 10:02:14.614 [update notice] store 76 ident: done
2021-03-18 10:02:14.614 [update notice] sent scan-read scan.76 QQ=31: Vaillant;VWZ00;0517;5103
2021-03-18 10:02:14.615 [bus notice] scan 76: ;Vaillant;VWZ00;0517;5103
2021-03-18 10:02:14.812 [update notice] sent unknown MS cmd: 3176b5090124 / 09003231313933363030
2021-03-18 10:02:15.046 [main error] unable to load scan config 76: no file from vaillant with prefix 76 found
2021-03-18 10:02:15.046 [main error] scan config 76: ERR: read timeout
2021-03-18 10:02:15.625 [update notice] received read hmu Status01 QQ=10: 28.5;25.0;-;-;-;on
2021-03-18 10:02:15.889 [update notice] received unknown MS cmd: 1076b5110101 / 093832a304ff5f0000ff
2021-03-18 10:02:16.149 [update notice] received unknown MS cmd: 1076b512030f0201 / 07fd0200c30115ff
2021-03-18 10:02:16.412 [update notice] received read hmu State QQ=71: 22;206;on;8
2021-03-18 10:02:16.413 [update notice] received unknown BC cmd: 10feb505025c00
2021-03-18 10:02:16.680 [update notice] received update-write hmu SetMode QQ=10: auto;27.0;-;-;0;1;1;0;0;0
2021-03-18 10:02:16.944 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2021-03-18 10:02:17.032 [bus notice] max. symbols per second: 108
2021-03-18 10:02:17.212 [update notice] received unknown MS cmd: 1076b5040100 / 0a00ffffffffffffffa304
2021-03-18 10:02:17.451 [update notice] received unknown MS cmd: 1008b507020936 / 020102
2021-03-18 10:02:17.691 [update notice] received update-read broadcast vdatetime QQ=10: 10:02:16;18.03.2021
2021-03-18 10:02:17.954 [update notice] received unknown MS cmd: 1008b5110100 / 09cc011553000900002c
2021-03-18 10:02:18.198 [update notice] received unknown MS cmd: 1076b51303040d00 / 020d00
2021-03-18 10:02:18.413 [update notice] received update-read broadcast outsidetemp QQ=10: 4.578
2021-03-18 10:02:18.647 [update notice] received update-write hmu StatusCirPump QQ=10: on
Hoffe ihr könnt mir da weiterhelfen.
Christian
Zitat von: rob am 18 März 2021, 08:47:12
Eine Frage: Die Jumper-Config im Wiki ist für die LAN-Kombi verifiziert (J1=RPI; J4=USB; J12=5-6)? Ich meine ja (Foto und 3D-Bild decken sich damit). Doch bevor ich Spannung anlege, frage ich lieber sicherheitshalber, weil bei mir noch J1=USB gesteckt ist. Könnte ja sein, dass bei der Menge an Arbeit eine Kleinigkeit durchgerutscht ist (wenn auch unwahrscheinlich :) ).
Die Jumper stehen noch von dem Test so und da wurde ja auf USB getestet. Da ich bei den UNI Varianten ohnehin nicht weiß wie sie betrieben werden laß ich die meist auf USB stecken, hat jetzt nichts mit durchgerutscht zu tun.
LG
Reinhart
@gallich
also "ebusctl i" passt nicht zu deinem Log, es wird hier nur der eigene Adapter angeführt. Außerdem hast du zweimal den Device beim Start definiert.
sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name
Die vielen "unknown" kommen weil hier keine entsprechenden csv geladen sind und daher werden die Rohdaten nicht dekodiert. Was ich im Log gesehen habe wird nur "15.700.csv" mit 481 Definitionen geladen.
Hast du wirklich die seriellen Einstellungen am Raspi gecheckt ob das alles so passt? Was hast du für einen Raspi?
LG
Zitat von: john30 am 17 März 2021, 21:28:08
zum Wifi Thema:
es scheint in der Kommunikation zwischen ebusd und dem Wemos (und evtl. dann zum PIC) ein Timingproblem zu geben. Das muss ich erst noch genau analysieren und komme frühestens am Wochenende dazu.
Bis dahin schafft ein extra "--latency=80" in den EBUSD_OPTS anscheinend Abhilfe.
Danke @Reinhart, dass ich Deine Anlage zur ersten Analyse nutzen durfte!
Danke John das du trotz deiner Abwesenheit dich der Sache so schnell angenommen hast und die ersten Analysen durchgeführt hast. Ich habe noch verschiedene Wemos getestet und das Verhalten ist eigentlich bei allen gleich bis auf unterschiedliche Feldstärken. Aktiviere ich noch zusätzlich das MQTT Protokoll versagt auch die latency=80, stelle ich MQTT ab gehts wieder tadellos.
Der Zusammenhang warum es bei einigen Anwendern trotzdem tadellos funktioniert ist mir noch nicht ganz klar, obwohl die auch MQTT nutzen.
LG
Zitat von: Reinhart am 18 März 2021, 10:43:18
...hat jetzt nichts mit durchgerutscht zu tun.
Dachte ich mir schon, sollte kein Vorwurf sein. Ich möchte halt Fehler meinerseits vermeiden.
Zitat von: Reinhart am 18 März 2021, 10:43:18
Die Jumper stehen noch von dem Test so und da wurde ja auf USB getestet.
Wenn ich den Adapter an der Therme betreibe, würde ich ihn via USB-Port mit Energie versorgen und das LAN-Kabel zum Switch ziehen (eBus-Leitung damit möglichst kurz). Ist es dann Wurscht, wie J1 gejumpert wird? USB klingt für mich zunächst einleuchtend und so hast ja auch getestet. Aber wenn RPI richtig ist, nehme ich natürlich das :)
Sorry für die doofen Fragen.
VG
rob
Zitatalso "ebusctl i" passt nicht zu deinem Log, es wird hier nur der eigene Adapter angeführt. Außerdem hast du zweimal den Device beim Start definiert.
sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name
Die vielen "unknown" kommen weil hier keine entsprechenden csv geladen sind und daher werden die Rohdaten nicht dekodiert. Was ich im Log gesehen habe wird nur "15.700.csv" mit 481 Definitionen geladen.
Hast du wirklich die seriellen Einstellungen am Raspi gecheckt ob das alles so passt? Was hast du für einen Raspi?
In der Config Datei hab ich das Device nur 1 mal drinnen.
War ein Kopierfehler von mir als ich ebusd direkt von der Kosole gestartet habe, ändert aber nichts an meinem Problem.
Habe eine Raspberry 4 und habe die seriellen Einstellungen so gemacht wie in der Anleitung steht.
Auf diesem Raspberry laufen noch andere Sache wie IoBroker mit div. Adptern, vielleicht haut mir dass irgendwo einen Hund rein.
Werde es mal mit meinem Raspberry Pi3 mit neu aufgesetztem Image versuchen.
Zitat von: Reinhart am 17 März 2021, 10:03:37
ich habe gestern noch den (WIFI) Fehler von Mitch in Scooby nachstellen können und wir analysieren gerade woher das kommt.
Der USB/RPI Betrieb funktioniert und ist davon nicht betroffen.
John ist allerdings auswärts und kann erst am Wochenende genauer drüber schauen, bitte um etwas Geduld!
LG
Reinhart
Kurze Meldung: habe mein Problem gelöst.
Ich wollte mal mit Ehernet testen und beim Jumper-umstellen fiel mir auf, daß J1 und J4 beide auf "USB" standen, anstatt RPI.
Ich hatte vor Inbetriebnahme nicht kontrolliert (hatte blind vertraut bei meiner WiFi Version).
Hauptsache es läuft nun:
$ ebusctl i
version: ebusd 21.2.p20210315
access: *
signal: acquired
symbol rate: 26
max symbol rate: 106
min arbitration micros: 4
max arbitration micros: 68
min symbol latency: 9
max symbol latency: 29
reconnects: 0
masters: 3
messages: 559
conditional: 20
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0211;HW=1902", loaded "vaillant/50.v61.mc.csv"
address ff: master #25, ebusd
Vielen Dank noch mal an alle die geholfen haben !
Zitat von: Reinhart am 16 März 2021, 12:17:24
Du musst dir also einen Timer definieren, der zB: alle 10 Minuten die Messwerte holt die du wünschst. Du kannst auch mehrere Timer definieren, die dann als Beispiel nur 2x täglich Werte abholen, wie Wasserdruck oder Zählerstände etc. Die wenigen Messdaten die jetzt schon kommen sind Broadcasts, die kommen auch ohne Timer!
define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/bai/WaterPressure/get;;\
set ebusMQTT publish ebusd/bai/FlowTemp/get;;\
set ebusMQTT publish ebusd/bai/ReturnTemp/get;;\
set ebusMQTT publish ebusd/bai/FanSpeed/get;;\
set ebusMQTT publish ebusd/bai/WPPWMPower/get;;\
set ebusMQTT publish ebusd/bai/Status02/get;;\
set ebusMQTT publish ebusd/bai/HcHours/get;;\
set ebusMQTT publish ebusd/bai/HwcStarts/get
Muster einer zeitgesteuerten Abfrage, die alle 10 Minuten Daten abholt.
Hi, ich brauche bitte noch etwas Hilfe zu diesem Thema:
ebusd schmeisst immer Fehler wenn ich versuche den Timer anzulegen:
$ ebusctl
localhost: define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/bai/WaterPressure/get;;\
set ebusMQTT publish ebusd/bai/FlowTemp/get;;\
usage: define [-r] DEFINITION
Define a new message.
-r replace an already existing definition
DEFINITION message definition to add
localhost: set ebusMQTT publish ebusd/bai/ReturnTemp/get;;\
ERR: command not found
localhost: set ebusMQTT publish ebusd/bai/FanSpeed/get;;\
set ebusMQTT publish ebusd/bai/WPPWMPower/get;;\
set ebusMQTT publish ebusd/bai/Status02/get;;\
set ebusMQTT publish ebusd/bai/HcHours/get;;\
ERR: command not found
localhost: set ebusMQTT publish ebusd/bai/HwcStarts/getERR: command not found
localhost: publish ebusd/bai/HcHours/get
ERR: command not found
localhost: publish ebus/430/HwcTempDesired/get
ERR: command not found
Was mache ich da falsch ?
Dank im voraus :)
Machst du das direkt auf der Konsole des RPi auf dem ebusd läuft ? :o
Das musst du in Fhem definieren!
Ist hier gut erklärt:
https://wiki.fhem.de/wiki/EBUS-MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2)
@Wolle02: Danke dir, hab's jetzt begriffen :D
Ich benutze nicht FHEM sondern Jeedom.
Ich versuchte zweifelhaft einen Zusammenhang zu finden und ebusd hat auch einen Befehl "define", deshalb die Verwechslung.
Ich werde das einfach mit cron machen.
;D
Ich habe heute meinen ebus-Adapter (per LAN) in Betrieb genommen.
Der ebusd (mit MQTT) ist installiert mit folgenden Optionen (port 8888 ist belegt):
EBUSD_OPTS="--port=8889 --scanconfig --accesslevel=* --latency=20000 -d enh:HeizungEBusAdapter3:9999 --address=ff"
HeizungEBusAdapter3 ist dessen IP-Adresse, sie ist erreichbar:
openhabian@openHABianDevice:~ $ ping HeizungEBusAdapter3
PING HeizungEBusAdapter3.fritz.box (192.168.178.58) 56(84) bytes of data.
64 bytes from HeizungEBusAdapter3.fritz.box (192.168.178.58): icmp_seq=1 ttl=128 time=0.414 ms
64 bytes from HeizungEBusAdapter3.fritz.box (192.168.178.58): icmp_seq=2 ttl=128 time=0.349 ms
64 bytes from HeizungEBusAdapter3.fritz.box (192.168.178.58): icmp_seq=3 ttl=128 time=0.348 ms
ebusctl info sieht für mich gut aus:
[19:03:39] root@openHABianDevice:/home/openhabian# ebusctl --port=8889 info
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 22
max symbol rate: 98
min arbitration micros: 5
max arbitration micros: 13
min symbol latency: 6
max symbol latency: 23
reconnects: 0
masters: 3
messages: 451
conditional: 16
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address ff: master #25, ebusd
Im log dest ebusd kommen andauernd Zeilen wie diese:
openhabian@openHABianDevice:~ $ tail -f /var/log/ebusd.log
2021-03-18 19:03:53.058 [main notice] found messages: 451 (16 conditional on 32 conditions, 0 poll, 10 update)
2021-03-18 19:03:55.951 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:04:02.036 [update notice] received read bai Status01 QQ=10: 49.0;44.0;4.250;-;59.0;on
2021-03-18 19:04:04.005 [update notice] received update-read broadcast vdatetime QQ=10: 19:04:04;18.03.2021
2021-03-18 19:04:04.256 [update notice] received update-write bai StatusCirPump QQ=10: on
2021-03-18 19:04:06.085 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:04:12.122 [update notice] received read bai Status01 QQ=10: 49.0;45.0;4.250;-;59.0;on
2021-03-18 19:04:14.130 [update notice] received read bai DateTime QQ=10: sync;19:04:21;-.-.-;4.250
2021-03-18 19:04:14.397 [update notice] received read bai Status02 QQ=10: auto;60;75.0;80;60.0
2021-03-18 19:04:16.175 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:04:20.179 [update notice] received read bai Status01 QQ=10: 49.0;45.0;4.250;-;59.0;on
2021-03-18 19:04:22.175 [update notice] received update-read broadcast outsidetemp QQ=10: 4.250
2021-03-18 19:04:26.269 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:04:30.315 [update notice] received read bai Status01 QQ=10: 49.0;45.0;4.250;-;59.0;on
2021-03-18 19:04:32.303 [update notice] received read bai Status02 QQ=10: auto;60;75.0;80;60.0
2021-03-18 19:04:36.350 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:04:40.392 [update notice] received read bai Status01 QQ=10: 49.0;45.0;4.250;-;59.0;on
2021-03-18 19:04:42.446 [update notice] received read bai DateTime QQ=10: sync;19:04:50;-.-.-;4.250
2021-03-18 19:04:42.668 [update notice] received unknown BC cmd: 10feb505020400
2021-03-18 19:04:46.491 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:04:50.487 [update notice] received read bai Status01 QQ=10: 50.0;46.0;4.250;-;58.0;on
2021-03-18 19:04:54.573 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:05:00.610 [update notice] received read bai Status01 QQ=10: 50.0;46.0;4.250;-;58.0;on
2021-03-18 19:05:02.623 [update notice] received update-read broadcast vdatetime QQ=10: 19:05:03;18.03.2021
2021-03-18 19:05:02.877 [update notice] received update-write bai StatusCirPump QQ=10: on
2021-03-18 19:05:04.655 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:05:10.738 [update notice] received read bai Status01 QQ=10: 50.0;46.0;4.250;-;58.0;on
2021-03-18 19:05:12.747 [update notice] received read bai DateTime QQ=10: valid;19:05:13;18.03.2021;4.250
2021-03-18 19:05:13.011 [update notice] received read bai Status02 QQ=10: auto;60;75.0;80;60.0
2021-03-18 19:05:14.743 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 19:05:20.781 [update notice] received read bai Status01 QQ=10: 50.0;46.0;4.250;-;58.0;on
2021-03-18 19:05:22.773 [update notice] received update-read broadcast outsidetemp QQ=10: 4.250
Im MQTT Broker kommt aber nichts an. Was mache ich falsch?
Für eure Mühe im Voraus herzlichen Dank
Hermann
Zitat von: Scooby am 18 März 2021, 16:29:17
Ich werde das einfach mit cron machen.
;D
Oder du benutzt einfach Fhem ;)
Zitat von: timekeeper am 18 März 2021, 18:44:15
Der ebusd (mit MQTT) ist installiert mit folgenden Optionen:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:HeizungEBusAdapter3:9999 --address=ff
HeizungEBusAdapter3 ist dessen IP-Adresse, sie ist erreichbar:
openhabian@openHABianDevice:~ $ ping HeizungEBusAdapter3
PING HeizungEBusAdapter3.fritz.box (192.168.178.58) 56(84) bytes of data.
64 bytes from HeizungEBusAdapter3.fritz.box (192.168.178.58): icmp_seq=1 ttl=128 time=0.414 ms
64 bytes from HeizungEBusAdapter3.fritz.box (192.168.178.58): icmp_seq=2 ttl=128 time=0.349 ms
64 bytes from HeizungEBusAdapter3.fritz.box (192.168.178.58): icmp_seq=3 ttl=128 time=0.348 ms
Im log dest ebusd kommen andauernd Zeilen wie diese:
2021-03-18 18:41:27.239 [update notice] received read bai Status01 QQ=10: 51.0;47.0;4.500;-;59.0;on
2021-03-18 18:41:29.188 [update notice] received update-read broadcast outsidetemp QQ=10: 4.500
2021-03-18 18:41:31.286 [update notice] received update-write bai SetMode QQ=10: auto;49.5;55.0;-;0;0;0;0;0;0
2021-03-18 18:41:31.602 [bus error] unable to open 192.168.178.56:9999: ERR: generic I/O error
2021-03-18 18:41:31.602 [bus notice] device invalid
2021-03-18 18:41:36.603 [bus error] unable to open 192.168.178.56:9999: ERR: generic I/O error
2021-03-18 18:41:36.603 [bus notice] device invalid
Im MQTT Broker kommt aber nichts an. Was mache ich falsch?
Für eure Mühe im Voraus herzlichen DankHermann
HeizungEBusAdapter3 ist keine IP-Adresse; allenfalls ein Host-Name. Damit die Konfiguration zu machen kann funktionieren, muss aber nicht. Ich würde es nicht machen, sondern tatsächlich IP-Adressen verwenden.
Dein HeizungEBusAdapter3 hat von deiner Fritzbox scheinbar die IP-Adresse 192.168.178.58 zugewiesen bekommen. Das sagt jedenfalls der ping
Im ebus-Log siehst du aber, dass scheinbar versucht wird ein Device mit der IP-Adresse 192,168.178.56 zu öffnen.
Das stimmt also was nicht.
Zitat von: timekeeper am 18 März 2021, 18:44:15
Der ebusd (mit MQTT) ist installiert mit folgenden Optionen (port 8888 ist belegt):
EBUSD_OPTS="--port=8889 --scanconfig --accesslevel=* --latency=20000 -d enh:HeizungEBusAdapter3:9999 --address=ff"
Im MQTT Broker kommt aber nichts an. Was mache ich falsch?
in deiner Config ist kein MQTT Protokoll definiert!
EBUSD_OPTS="--port=8889 --scanconfig --accesslevel=* --latency=80 -d enh:HeizungEBusAdapter3:9999 --mqttport=1883 --mqttjson --mqtthost=IP_vom_MQTTBroker --mqtttopic=ebusd/%circuit/%name --mqttchanges --address=ff"hier eine typische Config für MQTT, also Host, Port, JsonFormat, Topic definieren!
Außerdem musst du dann deine gewünschten MQTT Daten mit "GET" anfordern!
set ebusMQTT publish ebusd/bai/ReturnTemp/getLG
Zitat von: Wolle02 am 18 März 2021, 18:54:31
HeizungEBusAdapter3 ist keine IP-Adresse; allenfalls ein Host-Name. Damit die Konfiguration zu machen kann funktionieren, muss aber nicht. Ich würde es nicht machen, sondern tatsächlich IP-Adressen verwenden.
Dein HeizungEBusAdapter3 hat von deiner Fritzbox scheinbar die IP-Adresse 192.168.178.58 zugewiesen bekommen. Das sagt jedenfalls der ping
Im ebus-Log siehst du aber, dass scheinbar versucht wird ein Device mit der IP-Adresse 192,168.178.56 zu öffnen.
Das stimmt also was nicht.
ich sehe das auch so und würde solche Adressen als statisch konfigurieren und mit der IP Adresse anreden. DN geht nur wenn es auch zu 100% richtig definiert wurde und ob die SOHO Router das wirklich so machen zweifle ich immer etwas an. Warum hätten den Firmen Netzwerke einen ( meist einen Primary und Backup ) DNS mit Reverse Lookup eigenen Zonen usw. Ob die Fritz Box das so kann weiß ich nicht, meine Router ( Netgear Mesh 6 ) können das nicht wie gewünscht.
LG
Die Verwendung des hostnamens anstatt der IP-Adresse funktioniert mit meiner Fritzbox tadellos. Ich habe die Adresse auf dhcp stehen, jedoch in der Fritzbox eingestellt, dass der Adapter immer dieselbe bekommen soll.
Herzlichen Dank für die EBUSD_OPTS, jetzt kommt endlich etwas im MQTT-Broker an. Hurra!
Noch eine Frage: Woher weiss ich, welche Daten ich anfordern kann? Kann mir das ebusctl irgendwie mitteilen?
set ebusMQTT publish ebusd/bai/ReturnTemp/get
ganz einfach, schau in die csv die geladen wurden und du kennst die Namen der Datenpunkte.
Ich hänge sie dir hier an.
LG
Ganz einfach? Die Dateien sehen nicht danach aus, als ob ich damit jemals fertig würde. Gibt es da keinen anderen Weg?
Zitat von: timekeeper am 18 März 2021, 21:12:48
Ganz einfach? Die Dateien sehen nicht danach aus, als ob ich damit jemals fertig würde. Gibt es da keinen anderen Weg?
einfach `ebusctl find` aufrufen, dann werden die bekannten read Nachrichten ausgespuckt. Ich persönlich schaue nur selten in die CSVs rein, weil mit `ebusctl find -f -a` die zur Anlage gefundenen Messages auch ausgegeben werden können
Zitat von: timekeeper am 18 März 2021, 21:12:48
Ganz einfach? Die Dateien sehen nicht danach aus, als ob ich damit jemals fertig würde. Gibt es da keinen anderen Weg?
egal ob in der csv oder mit find gefundene Datenpunkte ( das Format ist ja dasselbe ) , du siehst immer ganz rechts eine Beschreibung was das ist.
Beispiel:
r,bai,HcHours,d.80 Hz. Betriebsstunden,,08,b509,0d2800,hoursum2,s,UIN,,h,Betriebsstunden im Heizbetrieb
ganz rechts steht:
Betriebsstunden im Heizbetrieb, und der Name des Datenpunktes steht links in der dritten Spalte und heißt:
HcHourspi@eBus:~ $ ebusctl r -f HcHours
9637
eine Abfrage von HcHours ergibt dann den Wert 9637, das ist dann der Wert in Stunden.
Das ist aber nun wirklich nicht kompliziert und macht man ja nur einmal. Und bitte solche Werte nicht jede Minute abfragen, die ändern sich maximal nur einmal pro Stunde und genügen im Prinzip höchstens einmal am Tag.
Aber entscheiden was du willst und brauchst musst du selber. Das ist wie beim Can Bus im Fahrzeug, was der Luftmengenmesser im Augenblick misst ist nur für den Mechaniker interessant der einen Fehler sucht, dir wird es viel wichtiger erscheinen was das Fahrzeug gerade verbraucht.
LG
WICHTIG
ich möchte alle Anwender ersuchen bei technischen Fragen sich hier im Forum zu melden und NICHT per Mail.
Da aus dem Bestellformular automatisch auch der gesamte Mailverkehr mit einer Kopie an mich geht und bei mir eine automatische Regel das in einen Archivordner verschiebt sehe ich meist nur durch Zufall solche Anfragen! In diesem Ordner liegen bereits 861 Mails und alle fragen sind hier im Forum besser aufgehoben da sie dann nur einmal beantwortet werden müssen weil sie dadurch auch anderen helfen!
Es braucht sich niemand zu scheuen hier zu posten, es gibt grundsätzlich keine "dummen" Fragen. alles hat seinen Sinn!
LG
Rückmeldung meiner "Probleme":
seit 3 Tagen läuft das Ganze stabil.
Geändert habe ich folgendes:
- Wemos neu geflashed
- Position geändert
- VM mit ebusd neu aufgesetzt
- Latency steht weiterhin auf 20000
Was leider immer noch nicht geht, ging vor Jahren, als die Configs noch lokal waren ist QuickVeto zu schreiben.
Reinhart, du hast ja auch die 430. Könntest du bei dir mal schauen?
Das sind die alten EInträger in meiner bai00.cfg:
# Hc1QuickVetoActive
get Hc1QuickVetoActive cmd {"r -m 10 Hc1QuickVetoActive\n"}
get Hc1QuickVetoActive expect ".*\n\n"
get Hc1QuickVetoActive postproc { $_ }
# Hc1QuickVetoActive Schreiben
get Hc1QuickVetoActiveSchreiben cmd {"write -c 430 Hc1QuickVetoActive ".Value("Hc1QuickVetoActiveEinstellen")."\n"}
get Hc1QuickVetoActiveSchreiben expect ".*\n\n"
get Hc1QuickVetoActiveSchreiben postproc { $_ }
# Hc1QuickVetoTemp
get Hc1QuickVetoTemp cmd {"r -m 10 Hc1QuickVetoTemp\n"}
get Hc1QuickVetoTemp expect ".*\n\n"
get Hc1QuickVetoTemp postproc { $_ }
# Hc1QuickVetoTemp Schreiben
get Hc1QuickVetoTempSchreiben cmd {"write -c 430 Hc1QuickVetoTemp ".Value("Hc1QuickVetoTempEinstellen")."\n"}
get Hc1QuickVetoTempSchreiben expect ".*\n\n"
get Hc1QuickVetoTempSchreiben postproc { $_ }
Blöderweise habe ich die cfg's nicht mehr (der ganze ebusd Raspy ist von mir gegangen :'( )
du hast ja das im Jahr 2016 das so gemacht (https://forum.fhem.de/index.php/topic,29737.msg436332.html#msg436332).
Auch in meiner lokalen 430.csv ist kein "w", also gesetzt neu geladen, aber geht trotzdem nicht!
r;w,,Hc1QuickVetoTemp,Quick Veto Temperatur Heizkreis 1,,,,"3C00",,,temp1,,,manual override setpoint of the first heating circuit
r;w,,Hc1QuickVetoActive,Quick Veto Aktiv Heizkreis 1,,,,"3D00",,,yesno,,,manual override of the first heating circuit enabled
pi@eBus:~ $ ebusctl r -f -c 430 Hc1QuickVetoActive
no
pi@eBus:~ $ ebusctl w -c 430 Hc1QuickVetoActive yes
ERR: element not found
LG
Danke Reinhart, meinen Text hatte ich auch schon rausgesucht, aber wie bei dir, es geht nicht mehr.
Ich muss wohl noch etwas anderes gemacht haben, weil es damals zu 100% funktioniert hatte.
Muss ich weiter suchen.
eigentlich sollte es schon online auch funktionieren
r,,HwcQuickVetoTemp,Quick Veto Temperatur Warmwasserkreis,,,,"4500",,,temp1,,,manual override setpoint for the domestic hot water circuit
[SW>=215]w,,HwcQuickVetoTemp,Quick Veto Temperatur Warmwasserkreis,,,,"4500",,,temp1,,,manual override setpoint for the domestic hot water circuit
r;w,,HwcQuickVetoActive,Quick Veto Aktiv Warmwasserkreis,,,,"4300",,,yesno,,,manual override of the domestic hot water circuit enabled
[SW>=215]w,,HwcQuickVetoActive,Quick Veto Aktiv Warmwasserkreis,,,,"4300",,,yesno,,,manual override of the domestic hot water circuit enabled
weil das hat John damals dazu gebaut und ich habe die SW 215 im 430er.
LG
Zitat von: Reinhart am 19 März 2021, 14:14:31
eigentlich sollte es schon online auch funktionieren
schau doch mal, ob die Nachricht wirklich da ist mit `ebusctl find -w HwcQuickVetoActive`
430 HwcQuickVetoActive = no data stored :'(
Zitat von: Mitch am 19 März 2021, 14:24:41
430 HwcQuickVetoActive = no data stored :'(
das ist ja gut und zeigt, dass die Messagedefinition existiert.
Deine bai00.cfg passt nur nicht dazu, denn dort heißt es Hc1... statt Hwc...
probier doch erstmal `ebusctl w -c 430 HwcQuickVetoActive yes`
und wenn das funktioniert, kannst die bai00.cfg anpassen
Zitat von: john30 am 19 März 2021, 14:20:10
schau doch mal, ob die Nachricht wirklich da ist mit `ebusctl find -w HwcQuickVetoActive`
pi@eBus:~ $ ebusctl find -r Hc1QuickVetoActive
430 Hc1QuickVetoActive = no
pi@eBus:~ $ ebusctl find -w Hc1QuickVetoActive
ERR: element not found
und ausserdem muss yesno mit 0 und 1 angeben werden.
yesno,UCH,0=no;1=yes,,LG
Zitat von: john30 am 19 März 2021, 14:28:01
das ist ja gut und zeigt, dass die Messagedefinition existiert.
Deine bai00.cfg passt nur nicht dazu, denn dort heißt es Hc1... statt Hwc...
probier doch erstmal `ebusctl w -c 430 HwcQuickVetoActive yes`
und wenn das funktioniert, kannst die bai00.cfg anpassen
was dir alles auffällt und schon gehts!
pi@eBus:~ $ ebusctl w -c 430 HwcQuickVetoActive 0
done
pi@eBus:~ $ ebusctl w -c 430 HwcQuickVetoActive 1
done
noch zur Info für Mitch, geht auch bei den Online Csv und nicht nur lokal! Musst aber schauen ob du auch SW 215 bei der 430 hast.
LG
Okay, danke schonmal für die vielen Infos.
Eine bai00.cfg habe ich nicht, weil ich ja MQTT mache.
Es hat jetzt auch mal geklappt, dann wieder nicht.
Temperatur konnte ich gar nicht über MQTT verstellen.
Auf dem ebusd geht es leider auch nur manchmal, und dann auch unzuverlässig, sprich er nimmt den Befehl, aber macht nichts:
root@ebusd:/etc/default# ebusctl w -c 430 HwcQuickVetoTemp 22
done
root@ebusd:/etc/default# ebusctl r -f -c 430 HwcQuickVetoTemp
55.0
root@ebusd:/etc/default# ebusctl w -c 430 HwcQuickVetoTemp 22
ERR: SYN received
root@ebusd:/etc/default# ebusctl w -c 430 HwcQuickVetoTemp 22
ERR: SYN received
root@ebusd:/etc/default# ebusctl w -c 430 HwcQuickVetoTemp 22
done
root@ebusd:/etc/default# ebusctl r -f -c 430 HwcQuickVetoTemp
55.0
@John
habe noch etwas mit den Wemos getestet!
Da ich mindestens 3 verschiedene Typen beipacke habe ich mir das Timing Problem angesehen.
Der linke D1 mini geht noch am Besten, der mittlere mit V3 so halbwegs und der rechte mit abgesetzter Antenne ist der anspruchsvollste, obwohl der den besten Empfang hat!
D.h. du musst jetzt einen Mittelweg finden der bei allen gleich gut funktioniert.
LG
Mitch hast du nicht noch zusätzlich das WIFI Problem?
Warte einfach noch bis John das fixen kann, dann läufst du nicht im Kreis und suchst unter Umständen Fehler die es eigentlich gar nicht mehr gibt.
LG
ZitatZitat
also "ebusctl i" passt nicht zu deinem Log, es wird hier nur der eigene Adapter angeführt. Außerdem hast du zweimal den Device beim Start definiert.
sudo ebusd -f --scanconfig -d enh:/dev/ttyAMA0 --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name
Die vielen "unknown" kommen weil hier keine entsprechenden csv geladen sind und daher werden die Rohdaten nicht dekodiert. Was ich im Log gesehen habe wird nur "15.700.csv" mit 481 Definitionen geladen.
Hast du wirklich die seriellen Einstellungen am Raspi gecheckt ob das alles so passt? Was hast du für einen Raspi?
In der Config Datei hab ich das Device nur 1 mal drinnen.
War ein Kopierfehler von mir als ich ebusd direkt von der Kosole gestartet habe, ändert aber nichts an meinem Problem.
Habe eine Raspberry 4 und habe die seriellen Einstellungen so gemacht wie in der Anleitung steht.
Auf diesem Raspberry laufen noch andere Sache wie IoBroker mit div. Adptern, vielleicht haut mir dass irgendwo einen Hund rein.
Werde es mal mit meinem Raspberry Pi3 mit neu aufgesetztem Image versuchen.
Habs nun mit Raspberry 3 probiert, dort hat es auf Anhieb geklappt.
Hab dann die Config nochmals bei meinem Pi4 gemacht und siehe da, es funktioniert auch.
Hat wohl irgendwas beim 1. mal konfigurieren nicht geklappt.
Daten kann ich jetzt schon sehr viele lesen.
Im Log hab ich aber noch immer sehr viele "received unknown MS cmd:" bzw. "scan config 76: ERR: element not found"
Ist das normal?
pi@raspberrypi4host:~ $ sudo ebusd -f --scanconfig --latency=50 -d enh:/dev/ttyAMA0 --accesslevel=* --mqttport=1883 --mqtthost=192.168.0.14 --mqtttopic=ebusd/%circuit/%name
2021-03-19 20:10:09.568 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device /dev/ttyAMA0
2021-03-19 20:10:09.809 [bus notice] bus started with own address 31/36
2021-03-19 20:10:09.818 [mqtt notice] connection established
2021-03-19 20:10:09.830 [bus notice] signal acquired
2021-03-19 20:10:09.946 [bus notice] new master 10, master count 2
2021-03-19 20:10:09.997 [bus notice] device status: reset
2021-03-19 20:10:10.127 [bus notice] new master 71, master count 3
2021-03-19 20:10:10.179 [bus notice] new master 03, master count 4
2021-03-19 20:10:10.179 [update notice] received unknown MS cmd: 7108b5110107 / 0a4d980101803900000000
2021-03-19 20:10:10.320 [update notice] received unknown MS cmd: 1076b512030f0202 / 070e0300570313ff
2021-03-19 20:10:10.585 [update notice] received unknown MS cmd: 1008b510090003ffff7aff070001 / 0101
2021-03-19 20:10:10.849 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:10:13.436 [update notice] received unknown MS cmd: 7108b5110107 / 0a4d980101803900000000
2021-03-19 20:10:15.363 [update notice] received unknown MS cmd: 7108b51a03046b32 / 0e6b07c0cfc07b3c00b01b20000000
2021-03-19 20:10:15.743 [update notice] received unknown MS cmd: 7108b51a03046c33 / 0e6c0000008a000000000000000000
2021-03-19 20:10:16.124 [update notice] received unknown MS cmd: 7108b51a03046d34 / 0e6dcf2000c0022101001800061800
2021-03-19 20:10:16.549 [update notice] received unknown MS cmd: 7108b51a03046e35 / 0e6e00000000000100b00000000000
2021-03-19 20:10:16.930 [update notice] received unknown MS cmd: 7108b51a03046f36 / 0e6f00000000000000000000000000
2021-03-19 20:10:17.220 [update notice] received unknown MS cmd: 7108b5120e1163033203220390051311080000 / 020264
2021-03-19 20:10:17.480 [update notice] received unknown MS cmd: 7108b5110107 / 0a4d980101803900000000
2021-03-19 20:10:19.816 [update notice] received unknown MS cmd: 1008b5110101 / 096c660080ffff0400ff
2021-03-19 20:10:19.984 [bus notice] scan 08: ;Vaillant;HMU00;0405;5103
2021-03-19 20:10:19.984 [update notice] store 08 ident: done
2021-03-19 20:10:19.984 [update notice] sent scan-read scan.08 QQ=31: Vaillant;HMU00;0405;5103
2021-03-19 20:10:19.984 [bus notice] scan 08: ;Vaillant;HMU00;0405;5103
2021-03-19 20:10:20.163 [update notice] received unknown MS cmd: 1076b5110101 / 096a664901ff610000ff
2021-03-19 20:10:20.233 [main notice] read common config file vaillant/scan.csv
2021-03-19 20:10:20.290 [main notice] read common config file vaillant/general.csv
2021-03-19 20:10:20.347 [main notice] read common config file vaillant/broadcast.csv
2021-03-19 20:10:20.406 [main notice] read scan config file vaillant/08.hmu.csv for ID "hmu00", SW0405, HW5103
2021-03-19 20:10:20.436 [update notice] received unknown MS cmd: 1076b512030f0202 / 070f0300570313ff
2021-03-19 20:10:20.521 [main notice] found messages: 61 (0 conditional on 0 conditions, 0 poll, 10 update)
2021-03-19 20:10:20.697 [update notice] sent unknown MS cmd: 3108b5090124 / 09003231313933343030
2021-03-19 20:10:20.930 [update notice] sent scan-read scan.08 id QQ=31:
2021-03-19 20:10:21.028 [bus notice] max. symbols per second: 125
2021-03-19 20:10:21.165 [update notice] sent scan-read scan.08 id QQ=31:
2021-03-19 20:10:21.310 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:10:21.486 [update notice] sent scan-read scan.08 id QQ=31: 21;19;34;0010021619;1610;005437;N1
2021-03-19 20:10:21.486 [bus notice] scan 08: ;21;19;34;0010021619;1610;005437;N1
2021-03-19 20:10:23.684 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2021-03-19 20:10:23.684 [update notice] store 15 ident: done
2021-03-19 20:10:23.684 [update notice] sent scan-read scan.15 QQ=31: Vaillant;70000;0613;6903
2021-03-19 20:10:23.684 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2021-03-19 20:10:23.871 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313933343030
2021-03-19 20:10:24.057 [update notice] sent scan-read scan.15 id QQ=31:
2021-03-19 20:10:24.245 [update notice] sent scan-read scan.15 id QQ=31:
2021-03-19 20:10:24.479 [update notice] sent scan-read scan.15 id QQ=31: 21;19;34;0020266797;0082;045585;N0
2021-03-19 20:10:24.479 [bus notice] scan 15: ;21;19;34;0020266797;0082;045585;N0
2021-03-19 20:10:24.656 [main notice] read scan config file vaillant/15.700.csv for ID "70000", SW0613, HW6903
2021-03-19 20:10:24.712 [main notice] found messages: 481 (0 conditional on 0 conditions, 0 poll, 10 update)
2021-03-19 20:10:25.044 [update notice] received unknown MS cmd: 7108b5120e1165033303220391051311080000 / 020264
2021-03-19 20:10:26.924 [bus notice] scan 76: ;Vaillant;VWZ00;0517;5103
2021-03-19 20:10:26.924 [update notice] store 76 ident: done
2021-03-19 20:10:26.924 [update notice] sent scan-read scan.76 QQ=31: Vaillant;VWZ00;0517;5103
2021-03-19 20:10:26.924 [bus notice] scan 76: ;Vaillant;VWZ00;0517;5103
2021-03-19 20:10:27.110 [update notice] sent unknown MS cmd: 3176b5090124 / 09003231313933363030
2021-03-19 20:10:27.298 [update notice] sent scan-read scan.76 id QQ=31:
2021-03-19 20:10:27.485 [update notice] sent scan-read scan.76 id QQ=31:
2021-03-19 20:10:27.674 [update notice] sent scan-read scan.76 id QQ=31: 21;19;36;0010023504;1610;005233;N8
2021-03-19 20:10:27.674 [bus notice] scan 76: ;21;19;36;0010023504;1610;005233;N8
2021-03-19 20:10:27.747 [main error] unable to load scan config 76: no file from vaillant with prefix 76 found
2021-03-19 20:10:27.747 [main error] scan config 76: ERR: element not found
2021-03-19 20:10:29.887 [update notice] received read hmu Status01 QQ=10: 54.0;51.0;-;-;-;hwc
2021-03-19 20:10:30.148 [update notice] received unknown MS cmd: 1076b5110101 / 096b664901ff610000ff
2021-03-19 20:10:30.415 [update notice] received unknown MS cmd: 1076b512030f0202 / 070f0300580313ff
2021-03-19 20:10:30.681 [update notice] received update-write hmu SetMode QQ=10: 3;-;-;122;1;1;1;1;0;0
2021-03-19 20:10:30.945 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:10:31.170 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:33.083 [update notice] received unknown MS cmd: 7108b5120e1166033303230392051312080000 / 020264
2021-03-19 20:10:34.582 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:38.055 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:39.944 [update notice] received read hmu Status01 QQ=10: 54.0;51.0;-;-;-;hwc
2021-03-19 20:10:40.204 [update notice] received unknown MS cmd: 1076b5110101 / 096b664901ff620000ff
2021-03-19 20:10:40.472 [update notice] received unknown MS cmd: 1076b512030f0202 / 07100300590313ff
2021-03-19 20:10:40.738 [update notice] received update-write hmu SetMode QQ=10: 3;-;-;122;1;1;1;1;0;0
2021-03-19 20:10:41.030 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:10:41.115 [update notice] received unknown MS cmd: 7108b5120e11660334032303940513fd070000 / 020264
2021-03-19 20:10:41.472 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:44.945 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:48.375 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:49.102 [update notice] received unknown MS cmd: 7108b5120e11660334032403950513fd070000 / 020264
2021-03-19 20:10:49.982 [update notice] received read hmu Status01 QQ=10: 54.0;51.0;-;-;-;hwc
2021-03-19 20:10:50.241 [update notice] received unknown MS cmd: 1076b5110101 / 096b663a01ff620000ff
2021-03-19 20:10:50.511 [update notice] received unknown MS cmd: 1076b512030f0202 / 071003005a0313ff
2021-03-19 20:10:50.724 [update notice] received unknown BC cmd: 10feb505025c00
2021-03-19 20:10:50.989 [update notice] received update-write hmu SetMode QQ=10: 3;-;-;122;1;1;1;1;0;0
2021-03-19 20:10:51.253 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:10:51.521 [update notice] received unknown MS cmd: 1076b5040100 / 0a03521020190305213a01
2021-03-19 20:10:51.760 [update notice] received unknown MS cmd: 1008b507020937 / 02c001
2021-03-19 20:10:52.028 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:52.049 [update notice] received update-read broadcast vdatetime QQ=10: 20:10:51;19.03.2021
2021-03-19 20:10:52.309 [update notice] received unknown MS cmd: 1008b5110100 / 09660313a7000900009c
2021-03-19 20:10:52.556 [update notice] received unknown MS cmd: 1076b51303040d00 / 020d00
2021-03-19 20:10:52.772 [update notice] received update-read broadcast outsidetemp QQ=10: 1.285
2021-03-19 20:10:55.239 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:10:57.108 [update notice] received unknown MS cmd: 7108b5120e1167033503250396051310080000 / 020264
2021-03-19 20:10:58.694 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:11:00.056 [update notice] received read hmu Status01 QQ=10: 54.0;51.0;-;-;-;hwc
2021-03-19 20:11:00.311 [update notice] received unknown MS cmd: 1076b5110101 / 096b664901ff620000ff
2021-03-19 20:11:00.583 [update notice] received unknown MS cmd: 1076b512030f0202 / 071103005a0313ff
2021-03-19 20:11:00.849 [update notice] received update-write hmu SetMode QQ=10: 3;-;-;122;1;1;1;1;0;0
2021-03-19 20:11:01.112 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:11:02.128 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:11:05.138 [update notice] received unknown MS cmd: 7108b5120e11670335032503970513fd070000 / 020264
2021-03-19 20:11:05.583 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:11:09.013 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:11:10.111 [update notice] received read hmu Status01 QQ=10: 54.0;51.0;-;-;-;hwc
2021-03-19 20:11:10.371 [update notice] received unknown MS cmd: 1076b5110101 / 096b664901ff620000ff
2021-03-19 20:11:10.639 [update notice] received unknown MS cmd: 1076b512030f0202 / 071203005b0313ff
2021-03-19 20:11:10.905 [update notice] received update-write hmu SetMode QQ=10: 3;-;-;122;1;1;1;1;0;0
2021-03-19 20:11:11.168 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2021-03-19 20:11:12.447 [update notice] received read hmu State QQ=71: 77;409;on;128
2021-03-19 20:11:13.131 [update notice] received unknown MS cmd: 7108b5120e1168033603250398051311080000 / 020264Christian
ich weiß ja nicht was die VWZ00 für ein Gerät ist, aber so wie es aussieht gibt es da noch kein csv (https://github.com/john30/ebusd/issues/379) dafür.
LG
Hallo,
ich habe meinen Adapter auch bekommen und wollte ihn heute morgen einrichten.
Anschluss erfolgt per LAN. Die Jumper habe ich entsprechend gesetzt. Jedoch bekomme ich keine LAN-Verbindung zum Adapter aufgebaut. Die blaue LED blinkt dabei permanent mit den ca. 4x pro Sekunde, weshalb ich davon ausgehe, dass die DHCP Vergabe nicht klappt. Woran kann dies ggf. liegen?
Der Anschluss selbst scheint i.O. zu sein, da sowohl im Switch als angeschlossen angezeigt wird und auch auf dem LAN-Modul des Adapters die grüne Leuchte leuchtet.
Zitat von: baumhous3 am 21 März 2021, 10:11:30
Anschluss erfolgt per LAN. Die Jumper habe ich entsprechend gesetzt. Jedoch bekomme ich keine LAN-Verbindung zum Adapter aufgebaut. Die blaue LED blinkt dabei permanent mit den ca. 4x pro Sekunde, weshalb ich davon ausgehe, dass die DHCP Vergabe nicht klappt. Woran kann dies ggf. liegen?
Was hast Du denn für einen DHCP Server?
Zitat von: Mitch am 19 März 2021, 14:58:35
Es hat jetzt auch mal geklappt, dann wieder nicht.
was heißt das genau? Also im Sinne der Antwort vom ebusd.
Zitat von: Mitch am 19 März 2021, 14:58:35
Temperatur konnte ich gar nicht über MQTT verstellen.
dann bitte mehr Details dazu geben, so kann ich absolut nichts dazu sagen (ebusd Log, MQTT Topic samt Content und Antwort).
Zitat von: Mitch am 19 März 2021, 14:58:35
Auf dem ebusd geht es leider auch nur manchmal
heißt was genau? wie ist die Antwort zum Kommando und wie setzt du es ab?
Zitat von: Mitch am 19 März 2021, 14:58:35
, und dann auch unzuverlässig, sprich er nimmt den Befehl, aber macht nichts:
root@ebusd:/etc/default# ebusctl w -c 430 HwcQuickVetoTemp 22
done
das würde dann wiederum an der Heizung liegen, denn mehr als die Message abschicken, kann ebusd auch nicht tun.
Zitat von: Mitch am 19 März 2021, 14:58:35
root@ebusd:/etc/default# ebusctl r -f -c 430 HwcQuickVetoTemp
55.0[/code]
bist Du sicher, dass nicht ein anderes Gerät den Wert überschreibt?
Wie sehen denn jetzt deine EBUSD_OPTS aus?
Und bist Du noch auf der Wemos Verbindung?
Du hast zuletzt geschrieben, dass es jetzt stabil läuft. Wie ist denn jètzt das Setup?
Zitat von: john30 am 21 März 2021, 11:04:52
Was hast Du denn für einen DHCP Server?
Nutze den Standard DHCP-Server der FritzBox
Nach ein paar kleinen Anfangsschwierigkeiten läuft nun mein ebus-Adaper (per LAN) und der ebusd reibungslos. Danke für die tolle Arbeit.
Ich habe noch eine Frage zum aktiven Auslesen von Werten:
Ich habe mir ein Script geschrieben, welches per ebusctl ausgewählte Werte meiner Vaillant-Therme ausliest. Dabei verwendet ich die Parameter "-p 1 -m 30".
Nun zu meinen Fragen:
- Im Wiki steht "-m SECONDS only return cached value if age is less than SECONDS": Bedeutet dies, dass der Wert zyklisch abgefragt wird oder einmalig?
- Wie binde ich mein Script am besten ein?
- Welche Bedeutung und welchen Wertebereich hat die Priorität
- Muss ich etwas beachten, um den Bus nicht zu überlasten?
Herzlichen Dank im Voraus
Hermann
-m liest aus dem Cache, -f ( force ) liefert dir aktuelle Daten und zwingt den Adapter zu einer aktuellen Abfrage.
Den Bus überlasten kannst du wenn du zu kurz hintereinander abfragst. Das System ist ja nicht dazu konzipiert hier ständig auszulesen, sondern oberste Priorität hat die Steuerung und der interne Infomationsfluß der Heizung. Bei einer Heizung ist ohnehin alles träge und wenn die Abstände der Abfragen in etwa 5 - 10 Minuten hast ist das in meinen Augen genug. Manche Werte benötigt man ohnehin nur einmal am Tag. Jede Abfrage mit -f ist ein Sendebefehl am Bus!
Man kann aber auch überlegen ob man nicht schon die Broadcast ausnutzt ( Status01 ), die kommen alle paar Sekunden und liefern schon wichtige Parameter wie Vorlauf, Rücklauf, Warmwassertemp, Aussentemp.
Ich würde aber lieber die Abfragesteuerung aus der Applikation mit einem Timer machen, da ist es komfortabler und du kannst es jederzeit ändern.
So eine typische Abfrage via MQTT könnte so ausssehen:
+*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/Status02/get;
set ebusMQTT publish ebusd/bai/HcHours/get;
set ebusMQTT publish ebusd/bai/HwcStarts/get
das ist jetzt in FHEM, aber du hast sicher im iobroker auch Timer zur Verfügung!
Die unten angehängten Bilder sind alle aus den Statusmeldungen generiert.
LG
Danke für die schnelle Antwort.
Ich verwende openhab, nicht iobroker. Und deshalb läuft die Kommunikation über dessen binding, nicht über MQTT.
Timer habe ich dort natürlich, ich weiß nur nicht, was ich hierfür triggern muss.
Mir geht es auch gar nicht darum, permanent alle Werte abzufragen. Da aber meine Vaillant ab und zu herumzickt und man nicht mitbekommt, wenn sie im Keller eine Fehlermeldung ausspuckt und in den Notbetrieb geht, steht man plötzlich mit kaltem Wasser unter der Dusche. Deshalb würde ich gerne zyklisch den currenterror abfragen, um eine Telegram-Notification zu versenden, falls sich da etwas tut.
Hermann
Hallo.
Heute bin ich nun endlich auch zum Testen gekommen ::)
- Therme stromlos gemacht
- Adapter LAN-Version an die Switch angeschl.
- ebus zur Therme dazu geklemmt
- Adapter Strom gegeben
- Therme eingeschaltet
- Fhem in Docker gestartet
docker run -d --rm --device=/dev/bus/usb/ --net=testnet -p 8083:8083 --name fhem fhem/fhem
- MQTT-Server angelegt und ebus-Template gesetzt
- ebusd in Docker gestartet
docker run --rm -it --net=testnet --name ebus -p 8888 john30/ebusd -f --scanconfig -d udp:192.168.222.188:9999 --latency=80 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=fhem --mqtttopic=ebusd/%circuit/%name --mqttchanges
--> Kommunikation MQTT klappt
2021-03-21 12:13:19.956 [main notice] ebusd 21.1.v21.1-3-g62221bb started with auto scan
2021-03-21 12:13:20.161 [bus notice] bus started with own address ff/04
2021-03-21 12:13:20.172 [mqtt notice] connection established
2021-03-21 12:15:30.226 [main notice] update check: version 21.2 available
Internals:
CFGFN
CID ebusd
DEF ebusd
DEVICETOPIC MQTT2_ebusd_21.1_1
FUUID 6057376c-f33f-10f2-373a-36496dae4bb63402
IODev myMQTT_Server
LASTInputDev myMQTT_Server
MSGCNT 108
NAME MQTT2_ebusd_21.1_1
NR 55
STATE Status:
1:true
Signal:
2:signal
<br>Uptime: 0 000 00:24
TYPE MQTT2_DEVICE
myMQTT_Server_MSGCNT 108
myMQTT_Server_TIME 2021-03-21 13:38:08
OLDREADINGS:
READINGS:
2021-03-21 13:15:30 associatedWith MQTT2_ebusd_21.1_1
2021-03-21 13:09:40 attrTemplateVersion 20200522 or prior
2021-03-21 13:10:32 datetime
2021-03-21 13:10:32 eeprom
2021-03-21 13:10:32 error
2021-03-21 13:38:08 formatedUptime 0 000 00:24
2021-03-21 13:10:32 id
2021-03-21 13:10:32 queryexistence
2021-03-21 13:10:32 ram
2021-03-21 13:13:20 running true
2021-03-21 13:13:30 scan "finished"
2021-03-21 13:10:32 signoflife
2021-03-21 13:10:32 state getAll
2021-03-21 13:15:30 updatecheck "version 21.2 available"
2021-03-21 13:38:08 uptime 1488
2021-03-21 13:13:20 version "ebusd 21.1.v21.1-3-g62221bb"
Attributes:
IODev myMQTT_Server
autocreate 1
bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
comment NOTE: additional templates and code have been downloaded from svn (contrib).
devStateIcon 1.true:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
icon sani_boiler_temp
model eBus_daemon_splitter
readingList ebusd/broadcast/datetime:.* datetime
ebusd/broadcast/error:.* error
ebusd/broadcast/id:.* id
ebusd/broadcast/queryexistence:.* queryexistence
ebusd/broadcast/signoflife:.* signoflife
ebusd_21.1_1:ebusd/memory/eeprom:.* eeprom
ebusd_21.1_1:ebusd/memory/ram:.* ram
ebusd/global/scan:.* scan
ebusd/global/updatecheck:.* updatecheck
room MQTT2_DEVICE
setList getKnown:noArg ebusd/list onlyknown
getAll:noArg ebusd/list
stateFormat Status:
1:running
Signal:
2:signal
<br>Uptime: formatedUptime
userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
--> ebusctl i sagt "no signal"
root@708e219e024d:/# ebusctl i
version: ebusd 21.1.v21.1-3-g62221bb
update check: version 21.2 available
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
--> die grüne LED flackert und blinkt ganz wild, als würden ganz viele Telegramme drüberflattern
--> Verkabelung ebus habe ich mehrfach gecheckt
--> Jumper stehen wie im Wiki beschrieben
--> Adapter ist aus dem Container heraus erreichbar:
root@6086aff6bf43:/# ping 192.168.222.188
PING 192.168.222.188 (192.168.222.188) 56(84) bytes of data.
64 bytes from 192.168.222.188: icmp_seq=1 ttl=127 time=2.18 ms
64 bytes from 192.168.222.188: icmp_seq=2 ttl=127 time=1.20 ms
64 bytes from 192.168.222.188: icmp_seq=3 ttl=127 time=0.971 ms
64 bytes from 192.168.222.188: icmp_seq=4 ttl=127 time=1.26 ms
64 bytes from 192.168.222.188: icmp_seq=5 ttl=127 time=1.16 ms
^C
--- 192.168.222.188 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 0.971/1.358/2.180/0.423 ms
root@6086aff6bf43:/#
Habe ich noch irgendwo einen Lapsus drinnen? Was kann/ sollte ich noch testen?
Vielen Dank und beste Grüße
rob
Hallo zusammen,
auch ich habe in der Woche meinen (USB-)Adapter bekommen und ihn jetzt am Wochenende eingebaut. Ihr habt ja wirklich professionelle Arbeit abgeliefert und super dokumentiert - vielen Dank dafür! :)
Hardware und ebusd laufen (aus den Sourcen kompiliert in einer VM auf einer Synology DS920+) soweit stabil die letzte Nacht über. Auch die Heizung scheint sich nicht am neuen Busteilnehmer zu stören. Ich habe eine Vaillant auroMATIC 620/3 mit zusätzlichem Mischermodul VR60/3, Therme ecoTEC plus VC206/5 und VPM Trinkwasserstation an einem Schichtspeicher.
Beim ersten ausprobieren hatte ich Bedenken, weil anscheinend viel auf den Bus gesendet wird. Die rote LED blieb nicht länger als vielleicht 3 Sekunden aus. Hatte daraufhin den ebusd mit --readonly gestartet, aber damit hat er lt. "ebusctl i" dann keine CSVs mehr geladen, obwohl nach einiger Zeit alle Slaves mit ID, SW und HW bekannt waren. Nächster Versuch war mit --pollinterval=0, aber damit wollte der ebusd gar nicht mehr starten:
Mar 20 17:57:14 smh ebusd[25024]: ebusd: scanconfig without polling may lead to invalid files included for certain products!
Mar 20 17:57:14 smh ebusd[25024]: Try `ebusd --help' or `ebusd --usage' for more information.
Ist das ein Bug?
Was wird da eigentlich gepollt? Die Auswahl der zu pollenden Werte müsste ich doch auch irgendwo konfigurieren können?
Letztlich lief dann mit dieser Config alles wunderbar die Nacht durch:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 --pollinterval=61 -d enh:/dev/ttyUSB0 --address=ff"
Zitat von: baumhous3 am 21 März 2021, 11:24:11
Nutze den Standard DHCP-Server der FritzBox
um einen defekten USR auszuschließen, könntest Du mal auf eine fixe IP umstellen?
Zitat von: rob am 21 März 2021, 13:57:02
- ebusd in Docker gestartet
docker run --rm -it --net=testnet --name ebus -p 8888 john30/ebusd -f --scanconfig -d udp:192.168.222.188:9999 --latency=80 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=fhem --mqtttopic=ebusd/%circuit/%name --mqttchanges
der Adapter kann kein UDP und je nachdem, wie der Jumper fürs enhanced Protokoll steht (Auslieferungszustand: enhanced), musst Du entweder "-d enh:192.168.222.188:9999" (enhanced) oder "-d tcp:192.168.222.188:9999" (nicht enhanced) nehmen.
Zitat von: chris371 am 21 März 2021, 14:40:06
Mar 20 17:57:14 smh ebusd[25024]: ebusd: scanconfig without polling may lead to invalid files included for certain products!
Mar 20 17:57:14 smh ebusd[25024]: Try `ebusd --help' or `ebusd --usage' for more information.
Ist das ein Bug?
nein, das Scannen der Geräte geht nur in Kombination mit Polling.
Zitat von: chris371 am 21 März 2021, 14:40:06
Was wird da eigentlich gepollt? Die Auswahl der zu pollenden Werte müsste ich doch auch irgendwo konfigurieren können?
Die ID der Geräte und die Nachrichten, die mit Poll Priorität versehen sind.
Zitat von: john30 am 21 März 2021, 14:56:36
der Adapter kann kein UDP...
Danke Dir, jetzt klappt es:
root@91ad7941eb6b:/# ebusctl i
version: ebusd 21.1.v21.1-3-g62221bb
update check: version 21.2 available
access: *
signal: acquired
symbol rate: 38
max symbol rate: 46
min arbitration micros: 4
max arbitration micros: 9
min symbol latency: 15
max symbol latency: 23
reconnects: 0
masters: 4
messages: 14
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address 07: master #16
address 0c: slave #16, scanned "MF=-;ID=??;SW=-;HW=-"
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID=W ;SW=2726;HW=-"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302"
address ff: master #25, ebusd
Ich hatte mich an der Docker-Doku orientiert. Die ist wahrscheinlich universeller formuliert, weil ja auch UDP-fähige Geräte im Einsatz sein könnten. Verstanden.
Dann mach ich mal an die CSV-Dinger, was ich aber wie angeregt in einem anderen Fred forcieren werde :)
Abermals vielen Dank, beste Grüße und einen schönen Sonntag noch
rob
zum Thema WIFI:
Ich hab jetzt Delays gemessen in den Varianten USB, Ethernet und Wemos und die Ergebnisse sind nicht unbedingt überraschend:
- Ethernet hat das kürzeste Send-Receive Delay bei 7/8/11 ms (min/mittel/max)
- USB folgt vom Mittelwert dahinter mit 13/17/32
- last but not least der Wemos mit 12/26/135
Wirklich unschön sind natürlich die sporadischen Wemos Ausreißer mit teilweise über 100 ms Verzögerung. Das ist andererseits nachvollziehbar in einem durchaus beanspruchten Umfeld mit zig weiteren WLANs in der Nähe (ja, mein WLAN ist wirklich schrottig). Deshalb hat es mich wie gesagt nicht sonderlich überrascht.
Meine Empfehlung daher: Beim Einsatz von Wemos das Maximum an Latency einstellen mit `--latency=100´.
Ethernet braucht theoretisch keine Latency, aber bissl was schadet vermutlich nicht und ich empfehle `--latency=20´.
Und weil USB Serial selbst im jetzigen enhanced protocol mit 9600 Bd auch nicht wahnsinnig flott ist, würde ich hier mit `--latency=20´ ins Rennen gehen.
Beim Raspi hab ich in Erinnerung, dass der UART wegen des Kernel Moduls bis zu 4 Bytes puffert, weshalb auch hier eine Latency Abhilfe schaffen kann. 4*5ms wären 20, aber ich denke `--latency=40´ wäre ein guter Wert.
Zitat von: john30 am 21 März 2021, 14:53:45
um einen defekten USR auszuschließen, könntest Du mal auf eine fixe IP umstellen?
Habe nun eine fixe IP vergeben und nun klappt die Verbindung :)
Bekomme auch Daten von der Lüftung. Nur kriege ich jetzt keine Daten mehr von der Heizung, die vorher lief über den esera adapter.
Er zeigt mir zwar die Vaillant an (siehe unten), jedoch kommen dort keine Daten.
Die KWL hingegen wird im find / scan result nicht angezeigt, liefert jedoch fleißig Daten per MQTT. Woran kann das nun liegen?
Sieht wie folgt aus:
Einstellungen:
EBUSD_OPTS1="-d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=PATH"
EBUSD_OPTS2="-d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=/etc/ebusd --address=ff"Ergebnisse:
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated)
Active: active (running) since Sun 2021-03-21 18:45:45 CET; 2min 42s ago
Docs: man:systemd-sysv-generator(8)
Process: 449 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
Tasks: 9 (limit: 4915)
CGroup: /system.slice/ebusd.service
├─471 /usr/bin/ebusd --pidfile /var/run/ebusd1.pid -d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=PATH
└─484 /usr/bin/ebusd --pidfile /var/run/ebusd2.pid -d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=/etc/
Mär 21 18:45:45 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Mär 21 18:45:45 raspberrypi ebusd[449]: Starting ebusd1: ebusd.
Mär 21 18:45:45 raspberrypi ebusd[449]: Starting ebusd2: ebusd.
Mär 21 18:45:45 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 24
max symbol rate: 94
min arbitration micros: 3
max arbitration micros: 5
min symbol latency: 9
max symbol latency: 12
reconnects: 0
masters: 4
messages: 3
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=72000;SW=0118;HW=7703"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;HMU00;0307;0403
15;Vaillant;72000;0118;7703
76;Vaillant;VWZ00;0307;0403
also --configpath=PATH wird nicht viel bringen, gib hier einen Pfad an sonst wird da nix gefunden oder laß ihn ganz weg wenn die die Online Konfiguration verwenden willst.
bei der MQTT Definition fehlen dir eine paar Parameter, vor allem die Topic.
Beispiel:
--mqttport=1883 --mqttjson --mqtthost=fhem --mqtttopic=ebusd/%circuit/%name --mqttchanges
LG
@John
ich habe ja auf meinem Testadapter jetzt auch 2 Tage Wifi mit MQTT parametriert und habe hier auch mit latency=80 regelmäßig "framing errors" und sogar "signal lost". Ich habe allerdings auf diesem AP im 2,4 Ghz Bereich auch 25 Devices hängen, aber in der Praxis wirkt sich das bei mir nicht negativ aus wenn man nicht ins Log schaut. Daten kommen regelmäßig an und man kann auch schreiben.
Wer nur WIFI zur Verfügung hat und bessere Stabilität erzielen möchte, sollte auf die alte Methode mit einem eigenen eBus Raspi und diesen mit WIFI verbinden setzen. Der Adapter kann dann via USB oder RPI angeschlossen werden, dann umgeht man die extremen Delays des Wemos.
Jeder hat hier eine andere Umgebung, daher empfiehlt sich einfach testen ob man mit Stabilität der Verbindung zufrieden ist.
LG
Das MQTT ist nicht das Problem, bzw das die Einstellungen falsch sind. Wenn ich den einzeln nehme bekomme ich das ja übermittelt, deshalb kann es daran doch eigentlich nicht liegen?
und configpath=PATH wird dir am ersten Adapter keine csv laden können.
MQTT ohne Topic zu verwenden kann dich bei der weiteren Auswertung ordentlich durcheinander bringen, aber damit umgehen musst eh du damit.
LG
Zwei Fragen möchte ich doch noch los werden :)
a)
Ich würde den Adapter (LAN) doch lieber nicht via USB bestromen, sondern per Schraubterminal und stabilisiertem 3.3V-Netzteil.
Beim fliegenden Aufbau hatte ich einige Wackler gesehen und kenne dies schon vom RPI und von unzählig geschrotteten Tablets meiner Kinder. Ferner sind Netzteile mit Micro-USB meist Ladegeräte und dann um die 1-3A = schon recht viel.
Laut Schaltplan schaut J7 gut aus: Ein Schraubterminal mit RM5.08 würde da genau passen. J4 müsste dann auf RPI stehen (?).
Wäre das korrekt/ sinnvoll oder wären andere PIN besser (welche)?
b)
Wieviel Milliampere sollten optimal zur Verfügung stehen?
Ich würde keck behaupten, 1A und mehr sind schon überdimensioniert.
Vielen Dank und beste Grüße
rob
OT: Ich glaube das Thema eBus usw. ist groß + komplex genug, um eine eigene Rubrik zu haben. Findet Ihr nicht? Angesichts der grandiosen Arbeit habt Ihr die Ebene "basteln" eh schon lange hinter Euch gelassen ;)
Viele Fragen passen imho nicht immer direkt zur Bestellung oder Inbetriebnahme und wären trotzdem noch zu allegemein für konkrete Hersteller-spezifische Threads (z.B. Gehäuse, Dockerkrams, andere Adapter am eBus usw.).
Zitat von: baumhous3 am 21 März 2021, 18:55:22
EBUSD_OPTS1="-d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=PATH"
EBUSD_OPTS2="-d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=/etc/ebusd --address=ff"
[/code]
die erste Zeile kann so nicht funktionieren mit "--configpath=PATH", denn PATH ist vermutlich mein Verzeichnis, in dem CSVs liegen, oder?
Zitatch würde den Adapter (LAN) doch lieber nicht via USB bestromen, sondern per Schraubterminal und stabilisiertem 3.3V-Netzteil.
Beim fliegenden Aufbau hatte ich einige Wackler gesehen und kenne dies schon vom RPI und von unzählig geschrotteten Tablets meiner Kinder. Ferner sind Netzteile mit Micro-USB meist Ladegeräte und dann um die 1-3A = schon recht viel.
Die Probleme mit dem USB Stecker kommen doch erst mit dem ununterbrochenen An-und Abstecken. Ich denke dass du den Adapter nicht öfter als 1-2x stecken wirst und dann gibt's auch keine Schrottung. Aber sei's drum.
ZitatLaut Schaltplan schaut J7 gut aus: Ein Schraubterminal mit RM5.08 würde da genau passen. J4 müsste dann auf RPI stehen (?).
Wäre das korrekt/ sinnvoll oder wären andere PIN besser (welche)?
Das sollte funktionieren, J4 sollte dann aber besser frei sein. Prinzipiell kann auf jedem Pin der
- entweder +3V3 verbunden hat und J4 frei ist
- oder auf RPI-3V3 liegt und J4 auf RPI steckt
eine Spannung von 3,3V eingespeist werden. den GND1 Pin kannst du von irgendwo nehmen. Aber fasse bloß nicht den J11 oder J12 an!
ZitatWieviel Milliampere sollten optimal zur Verfügung stehen?
Ich würde keck behaupten, 1A und mehr sind schon überdimensioniert.
Das hängt vor allem von der momentanen Bus-Aktivität ab, aber mehr als 100mA kommen da sicher nicht vor.
LG
Zitat von: Reinhart am 21 März 2021, 19:28:39
also --configpath=PATH wird nicht viel bringen, gib hier einen Pfad an sonst wird da nix gefunden oder laß ihn ganz weg wenn die die Online Konfiguration verwenden willst.
bei der MQTT Definition fehlen dir eine paar Parameter, vor allem die Topic.
Beispiel:
--mqttport=1883 --mqttjson --mqtthost=fhem --mqtttopic=ebusd/%circuit/%name --mqttchanges
LG
Zitat von: john30 am 21 März 2021, 22:22:11
die erste Zeile kann so nicht funktionieren mit "--configpath=PATH", denn PATH ist vermutlich mein Verzeichnis, in dem CSVs liegen, oder?
Ja, er soll sich immer das aktuelle dann Online ziehen.
Habe das ganze nun angepasst:
EBUSD_OPTS1="-d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --mqttchanges --scanconfig"
EBUSD_OPTS2="-d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --mqttchanges --scanconfig --configpath=/etc/ebusd --address=ff"
Jedoch kommt dann eine Meldung, zu einer invalid ConfigPath, wenn ich das komplett weg lasse.
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated)
Active: active (running) since Mon 2021-03-22 13:21:08 CET; 1min 3s ago
Docs: man:systemd-sysv-generator(8)
Process: 456 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
Tasks: 5 (limit: 4915)
CGroup: /system.slice/ebusd.service
└─494 /usr/bin/ebusd --pidfile /var/run/ebusd2.pid -d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --mqttchanges --scanconfig --co
Mär 22 13:21:08 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Mär 22 13:21:08 raspberrypi ebusd[456]: Starting ebusd1: ebusd2021-03-22 13:21:08.320 [main error] invalid configPath URL
Mär 22 13:21:08 raspberrypi ebusd[456]: failed!
Mär 22 13:21:08 raspberrypi ebusd[456]: Starting ebusd2: ebusd.
Mär 22 13:21:08 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2
signal: acquired
symbol rate: 41
max symbol rate: 60
min arbitration micros: 6
max arbitration micros: 21
min symbol latency: 7
max symbol latency: 17
reconnects: 0
masters: 2
messages: 87
conditional: 0
poll: 61
update: 4
address 04: slave #25, ebusd
address 37: master #18
address 3c: slave #18, scanned "MF=ENCON;ID= ;SW=-;HW=-", loaded "encon/3c.csv"
address ff: master #25, ebusd
dann setzt den ersten auch auf --configpath=/etc/ebusd da die ohnehin schon lokal installiert ist, aber nicht auf PATH.
LG
Warum klappt es denn nicht bei dem Pfad im Internet? Vorteil dort wäre an Updates entsprechend partizipieren zu können.
Beim lokalen Pfad lädt er nun beide:
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated)
Active: active (running) since Mon 2021-03-22 21:28:29 CET; 12min ago
Docs: man:systemd-sysv-generator(8)
Process: 445 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
Tasks: 9 (limit: 4915)
CGroup: /system.slice/ebusd.service
├─482 /usr/bin/ebusd --pidfile /var/run/ebusd1.pid -d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --mqttchanges --scanconfig --config
└─489 /usr/bin/ebusd --pidfile /var/run/ebusd2.pid -d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --mqttchanges --scanconfig --co
Mär 22 21:28:28 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Mär 22 21:28:29 raspberrypi ebusd[445]: Starting ebusd1: ebusd.
Mär 22 21:28:29 raspberrypi ebusd[445]: Starting ebusd2: ebusd.
Mär 22 21:28:29 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
Er sendet auch Daten für die KWL und von der Vaillant Heizung. Jedoch bei der Heizung nur die Polling. Ich habe ursprünglich für die Heizung einen Cronjob angelegt, der alle 5 Minuten ebusd/contrib/scripts/readall.sh ausführt. Wenn das Script ausgeführt wird, werden jedoch nur die Daten der KWL abgerufen, nicht der Heizung.
Er zeigt mir als Info und Scan Result auch nur an:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 22
max symbol rate: 64
min arbitration micros: 7
max arbitration micros: 10
min symbol latency: 7
max symbol latency: 15
reconnects: 0
masters: 2
messages: 87
conditional: 0
poll: 61
update: 4
address 04: slave #25, ebusd
address 37: master #18
address 3c: slave #18, scanned "MF=ENCON;ID= ;SW=-;HW=-", loaded "encon/3c.csv"
address ff: master #25, ebusd
pi@raspberrypi:~ $ ebusctl scan result
3c;ENCON; ;-;-
Geht es nicht beide dort angezeigt zu bekommen und das Script auf beide bzw. gezielt auf einen anzuwenden?
Auch das gezielte Abrufen eines Wertes klappt nicht:
pi@raspberrypi:~ $ ebusctl r -c 720 HwcStorageTemp
ERR: element not found
Zitat von: john30 am 19 März 2021, 14:28:01
das ist ja gut und zeigt, dass die Messagedefinition existiert.
Deine bai00.cfg passt nur nicht dazu, denn dort heißt es Hc1... statt Hwc...
probier doch erstmal `ebusctl w -c 430 HwcQuickVetoActive yes`
und wenn das funktioniert, kannst die bai00.cfg anpassen
Ich muss nochmal darauf eingehen.
Es muss schon Hc1 sein, weil Hwc ist Wasser! Deswegen kommen immer die 55 Grad (ist meine Wassertemperatur).
Also geht QuickVeto für den Heizkreis nicht :-\
Den rest deiner Fragen beantworte ich am WE.
@baumhous3
ich würde dir empfehlen nicht alles auf einen Schlag in Betrieb zu nehmen, sondern schrittweise. Schließ zunächst einen Adapter an, checke mit ebusctl i ob auch die csv Files geladen werden und kümmere dich um eine einfache Abfrage von benötigten Daten, aber nicht mit dem Script "readall.sh", das bringt über kurz oder lang dein Heizsystem außer Kontrolle und ist eigentlich nur für Tests gedacht.
Der eBus ist kein Hochgeschwindigkeitsbus und ist für solche Zwecke nicht konzipiert worden, eigentlich dient er nur der internen Steuerung der Geräte des Herstellers untereinander. So wie es jetzt aussieht, sendet der Adapter alle 5 Minuten 87 Anfragen an den Bus. Mich geht es auch nichts an, aber ich kann mir nicht vorstellen das man diesen Datenmüll auswerten will, höchstens für einen Techniker der an der Anlage einen Fehler sucht.
Wenn der erste Adapter dann tadellos funktioniert, hänge ihn ab und mach das gleiche mit dem zweiten. D.h jeder Adapter für sich muss einmal die csv laden, sonst klappt das nicht. Erst wenn dieser auch problemlos funktioniert, dann versuche es mit beiden. Du beginnst jetzt mit dem maximalen Ziel was wie man sieht dann kompliziert wird.
Es ist aber deine Entscheidung wie du vorgehst, was ich oben geschrieben habe ist nur ein Vorschlag komplexe Dinge in kleine logische Schritte zu teilen. Während der schrittweisen Inbetriebnahme wirst du dir nebenbei wertvolle Erkenntnisse über die funktionsweise aneignen können.
LG
Zitat von: baumhous3 am 22 März 2021, 21:45:21
Geht es nicht beide dort angezeigt zu bekommen und das Script auf beide bzw. gezielt auf einen anzuwenden?
du musst erstmal beide auf unterschiedliche Ports setzen, derzeit laufen beide auf 8888 und somit kannst du mittels ebusctl nur mit einem kommunizieren. Also in einer der beiden OPTS noch bspw. "-p 9998" dazu nehmen und diesen ebusd dann mit "ebusctl -p 9998" abfragen.
Zitat von: john30 am 21 März 2021, 11:13:24
was heißt das genau? Also im Sinne der Antwort vom ebusd.
dann bitte mehr Details dazu geben, so kann ich absolut nichts dazu sagen (ebusd Log, MQTT Topic samt Content und Antwort).
heißt was genau? wie ist die Antwort zum Kommando und wie setzt du es ab?
das würde dann wiederum an der Heizung liegen, denn mehr als die Message abschicken, kann ebusd auch nicht tun.
bist Du sicher, dass nicht ein anderes Gerät den Wert überschreibt?
Wie sehen denn jetzt deine EBUSD_OPTS aus?
Und bist Du noch auf der Wemos Verbindung?
Du hast zuletzt geschrieben, dass es jetzt stabil läuft. Wie ist denn jètzt das Setup?
So, nachdem nun seit gestern wieder einige Werte nicht kommen (Druck, Heizkurve, Heizmode, usw.), hier mal ein paar Daten.
Device in fhem:
Internals:
CID ebusd
DEF ebusd
DEVICETOPIC MQTT2_ebusd
FUUID 5e4e8943-f33f-5738-8a36-fcdbdf824cf307b7
FVERSION 10_MQTT2_DEVICE.pm:0.238430/2021-02-27
IODev ebusServer
LASTInputDev ebusServer
MSGCNT 722
NAME MQTT2_ebusd
NR 643
STATE Status:
1:true
Signal:
2:true
<br>Uptime: 0 000 02:53
TYPE MQTT2_DEVICE
ebusServer_MSGCNT 722
ebusServer_TIME 2021-03-25 12:31:40
Helper:
DBLOG:
_Aussentemp:
myDbLog:
TIME 1616671752.05854
VALUE 12.688
_Pumpenstatus:
myDbLog:
TIME 1616671752.05854
VALUE off
_Ruecklauf:
myDbLog:
TIME 1616671752.05854
VALUE 37.0
_Vorlauf:
myDbLog:
TIME 1616671752.05854
VALUE 36.0
_WWSpeicher:
myDbLog:
TIME 1616671752.05854
VALUE 51.0
updatecheck:
myDbLog:
TIME 1616661317.47189
VALUE "OK"
uptime:
myDbLog:
TIME 1616671621.00302
VALUE 10436
JSONMAP:
Status01_0_value _Vorlauf
Status01_1_value _Ruecklauf
Status01_2_value _Aussentemp
Status01_3_value _Warmwasser
Status01_4_value _WWSpeicher
Status01_5_value _Pumpenstatus
Status02_0_value _HWCMode
Status02_1_value _Maximaltemperatur
Status02_2_value _ReglerMaxTEMP
Status02_3_value _ReglerCurrentTemp
Status02_4_value _WWsoll
READINGS:
2021-03-25 12:31:15 DateTime_bdate_value 25.03.2021
2021-03-25 12:31:15 DateTime_btime_value 12:31:11
2021-03-25 12:31:15 DateTime_dcfstate_value valid
2021-03-25 12:31:15 DateTime_temp2_value 12.688
2021-03-25 09:26:39 DisplayedHc1RoomTempDesired_temp1_value 22.0
2021-03-25 09:26:39 DisplayedHwcStorageTemp_temp1_value 51.0
2021-03-24 23:06:27 Hc1HeatCurve_curve_value 1.40
2021-03-24 22:56:29 Hc1OPMode_0_name
2021-03-24 22:56:29 Hc1OPMode_0_value auto
2021-03-24 22:56:32 Hc1QuickVetoActive_yesno_value no
2021-03-24 22:46:27 Hc1QuickVetoTemp_temp1_value 22.0
2021-03-24 22:46:27 HcHours {
"hoursum2": {"value": 18027}}
2021-03-24 22:56:29 HwcHours {
"hoursum2": {"value": 2384}}
2021-03-24 22:56:29 HwcOPMode_0_name
2021-03-24 22:56:29 HwcOPMode_0_value auto
2021-03-23 12:33:41 HwcQuickVetoActive_yesno_value no
2021-03-23 12:17:52 HwcQuickVetoTemp_temp1_value 25.0
2021-03-24 22:56:29 HwcStarts {
"0": {"name": "", "value": 13100}}
2021-03-24 22:56:29 HwcTempDesired_temp1_value 55.0
2021-03-25 12:31:40 Mischventil Heizkreis
2021-03-24 22:56:32 PositionValveSet_0_name
2021-03-24 22:56:32 PositionValveSet_0_value 0
2021-03-23 12:02:52 ReturnTemp {
"temp": {"value": 44.81},
"tempmirror": {"value": 64818},
"sensor": {"value": "ok"}}
2021-03-25 12:31:35 SetMode_disablehc_value 0
2021-03-25 12:31:35 SetMode_disablehwcload_value 0
2021-03-25 12:31:35 SetMode_disablehwctapping_value 0
2021-03-25 12:31:35 SetMode_flowtempdesired_value 40.0
2021-03-25 12:31:35 SetMode_hcmode_value auto
2021-03-25 12:31:35 SetMode_hwctempdesired_value 55.0
2021-03-25 12:31:35 SetMode_releaseBackup_value 0
2021-03-25 12:31:35 SetMode_releaseCooling_value 0
2021-03-25 12:31:35 SetMode_remoteControlHcPump_value 0
2021-03-25 12:31:40 Status01_0_name temp1
2021-03-25 12:31:40 Status01_1_name temp1
2021-03-25 12:31:40 Status01_2_name temp2
2021-03-25 12:31:40 Status01_3_name temp1
2021-03-25 12:31:40 Status01_4_name temp1
2021-03-25 12:31:40 Status01_5_name pumpstate
2021-03-25 12:31:08 Status02_0_name hwcmode
2021-03-25 12:31:08 Status02_1_name temp0
2021-03-25 12:31:08 Status02_2_name temp1
2021-03-25 12:31:08 Status02_3_name temp0
2021-03-25 12:31:08 Status02_4_name temp1
2021-03-25 12:31:35 StatusCirPump_0_name
2021-03-25 12:31:35 StatusCirPump_0_value off
2021-03-24 22:56:29 WaterPressure_press_value 1.222
2021-03-24 22:56:29 WaterPressure_sensor_value ok
2021-03-25 12:31:40 _Aussentemp 12.688
2021-03-25 12:31:08 _HWCMode auto
2021-03-25 12:31:08 _Maximaltemperatur 60
2021-03-25 12:31:40 _Pumpenstatus on
2021-03-25 12:31:08 _ReglerCurrentTemp 80
2021-03-25 12:31:08 _ReglerMaxTEMP 75.0
2021-03-25 12:31:40 _Ruecklauf 34.0
2021-03-25 12:31:40 _Vorlauf 38.0
2021-03-25 12:31:40 _WWSpeicher 51.0
2021-03-25 12:31:08 _WWsoll 65.0
2021-03-25 12:27:00 formatedUptime 0 000 02:53
2021-03-25 12:29:11 id_counter_value 011789
2021-03-25 12:29:11 id_prefix_value 21
2021-03-25 12:29:11 id_product_value 0010004279
2021-03-25 12:29:11 id_suffix_value N8
2021-03-25 12:29:11 id_supplier_value 0001
2021-03-25 12:29:11 id_week_value 48
2021-03-25 12:29:11 id_year_value 10
2021-03-25 12:30:55 outsidetemp_temp2_value 12.688
2021-03-25 12:28:58 running true
2021-03-25 12:29:49 scan "finished"
2021-03-25 12:29:11 scan.08_HW_value 7401
2021-03-25 12:29:11 scan.08_ID_value BAI00
2021-03-25 12:29:11 scan.08_MF_value Vaillant
2021-03-25 12:29:11 scan.08_SW_value 0518
2021-03-25 12:29:37 scan.15_HW_value 2002
2021-03-25 12:29:37 scan.15_ID_value 43000
2021-03-25 12:29:37 scan.15_MF_value Vaillant
2021-03-25 12:29:37 scan.15_SW_value 0215
2021-03-25 12:29:11 signal true
2021-03-23 12:34:44 state Hc1QuickVetoActive_yesno_value
2021-03-25 09:35:07 subscriptions ebusd/#
2021-03-25 09:35:17 updatecheck "OK"
2021-03-25 12:31:35 uptime 160
2021-03-25 12:31:35 vdatetime_date_value 25.03.2021
2021-03-25 12:31:35 vdatetime_time_value 12:31:33
2021-03-25 12:28:57 version "ebusd 21.2.v21.2"
Attributes:
DbLogInclude .*
IODev ebusServer
alias Vaillant eBus
autocreate 1
devStateIcon 1.running:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
event-min-interval .*:300
getList Heizkreis1:noArg Hc1OPMode_0_value ebusd/430/Hc1OPMode/get
Heizkurve:noArg Hc1HeatCurve_curve_value ebusd/430/Hc1HeatCurve/get
SollTemperatur:noArg HwcTempDesired_temp1_value ebusd/430/HwcTempDesired/get
RaumSoll:noArg DisplayedHc1RoomTempDesired_temp1_value ebusd/430/DisplayedHc1RoomTempDesired/get
WarmwasserMode:noArg HwcOPMode_0_value ebusd/430/HwcOPMode/get
WarmwasserIst:noArg DisplayedHwcStorageTemp_temp1_value ebusd/430/DisplayedHwcStorageTemp/get
Wasserdruck:noArg WaterPressure_press_value ebusd/bai/WaterPressure/get
Zirkulationspumpe:noArg CirPump_onoff_value ebusd/430/CirPump/get
QuickVetoHeizung:noArg HwcQuickVetoActive_yesno_value ebusd/430/Hc1QuickVetoActive/get
QuickVetoTemp:noArg HwcQuickVetoTemp_temp1_value ebusd/430/Hc1QuickVetoTemp/get
QuickVetoWasser:noArg HwcQuickVetoActive_yesno_value ebusd/430/HwcQuickVetoActive/get
QuickVetoTempWasser:noArg HwcQuickVetoTemp_temp1_value ebusd/430/HwcQuickVetoTemp/get
Mischventil:noArg PositionValveSet_0_value ebusd/bai/PositionValveSet/get
WarmwasserSoll:noArg Status02_4_value ebusd/bai/Status02_4/get
group Zentrale
icon sani_boiler_temp
jsonMap Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp Status02_4_value:_WWsoll
readingList ebusd/global/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/global/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd:ebusd/global/version:.* version
ebusd:ebusd/global/running:.* running
ebusd:ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd:ebusd/scan\.08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd:ebusd/global/uptime:.* uptime
ebusd:ebusd/global/signal:.* signal
ebusd:ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
ebusd:ebusd/scan\.15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd:ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }
ebusd:ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd:ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd:ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }
ebusd:ebusd/bai/PositionValveSet:.* { json2nameValue($EVENT, 'PositionValveSet_', $JSONMAP) }
ebusd:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }
ebusd:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }
ebusd:ebusd/430/Hc1OPMode:.* { json2nameValue($EVENT, 'Hc1OPMode_', $JSONMAP) }
ebusd:ebusd/global/updatecheck:.* updatecheck
ebusd:ebusd/430/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }
ebusd:ebusd/430/Hc1QuickVetoActive:.* { json2nameValue($EVENT, 'Hc1QuickVetoActive_', $JSONMAP) }
ebusd:ebusd/430/DisplayedHc1RoomTempDesired:.* { json2nameValue($EVENT, 'DisplayedHc1RoomTempDesired_', $JSONMAP) }
ebusd:ebusd/430/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }
ebusd:ebusd/430/DisplayedHwcStorageTemp:.* { json2nameValue($EVENT, 'DisplayedHwcStorageTemp_', $JSONMAP) }
ebusd:ebusd/430/HwcOPMode:.* { json2nameValue($EVENT, 'HwcOPMode_', $JSONMAP) }
ebusd:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }
ebusd:ebusd/430/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }
ebusd:ebusd/430/HwcQuickVetoActive:.* { json2nameValue($EVENT, 'HwcQuickVetoActive_', $JSONMAP) }
ebusd:ebusd/430/HwcQuickVetoTemp:.* { json2nameValue($EVENT, 'HwcQuickVetoTemp_', $JSONMAP) }
ebusd:ebusd/broadcast/error:.* { json2nameValue($EVENT, 'error_', $JSONMAP) }
ebusd:ebusd/scan\x2e26/:.* { json2nameValue($EVENT) }
ebusd:ebusd/scan\x2e26/id:.* { json2nameValue($EVENT) }
ebusd:ebusd/bai/error:.* { json2nameValue($EVENT, 'error_bai_', $JSONMAP) }
ebusd:ebusd/global/error:.* { json2nameValue($EVENT, 'error_global_', $JSONMAP) }
ebusd:ebusd/430/error:.* { json2nameValue($EVENT, 'error_430_', $JSONMAP) }
ebusd:ebusd/broadcast/error:.* { json2nameValue($EVENT, 'error_broadcast_', $JSONMAP) }
ebusd:ebusd/430:.* { json2nameValue($EVENT, '430_', $JSONMAP) }
ebusd:ebusd/bai:.* { json2nameValue($EVENT, 'bai_', $JSONMAP) }
ebusd:ebusd/global:.* { json2nameValue($EVENT, 'global_', $JSONMAP) }
ebusd:ebusd/broadcast:.* { json2nameValue($EVENT, 'broadcast_', $JSONMAP) }
ebusd:ebusd/430/ACTOstorDetected:.* ebusd_430_ACTOstorDetected
ebusd:ebusd/430/actoSTOROPMode:.* ebusd_430_actoSTOROPMode
ebusd:ebusd/430/actostorstate:.* ebusd_430_actostorstate
ebusd:ebusd/430/ActualRoomTempDesiredHc1:.* ebusd_430_ActualRoomTempDesiredHc1
ebusd:ebusd/430/ActualWeekday:.* ebusd_430_ActualWeekday
ebusd:ebusd/430/adpPreHActive:.* ebusd_430_adpPreHActive
ebusd:ebusd/430/adpPreHCurrentRoomTemp:.* ebusd_430_adpPreHCurrentRoomTemp
ebusd:ebusd/430/adpPreHInSideTW:.* ebusd_430_adpPreHInSideTW
ebusd:ebusd/430/adpPreHMinutesBeforeFirstTW:.* ebusd_430_adpPreHMinutesBeforeFirstTW
ebusd:ebusd/430/adpPreHOutdoorTemp:.* ebusd_430_adpPreHOutdoorTemp
ebusd:ebusd/430/adpPreHOutdoorTempStart:.* ebusd_430_adpPreHOutdoorTempStart
ebusd:ebusd/430/adpPreHPreheatingTime:.* ebusd_430_adpPreHPreheatingTime
ebusd:ebusd/430/adpPreHRamp:.* ebusd_430_adpPreHRamp
ebusd:ebusd/430/adpPreHRoomTempDesired:.* ebusd_430_adpPreHRoomTempDesired
ebusd:ebusd/430/adpPreHRoomTempStart:.* ebusd_430_adpPreHRoomTempStart
ebusd:ebusd/430/adpPreHStarttime:.* ebusd_430_adpPreHStarttime
ebusd:ebusd/430/AssertFileName:.* ebusd_430_AssertFileName
ebusd:ebusd/430/AssertLineNumber:.* ebusd_430_AssertLineNumber
ebusd:ebusd/430/AutoOffMode:.* ebusd_430_AutoOffMode
ebusd:ebusd/430/B50418actDesFlowTemp:.* ebusd_430_B50418actDesFlowTemp
ebusd:ebusd/430/B51000FlowSetMonitor:.* ebusd_430_B51000FlowSetMonitor
ebusd:ebusd/430/B51000M10HwcFlowSetMon:.* ebusd_430_B51000M10HwcFlowSetMon
ebusd:ebusd/430/B51000M12DisableBitsMon:.* ebusd_430_B51000M12DisableBitsMon
ebusd:ebusd/430/B51000M14Monitor:.* ebusd_430_B51000M14Monitor
ebusd:ebusd/430/B51000M7OpModeMonitor:.* ebusd_430_B51000M7OpModeMonitor
ebusd:ebusd/430/B51000TempDesiredLoadingPump:.* ebusd_430_B51000TempDesiredLoadingPump
ebusd:ebusd/430/BaseDisplay:.* ebusd_430_BaseDisplay
ebusd:ebusd/430/BMUB51101BoilerFlowTemp:.* ebusd_430_BMUB51101BoilerFlowTemp
ebusd:ebusd/430/BMUB51101ErrorStatus:.* ebusd_430_BMUB51101ErrorStatus
ebusd:ebusd/430/BMUB51101HwcState:.* ebusd_430_BMUB51101HwcState
ebusd:ebusd/430/BMUB51101StorageTemp:.* ebusd_430_BMUB51101StorageTemp
ebusd:ebusd/430/BMUFlowTempOrVF1:.* ebusd_430_BMUFlowTempOrVF1
ebusd:ebusd/430/CalculatedKickStopTime:.* ebusd_430_CalculatedKickStopTime
ebusd:ebusd/430/ccTimer\x2eFriday:.* ebusd_430_ccTimer.Friday
ebusd:ebusd/430/ccTimer\x2eMonday:.* ebusd_430_ccTimer.Monday
ebusd:ebusd/430/ccTimer\x2eSaturday:.* ebusd_430_ccTimer.Saturday
ebusd:ebusd/430/ccTimer\x2eSunday:.* ebusd_430_ccTimer.Sunday
ebusd:ebusd/430/ccTimer\x2eThursday:.* ebusd_430_ccTimer.Thursday
ebusd:ebusd/430/ccTimer\x2eTuesday:.* ebusd_430_ccTimer.Tuesday
ebusd:ebusd/430/ccTimer\x2eWednesday:.* ebusd_430_ccTimer.Wednesday
ebusd:ebusd/430/ChimneySweepModeActive:.* ebusd_430_ChimneySweepModeActive
ebusd:ebusd/430/clearerrorhistory:.* ebusd_430_clearerrorhistory
ebusd:ebusd/430/ContinuosHeating:.* ebusd_430_ContinuosHeating
ebusd:ebusd/430/CountryVariant:.* ebusd_430_CountryVariant
ebusd:ebusd/430/CPLPLast24started:.* ebusd_430_CPLPLast24started
ebusd:ebusd/430/currenterror:.* ebusd_430_currenterror
ebusd:ebusd/430/Date:.* ebusd_430_Date
ebusd:ebusd/430/DisplayedRoomTemp:.* ebusd_430_DisplayedRoomTemp
ebusd:ebusd/430/EepromUpdateActive:.* ebusd_430_EepromUpdateActive
ebusd:ebusd/430/EnermanState:.* ebusd_430_EnermanState
ebusd:ebusd/430/errorhistory:.* ebusd_430_errorhistory
ebusd:ebusd/430/ExcessTemp:.* ebusd_430_ExcessTemp
ebusd:ebusd/430/FrostOverRideTime:.* ebusd_430_FrostOverRideTime
ebusd:ebusd/430/FrostProtectDelayMonitor:.* ebusd_430_FrostProtectDelayMonitor
ebusd:ebusd/430/FrostProtectionRequiredMonitor:.* ebusd_430_FrostProtectionRequiredMonitor
ebusd:ebusd/430/FrostProtectStateMonitor:.* ebusd_430_FrostProtectStateMonitor
ebusd:ebusd/430/Hc1ActualFlowTempDesired:.* ebusd_430_Hc1ActualFlowTempDesired
ebusd:ebusd/430/Hc1HcType:.* ebusd_430_Hc1HcType
ebusd:ebusd/430/Hc1ManualOPRoomTempDesired:.* ebusd_430_Hc1ManualOPRoomTempDesired
ebusd:ebusd/430/Hc1MinimalFlowTempDesired:.* ebusd_430_Hc1MinimalFlowTempDesired
ebusd:ebusd/430/Hc1NightTemp:.* { json2nameValue($EVENT, 'Hc1NightTemp_', $JSONMAP) }
ebusd:ebusd/430/Hc1PreOrContinuosHeatingActive:.* ebusd_430_Hc1PreOrContinuosHeatingActive
ebusd:ebusd/430/Hc1Pump:.* ebusd_430_Hc1Pump
ebusd:ebusd/430/Hc1PumpLast24started:.* ebusd_430_Hc1PumpLast24started
ebusd:ebusd/430/Hc1RoomTempSwitchOn:.* ebusd_430_Hc1RoomTempSwitchOn
ebusd:ebusd/430/Hc1SummerOffset:.* ebusd_430_Hc1SummerOffset
ebusd:ebusd/430/Hc2HcType:.* ebusd_430_Hc2HcType
ebusd:ebusd/430/HcMc1ConfigCPLPAsLP:.* ebusd_430_HcMc1ConfigCPLPAsLP
ebusd:ebusd/430/HcMc1CPLPState:.* ebusd_430_HcMc1CPLPState
ebusd:ebusd/430/HcMc1Detected:.* ebusd_430_HcMc1Detected
ebusd:ebusd/430/hcTimer\x2eFriday:.* ebusd_430_hcTimer.Friday
ebusd:ebusd/430/hcTimer\x2eMonday:.* ebusd_430_hcTimer.Monday
ebusd:ebusd/430/hcTimer\x2eSaturday:.* ebusd_430_hcTimer.Saturday
ebusd:ebusd/430/hcTimer\x2eSunday:.* ebusd_430_hcTimer.Sunday
ebusd:ebusd/430/hcTimer\x2eThursday:.* ebusd_430_hcTimer.Thursday
ebusd:ebusd/430/hcTimer\x2eTuesday:.* ebusd_430_hcTimer.Tuesday
ebusd:ebusd/430/hcTimer\x2eWednesday:.* ebusd_430_hcTimer.Wednesday
ebusd:ebusd/430/HolidayEndPeriod:.* ebusd_430_HolidayEndPeriod
ebusd:ebusd/430/HolidayRoomTemp:.* ebusd_430_HolidayRoomTemp
ebusd:ebusd/430/HolidayStartPeriod:.* ebusd_430_HolidayStartPeriod
ebusd:ebusd/430/HRUDetected:.* ebusd_430_HRUDetected
ebusd:ebusd/430/HwcActualTempDesired:.* ebusd_430_HwcActualTempDesired
ebusd:ebusd/430/HwcCircuitActive:.* ebusd_430_HwcCircuitActive
ebusd:ebusd/430/HwcLegioStartDay:.* ebusd_430_HwcLegioStartDay
ebusd:ebusd/430/HwcLegioStartTime:.* ebusd_430_HwcLegioStartTime
ebusd:ebusd/430/HwcLoadingIn430Active:.* ebusd_430_HwcLoadingIn430Active
ebusd:ebusd/430/HwcLoadingInBMUActive:.* ebusd_430_HwcLoadingInBMUActive
ebusd:ebusd/430/HwcLoadingOffset:.* ebusd_430_HwcLoadingOffset
ebusd:ebusd/430/HwcManualOPTempDesired:.* ebusd_430_HwcManualOPTempDesired
ebusd:ebusd/430/HwcParallelLoading:.* ebusd_430_HwcParallelLoading
ebusd:ebusd/430/HwcPressLowpostrunningtime:.* ebusd_430_HwcPressLowpostrunningtime
ebusd:ebusd/430/hwcTimer\x2eFriday:.* ebusd_430_hwcTimer.Friday
ebusd:ebusd/430/hwcTimer\x2eMonday:.* ebusd_430_hwcTimer.Monday
ebusd:ebusd/430/hwcTimer\x2eSaturday:.* ebusd_430_hwcTimer.Saturday
ebusd:ebusd/430/hwcTimer\x2eSunday:.* ebusd_430_hwcTimer.Sunday
ebusd:ebusd/430/hwcTimer\x2eThursday:.* ebusd_430_hwcTimer.Thursday
ebusd:ebusd/430/hwcTimer\x2eTuesday:.* ebusd_430_hwcTimer.Tuesday
ebusd:ebusd/430/hwcTimer\x2eWednesday:.* ebusd_430_hwcTimer.Wednesday
ebusd:ebusd/430/IsInHoliday:.* ebusd_430_IsInHoliday
ebusd:ebusd/430/KeyCodeforConfigMenu:.* ebusd_430_KeyCodeforConfigMenu
ebusd:ebusd/430/LcdContrastValue:.* ebusd_430_LcdContrastValue
ebusd:ebusd/430/LegioProtectActive:.* ebusd_430_LegioProtectActive
ebusd:ebusd/430/MaintenanceDate:.* ebusd_430_MaintenanceDate
ebusd:ebusd/430/MonitorEEpromInkonsiNumber:.* ebusd_430_MonitorEEpromInkonsiNumber
ebusd:ebusd/430/NameHc1:.* ebusd_430_NameHc1
ebusd:ebusd/430/NameHc2:.* ebusd_430_NameHc2
ebusd:ebusd/430/NameHwc:.* ebusd_430_NameHwc
ebusd:ebusd/430/OutsideTemp:.* ebusd_430_OutsideTemp
ebusd:ebusd/430/OutsideTempOffset:.* ebusd_430_OutsideTempOffset
ebusd:ebusd/430/PhoneNumber1:.* ebusd_430_PhoneNumber1
ebusd:ebusd/430/PhoneNumber2:.* ebusd_430_PhoneNumber2
ebusd:ebusd/430/PreheatingTime:.* ebusd_430_PreheatingTime
ebusd:ebusd/430/PreStopTime:.* ebusd_430_PreStopTime
ebusd:ebusd/430/PumpBlockingTimeMax:.* ebusd_430_PumpBlockingTimeMax
ebusd:ebusd/430/PumpEnergySaveCalculatedTimeMonitor:.* ebusd_430_PumpEnergySaveCalculatedTimeMonitor
ebusd:ebusd/430/PumpEnergySaveStateMonitor:.* ebusd_430_PumpEnergySaveStateMonitor
ebusd:ebusd/430/RoomTemp:.* ebusd_430_RoomTemp
ebusd:ebusd/430/RoomTempCorrection:.* ebusd_430_RoomTempCorrection
ebusd:ebusd/430/RoomTempOffsetSelfWarming:.* ebusd_430_RoomTempOffsetSelfWarming
ebusd:ebusd/430/Setpoints\x2eFriday:.* ebusd_430_Setpoints.Friday
ebusd:ebusd/430/Setpoints\x2eMonday:.* ebusd_430_Setpoints.Monday
ebusd:ebusd/430/Setpoints\x2eSaturday:.* ebusd_430_Setpoints.Saturday
ebusd:ebusd/430/Setpoints\x2eSunday:.* ebusd_430_Setpoints.Sunday
ebusd:ebusd/430/Setpoints\x2eThursday:.* ebusd_430_Setpoints.Thursday
ebusd:ebusd/430/Setpoints\x2eTuesday:.* ebusd_430_Setpoints.Tuesday
ebusd:ebusd/430/Setpoints\x2eWednesday:.* ebusd_430_Setpoints.Wednesday
ebusd:ebusd/430/SolModuleDetected:.* ebusd_430_SolModuleDetected
ebusd:ebusd/430/StartEepromUpdate:.* ebusd_430_StartEepromUpdate
ebusd:ebusd/430/StatusDcf:.* ebusd_430_StatusDcf
ebusd:ebusd/430/SummerWinterTimeAdjust:.* ebusd_430_SummerWinterTimeAdjust
ebusd:ebusd/430/Time:.* ebusd_430_Time
ebusd:ebusd/430/V430PluggedIn:.* ebusd_430_V430PluggedIn
ebusd:ebusd/430/VF1:.* ebusd_430_VF1
ebusd:ebusd/bai/AccessoriesOne:.* AccessoriesOne
ebusd:ebusd/bai/AccessoriesTwo:.* AccessoriesTwo
ebusd:ebusd/bai/ACRoomthermostat:.* ACRoomthermostat
ebusd:ebusd/bai/APCComStatus:.* APCComStatus
ebusd:ebusd/bai/APCLegioProtection:.* APCLegioProtection
ebusd:ebusd/bai/averageIgnitiontime:.* averageIgnitiontime
ebusd:ebusd/bai/BlockTimeHcMax:.* BlockTimeHcMax
ebusd:ebusd/bai/BoilerType:.* BoilerType
ebusd:ebusd/bai/ChangesDSN:.* ChangesDSN
ebusd:ebusd/bai/CirPump:.* CirPump
ebusd:ebusd/bai/clearerrorhistory:.* clearerrorhistory
ebusd:ebusd/bai/CounterStartattempts1:.* CounterStartattempts1
ebusd:ebusd/bai/CounterStartattempts2:.* CounterStartattempts2
ebusd:ebusd/bai/CounterStartAttempts3:.* CounterStartAttempts3
ebusd:ebusd/bai/CounterStartAttempts4:.* CounterStartAttempts4
ebusd:ebusd/bai/currenterror:.* currenterror
ebusd:ebusd/bai/dcfState:.* dcfState
ebusd:ebusd/bai/DCFTimeDate:.* DCFTimeDate
ebusd:ebusd/bai/DCRoomthermostat:.* DCRoomthermostat
ebusd:ebusd/bai/DeactivationsIFC:.* DeactivationsIFC
ebusd:ebusd/bai/DeactivationsTemplimiter:.* DeactivationsTemplimiter
ebusd:ebusd/bai/DeltaFlowReturnMax:.* DeltaFlowReturnMax
ebusd:ebusd/bai/DisplayMode:.* DisplayMode
ebusd:ebusd/bai/DSN:.* DSN
ebusd:ebusd/bai/DSNOffset:.* DSNOffset
ebusd:ebusd/bai/DSNStart:.* DSNStart
ebusd:ebusd/bai/EBusHeatcontrol:.* EBusHeatcontrol
ebusd:ebusd/bai/EbusSourceOn:.* EbusSourceOn
ebusd:ebusd/bai/EbusVoltage:.* EbusVoltage
ebusd:ebusd/bai/errorhistory:.* errorhistory
ebusd:ebusd/bai/expertlevel_ReturnTemp:.* expertlevel_ReturnTemp
ebusd:ebusd/bai/ExternalFaultmessage:.* ExternalFaultmessage
ebusd:ebusd/bai/externalFlowTempDesired:.* externalFlowTempDesired
ebusd:ebusd/bai/externalHwcSwitch:.* externalHwcSwitch
ebusd:ebusd/bai/ExternGasvalve:.* ExternGasvalve
ebusd:ebusd/bai/ExtFlowTempDesiredMin:.* ExtFlowTempDesiredMin
ebusd:ebusd/bai/ExtStorageModulCon:.* ExtStorageModulCon
ebusd:ebusd/bai/extWP:.* extWP
ebusd:ebusd/bai/FanHours:.* FanHours
ebusd:ebusd/bai/FanMaxSpeedOperation:.* FanMaxSpeedOperation
ebusd:ebusd/bai/FanMinSpeedOperation:.* FanMinSpeedOperation
ebusd:ebusd/bai/FanPWMSum:.* FanPWMSum
ebusd:ebusd/bai/FanPWMTest:.* FanPWMTest
ebusd:ebusd/bai/FanSpeed:.* FanSpeed
ebusd:ebusd/bai/FanSpeedOffsetMax:.* FanSpeedOffsetMax
ebusd:ebusd/bai/FanSpeedOffsetMin:.* FanSpeedOffsetMin
ebusd:ebusd/bai/FanStarts:.* FanStarts
ebusd:ebusd/bai/Flame:.* Flame
ebusd:ebusd/bai/FlameSensingASIC:.* FlameSensingASIC
ebusd:ebusd/bai/FloorHeatingContact:.* FloorHeatingContact
ebusd:ebusd/bai/FlowsetHcMax:.* FlowsetHcMax
ebusd:ebusd/bai/FlowsetHwcMax:.* FlowsetHwcMax
ebusd:ebusd/bai/FlowSetPotmeter:.* FlowSetPotmeter
ebusd:ebusd/bai/FlowTemp:.* FlowTemp
ebusd:ebusd/bai/FlowTempDesired:.* FlowTempDesired
ebusd:ebusd/bai/FlowTempMax:.* FlowTempMax
ebusd:ebusd/bai/Fluegasvalve:.* Fluegasvalve
ebusd:ebusd/bai/FluegasvalveOpen:.* FluegasvalveOpen
ebusd:ebusd/bai/Gasvalve3UC:.* Gasvalve3UC
ebusd:ebusd/bai/Gasvalve:.* Gasvalve
ebusd:ebusd/bai/GasvalveASICFeedback:.* GasvalveASICFeedback
ebusd:ebusd/bai/GasvalveUC:.* GasvalveUC
ebusd:ebusd/bai/GasvalveUCFeedback:.* GasvalveUCFeedback
ebusd:ebusd/bai/HcHours:.* HcHours
ebusd:ebusd/bai/HcPumpMode:.* HcPumpMode
ebusd:ebusd/bai/HcPumpStarts:.* HcPumpStarts
ebusd:ebusd/bai/HcStarts:.* HcStarts
ebusd:ebusd/bai/HcUnderHundredStarts:.* HcUnderHundredStarts
ebusd:ebusd/bai/HeatingSwitch:.* HeatingSwitch
ebusd:ebusd/bai/HoursTillService:.* HoursTillService
ebusd:ebusd/bai/HwcDemand:.* HwcDemand
ebusd:ebusd/bai/HwcHours:.* HwcHours
ebusd:ebusd/bai/HwcImpellorSwitch:.* HwcImpellorSwitch
ebusd:ebusd/bai/HwcPostrunTime:.* HwcPostrunTime
ebusd:ebusd/bai/HwcSetPotmeter:.* HwcSetPotmeter
ebusd:ebusd/bai/HwcStarts:.* HwcStarts
ebusd:ebusd/bai/HwcSwitch:.* HwcSwitch
ebusd:ebusd/bai/HwcTemp:.* HwcTemp
ebusd:ebusd/bai/HwcTempDesired:.* HwcTempDesired
ebusd:ebusd/bai/HwcTempMax:.* HwcTempMax
ebusd:ebusd/bai/HwcTypes:.* HwcTypes
ebusd:ebusd/bai/HwcUnderHundredStarts:.* HwcUnderHundredStarts
ebusd:ebusd/bai/HwcWaterflow:.* HwcWaterflow
ebusd:ebusd/bai/HwcWaterflowMax:.* HwcWaterflowMax
ebusd:ebusd/bai/Ignitor:.* Ignitor
ebusd:ebusd/bai/InitialisationEEPROM:.* InitialisationEEPROM
ebusd:ebusd/bai/IonisationVoltageLevel:.* IonisationVoltageLevel
ebusd:ebusd/bai/maintenancedata_HwcTempMax:.* maintenancedata_HwcTempMax
ebusd:ebusd/bai/maxIgnitiontime:.* maxIgnitiontime
ebusd:ebusd/bai/minIgnitiontime:.* minIgnitiontime
ebusd:ebusd/bai/ModulationTempDesired:.* ModulationTempDesired
ebusd:ebusd/bai/OutdoorstempSensor:.* OutdoorstempSensor
ebusd:ebusd/bai/OverflowCounter:.* OverflowCounter
ebusd:ebusd/bai/ParamToken:.* ParamToken
ebusd:ebusd/bai/PartloadHcKW:.* PartloadHcKW
ebusd:ebusd/bai/PartloadHwcKW:.* PartloadHwcKW
ebusd:ebusd/bai/PartnumberBox:.* PartnumberBox
ebusd:ebusd/bai/PowerValue:.* PowerValue
ebusd:ebusd/bai/PrAPSCounter:.* PrAPSCounter
ebusd:ebusd/bai/PrAPSSum:.* PrAPSSum
ebusd:ebusd/bai/PrEnergyCountHc1:.* PrEnergyCountHc1
ebusd:ebusd/bai/PrEnergyCountHc2:.* PrEnergyCountHc2
ebusd:ebusd/bai/PrEnergyCountHc3:.* PrEnergyCountHc3
ebusd:ebusd/bai/PrEnergyCountHwc1:.* PrEnergyCountHwc1
ebusd:ebusd/bai/PrEnergyCountHwc2:.* PrEnergyCountHwc2
ebusd:ebusd/bai/PrEnergyCountHwc3:.* PrEnergyCountHwc3
ebusd:ebusd/bai/PrEnergySumHc1:.* PrEnergySumHc1
ebusd:ebusd/bai/PrEnergySumHc2:.* PrEnergySumHc2
ebusd:ebusd/bai/PrEnergySumHc3:.* PrEnergySumHc3
ebusd:ebusd/bai/PrEnergySumHwc1:.* PrEnergySumHwc1
ebusd:ebusd/bai/PrEnergySumHwc2:.* PrEnergySumHwc2
ebusd:ebusd/bai/PrEnergySumHwc3:.* PrEnergySumHwc3
ebusd:ebusd/bai/ProductionByte:.* ProductionByte
ebusd:ebusd/bai/PrVortexFlowSensorValue:.* PrVortexFlowSensorValue
ebusd:ebusd/bai/PumpHours:.* PumpHours
ebusd:ebusd/bai/PumpHwcFlowNumber:.* PumpHwcFlowNumber
ebusd:ebusd/bai/PumpHwcFlowSum:.* PumpHwcFlowSum
ebusd:ebusd/bai/RemainingBoilerblocktime:.* RemainingBoilerblocktime
ebusd:ebusd/bai/ReturnRegulation:.* ReturnRegulation
ebusd:ebusd/bai/ReturnTemp:.* ReturnTemp
ebusd:ebusd/bai/ReturnTempMax:.* ReturnTempMax
ebusd:ebusd/bai/SecondPumpMode:.* SecondPumpMode
ebusd:ebusd/bai/SerialNumber:.* SerialNumber
ebusd:ebusd/bai/SetFactoryValues:.* SetFactoryValues
ebusd:ebusd/bai/SHEMaxDeltaHwcFlow:.* SHEMaxDeltaHwcFlow
ebusd:ebusd/bai/SHEMaxFlowTemp:.* SHEMaxFlowTemp
ebusd:ebusd/bai/SolPostHeat:.* SolPostHeat
ebusd:ebusd/bai/Statenumber:.* Statenumber
ebusd:ebusd/bai/Status16:.* Status16
ebusd:ebusd/bai/Status:.* Status
ebusd:ebusd/bai/Storageloadpump:.* Storageloadpump
ebusd:ebusd/bai/StorageLoadPumpHours:.* StorageLoadPumpHours
ebusd:ebusd/bai/StorageloadPumpStarts:.* StorageloadPumpStarts
ebusd:ebusd/bai/StorageLoadTimeMax:.* StorageLoadTimeMax
ebusd:ebusd/bai/StoragereleaseClock:.* StoragereleaseClock
ebusd:ebusd/bai/StorageTemp:.* StorageTemp
ebusd:ebusd/bai/StorageTempDesired:.* StorageTempDesired
ebusd:ebusd/bai/StorageTempMax:.* StorageTempMax
ebusd:ebusd/bai/TargetFanSpeed:.* TargetFanSpeed
ebusd:ebusd/bai/TargetFanSpeedOutput:.* TargetFanSpeedOutput
ebusd:ebusd/bai/TempDiffBlock:.* TempDiffBlock
ebusd:ebusd/bai/TempDiffFailure:.* TempDiffFailure
ebusd:ebusd/bai/TempGradientFailure:.* TempGradientFailure
ebusd:ebusd/bai/Templimiter:.* Templimiter
ebusd:ebusd/bai/TemplimiterWithNTC:.* TemplimiterWithNTC
ebusd:ebusd/bai/TempMaxDiffExtTFT:.* TempMaxDiffExtTFT
ebusd:ebusd/bai/Testbyte:.* Testbyte
ebusd:ebusd/bai/TimerInputHc:.* TimerInputHc
ebusd:ebusd/bai/ValveMode:.* ValveMode
ebusd:ebusd/bai/ValveStarts:.* ValveStarts
ebusd:ebusd/bai/VolatileLockout:.* VolatileLockout
ebusd:ebusd/bai/VolatileLockoutIFCGV:.* VolatileLockoutIFCGV
ebusd:ebusd/bai/VortexFlowSensor:.* VortexFlowSensor
ebusd:ebusd/bai/WarmstartDemand:.* WarmstartDemand
ebusd:ebusd/bai/WarmstartOffset:.* WarmstartOffset
ebusd:ebusd/bai/WaterHcFlowMax:.* WaterHcFlowMax
ebusd:ebusd/bai/WaterpressureBranchControlOff:.* WaterpressureBranchControlOff
ebusd:ebusd/bai/WaterpressureMeasureCounter:.* WaterpressureMeasureCounter
ebusd:ebusd/bai/WaterpressureVariantSum:.* WaterpressureVariantSum
ebusd:ebusd/bai/WP:.* WP
ebusd:ebusd/bai/WPPostrunTime:.* WPPostrunTime
ebusd:ebusd/bai/WPSecondStage:.* WPSecondStage
ebusd:ebusd/broadcast/datetime:.* datetime
ebusd:ebusd/broadcast/hwcStatus:.* hwcStatus
ebusd:ebusd/broadcast/id:.* id
ebusd:ebusd/broadcast/load:.* load
ebusd:ebusd/broadcast/queryexistence:.* queryexistence
ebusd:ebusd/broadcast/signoflife:.* signoflife
ebusd:ebusd/general/valuerange:.* valuerange
ebusd:ebusd/memory/eeprom:.* eeprom
ebusd:ebusd/memory/ram:.* ram
ebusd:ebusd/scan/id:.* id
ebusd:ebusd/bai/StatusCirPump:.* { json2nameValue($EVENT, 'StatusCirPump_', $JSONMAP) }
ebusd:ebusd/global/scan:.* scan
ebusd:ebusd/430/Hc1QuickVetoTemp:.* { json2nameValue($EVENT, 'Hc1QuickVetoTemp_', $JSONMAP) }
room Zentrale
setList Hc1OPMode_0_value:uzsuDropDown,auto,manual,off ebusd/430/Hc1OPMode/set $EVTPART1
Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/430/Hc1HeatCurve/set $EVTPART1
HwcOPMode_0_value:uzsuDropDown,auto,manual,off ebusd/430/HwcOPMode/set $EVTPART1
HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/430/HwcTempDesired/set $EVTPART1
Hc1QuickVetoActive_yesno_value:uzsuDropDown,yes,no ebusd/430/Hc1QuickVetoActive/set $EVTPART1
Hc1QuickVetoTemp_temp1_value:uzsuDropDown,20.0,21.0,22.0,23.0,24.0,25.0 ebusd/430/Hc1QuickVetoTemp/set $EVTPART1
HwcQuickVetoActive_yesno_value:uzsuDropDown,yes,no ebusd/430/HwcQuickVetoActive/set $EVTPART1
getKnown:noArg ebusd/list onlyknown
getAll:noArg ebusd/list
stateFormat Status:
1:running
Signal:
2:signal
<br>Uptime: formatedUptime
userReadings Mischventil {ReadingsVal($name,"PositionValveSet_0_value",0)==0?"Heizkreis":
ReadingsVal($name,"PositionValveSet_0_value",0)==100?"Warmwasser":
ReadingsVal($name,"PositionValveSet_0_value",0)==40?"Mittelstellung":"unknown",},
formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
webCmdLabel HK Mode
:Heizkurve
:WW Mode
:Wassertemperatur
:QuickVeto
:QuickVeto TemperaturAbruf der Daten auf zwei Wegen.
1. im MQTT Device (siehe auch oben):
Heizkreis1:noArg Hc1OPMode_0_value ebusd/430/Hc1OPMode/get2. über den MQTT Server:
set ebusServer publish ebusd/430/Hc1HeatCurve/getEBUSD_OPTS:
--scanconfig --accesslevel=* --latency=20000 -d enh:10.11.0.75:9999 --loglevel=debug --address=ff --mqtt....ebusd.log im Anhang.
esp Config als Screenshot im Anhang.
Wenn ich es richtig verstanden habe, müsste man die "vaillant/08.hmu.csv" erweitern, um den Live Monitor auslesen zu können. Anscheinend gibt es dazu schon ein erweitertes csv, wurde aber noch nicht gemerged. Wäre es möglich, dieses csv einzuchecken? ::)
https://github.com/john30/ebusd-configuration/pull/160
Hallo zusammen,
mein Adapter ist ebenfalls angekommen und bereits per USB eingebunden. Vielen Dank für die Entwicklung und die vielen Ressourcen und Infos ans gesamte Team!
Ich bin nun an einem Punkt angekommen, wo ich eine Rückfrage habe. Vermutlich liegt mein Problem aber eher irgendwo zwischen MQTT und FHEM. Aber wer weiß...
Ich nutze den Adapter per USB am RPi. Verwendet wird eine Anlage von Wolf, weshalb die .csv-Files ein echter Krampf sind, aber grundsätzlich habe ich es am laufen. Eine 15.csv und f6.csv habe ich grundsätzlich auch am Speicherort liegen, keine Ahnung warum diese nicht geladen wird.
EBUSD_OPTS="--scanconfig --accesslevel=* --loglevel=debug --latency=20 --configpath=/etc/ebusd/wolf/de -d enh:/dev/ttyUSB0 --address=ff --mqttport=1883 --mqttjson --mqtthost=127.0.0.1 --mqtttopic=ebusd/%circuit/%name"
version: ebusd 21.2.v21.2-12-g86b700c
update check: revision v21.2 available, broadcast.csv: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 89
min arbitration micros: 338
max arbitration micros: 448
min symbol latency: 11
max symbol latency: 13
reconnects: 0
masters: 6
messages: 101
conditional: 0
poll: 0
update: 6
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Kromschroeder;ID= 3L ;SW=0300;HW=6830", loaded "kromschroeder/08.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-", loaded "kromschroeder/35.csv"
address 51: slave, scanned "MF=Kromschroeder;ID= ;SW=0208;HW=-", loaded "kromschroeder/51.csv"
address 70: master #4
address 75: slave #4, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-", loaded "kromschroeder/75.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=-"
address ff: master #25, ebusd
Verknüpft ist FHEM nun mittels MQTT2. Server und Client sind entsprechend des Artikels EBUS-MQTT2 "https://wiki.fhem.de/wiki/EBUS-MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2)" eingerichtet.
Das Gerät "MQTT2_ebusd" ist als "eBus-Daemon-Splitter" eingerichtet und funktioniert auch. Die Broadcastbotschaften kommen regelmäßig an. Es wird dann auch noch ein weiteres Gerät (z.B. MQTT2_ebusd_21.2_1908) automatisch angelegt. Wenn jetzt über den Timer Aktualisierungen über MQTT angefragt werden, dann landen die Readings auch in diesem Gerät. (Leider nicht auch in dem Splitter, dann hätte ich das Problem gar nicht erst)
Jetzt mein Problem / Frage:
Sobald ich ebusd neustarte (was momentan zum Einrichten sehr häufig passiert - logischerweise auch wenn ich den Pi mal Neustarte), dann wird in FHEM ein weiteres Gerät "MQTT2_ebusd_21.2_XYZ" angelegt. (Endung entsprechend irgendwie anders)
Das alte Gerät MQTT2_ebusd_21.2_1908 wird dann nicht weiter bedient. Und genau hier komme ich nicht weiter, wenn ich jetzt die Readings verwenden möchte, da sich das Device ja ändern kann. Wie kann ich das lösen?
Herzlichen Dank und Grüße an alle!
ah ja, da läuft noch irgendwas nicht rund.
Attributes:
autocreate complex
rawEvents .*
room MQTT2_DEVICE
verbose 2
Kannst du am Server checken ob die Attribute passen, vor allem autocreate complex?
Attributes:
IODev ebusMQTT
autocreate 1
bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"
und hier noch die Attribute vom MQTT2_ebusd, bitte auch vergleichen ob die Regexp soweit passen.
Landen eigentlich alle falsch oder nur bestimmte? Da du eine Wolf hast könnte ich mir eventuell vorstellen das wir in diesem Fall die regexp noch etwas anpassen müssen.
LG
Hallo,
da ich auch zu den Empfängern des EbusD Adapter 3 gehöre, erst einmal an dieser Stelle meinen großen Dank an John30 und Reinhart für ihre Arbeit.
Mein Aktuelles Heizsystem und Steuerung:
- Vaillant atmoTEC plus VCW 194/4-5
- Vaillant calorMATIC VRT 350
- Mini-ITX (Debian 10 Buster), IOBroker, Ebusd-Daemon, Homematic IP Thermostate, Homematic CCU2, Zigbee, u.v.m.
Ebusd-Daemon Konfiguration:
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d enh:192.168.xxx.8:9999 -p 8888 --scanconfig=full --configpath=/etc/ebusd/ --loglevel=error -l /var/log/ebusd.log --httpport=8889 --htmlpath=/var/www/html/ --accesslevel=* --latency=20000 --pollinterval=300 --mqttchanges --mqttjson --mqtttopic=ebusd/%circuit/%name --mqtthost=192.168.xxx.4 --mqttport=1883 --mqttuser=iobroker --mqttpass=topsecret"
Ausgabe ebusctl -i
ebusd@iobroker:~$ ebusctl i
version: ebusd 21.2.v21.2
update check: OK, vaillant/15.350.csv: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 116
min arbitration micros: 1
max arbitration micros: 16
min symbol latency: 8
max symbol latency: 56
reconnects: 0
masters: 3
messages: 356
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=35000;SW=0114;HW=7102", loaded "vaillant/15.350.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Kurzer Mittschnitt mit einzigem Eintrag:
2021-03-24 02:33:41.956 [main error] unable to load scan config 26: no file from vaillant with prefix 26 matches ID "35000", SW0114, HW7102
2021-03-24 02:33:41.956 [main error] scan config 26: ERR: element not found
Beim ersten Start kamen keine Datenpunkte beim IOBroker an und mit ebusctl konnte ich auch keine Datenpunkte auslesen.
Die vorhandene orginale /etc/ebusd/vaillant/15.350.csv funktionierte bei mir nicht, so habe ich den inhalt der /etc/ebusd/vaillant/15.370.csv genommen und die ersten beiden Zeilen angepasst.
Danach kamen dann auch die Datenpunkte, die ich einmalig über "ebusdctl" über die Konsole abgefragt habe, beim IOBroker im dortigen "ebus.0"-Adpater an und werden auch schön artig alle 5 Minuten (IOBroker Adpater Einstellung) aktuallisiert.
Nun zu meinem Problem, bei dem ich mir gerade so die Zähne bischen ausbeisse:
Über IOBroker hatte ich bereits einen MQTT-Server in Betrieb um damit den Status meiner Sonoff/Tasmota Geräte auslesen und auch über Blockly oder Node-Red nach belieben ändern zu können. Nun taucht zwar der Ebusd dort auch auf aber nur mit einer Reisionsnummer und ALIVE state (siehe angehängtes Bild!) auf. Seltsam ist der Topic, da ich jenen ja in der Ebusd Konfiguration bereits mit "ebusd" vorgegeben hatte und dort hinter aber ein "_21" gehängt ist (Ebusd Version?) und als "%circuit" auch nur die Revisionsnummer kommt, wobei diese sich jedesmal ändert beim neustart des Ebusd-Daemon.
Habe auch mal den Loglevel geändert auf "notice" und konnte sehen, das die Verbindung zum IOBroker MQTT aufgebaut wurde:
2021-03-27 01:00:05.108 [main notice] ebusd 21.2.v21.2 started with full scan on enhanced device 192.168.xxx.8:9999
2021-03-27 01:00:05.174 [bus notice] bus started with own address 31/36
2021-03-27 01:00:05.178 [mqtt notice] connection established
2021-03-27 01:00:05.208 [bus notice] signal acquired
2021-03-27 01:00:05.873 [bus notice] device status: reset
2021-03-27 01:00:06.324 [bus notice] new master 10, master count 2
2021-03-27 01:00:06.391 [bus notice] new master 03, master count 3
Im Prinzip kann ich schon mit Blockly und Node-Red schon einmal die ersten Einstellungen über Ebusd und dem Adapter 3 erfolgreich nach belieben verändern, jedoch wünsche ich mir ebenfalls eine MQTT Integration und würde mich über Hilfestellung in dieser Sache freuen ...
Hallo Mümmelmann,
wenn du Messdaten benötigst musst du die per "get" via MQTT anfordern.
Beispiel:
set ebusMQTT publish ebusd/bai/WaterPressure/get
set ebusMQTT publish ebusd/bai/FlowTemp/get
Baue dir dazu eine Routine die das für dich erledigt! Der Adapter selbst lausch ja nur mit liefert somit nur die Broadcast Daten die regelmäßig am Bus kommen. Eventuell hilft dir das Wiki (https://wiki.fhem.de/wiki/EBUS-MQTT2) weiter.
LG
Zitat von: Reinhart am 27 März 2021, 09:26:18
Hallo Mümmelmann,
wenn du Messdaten benötigst musst du die per "get" via MQTT anfordern.
Beispiel:
set ebusMQTT publish ebusd/bai/WaterPressure/get
set ebusMQTT publish ebusd/bai/FlowTemp/get
Baue dir dazu eine Routine die das für dich erledigt! Der Adapter selbst lausch ja nur mit liefert somit nur die Broadcast Daten die regelmäßig am Bus kommen. Eventuell hilft dir das Wiki (https://wiki.fhem.de/wiki/EBUS-MQTT2) weiter.
LG
Hallo Reinart,
mein Prblem ist, dass ich das nicht verstehe und am grübeln bin, wie man das umsetzt. Wenn ich z.B. in der Konsole folgendes eingebe:
ebusd@iobroker:~$ ebusctl
localhost: set ebusMQTT publish ebusd/bai/FlowTemp/get;
ERR: command not found
localhost: set ebusMQTT publish ebusd/350/DisplayedHc1RoomTempDesired/get
ERR: command not found
localhost:
erhalte ich diese Rückmeldung ....
LG
das Beispiel mit "get" nicht in der Konsole eingeben. Das gebe ich in Fhem zum Testen in die Befehlszeile ein oder besser ich baue eine Timer gesteuerte Abfrage.
Ich kenne leider ioBroker nicht, deshalb kann ich dir auch nicht sagen wie das dort funktioniert, aber das wird sicher im Forum dort genauer beschrieben sein.
LG
Hallo Reinhart,
Die Resonanz im IOBroker Forum in Sachen EbusD ist da sehr, sehr bescheiden, daher bin ich erst einmal hier hin ausgewichen.
zum besseren Verständnis zur Funktionsweise MQTT <-> EBusd:
Wenn der Ebusd-Daemon mit MQTT Parametern gestartet wird, verbindet er sich zwar mit dem MQTT Server, sendet aber von sich aus keine peridoischen MQTT-Daten zum MQTT-Server (wie man es z.B. von Tasmota kennt), auch wenn man per "ebusctl" z.B. den Datenpunkt "FlowTemp" zuvor mit "ebusctl r FlowTemp" einmalig abgerufen hat (und somit der Datenpunkt "FlowTemp" automatisch künftig gepollt wird)?
Wenn ich aus der FHEM-Doku (bin kein FHEM Nutzer, daher bitte schlagen wenn ich falsch liege) entnehmen soll, das ich zwischen dem MQTT-Broker und EBusD einen virtuellen Adpater zum pollen von Abfragen packen muss zur Kommunikation zwischen beiden, verstehe ich die Logik der MQTT Unterstützung des EbusD leider nicht.
ich glaube du denkst da schon zu kompliziert, bei Tasmota ist es ja so, dass du die "Telemetric period" einstellst und die sorgt dafür das die Messdaten gesendet werden. In Fhem ist das ganz einfach Zeit gesteuerte Abfragen ( Timer ) zu definieren und ich glaube bei IOBroker muss das auch so funktionieren, denn dort kannst du ja auch Lichtschalter mit MQTT einschalten, also MQTT senden!
Mit ebusctl hat das nix zu tun, das ist nur ein Werkzeug um von der Konsole Überprüfungen und Tests durchführen zu können, eben Messdaten abfragen. Auch wenn du damit Werte abfragst, werden die in Zukunft nicht gepollt!
Schau mal hier, (https://www.smarthome-tricks.de/software-iobroker/der-mqtt-adapter/) vielleicht hilft dir das weiter, da ist der Vorgang "subscribe" relativ gut beschrieben!
oder hier (https://crycode.de/homepi-einbindung-von-mqtt-in-iobroker)
LG
Zitat von: Reinhart am 27 März 2021, 17:02:36
ich glaube du denkst da schon zu kompliziert ...
Wahre Worte, wahre Worte ... Fehler gefunden, beseitigt, Daten kommen jetzt einwandfrei ...
Ursache: Im IOBroker hatte ich den Sonoff MQTT Broker am laufen, der in Kombination mit Tasmota Devices sich bestens bewährt hat bei mir. Erst Dein Link zu der Seite mit den smarten Tricks brachte den Kronleuchter im Kopf zum leuchten, denn der Sonoff MQTT Broker fragt ausschließlich nur Sonoff/Tasmota typische States ab beim verbinden des jeweiligen Device ab, aber nicht welche States es denn so alle noch zu bieten hat. Also habe ich mal flux einen normalen reinen MQTT Broker Adapter zusätzlich im IOBroker installiert und den Port von diesem mal geringfügig von 1883 (da läuft ja bei mir schon der Sonoff/Tasmota Broker) auf 1884 geändert. Der zweite MQTT Broker fragt nun den Clienten beim verbinden mal ganz nett nach, was er denn so alles an States zu bieten hat und siehe da, die Daten kommen nun zu Hauf. Zu beachten ist, das hier nur jene Werte kommen, die bereits schon einmal beim Ebusd-Serer abgefragt wuden. Um wirklich ALLE Werte zu bekommen, KÖNNTE man EINMALIG das readall.sh Script von John einmal laufen lassen, wobei zu beachten ist, das der vorhandene ebus keine Highspeed-Schnittstelle ist und man sich auf die tatsächlich nur benötigten Werte beschränken sollte. Für meinen Teil hat die readall.sh bestens funktioniert und trotz der vielen zu aktuallisierenden Datenpunkten über den ebus merke ich in meinem Fall keine Einschränkungen, was aber nicht unbedingt heißen soll, das es bei anderen Anwendern nicht dazu kommen könnte ... ::)
Manchmal sieht man den Wald vor lauter Bäumen nicht mehr ... ;D
Vielen Dank für die Geduld und den Support
LG
recht viel habe ich eh nicht dazu beitragen können weil ich IOBroker nicht kenne und im Prinzip konntest du durch den Link die Ursache selbst finden.
Danke für deine Erklärung, das hilft anderen sicher auch weiter!
Hauptsache es läuft jetzt wieder!
LG
Reinhart
Hallo,
ich habe heute meinen RPi-Adapter in Betrieb genommen. Vielen Dank für Eure Arbeit.
Meine Erfahrungen dazu:
- Installation des aktuellen ebusd aus den Packetquellen führt zu einem "segmentation fault" beim start.
(auf stretch und einem neu aufgesetzten buster das selbe Verhalten)
-> Kompilierung aus den Sourcen funktioniert.
Ich nutze den Adapter an einer WOLF CGB2-20 mit ECMD und gaebus (ist so gewachsen) auf einem PI B 2.
Ich hatte vorher einen selbstbestückten Adapter aus dem Forum in Betrieb.
Bis auf das oben geschrieben Problem mit dem ebusd war der Umstieg problemlos.
im Log sehe ich häufiger:
2021-03-27 21:03:35.177 [bus error] device status: eBUS comm error: framing
2021-03-27 21:03:35.179 [bus error] arbitration start error
Grüße
druschba
Hallo zusammen,
dieses Wochenende habe ich endlich Zeit gefunden, mich mit dem Adapter auseinanderzusetzen.
Schon mal vorab: Ihr habt echt einen super Job gemacht!
Für mich ist sowohl ebus als auch mqtt, welches ich benutzen möchte, Neuland, daher hier meine bisherigen Erfahrungen:
Als Heizungsanlage habe ich:
- Vaillant ecoTEC Plus VC 146/5
- Vaillant AuroMATIC VRS620
Die Installation von ebusd unter Raspian Buster lief bis auf eine Sache wie beschrieben durch:
Es wurde keine ebusd.service Datei angelegt. Im deb-Paket selbst ist die service-Datei auch nicht vorhanden.
Ich habe die Datei direkt aus dem Repo geladen.
Eine kleine Änderung musste ich in der Datei noch vornehmen, da sich systemd daran gestört hat:
PIDFile=/run/ebusd.pidDanach startete ebusd ohne Fehler und hat folgende Geräte ausgegeben:
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ff: master #25, ebusdDie beiden Geräte unter Adresse 23 und 25 lädt ebusd relativ selten.
Ein
ebusctl scan 23 erkennt dann zwar das Gerät aber lädt die dazugehörige Konfigurationsdatei nicht.
Ich muss relativ häufig das Kommando
reload durchführen, bis ebusd diese einmal findet.
Kann es sein, dass ich den enhanced Mode nicht verwenden sollte, oder hat das damit nichts zu tun?
Zu MQTT hätte ich auch noch zwei Fragen. Ziel soll sein, die Daten in eine Graphite-DB zu schreiben, um mit Grafana darauf zuzugreifen:
Wenn ich einen Wert abfrage, z.B.:
# mosquitto_pub -h localhost -t 'ebusd/sc/Coll1Sensor/get' -m '?'bekomme ich die Werte immer doppelt zurück. Ist das normal?
# mosquitto_sub -v -h localhost -p 1883 -t 'ebusd/sc/#'
ebusd/sc/Coll1Sensor/get ?
ebusd/sc/Coll1Sensor 14.75;ok
ebusd/sc/Coll1Sensor 14.75;okDes Weiteren kann ich lt Doku ein Polling für Werte aktivieren, z.B. mit:
# mosquitto_pub -h localhost -t 'ebusd/sc/Coll1Sensor/get' -m '?9'Wie kann man das wieder deaktivieren außer ebusd zu restarten?
Wenn das Polling aktiv ist, kommen die Werte auch nur noch einmal.
Anbei noch ein Foto meines Raspberry "Sandwiches". Ich habe noch den PoE-HAT dazwischen.
Das Ganze ist in einem Hutschienengehäuse, an dem ich im wahrsten Sinne des Wortes noch feilen muss ;)
Viele Grüße und nochmals Danke!
Reinhard
Zitat von: Reinhart am 26 März 2021, 19:51:36
ah ja, da läuft noch irgendwas nicht rund.
Attributes:
autocreate complex
rawEvents .*
room MQTT2_DEVICE
verbose 2
Kannst du am Server checken ob die Attribute passen, vor allem autocreate complex?
Attributes:
IODev ebusMQTT
autocreate 1
bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"
und hier noch die Attribute vom MQTT2_ebusd, bitte auch vergleichen ob die Regexp soweit passen.
Landen eigentlich alle falsch oder nur bestimmte? Da du eine Wolf hast könnte ich mir eventuell vorstellen das wir in diesem Fall die regexp noch etwas anpassen müssen.
LG
Hallo in die Runde,
ja der Server ist in meinen Augen richtig konfiguriert:
Internals:
CONNECTS 4
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 17
FUUID 605b0c8a-f33f-f777-760d-fd2b43f0a0d6d390
NAME ebusMQTT
NR 56
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2021-03-27 17:30:51 RETAIN {"ebusd/global/running":"true","ebusd/global/scan":"\u0022finished\u0022","ebusd/global/signal":"true","ebusd/global/updatecheck":"\u0022revision v21.2 available, broadcast.csv: different version available\u0022","ebusd/global/version":"\u0022ebusd 21.2.v21.2-12-g86b700c\u0022"}
2021-03-29 08:38:10 lastPublish ebusd/MM1/ST1/get:
2021-03-26 14:37:26 nrclients 1
2021-03-26 14:33:19 state Initialized
clients:
ebusMQTT_127.0.0.1_40760 1
retain:
ebusd/global/running:
ts 1616765846.76345
val true
ebusd/global/scan:
ts 1616765875.79951
val "finished"
ebusd/global/signal:
ts 1616862651.66903
val true
ebusd/global/updatecheck:
ts 1616765995.89392
val "revision v21.2 available, broadcast.csv: different version available"
ebusd/global/version:
ts 1616765846.72029
val "ebusd 21.2.v21.2-12-g86b700c"
Attributes:
autocreate complex
rawEvents .*
room MQTT2_SERVER
verbose 2Aufgefallen ist mir, dass deine hier angegebene RegExp eine andere ist als im Wiki steht. (Siehe Anhang)
Außerdem fehlte mir das "rawEvents .*", dass hatte ich vorher nicht drin, da es auch nicht im Wiki steht.
Ich habe jetzt mal deine RegExp und das rawEvents eingefügt. Es ist weiterhin funktionsfähig, erzeugt beim Neustarten des Ebusd allerdings auch weiterhin ein neues Device.
Auf deine Frage, ob eigentlich alle falsch landen oder nur bestimmte, kann ich Dur nur wie folgt antworten:
Es gibt bei mir neben dem MQTT2_ebusd immer nur ein weiteres Device (und das wird auch immer wieder neu angelegt). Ursprünglich hatte ich auch gedacht/verstanden, dass mehrere erstellt werden müssten. Je geladener .csv ein Device??
Ich muss ehrlicherweise gestehen, dass ich noch nicht verstanden habe auf welchen Trigger hin das neue Device angelegt wird, bzw. wie erkannt werden müsste, dass ja bereits ein Device besteht. Dafür habe ich das Zusammenspiel von MQTT und FHEM noch nicht genau genug verstanden, da ich für den Bus-Adapter erstmalig MQTT einsetze.
Von ähnlichen Problemen (egal ob Wolf [bei mir übrigens COB-20] oder anderen Heizgeräten) habe ich bisher auch leider noch nicht gelesen.
LG
poste bitte mal ein "list" vom Device wo die alle falsch landen!
zum Beispiel:
list MQTT2_ebusd_bai
Internals:
CID ebusd_bai
DEF ebusd_bai
DEVICETOPIC MQTT2_ebusd_bai
FUUID 5c9144bc-f33f-27bd-8f79-fe0e0b9e014cc7ee
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 27591
NAME MQTT2_ebusd_bai
NR 1851
STATE ???
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 27591
ebusMQTT_TIME 2021-03-29 09:32:57
JSONMAP:
Status01_0_value _Vorlauf
Status01_1_value _Ruecklauf
Status01_2_value _Aussentemp
Status01_3_value _Warmwasser
Status01_4_value _WWSpeicher
Status01_5_value _Pumpenstatus
Status02_0_value _HWCMode
Status02_1_value _Maximaltemperatur
Status02_2_value _ReglerMaxTEMP
Status02_3_value _ReglerCurrentTemp
READINGS:
2021-02-09 19:33:10 AATemp {
"temp": {"value": 0.00},
"tempmirror": {"value": null},
"sensor": {"value": "cutoff"}}
2021-03-18 11:18:54 CounterStartattempts1_temp0_value 30
2021-03-29 09:32:38 DateTime_bdate_value -.-.-
2021-03-29 09:32:38 DateTime_btime_value 21:19:57
2021-03-29 09:32:38 DateTime_dcfstate_value nosignal
2021-03-29 09:32:38 DateTime_temp2_value 15.750
2021-03-18 11:18:53 DeactivationsIFC_0_name
2021-03-18 11:18:53 DeactivationsIFC_0_value 19
2021-03-29 08:53:11 FanHours_hoursum2_value 11132
2021-03-29 09:23:20 FanSpeed_0_name
2021-03-29 09:23:20 FanSpeed_0_value 0
2021-02-09 19:34:28 FanStarts {
"cntstarts2": {"value": 49}}
2021-03-29 09:29:12 FlowTempDesired_temp_value 34.00
2021-03-29 09:29:12 FlowTemp_sensor_value ok
2021-03-29 09:29:12 FlowTemp_temp_value 32.19
2021-03-29 09:23:21 HcHours_hoursum2_value 9737
2021-03-28 19:23:11 HcStarts_0_name
2021-03-28 19:23:11 HcStarts_0_value 70900
2021-03-25 10:58:01 HwcHours_hoursum2_value 1032
2021-03-18 11:18:54 HwcSetPotmeter_temp_value 49.00
2021-03-29 09:23:23 HwcStarts_0_name
2021-03-29 09:23:23 HwcStarts_0_value 137900
2021-03-29 09:13:13 OutdoorstempSensor_sensor_value ok
2021-03-29 09:13:13 OutdoorstempSensor_temp_value 14.31
2021-03-18 11:18:53 PartloadHcKW_power_value 18
2021-03-17 03:38:45 PrEnergyCountHc1 {
"0": {"name": "", "value": 21645124}}
2021-03-17 03:38:45 PrEnergyCountHwc1 {
"0": {"name": "", "value": 3762837}}
2021-03-17 03:38:46 PrEnergySumHc1 {
"0": {"name": "", "value": 4294967154}}
2021-03-17 03:38:45 PrEnergySumHc2 {
"0": {"name": "", "value": 0}}
2021-03-17 03:38:45 PrEnergySumHc3 {
"0": {"name": "", "value": 0}}
2021-03-29 09:29:12 ReturnTemp_sensor_value ok
2021-03-29 09:29:12 ReturnTemp_temp_value 32.19
2021-03-29 09:29:12 ReturnTemp_tempmirror_value 65020
2021-03-29 09:28:08 SetMode_disablehc_value 0
2021-03-29 09:28:08 SetMode_disablehwcload_value 1
2021-03-29 09:28:08 SetMode_disablehwctapping_value 0
2021-03-29 09:28:08 SetMode_flowtempdesired_value 34.0
2021-03-29 09:28:08 SetMode_hcmode_value auto
2021-03-29 09:28:08 SetMode_releaseBackup_value 0
2021-03-29 09:28:08 SetMode_releaseCooling_value 0
2021-03-29 09:28:08 SetMode_remoteControlHcPump_value 0
2021-03-29 09:32:57 Status01_0_name temp1
2021-03-29 09:32:57 Status01_1_name temp1
2021-03-29 09:32:57 Status01_2_name temp2
2021-03-29 09:32:57 Status01_3_name temp1
2021-03-29 09:32:57 Status01_4_name temp1
2021-03-29 09:32:57 Status01_5_name pumpstate
2021-03-29 09:23:21 Status02_0_name hwcmode
2021-03-29 09:23:21 Status02_1_name temp0
2021-03-29 09:23:21 Status02_2_name temp1
2021-03-29 09:23:21 Status02_3_name temp0
2021-03-29 09:23:21 Status02_4_name temp1
2021-03-29 09:23:21 Status02_4_value 49.0
2021-03-29 03:23:45 StatusCirPump_0_name
2021-03-29 03:23:45 StatusCirPump_0_value on
2021-03-29 09:23:21 WPPWMPower_percent0_value 60
2021-03-29 09:29:12 WaterPressure_press_value 1.576
2021-03-29 09:29:12 WaterPressure_sensor_value ok
2021-03-29 09:32:57 _Aussentemp 15.750
2021-03-29 09:23:21 _HWCMode auto
2021-03-29 09:23:21 _Maximaltemperatur 60
2021-03-29 09:32:57 _Pumpenstatus off
2021-03-29 09:23:21 _ReglerCurrentTemp 70
2021-03-29 09:23:21 _ReglerMaxTEMP 70.0
2021-03-29 09:32:57 _Ruecklauf 32.0
2021-03-29 09:32:57 _Vorlauf 32.0
2021-03-29 09:32:57 _WWSpeicher 36.0
2021-03-29 09:32:57 _Warmwasser 37.0
2021-02-25 08:35:14 associatedWith MQTT2_ebusd
2021-03-29 09:32:47 outsidetemp_temp2_value 13.750
2021-03-29 09:32:28 vdatetime_date_value 25.06.2008
2021-03-29 09:32:28 vdatetime_time_value 10:08:45
Attributes:
IODev ebusMQTT
devStateStyle style="text-align:right"
icon sani_boiler_temp
jsonMap Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
Status02_0_value:_HWCMode
Status02_1_value:_Maximaltemperatur
Status02_2_value:_ReglerMaxTEMP
Status02_3_value:_ReglerCurrentTemp
model E_05_eBus_bai_Fan_Pump
readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }
ebusd/bai/WaterPressure/get:.* get
ebusd/bai/FlowTemp/get:.* get
ebusd/bai/ReturnTemp/get:.* get
ebusd/bai/FanSpeed/get:.* get
ebusd/bai/WPPWMPower/get:.* get
ebusd/bai/OutdoorstempSensor/get:.* get
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }
ebusd/bai/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }
ebusd/bai/WPPWMPower:.* { json2nameValue($EVENT, 'WPPWMPower_', $JSONMAP) }
ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT, 'OutdoorstempSensor_', $JSONMAP) }
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }
ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT, 'FlowTempDesired_', $JSONMAP) }
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }
ebusd/bai/ccTimer\.Monday/get:.* get
ebusd/bai/DeactivationsIFC:.* { json2nameValue($EVENT, 'DeactivationsIFC_', $JSONMAP) }
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }
ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT, 'CounterStartattempts1_', $JSONMAP) }
ebusd/bai/PartloadHcKW:.* { json2nameValue($EVENT, 'PartloadHcKW_', $JSONMAP) }
ebusd/bai/HwcSetPotmeter:.* { json2nameValue($EVENT, 'HwcSetPotmeter_', $JSONMAP) }
ebusd/bai/list:.* list
ebusd/bai/AATemp:.* AATemp
ebusd/bai/AccessoriesOne:.* AccessoriesOne
ebusd/bai/AccessoriesTwo:.* AccessoriesTwo
ebusd/bai/ACRoomthermostat:.* ACRoomthermostat
ebusd/bai/AircontrolOk:.* AircontrolOk
ebusd/bai/AITemp:.* AITemp
ebusd/bai/AntiCondensValue:.* AntiCondensValue
ebusd/bai/averageIgnitiontime:.* averageIgnitiontime
ebusd/bai/BlockTimeHcMax:.* BlockTimeHcMax
ebusd/bai/BoilerType2:.* BoilerType2
ebusd/bai/BoilerType:.* BoilerType
ebusd/bai/ChangesDSN:.* ChangesDSN
ebusd/bai/CirPump:.* CirPump
ebusd/bai/clearerrorhistory:.* clearerrorhistory
ebusd/bai/CounterStartattempts2:.* CounterStartattempts2
ebusd/bai/CounterStartAttempts3:.* CounterStartAttempts3
ebusd/bai/currenterror:.* currenterror
ebusd/bai/dcfState:.* dcfState
ebusd/bai/DCFTimeDate:.* DCFTimeDate
ebusd/bai/DCRoomthermostat:.* DCRoomthermostat
ebusd/bai/DeactivationsTemplimiter:.* DeactivationsTemplimiter
ebusd/bai/DeltaFlowReturnMax:.* DeltaFlowReturnMax
ebusd/bai/DisplayMode:.* DisplayMode
ebusd/bai/DSN:.* DSN
ebusd/bai/DSNOffset:.* DSNOffset
ebusd/bai/DSNStart:.* DSNStart
ebusd/bai/EBusHeatcontrol:.* EBusHeatcontrol
ebusd/bai/EbusSourceOn:.* EbusSourceOn
ebusd/bai/EbusVoltage:.* EbusVoltage
ebusd/bai/errorhistory:.* errorhistory
ebusd/bai/ExhaustCurve:.* ExhaustCurve
ebusd/bai/exhaustWayBlockCounter:.* exhaustWayBlockCounter
ebusd/bai/expertlevel_ReturnTemp:.* expertlevel_ReturnTemp
ebusd/bai/ExternalFaultmessage:.* ExternalFaultmessage
ebusd/bai/externalFlowTempDesired:.* externalFlowTempDesired
ebusd/bai/externalHwcSwitch:.* externalHwcSwitch
ebusd/bai/ExternGasvalve:.* ExternGasvalve
ebusd/bai/ExtFlowTempDesiredMin:.* ExtFlowTempDesiredMin
ebusd/bai/extWP:.* extWP
ebusd/bai/FanMaxSpeedOperation:.* FanMaxSpeedOperation
ebusd/bai/FanMinSpeedOperation:.* FanMinSpeedOperation
ebusd/bai/FanPWMSum:.* FanPWMSum
ebusd/bai/FanPWMTest:.* FanPWMTest
ebusd/bai/FanStarts:.* FanStarts
ebusd/bai/Flame:.* Flame
ebusd/bai/FlameSensingASIC:.* FlameSensingASIC
ebusd/bai/FloorHeatingContact:.* FloorHeatingContact
ebusd/bai/FlowsetHcMax:.* FlowsetHcMax
ebusd/bai/FlowsetHwcMax:.* FlowsetHwcMax
ebusd/bai/FlowSetPotmeter:.* FlowSetPotmeter
ebusd/bai/Fluegasvalve:.* Fluegasvalve
ebusd/bai/Gasvalve3UC:.* Gasvalve3UC
ebusd/bai/Gasvalve:.* Gasvalve
ebusd/bai/GasvalveASICFeedback:.* GasvalveASICFeedback
ebusd/bai/GasvalveUC:.* GasvalveUC
ebusd/bai/GasvalveUCFeedback:.* GasvalveUCFeedback
ebusd/bai/GVStepOffsetMax:.* GVStepOffsetMax
ebusd/bai/GVStepOffsetMin:.* GVStepOffsetMin
ebusd/bai/HcPumpMode:.* HcPumpMode
ebusd/bai/HcPumpStarts:.* HcPumpStarts
ebusd/bai/HcUnderHundredStarts:.* HcUnderHundredStarts
ebusd/bai/HeatingSwitch:.* HeatingSwitch
ebusd/bai/HoursTillService:.* HoursTillService
ebusd/bai/HwcDemand:.* HwcDemand
ebusd/bai/HwcImpellorSwitch:.* HwcImpellorSwitch
ebusd/bai/HwcPostrunTime:.* HwcPostrunTime
ebusd/bai/HwcSwitch:.* HwcSwitch
ebusd/bai/HwcTemp:.* HwcTemp
ebusd/bai/HwcTempDesired:.* HwcTempDesired
ebusd/bai/HwcTempMax:.* HwcTempMax
ebusd/bai/HwcTypes:.* HwcTypes
ebusd/bai/HwcUnderHundredStarts:.* HwcUnderHundredStarts
ebusd/bai/HwcWaterflow:.* HwcWaterflow
ebusd/bai/HwcWaterflowMax:.* HwcWaterflowMax
ebusd/bai/Ignitor:.* Ignitor
ebusd/bai/IonisationVoltageLevel:.* IonisationVoltageLevel
ebusd/bai/maintenancedata_HwcTempMax:.* maintenancedata_HwcTempMax
ebusd/bai/maxIgnitiontime:.* maxIgnitiontime
ebusd/bai/minIgnitiontime:.* minIgnitiontime
ebusd/bai/ModulationTempDesired:.* ModulationTempDesired
ebusd/bai/OverflowCounter:.* OverflowCounter
ebusd/bai/ParamToken:.* ParamToken
ebusd/bai/PartloadHwcKW:.* PartloadHwcKW
ebusd/bai/PartnumberBox:.* PartnumberBox
ebusd/bai/PositionValveSet:.* PositionValveSet
ebusd/bai/PowerValue:.* PowerValue
ebusd/bai/PrAPSCounter:.* PrAPSCounter
ebusd/bai/PrAPSSum:.* PrAPSSum
ebusd/bai/PredCombustionDecrementTime:.* PredCombustionDecrementTime
ebusd/bai/PredCombustionPredCounter:.* PredCombustionPredCounter
ebusd/bai/PredCombustionSwitchingPoint:.* PredCombustionSwitchingPoint
ebusd/bai/PredFanPWMDevThreshold:.* PredFanPWMDevThreshold
ebusd/bai/PredFanPWMPredCounter:.* PredFanPWMPredCounter
ebusd/bai/PredFanPWMRefPWMcounter:.* PredFanPWMRefPWMcounter
ebusd/bai/PredFanPWMRefPWMsum:.* PredFanPWMRefPWMsum
ebusd/bai/PredFanPWMSwitchingPoint:.* PredFanPWMSwitchingPoint
ebusd/bai/PredIgnitionPredCounter:.* PredIgnitionPredCounter
ebusd/bai/PredIgnitionSwitchingPoint:.* PredIgnitionSwitchingPoint
ebusd/bai/PredSourcePressureDevThreshold:.* PredSourcePressureDevThreshold
ebusd/bai/PredSourcePressurePredCounter:.* PredSourcePressurePredCounter
ebusd/bai/PredSourcePressureSwitchingPoint:.* PredSourcePressureSwitchingPoint
ebusd/bai/PredWaterflowDevThreshold:.* PredWaterflowDevThreshold
ebusd/bai/PredWaterflowSwitchingPoint:.* PredWaterflowSwitchingPoint
ebusd/bai/PredWaterpressureMaxPressure:.* PredWaterpressureMaxPressure
ebusd/bai/PredWaterpressureMinPressure:.* PredWaterpressureMinPressure
ebusd/bai/PredWaterpressureSwitchingPoint:.* PredWaterpressureSwitchingPoint
ebusd/bai/PrEnergyCountHc1:.* PrEnergyCountHc1
ebusd/bai/PrEnergyCountHc2:.* PrEnergyCountHc2
ebusd/bai/PrEnergyCountHc3:.* PrEnergyCountHc3
ebusd/bai/PrEnergyCountHwc1:.* PrEnergyCountHwc1
ebusd/bai/PrEnergyCountHwc2:.* PrEnergyCountHwc2
ebusd/bai/PrEnergyCountHwc3:.* PrEnergyCountHwc3
ebusd/bai/PrEnergySumHc1:.* PrEnergySumHc1
ebusd/bai/PrEnergySumHc2:.* PrEnergySumHc2
ebusd/bai/PrEnergySumHc3:.* PrEnergySumHc3
ebusd/bai/PrEnergySumHwc1:.* PrEnergySumHwc1
ebusd/bai/PrEnergySumHwc2:.* PrEnergySumHwc2
ebusd/bai/PrEnergySumHwc3:.* PrEnergySumHwc3
ebusd/bai/PumpHours:.* PumpHours
ebusd/bai/PumpHwcFlowNumber:.* PumpHwcFlowNumber
ebusd/bai/PumpHwcFlowSum:.* PumpHwcFlowSum
ebusd/bai/ReduceModulationBlocktime:.* ReduceModulationBlocktime
ebusd/bai/RemainingBoilerblocktime:.* RemainingBoilerblocktime
ebusd/bai/ReturnRegulation:.* ReturnRegulation
ebusd/bai/ReturnTempMax:.* ReturnTempMax
ebusd/bai/SecondPumpMode:.* SecondPumpMode
ebusd/bai/SerialNumber:.* SerialNumber
ebusd/bai/SetFactoryValues:.* SetFactoryValues
ebusd/bai/SHEMaxDeltaHwcFlow:.* SHEMaxDeltaHwcFlow
ebusd/bai/SHEMaxFlowTemp:.* SHEMaxFlowTemp
ebusd/bai/SolPostHeat:.* SolPostHeat
ebusd/bai/SpecialAdj:.* SpecialAdj
ebusd/bai/Statenumber:.* Statenumber
ebusd/bai/Status16:.* Status16
ebusd/bai/Status:.* Status
ebusd/bai/Storageloadpump:.* Storageloadpump
ebusd/bai/StorageLoadPumpHours:.* StorageLoadPumpHours
ebusd/bai/StorageloadPumpStarts:.* StorageloadPumpStarts
ebusd/bai/StorageLoadTimeMax:.* StorageLoadTimeMax
ebusd/bai/StoragereleaseClock:.* StoragereleaseClock
ebusd/bai/StorageTemp:.* StorageTemp
ebusd/bai/StorageTempDesired:.* StorageTempDesired
ebusd/bai/StorageTempMax:.* StorageTempMax
ebusd/bai/TargetFanSpeed:.* TargetFanSpeed
ebusd/bai/TargetFanSpeedOutput:.* TargetFanSpeedOutput
ebusd/bai/TempDiffBlock:.* TempDiffBlock
ebusd/bai/TempDiffFailure:.* TempDiffFailure
ebusd/bai/TempGradientFailure:.* TempGradientFailure
ebusd/bai/Templimiter:.* Templimiter
ebusd/bai/TemplimiterWithNTC:.* TemplimiterWithNTC
ebusd/bai/TempMaxDiffExtTFT:.* TempMaxDiffExtTFT
ebusd/bai/TimerInputHc:.* TimerInputHc
ebusd/bai/ValveMode:.* ValveMode
ebusd/bai/ValveStarts:.* ValveStarts
ebusd/bai/VolatileLockout:.* VolatileLockout
ebusd/bai/WarmstartDemand:.* WarmstartDemand
ebusd/bai/WarmstartOffset:.* WarmstartOffset
ebusd/bai/WaterHcFlowMax:.* WaterHcFlowMax
ebusd/bai/WaterpressureBranchControlOff:.* WaterpressureBranchControlOff
ebusd/bai/WaterpressureMeasureCounter:.* WaterpressureMeasureCounter
ebusd/bai/WaterpressureVariantSum:.* WaterpressureVariantSum
ebusd/bai/WP:.* WP
ebusd/bai/WPPostrunTime:.* WPPostrunTime
ebusd/bai/WPPWMPowerDia:.* WPPWMPowerDia
ebusd/bai/WPSecondStage:.* WPSecondStage
ebusd/bai/StatusCirPump:.* { json2nameValue($EVENT, 'StatusCirPump_', $JSONMAP) }
room MQTT2_DEVICE
LG
Hier kommt das List für das aktuelle Device "MQTT2_ebusd_21.2_19013"
(Nach einem Neustart von ebusd würde das Device dann MQTT2_ebusd_21.2_xxxxx heißen, wobei die Endung bisher 3-5 stellige Zahlen waren)
In diesem Device landen alle meine MQTT Request vom Timer. List dazu unten.
Internals:
CFGFN
CID ebusd_21.2_19013
DEF ebusd_21.2_19013
DEVICETOPIC MQTT2_ebusd_21.2_19013
FUUID 606184b5-f33f-f777-e668-b4513496ccd531a6
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 432
NAME MQTT2_ebusd_21.2_19013
NR 112
STATE Brennerstunden: 1254
<br>Brennerstarts: 48546
<br>Vorlauf Heizung IST/SOLL: 58.0°C / 39.0°C
<br>Rücklauf IST: 3276.8°C
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 432
ebusMQTT_TIME 2021-03-29 09:57:24
READINGS:
2021-03-29 09:57:19 BM0_MM1_RT_value 21
2021-03-29 09:57:19 BM0_MM1_ST2_value 02 00
2021-03-29 09:57:19 BM0_MM1_ST_value 00
2021-03-29 09:57:19 BM0_MM1_VF_S_value 7.654
2021-03-29 09:57:19 BM0_MM1_VF_value 0.256
2021-03-29 09:57:19 BM0_MM1_WW_S_value 10.0
2021-03-29 09:57:19 BM0_MM1_XX_value 4d 1c 00 d8 14 64 00
2021-03-29 09:56:09 SP1_0_name
2021-03-29 09:56:09 SP1_0_value 29.0
2021-03-29 09:56:09 ST1_0_name
2021-03-29 09:56:09 ST1_0_value 16.0
2021-03-29 09:56:04 TT1_0_name
2021-03-29 09:56:04 TT1_0_value 22.5
2021-03-29 09:56:04 VF1_0_name
2021-03-29 09:56:04 VF1_0_value 27.6
2021-03-29 09:57:24 betrd_aktion_value 6
2021-03-29 09:57:24 betrd_brauchwassersolltemp_value 10.0
2021-03-29 09:57:24 betrd_kesselsolltemp_value 39.88
2021-03-29 09:57:24 betrd_status_value Heizen
2021-03-29 09:56:04 hg90_betriebsstunden_brenner_value 1254
2021-03-29 09:56:04 hg91_brennerstarts_value 48546
2021-03-29 09:56:04 hg9x_betriebsstunden_netz_value 8615
2021-03-29 09:56:04 ruecklauf_ist_ruecklauf_ist_value 3276.8
2021-03-29 09:41:41 scan.08_HW_value 6830
2021-03-29 09:41:41 scan.08_ID_value 3L
2021-03-29 09:41:41 scan.08_MF_value Kromschroeder
2021-03-29 09:41:41 scan.08_SW_value 0300
2021-03-29 09:41:44 scan.15_ID_value
2021-03-29 09:41:44 scan.15_MF_value Kromschroeder
2021-03-29 09:41:44 scan.15_SW_value 0204
2021-03-29 09:42:33 scan.35_ID_value
2021-03-29 09:42:33 scan.35_MF_value Kromschroeder
2021-03-29 09:42:33 scan.35_SW_value 0204
2021-03-29 09:41:47 scan.51_ID_value
2021-03-29 09:41:47 scan.51_MF_value Kromschroeder
2021-03-29 09:41:47 scan.51_SW_value 0208
2021-03-29 09:41:48 scan.75_ID_value
2021-03-29 09:41:48 scan.75_MF_value Kromschroeder
2021-03-29 09:41:48 scan.75_SW_value 0204
2021-03-29 09:41:50 scan.f6_ID_value
2021-03-29 09:41:50 scan.f6_MF_value Kromschroeder
2021-03-29 09:41:50 scan.f6_SW_value 0204
2021-03-29 09:57:24 sollw_aussentemp_value 13.000
2021-03-29 09:57:24 sollw_brauchwassersolltemp_value 10.000
2021-03-29 09:57:24 sollw_kesselsolltemp_value 39.898
2021-03-29 09:57:24 sollw_status_value 02
2021-03-29 09:41:41 subscriptions ebusd/#
2021-03-29 09:52:34 temp_51_12_0_name
2021-03-29 09:52:34 temp_51_12_0_value 75.0
2021-03-29 09:52:34 temp_51_13_0_name
2021-03-29 09:52:34 temp_51_13_0_value 10.0
2021-03-29 09:52:34 temp_51_8_0_name
2021-03-29 09:52:34 temp_51_8_0_value 0.8
2021-03-29 09:56:04 vorlauf_ist_vorlauf_ist_value 58.0
2021-03-29 09:56:04 vorlauf_soll_vorlauf_soll_value 39.0
Attributes:
IODev ebusMQTT
readingList ebusd_21.2_19013:ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd_21.2_19013:ebusd/scan\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/sollw:.* { json2nameValue($EVENT, 'sollw_', $JSONMAP) }
ebusd_21.2_19013:ebusd/scan\x2e51/:.* { json2nameValue($EVENT, 'scan.51_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/BM0_MM1:.* { json2nameValue($EVENT, 'BM0_MM1_', $JSONMAP) }
ebusd_21.2_19013:ebusd/scan\x2e75/:.* { json2nameValue($EVENT, 'scan.75_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/betrd:.* { json2nameValue($EVENT, 'betrd_', $JSONMAP) }
ebusd_21.2_19013:ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/hg90:.* { json2nameValue($EVENT, 'hg90_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/hg91:.* { json2nameValue($EVENT, 'hg91_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/hg9x:.* { json2nameValue($EVENT, 'hg9x_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/vorlauf_ist:.* { json2nameValue($EVENT, 'vorlauf_ist_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/vorlauf_soll:.* { json2nameValue($EVENT, 'vorlauf_soll_', $JSONMAP) }
ebusd_21.2_19013:ebusd/feuerung/ruecklauf_ist:.* { json2nameValue($EVENT, 'ruecklauf_ist_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/VF1:.* { json2nameValue($EVENT, 'VF1_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/TT1:.* { json2nameValue($EVENT, 'TT1_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/SP1:.* { json2nameValue($EVENT, 'SP1_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/ST1:.* { json2nameValue($EVENT, 'ST1_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/temp_51_13:.* { json2nameValue($EVENT, 'temp_51_13_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/temp_51_12:.* { json2nameValue($EVENT, 'temp_51_12_', $JSONMAP) }
ebusd_21.2_19013:ebusd/MM1/temp_51_8:.* { json2nameValue($EVENT, 'temp_51_8_', $JSONMAP) }
ebusd_21.2_19013:ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }
room MQTT2_DEVICE
stateFormat Brennerstunden: hg90_betriebsstunden_brenner_value
<br>Brennerstarts: hg91_brennerstarts_value
<br>Vorlauf Heizung IST/SOLL: vorlauf_ist_vorlauf_ist_value°C / vorlauf_soll_vorlauf_soll_value°C
<br>Rücklauf IST: ruecklauf_ist_ruecklauf_ist_value°C
At-Abfragesteuerung:
Internals:
COMMAND set ebusMQTT publish ebusd/feuerung/hg90/get;
set ebusMQTT publish ebusd/feuerung/hg91/get;
set ebusMQTT publish ebusd/feuerung/hg9x/get;
set ebusMQTT publish ebusd/feuerung/vorlauf_ist/get;
set ebusMQTT publish ebusd/feuerung/vorlauf_soll/get;
set ebusMQTT publish ebusd/feuerung/ruecklauf_ist/get;
set ebusMQTT publish ebusd/MM1/VF1/get;
set ebusMQTT publish ebusd/MM1/TT1/get;
set ebusMQTT publish ebusd/MM1/SP1/get;
set ebusMQTT publish ebusd/MM1/ST1/get;
DEF +*00:02:00
set ebusMQTT publish ebusd/feuerung/hg90/get;
set ebusMQTT publish ebusd/feuerung/hg91/get;
set ebusMQTT publish ebusd/feuerung/hg9x/get;
set ebusMQTT publish ebusd/feuerung/vorlauf_ist/get;
set ebusMQTT publish ebusd/feuerung/vorlauf_soll/get;
set ebusMQTT publish ebusd/feuerung/ruecklauf_ist/get;
set ebusMQTT publish ebusd/MM1/VF1/get;
set ebusMQTT publish ebusd/MM1/TT1/get;
set ebusMQTT publish ebusd/MM1/SP1/get;
set ebusMQTT publish ebusd/MM1/ST1/get;
FUUID 605c9ea4-f33f-f777-2ee7-cfe788417e7548ea
NAME Abfrage_EBUS.MQTT
NR 60
NTM 10:02:01
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 10:02:01
TIMESPEC 00:02:00
TRIGGERTIME 1617004921.19432
TRIGGERTIME_FMT 2021-03-29 10:02:01
TYPE at
READINGS:
2021-03-29 10:00:01 state Next: 10:02:01
Attributes:
room MQTT2_DEVICE
Grüße
Ich habe am WE nochmal einige Test gemacht.
Um WiFi Probleme auszuschließen habe ich einen Wemos Pro mit externer Antenne benutzt.
WiFi 78% wenn ich den Wemos alleine am Standort betreibe. Sobald der Wemos auf dem ebus steckt, kaum mehr bis gar keinen Wifi Empfang.
Ich gehe mitlerweile von einem defekt des ebus-Board aus.
Wie kann ich das ebus-Board umtauschen?
@Swuwe
deine regexp kann hier absolut nicht greifen, weil die für Vaillant Geräte ausgelegt ist und deine nicht gefiltert werden, daher landen die alle im Quelldevice.
Da du nur die beiden Devices "feuerung" und "MM1" hast müsste die regexp wie folgt aussehen. Versuche das mal so. allerdings musst du dann die falsch zugeordneten Einträge löschen, bzw. den eBusd neu starten dann wird ein neuer ebusd_xxx angelegt und du kannst den alten komplett löschen.
(ebus.)[^/]*/(feuerung|MM1|)/.*:.* "$1"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"
LG
Hallo Reinhart,
ich hätte da einmal eine Verständnisfrage zu MQTT und Ebusd, da ich gerade bei einem Problem kleben bleibe.
Wie aus den vergangenen Beiträgen von letzter Woche ersichtlich, läuft bei mir Ebusd als Daemon einwandfrei, auch werden mir alle verfügbaren STATEs via MQTT im IOBroker (ja, ich weiß, du schriebst, das Du IOBroker nicht so gut kennst) regelmäßig vom Ebusd-Daemon im IOBroker MQTT-Server publiziert und angezeigt. Also funktioniert schon mal eine Richtung via MQTT (Daten vom Ebusd -> MQTT-Server).
Nun war ich bischen in Node-Red am basteln gewesen und da fiel mir etwas entscheidenes auf: Wenn ich ein State (z.B. Hc1DayTemp) im MQTT Server ändere, ging ich davon aus, das der Ebusd-Daemon diese Änderung empfängt und die gewünschte Änderung mittels des Adapters an den Ebus weiter gibt und der Wert gändert wird. Dem ist aber nicht so.
Gehe ich Recht in der Annahme, das ich via MQTT alle States vom Ebusd-Daemon zwar empfangen kann, aber die States über Ebusd via MQTT nicht ändern kann? Bliebe mir dann nur der Weg über "ebusctl" mittels "ebusctl write -c 350 Hc1DayTemp 20" mittels "exec" , wobei Du ja expliziet "ebusdctl" nur als Progamm zum testen der korrekten Funktionsweise des Ebusd-Daemons ausgewiesen hattest?
Lg
@ Reinhart
Hervorragend, somit kommen die Readings immerhin schonmal direkt im MQTT2_ebusd an. Jetzt habe ich auch verstanden was ich machen muss, wenn ich später noch andere Sachen vom Bus lesen möchte. Eigentlich müsste es noch mehr geben (Mischer kon. Heizung und Mischer Fußbodenheizung im Einsatz) . Aber da suche ich mal selber nach.
Trotzdem wird weiterhin bei jedem Neustart ein neues Device QTT2_ebusd_21.2_xxxxx angelegt. Erwartungsgemäß, oder habe ich da noch einen Fehler zu beheben? Autocreate bleibt ja eigentlich an, oder?
Danke und Grüße
Zitat von: Swuwe am 30 März 2021, 15:19:11
Trotzdem wird weiterhin bei jedem Neustart ein neues Device QTT2_ebusd_21.2_xxxxx angelegt. Erwartungsgemäß, oder habe ich da noch einen Fehler zu beheben? Autocreate bleibt ja eigentlich an, oder?
Ja das ist bekannt, dass hier immer ein neues Devices angelegt wird, deshalb sollte da auch nix landen. Autocreate bleibt an, sonst werden neue Daten nicht zugeordnet.
Schön wenn du den Mechanismus verstanden hast und dir jetzt klar ist warum das vorher nicht klappte. Die regexp kannst ja beliebig erweitern und auch noch andere "Gruppen" erfassen. ich bin auch nicht der regexp Spezialist, aber du kannst ja einfach probieren bis du es hast so wie du es dir vorstellst.
LG
Zitat von: Mümmelmann am 30 März 2021, 01:25:15
Gehe ich Recht in der Annahme, das ich via MQTT alle States vom Ebusd-Daemon zwar empfangen kann, aber die States über Ebusd via MQTT nicht ändern kann? Bliebe mir dann nur der Weg über "ebusctl" mittels "ebusctl write -c 350 Hc1DayTemp 20" mittels "exec" , wobei Du ja expliziet "ebusdctl" nur als Progamm zum testen der korrekten Funktionsweise des Ebusd-Daemons ausgewiesen hattest?
MQTT ist ja ein standardisiertes Protokoll, dass keine Point to Point Verbindung ist, sondern mi "publish" (senden) und "subscribed" (empfangen) kommuniziert. Wenn du jetzt den "state" änderst, wirkt sich das nicht auf MQTT aus. Du musst schon einen Publish Befehl mit der Topic senden, damit du eine Antwort bekommst, bzw. in ein Register vom eBus Device schreiben kannst.
MQTT hat ja nix spezifisches mit eBus zu tun, sondern ist ein Protokoll für Datenübertragung und der eBus Dämon unterstützt dieses.
Beispiel:
set ebusMQTT publish ebusd/bai/FlowTemp/getwenn du den "state" des Vorlaufs haben willst, dann musst du einen "publish" durchführen. Das gilt natürlich auch für schreibbare Daten beim eBus. Neuen Wert setzen, daher mit "publish".
LG
@Mitch
bevor ich hier alles durchlese, von wem hast du den Adapter seinerzeit bekommen, von John oder von mir?
LG
Zitat von: Mitch am 29 März 2021, 11:01:04
Um WiFi Probleme auszuschließen habe ich einen Wemos Pro mit externer Antenne benutzt.
WiFi 78% wenn ich den Wemos alleine am Standort betreibe. Sobald der Wemos auf dem ebus steckt, kaum mehr bis gar keinen Wifi Empfang.
Ich gehe mitlerweile von einem defekt des ebus-Board aus.
was für eine Stromversorgung nutzt Du und wie hast Du diese angesteckt?
Zitat von: Reinhart am 30 März 2021, 20:07:04
@Mitch
bevor ich hier alles durchlese, von wem hast du den Adapter seinerzeit bekommen, von John oder von mir?
LG
Kam von John.
Zitat von: john30 am 31 März 2021, 08:05:32
was für eine Stromversorgung nutzt Du und wie hast Du diese angesteckt?
Guter Punkt John. Ich hatte hier auch schon den Adapter in Verdacht. Mittlerweile habe ich drei Stück ausprobiert.
Einen vom iPhone, einen NoName und einen vom Amazon Echo. Kein Unterschied.
Angesteckt immer über den Wemos, ebus Adapter bekommt ja davon dann Strom.
Ich habe jetzt nochmal an meinem Setup gearbeitet und teste gerade (habe einen anderen AP installiert (U6-LR).
Mal sehen, wie es sich jetzt verhält.
Ich werde weiter beobachten und berichten. Im Zweifel würde ich mich über einen Austausch freuen, oder, du schickst mir noch einen zum testen. Wenn es die gleichen Probleme gibt, dann liegt es an mir und meiner Heizung :-[
Wobei ja der ebus Adapter v1 seit Jahren ohne Probleme lief.
Hallo nochmal,
ist es eigentlich möglich beim ebusd Docker-Image eine eigene Config per --configpath=PATH zu verwenden? Und wenn ja, bezieht sich der PATH dann auf das Dateisystem des Docker-Containers oder das des Host-Systems?
Zitat von: Mitch am 01 April 2021, 11:13:08
Guter Punkt John. Ich hatte hier auch schon den Adapter in Verdacht. Mittlerweile habe ich drei Stück ausprobiert.
Einen vom iPhone, einen NoName und einen vom Amazon Echo. Kein Unterschied.
Angesteckt immer über den Wemos, ebus Adapter bekommt ja davon dann Strom.
mir ist noch was eingefallen:
kannst Du mal Wemos+eBUS vom Adapter trennen, USB Stromversorgung auf J2 geben und am J4 den Strom zwischen Pin 2 und 3 messen? Der sollte unter 90 mA liegen.
Danach könntest Du den Wemos aufstecken und nochmal die gleiche Messung durchführen (also Wemos via J2 versorgen). Das dürfte insgesamt nicht über 160 mA gehen.
Ach ja: hast Du beim Wemos pro den 0 Ohm auch umgelötet, damit die externe Antenne überhaupt genutzt wird?
Zitat von: schneivo am 01 April 2021, 18:36:31
ist es eigentlich möglich beim ebusd Docker-Image eine eigene Config per --configpath=PATH zu verwenden? Und wenn ja, bezieht sich der PATH dann auf das Dateisystem des Docker-Containers oder das des Host-Systems?
ja klar. Das Filesystem ist immer das innerhalb des Containers. Du kannst aber via Bind Mount einen Pfad vom Host in den Container hängen. Bspw. mit "-v /var/ebusd-config:/etc/ebusd" und dann via "-c /etc/ebusd" nutzen.
Zitat von: john30 am 01 April 2021, 19:13:11
ja klar. Das Filesystem ist immer das innerhalb des Containers. Du kannst aber via Bind Mount einen Pfad vom Host in den Container hängen. Bspw. mit "-v /var/ebusd-config:/etc/ebusd" und dann via "-c /etc/ebusd" nutzen.
Werde ich ausprobieren, danke!
Vielen, vielen Dank an das eBus-Adapter-Team. Super Arbeit!
Heizung: VCW206/5-5 R5 ("bai00", SW0609, HW5502) + VT 350 ("35000", SW0114, HW7102)
Setup: RPi 4, 8GB mit SSD + RPI-RF-MOD auf HB-RF-USB-2 (wegen der USB3.0 Störstrahlung) + ebus Adapter 3 via Ethernet
Software: Home Assistant + debmatic + ebusd
Platine kam an, Jumper überprüft, einen umgesetzt, an den eBus gehangen und dann kam die Lernkurve unterbrochen von Layer 8 Problemen :-X
Dinge, die mir aufgefallen sind: Das Docker Image (latest) läuft nicht auf einem 64 bit Raspberry Pi unter Debian Buster (Geschmacksrichtung Raspberry Pi OS). Der Parameter --platform linux/arm64/v8 hilft nicht, nach umschalten auf devel ging es ohne jegliches zutun. Bugreport dazu auf Github geöffnet.
sysop@homepi:~ $ sudo docker run --rm -it -p 8888 john30/ebusd -f --scanconfig -d enh:192.168.182.13:9999 --latency=20 -f
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:219: exec user process caused: exec format error
sysop@homepi:~ $ sudo docker run --platform linux/arm64/v8 --rm -it -p 8888 john30/ebusd -f --scanconfig -d enh:192.168.182.13:9999 --latency=20 -f
Unable to find image 'john30/ebusd:latest' locally
latest: Pulling from john30/ebusd
Digest: sha256:fb8cb181acdec4444b32f1742f5ceaa2cfd9a763b9631c0ff21269176cdd65e9
Status: Image is up to date for john30/ebusd:latest
docker: Error response from daemon: image with reference john30/ebusd was found but does not match the specified platform: wanted linux/arm64/v8, actual: linux/amd64.
See 'docker run --help'.
sysop@homepi:~ $ sudo docker run --rm -it -p 8888 john30/ebusd[b]:devel[/b] -f --scanconfig -d enh:192.168.182.13:9999 --latency=20 -f
2021-04-02 09:05:12.412 [main notice] ebusd 21.2.v21.2-12-g86b700c started with auto scan on enhanced device 192.168.182.13:9999
2021-04-02 09:05:12.732 [bus notice] bus started with own address 31/36
2021-04-02 09:05:12.762 [bus notice] signal acquired
2021-04-02 09:05:12.960 [bus notice] new master 10, master count 2
2021-04-02 09:05:12.988 [bus notice] new master 03, master count 3
2021-04-02 09:05:12.988 [update notice] received unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2021-04-02 09:05:12.995 [bus notice] device status: reset
2021-04-02 09:05:17.051 [update notice] received unknown MS cmd: 1008b5110101 / 095857008043530000ff
2021-04-02 09:05:22.896 [bus notice] scan 08: ;Vaillant;BAI00;0609;5502
2021-04-02 09:05:22.896 [update notice] store 08 ident: done
2021-04-02 09:05:22.897 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0609;5502
2021-04-02 09:05:22.897 [bus notice] scan 08: ;Vaillant;BAI00;0609;5502
2021-04-02 09:05:23.220 [main notice] read common config file vaillant/scan.csv
2021-04-02 09:05:23.258 [update notice] received unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2021-04-02 09:05:23.292 [main notice] read common config file vaillant/general.csv
2021-04-02 09:05:23.368 [main notice] read common config file vaillant/broadcast.csv
2021-04-02 09:05:23.444 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0609, HW5502
2021-04-02 09:05:23.633 [update notice] sent scan-read scan.08 id QQ=31:
2021-04-02 09:05:23.797 [update notice] sent scan-read scan.08 id QQ=31:
2021-04-02 09:05:23.960 [update notice] sent scan-read scan.08 id QQ=31:
2021-04-02 09:05:24.124 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:24.401 [main notice] found messages: 212 (3 conditional on 26 conditions, 0 poll, 10 update)
2021-04-02 09:05:24.590 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:24.753 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:24.917 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:25.081 [update notice] sent scan-read scan.08 id QQ=31: 21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:25.081 [bus notice] scan 08: ;21;16;38;0010019276;0001;013308;N0
2021-04-02 09:05:27.246 [update notice] received read bai Status01 QQ=10: 44.0;43.5;-;33.5;41.5;off
2021-04-02 09:05:27.401 [bus notice] scan 15: ;Vaillant;35000;0114;7102
2021-04-02 09:05:27.401 [update notice] store 15 ident: done
2021-04-02 09:05:27.401 [update notice] sent scan-read scan.15 QQ=31: Vaillant;35000;0114;7102
2021-04-02 09:05:27.402 [bus notice] scan 15: ;Vaillant;35000;0114;7102
2021-04-02 09:05:27.584 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313633303030
2021-04-02 09:05:27.766 [update notice] sent scan-read scan.15 id QQ=31:
2021-04-02 09:05:27.947 [update notice] sent scan-read scan.15 id QQ=31:
2021-04-02 09:05:28.002 [bus notice] max. symbols per second: 114
2021-04-02 09:05:28.129 [update notice] sent scan-read scan.15 id QQ=31: 21;16;30;0020124472;0082;022440;N0
2021-04-02 09:05:28.129 [bus notice] scan 15: ;21;16;30;0020124472;0082;022440;N0
2021-04-02 09:05:28.313 [main notice] read scan config file vaillant/15.350.csv for ID "35000", SW0114, HW7102
2021-04-02 09:05:28.314 [main notice] found messages: 412 (7 conditional on 29 conditions, 0 poll, 10 update)
2021-04-02 09:05:29.191 [update notice] received update-read broadcast vdatetime QQ=10: 11:05:31;02.04.2021
2021-04-02 09:05:29.429 [update notice] received update-write bai StatusCirPump QQ=10: off
2021-04-02 09:05:33.232 [update notice] received update-write bai SetMode QQ=10: auto;0.0;-;-;1;0;1;0;0;0
...
Dann also erstmal lokal installiert, für die Parameterfindungsphase.
Aktueller manueller Aufruf:
ebusd -d enh:192.168.x.x:9999 --scanconfig --latency=20 --accesslevel=* --mqtthost=192.168.x.x --mqttport=1883 --mqttuser=ein_user --mqttpass=geheim --mqttjson --configlang=de -f --configpath=/etc/ebusd/Tipp: Falls readall.sh, ebusctl, ... nicht richtig spielen wollen, aber durch den Parameter -f eine Ausgabe an einem vorbeiflimmert, mit ps -ely | grep ebus sicherstellen, dass nur eine Instanz läuft. Eigene Erfahrung ;)
Zunächst im Home Assistant mit dem ebusd-Plugin einige Werte am ebusd abgeholt, ging grundsätzlich aber die Möglichkeiten sind doch sehr beschränkt; bai ist bekannt VT350 nicht.
Also auf zu MQTTEine Möglichkeit für einen Broker unter HA ist hier beschrieben: https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md (https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md)
Mir ging es dann wie einigen Anderen, dass ich mich gewundert habe, dass nichts ankommt und keine "Sensoren entstehen".
Zum manuellen Lesen und Abfragen von Werten und Beobachten der Kommunikation ist der MQTT-Explorer eine gute Hilfe: https://github.com/thomasnordquist/MQTT-Explorer/releases
Achtung! Die neuste Release wollte auf meinem Mac nicht starten. Die 0.3.6 funktioniert, auch wenn ein Helper beim Start crasht und eine Fehlermeldung kommt.
Eine weitere gute Inspiration für ebusd + MQTT + Home Assistant ist hier zu finden: https://community.home-assistant.io/t/ebus-integration/47343/54
Mit dem folgenden Code Schnipsel werden einige Temperaturen alle 5 Minuten ausgelesen (Besipiel).
automation:
- alias: ebusd_mqtt_update
initial_state: on
trigger:
- platform: time_pattern
minutes: "/5"
action:
- service: mqtt.publish
data:
topic: "ebusd/bai/ReturnTemp/get"
payload: "1"
- service: mqtt.publish
data:
topic: "ebusd/bai/ReturnTempExternal/get"
payload: "1"
Um sich einen eigenen Schnipsel zu bauen die CSV Datei in Open/Libre Office, Excel, whatever öffnen und dann:
- Alle spalten entfernen bis auf die Bezeichnungen der Werte,
- alle Header entfernen,
- alle nicht benötigten Werte entfernen,
- alles zusammenschieben, so dass links von den Bezeichnern eine freie Spalte existiert,
- alle Felder der linken Spalte mit _x_ füllen,
- alle Felder der Spalte rechts von den Bezeichnern mit _y_ füllen (siehe Bild),
- in einer neuen Datei speichern,
- Datei in einem Texteditor öffnen,
- mit suchen und ersetzen die _x_, tauschen durch >> - service: mqtt.publish
data:
topic: "<<, - mit suchen und ersetzen die _y_, tauschen durch >>"
payload: "1"<< und - in die Automation einfügen.
>><< markieren die Codeschnipsel, code funktioniert nicht in einer Aufzählung.
Für andere Heimautomatisierungssysteme wird man andere Codeschnipsel benötigen, aber für das schnelle erstellen von Konfigurationen ohne Typos wird das vorgehen auch hilfreich sein.
Nach dem VT350-VT370 hack gibt es weniger ERR Meldungen. Aber bei der Kommunikation mit der Therme gibt es noch viele solcher Nachrichten. Hier bräuchte ich ein wenig Hilfe. Wo finde ich die "Rohdaten-Nachrichten", um mich selber an der Dekodierung zu versuchen?
Ich habe mein System grundsätzich am laufen, d.h. Daten der Heizung werden über ebusd mitgelesen, per MQTT weitergereicht und (bei mir) über iobroker weiterverarbeitet. Jetzt geht es mir darum, alle für mich interessanten Werte erstmal zu finden, und dann zyklisch zu pollen, falls sie nicht ohnehin schon einfach mitgelesen werden können.
Um so wenig wie möglich auf den Bus zu schreiben habe ich folgende Fragen mit Bezug auf Johns letzte Antwort an mich:
Zitat von: john30 am 21 März 2021, 14:58:23
Zitat von: chris371
Was wird da eigentlich gepollt?
Die ID der Geräte und die Nachrichten, die mit Poll Priorität versehen sind.
1.) Nachdem nach einigen Tagen mit --scanconfig jetzt klar ist, welche Geräte-IDs bei mir vorkommen: wäre es da nicht sinnvoll, die fest zu konfigurieren (wie?) und auf das ständige scannen danach zu verzichten? Schließlich ändert sich meine Anlage im Normalfall ja nicht spontan.
2.) Wenn ich die für mich interessanten Werte identifiziert habe und sie pollen muss: Soll ich lieber die CSVs lokal editieren und den besagten Nachrichten eine Poll-Priorität zuweisen (damit der ebusd selber pollt)? Oder würdet ihr lieber ein zyklisches Abfragen über MQTT empfehlen (und wenn ja warum?)?
welche Datenpunkte du für wichtig empfindest ist wohl bei jedem unterschiedlich, da hier individuelle Schwerpunkte des Anwenders eine Rolle spielen.
zu 1, es wird ja nicht ständig gescannt, sondern nur bei einem Neustart des Dämons und das hält sich ja in Grenzen. Lediglich bei der Inbetriebnahme wird das häufiger sein.
zu 2, musst du entscheiden, aber ich persönlich bevorzuge die zyklische Abfrage weil du hier mit den Timings flexibler bist. Es gibt Datenpunkte die genügen 1-2 mal pro Tag, andere vielleicht jede Stunde und andere alle 5 Minuten. Dann kannst du mit 3 verschiedenen Timern das bequem steuern und sparst so unnötiges schreiben am Bus.
LG
Darf ich mich in eure Diskussion einklinken?
Zitat von: Reinhart am 04 April 2021, 20:12:44
zu 1, es wird ja nicht ständig gescannt, sondern nur bei einem Neustart des Dämons und das hält sich ja in Grenzen.
Wie kann man denn die statische Konfiguration umsetzen? Wie ich schon geschrieben hatte, findet ebusd die Module an Adresse 23 und 25 bei mir nur sehr sporadisch.
Zu dem Polling hätte ich auch eine Frage. Das kann ich ja mit MQTT starten:
# mosquitto_pub -h localhost -t 'ebusd/sc/Coll1Sensor/get' -m '?9'Wie kann ich das Polling wieder deaktivieren?
Ist es eigentlich normal, dass nach einer Werteabfrage der Wert zweimal zurückgegeben wird:
# mosquitto_pub -h localhost -t 'ebusd/sc/Coll1Sensor/get' -m '?'# mosquitto_sub -v -h localhost -p 1883 -t 'ebusd/sc/#'
ebusd/sc/Coll1Sensor/get ?
ebusd/sc/Coll1Sensor 14.75;ok
ebusd/sc/Coll1Sensor 14.75;okDanke euch!
Grüße
Zitat von: Pretender am 04 April 2021, 20:36:16
Wie kann man denn die statische Konfiguration umsetzen? Wie ich schon geschrieben hatte, findet ebusd die Module an Adresse 23 und 25 bei mir nur sehr sporadisch.
nur die files von ebusd-configuration in /etc/ebusd legen, die deine Anlage braucht, und dann ebusd darauf konfigurieren (--configpath).
Zitat von: Pretender am 04 April 2021, 20:36:16
Zu dem Polling hätte ich auch eine Frage. Das kann ich ja mit MQTT starten:
Wie kann ich das Polling wieder deaktivieren?
Option --pollinterval=0
Zitat von: Pretender am 04 April 2021, 20:36:16
Ist es eigentlich normal, dass nach einer Werteabfrage der Wert zweimal zurückgegeben wird:
ja.
Therme: VCW DE 206/5-5 R5, SW0609, HW5502, PROD 0010019276
Frage: Wie kann ich die letzten Felder dekodieren?
Stand jetzt:
Die Therme wird nur über den default bai.308523.inc eingebunden und mehr schlecht als recht unterstützt. Nach einer WWW Suche nach Product ID und nach "SW0609 HW5502" bin ich auf den Issue https://github.com/john30/ebusd-configuration/issues/106 (https://github.com/john30/ebusd-configuration/issues/106) gestoßen. Gleiche SW und HW Version, PROD=0010019268 unterscheidet sich in den letzten beiden Stellen von meiner Therme (s.o.).
Ein erster Test hat ergeben, dass die meisten Werte korrekt ausgewertet werden.
Ausnahmen:
bai APCLegioProtection = ERR: invalid position in decode
bai Status = ERR: invalid position in decode
bai Status16 = ERR: invalid position in decode
Bei "bai errorhistory = ERR: end of input reached" gehe ich davon aus, dass der ERR bedeutet "kein Fehler", insofern der Wert korrekt ausgewertet wurde.
Wie würde man vorgehen, um die Daten zu dekodieren?
Zitat von: Reinhart am 04 April 2021, 20:12:44
zu 1, es wird ja nicht ständig gescannt, sondern nur bei einem Neustart des Dämons und das hält sich ja in Grenzen. Lediglich bei der Inbetriebnahme wird das häufiger sein.
Danke für den Hinweis!
Ich hatte ja ständig Schreiboperationen auf dem Bus (zu sehen an der roten LED des Adapters) und habe das zunächst mit --pollinterval=61 auf wenigstens einmal pro Minute etwas reduziert bekommen. Ich glaubte, dass das wohl wiederholte Scans sein müssten. Nach Deinem Hinweis habe ich mich aber auf die Suche gemacht und festgestellt, dass es stattdessen die "YieldThisYear"-Message aus ebusd-2.1.x/de/vaillant/yield4445.inc war, die standardmäßig Poll-Priorität hat.
Also auf lokale Config-Files umgestellt, in yield4445.inc von "r9" auf "r" geändert, und der Spuk mit der ständigen Pollerei ist vorbei! :D
Vielen Dank!
Beobachtung am Rande:
Bei der Message hat die Poll-Priorität offenbar keine Wirkung. Egal ob mit "r9" oder "r1", es kommt ein Bündel dieser Messages immer alle --pollinterval Sekunden. Das könnte evtl. ein Bug sein; gemäß Doku hätte ich bei "r9" mit (9 x pollinterval) gerechnet.
Zitat von: Reinhart am 04 April 2021, 20:12:44
zu 2, musst du entscheiden, aber ich persönlich bevorzuge die zyklische Abfrage weil du hier mit den Timings flexibler bist. Es gibt Datenpunkte die genügen 1-2 mal pro Tag, andere vielleicht jede Stunde und andere alle 5 Minuten. Dann kannst du mit 3 verschiedenen Timern das bequem steuern und sparst so unnötiges schreiben am Bus.
Okay, danke. Ich glaubte, die Poll-Prioritäten in der Message-Definition wären genau für solche unterschiedlichen Intervalle gedacht. Aber aktive Abfrage über MQTT ist trotzdem flexiber, das stimmt schon.
Schöne Grüße.
Kann man die Signalerkennung verbessern? Oder liegt das eher an meiner heizungsseitigen Installation? Oder am Raspi4?
Nach dem Hochfahren: kein Signal
root@raspberrypi:/home/pi# ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
ein paar Minuten später, ohne irgendetwas geändert oder angefaßt zu haben:
root@raspberrypi:/home/pi# ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
access: *
signal: acquired
symbol rate: 39
max symbol rate: 146
min arbitration micros: 5
max arbitration micros: 20
min symbol latency: 10
max symbol latency: 15
reconnects: 1
masters: 4
messages: 485
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU01;SW=0304;HW=8802", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0111;HW=0103"
address e8: slave, scanned "MF=Vaillant;ID=FMU00;SW=0203;HW=6502"
address ff: master #25, ebusd
welche Verbindung hast du, USB ?
und kannst du einmal ins Log schauen was da zwischen dem ersten Start und einige Minuten später passiert.
was mir noch auffällt, es hat ein reconnect stattgefunden und dann gings offensichtlich.
LG
Zitat von: john30 am 05 April 2021, 09:12:28
nur die files von ebusd-configuration in /etc/ebusd legen, die deine Anlage braucht, und dann ebusd darauf konfigurieren (--configpath).
Alles klar, danke! Ich hatte das nur als die "Offline"-Variante interpretiert. D.h. wenn ebusd ausschließlich die passenden Dateien zur Verfügung hat, zieht es diese immer an, auch wenn es ein Modul an einer bestimmten Adresse häufig nicht erkannt hat? Ich habe dann so Sachen wie:
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"Also das "loaded ..." fehlt und das bekomme ich mit einem reload nicht hin. Mit einigen Neustarts hat es bis jetzt immer funktioniert.
Zitat von: john30 am 05 April 2021, 09:12:28
Option --pollinterval=0
Hätte ich auch selbst drauf kommen können ::) In der Doku nicht gesehen und dann nicht weit genug gedacht...
Danke für den super Support und das tolle Projekt!
Viele Grüße
Reinhard
Zitat von: Reinhart am 05 April 2021, 18:30:45
welche Verbindung hast du, USB ?
Nee, GPIO, also ttyAMA0
Zitat von: Reinhart am 05 April 2021, 18:30:45
und kannst du einmal ins Log schauen was da zwischen dem ersten Start und einige Minuten später passiert.
was mir noch auffällt, es hat ein reconnect stattgefunden und dann gings offensichtlich.
Ich habe ein paar Zeilen ausgelassen:
2021-04-05 17:34:32.312 [main notice] ebusd 21.2.v21.2-12-g86b700c started with auto scan on enhanced device /dev/ttyAMA0
2021-04-05 17:34:32.313 [main info] loading configuration files from http://ebusd.eu/config/
2021-04-05 17:34:32.373 [main info] reading templates /
2021-04-05 17:34:32.434 [main info] read templates in /
2021-04-05 17:34:32.435 [main info] reading file memory.csv
2021-04-05 17:34:32.493 [main info] successfully read file memory.csv
2021-04-05 17:34:32.493 [main info] reading file broadcast.csv
2021-04-05 17:34:32.553 [main info] successfully read file broadcast.csv
2021-04-05 17:34:32.553 [main info] read config files
2021-04-05 17:34:32.554 [bus notice] bus started with own address ff/04
2021-04-05 17:34:32.554 [main info] registering data handlers
2021-04-05 17:34:32.554 [main info] registered data handlers
2021-04-05 17:34:32.582 [bus notice] signal acquired
2021-04-05 17:34:32.751 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:32.751 [bus error] device status: unexpected available enhanced following byte 1
#Wiederholungen gelöscht
#
2021-04-05 17:34:34.033 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:34.033 [bus error] signal lost
2021-04-05 17:34:34.076 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:34.076 [bus error] device status: unexpected available enhanced following byte 1
#Wiederholungen gelöscht
#
2021-04-05 17:34:41.755 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:41.755 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:42.007 [bus error] device status: unexpected enhanced command 0x08
2021-04-05 17:34:42.008 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:42.008 [bus notice] signal acquired
2021-04-05 17:34:42.050 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:42.050 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:42.093 [bus error] device status: unexpected available enhanced byte 2
#Wiederholungen gelöscht
#
2021-04-05 17:34:42.650 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:42.650 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:42.695 [bus error] device status: unexpected enhanced command 0x0e
2021-04-05 17:34:42.737 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:42.738 [bus error] device status: unexpected enhanced command 0x0e
2021-04-05 17:34:42.780 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:42.780 [bus error] device status: unexpected enhanced command 0x0e
2021-04-05 17:34:42.823 [bus error] device status: unexpected available enhanced following byte 1
#Wiederholungen gelöscht
#
2021-04-05 17:34:45.057 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.057 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:45.062 [bus error] device status: unexpected enhanced command 0x0e
2021-04-05 17:34:45.066 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.066 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.069 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.073 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.073 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:45.077 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:45.077 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:45.104 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.117 [bus error] device status: unexpected enhanced command 0x0f
2021-04-05 17:34:45.117 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:45.138 [bus error] device status: unexpected available enhanced byte 2
2021-04-05 17:34:45.143 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.143 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:34:45.147 [bus error] device status: unexpected available enhanced following byte 1
#Wiederholungen gelöscht
#
2021-04-05 17:35:30.580 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.580 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.583 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.592 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.597 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.601 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.602 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.602 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.624 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.629 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.682 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.682 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.682 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.767 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.767 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.767 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.810 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.810 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.810 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.823 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.824 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.824 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:30.824 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:35:31.868 [network info] [00001] client connection opened XXX.YYY.ZZZ.AAA
2021-04-05 17:36:18.255 [network info] [00002] client connection opened 127.0.0.1
2021-04-05 17:36:18.258 [network info] [00002] connection closed
2021-04-05 17:36:33.293 [bus notice] device status: resetting
2021-04-05 17:36:33.293 [bus notice] re-opened /dev/ttyAMA0
2021-04-05 17:36:33.298 [bus notice] signal acquired
2021-04-05 17:36:33.802 [bus error] device status: unexpected available enhanced following byte 1
2021-04-05 17:36:33.878 [bus notice] new master 71, master count 2
2021-04-05 17:36:34.156 [bus notice] device status: reset
2021-04-05 17:36:34.433 [bus notice] new master 03, master count 3
2021-04-05 17:36:34.503 [update info] received MS cmd: 03e8b512060b0000000000 / 0b0000000001ffffffffff00
2021-04-05 17:36:34.503 [update notice] received unknown MS cmd: 03e8b512060b0000000000 / 0b0000000001ffffffffff00
2021-04-05 17:36:34.665 [bus notice] new master 10, master count 4
2021-04-05 17:36:34.725 [update info] received MS cmd: 1008b5110100 / 09ab01ff000308008000
2021-04-05 17:36:34.725 [update notice] received unknown MS cmd: 1008b5110100 / 09ab01ff000308008000
2021-04-05 17:36:34.804 [update info] received MS cmd: 7108b5110107 / 050019010101
nochwas aus der deamon.log:
Apr 5 17:34:32 raspberrypi systemd[1]: ebusd.service: Service RestartSec=30s expired, scheduling restart.
Apr 5 17:34:32 raspberrypi systemd[1]: ebusd.service: Scheduled restart job, restart counter is at 1.
Apr 5 17:34:32 raspberrypi systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Apr 5 17:34:32 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Apr 5 17:34:32 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
Apr 5 17:36:09 raspberrypi systemd[1]: Started Session 4 of user pi
Hallo,
Zitat von: chris371 am 05 April 2021, 15:44:16
Beobachtung am Rande:
Bei der Message hat die Poll-Priorität offenbar keine Wirkung. Egal ob mit "r9" oder "r1", es kommt ein Bündel dieser Messages immer alle --pollinterval Sekunden. Das könnte evtl. ein Bug sein; gemäß Doku hätte ich bei "r9" mit (9 x pollinterval) gerechnet.
Dieser Punkt ist mir auch aufgefallen - muss ich explizit mit --pollinterval=SEC ein Poll-Intervall setzen damit es funktioniert? Bisher scheint bei mir der Standard-Wert 5-Sekunden aktiv zu sein.
Grüße
Dieter
Hallo,
mein Adapter auf einem Raspberry Pi läuft:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=40 -d enh:/dev/ttyAMA0 --address=ff --mqttport=1883 --mqtthost=192.168.xx.xx --mqtttopic=ebusd/%circuit/%name"
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 23
max symbol rate: 127
min arbitration micros: 4
max arbitration micros: 6
min symbol latency: 10
max symbol latency: 28
reconnects: 0
masters: 3
messages: 621
conditional: 2
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0205;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015597']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv"
address ff: master #25, ebusd
Da ich nicht immer einen Internet Zugriff garantieren kann - z.B. nach einem Stromausfall - möchte ich die Konfigurationsdateien lokal ablegen.
Müsste ich dann "--scanconfig" durch z.B. "--configpath=/etc/ebusd/config" ersetzten?
Gibt es nach einem "--scanconfig" irgendwo eine lokale Kopie der erforderlichen Dateien?
Grüße
Dieter
Moin Dieter,
ich schreib mal was ich dazu weiß:
Zitat von: DieterPN am 07 April 2021, 12:53:10
muss ich explizit mit --pollinterval=SEC ein Poll-Intervall setzen damit es funktioniert? Bisher scheint bei mir der Standard-Wert 5-Sekunden aktiv zu sein.
Ich habe das zumindest so gemacht. Nur mit den Standard-Einstellungen kam das Paket mit den 12 YieldThisYear-Nachrichten alle 5 Sekunden ... das war ein wenig heftig. ;)
Zitat von: DieterPN am 07 April 2021, 13:27:32
[...] möchte ich die Konfigurationsdateien lokal ablegen.
Müsste ich dann "--scanconfig" durch z.B. "--configpath=/etc/ebusd/config" ersetzten?
Nein, nur --configpath zusätzlich angeben. Ich habe auf dem Device das Git-Repository geklont...
chris371@smh:~$ cd src/john30
chris371@smh:~/src/john30$ git clone https://github.com/john30/ebusd-configuration.git
chris371@smh:~/src/john30$ cd /etc/ebusd
chris371@smh:/etc/ebusd$ sudo ln -s ~/src/john30/ebusd-configuration/ebusd-2.1.x/de
...und dann "--configpath=/etc/ebusd/de" bei den ebusd-Startparametern ergänzt. Auf die Weise kann man auch als nicht-root an den Config-Dateien herumeditieren, hat im lokalen Git-Repository eine Versions-Historie dazu (was habe ich wann gemacht und warum?), und kann sich bei Bedarf auch aktuelle Stände von John holen, ohne die eigenen Änderungen zu verlieren.
Zitat von: DieterPN am 07 April 2021, 13:27:32
Gibt es nach einem "--scanconfig" irgendwo eine lokale Kopie der erforderlichen Dateien?
Die hatte ich vorher auch gesucht, habe aber keine gefunden.
Guten Abend!
Vorerst Dank an die Hard- und Software Entwickler.
eBUS Adapter 3.0 über RPI funktionierte sofort und läuft tadellos!
leider:
eBUS Adapter 3.0 über LAN funktioniert trotz bereits sehr vielen Stunden ausprobieren nicht.
Meine Config
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20 -d enh:192.168.178.72:9999 --address=ff"
Die Abfrage
pi@TestRPi:~ $ ebusctl i
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
Das Log
021-04-07 19:42:52.332 [main notice] update check: OK
2021-04-07 19:42:58.102 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device 192.168.178.72:9999
2021-04-07 19:42:58.302 [bus error] unable to open 192.168.178.72:9999: ERR: generic I/O error
2021-04-07 19:42:58.303 [bus notice] bus started with own address ff/04
2021-04-07 19:42:58.303 [bus notice] device invalid
2021-04-07 19:43:03.303 [bus error] unable to open 192.168.178.72:9999: ERR: generic I/O error
2021-04-07 19:43:03.304 [bus notice] device invalid
2021-04-07 19:43:08.304 [bus error] unable to open 192.168.178.72:9999: ERR: generic I/O error
2021
Die IP wurde automatisch zugewiesen und auch der Port 9999 ist laut Netzwerkscanner vorhanden, wird aber von ebusd nicht erkannt.
Ich bin am Ende mit meiner Problemlösung (und Wissen) - vielleicht hat jemand eine Lösung?
LG
Zitat von: jutonium am 05 April 2021, 13:50:40
Bei "bai errorhistory = ERR: end of input reached" gehe ich davon aus, dass der ERR bedeutet "kein Fehler", insofern der Wert korrekt ausgewertet wurde.
Wie würde man vorgehen, um die Daten zu dekodieren?
errorhistory braucht noch eine Eingabe, da das eine Liste von Messages ist mit Index.
die "restlichen" zu dekodieren ist halt Fleißarbeit. Messages als hex anschauen (bspw. via grab result) und passende Werte identifizieren und Datentypen zuordnen (da hilft evtl. auch grab result decode).
Zitat von: chris371 am 05 April 2021, 15:44:16
Beobachtung am Rande:
Bei der Message hat die Poll-Priorität offenbar keine Wirkung. Egal ob mit "r9" oder "r1", es kommt ein Bündel dieser Messages immer alle --pollinterval Sekunden. Das könnte evtl. ein Bug sein; gemäß Doku hätte ich bei "r9" mit (9 x pollinterval) gerechnet.
Okay, danke. Ich glaubte, die Poll-Prioritäten in der Message-Definition wären genau für solche unterschiedlichen Intervalle gedacht. Aber aktive Abfrage über MQTT ist trotzdem flexiber, das stimmt schon.
wie der Names sagt ist es eine Priorität und kein Faktor auf das Intervall. Alle Messages in der gleichen Prio 1 werden in jedem Zyklus abgefragt, alles in Prio 2 nur jeden 2. Zyklus. Gibt es keine in Prio 1, dann rutschen die entsprechend nach.
Die yield sind insofern speziell, als dass das eine aus mehreren einzelnen Messages (12 Stück) kombinierte Message ist. Wir die kombinierte 1x abgefragt, braucht es konsequenterweise 12 Abfragen auf den Bus dafür.
Zitat von: DieterPN am 07 April 2021, 13:27:32
Müsste ich dann "--scanconfig" durch z.B. "--configpath=/etc/ebusd/config" ersetzten?
du kannse scanconfig auch mit lokalen files nutzen. einfach nur configpath auf das latest/de oder latest/en Verzeichnis des geclonten ebusd-config repos setzen.
Zitat von: DieterPN am 07 April 2021, 13:27:32
Gibt es nach einem "--scanconfig" irgendwo eine lokale Kopie der erforderlichen Dateien?
nein
Zitat von: raimundl am 07 April 2021, 21:42:11
Die IP wurde automatisch zugewiesen und auch der Port 9999 ist laut Netzwerkscanner vorhanden, wird aber von ebusd nicht erkannt.
Ich bin am Ende mit meiner Problemlösung (und Wissen) - vielleicht hat jemand eine Lösung?
reagiert die IP auf nen ping?
Und passen die LEDs am Adapter laut Doku?
Zitat von: john30 am 07 April 2021, 22:49:07
reagiert die IP auf nen ping?
Und passen die LEDs am Adapter laut Doku?
Guten Morgen!
Habe nun wieder von RPI auf LAN umgebaut und siehe da es funktioniert problemlos. Wieso kann ich nicht erklären, da ich nichts (wissentlich) verändert habe.
Trotzdem Danke für die Hilfestellung!
Eine Bitte noch - nachstehend meine funktionierende Configuration, bitte um Überprüfung ob fachlich in Ordnung.
EBUSD_OPTS="--latency=20 -d enh:192.168.178.72:9999 --address=ff -l /var/log/ebusd.log --scanconfig --accesslevel=* --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=192.168.178.53 --mqtttopic=ebusd/%circuit/%name"
Danke und LG
Zitat von: john30 am 07 April 2021, 22:43:41
Alle Messages in der gleichen Prio 1 werden in jedem Zyklus abgefragt, alles in Prio 2 nur jeden 2. Zyklus. Gibt es keine in Prio 1, dann rutschen die entsprechend nach.
Aah! Das mit dem Nachrücken war mir nur durchs lesen der Doku nicht klar geworden. Danke für die Erläuterung. :)
Hallo,
ich habe noch Fragen zum Polling:
Ich habe versucht die
ZitatOption --pollinterval=0
in /etc/default/ebusd einzusetzen (EBUSD_OPTS). Danach lässt sich der service ebusd nicht mehr starten.
Muss --pollinterval=0 an einer bestimmten Stelle eingesetzt werden?
In einem Beitrag hatte ich gelesen das
ZitatPoll-Prioritäten in der Message-Definition
eingestellt werden können.
Wo finde ich eine Beschreibung wie das gemacht wird? Ich habe schon viel gelesen aber wohl nicht die richtige Seite gefunden.
Grüße
Dieter
Zitat von: DieterPN am 09 April 2021, 11:09:33
Ich habe versucht die [Option --pollinterval=0] in /etc/default/ebusd einzusetzen (EBUSD_OPTS). Danach lässt sich der service ebusd nicht mehr starten.
Darüber bin ich auch schon gestolpert: --pollinterval=0 geht nicht zusammen mit --scanconfig. John hatte das hier bestätigt:
Zitat von: john30 am 21 März 2021, 14:58:23
das Scannen der Geräte geht nur in Kombination mit Polling.
Zitat von: DieterPN am 09 April 2021, 11:09:33
In einem Beitrag hatte ich gelesen das [Poll-Prioritäten in der Message-Definition] eingestellt werden können.
Wo finde ich eine Beschreibung wie das gemacht wird?
Das steht in der Message-Definition auf Johns Wiki (https://github.com/john30/ebusd/wiki/4.1.-Message-definition). Gleich die erste Spalte "TYPE".
Zitat von: chris371 am 09 April 2021, 12:25:56
Darüber bin ich auch schon gestolpert: --pollinterval=0 geht nicht zusammen mit --scanconfig. John hatte das hier bestätigt:
Danke für die Info - aber wie/wann kann ich dann "--pollinterval=0" überhaupt einsetzen?
Zitat von: DieterPN am 09 April 2021, 12:50:32
Danke für die Info - aber wie/wann kann ich dann "--pollinterval=0" überhaupt einsetzen?
Nur zusammen mit der statischen Konfiguration. Also nur die für Deine Anlage relevanten CSVs und INCs lokal in einen Ordner legen und den --configpath dorthin umbiegen.
Ich war auch in Versuchung, das zu machen, aber da es in meiner Anlage noch unbekannte Devices gibt, wollte ich gern von vielleicht späteren Updates im Configuration-GIT profitieren. ;D
Eigentlich gefällt es mir auch besser, den ebusd pollen zu lassen, weil das MQTT ja eigentlich genau für asynchrone Benachrichtigungen gedacht ist, und man so mehr Anlagen-spezifisches vom ebusd abhandeln lassen kann. Also bleibe ich vermutlich bei einem heraufgesetzten Poll-Interval.
Hallo,
noch eine Frage zur doppelten Rückgabe:
ZitatZitat von: Pretender am 04 April 2021, 20:36:16
Ist es eigentlich normal, dass nach einer Werteabfrage der Wert zweimal zurückgegeben wird:
john30: ja.
Kann man davon ausgehen das beide zurückgegebenen Werte gleich sind (bis auf den Zeitpunkt)?
Ich suche ein Kriterium einen der beiden Werte zu ignorieren.
Grüße
Dieter
Zitat von: raimundl am 08 April 2021, 08:27:54
Habe nun wieder von RPI auf LAN umgebaut und siehe da es funktioniert problemlos. Wieso kann ich nicht erklären, da ich nichts (wissentlich) verändert habe.
Trotzdem Danke für die Hilfestellung!
Eine Bitte noch - nachstehend meine funktionierende Configuration, bitte um Überprüfung ob fachlich in Ordnung.
EBUSD_OPTS="--latency=20 -d enh:192.168.178.72:9999 --address=ff -l /var/log/ebusd.log --scanconfig --accesslevel=* --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=192.168.178.53 --mqtttopic=ebusd/%circuit/%name"
sieht in Ordnung aus. den letzten Parameter (mqtttopic) müsstest Du Dir auch sparen können, da das sehr nach dem default aussieht.
Zitat von: DieterPN am 09 April 2021, 16:45:49
Kann man davon ausgehen das beide zurückgegebenen Werte gleich sind (bis auf den Zeitpunkt)?
eigentlich ja, aber ich würde dennoch nicht davon ausgehen.
Im Prinzip sollte mit "--mqttchanges" die Message auch nur dann 2x kommen, wenn sich der Wert wirklich geändert hat. Die erste Message kommt gezwungenermaßen als Antwort auf den Request.
Zitat von: john30 am 05 April 2021, 09:12:28
nur die files von ebusd-configuration in /etc/ebusd legen, die deine Anlage braucht, und dann ebusd darauf konfigurieren (--configpath).
Ich fürchte, das habe ich noch nicht ganz verstanden. Die Dateien liegen bei mir unter /etc/ebusd und werden auch dort angezogen. Aber um es wirklich statisch zu machen, müsste ich doch dem ebusd z.B. irgendwie sagen können:
Adresse 15 ist "MF=Vaillant;ID=UI ;SW=0508;HW=6201", lade bitte die Datei "vaillant/15.ui.csv", also letztendlich was das System gescannt hat.
Eine Frage hätte ich noch zum Scannen: Wenn ebusd startet, bekomme ich von dem CC und HWC (Adresse 23 und 25) sehr oft den Fehler
[main error] scan config 23: ERR: read timeoutWenn ich es im Nachgang ein paar Mal mit einem
scan 23 versuche, wird das Gerät gefunden - allerdings wird die Konfigdatei nicht mehr geladen, in diesem Fall die vaillant/23.solsy.cc.csv. Gibt es da eine bestimmte Logik? Ich dachte an Gerät gefunden, Daten werden geprüft, geeignetes Konfigfile laden. Sollte das so sein, auch wenn man nachträglich scannt?
Kann das auf die Issue #398 hindeuten? Ich hatte jedoch nie eine 3.x Version am laufen.
Eine ganz dumme Frage hätte ich noch: Was bedeutet BAI ausgeschrieben?
Danke und einen schönen Sonntag!
Reinhard
Zu statischen Konfiguration kann ich etwas sagen:
Zitat von: Pretender am 11 April 2021, 13:41:20
Aber um es wirklich statisch zu machen, müsste ich doch dem ebusd z.B. irgendwie sagen können:
Adresse 15 ist "MF=Vaillant;ID=UI ;SW=0508;HW=6201", lade bitte die Datei "vaillant/15.ui.csv", also letztendlich was das System gescannt hat.
Bei aktiviertem --scanconfig benötigt der ebusd die weiteren Informationen (MF, ID, SW, HW) aus der scan-Message, um aus den ganz vielen Dateien für die Adresse 15 die richtige auswählen und laden zu können.
Ohne --scanconfig hast Du ihm diese Auswahl bereits abgenommen, indem Du nur die für Deine Anlage relevanten Dateien in den --configpath gelegt hast. Der ebusd läd dann einfach von vornherein immer
sämtliche Dateien, die er dort findet. Wegen Deiner Vorauswahl gibt es darunter aber nur eine für Adresse 15. Und die wird dann auch für das entsprechende Device genommen.
Zitat von: chris371 am 11 April 2021, 15:39:49
Bei aktiviertem --scanconfig benötigt der ebusd die weiteren Informationen (MF, ID, SW, HW) aus der scan-Message, um aus den ganz vielen Dateien für die Adresse 15 die richtige auswählen und laden zu können.
Ohne --scanconfig hast Du ihm diese Auswahl bereits abgenommen, indem Du nur die für Deine Anlage relevanten Dateien in den --configpath gelegt hast. Der ebusd läd dann einfach von vornherein immer sämtliche Dateien, die er dort findet. Wegen Deiner Vorauswahl gibt es darunter aber nur eine für Adresse 15. Und die wird dann auch für das entsprechende Device genommen.
genau!
Zitat von: Pretender am 11 April 2021, 13:41:20
Eine Frage hätte ich noch zum Scannen: Wenn ebusd startet, bekomme ich von dem CC und HWC (Adresse 23 und 25) sehr oft den Fehler
[main error] scan config 23: ERR: read timeout
das heißt, dass das Gerät nicht rechtzeitig antwortet. Sollte eigentlich nicht passieren, aber ich bräuchte mehr Kontext, um das besser beurteilen zu können. Also bspw. mal raw log anschalten, wo man dann das Timing genau sehen kann.
Hast Du die "--latency=" eingestellt?
Zitat von: Pretender am 11 April 2021, 13:41:20
Eine ganz dumme Frage hätte ich noch: Was bedeutet BAI ausgeschrieben?
das weiß ich auch nicht. Das ist die ID, mit der sich das Gerät meldet. Bspw. "EHP" steht für eletric heat pump, oder "HWC" steht für hot water circuit und CC für circulation circuit.
Guten Morgen!
Da nun alles problemlos läuft eine Frage zum traffic am ebus:
Dieses Thema wird ja sehr häufig diskutiert - ich kann jedoch keinen Schluss daraus für mich ziehen.
Viele der Aktualisierungen am ebus finden bei mir alle 10 Sekunden statt. Ist diese Aktualisierungsfrequenz im Hinblick auf eine eventuelle Belastung des Gerätes in Ordnung?
Oder sollte man nur aktiv den ebus mit bestimmten Werten abfragen?
Zitat von: chris371 am 11 April 2021, 15:39:49
Ohne --scanconfig hast Du ihm diese Auswahl bereits abgenommen, indem Du nur die für Deine Anlage relevanten Dateien in den --configpath gelegt hast. Der ebusd läd dann einfach von vornherein immer sämtliche Dateien, die er dort findet.
Alles klar! Man sollte dann auch die include-Dateien löschen, die man nicht benötigt richtig? Das 08.bai.csv zieht ja die inc-Datei an, die dem Scanergebnis entspricht. Bei mir wird die bai.308523.inc geladen, d.h. das "last resort" wenn man so sagen will. Aber ansonsten müsste ich doch in die csv reinschreiben:
!load,bai.<meine-anlage>.inc,,,Denn mehrere incs enthalten z.B. den Wert WaterHcFlowMax und dann gewinnt wahrscheinlich die zuletzt geladene Konfiguration.
Danke und viele Grüße
Reinhard
Zitat von: john30 am 11 April 2021, 20:08:49
Also bspw. mal raw log anschalten, wo man dann das Timing genau sehen kann.
Hast Du die "--latency=" eingestellt?
Ja. Meine Startparameter sehen so aus:
EBUSD_OPTS="--scanconfig --configpath=/etc/ebusd --accesslevel=* --mqttport=1883 --mqtthost=localhost --mqtttopic=ebusd/%circuit/%name --latency=20000 -d enh:/dev/ttyAMA0 --log=all:error --log=main:info --log=bus:info --address=ff"Den Latenzwert habe ich nicht verändert.
Was brauchst du beim Raw Log genau?
Reicht es bei laufendem ebusd unter ebusctl raw logging zu aktivieren, ein scan Kommando abzusetzen und dann wieder deaktivieren, oder brauchst du das ab Start des ebusd?
Danke Dir und viele Grüße
Reinhard
Zitat von: raimundl am 12 April 2021, 08:02:30
eine Frage zum traffic am ebus:
Dieses Thema wird ja sehr häufig diskutiert - ich kann jedoch keinen Schluss daraus für mich ziehen.
Viele der Aktualisierungen am ebus finden bei mir alle 10 Sekunden statt. Ist diese Aktualisierungsfrequenz im Hinblick auf eine eventuelle Belastung des Gerätes in Ordnung?
Ich tue mich auch etwas schwer damit, mich für ein bestimmtes Vorgehen zu entscheiden. Aber ich verstehe auch nicht ganz, was Du mit "Aktualisierungen" meinst.
- Der Bus ist ja dazu da, damit sich die einzelnen Komponenten der Heizungsanlage unterhalten können. Das tun sie ganz unabhängig vom ebusd und dem Adapter natürlich auch. Normalerweise passiert das in einem bestimmten Rhythmus, der sich der Hersteller so ausgedacht hat, und ist natürlich in dieser Form damit auch vollkommen okay. Man weiß aber nie, ob/wann sich dieser Rhythmus vielleicht auch mal im Betrieb ändern könnte.
- Diesen Traffic kann man mit dem ebusd gefahrlos "belauschen" und diese Daten verwenden. Egal, wie viele "Aktualisierungen" da pro Zeit passieren.
- Potentiell heikel wird es erst, wenn der ebusd selber aktiv auf den Bus zugreift. Dann wäre es denkbar, dass er damit die Kommunikation der restlichen Teilnehmer durcheinanderbringt.
Die gute Nachricht ist, dass man dieses Risiko durch die Wahl der (ja auch hier empfohlenen) --address=ff recht klein halten kann. Diese Master-Adresse für den ebusd sorgt zusammen mit dem Arbitrierungsmechanismus aus der eBus-Spezifikation dafür, dass der ebusd keinen der anderen Master vom Bus "verdrängen" kann - WENN sich denn alle Geräte exakt an die Spezifikation halten und auch keine Bugs in der Implementation (auch bei den Geräten der vorhandenen Heizung!) schlummern.
Da alle Entwickler nur Menschen sind und wir nun mal Fehler machen, kann man also nie ganz ausschließen, dass aktives Senden des ebusd "irgendwas" der normalen Buskommunikation durcheinanderbringt. Daher kann eigentlich fürs aktive Senden nur gelten:
So wenig wie möglich und nur so viel wie nötig.
Zitat von: Pretender am 12 April 2021, 09:57:09
Man sollte dann auch die include-Dateien löschen, die man nicht benötigt richtig? Das 08.bai.csv zieht ja die inc-Datei an, die dem Scanergebnis entspricht.
Gute Frage. Das Scan-Ergebnis liegt ja bei der statischen Konfiguration gar nicht vor. Mal sehen, was John dazu sagt. :)
Zitat von: chris371 am 12 April 2021, 10:09:23
Ich tue mich auch etwas schwer damit, mich für ein bestimmtes Vorgehen zu entscheiden. Aber ich verstehe auch nicht ganz, was Du mit "Aktualisierungen" meinst.
Die gute Nachricht ist, dass man dieses Risiko durch die Wahl der (ja auch hier empfohlenen) --address=ff recht klein halten kann. Diese Master-Adresse für den ebusd sorgt zusammen mit dem Arbitrierungsmechanismus aus der eBus-Spezifikation dafür, dass der ebusd keinen der anderen Master vom Bus "verdrängen" kann - WENN sich denn alle Geräte exakt an die Spezifikation halten und auch keine Bugs in der Implementation (auch bei den Geräten der vorhandenen Heizung!) schlummern.
Danke Chris371!
Mit dieser Aussage habe ich meine Entscheidung getroffen - das Busgeschehen werde ich nicht beeinflussen, meine abgesetzten read/write Befehle halten sich wirklich in Grenzen. Daher widme ich mich nun der Visualisierung der Werte.
LG
Zitat von: john30 am 07 April 2021, 22:40:59
errorhistory braucht noch eine Eingabe, da das eine Liste von Messages ist mit Index.
die "restlichen" zu dekodieren ist halt Fleißarbeit. Messages als hex anschauen (bspw. via grab result) und passende Werte identifizieren und Datentypen zuordnen (da hilft evtl. auch grab result decode).
Vielleicht hier eine Frage, ich habe inzwischen mit grab "herumgespielt" - es ist in der Tat Fleißarbeit, und was ggf helfen würde, was ich aber noch nicht gefunden habe. Einen Sniffer gibt es nicht, oder? Also die Möglichkeit das ganze zur Laufzeit auch schon gruppiert zu bekommen.
Beispiel wäre dann die Datenbytes in der Anzeige laufend zu überschreiben wenn von gleicher Quelle an das gleiche Ziel mit gleicher Dienstgruppe Daten gesendet wird. Würde mir helfen... bin ich zu blöd das einzustellen?
Hallo,
ich melde mich jetzt auch mal zu Wort. Habe den Adapter jetzt bereits seit 27.01.2021 und ihn am 31.01.2021 mit einem Wemos D1 Mini in Betrieb genommen.
Alle aktuellen Builds sowohl auf den ESP8266 als auch beim ebusd installiert (hatte für die Testphase noch ältere Versionen drauf, dank DHL kam es ja aber nicht dazu ;) ).
Seit diesem Datum lief alles auch ohne Probleme zusammen mit HomeAssistant und der ebusd Integration. Habe dann zwischenzeitlich noch begonnen über MQTT weitere Werte abzurufen, bin aber bei ersten Tests bei einem hängen geblieben und seitdem fehlte die Zeit das ganze komplett über MQTT abzufragen ohne die ebusd-Integration.
Nun fiel mir aber am Sonntag (11.04.2021) plötzlich auf, dass keine neueren Daten mehr kommen. Erste Vermutung HomeAssistant macht quatsch (dort bastelt man ja am meisten rum), also Docker neu gestartet, aber nichts...
Wieder zu Hause nach geschaut, LEDs am Adapter blinken weiterhin schön vor sich hin, auch der Wemos blinkt wie immer. Trotz allem dort mal auf die Weboberfläche geschaut. Trotz blinken stand dort das keine Verbindung zum Bus bestehen würde, also neu gestartet. Läuft.
Kennt ihr das schon, ist das nach den knappen 2,5 Monaten ein Speichervolllaufen oder ähnliches?
In der Weboberfläche stand noch was von freeHeap oder so, das hat sich nach dem Neustart als einzigstes merklich geändert.
@Hispanic:
Ist mir auch so passiert, aber mit einem eBus Adapter mit Ethernet (USR-ES1). Ich denke, dass der Adapter ca. 2 Wochen lief.
Am 19.04. gegen 4:20 kamen die letzten Werte im Home Assistant an.
Adapter war nicht pingbar, mehrfach neu gestartet, anderer Port am Switch und der Adapter hat wieder eine IP bekommen und war pingbar. Aber ebusd konnte nicht mit dem Adapter kommunizieren.
ebusd:
2021-04-19 21:21:30.370 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device 192.168.x.x:9999
2021-04-19 21:21:30.382 [bus error] unable to open 192.168.x.x:9999: ERR: generic I/O error
2021-04-19 21:21:30.383 [bus notice] bus started with own address 31/36
2021-04-19 21:21:30.383 [bus notice] device invalid
2021-04-19 21:21:35.383 [bus error] unable to open 192.168.x.x:9999: ERR: generic I/O error
Wobei sich die letzten beiden Zeilen wiederholt haben.
Nachdem der Adapter eine Weile stromlos war, konnte ebusd wieder Kontakt aufnehmen.
Die fraglichen Ports am Switch waren in einem Test alle in Ordnung.
Ähnlich wie hier:
https://forum.fhem.de/index.php/topic,116418.msg1117577.html#msg1117577
Hallo,
ich bin mit meinem eBUS Adapter vom Raspberry PI 3+ auf einen PI 4 gewechselt und habe alles neu installiert.
'ebusd' läuft wie vorher aber ich kann keinen Autostart einrichten:
sudo systemctl enable ebusd
ebusd.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ebusd
Habt ihr Tipps was ich anders machen muss?
Grüße
Dieter
Zitat von: DieterPN am 26 April 2021, 07:57:32
sudo systemctl enable ebusd
ebusd.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ebusd
Moin,
Du nutzt die deb-Pakete zur Installation?
Da hatte ich das Problem auch. Ich bin mit der aktuellen Version (21.2) in das Abenteuer ebus gestartet, daher keine Ahnung wie es vorher war.
Wenn Du Dir den Paketinhalt ansiehst, wirst du sehen, dass kein systemd Servicefile vorhanden ist.
Ich habe mir das daher direkt aus Github geholt, https://github.com/john30/ebusd/tree/master/contrib/debian/systemd (https://github.com/john30/ebusd/tree/master/contrib/debian/systemd).
Das kopierst Du dann nach
/usr/lib/systemd/system/ und passt ggf. die Rechte analog zu den anderen Service-Dateien an.
Evtl. ist noch ein
systemctl daemon-reload notwendig. Danach solltest Du ebusd wie gewohnt steuern können.
Grüße
Reinhard
Zitat von: jutonium am 19 April 2021, 22:43:33
@Hispanic:
Ist mir auch so passiert, aber mit einem eBus Adapter mit Ethernet (USR-ES1). Ich denke, dass der Adapter ca. 2 Wochen lief.
Am 19.04. gegen 4:20 kamen die letzten Werte im Home Assistant an.
Adapter war nicht pingbar, mehrfach neu gestartet, anderer Port am Switch und der Adapter hat wieder eine IP bekommen und war pingbar. Aber ebusd konnte nicht mit dem Adapter kommunizieren.
[...]
Wobei sich die letzten beiden Zeilen wiederholt haben.
Nachdem der Adapter eine Weile stromlos war, konnte ebusd wieder Kontakt aufnehmen.
Die fraglichen Ports am Switch waren in einem Test alle in Ordnung.
Ähnlich wie hier:
https://forum.fhem.de/index.php/topic,116418.msg1117577.html#msg1117577
Ich gehe hier sogar über WLAN, da hat der ESP ja sogar noch eine eigene Firmware.
Das ganze läuft ansich auch total stabil, bis auf den einen kleinen Hänger.
Gibt es in irgendwelchen Optionen oder ähnlichem die Möglichkeit den ESP aus der Heimautomatisierung neu zu starten?
Ich werde mich wieder melden sobald das Problem noch einmal auftreten sollte, eventuell möchte das dann jemand Live untersuchen?
du könntest einen Watchdog mit einem notify einrichten, der irgend einen Wert vom eBus überwacht ( zB: Disconnected oder Vorlauf Error ) und dann einen "reopen" einleitet.
define EBUS.Watchdog notify (EBUS.*DISCONNECTED.*)|(Vorlauf:Vorlauf.*err) { EBUSrecover("notify EBUS.Watchdog",0)}
attr EBUS.Watchdog group ECMD
attr EBUS.Watchdog icon dog_silhouette
die Definition in Fhem, bei "Vorlauf error" wird die Subroutine "EBUSrecover" aufgerufen
sub EBUSrecover($$)
{
my ($evt,$num) = @_;
Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
if(Value("EBUS") ne "opened"){
if( $num < 7){
$num++;
fhem("set EBUS reopen");
DebianMail('Ausfall eBus FHEM','Ausfall Ebus, reconnect wird versucht');
fhem("define EBUSrecoverdly at +00:01:00
{EBUSrecover('EBUSrecover',$num)}");
}else{
fhem("set Device.warn EBUS")
}
}
}
und hier die Subroutine dazu die man in die 99_myUtils legen kann. Es wird ein "reopen" initiiert! Hier wird auch noch eine Mail abgesetzt damit ich das mitbekomme.
Den ESP kannst dabei aber so nicht neu starten, dazu müsstest du die Spannungsversorgung gleichzeitig kurz unterbrechen.
LG
Zitat von: Pretender am 26 April 2021, 08:24:37
Ich habe mir das daher direkt aus Github geholt, https://github.com/john30/ebusd/tree/master/contrib/debian/systemd (https://github.com/john30/ebusd/tree/master/contrib/debian/systemd).
Das kopierst Du dann nach /usr/lib/systemd/system/ und passt ggf. die Rechte analog zu den anderen Service-Dateien an.
Evtl. ist noch ein systemctl daemon-reload notwendig. Danach solltest Du ebusd wie gewohnt steuern können.
Danke! Hat funktioniert.
Ich habe den Ebus Adapter erfolgreich über Wifi installiert. Den Adapter habe ich an den eBUS meiner Vaillant VRC 630 Regelung angeschlossen.
Die grüne Leuchte blinkt und es sollten somit Daten übertragen werden.
Über die IP kann ich den Adapter ansprechen:
eBUS adapter 3
Build: 20201122
ebusd device string: enh:192.168.8.xxx:9999
WiFi signal: 62% (-69dBm)
Chip ID: 00d17d9a
Hostname: ebus-d17d9a
Up time: 149
Free heap: 34840
ebusd connected: no
eBUS signal: no signal
Obwohl die grüne Leuchte blinkt, ist scheinbar kein eBUS Signal vorhanden. Hat jemand eine Idee woran das liegen könnte?
die grüne Led blinkt sobald physikalisch am Adapter der eBus angeschlossen ist und auch ein Signal detektiert wird. Ob auch auch die Konfiguration bis zum Dämon korrekt ist ist damit nicht gesagt.
Poste doch bitte einmal deine Config vom Dämon ( /etc/default/ebusd ) denn die WIFI Einstellungen scheinen ja korrekt zu sein!
LG
Hallo,
ich hoffe das ich hier richtig bin und es OK ist, dass ich hier meine Frage stelle ?
Ich versuche gerade meinen neuen Bus Adapter anzuschließen, jedoch bekomme ich über LAN keine IP zugewiesen ?!
Der Adapter ist über LAN angeschlossen und die Jumper sind richtig gesetzt, jedoch bekommt der Adapter irgendwie keine IP zugewiesen.
DHCP funktioniert ansonsten bei neuen Geräten einwandfrei.
Woran könnte das liegen ?
Und mit dem Thema eine Feste IP zuweisen schnall ich nicht ganz wie und wo ich welche Software installieren muss um den Adapter zu programmieren.
Ich hoffe ihr könnt mir weiterhelfen ?
Grüße & Danke
Totti
Zitat von: TottiToad am 05 Mai 2021, 19:34:51
Ich versuche gerade meinen neuen Bus Adapter anzuschließen, jedoch bekomme ich über LAN keine IP zugewiesen ?!
Der Adapter ist über LAN angeschlossen und die Jumper sind richtig gesetzt, jedoch bekommt der Adapter irgendwie keine IP zugewiesen.
hast du wirklich alle jumper kontrolliert, insbesondere auch J1 und J4? siehe hier (https://adapter.ebusd.eu/#ethernet)
Zitat von: Reinhart am 05 Mai 2021, 10:45:04
die grüne Led blinkt sobald physikalisch am Adapter der eBus angeschlossen ist und auch ein Signal detektiert wird. Ob auch auch die Konfiguration bis zum Dämon korrekt ist ist damit nicht gesagt.
Poste doch bitte einmal deine Config vom Dämon ( /etc/default/ebusd ) denn die WIFI Einstellungen scheinen ja korrekt zu sein!
LG
Ich verwende openhab auf einem Pi4 und habe das dortige Ebus Binding installiert. Soweit ich herausgefunden habe, muss ich da noch den ebusd Dämon installieren. Leider weiß ich nicht wie das unter openhabian geht. Kann mir das bitte jemand erklären oder gibt es einen Link auf eine Anleitung. Meine Suche hat da leider kein Ergebnis geliefert.
Zitat von: r-schmid@gmx.at am 07 Mai 2021, 14:18:44
Soweit ich herausgefunden habe, muss ich da noch den ebusd Dämon installieren. Leider weiß ich nicht wie das unter openhabian geht. Kann mir das bitte jemand erklären oder gibt es einen Link auf eine Anleitung.
Für mich hat die Anleitung auf Johns Wiki wunderbar funktioniert:
https://github.com/john30/ebusd/wiki/1.-Build-and-install
Ich habe allerdings keinen Raspberry sondern eine VM mit Ubuntu 20.04.2 Server, und habe da den Weg über das Kompilieren der Sourcen gewählt.
Den ebusd Daemon habe ich mittlerweile installiert.
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"
-d enh:192.168.8.162:9999
Der Adapterstatur ist nun:
ebusd connected: yes (inactive)
eBUS signal: no signal
eBUS initial signal: echo
Wie kann ich den ebusd aktivieren und das eBUS Signal bekommen?
Hallo zusammen,
durch den Umstieg vom Raspi 3 auf Raspi 4 bin ich auch vom ebus Adapter 2 auf den 3er umgestiegen. Leider bekomme ich den V3 (RPI Version) mit meiner WOLF Lüftungsanlage nicht zum Laufen. :-(
Was passiert - Raspi startet, auf dem Adapter:
- gelbe LED leuchtet
- grüne LED blinkt sehr schnell
- blaue LED geht für ein paar Sekunden mit normaler Helligkeit an, dann aus und dann wieder mit hoher Helligkeit an
Config:
--device=enh:/dev/ttyAMA0 --latency=50 --scanconfig --localhost --port=8889 --mqttretain --mqttchanges --mqtthost=localhost --mqttport=1883 --mqtttopic=ebusd2/%circuit/%name/%field --pidfile=/var/run/ebusd2.pid --logfile=/var/log/ebusd2.log --accesslevel=* --address=ff --loglevel=debug
ebustclt -p 8889 i
version: ebusd 21.2.v21.2
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
Habe auch schon mit er Latency gespielt - keine Erfolg. Kabellänge ist ca. 5m und wie schon erwähnt - mit dem Raspi 3 und dem Adapter V2 lief es.
Die Anleitungen für Einrichtung des Serial Ports habe ich auch schon mehrfach durch - sollte passen.
Spontane Ideen?
Danke
Sebastian
die seriellen Einstellungen (https://forum.fhem.de/index.php/topic,118143.msg1139968/topicseen.html#msg1139968) ( raspi-config) hast du beachtet?
Ansnsonsten würde ich dir empfehlen zunächst alles auf USB ( ttyUSBO ) zu testen, dann bist du dir sicher obs an der internen seriellen ( ttyAMA0 ) liegt oder nicht.
Den ebusd wollte ich mit der buster distribution ohne mqtt installieren:
Ich bin dieser Anleitung gefolgt https://github.com/john30/ebusd-debian
## Release = Raspbian GNU/Linux 10 (buster)
## Kernel = Linux 5.10.17-v7l+
## Platform = Raspberry Pi 4 Model B Rev 1.2
Bei der Installation der Updates (vorletzter Punkt der Anleitung) bekomme ich Fehlermeldungen:
apt-get update
OK:1 http://archive.raspberrypi.org/debian buster InRelease
Holen:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15,0 kB]
OK:3 https://deb.nodesource.com/node_14.x buster InRelease
Fehl:4 https://dl.bintray.com/openhab/apt-repo2 stable InRelease
403 Forbidden [IP: 18.158.192.105 443]
Holen:5 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13,0 MB]
OK:6 https://www.ebusd.eu/repos/apt/nomqtt/buster buster InRelease
Paketlisten werden gelesen... Fertig
E: Fehlschlag beim Holen von https://dl.bintray.com/openhab/apt-repo2/dists/stable/InRelease 403 Forbidden [IP: 18.158.192.105 443]
E: Das Depot »https://dl.bintray.com/openhab/apt-repo2 stable InRelease« ist nicht mehr signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
Gibt es dafür einen Workaround?
Das ebusd log file /var/log/ebusd.log hat mittlerweile 170MB da steht:
...2021-05-14 14:07:50.406 [bus error] device status: unexpected available enhanced byte 2
2021-05-14 14:07:50.408 [bus error] device status: unexpected available enhanced byte 2
2021-05-14 14:07:50.411 [bus error] device status: unexpected available enhanced following byte 1
2021-05-14 14:07:50.421 [bus error] device status: unexpected available enhanced byte 2
2021-05-14 14:07:50.429 [bus error] device status: unexpected available enhanced following byte 1
2021-05-14 14:07:50.437 [bus error] device status: unexpected available enhanced following byte 1
2021-05-14 14:07:50.443 [bus error] device status: unexpected available enhanced following byte 1
2021-05-14 14:07:50.468 [bus error] device status: unexpected available enhanced byte 2
2021-05-14 14:07:50.475 [bus error] device status: unexpected available enhanced following byte 1
2021-05-14 14:07:50.476 [bus error] device status: unexpected available enhanced byte 2
2021-05-14 14:07:50.506 [bus error] device status: unexpected enhanced command 0x0e
ZitatGibt es dafür einen Workaround?
Siehe hier: https://community.openhab.org/t/the-stable-release-linux-repositories-have-changed-location/121261#faq-5 (https://community.openhab.org/t/the-stable-release-linux-repositories-have-changed-location/121261#faq-5)
Soll heißen, in den Dateien unterhalb von /etc/apt/sources.list.d/* den Verweis
"deb https://dl.bintray.com/openhab/apt-repo2 stable main" löschen/auskommentieren.
Hat bei mir geklappt.
Gruß Torsten
Hat bei mir auch geklappt. Danke!
Ich habe ebusd nochmals neu installiert. Im ebusd.log steht nun:
2021-05-16 10:34:12.994 [main notice] ebusd 21.2.v21.2 started with auto scan on enhanced device 192.168.8.162:9999
2021-05-16 10:34:13.479 [bus notice] bus started with own address ff/04
2021-05-16 10:34:13.485 [bus notice] device status: reset
2021-05-16 10:34:13.532 [bus error] device status: unexpected available enhanced byte 2
2021-05-16 10:34:13.532 [bus notice] signal acquired
2021-05-16 10:34:13.571 [bus error] device status: unexpected enhanced command 0x0e
2021-05-16 10:34:13.614 [bus error] device status: unexpected enhanced command 0x0e
2021-05-16 10:34:13.657 [bus error] device status: unexpected enhanced command 0x0e
2021-05-16 10:34:13.700 [bus error] device status: unexpected enhanced command 0x0e
2021-05-16 10:34:13.704 [bus error] device status: unexpected available enhanced following byte 1
2021-05-16 10:34:13.713 [bus error] device status: unexpected available enhanced following byte 1
Was könnte die Ursache für den bus error sein?
Die Anleitung Punkt 4. Make the daemon autostart with 'update-rc.d ebusd enable' führt zu:
Failed to enable unit: Unit /run/systemd/generator.late/ebusd.service is transient or generated.
Die Statusabfragen ebusctl info & systemctl status ebusd scheinen vernünftig:
[10:41:25] root@openhab:/home/openhabian# ebusctl info
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 54
max symbol rate: 156
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
[10:42:55] root@openhab:/home/openhabian# systemctl status ebusd
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated)
Active: active (running) since Sun 2021-05-16 10:34:12 CEST; 9min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/ebusd.service
└─13599 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig --accesslevel=* --latency=100 -d enh:192.168.8.162:9999 --address=ff
Mai 16 10:34:12 openhab systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Mai 16 10:34:12 openhab ebusd[13593]: Starting ebusd: ebusd.
Mai 16 10:34:12 openhab systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
@r-schmid@gmx.at:
kann dir nur bzgl. dem Autostart helfen:
sudo systemctl enable ebusd.service
startet den ebusd beim Systemstart ab Jessie (?)
Gruß Torsten
Ich habe ein paar (für mich) interessante Temperaturwerte in einer noch nicht dekodierten Message entdeckt, und wollte die nun gerne das entsprechende Config-File nachtragen.
Es geht um diese Message:
2021-05-17 16:39:09.233 [update notice] received unknown MS cmd: 10ecb5040110 / 0a94039401008000807103
Dafür muss ich (bei mir) die ec.solsy.sc.csv erweitern, und zwar habe ich das so gemacht:
$ git diff
diff --git a/ebusd-2.1.x/de/vaillant/ec.solsy.sc.csv b/ebusd-2.1.x/de/vaillant/ec.solsy.sc.csv
index b911917..7ae1811 100644
--- a/ebusd-2.1.x/de/vaillant/ec.solsy.sc.csv
+++ b/ebusd-2.1.x/de/vaillant/ec.solsy.sc.csv
@@ -54,5 +54,6 @@ r,,SolOperatingMode,Betriebsart,,,,"AC00",,,UCH,,,Operating mode solar
r,,SolTeleswitchOperatingMode,Teleswitch Betriebsart,,,,"AD00",,,UCH,,,Teleswitch operating mode solar
r;w,,KolTempMin1,Minimaltemperatur 1,,,,"A000",,,temp0,,,Temperature COL1 sensor has to reach before starting pumps at least
r;w,,KolTempMin2,Minimaltemperatur 2,,,,"A008",,,temp0,,,Temperature COL2 sensor has to reach before starting pumps at least
+r,,StorageTemps,SP1/SP2/SP3/TD1/TD2,,,"B504","0110",,,temp;temp;temp;temp;temp,,,
!include,iotest620.inc,,,,,,,,,,,,
!include,errors.inc,,,,,,,,,,,,
...was aber leider nicht zum gewünschten Ergebis führte. Im Log ist die Message nach wie vor als "unknown" drin, und ein "$ ebusctl read StorageTemps" führt zu:
2021-05-17 19:57:41.850 [update error] unable to parse read sc StorageTemps from ffecb504020110 / 09000300000207000100: ERR: invalid position
2021-05-17 19:57:41.850 [main error] read sc StorageTemps: decode ERR: invalid position
Hat jemand eine Idee, was ich falsch mache?
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
update check: revision v21.2 available
access: *
...usw
Wie mache ich am besten/sichersten ein Update?
Zitat von: chris371 am 17 Mai 2021, 22:20:04
Ich habe ein paar (für mich) interessante Temperaturwerte in einer noch nicht dekodierten Message entdeckt,
(...)
Hat jemand eine Idee, was ich falsch mache?
War wohl gestern schon zu spät für mich. Ich hatte ein Längenbyte mit einem Datenbyte verwechselt. ;)
Die zusätzliche Zeile im ec.solsy.sc.csv muss natürlich lauten:
r,,StorageTemps,SP1/SP2/SP3/TD1/TD2,,,"B504","10",,,temp;temp;temp;temp;temp,,,Dann funktioniert das auch wie es soll. :)
@john30 :
Pflegst Du sowas auf Zuruf ein, oder soll ich mir mal einen Github-Account zulegen und einen richtigen Merge-Request zusammenbasteln?
Falls letzteres, willst Du für die "sc"-Sachen auch eine Include-Datei anfangen, ähnlich wie hcmode.inc und hwcmode.inc ? Oder lohnt sich das für einen (oder zwei) zusätzlich dekodierte Messages nicht?
Zitat von: DerFranke am 18 Mai 2021, 15:32:06
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
update check: revision v21.2 available
access: *
...usw
Wie mache ich am besten/sichersten ein Update?
Sieht doch eigentlich nicht so aus als bräuchtest Du eins.
Bei Dir läuft eine v21.2, und online gibt es auch "nur" v21.2 (so verstehe ich zumindest die Ausgabe...)
Zitat von: chris371 am 18 Mai 2021, 18:13:33
Sieht doch eigentlich nicht so aus als bräuchtest Du eins.
Bei Dir läuft eine v21.2, und online gibt es auch "nur" v21.2 (so verstehe ich zumindest die Ausgabe...)
Bisher stand da immer update check: OK
Hallo zusammen
Ich bin verusche eine ebus Schnittstelle zu meinem TEM-Regeler SE 6024 SG in Betrieb zu setzen. Leider will das noch nicht ganz funktionieren. Ich bekomme bereits einige Daten des Regles. Leider kann ich diese nicht entschlüsseln. Ich habe es mit dem .csv File von Rellla verucht.
Ich habe das Logfile des ebus angehängt.
Ich wäre dankbar um jeden Tip.
Zitat von: hallozuerich am 22 Mai 2021, 22:18:27
Ich habe es mit dem .csv File von Rellla verucht.
Sieht nicht so aus als würde Dein ebusd irgendwelche CSVs laden.
Has Du dies hier (https://forum.fhem.de/index.php?topic=99968.0) schon gefunden? In der dort verlinkten Diskussion auf github stecken so viele Detailinformationen, um jemanden vermutlich für Wochen beschäftigt zu halten. ;)
Es scheint wohl so zu sein, dass TEM und Ochsner sehr verwandt sind. Ich würde an Deiner Stelle ebusd auf manuelle Konfiguration umstellen, und mir dann mal die Dateien aus https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner näher ansehen. Vermutlich müsste man die damals entschlüsselten Ochsner-Daten in das neue Konfigurationsdatei-Format überführen.
Hallo Chris
Vielen Dank für Deine Inputs. Nun habe ich bereits die nächsten fragen :)
Kann mir jemand sagen, wie ich überprüfen kann, ob das .csv File richtig eingelesen wird? Ich habe das Gefühl, dass das File nicht berücksichtig wird.
Kann mir jemand den Aufbau der folgenden Meldung erklären? Welcher Teil bestimmt welche Nachricht?
2021-05-22 19:43:45.433 [update notice] received unknown MM cmd: 101305010a00000a0c000001000100
2021-05-22 19:43:46.029 [update notice] received unknown BC cmd: 10fe0801084d2a008000080027
2021-05-22 19:43:46.196 [update notice] received unknown MS cmd: 01150621040080004a / 0a00800d02f4010cfe7d00
Zitat von: hallozuerich am 23 Mai 2021, 22:06:47
Kann mir jemand sagen, wie ich überprüfen kann, ob das .csv File richtig eingelesen wird? Ich habe das Gefühl, dass das File nicht berücksichtig wird.
Mit manueller Konfiguration (d.h. ohne --scanconfig) werden sämtliche Dateien im Konfigurationsverzeichnis gelesen. Da solltest Du darauf achten, dort nur die (wenigen) Dateien hinzulegen, die für Deine Anlage passen.
Mit --scanconfig ermittelt der ebusd selbst, welche Files er laden soll (siehe https://github.com/john30/ebusd/wiki/4.-Configuration ), und schreibt das dann auch in sein logfile - hier mal exemplarisch bei mir für die Bus-Adresse 0x08:
2021-04-05 12:14:42.561 [update notice] sent scan-read scan.08 QQ=ff: Vaillant;BAI00;0204;9602
2021-04-05 12:14:42.561 [bus notice] scan 08: ;Vaillant;BAI00;0204;9602
2021-04-05 12:14:42.565 [main notice] read common config file vaillant/general.csv
2021-04-05 12:14:42.565 [main notice] read common config file vaillant/broadcast.csv
2021-04-05 12:14:42.565 [main notice] read common config file vaillant/scan.csv
2021-04-05 12:14:42.566 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0204, HW9602
2021-04-05 12:14:44.058 [main notice] found messages: 202 (2 conditional on 25 conditions, 0 poll, 10 update)
Zitat von: hallozuerich am 23 Mai 2021, 22:06:47
Kann mir jemand den Aufbau der folgenden Meldung erklären? Welcher Teil bestimmt welche Nachricht?
2021-05-22 19:43:45.433 [update notice] received unknown MM cmd: 101305010a00000a0c000001000100
2021-05-22 19:43:46.029 [update notice] received unknown BC cmd: 10fe0801084d2a008000080027
2021-05-22 19:43:46.196 [update notice] received unknown MS cmd: 01150621040080004a / 0a00800d02f4010cfe7d00
Die drei Zeilen zeigen verschiedene Message-Typen. Master-to-Master, Broadcast, und Master-to-Slave (mit der Antwort vom Slave)
Schau mal in die ebus-Spezifikation (https://code.google.com/archive/p/ebus-alliance/downloads), was es alles gibt und wie die Nachrichten grundsätzlich aufgebaut sind.
Wie dann die Datenbytes interpretiert werden müssen ist bis auf wenige Ausnahmen herstellerspezifisch und üblicherweise von denen nicht offen gelegt. Da hilft dann nur kreatives Suchen in den Rohdaten bei bestimmten, wohlbekannten Ereignissen, oder mal schauen, was andere bereits herausgefunden haben -> anschauen und verstehen der vorhandenen Config-Files, durchkämmen der Foren/github-Diskussionen.
Zitat von: hallozuerich am 22 Mai 2021, 22:18:27
Hallo zusammen
Ich bin verusche eine ebus Schnittstelle zu meinem TEM-Regeler SE 6024 SG in Betrieb zu setzen. Leider will das noch nicht ganz funktionieren. Ich bekomme bereits einige Daten des Regles. Leider kann ich diese nicht entschlüsseln. Ich habe es mit dem .csv File von Rellla verucht.
Ich habe das Logfile des ebus angehängt.
Ich wäre dankbar um jeden Tip.
Die erste Nachricht aus deinem Log sollte https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/tem/15.csv#L188 sein.
Sieht also so aus, als wäre die config schon einigermaßen kompatibel und dir bliebe die große Arbeit erspart ;)
Ich habe ebusd schon lange nicht mehr aktualisiert und lese meine csv aktuell manuell ein. Also müsstest du es erstmal schaffen, ebusd mit dieser Konfiguration zu starten.
Gruß
Andreas
EDIT: Das Protokoll von TEM ist eigentlich relativ einfach zu entschlüsseln, wenn man es mal verstanden hat...
Hallo Andreas
Kannst du mir dein Konfigfile zeigen?
Gruss Dario
Was meinst du damit? Ich starte ebusd mit "-s" und "--configpath=/pfad/zu/csv", wobei configpath zu einem Verzeichnis zeigt, in dem
https://github.com/rellla/ebusd-configuration/tree/for_upstream/ebusd-2.1.x/de liegt.
Gruß
Andreas
Zitat von: chris371 am 18 Mai 2021, 17:50:59
@john30 :
Pflegst Du sowas auf Zuruf ein, oder soll ich mir mal einen Github-Account zulegen und einen richtigen Merge-Request zusammenbasteln?
Falls letzteres, willst Du für die "sc"-Sachen auch eine Include-Datei anfangen, ähnlich wie hcmode.inc und hwcmode.inc ? Oder lohnt sich das für einen (oder zwei) zusätzlich dekodierte Messages nicht?
am besten via pull request, dann kann man das auch noch diskutieren und Änderungen anfordern. wenn es nur 1 oder 2 Messages sind, die in mehreren files gebraucht werden, lohnt sich die Separierung in extra File wohl nicht
Zitat von: r-schmid@gmx.at am 16 Mai 2021, 10:44:36
Was könnte die Ursache für den bus error sein?
das klappt nur, wenn Du einen eBUS Adapter 3 hast und dieser im enhanced mode läuft
Moin,
erstmal riesen Dank an John und das Team für die tolle Arbeit am Adapter der vor einigen Wochen bei mir angekommen ist.
Diesbezüglich hätte ich jetzt jedoch einmal eine Frage: Die Daten der Wärmepumpe auslesen klappt damit Wunderbar, ist aber tatsächlich eher "nice to have" als ein "must have", da die Anlage ja an und für sich statisch läuft und ich da nicht ständig Befehle reinsenden muss.
Jetzt hab ich aber auch noch eine Vaillant Lüftungsanlage, die natürlich mit dem blöden Buskoppler gekoppelt ist, den ich ja über den ebus derzeit leider nicht erreiche.
Frage wäre jetzt: macht es überhaupt Sinn die Lüftungsanlage erreichen zu können? Interessant wäre hier für mich den Bypass-Status auslsen zu können und vielleicht die Lüftungsstufe steuern zu können. Hat das jemand im Einsatz und nutzt das so?
Wenn das möglich wäre würde ich vermutlich den ebus Adapter doch nochmal an anderer Stelle verbauen um an den ebus der Lüftungsanlage zu kommen.
Grüße
Hallo!
Endlich hab ich es geschafft, mich mit dem eBUS-Adapter zu beschäftigen. Im Großen und Ganzen funktioniert alles recht gut. Wahnsinn, was alles schon vorbereitet und dokumentiert wurde. Allerdings ist das gleichzeitig vielleicht auch ein Problem, nämlich in der Masse der Informationen die richtigen/relevanten zu finden, was wahrscheinlich auch einfach daran liegt, dass wir jetzt schon bei der 3. Generation des Adapters sind. Bei mir sind jedenfalls einige Fragen übrig geblieben, auf die mir vielleicht jemand hier eine Antwort geben kann oder zumindest einen Hinweis, wo ich die Infos finde:
- Ist irgendwo beschrieben, wie die Blinkcodes der blaue Wemos-LED definiert sind? Ich finds nicht...
- 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?
- 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?
- 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?
- 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?
Danke für Eure Hilfe!
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 (https://adapter.ebusd.eu/picfirmware#led).
- 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/ (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]
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?
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
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.
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 (https://github.com/john30/ebusd/wiki/4.1.-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.
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?
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
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
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 (https://forum.fhem.de/index.php/topic,118143.msg1148321.html#msg1148321) 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.
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?
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?
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
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
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
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
Zitat von: ioAndreas am 04 Oktober 2021, 00:14:15
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
Hi Andreas,
ich habe auch mit der Kombination Vaillant / Raspi so meine Probleme. Wenn der eBus nach einem Raspi-Neustart nicht erkannt wird, dann hilft ein komplettes Ausschalten der WP an der Sicherung immer. Das Drücken des Reset-Taster funktioniert nur selten.
Danke für den Hinweis. Dies hatte ich schon gelesen und mehrfach ausprobiert. Gerade noch einmal getestet: ein "Neustart" per Sicherung bringt keinerlei Veränderung.
Ich gehe im Moment davon aus, dass ich noch irgend etwas falsch gemacht habe. Nur was?
Zitat von: ioAndreas am 04 Oktober 2021, 00:14:15
EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log --scanconfig=full --httpport=8889 --htmlpath=/var/ebusd/html"
Du musst enh:/dev/ttyUSB0 verwenden (siehe Doku (https://adapter.ebusd.de/#usb)) oder den Jumper für enhanced mode rausnehmen (siehe auch Doku (https://adapter.ebusd.de/picfirmware.html#versions))
Zitat von: john30 am 04 Oktober 2021, 10:03:43
Du musst enh:/dev/ttyUSB0 verwenden (siehe Doku (https://adapter.ebusd.de/#usb)) oder den Jumper für enhanced mode rausnehmen (siehe auch Doku (https://adapter.ebusd.de/picfirmware.html#versions))
Das war es! (ist schon hilfreich, wenn man einfach mal das tut, was in der Doku steht... ;-) ) Jetzt wird etwas erkannt:
pi@raspberrypi:~ $ ebusctl i
version: ebusd 21.2.v21.2
signal: acquired
symbol rate: 74
max symbol rate: 109
min arbitration micros: 348
max arbitration micros: 1567
min symbol latency: 11
max symbol latency: 13
reconnects: 0
masters: 3
messages: 344
conditional: 139
poll: 1
update: 59
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0344;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0226;HW=6901"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0344;HW=7201"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0344;HW=7201"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave
Spitze, vielen Dank @John30 ! Jetzt bin ich ein großes Stück weiter und kann weiter tüfteln, wie ich nun an die Daten komme... Aber dazu gibt es ja hier viel zu lesen.
Hallo john30
Ich frage jetzt doch hier: Könntest Du bitte das ebus Docker-Release mit dem Tag "latest" auch als Multi-Arch pushen?
Warum frage ich das?
Aktuell steht latest nur für amd64 zur Verfügung und ich gehe für meinen Raspi deshalb auf V21.2. Weil ich meine Docker-Container automatisch durch Watchtower aktualisieren lasse, bekomme ich keine Updates mit, wo ich konkrete Release-Versionen einsetze. Neue Releases wirst Du ja wahrscheinlich nicht erneut unter V21.2 pushen.
Nehme ich latest klappt das (sofern latest aktualisiert wird ;) ). Momentan kann ich latest jedoch nicht nehmen, weil amd64 nicht auf dem Raspi läuft.
Ja, Multi-Arch builden kann nervig sein. Ich fände es klasse, wenn Du es trotzdem auf Dich nehmen würdest :D
Vielen Dank und beste Grüße
rob
Zitat von: rob am 04 Oktober 2021, 11:05:29
Ich frage jetzt doch hier: Könntest Du bitte das ebus Docker-Release mit dem Tag "latest" auch als Multi-Arch pushen?
das ist nicht ganz so einfach, weil docker hub jetzt kostenpflichtig ist und somit die ganze build chain nicht mehr funktioniert.
ich schaue bereits nach anderen Möglichkeiten, aber dauert noch
Ja, sehr schade. Vielen Dank für Deine Rückmeldung.
Magst Du denn das zugrunde liegende Dockerfile ggf. veröffentlichen (z.B. Github)? Dann könnte man sich im Zweifel den Container mit neuestem Inhalt selber nach Bedarf builden und Du hättest den "Suchdruck" etwas los :)
Ich pflege auch einen Container als multiarch und muss diesen immer manuell builden + pushen. Weil es dort nicht so viele Updates im Basisimage gibt, ist es für mich noch händelbar. Wie man das kostenfrei automatisiert, würde mich auch interessieren - aber das ist ein anderes Thema und hier mehr OT ;)
Viele Grüße
rob
Zitat von: rob am 12 Oktober 2021, 07:38:05
Magst Du denn das zugrunde liegende Dockerfile ggf. veröffentlichen (z.B. Github)? Dann könnte man sich im Zweifel den Container mit neuestem Inhalt selber nach Bedarf builden und Du hättest den "Suchdruck" etwas los :)
siehe hier (https://github.com/john30/ebusd/tree/master/contrib/docker)
Hallo john30.
Eine andere Frage möchte ich auch gerne adressieren :)
Ich habe den Adapter an meiner Weishaupt-Anlage via MQTT in Betrieb genommen (und für den MQTT-Teil von Beta-User bereits sehr viel Unterstützung erhalten https://forum.fhem.de/index.php/topic,122048.msg1167502/topicseen.html#msg1167502).
Wenn ich in Fhem am Hauptdevice ein
set MQTT2_ebusd_21.2_1 getAllloslasse, erhalte ich alles an Readings die in den CSV so definiert sind.
ABER: überwiegend ohne Werte. Die Werte sind genau dort leer, wo von alleine die Weishaupt nix sagen will. Erst wenn ich diese Werte einzeln hole (via MQTT get oder CLI), kommen sie auch mit getAll. Ansonsten ist der Payload einfach leer.
Ist das so gedacht/ korrekt oder habe ich etwas vergessen/ falsch verstanden?
Ich hoffe, ich habe das nicht allzu verwirrend dargestellt :D
Vielen Dank und beste Grüße
rob
Hintergrund:
Zitat von: Beta-User am 22 Juli 2021, 10:59:45
...
Eventuell ist da auch bei "getAll" irgendwas gespeichertes aberufen worden, und der letzte Wert scheint jeweils "leer" gewesen zu sein(?). Grundsätzlich bin ich der Meinung, man sollte das an john30 adressieren, das kommt mir unbeabsichtigt vor, dass da "leere" Payload und JSON im Wechsel kommen.
...
Zitat von: rob am 14 Oktober 2021, 09:48:00
ABER: überwiegend ohne Werte. Die Werte sind genau dort leer, wo von alleine die Weishaupt nix sagen will. Erst wenn ich diese Werte einzeln hole (via MQTT get oder CLI), kommen sie auch mit getAll. Ansonsten ist der Payload einfach leer.
Ist das so gedacht/ korrekt oder habe ich etwas vergessen/ falsch verstanden?
das ist so gedacht, denn wenn man bei jeder Frage nach allen Werten eben alle Werte vom Bus auslesen würde, wäre das schon bisschen heftig (nicht nur, dass es viel zu lange dauern würde).
Deshalb muss man Werte, an denen man Interesse hat, entweder via Poll Priorität (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#read) automatisch in Intervallen abrufen lassen, oder explizit via ebusctl oder via "/get" Suffix an einzelne MQTT Topics (https://github.com/john30/ebusd/wiki/3.3.-MQTT-client)
Für alle, die eben einen Adapter bekommen haben oder bald bekommen werden, habe ich hier ein paar erste Schritte notiert (https://adapter.ebusd.eu/steps.html), an denen man sich orientieren kann.
Verbesserungsvorschläge dazu gern via PR auf dem github (https://github.com/eBUS/adapter/pulls)
Hallo zusammen,
ich habe Adapter bekommen, soweit angerichtet, dass der im Netzwerk zu sehen ist.
An Gastherme Vaillant angeklemmt, aber wie soll ich jetzt die Daten per MQTT senden
zum eBus Adapter im IOBroker?
IOBroker läuft auf einem Raspi3 und ich kann Daten von verschiedenen Objekte
sammeln, z.b. Fronius, Sonoff, Tasmota, Wled.
Hier komme ich aber nicht weiter!!!
Die gelbe LED blinkt, also kommuniziert der Adapter mit dem Vaillant.
Was kann/soll ich als Nächstes tun?
Bin für jeden Tipp der mich weiter bringt dankbar.
Hallo
Dafür mußt du eBusD auf dem Raspberry installieren und zwar mit MQTT
Anleitung siehe oben
Hallo,
ich bin kein Stückchen weiter gekommen,
kurzzeitig war mein Wemos wohl mit dem ebusd verbunden.
config sieht so aus:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
#
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=100 -d enh:192.168.178.xxx:9999 --address=ff"
#EBUSD_OPTS="--device=192.168.178.96 --httpport=8889 --scanconfig --latency=30000 --configpath=http://ebusd.eu/config/" --mqttjson"
Wemos soll erstmal mit ebusd auf Raspi kommunizieren,
danach könnte ich per MQTT oder HTTP Daten von Raspi abrufen.
ich bräuchte eine Step by Step Anleitung für Wemos. Bin ein absoluter Anfänger.
Falls jemand eine ausführliche Anleitung mit einzelnen commandos/ Reihenfolge posten kann wird es bestimmt nicht nur mir helfen.
Danke.
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=100 -d enh:192.168.178.xxx:9999 --address=ff"
und du hast diese "xxx" schon durch deine IP ersetzt ?
Kannst du denn auf das Webinterface des Wemos zugreifen und ihn konfigurieren, wenn ja poste doch das Bild wie das aussieht.#
und schau dir das hier (https://github.com/john30/ebusd-esp/)genau an.
LG
Hallo,
richtige Firmware auf Wemos ist drauf, ip Adresse enthält keine (xxx) sondern ist komplett eingetragen
wie die im Router zu sehen ist. Ebusdis auf raspi installiert, Bild habe ich im Beitrag #297 gepostet.
MFG
Zitat von: Rem21 am 23 Oktober 2021, 10:25:57
Hallo,
richtige Firmware auf Wemos ist drauf, ip Adresse enthält keine (xxx) sondern ist komplett eingetragen
wie die im Router zu sehen ist. Ebusdis auf raspi installiert, Bild habe ich im Beitrag #296 gepostet.
MFG
Servus zusammen!
Zitat von: john30 am 17 März 2021, 21:28:08
zum Wifi Thema:
es scheint in der Kommunikation zwischen ebusd und dem Wemos (und evtl. dann zum PIC) ein Timingproblem zu geben. Das muss ich erst noch genau analysieren und komme frühestens am Wochenende dazu.
Bis dahin schafft ein extra "--latency=80" in den EBUSD_OPTS anscheinend Abhilfe.
Danke @Reinhart, dass ich Deine Anlage zur ersten Analyse nutzen durfte!
Konntet ihr denn hier zwischenzeitlich schon etwas näheres zu den Latenzproblemen mit dem Wemos herausfinden?
Meine Kombination aus frisch in Betrieb genommenen V3 Adapter mit Wemos und ebusd als Docker Container auf einem RPI 4 zickt leider die ganze Zeit herum und ist relativ unzuverlässig im pollen und senden der Daten.
Zuvor war Gezwungenermaßen ein RPI 3 mit V2 Adapter im Einsatz - da lief alles wie geschmiert.
Den V3 Adapter via LAN zu verbinden oder einen Raspberry mit V3 Adapter via GPIO zu betreiben ist leider keine Option (zu sperrig und in meinen Augen Ressourcenverschwendung :-)).
Ebusd Container läuft mit latency=100 (habe ich ein paar Seiten weiter in einem Beitrag von Reinhart als maximal empfohlenen Wert übernommen).
Auf den Wemos wurde wie beschrieben die FW https://github.com/john30/ebusd-esp/blob/master/dist/ebus-v3_d1mini.bin via NODEMCU geflasht. Lt. Wemos Web-UI habe ich ein WLAN-Signal von 72%.
Beste Grüße
EDIT:
ebusd Fehlermeldungen:
2021-10-23 12:52:38.112 [bus error] poll bai WaterPressure failed: ERR: read timeout
2021-10-23 12:52:44.145 [bus error] device status: eBUS comm error: framing
2021-10-23 12:52:44.145 [bus error] poll bai Flame failed: ERR: read timeout
2021-10-23 12:54:02.147 [bus error] poll bai HwcDemand failed: ERR: wrong symbol received
2021-10-23 12:54:26.142 [bus error] poll bai Flame failed: ERR: wrong symbol received
2021-10-23 12:56:02.179 [bus error] poll bai WaterPressure failed: ERR: SYN received
2021-10-23 12:56:20.114 [bus error] poll 392 CirPump failed: ERR: wrong symbol received
2021-10-23 12:57:02.129 [bus error] device status: eBUS comm error: framing
...
2021-10-24 09:41:10.110 [bus error] signal lost
2021-10-24 09:41:10.411 [bus error] device status: unexpected available enhanced byte 2
2021-10-24 09:41:13.881 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:41:13.883 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:41:13.885 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:41:21.738 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:41:23.647 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:41:26.021 [bus error] signal lost
2021-10-24 09:41:26.742 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:41:40.038 [bus error] signal lost
2021-10-24 09:41:51.010 [bus error] signal lost
2021-10-24 09:41:52.345 [bus error] arbitration start error
2021-10-24 09:42:09.203 [bus error] poll bai WaterPressure failed: ERR: SYN received
2021-10-24 09:42:12.183 [bus error] signal lost
2021-10-24 09:42:12.524 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 09:42:24.681 [bus error] device status: unexpected available enhanced following byte 1
...
2021-10-24 19:30:50.024 [bus error] signal lost
2021-10-24 19:30:50.445 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 19:39:06.168 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 19:52:32.060 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 20:02:01.999 [bus error] device status: unexpected available enhanced following byte 1
2021-10-24 21:34:44.249 [bus error] device status: unexpected available enhanced byte 2
2021-10-24 22:22:51.255 [bus error] device status: eBUS comm error: framing
2021-10-24 22:22:51.256 [bus error] send to 08: ERR: read timeout, retry
2021-10-24 22:22:54.149 [bus error] device status: eBUS comm error: framing
2021-10-24 22:22:54.149 [bus error] send to 08: ERR: read timeout, retry
2021-10-24 22:22:57.174 [bus error] poll bai AATemp failed: ERR: wrong symbol received
2021-10-24 22:23:03.160 [bus error] poll 392 ActualRoomTempDesiredHc1 failed: ERR: SYN received
2021-10-24 22:23:09.312 [bus error] poll 392 DisplayedRoomTemp failed: ERR: SYN received
2021-10-24 22:23:45.233 [bus error] poll bai WarmstartDemand failed: ERR: SYN received
2021-10-24 22:23:51.120 [bus error] poll bai WP failed: ERR: SYN received
2021-10-24 22:24:03.149 [bus error] device status: eBUS comm error: framing
2021-10-24 22:24:03.149 [bus error] poll bai Flame failed: ERR: read timeout
2021-10-24 22:24:15.105 [bus error] poll 392 CirPump failed: ERR: wrong symbol received
2021-10-24 22:25:15.204 [bus error] poll bai PositionValveSet failed: ERR: SYN received
2021-10-24 22:25:51.139 [bus error] poll bai Ignitor failed: ERR: SYN received
2021-10-24 22:26:15.205 [bus error] poll bai AITemp failed: ERR: SYN received
2021-10-24 22:26:27.164 [bus error] poll 392 ActualRoomTempDesiredHc1 failed: ERR: SYN received
2021-10-24 22:27:09.198 [bus error] poll bai WarmstartDemand failed: ERR: SYN received
2021-10-24 22:27:27.106 [bus error] device status: eBUS comm error: framing
2021-10-24 22:27:27.106 [bus error] poll bai Flame failed: ERR: read timeout
2021-10-24 22:27:51.276 [bus error] poll 392 Hc1ManualOPRoomTempDesired failed: ERR: SYN received
2021-10-24 22:28:03.162 [bus error] poll bai AATemp failed: ERR: SYN received
2021-10-24 22:28:27.295 [bus error] poll bai FlowTemp failed: ERR: SYN received
2021-10-24 22:28:39.347 [bus error] poll bai PositionValveSet failed: ERR: SYN received
2021-10-24 22:28:51.224 [bus error] poll bai WarmstartDemand failed: ERR: SYN received
2021-10-24 22:29:45.139 [bus error] poll bai AATemp failed: ERR: SYN received
2021-10-24 22:29:51.130 [bus error] poll 392 ActualRoomTempDesiredHc1 failed: ERR: SYN received
2021-10-24 22:30:09.125 [bus error] poll bai FlowTemp failed: ERR: SYN received
2021-10-24 22:30:21.195 [bus error] device status: eBUS comm error: framing
2021-10-24 22:30:21.195 [bus error] poll bai PositionValveSet failed: ERR: read timeout
2021-10-24 22:31:27.115 [bus error] poll bai AATemp failed: ERR: SYN received
2021-10-24 22:31:51.174 [bus error] poll bai FlowTemp failed: ERR: SYN received
2021-10-24 22:32:15.149 [bus error] poll bai WarmstartDemand failed: ERR: SYN received
2021-10-24 22:32:21.207 [bus error] device status: eBUS comm error: framing
2021-10-24 22:32:21.208 [bus error] poll bai WP failed: ERR: read timeout
2021-10-24 22:32:51.097 [bus error] poll 392 Hc1OPMode failed: ERR: wrong symbol received
2021-10-24 22:33:09.133 [bus error] poll bai AATemp failed: ERR: SYN received
2021-10-24 22:35:45.117 [bus error] poll bai WP failed: ERR: SYN received
2021-10-24 22:36:03.139 [bus error] device status: eBUS comm error: framing
2021-10-24 22:36:03.139 [bus error] poll bai Ignitor failed: ERR: read timeout
2021-10-24 22:36:27.148 [bus error] poll bai AITemp failed: ERR: SYN received
2021-10-24 22:39:57.073 [bus error] device status: eBUS comm error: framing
2021-10-24 22:39:57.073 [bus error] arbitration start error
2021-10-24 22:40:27.101 [bus error] poll bai HwcWaterflow failed: ERR: SYN received
2021-10-24 22:46:03.100 [bus error] device status: eBUS comm error: framing
2021-10-24 22:46:03.100 [bus error] arbitration start error
2021-10-24 22:47:39.109 [bus error] poll bai WP failed: ERR: wrong symbol received
2021-10-24 22:50:21.118 [bus error] poll 392 DisplayedRoomTemp failed: ERR: wrong symbol received
Zitat von: hexenjaeger am 25 Oktober 2021, 00:47:01
Konntet ihr denn hier zwischenzeitlich schon etwas näheres zu den Latenzproblemen mit dem Wemos herausfinden?
Meine Kombination aus frisch in Betrieb genommenen V3 Adapter mit Wemos und ebusd als Docker Container auf einem RPI 4 zickt leider die ganze Zeit herum und ist relativ unzuverlässig im pollen und senden der Daten.
welche ebusd Version setzt du denn ein?
und wie versorgst Du den Adapter mit Strom?
Zitat von: john30 am 25 Oktober 2021, 19:35:06
welche ebusd Version setzt du denn ein?
und wie versorgst Du den Adapter mit Strom?
nutze die latest Version vom Docker image - ebusctl info im Container meint, dass 21.2 im Einsatz ist (sollte also eigentlich die letzte Master von Github sein).
pi@raspberrypi:~ $ docker exec -it 0df bash
root@0dfb26836318:/# ebusctl info
version: ebusd 21.2.v21.2-48-g24a6525
update check: revision v21.2 available
signal: acquired
symbol rate: 56
max symbol rate: 137
min arbitration micros: 7
max arbitration micros: 713
min symbol latency: 1
max symbol latency: 182
reconnects: 0
masters: 3
messages: 382
conditional: 10
poll: 17
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0516;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='0010006140']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=39200;SW=0215;HW=2002", loaded "vaillant/15.392.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Stromversorgung via USB-Anschluss auf der Steckdose (5V, max. 2A pro USB - 2 Anschlüsse vorhanden, nur derjenige belegt, auf welchem der Wemos verbunden ist).
Zitat von: hexenjaeger am 25 Oktober 2021, 22:32:01
Stromversorgung via USB-Anschluss auf der Steckdose (5V, max. 2A pro USB - 2 Anschlüsse vorhanden, nur derjenige belegt, auf welchem der Wemos verbunden ist).
anscheinend gibt es ein Speicherproblem in ebusd-esp (https://github.com/john30/ebusd-esp/issues/50), das muss ich erst fixen
Zitat von: john30 am 27 Oktober 2021, 07:35:53
anscheinend gibt es ein Speicherproblem in ebusd-esp (https://github.com/john30/ebusd-esp/issues/50), das muss ich erst fixen
Sehe ich das richtig, daß es eBusD auf dem Raspberry betrifft ? Das würde mein Problem erklären : Sporadischer Ausfall des gesamten Systems ( MQTT, eBusD, Openhab, MySql ect ) durch Speichermangel und Vollmüllen der Logfiles ?
Glückauf
guinnes
Zitat von: guinnes am 27 Oktober 2021, 21:45:28
Sehe ich das richtig, daß es eBusD auf dem Raspberry betrifft ? Das würde mein Problem erklären : Sporadischer Ausfall des gesamten Systems ( MQTT, eBusD, Openhab, MySql ect ) durch Speichermangel und Vollmüllen der Logfiles ?
nein, betrifft nur den Wemos
Zitat von: john30 am 27 Oktober 2021, 07:35:53
anscheinend gibt es ein Speicherproblem in ebusd-esp (https://github.com/john30/ebusd-esp/issues/50), das muss ich erst fixen
vielen Dank für deine/eure Mühen - finde das Spitze!
Habe mal die Notifications für das Issue auf Github aktiviert und verfolge mal mit was sich so tut.
Falls ich irgendwo als Test-User behilflich sein kann, bitte einfach Bescheid geben. Einzig mit C/C++/C#-Kenntnissen kann ich leider nicht aufwarten :-)
Edit: habe gerade die Bug description näher durchgelesen - der Fehler taucht bei mir nicht in der Art auf. free heap bleibt konstant bei ~33k, selbst nach einigen Stunden uptime.
Zitat von: guinnes am 27 Oktober 2021, 21:45:28
mein Problem (...) Vollmüllen der Logfiles ?
Das Anwachsen des Logfiles könnte vielleicht wirklich ein Problem werden. Nach ca. einem halben Jahr Betrieb war das ebusd.log bei mir etwa 2 GByte groß.
Es ist durchaus superpraktisch, wenn man gelegentlich mal ins Log von vor ein paar Wochen schauen kann. Aber vielleicht sollte man sich doch mal darum kümmern, dass es nicht unkontrolliert wächst.
Wie macht ihr anderen das? Hab ihr einen zusätzlichen Dienst eingerichtet? Die Log-Optionen des ebusd selbst (https://github.com/john30/ebusd/wiki/2.-Run#log-options) scheinen noch keine Größenbegrenzung oder Logrotation zu unterstützen.
Wiki eBusd_Logrotate (https://wiki.fhem.de/wiki/EBUS#eBusd_Logrotate)
Hallo zusammen!
Nach einer kleinen Ewigkeit ist nun heute mein USB Adapter angekommen.
Voll motiviert wollte ich mich gleich an das Werk machen, leider mit mangelnden Erfolg.
Bräuchte daher bitte Eure Hilfe!
Jumper sind auf J1 und J4 gesetzt, sowie Enhanced (J12) - Ebenso auf Standard zu setzen brachte keinen Erfolg.
Leider erkennt mein RPI 4 anscheinend den via USB angeschlossenen Adapter nicht. (siehe Bild)
Raspbian OS (Debian Buster) - auch auf einem zweiten Raspberry PI 4 keine Erkennung des USB eBus Adapters!
Habe mich strickt nach der Anleitung gehalten. Vielen Dank schon im Voraus.
LG
Zitat von: TomLee am 29 Oktober 2021, 11:54:38
Wiki eBusd_Logrotate (https://wiki.fhem.de/wiki/EBUS#eBusd_Logrotate)
Okay, vielen Dank! (auch fürs Reparieren des Links. ;) )
Zitat von: FloRet am 29 Oktober 2021, 16:18:54
Leider erkennt mein RPI 4 anscheinend den via USB angeschlossenen Adapter nicht. (siehe Bild)
Raspbian OS (Debian Buster) - auch auf einem zweiten Raspberry PI 4 keine Erkennung des USB eBus Adapters!
Vielleicht liegt es am Kabel? Nicht selten liegen Geräten USB-Kabel bei, die nur als Ladekabel gedacht sind und bei denen die Datenleitungen gar nicht verbunden sind. Probier' doch mal eins, von dem Du sicher weißt, dass es geht.
Zitat von: chris371 am 29 Oktober 2021, 18:01:15
Okay, vielen Dank! (auch fürs Reparieren des Links. ;) )
genau, logrotate config kommt sogar bei der ebusd Installation mit. Im docker natürlich nicht
Zitat von: FloRet am 29 Oktober 2021, 16:18:54
Jumper sind auf J1 und J4 gesetzt, sowie Enhanced (J12) - Ebenso auf Standard zu setzen brachte keinen Erfolg.
Leider erkennt mein RPI 4 anscheinend den via USB angeschlossenen Adapter nicht. (siehe Bild)
ist das denn jetzt die Raspi Aufsteck-Variante oder eine USB?
Zitat von: john30 am 29 Oktober 2021, 18:14:52
genau, logrotate config kommt sogar bei der ebusd Installation mit. Im docker natürlich nicht
Ah, okay. :) Ich habs aus den Sourcen gemäß Deiner Anleitung (https://github.com/john30/ebusd/wiki/1.-Build-and-install) kompiliert und installiert, auf einem Ubuntu 20.04.2 Server (welches in einer VM läuft). Auf dem Ubuntu scheint auch logrotate zum Einsatz zu kommen, aber "make install" hat die config nicht kopiert. Vielleicht wäre noch ein kleiner Hinweis (wie der mit dem systemctl) am Ende des Wiki-Kapitels sinnvoll?
Dankeschön!
Zitat von: john30 am 29 Oktober 2021, 18:15:46
ist das denn jetzt die Raspi Aufsteck-Variante oder eine USB?
Die USB Variante!
Tatsächlich habe ich nur "Ladekabel" im Haus. Sollte ich ein Datenkabel besorgen, wenn ja - Empfehlungen?
Zitat von: FloRet am 29 Oktober 2021, 19:06:20
Die USB Variante!
Tatsächlich habe ich nur "Ladekabel" im Haus. Sollte ich ein Datenkabel besorgen, wenn ja - Empfehlungen?
ja gut, mit nem Ladekabel kanns schlecht gehen, weil dann ja keine Daten durchkommen. Ganz normales USB Kabel halt
@all - Ein Samsung Kabel hat es nun gerichtet und die Verbindung klappt.
Alles soweit perfekt, danke fürs helfen!!
Jetzt bin ich mal gespannt, was meine Vaillant VWF 197/4 alles preis gibt ;-)
Auf https://adapter.ebusd.eu/ (https://adapter.ebusd.eu/) sowie auch hier im Thread wird ja explizit darauf hingewiesen, dass bei der Wemos Variante die Stromversorgung "kritisch" ist.
Gibt es da Empfehlungen? Was nutzt ihr dafür?
Mein eBus Adapter wird im Heizungsraum montiert. Ich würde ihn am liebsten zusammen mit dem Netzteil in einer Feuchtraumdose verschwinden lassen. Jetzt habe ich mal nach für USB geeigneten Netzteilen mit Schraubklemmen gesucht (präferiert Schaltnetzteile). Das Angebot ist aber nicht so überzeugend, da kommt auch wieder viel von dem üblichen AliExpress Zeug.
Reichelt bietet so etwas https://www.reichelt.de/schaltnetzteil-geschlossen-15-w-5-v-3-a-snt-rs-15-5-p137080.html?PROVID=2788 (https://www.reichelt.de/schaltnetzteil-geschlossen-15-w-5-v-3-a-snt-rs-15-5-p137080.html?PROVID=2788) an, da habe ich aber Bedenken wg. der Abwärme wenn ich das in eine Dose verpacke.
Zitat von: weini am 30 Oktober 2021, 14:08:37
Mein eBus Adapter wird im Heizungsraum montiert. Ich würde ihn am liebsten zusammen mit dem Netzteil in einer Feuchtraumdose verschwinden lassen. Jetzt habe ich mal nach für USB geeigneten Netzteilen mit Schraubklemmen gesucht (präferiert Schaltnetzteile). Das Angebot ist aber nicht so überzeugend, da kommt auch wieder viel von dem üblichen AliExpress Zeug.
Für die Warema-Zentrale, die man auch alternativ mit USB versorgen kann, gibt es ein UP-Netzteil Nr. 1002898 5V1A
Das wär doch was.
Danke dir! Neben dem konkreten Netzteil hast du mich noch darauf gebracht, nach 5V Netzteilen für UP Dosen zu suchen. Da wird die Auswahl etwas besser.
Wieviel Strom benötigt der eBus Adapter v3 inkl. dem Wemos denn? Viel kann das doch eigentlich nicht sein.
Falls 600mA ausreichend währen, dann würde mir das RECOM RAC RAC03-05SER/277 https://www.reichelt.de/ac-dc-wandler-85-305-v-ac-5-v-dc-modul-rac03-05ser277-p177293.html?&trstct=pol_8&nbc=1 (https://www.reichelt.de/ac-dc-wandler-85-305-v-ac-5-v-dc-modul-rac03-05ser277-p177293.html?&trstct=pol_8&nbc=1) gut gefallen.
Zitat von: weini am 30 Oktober 2021, 17:23:23
Danke dir! Neben dem konkreten Netzteil hast du mich noch darauf gebracht, nach 5V Netzteilen für UP Dosen zu suchen. Da wird die Auswahl etwas besser.
Wieviel Strom benötigt der eBus Adapter v3 inkl. dem Wemos denn? Viel kann das doch eigentlich nicht sein.
Falls 600mA ausreichend währen, dann würde mir das RECOM RAC RAC03-05SER/277 https://www.reichelt.de/ac-dc-wandler-85-305-v-ac-5-v-dc-modul-rac03-05ser277-p177293.html?&trstct=pol_8&nbc=1 (https://www.reichelt.de/ac-dc-wandler-85-305-v-ac-5-v-dc-modul-rac03-05ser277-p177293.html?&trstct=pol_8&nbc=1) gut gefallen.
ich nutze fast nur alte Handyladegeräte. Die haben genug Saft (meist über 1A) und liegen eh nur rum :-)
Das mache ich für meine "normalen" ESP Basteleien genauso. Aber da hatte ich auch schon mal einen Ausfall, weil das alte Handynetzteil nicht mehr sauber gearbeitet hat. Deshalb wollte ich dem eBus Adapter etwas besseres gönnen.
Zum Thema langlebige Stromversorgung für den Heizungskeller hatte ich mir auch schon mal Gedanken gemacht (https://www.mikrocontroller.net/topic/494910?goto=6244873#6244873). Ich habe mich dann zwar umentschieden und keinen Kleinrechner mehr benutzt, aber wenn ich das heute nochmal so machen wollen würde, würde ich wohl das bewährte Konzept mit Netztrafo, Brückengleichrichter und Glättungselko nehmen, und dann einen sehr großzügig ausgelegten "Simple Switcher" von National Semiconductor zur Stabilisierung der 5V dahinterhängen. Das alles im Selbstbau zusammen mit dem eBus-Adapter in einem größeren Feuchtraumgehäuse.
Hallo zusammen,
erstmal Danke für die großartige Arbeit. Mein Ebus-Adapter ist angekommen und ich habe ich per Lan in Betrieb genommen.
Nun sind auch Probleme und Fragen aufgetreten:
Meine Konfiguration: Vaillant Wärmepumpe Arotherm vwl 75/5, Gas-Brennwert ecoTEC plus VC 206 mit VR32, VR71, Trinkwasserstation Vaillant aguaFLOW exclusive VPM 20/25/2, VRC720
Es werden nicht alle Geräte erkannt, bzw so wie ich es verstanden habe fehlen csv-files.
EBUSD_OPTS="-d enh:192.168.0.12:9999 -l /var/log/ebusd.log --log='all error' --log='bus info' --scanconfig --httpport=88 --htmlpath=/var/ebusd/html --accesslevel=* --configlang=DE --mqttport=1883 --mqttjson --mqtthost=192.168.0.6 --mqtttopic=ebusd/%circuit/%name --latency=20000"
>
0522;5103
2021-11-05 13:15:07.767 [bus notice] scan 76: ;Vaillant;VWZ00;0522;5103
2021-11-05 13:15:07.767 [bus info] scan 76 cmd: 3176b5090124
2021-11-05 13:15:07.926 [bus info] scan 76 cmd: 3176b5090125
2021-11-05 13:15:08.154 [bus info] scan 76 cmd: 3176b5090126
2021-11-05 13:15:08.478 [bus info] scan 76 cmd: 3176b5090127
2021-11-05 13:15:08.636 [bus notice] scan 76: ;21;21;20;0010023495;1610;005478;N3
2021-11-05 13:15:08.713 [main error] unable to load scan config 76: no file from vaillant with prefix 76 found
2021-11-05 13:15:08.713 [main error] scan config 76: ERR: element not found
2021-11-05 13:15:09.028 [bus notice] max. symbols per second: 149
2021-11-05 13:15:28.316 [bus notice] new master 13, master count 5
2021-11-05 13:15:37.448 [bus info] scan 18 cmd: 3118070400
2021-11-05 13:15:37.616 [bus notice] scan 18: ;Vaillant;V32;0117;9802
2021-11-05 13:15:37.616 [bus notice] scan 18: ;Vaillant;V32;0117;9802
2021-11-05 13:15:37.617 [bus info] scan 18 cmd: 3118b5090124
2021-11-05 13:15:37.910 [main error] unable to load scan config 18: no file from vaillant with prefix 18 found
2021-11-05 13:15:37.910 [main error] scan config 18: ERR: read timeout
2021-11-05 13:16:09.915 [bus info] scan 0a cmd: 310a070400
2021-11-05 13:16:10.110 [bus notice] scan 0a: ;Vaillant;PMW01;0206;8302
2021-11-05 13:16:10.110 [bus notice] scan 0a: ;Vaillant;PMW01;0206;8302
2021-11-05 13:16:10.110 [bus info] scan 0a cmd: 310ab5090124
2021-11-05 13:16:10.341 [bus info] scan 0a cmd: 310ab5090125
2021-11-05 13:16:10.396 [bus info] arbitration delay 7 - 21 micros
2021-11-05 13:16:10.535 [bus info] scan 0a cmd: 310ab5090126
2021-11-05 13:16:10.820 [bus info] arbitration delay 7 - 56 micros
2021-11-05 13:16:10.951 [bus info] scan 0a cmd: 310ab5090127
2021-11-05 13:16:11.137 [bus notice] scan 0a: ;21;21;21;0010014311;3110;017352;N4
2021-11-05 13:23:39.381 [bus notice] device status: resetting
2021-11-05 13:23:39.397 [bus notice] bus started with own address 31/36
2021-11-05 13:23:39.397 [bus notice] signal acquired
2021-11-05 13:23:39.641 [bus notice] new master 10, master count 2
2021-11-05 13:23:39.641 [bus notice] device status: reset
2021-11-05 13:23:39.641 [bus error] device status: unexpected enhanced byte 2
2021-11-05 13:23:39.975 [bus notice] new master 03, master count 3
2021-11-05 13:23:40.339 [bus notice] new master 13, master count 4
2021-11-05 13:23:41.970 [bus notice] new master 71, master count 5
2021-11-05 13:23:49.398 [bus info] scan 08 cmd: 3108070400
root@fhem:/etc/default# ebusctl info
version: ebusd 21.2.v21.2-54-g142a552
update check: revision v21.2 available
access: *
signal: acquired
symbol rate: 65
max symbol rate: 159
min arbitration micros: 7
max arbitration micros: 12
min symbol latency: 6
max symbol latency: 13
reconnects: 0
masters: 5
messages: 497
conditional: 0
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0522;HW=5103", loaded "vaillant/08.hmu.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=Vaillant;ID=72000;SW=0122;HW=7703", loaded "vaillant/15.720.csv"
address 18: slave #12, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0522;HW=5103"
Was kann man da tun?
Schöne Grüße
Arek
Zitat von: Arek am 05 November 2021, 13:43:14
Es werden nicht alle Geräte erkannt, bzw so wie ich es verstanden habe fehlen csv-files.
Dann hast du erst einmal Pech, scheinbar hat noch keiner die *.csv-Files für diese Geräte aufgenommen, und von Vaillant wirst du wohl keine Unterstützung bekommen ( Scheint ein Betriebsgeheimniss zu sein )
Zitat
EBUSD_OPTS="-d enh:192.168.0.12:9999 -l /var/log/ebusd.log --log='all error' --log='bus info' --scanconfig --httpport=88 --htmlpath=/var/ebusd/html --accesslevel=* --configlang=DE --mqttport=1883 --mqttjson --mqtthost=192.168.0.6 --mqtttopic=ebusd/%circuit/%name --latency=20000"
>
Für den Anfang solltest du das komplette Log aufzeichnen, damit du erst einmal siehst, was denn alles über den eBus so abgeht. also welche Telegramme jetzt schon über den Bus gehen ( die Geräte unterhalten sich wahrscheinlich untereinander, diese Telegramme kannst du mitscheiden und auswerten )
Beispiel :
2021-07-10 11:59:11.877 [update notice] received unknown MS cmd: 1008b5110101 / 095c00e017007c0000ff
2021-07-10 11:59:17.304 [bus notice] new master ff, master count 4
2021-07-10 11:59:17.324 [update notice] received unknown MS cmd: ff15b509030d0000 / 03a10100
2021-07-10 11:59:17.747 [update notice] received unknown MS cmd: 1008b5100900000076ffff050000 / 0101
2021-07-10 11:59:18.309 [update notice] received unknown MS cmd: ff15b509030d4200 / 0102
2021-07-10 11:59:18.522 [update notice] received unknown MS cmd: ff15b509030d5d00 / 0100
Diese unknown commands kannst du dann auswerten und hast damit schon mal einen Grundstock, auf dem du aufbauen kannst
Ich hab mir für die Auswertung ein Programm geschrieben, womit man diese Telegramme untersuchen kann ( z.B. die Datentypen auswerten usw )
glückauf
guinnes
Zitat von: guinnes am 05 November 2021, 18:29:32
Dann hast du erst einmal Pech, scheinbar hat noch keiner die *.csv-Files für diese Geräte aufgenommen, und von Vaillant wirst du wohl keine Unterstützung bekommen ( Scheint ein Betriebsgeheimniss zu sein )Für den Anfang solltest du das komplette Log aufzeichnen, damit du erst einmal siehst, was denn alles über den eBus so abgeht. also welche Telegramme jetzt schon über den Bus gehen ( die Geräte unterhalten sich wahrscheinlich untereinander, diese Telegramme kannst du mitscheiden und auswerten )
Beispiel :
2021-07-10 11:59:11.877 [update notice] received unknown MS cmd: 1008b5110101 / 095c00e017007c0000ff
2021-07-10 11:59:17.304 [bus notice] new master ff, master count 4
2021-07-10 11:59:17.324 [update notice] received unknown MS cmd: ff15b509030d0000 / 03a10100
2021-07-10 11:59:17.747 [update notice] received unknown MS cmd: 1008b5100900000076ffff050000 / 0101
2021-07-10 11:59:18.309 [update notice] received unknown MS cmd: ff15b509030d4200 / 0102
2021-07-10 11:59:18.522 [update notice] received unknown MS cmd: ff15b509030d5d00 / 0100
Diese unknown commands kannst du dann auswerten und hast damit schon mal einen Grundstock, auf dem du aufbauen kannst
Ich hab mir für die Auswertung ein Programm geschrieben, womit man diese Telegramme untersuchen kann ( z.B. die Datentypen auswerten usw )
glückauf
guinnes
Ok dann werde ich erstmal alles loggen und mir das anschauen. Gibt es irgendwelche Infos, wie solche csv-files erstellt werden können?
Ich habe die Devices in Fhem über MQTT eingebunden, wie im wiki beschrieben. Es wurden automatisch die Geräte im Screenshot angelegt, jedoch fehlt das VRC720. Wenn ich ebusctl find -a ausführe bekomme eine ganze Menge:
720 AdaptHeatCurve = no data stored
720 AdaptHeatCurve = no data stored
720 BankHolidayEndPeriod = no data stored
720 BankHolidayEndPeriod = no data stored
720 BankHolidayStartPeriod = no data stored
720 BankHolidayStartPeriod = no data stored
720 ccTimer.Friday = no data stored
720 ccTimer.Friday = no data stored
720 ccTimer.Monday = no data stored
720 ccTimer.Monday = no data stored
720 ccTimer.Saturday = no data stored
720 ccTimer.Saturday = no data stored
720 ccTimer.Sunday = no data stored
720 ccTimer.Sunday = no data stored
720 ccTimer.Thursday = no data stored
720 ccTimer.Thursday = no data stored
720 ccTimer.Tuesday = no data stored
720 ccTimer.Tuesday = no data stored
720 ccTimer.Wednesday = no data stored
720 ccTimer.Wednesday = no data stored
720 clearerrorhistory = no data stored
720 ContinuosHeating = no data stored
720 ContinuosHeating = no data stored
720 currenterror = no data stored
720 CylinderChargeHyst = no data stored
720 CylinderChargeHyst = no data stored
720 CylinderChargeOffset = no data stored
720 CylinderChargeOffset = no data stored
720 Date = no data stored
720 Date = no data stored
720 DisplayedOutsideTemp = no data stored
720 errorhistory = no data stored
720 FrostOverRideTime = no data stored
720 FrostOverRideTime = no data stored
720 Hc1ActualFlowTempDesired = no data stored
720 Hc1AutoOffMode = no data stored
720 Hc1AutoOffMode = no data stored
720 Hc1CircuitType = no data stored
720 Hc1ExcessTemp = no data stored
720 Hc1ExcessTemp = no data stored
720 Hc1FlowTemp = no data stored
720 Hc1HeatCurve = no data stored
720 Hc1HeatCurve = no data stored
720 Hc1HeatCurveAdaption = no data stored
720 Hc1MaxFlowTempDesired = no data stored
720 Hc1MaxFlowTempDesired = no data stored
720 Hc1MinFlowTempDesired = no data stored
720 Hc1MinFlowTempDesired = no data stored
720 Hc1MixerMovement = no data stored
720 Hc1PumpStatus = no data stored
720 Hc1PumpStatus = no data stored
720 Hc1RoomTempSwitchOn = no data stored
720 Hc1RoomTempSwitchOn = no data stored
720 Hc1Status = no data stored
720 Hc1Status = no data stored
720 Hc1SummerTempLimit = no data stored
720 Hc1SummerTempLimit = no data stored
720 Hc2ActualFlowTempDesired = no data stored
720 Hc2AutoOffMode = no data stored
720 Hc2AutoOffMode = no data stored
720 Hc2CircuitType = no data stored
720 Hc2ExcessTemp = no data stored
720 Hc2ExcessTemp = no data stored
720 Hc2FlowTemp = no data stored
720 Hc2HeatCurve = no data stored
720 Hc2HeatCurve = no data stored
720 Hc2HeatCurveAdaption = no data stored
720 Hc2MaxFlowTempDesired = no data stored
720 Hc2MaxFlowTempDesired = no data stored
720 Hc2MinFlowTempDesired = no data stored
720 Hc2MinFlowTempDesired = no data stored
720 Hc2MixerMovement = no data stored
720 Hc2PumpStatus = no data stored
720 Hc2PumpStatus = no data stored
720 Hc2RoomTempSwitchOn = no data stored
720 Hc2RoomTempSwitchOn = no data stored
720 Hc2Status = no data stored
720 Hc2Status = no data stored
720 Hc2SummerTempLimit = no data stored
720 Hc2SummerTempLimit = no data stored
720 Hc3ActualFlowTempDesired = no data stored
720 Hc3AutoOffMode = no data stored
720 Hc3AutoOffMode = no data stored
720 Hc3CircuitType = no data stored
720 Hc3ExcessTemp = no data stored
720 Hc3ExcessTemp = no data stored
720 Hc3FlowTemp = no data stored
720 Hc3HeatCurve = no data stored
720 Hc3HeatCurve = no data stored
720 Hc3HeatCurveAdaption = no data stored
720 Hc3MaxFlowTempDesired = no data stored
720 Hc3MaxFlowTempDesired = no data stored
720 Hc3MinFlowTempDesired = no data stored
720 Hc3MinFlowTempDesired = no data stored
720 Hc3MixerMovement = no data stored
720 Hc3PumpStatus = no data stored
720 Hc3PumpStatus = no data stored
720 Hc3RoomTempSwitchOn = no data stored
720 Hc3RoomTempSwitchOn = no data stored
720 Hc3Status = no data stored
720 Hc3Status = no data stored
720 Hc3SummerTempLimit = no data stored
720 Hc3SummerTempLimit = no data stored
720 HcStorageTempBottom = no data stored
720 HcStorageTempTop = no data stored
720 HolidayEndPeriod = no data stored
720 HolidayEndPeriod = no data stored
720 HolidayStartPeriod = no data stored
720 HolidayStartPeriod = no data stored
720 HolidayTemp = no data stored
720 HolidayTemp = no data stored
720 HwcBankHolidayEndPeriod = no data stored
720 HwcBankHolidayEndPeriod = no data stored
720 HwcBankHolidayStartPeriod = no data stored
720 HwcBankHolidayStartPeriod = no data stored
720 HwcFlowTemp = no data stored
720 HwcHolidayEndPeriod = no data stored
720 HwcHolidayEndPeriod = no data stored
720 HwcHolidayStartPeriod = no data stored
720 HwcHolidayStartPeriod = no data stored
720 HwcLockTime = no data stored
720 HwcLockTime = no data stored
720 HwcMaxFlowTempDesired = no data stored
720 HwcMaxFlowTempDesired = no data stored
720 HwcOpMode = no data stored
720 HwcOpMode = no data stored
720 HwcParallelLoading = no data stored
720 HwcParallelLoading = no data stored
720 HwcSFMode = no data stored
720 HwcSFMode = no data stored
720 HwcStorageTemp = no data stored
720 HwcStorageTempBottom = no data stored
720 HwcStorageTempTop = no data stored
720 HwcTempDesired = no data stored
720 HwcTempDesired = no data stored
720 hwcTimer.Friday = no data stored
720 hwcTimer.Friday = no data stored
720 hwcTimer.Monday = no data stored
720 hwcTimer.Monday = no data stored
720 hwcTimer.Saturday = no data stored
720 hwcTimer.Saturday = no data stored
720 hwcTimer.Sunday = no data stored
720 hwcTimer.Sunday = no data stored
720 hwcTimer.Thursday = no data stored
720 hwcTimer.Thursday = no data stored
720 hwcTimer.Tuesday = no data stored
720 hwcTimer.Tuesday = no data stored
720 hwcTimer.Wednesday = no data stored
720 hwcTimer.Wednesday = no data stored
720 HydraulicScheme = no data stored
720 HydraulicScheme = no data stored
720 Installer1 = no data stored
720 Installer1 = no data stored
720 Installer2 = no data stored
720 Installer2 = no data stored
720 KeyCodeforConfigMenu = no data stored
720 KeyCodeforConfigMenu = no data stored
720 MaintenanceDate = no data stored
720 MaintenanceDate = no data stored
720 MaintenanceDue = no data stored
720 MaxCylinderChargeTime = no data stored
720 MaxCylinderChargeTime = no data stored
720 MaxRoomHumidity = no data stored
720 MaxRoomHumidity = no data stored
720 MultiRelaySetting = no data stored
720 MultiRelaySetting = no data stored
720 noiseReductionTimer.Friday = no data stored
720 noiseReductionTimer.Friday = no data stored
720 noiseReductionTimer.Monday = no data stored
720 noiseReductionTimer.Monday = no data stored
720 noiseReductionTimer.Saturday = no data stored
720 noiseReductionTimer.Saturday = no data stored
720 noiseReductionTimer.Sunday = no data stored
720 noiseReductionTimer.Sunday = no data stored
720 noiseReductionTimer.Thursday = no data stored
720 noiseReductionTimer.Thursday = no data stored
720 noiseReductionTimer.Tuesday = no data stored
720 noiseReductionTimer.Tuesday = no data stored
720 noiseReductionTimer.Wednesday = no data stored
720 noiseReductionTimer.Wednesday = no data stored
720 OpMode = no data stored
720 OpMode = no data stored
720 OpModeEffect = no data stored
720 OpModeEffect = no data stored
720 OutsideTempAvg = no data stored
720 OutsideTempAvg = no data stored
720 PhoneNumber1 = no data stored
720 PhoneNumber1 = no data stored
720 PhoneNumber2 = no data stored
720 PhoneNumber2 = no data stored
720 PrEnergySum = no data stored
720 PrEnergySum = no data stored
720 PrEnergySumHc = no data stored
720 PrEnergySumHc = no data stored
720 PrEnergySumHcLastMonth = no data stored
720 PrEnergySumHcLastMonth = no data stored
720 PrEnergySumHcThisMonth = no data stored
720 PrEnergySumHcThisMonth = no data stored
720 PrEnergySumHwc = no data stored
720 PrEnergySumHwc = no data stored
720 PrEnergySumHwcLastMonth = no data stored
720 PrEnergySumHwcLastMonth = no data stored
720 PrEnergySumHwcThisMonth = no data stored
720 PrEnergySumHwcThisMonth = no data stored
720 PrFuelSum = no data stored
720 PrFuelSum = no data stored
720 PrFuelSumHc = no data stored
720 PrFuelSumHc = no data stored
720 PrFuelSumHcLastMonth = no data stored
720 PrFuelSumHcLastMonth = no data stored
720 PrFuelSumHcThisMonth = no data stored
720 PrFuelSumHcThisMonth = no data stored
720 PrFuelSumHwc = no data stored
720 PrFuelSumHwc = no data stored
720 PrFuelSumHwcLastMonth = no data stored
720 PrFuelSumHwcLastMonth = no data stored
720 PrFuelSumHwcThisMonth = no data stored
720 PrFuelSumHwcThisMonth = no data stored
720 PumpAdditionalTime = no data stored
720 PumpAdditionalTime = no data stored
720 SFMode = no data stored
720 SFMode = no data stored
720 SolarYieldTotal = no data stored
720 SolarYieldTotal = no data stored
720 SystemFlowTemp = no data stored
720 tariffTimer.Friday = no data stored
720 tariffTimer.Friday = no data stored
720 tariffTimer.Monday = no data stored
720 tariffTimer.Monday = no data stored
720 tariffTimer.Saturday = no data stored
720 tariffTimer.Saturday = no data stored
720 tariffTimer.Sunday = no data stored
720 tariffTimer.Sunday = no data stored
720 tariffTimer.Thursday = no data stored
720 tariffTimer.Thursday = no data stored
720 tariffTimer.Tuesday = no data stored
720 tariffTimer.Tuesday = no data stored
720 tariffTimer.Wednesday = no data stored
720 tariffTimer.Wednesday = no data stored
720 Time = no data stored
720 Time = no data stored
720 ventilationTimer.Friday = no data stored
720 ventilationTimer.Friday = no data stored
720 ventilationTimer.Monday = no data stored
720 ventilationTimer.Monday = no data stored
720 ventilationTimer.Saturday = no data stored
720 ventilationTimer.Saturday = no data stored
720 ventilationTimer.Sunday = no data stored
720 ventilationTimer.Sunday = no data stored
720 ventilationTimer.Thursday = no data stored
720 ventilationTimer.Thursday = no data stored
720 ventilationTimer.Tuesday = no data stored
720 ventilationTimer.Tuesday = no data stored
720 ventilationTimer.Wednesday = no data stored
720 ventilationTimer.Wednesday = no data stored
720 WaterPressure = no data stored
720 YieldTotal = no data stored
720 YieldTotal = no data stored
720 z1ActualRoomTempDesired = no data stored
720 z1ActualRoomTempDesired = no data stored
720 z1BankHolidayEndPeriod = no data stored
720 z1BankHolidayEndPeriod = no data stored
720 z1BankHolidayStartPeriod = no data stored
720 z1BankHolidayStartPeriod = no data stored
720 z1CoolingTemp = no data stored
720 z1CoolingTemp = no data stored
720 z1CoolingTimer.Friday = no data stored
720 z1CoolingTimer.Friday = no data stored
720 z1CoolingTimer.Monday = no data stored
720 z1CoolingTimer.Monday = no data stored
720 z1CoolingTimer.Saturday = no data stored
720 z1CoolingTimer.Saturday = no data stored
720 z1CoolingTimer.Sunday = no data stored
720 z1CoolingTimer.Sunday = no data stored
720 z1CoolingTimer.Thursday = no data stored
720 z1CoolingTimer.Thursday = no data stored
720 z1CoolingTimer.Tuesday = no data stored
720 z1CoolingTimer.Tuesday = no data stored
720 z1CoolingTimer.Wednesday = no data stored
720 z1CoolingTimer.Wednesday = no data stored
720 z1DayTemp = no data stored
720 z1DayTemp = no data stored
720 z1HolidayEndPeriod = no data stored
720 z1HolidayEndPeriod = no data stored
720 z1HolidayStartPeriod = no data stored
720 z1HolidayStartPeriod = no data stored
720 z1HolidayTemp = no data stored
720 z1HolidayTemp = no data stored
720 z1Name1 = no data stored
720 z1Name1 = no data stored
720 z1Name2 = no data stored
720 z1Name2 = no data stored
720 z1NightTemp = no data stored
720 z1NightTemp = no data stored
720 z1OpMode = no data stored
720 z1OpMode = no data stored
720 z1QuickVetoTemp = no data stored
720 z1QuickVetoTemp = no data stored
720 z1RoomTemp = no data stored
720 z1RoomZoneMapping = no data stored
720 z1RoomZoneMapping = no data stored
720 z1SFMode = no data stored
720 z1SFMode = no data stored
720 z1Shortname = no data stored
720 z1Shortname = no data stored
720 z1Timer.Friday = no data stored
720 z1Timer.Friday = no data stored
720 z1Timer.Monday = no data stored
720 z1Timer.Monday = no data stored
720 z1Timer.Saturday = no data stored
720 z1Timer.Saturday = no data stored
720 z1Timer.Sunday = no data stored
720 z1Timer.Sunday = no data stored
720 z1Timer.Thursday = no data stored
720 z1Timer.Thursday = no data stored
720 z1Timer.Tuesday = no data stored
720 z1Timer.Tuesday = no data stored
720 z1Timer.Wednesday = no data stored
720 z1Timer.Wednesday = no data stored
720 z1ValveStatus = no data stored
720 z1ValveStatus = no data stored
720 z2ActualRoomTempDesired = no data stored
720 z2ActualRoomTempDesired = no data stored
720 z2BankHolidayEndPeriod = no data stored
720 z2BankHolidayEndPeriod = no data stored
720 z2BankHolidayStartPeriod = no data stored
720 z2BankHolidayStartPeriod = no data stored
720 z2CoolingTemp = no data stored
720 z2CoolingTemp = no data stored
720 z2CoolingTimer.Friday = no data stored
720 z2CoolingTimer.Friday = no data stored
720 z2CoolingTimer.Monday = no data stored
720 z2CoolingTimer.Monday = no data stored
720 z2CoolingTimer.Saturday = no data stored
720 z2CoolingTimer.Saturday = no data stored
720 z2CoolingTimer.Sunday = no data stored
720 z2CoolingTimer.Sunday = no data stored
720 z2CoolingTimer.Thursday = no data stored
720 z2CoolingTimer.Thursday = no data stored
720 z2CoolingTimer.Tuesday = no data stored
720 z2CoolingTimer.Tuesday = no data stored
720 z2CoolingTimer.Wednesday = no data stored
720 z2CoolingTimer.Wednesday = no data stored
720 z2DayTemp = no data stored
720 z2DayTemp = no data stored
720 z2HolidayEndPeriod = no data stored
720 z2HolidayEndPeriod = no data stored
720 z2HolidayStartPeriod = no data stored
720 z2HolidayStartPeriod = no data stored
720 z2HolidayTemp = no data stored
720 z2HolidayTemp = no data stored
720 z2Name1 = no data stored
720 z2Name1 = no data stored
720 z2Name2 = no data stored
720 z2Name2 = no data stored
720 z2NightTemp = no data stored
720 z2NightTemp = no data stored
720 z2OpMode = no data stored
720 z2OpMode = no data stored
720 z2QuickVetoTemp = no data stored
720 z2QuickVetoTemp = no data stored
720 z2RoomTemp = no data stored
720 z2RoomZoneMapping = no data stored
720 z2RoomZoneMapping = no data stored
720 z2SFMode = no data stored
720 z2SFMode = no data stored
720 z2Shortname = no data stored
720 z2Shortname = no data stored
720 z2Timer.Friday = no data stored
720 z2Timer.Friday = no data stored
720 z2Timer.Monday = no data stored
720 z2Timer.Monday = no data stored
720 z2Timer.Saturday = no data stored
720 z2Timer.Saturday = no data stored
720 z2Timer.Sunday = no data stored
720 z2Timer.Sunday = no data stored
720 z2Timer.Thursday = no data stored
720 z2Timer.Thursday = no data stored
720 z2Timer.Tuesday = no data stored
720 z2Timer.Tuesday = no data stored
720 z2Timer.Wednesday = no data stored
720 z2Timer.Wednesday = no data stored
720 z2ValveStatus = no data stored
720 z2ValveStatus = no data stored
720 z3ActualRoomTempDesired = no data stored
720 z3ActualRoomTempDesired = no data stored
720 z3BankHolidayEndPeriod = no data stored
720 z3BankHolidayEndPeriod = no data stored
720 z3BankHolidayStartPeriod = no data stored
720 z3BankHolidayStartPeriod = no data stored
720 z3DayTemp = no data stored
720 z3DayTemp = no data stored
720 z3HolidayEndPeriod = no data stored
720 z3HolidayEndPeriod = no data stored
720 z3HolidayStartPeriod = no data stored
720 z3HolidayStartPeriod = no data stored
720 z3HolidayTemp = no data stored
720 z3HolidayTemp = no data stored
720 z3Name1 = no data stored
720 z3Name1 = no data stored
720 z3Name2 = no data stored
720 z3Name2 = no data stored
720 z3NightTemp = no data stored
720 z3NightTemp = no data stored
720 z3OpMode = no data stored
720 z3OpMode = no data stored
720 z3QuickVetoTemp = no data stored
720 z3QuickVetoTemp = no data stored
720 z3RoomTemp = no data stored
720 z3RoomZoneMapping = no data stored
720 z3RoomZoneMapping = no data stored
720 z3SFMode = no data stored
720 z3SFMode = no data stored
720 z3Shortname = no data stored
720 z3Shortname = no data stored
720 z3ValveStatus = no data stored
720 z3ValveStatus = no data stored
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = 9.441
broadcast queryexistence = no data stored
broadcast signoflife = no data stored
broadcast vdatetime = 19:41:49;05.11.2021
broadcast vdatetime = no data stored
general valuerange = no data stored
hmu clearerrorhistory = no data stored
hmu ConsumptionThisYear10 = no data stored
hmu ConsumptionThisYear11 = no data stored
hmu ConsumptionThisYear12 = no data stored
hmu ConsumptionThisYear1 = no data stored
hmu ConsumptionThisYear2 = no data stored
hmu ConsumptionThisYear3 = no data stored
hmu ConsumptionThisYear4 = no data stored
hmu ConsumptionThisYear5 = no data stored
hmu ConsumptionThisYear6 = no data stored
hmu ConsumptionThisYear7 = no data stored
hmu ConsumptionThisYear8 = no data stored
hmu ConsumptionThisYear9 = no data stored
hmu ConsumptionTotal = no data stored
hmu currenterror = no data stored
hmu DateTime = no data stored
hmu EnergyCool = no data stored
hmu EnergyHc = no data stored
hmu errorhistory = no data stored
hmu Hours = no data stored
hmu HoursCool = no data stored
hmu HoursHc = no data stored
hmu SetMode = auto;34.5;-;-;0;1;1;0;0;0
hmu State = 0;428;193;8
hmu Status01 = 35.0;32.5;-;-;-;on
hmu Status02 = no data stored
hmu Status16 = no data stored
hmu Status = no data stored
hmu StatusCirPump = on
hmu YieldThisYear10 = no data stored
hmu YieldThisYear11 = no data stored
hmu YieldThisYear12 = no data stored
hmu YieldThisYear1 = no data stored
hmu YieldThisYear2 = no data stored
hmu YieldThisYear3 = no data stored
hmu YieldThisYear4 = no data stored
hmu YieldThisYear5 = no data stored
hmu YieldThisYear6 = no data stored
hmu YieldThisYear7 = no data stored
hmu YieldThisYear8 = no data stored
hmu YieldThisYear9 = no data stored
hmu YieldTotal = no data stored
hwc ActorFernsteuerung = no data stored
hwc ActualKrm = no data stored
hwc ActualTappingTempDesired = no data stored
hwc ActualTnm = no data stored
hwc AutoTappingTempDesired = no data stored
hwc BigHExThreshold = no data stored
hwc CalculatedMixerPosition = no data stored
hwc CircoPump = no data stored
hwc clearerrorhistory = no data stored
hwc currenterror = no data stored
hwc Date = no data stored
hwc DateTime = no data stored
hwc DurchflussTemp = no data stored
hwc ElectricalHeater = no data stored
hwc EnableHwcOperation = no data stored
hwc errorhistory = no data stored
hwc HeatDemand = no data stored
hwc HExIndex = no data stored
hwc HexMonitoringCounter = no data stored
hwc HExThreshold = no data stored
hwc HolidayStart = no data stored
hwc Krm = no data stored
hwc KrmFaktorMiddl = no data stored
hwc KrmFaktorSmall = no data stored
hwc Krp = no data stored
hwc LegioStartDay = no data stored
hwc LegioStartTime = no data stored
hwc load = no data stored
hwc ManualTappingTempDesired = no data stored
hwc ManualTappingTempDesired = no data stored
hwc Mode = no data stored
hwc Ntc1Sensor = no data stored
hwc Ntc2Sensor = no data stored
hwc Ntc3Sensor = no data stored
hwc OperatingMode = no data stored
hwc OperatingMode = no data stored
hwc OverheatTimer = no data stored
hwc Params = no data stored
hwc party = no data stored
hwc PartyStart = no data stored
hwc PumpED = no data stored
hwc QuickVetoStart = no data stored
hwc QuickVetoTempDesired = no data stored
hwc save = no data stored
hwc SetFlowTempMax = no data stored
hwc SetFlowTempMin = no data stored
hwc SetMode = no data stored
hwc SetTempDesired = no data stored
hwc SingleStorageCharge = no data stored
hwc StateCircoKick = no data stored
hwc StateHExMonitoring = no data stored
hwc StateMainControl = no data stored
hwc StateMixerPumpControl = no data stored
hwc Status0a = no data stored
hwc Status16 = no data stored
hwc Status = 56;on;-;45
hwc SteBusCheckFailedCounter = no data stored
hwc SteBusCheckFailedCounter = no data stored
hwc StFrostProtCounter = no data stored
hwc StFrostProtCounter = no data stored
hwc StInstallationDate = no data stored
hwc StInstallationDate = no data stored
hwc StLegioAbortTimeCounter = no data stored
hwc StLegioAbortTimeCounter = no data stored
hwc StLegioStopTimeCounter = no data stored
hwc StLegioStopTimeCounter = no data stored
hwc TeleSwitch = no data stored
hwc TeleSwitchState = no data stored
hwc Time = no data stored
hwc Timer.Friday = no data stored
hwc Timer.Friday = no data stored
hwc Timer.Monday = no data stored
hwc Timer.Monday = no data stored
hwc Timer.Saturday = no data stored
hwc Timer.Saturday = no data stored
hwc Timer.Sunday = no data stored
hwc Timer.Sunday = no data stored
hwc Timer.Thursday = no data stored
hwc Timer.Thursday = no data stored
hwc Timer.Tuesday = no data stored
hwc Timer.Tuesday = no data stored
hwc Timer.Wednesday = no data stored
hwc Timer.Wednesday = no data stored
hwc TimeTicker = no data stored
hwc Tm = no data stored
hwc Tnm = no data stored
hwc TnmFaktorMiddl = no data stored
hwc TnmFaktorSmall = no data stored
hwc Tp = no data stored
hwc Tvm = no data stored
hwc Tvp = no data stored
hwc Vortex = no data stored
hwc VPMWMode = no data stored
hwc Weekday = no data stored
hwc ZaehlerBetriebsStunden = no data stored
memory eeprom = no data stored
memory eeprom = no data stored
memory ram = no data stored
memory ram = no data stored
scan id = no data stored
scan.08 = Vaillant;HMU00;0522;5103
scan.08 id = 21;21;03;0010021111;0001;005103;N8
scan.0a = Vaillant;PMW01;0206;8302
scan.0a id = 21;21;21;0010014311;3110;017352;N4
scan.15 = Vaillant;72000;0122;7703
scan.15 id = 21;21;03;0020260914;0953;006826;N0
scan.18 = Vaillant;V32;0117;9802
scan.26 = Vaillant;VR_71;0104;0503
scan.26 id = 21;21;21;0020184846;0082;011350;N7
scan.76 = Vaillant;VWZ00;0522;5103
scan.76 id = 21;21;20;0010023495;1610;005478;N3
vr_71 clearerrorhistory = no data stored
vr_71 currenterror = no data stored
vr_71 errorhistory = no data stored
vr_71 Mc1FlowTempDesired = on;33.0;on;25
vr_71 Mc2FlowTempDesired = no data stored
vr_71 Mc3FlowTempDesired = no data stored
vr_71 SensorData1 = 33.94;29.88;-;-;34.88;34.75;56.12;50 00
vr_71 SensorData2 = 49.50;-;-;-;0.00;8.00;80 fc 05
vr_71 SetActorState = -;off;off;off;off;off;-;-;off;off;off;off;00 00
Wieso werden einige Geräte automatisch angelegt, aber nicht alle? Liegt es daran, dass die Geräte, die untereinander über den Bus kommunizieren vom ebusd die Werte bekommen und dadurch die Geräte angelegt werden und das VRC720 sendet einfach nichts auf den Bus? Verstehe ich es richtig, dass ich nun alle notwendigen Daten per Timer abfragen muss?
Zitat von: Arek am 05 November 2021, 19:55:35
Ok dann werde ich erstmal alles loggen und mir das anschauen. Gibt es irgendwelche Infos, wie solche csv-files erstellt werden können?
Sieht erst mal komliziert aus, ist aber eigentlich recht logisch. Das war für mich der Grund, warum ich erst was anderes probiert hatte. Leider war die andere Möglichkeit nicht sehr zuverlässig, darum hab ich dann doch gewechselt und bin mittlerweile recht zufrieden mit eBusD.
( Hab mir ein Programm geschrieben, welches die *.csv-Files bearbeiten kann )
Infos https://github.com/john30/ebusd/wiki/4.-Configuration (https://github.com/john30/ebusd/wiki/4.-Configuration)
Zitat
Wieso werden einige Geräte automatisch angelegt, aber nicht alle?
Es werden die Geräte angelegt, für die es eine Konfigurationsdatei gibt. Leider passen auch die Konfigurationsfiles nicht immer genau zu dem Gerät. ich mußte mir meine auch zusammensammeln. Die nötigen Infos hab ich aus den Logs entnommen
Glückauf
guinnes
Hi guinnes.
Zitat von: guinnes am 05 November 2021, 18:29:32
Ich hab mir für die Auswertung ein Programm geschrieben, womit man diese Telegramme untersuchen kann ( z.B. die Datentypen auswerten usw )
Klingt sehr interessant. Hättest du Muße dies (ggf. in einem eigenen Fred) zu vertiefen? Könnte mir vorstellen, dass dies auch andere hilfreich fänden :)
Oder hast du schon eine externe Lesequelle?
Viele Grüße
rob
Zitat von: guinnes am 05 November 2021, 21:55:54
( Hab mir ein Programm geschrieben, welches die *.csv-Files bearbeiten kann )
dazu hilft auch "ebusctl grab result decode", was für alle gegrabbten unknown für jeden Datentyp und jede mögliche und im Resultat gültige Position den dekodierten Wert ausgibt, z.B. so:
1052b5040132 / 0a002806020101c0040100 = 821
BCD 00=0, 28=28, 06=6, 02=2, 01=1, 01=1, 04=4, 01=1, 00=0
BCD:2 0028=2800, 2806=628, 0602=206, 0201=102, 0101=101, 0401=104, 0100=1
BCD:3 002806=62800, 280602=20628, 060201=10206, 020101=10102, 040100=104
BCD:4 00280602=2062800, 28060201=1020628, 06020101=1010206
BDA 28060201="28.06.2001", 06020101="06.02.2001", 0101c004="01.01.2004"
BDA:3 280602="28.06.2002", 060201="06.02.2001", 020101="02.01.2001", 040100="04.01.2000"
BDY 00=Mon, 06=Sun, 02=Wed, 01=Tue, 01=Tue, 04=Fri, 01=Tue, 00=Mon
BDZ 28060201="28.06.2001", 06020101="06.02.2001", 0101c004="01.01.2004"
BTI 002806="06:28:00", 280602="02:06:28", 060201="01:02:06", 020101="01:01:02", 040100="00:01:04"
BTM 2806="06:28", 0602="02:06", 0201="01:02", 0101="01:01", 0401="01:04", 0100="00:01"
...
UCH 00=0, 28=40, 06=6, 02=2, 01=1, 01=1, c0=192, 04=4, 01=1, 00=0
UIN 0028=10240, 2806=1576, 0602=518, 0201=258, 0101=257, 01c0=49153, c004=1216, 0401=260, 0100=1
UIR 0028=40, 2806=10246, 0602=1538, 0201=513, 0101=257, 01c0=448, c004=49156, 0401=1025, 0100=256
ULG 00280602=33957888, 28060201=16909864, 06020101=16843270, 020101c0=3221291266, 0101c004=79692033, 01c00401=17088513, c0040100=66752
ULR 00280602=2622978, 28060201=671482369, 06020101=100794625, 020101c0=33620416, 0101c004=16891908, 01c00401=29361153, c0040100=3221487872
VTI 002806="06:40:00", 280602="02:06:40", 060201="01:02:06", 020101="01:01:02", 040100="00:01:04"
VTM 2806="06:40", 0602="02:06", 0201="01:02", 0101="01:01", 0401="01:04", 0100="00:01"
also z.B. die Zeile `BCD:4 00280602=2062800, 28060201=1020628, 06020101=1010206` zeigt die Byte Sequenzen, die für den Datentyp BCD:4 (4 Bytes BCD codiert least significant byte first) möglich wären, beginnend mit dem ersten Datenbyte in der Antwort vom Slave nach dem Längenbyte 0x0a.
Wenn man nun weiß, dass das Ziel 0x52 ein Mischer ist, kann man evtl. schon ahnen, was im einzelnen hinter den Werten verborgen sein könnte. Das könnte man noch mit anderen Werten korrelieren, die vielleicht bereits dekodiert sind, und so kommt man langsam vorwärts.
Es hilft natürlich auch, so eine Nachricht im Lauf der Zeit zu betrachten. Man könnte zum Mischer hingehen und lauschen, ob er irgendwann mal abschaltet oder gravierend die Temperatur erhöht. Das sollte sich dann in den Daten auch widerspiegeln.
Oder man forciert eine solche Änderung durch Änderung einer Einstellung am System. Dann einfach das grab result vorher/nachher diffen und schon hat man wieder etwas mehr Input :-)
Zitat von: rob am 05 November 2021, 22:19:01
Klingt sehr interessant. Hättest du Muße dies (ggf. in einem eigenen Fred) zu vertiefen? Könnte mir vorstellen, dass dies auch andere hilfreich fänden :)
Das Programm ist nur so "hingeschissen", also ohne einen roten Faden und ohne selbsterklärend zu sein. Es ist gewachsen, ohne Struktur und Dokumentation ist nicht so meines ;)
Zitat
Oder hast du schon eine externe Lesequelle?
??
Aber wenn Interesse besteht....
Glückauf
guinnes
Erst einmal vielen Dank für das tolle Projekt!
Ich versuche aktuell, meinen eBus 3.0 Adapter (Wemos Variante) in Betrieb zu nehmen. Beim Testen ist mir jetzt aufgefallen, dass nach einem Neustart des ebusd auf meinem Raspi der Adapter keine eBus Meldungen mehr liest eBUS signal: no signal.
Wenn ich einen Reboot über das Web-Interface durchführe, dann startet anscheinend nur der Wemos neu.
Nur wenn ich den Adapter vom Strom trenne und so dafür sorge, dass auch der PIC neu startet, dann kommen wieder Meldungen rein.
Gibt es denn keine Möglichkeit, den PIC "remote" durchzustarten?
Hallo miteinander,
heute habe ich meinen kürzlich ausgelieferten ebus Adapter in Betrieb genommen (great job :) ).
Den eBus-Daemon habe ich als docker Container auf meiner Syno laufen, der Adapter ist mit einer festen IP über das LAN erreichbar.
Die Heizung bestaht aus einer Vaillant mit VRC700 und VR70.
Soweit scheint auch alles zu laufen, nur werden die Vaillant Komponenten wohl nicht erkannt und die CSV-Files nicht geladen.
Ich habe nun schon einiges mit latency probiert und auch ein lokales Config-Directory ausprobiert, ohne Erfolg.
Momentan sehen die Startargumente so aus:
-f --scanconfig --configlang=de --readonly --accesslevel=* -d enh:192.168.2.216:9999 --loglevel=info --latency=20 --address=ff
Im Startlog ist zu sehen, dass die grundlegenden CSV geladen werden:
2021-11-07 19:50:39.828 [main notice] ebusd 21.1.v21.1-3-g62221bb started with auto scan
2021-11-07 19:50:39.828 [main info] loading configuration files from http://ebusd.eu/config/
2021-11-07 19:50:39.868 [main info] reading templates /
2021-11-07 19:50:39.906 [main info] read templates in /
2021-11-07 19:50:39.906 [main info] reading file memory.csv
2021-11-07 19:50:39.945 [main info] successfully read file memory.csv
2021-11-07 19:50:39.945 [main info] reading file broadcast.csv
2021-11-07 19:50:39.984 [main info] successfully read file broadcast.csv
2021-11-07 19:50:39.984 [main info] read config files
2021-11-07 19:50:40.010 [main info] registering data handlers
2021-11-07 19:50:40.010 [main info] registered data handlers
2021-11-07 19:50:40.010 [bus notice] bus started with own address ff/04
2021-11-07 19:50:40.020 [bus notice] signal acquired
2021-11-07 19:50:40.094 [bus notice] new master 10, master count 1
2021-11-07 19:50:40.144 [bus notice] new master 03, master count 2
2021-11-07 19:50:40.145 [update info] received MS cmd: 1008b5110102 / 05033c965082
2021-11-07 19:50:40.145 [update notice] received unknown MS cmd: 1008b5110102 / 05033c965082
2021-11-07 19:50:40.153 [bus notice] device status: reset
2021-11-07 19:50:40.452 [update info] received MS cmd: 1052b523080114ff0014ffff00 / 0101
2021-11-07 19:50:40.452 [update notice] received unknown MS cmd: 1052b523080114ff0014ffff00 / 01
01
2021-11-07 19:50:40.707 [update info] received MS cmd: 1052b523040201015b / 020141
2021-11-07 19:50:40.707 [update notice] received unknown MS cmd: 1052b523040201015b / 020141
2021-11-07 19:50:49.352 [update info] received MS cmd: 1008b5110101 / 095cff600800ff4000ff
.....
ebusctl i zeigt:
root@ebusd:/# ebusctl i
version: ebusd 21.1.v21.1-3-g62221bb
update check: version 21.2 available
access: *
signal: acquired
symbol rate: 61
max symbol rate: 101
reconnects: 0
masters: 2
messages: 14
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 52: slave
Nach dem was ich hier gelesen habe sollte es soweit passen. Nur warum wird Vaillant nicht erkannt ?
Im Repo gibt es ein Unterverzeichnis vaillant. Dort findet sich auch eine 52.vr_70.csv die m.M. nach passen sollte. Auch eine 15.700.csv findet sich für den VRC700.
Habt ihre eine Idee was nicht stimmt oder ein Startparameter fehlt ?
FHEM habe ich nicht integriert, der Daemon soll erstmal die Komponenten erkennen, dann kommt MQTT dran.
Grüße,
Heiko
Bin einen Schritt weiter. Ich musste das Argument "--readonly" entfernen.
Nun sieht ebusctl i schonmal gut aus:
root@ebusd:/# ebusctl i
version: ebusd 21.1.v21.1-3-g62221bb
access: *
signal: acquired
symbol rate: 22
max symbol rate: 144
min arbitration micros: 2
max arbitration micros: 42
min symbol latency: 5
max symbol latency: 19
reconnects: 0
masters: 3
messages: 661
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010007508.inc" ([PROD='0010007508']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
address ff: master #25, ebusd
Ich hatte die --readonly Option als Sicherheitsfeature verstanden um ein versehentliches Schreiben auf den eBus zu verhindern.
Warum dadurch die Erkennung verhindert wird erscheint mir unlogisch.
Wie sehen das die Spezialisten ?
Edit: Noch eine Frage zu "poll". Lt. obigen Ausdruck ist poll = 0. Ich hatte es so verstanden dass wenn --pollinterval nicht explizit gesetzt ist der default von 5 Sec greift, oder ist es ein anderer Zusammenhang ?
LG
Zitat von: DS_Starter am 07 November 2021, 23:03:54
Bin einen Schritt weiter. Ich musste das Argument "--readonly" entfernen.
(...)
Ich hatte die --readonly Option als Sicherheitsfeature verstanden um ein versehentliches Schreiben auf den eBus zu verhindern.
Warum dadurch die Erkennung verhindert wird erscheint mir unlogisch.
Darüber bin ich auch (https://forum.fhem.de/index.php/topic,118143.msg1141832.html#msg1141832) anfangs gestolpert. ;)
Die --readonly Option verhindert sämtliches Schreiben des ebusd auf dem Bus. Damit wird dann tatsächlich auch die automatische Erkennung der Komponenten verhindert, denn dafür muss ebusd aktiv Details der kommunizierenden Geräte über den Bus abfragen. Möchte man längerfristig mit --readonly arbeiten, bleibt eigentlich nur die manuelle Konfiguration.
Zitat von: DS_Starter am 07 November 2021, 23:03:54
Noch eine Frage zu "poll". Lt. obigen Ausdruck ist poll = 0. Ich hatte es so verstanden dass wenn --pollinterval nicht explizit gesetzt ist der default von 5 Sec greift, oder ist es ein anderer Zusammenhang ?
--pollinterval hat einen Standardwert > 0, das ist richtig.
Die Ausgabe "poll: 0" vom "ebusctl i" bedeutet, dass in der verwendeten Konfiguration 0 Messages eine Poll-Priorität zugeordnet wurde. D.h. ebusd wird von sich aus keine Werte zyklisch abfragen.
Danke für die Infos ... dann mache ich mal an der Stelle weiter.
ich ersuche alle die jetzt die Adapter in Betrieb nehmen mir keine Mails oder PN zu schicken um Lösungen oder Erklärungen anzufragen, ich lese die kaum da die meisten Mails die ihr erhaltet ja automatisch aus dem Reservierungsformular kommen und bei mir durch Regeln in bestimmte Ordner verschoben werden. Ich horte die nur um bei eventuellen Versandproblemen nachschauen zu können.
Bitte alle Probleme zur Inbetriebnahme einfach hier posten, dazu ist das Forum ja da und andere profitieren auch davon!
LG
Reinhart
Zitat von: weini am 07 November 2021, 18:30:37
Ich versuche aktuell, meinen eBus 3.0 Adapter (Wemos Variante) in Betrieb zu nehmen. Beim Testen ist mir jetzt aufgefallen, dass nach einem Neustart des ebusd auf meinem Raspi der Adapter keine eBus Meldungen mehr liest.
Das Problem hat sich glücklicherweise erledigt. Es muss aber irgendetwas mit der ebusd Konfiguration zu tun gehabt haben, da ich sonst nichts mehr geändert habe. Ich kann den ebusd jetzt beliebig beenden und neu starten, ohne dass der Adapter den Dienst verweigern würde.
Ich habe jetzt ein neues Problem:
Die Heizkurve lässt sich bei meiner Steuerung (VRC720) in 0,05 Schritten einstellen, jedoch hat das Reading immer nur eine Nachkommastelle. Wenn ich den Wert über ebusctl abfrage, bekomme ich es korrekt.
ebusctl read Hc1HeatCurve
0.45
Internals:
CID ebusd_720
DEF ebusd_720
DEVICETOPIC MQTT2_ebusd_720
FUUID 6187f23c-f33f-e57f-72d7-829cee2dbfbf5794
IODev mqttBroker
LASTInputDev mqttBroker
MSGCNT 8
NAME MQTT2_ebusd_720
NR 165
STATE Vorlauf: 0.0
Ruecklauf: 0.0
Warmwasser: 0.0
Aussentemp.: 0.0
Pumpe: 0
HWC-maxTemp: 0.0
HWC-Regler_Max: 0.0
HWC-CurrentTemp: 0.0
HWC-Mode: 0
TYPE MQTT2_DEVICE
mqttBroker_MSGCNT 8
mqttBroker_TIME 2021-11-12 20:05:15
JSONMAP:
attr MQTT2_ebusd_720
ebusd_720_Hc1HeatCurve_name 0\
ebusd_720_Hc1HeatCurve_value Hc1HeatCurve
ebusd_720_HwcTempDesired_name 0
ebusd_720_HwcTempDesired_value HwcTempDesired
model eBus_720_Pump_Fan_HeatCurve_HwcTemp
READINGS:
2021-11-12 17:37:07 0_name
2021-11-12 17:37:07 0_value 0.4
2021-11-12 20:05:15 Hc1HeatCurve_0_name
2021-11-12 20:05:15 Hc1HeatCurve_0_value 0.4
2021-11-12 17:55:26 HwcTempDesired_tempv_value 45.0
2021-11-12 19:08:19 IODev mqttBroker
2021-11-12 17:21:23 attrTemplateVersion 20210722
2021-11-12 17:32:51 ebusd_720_Hc1HeatCurve {
"0": {"name": "", "value": 0.4}}
2021-11-12 17:50:58 state Hc1HeatCurve_0_value
Attributes:
devStateIcon {my $vC = ReadingsVal($name, "Hc1HeatCurve_curve_value", "10")*10; my $colCur = substr(Color::pahColor(5,10,15,$vC,0),0,6); my $iconCur = 'time_graph@'.$colCur; my $vH = ReadingsVal($name, "HwcTempDesired_temp1_value", "30"); my $colHot = substr(Color::pahColor(0,30,60,$vH,0),0,6); my $iconHot = 'sani_water_hot@'.$colHot; ; "
" . FW_makeImage("$iconCur",'file_unknown@grey') . "
" . FW_makeImage("$iconHot",'sani_water_hot@red') . "
"}
devStateStyle style="text-align:right"
getList Hc1HeatCurve:noArg Hc1HeatCurve_curve_value ebusd/720/Hc1HeatCurve/get
HwcTempDesired:noArg HwcTempDesired_temp1_value ebusd/720/HwcTempDesired/get
group eBus_Hcurve
icon message_tendency_steady
jsonMap ebusd_720_Hc1HeatCurve_value:Hc1HeatCurve ebusd_720_Hc1HeatCurve_name:0\
ebusd_720_HwcTempDesired_value:HwcTempDesired ebusd_720_HwcTempDesired_name:0
attr MQTT2_ebusd_720 model eBus_720_Pump_Fan_HeatCurve_HwcTemp
readingList ebusd/720/AdaptHeatCurve:.* ebusd_720_AdaptHeatCurve
ebusd/720/BankHolidayEndPeriod:.* ebusd_720_BankHolidayEndPeriod
ebusd/720/BankHolidayStartPeriod:.* ebusd_720_BankHolidayStartPeriod
ebusd/720/ccTimer\x2eFriday:.* ebusd_720_ccTimer.Friday
ebusd/720/ccTimer\x2eMonday:.* ebusd_720_ccTimer.Monday
ebusd/720/ccTimer\x2eSaturday:.* ebusd_720_ccTimer.Saturday
ebusd/720/ccTimer\x2eSunday:.* ebusd_720_ccTimer.Sunday
ebusd/720/ccTimer\x2eThursday:.* ebusd_720_ccTimer.Thursday
ebusd/720/ccTimer\x2eTuesday:.* ebusd_720_ccTimer.Tuesday
ebusd/720/ccTimer\x2eWednesday:.* ebusd_720_ccTimer.Wednesday
ebusd/720/clearerrorhistory:.* ebusd_720_clearerrorhistory
ebusd/720/ContinuosHeating:.* ebusd_720_ContinuosHeating
ebusd/720/currenterror:.* ebusd_720_currenterror
ebusd/720/CylinderChargeHyst:.* ebusd_720_CylinderChargeHyst
ebusd/720/CylinderChargeOffset:.* ebusd_720_CylinderChargeOffset
ebusd/720/Date:.* ebusd_720_Date
ebusd/720/DisplayedOutsideTemp:.* ebusd_720_DisplayedOutsideTemp
ebusd/720/errorhistory:.* ebusd_720_errorhistory
ebusd/720/FrostOverRideTime:.* ebusd_720_FrostOverRideTime
ebusd/720/Hc1ActualFlowTempDesired:.* { FHEM::aTm2u_ebus::j2nv( $EVENT, '', $JSONMAP ) }
ebusd/720/Hc1AutoOffMode:.* ebusd_720_Hc1AutoOffMode
ebusd/720/Hc1CircuitType:.* ebusd_720_Hc1CircuitType
ebusd/720/Hc1ExcessTemp:.* ebusd_720_Hc1ExcessTemp
ebusd/720/Hc1FlowTemp:.* ebusd_720_Hc1FlowTemp
ebusd/720/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }
ebusd/720/Hc1HeatCurveAdaption:.* ebusd_720_Hc1HeatCurveAdaption
ebusd/720/Hc1MaxFlowTempDesired:.* ebusd_720_Hc1MaxFlowTempDesired
ebusd/720/Hc1MinFlowTempDesired:.* ebusd_720_Hc1MinFlowTempDesired
ebusd/720/Hc1MixerMovement:.* ebusd_720_Hc1MixerMovement
ebusd/720/Hc1PumpStatus:.* ebusd_720_Hc1PumpStatus
ebusd/720/Hc1RoomTempSwitchOn:.* ebusd_720_Hc1RoomTempSwitchOn
ebusd/720/Hc1Status:.* { FHEM::aTm2u_ebus::j2nv( $EVENT, '', $JSONMAP ) }
ebusd/720/Hc1SummerTempLimit:.* ebusd_720_Hc1SummerTempLimit
ebusd/720/Hc2ActualFlowTempDesired:.* ebusd_720_Hc2ActualFlowTempDesired
ebusd/720/Hc2AutoOffMode:.* ebusd_720_Hc2AutoOffMode
ebusd/720/Hc2CircuitType:.* ebusd_720_Hc2CircuitType
ebusd/720/Hc2ExcessTemp:.* ebusd_720_Hc2ExcessTemp
ebusd/720/Hc2FlowTemp:.* ebusd_720_Hc2FlowTemp
ebusd/720/Hc2HeatCurve:.* ebusd_720_Hc2HeatCurve
ebusd/720/Hc2HeatCurveAdaption:.* ebusd_720_Hc2HeatCurveAdaption
ebusd/720/Hc2MaxFlowTempDesired:.* ebusd_720_Hc2MaxFlowTempDesired
ebusd/720/Hc2MinFlowTempDesired:.* ebusd_720_Hc2MinFlowTempDesired
ebusd/720/Hc2MixerMovement:.* ebusd_720_Hc2MixerMovement
ebusd/720/Hc2PumpStatus:.* ebusd_720_Hc2PumpStatus
ebusd/720/Hc2RoomTempSwitchOn:.* ebusd_720_Hc2RoomTempSwitchOn
ebusd/720/Hc2Status:.* ebusd_720_Hc2Status
ebusd/720/Hc2SummerTempLimit:.* ebusd_720_Hc2SummerTempLimit
ebusd/720/Hc3ActualFlowTempDesired:.* ebusd_720_Hc3ActualFlowTempDesired
ebusd/720/Hc3AutoOffMode:.* ebusd_720_Hc3AutoOffMode
ebusd/720/Hc3CircuitType:.* ebusd_720_Hc3CircuitType
ebusd/720/Hc3ExcessTemp:.* ebusd_720_Hc3ExcessTemp
ebusd/720/Hc3FlowTemp:.* ebusd_720_Hc3FlowTemp
ebusd/720/Hc3HeatCurve:.* ebusd_720_Hc3HeatCurve
ebusd/720/Hc3HeatCurveAdaption:.* ebusd_720_Hc3HeatCurveAdaption
ebusd/720/Hc3MaxFlowTempDesired:.* ebusd_720_Hc3MaxFlowTempDesired
ebusd/720/Hc3MinFlowTempDesired:.* ebusd_720_Hc3MinFlowTempDesired
ebusd/720/Hc3MixerMovement:.* ebusd_720_Hc3MixerMovement
ebusd/720/Hc3PumpStatus:.* ebusd_720_Hc3PumpStatus
ebusd/720/Hc3RoomTempSwitchOn:.* ebusd_720_Hc3RoomTempSwitchOn
ebusd/720/Hc3Status:.* ebusd_720_Hc3Status
ebusd/720/Hc3SummerTempLimit:.* ebusd_720_Hc3SummerTempLimit
ebusd/720/HcStorageTempBottom:.* ebusd_720_HcStorageTempBottom
ebusd/720/HcStorageTempTop:.* ebusd_720_HcStorageTempTop
ebusd/720/HolidayEndPeriod:.* ebusd_720_HolidayEndPeriod
ebusd/720/HolidayStartPeriod:.* ebusd_720_HolidayStartPeriod
ebusd/720/HolidayTemp:.* ebusd_720_HolidayTemp
ebusd/720/HwcBankHolidayEndPeriod:.* ebusd_720_HwcBankHolidayEndPeriod
ebusd/720/HwcBankHolidayStartPeriod:.* ebusd_720_HwcBankHolidayStartPeriod
ebusd/720/HwcFlowTemp:.* { FHEM::aTm2u_ebus::j2nv( $EVENT, '', $JSONMAP ) }
ebusd/720/HwcHolidayEndPeriod:.* ebusd_720_HwcHolidayEndPeriod
ebusd/720/HwcHolidayStartPeriod:.* ebusd_720_HwcHolidayStartPeriod
ebusd/720/HwcLockTime:.* ebusd_720_HwcLockTime
ebusd/720/HwcMaxFlowTempDesired:.* ebusd_720_HwcMaxFlowTempDesired
ebusd/720/HwcOpMode:.* ebusd_720_HwcOpMode
ebusd/720/HwcParallelLoading:.* ebusd_720_HwcParallelLoading
ebusd/720/HwcSFMode:.* ebusd_720_HwcSFMode
ebusd/720/HwcStorageTemp:.* ebusd_720_HwcStorageTemp
ebusd/720/HwcStorageTempBottom:.* ebusd_720_HwcStorageTempBottom
ebusd/720/HwcStorageTempTop:.* ebusd_720_HwcStorageTempTop
ebusd/720/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }
ebusd/720/hwcTimer\x2eFriday:.* ebusd_720_hwcTimer.Friday
ebusd/720/hwcTimer\x2eMonday:.* ebusd_720_hwcTimer.Monday
ebusd/720/hwcTimer\x2eSaturday:.* ebusd_720_hwcTimer.Saturday
ebusd/720/hwcTimer\x2eSunday:.* ebusd_720_hwcTimer.Sunday
ebusd/720/hwcTimer\x2eThursday:.* ebusd_720_hwcTimer.Thursday
ebusd/720/hwcTimer\x2eTuesday:.* ebusd_720_hwcTimer.Tuesday
ebusd/720/hwcTimer\x2eWednesday:.* ebusd_720_hwcTimer.Wednesday
ebusd/720/HydraulicScheme:.* ebusd_720_HydraulicScheme
ebusd/720/Installer1:.* ebusd_720_Installer1
ebusd/720/Installer2:.* ebusd_720_Installer2
ebusd/720/KeyCodeforConfigMenu:.* ebusd_720_KeyCodeforConfigMenu
ebusd/720/MaintenanceDate:.* ebusd_720_MaintenanceDate
ebusd/720/MaintenanceDue:.* ebusd_720_MaintenanceDue
ebusd/720/MaxCylinderChargeTime:.* ebusd_720_MaxCylinderChargeTime
ebusd/720/MaxRoomHumidity:.* ebusd_720_MaxRoomHumidity
ebusd/720/MultiRelaySetting:.* ebusd_720_MultiRelaySetting
ebusd/720/noiseReductionTimer\x2eFriday:.* ebusd_720_noiseReductionTimer.Friday
ebusd/720/noiseReductionTimer\x2eMonday:.* ebusd_720_noiseReductionTimer.Monday
ebusd/720/noiseReductionTimer\x2eSaturday:.* ebusd_720_noiseReductionTimer.Saturday
ebusd/720/noiseReductionTimer\x2eSunday:.* ebusd_720_noiseReductionTimer.Sunday
ebusd/720/noiseReductionTimer\x2eThursday:.* ebusd_720_noiseReductionTimer.Thursday
ebusd/720/noiseReductionTimer\x2eTuesday:.* ebusd_720_noiseReductionTimer.Tuesday
ebusd/720/noiseReductionTimer\x2eWednesday:.* ebusd_720_noiseReductionTimer.Wednesday
ebusd/720/OpMode:.* ebusd_720_OpMode
ebusd/720/OpModeEffect:.* ebusd_720_OpModeEffect
ebusd/720/OutsideTempAvg:.* ebusd_720_OutsideTempAvg
ebusd/720/PhoneNumber1:.* ebusd_720_PhoneNumber1
ebusd/720/PhoneNumber2:.* ebusd_720_PhoneNumber2
ebusd/720/PrEnergySum:.* ebusd_720_PrEnergySum
ebusd/720/PrEnergySumHc:.* ebusd_720_PrEnergySumHc
ebusd/720/PrEnergySumHcLastMonth:.* ebusd_720_PrEnergySumHcLastMonth
ebusd/720/PrEnergySumHcThisMonth:.* ebusd_720_PrEnergySumHcThisMonth
ebusd/720/PrEnergySumHwc:.* ebusd_720_PrEnergySumHwc
ebusd/720/PrEnergySumHwcLastMonth:.* ebusd_720_PrEnergySumHwcLastMonth
ebusd/720/PrEnergySumHwcThisMonth:.* ebusd_720_PrEnergySumHwcThisMonth
ebusd/720/PrFuelSum:.* ebusd_720_PrFuelSum
ebusd/720/PrFuelSumHc:.* ebusd_720_PrFuelSumHc
ebusd/720/PrFuelSumHcLastMonth:.* ebusd_720_PrFuelSumHcLastMonth
ebusd/720/PrFuelSumHcThisMonth:.* ebusd_720_PrFuelSumHcThisMonth
ebusd/720/PrFuelSumHwc:.* ebusd_720_PrFuelSumHwc
ebusd/720/PrFuelSumHwcLastMonth:.* ebusd_720_PrFuelSumHwcLastMonth
ebusd/720/PrFuelSumHwcThisMonth:.* ebusd_720_PrFuelSumHwcThisMonth
ebusd/720/PumpAdditionalTime:.* ebusd_720_PumpAdditionalTime
ebusd/720/SFMode:.* ebusd_720_SFMode
ebusd/720/SolarYieldTotal:.* ebusd_720_SolarYieldTotal
ebusd/720/SystemFlowTemp:.* ebusd_720_SystemFlowTemp
ebusd/720/tariffTimer\x2eFriday:.* ebusd_720_tariffTimer.Friday
ebusd/720/tariffTimer\x2eMonday:.* ebusd_720_tariffTimer.Monday
ebusd/720/tariffTimer\x2eSaturday:.* ebusd_720_tariffTimer.Saturday
ebusd/720/tariffTimer\x2eSunday:.* ebusd_720_tariffTimer.Sunday
ebusd/720/tariffTimer\x2eThursday:.* ebusd_720_tariffTimer.Thursday
ebusd/720/tariffTimer\x2eTuesday:.* ebusd_720_tariffTimer.Tuesday
ebusd/720/tariffTimer\x2eWednesday:.* ebusd_720_tariffTimer.Wednesday
ebusd/720/Time:.* ebusd_720_Time
ebusd/720/ventilationTimer\x2eFriday:.* ebusd_720_ventilationTimer.Friday
ebusd/720/ventilationTimer\x2eMonday:.* ebusd_720_ventilationTimer.Monday
ebusd/720/ventilationTimer\x2eSaturday:.* ebusd_720_ventilationTimer.Saturday
ebusd/720/ventilationTimer\x2eSunday:.* ebusd_720_ventilationTimer.Sunday
ebusd/720/ventilationTimer\x2eThursday:.* ebusd_720_ventilationTimer.Thursday
ebusd/720/ventilationTimer\x2eTuesday:.* ebusd_720_ventilationTimer.Tuesday
ebusd/720/ventilationTimer\x2eWednesday:.* ebusd_720_ventilationTimer.Wednesday
ebusd/720/WaterPressure:.* ebusd_720_WaterPressure
ebusd/720/YieldTotal:.* ebusd_720_YieldTotal
ebusd/720/z1ActualRoomTempDesired:.* ebusd_720_z1ActualRoomTempDesired
ebusd/720/z1BankHolidayEndPeriod:.* ebusd_720_z1BankHolidayEndPeriod
ebusd/720/z1BankHolidayStartPeriod:.* ebusd_720_z1BankHolidayStartPeriod
ebusd/720/z1CoolingTemp:.* ebusd_720_z1CoolingTemp
ebusd/720/z1CoolingTimer\x2eFriday:.* ebusd_720_z1CoolingTimer.Friday
ebusd/720/z1CoolingTimer\x2eMonday:.* ebusd_720_z1CoolingTimer.Monday
ebusd/720/z1CoolingTimer\x2eSaturday:.* ebusd_720_z1CoolingTimer.Saturday
ebusd/720/z1CoolingTimer\x2eSunday:.* ebusd_720_z1CoolingTimer.Sunday
ebusd/720/z1CoolingTimer\x2eThursday:.* ebusd_720_z1CoolingTimer.Thursday
ebusd/720/z1CoolingTimer\x2eTuesday:.* ebusd_720_z1CoolingTimer.Tuesday
ebusd/720/z1CoolingTimer\x2eWednesday:.* ebusd_720_z1CoolingTimer.Wednesday
ebusd/720/z1DayTemp:.* ebusd_720_z1DayTemp
ebusd/720/z1HolidayEndPeriod:.* ebusd_720_z1HolidayEndPeriod
ebusd/720/z1HolidayStartPeriod:.* ebusd_720_z1HolidayStartPeriod
ebusd/720/z1HolidayTemp:.* ebusd_720_z1HolidayTemp
ebusd/720/z1Name1:.* ebusd_720_z1Name1
ebusd/720/z1Name2:.* ebusd_720_z1Name2
ebusd/720/z1NightTemp:.* ebusd_720_z1NightTemp
ebusd/720/z1OpMode:.* ebusd_720_z1OpMode
ebusd/720/z1QuickVetoTemp:.* ebusd_720_z1QuickVetoTemp
ebusd/720/z1RoomTemp:.* ebusd_720_z1RoomTemp
ebusd/720/z1RoomZoneMapping:.* ebusd_720_z1RoomZoneMapping
ebusd/720/z1SFMode:.* ebusd_720_z1SFMode
ebusd/720/z1Shortname:.* ebusd_720_z1Shortname
ebusd/720/z1Timer\x2eFriday:.* ebusd_720_z1Timer.Friday
ebusd/720/z1Timer\x2eMonday:.* ebusd_720_z1Timer.Monday
ebusd/720/z1Timer\x2eSaturday:.* ebusd_720_z1Timer.Saturday
ebusd/720/z1Timer\x2eSunday:.* ebusd_720_z1Timer.Sunday
ebusd/720/z1Timer\x2eThursday:.* ebusd_720_z1Timer.Thursday
ebusd/720/z1Timer\x2eTuesday:.* ebusd_720_z1Timer.Tuesday
ebusd/720/z1Timer\x2eWednesday:.* ebusd_720_z1Timer.Wednesday
ebusd/720/z1ValveStatus:.* ebusd_720_z1ValveStatus
ebusd/720/z2ActualRoomTempDesired:.* ebusd_720_z2ActualRoomTempDesired
ebusd/720/z2BankHolidayEndPeriod:.* ebusd_720_z2BankHolidayEndPeriod
ebusd/720/z2BankHolidayStartPeriod:.* ebusd_720_z2BankHolidayStartPeriod
ebusd/720/z2CoolingTemp:.* ebusd_720_z2CoolingTemp
ebusd/720/z2CoolingTimer\x2eFriday:.* ebusd_720_z2CoolingTimer.Friday
ebusd/720/z2CoolingTimer\x2eMonday:.* ebusd_720_z2CoolingTimer.Monday
ebusd/720/z2CoolingTimer\x2eSaturday:.* ebusd_720_z2CoolingTimer.Saturday
ebusd/720/z2CoolingTimer\x2eSunday:.* ebusd_720_z2CoolingTimer.Sunday
ebusd/720/z2CoolingTimer\x2eThursday:.* ebusd_720_z2CoolingTimer.Thursday
ebusd/720/z2CoolingTimer\x2eTuesday:.* ebusd_720_z2CoolingTimer.Tuesday
ebusd/720/z2CoolingTimer\x2eWednesday:.* ebusd_720_z2CoolingTimer.Wednesday
ebusd/720/z2DayTemp:.* ebusd_720_z2DayTemp
ebusd/720/z2HolidayEndPeriod:.* ebusd_720_z2HolidayEndPeriod
ebusd/720/z2HolidayStartPeriod:.* ebusd_720_z2HolidayStartPeriod
ebusd/720/z2HolidayTemp:.* ebusd_720_z2HolidayTemp
ebusd/720/z2Name1:.* ebusd_720_z2Name1
ebusd/720/z2Name2:.* ebusd_720_z2Name2
ebusd/720/z2NightTemp:.* ebusd_720_z2NightTemp
ebusd/720/z2OpMode:.* ebusd_720_z2OpMode
ebusd/720/z2QuickVetoTemp:.* ebusd_720_z2QuickVetoTemp
ebusd/720/z2RoomTemp:.* ebusd_720_z2RoomTemp
ebusd/720/z2RoomZoneMapping:.* ebusd_720_z2RoomZoneMapping
ebusd/720/z2SFMode:.* ebusd_720_z2SFMode
ebusd/720/z2Shortname:.* ebusd_720_z2Shortname
ebusd/720/z2Timer\x2eFriday:.* ebusd_720_z2Timer.Friday
ebusd/720/z2Timer\x2eMonday:.* ebusd_720_z2Timer.Monday
ebusd/720/z2Timer\x2eSaturday:.* ebusd_720_z2Timer.Saturday
ebusd/720/z2Timer\x2eSunday:.* ebusd_720_z2Timer.Sunday
ebusd/720/z2Timer\x2eThursday:.* ebusd_720_z2Timer.Thursday
ebusd/720/z2Timer\x2eTuesday:.* ebusd_720_z2Timer.Tuesday
ebusd/720/z2Timer\x2eWednesday:.* ebusd_720_z2Timer.Wednesday
ebusd/720/z2ValveStatus:.* ebusd_720_z2ValveStatus
ebusd/720/z3ActualRoomTempDesired:.* ebusd_720_z3ActualRoomTempDesired
ebusd/720/z3BankHolidayEndPeriod:.* ebusd_720_z3BankHolidayEndPeriod
ebusd/720/z3BankHolidayStartPeriod:.* ebusd_720_z3BankHolidayStartPeriod
ebusd/720/z3DayTemp:.* ebusd_720_z3DayTemp
ebusd/720/z3HolidayEndPeriod:.* ebusd_720_z3HolidayEndPeriod
ebusd/720/z3HolidayStartPeriod:.* ebusd_720_z3HolidayStartPeriod
ebusd/720/z3HolidayTemp:.* ebusd_720_z3HolidayTemp
ebusd/720/z3Name1:.* ebusd_720_z3Name1
ebusd/720/z3Name2:.* ebusd_720_z3Name2
ebusd/720/z3NightTemp:.* ebusd_720_z3NightTemp
ebusd/720/z3OpMode:.* ebusd_720_z3OpMode
ebusd/720/z3QuickVetoTemp:.* ebusd_720_z3QuickVetoTemp
ebusd/720/z3RoomTemp:.* ebusd_720_z3RoomTemp
ebusd/720/z3RoomZoneMapping:.* ebusd_720_z3RoomZoneMapping
ebusd/720/z3SFMode:.* ebusd_720_z3SFMode
ebusd/720/z3Shortname:.* ebusd_720_z3Shortname
ebusd/720/z3ValveStatus:.* ebusd_720_z3ValveStatus
room MQTT2_DEVICE
setList Hc1HeatCurve_0_value:uzsuDropDown,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75 ebusd/720/Hc1HeatCurve/set $EVTPART1
HwcTempDesired_tempv_value:uzsuDropDown,40.0,41.0,42.0,43.0,44.0,45.0,46.0,47.0,48.0,49.0,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/720/HwcTempDesired/set $EVTPART1
stateFormat {sprintf("Vorlauf: %.1f
Ruecklauf: %.1f
Warmwasser: %.1f
Aussentemp.: %.1f
Pumpe: %s
HWC-maxTemp: %.1f
HWC-Regler_Max: %.1f
HWC-CurrentTemp: %.1f
HWC-Mode: %s", ReadingsVal($name,"_Vorlauf",0), ReadingsVal($name,"_Ruecklauf",0), ReadingsVal($name,"_Warmwasser",0), ReadingsVal($name,"_Aussentemp",0), ReadingsVal($name,"_Pumpenstatus",0), ReadingsVal($name,"_Maximaltemperatur",0), ReadingsVal($name,"_ReglerMaxTEMP",0), ReadingsVal($name,"_ReglerCurrentTemp",0), ReadingsVal($name,"_HWCMode",0))}
webCmd Hc1HeatCurve_0_value:HwcTempDesired_tempv_value
webCmdLabel Heizkurve
:Warmwasser
Wie kriege ich die 2. Nachkommastelle hin?
Zitat von: Arek am 12 November 2021, 20:07:13
Wie kriege ich die 2. Nachkommastelle hin?
Probier mal im stateFormat bei sprintf anstatt %.1f -> %.2f
Zitat von: Wolle02 am 13 November 2021, 10:50:00
Probier mal im stateFormat bei sprintf anstatt %.1f -> %.2f
Geht leider nicht. Das Reading ist ja schon mit nur einer Nachkommastelle (0,4) angegeben und die 0,05 wird einfach entfernt.
also ich verstehe jetzt nicht genau wo das Problem ist, kannst du das näher erklären?
{'eBusSet.sollcurve'=>'Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.30,0.35,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70','eBusSet.sollwater'=>'HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0'}
wenn ich den uzsuDropdown so definiere (alles mit 2 Nachkommastellen) dann kann ich die doch auswählen und auch der Variablen "sollcurve" ordentlich übergeben.
<>,<Name>,< Ist>,< Soll>
MQTT2_ebusd_430:<%message_tendency_steady>,<Heizkurve>,Hc1HeatCurve_curve_value,<sollcurve>
MQTT2_ebusd_430:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_temp1_value,<sollwater>
oder per setlist so wie im letzten Bild:
state:0.20,0.30,0.35,0.40,0.50,0.60,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70
Hier siehst du auch das dieser Wert ordentlich abgesetzt wurde. Der linke Wert ist der ausgelesene Istwert.
LG
Hallo zusammen
Ich nutze den ebusd mit der csv-Datei von Rellla für den TEM-Regler.
https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/tem/15.csv
1.Frage:
Wenn ich über das Terminal eine Abfrage mache, bekomme ich folgende Antwort:
Anfrage: "ebusctl r -f temp_hg"
Antwort: "00-107;Temperatur;°C;100.0;0.0;46.9"
Kann mir jemand sagen, was die erste Nummern (00-107) bedeuten?
2.Frage:
Wie kann ich eine Abfrage auf die vl_temp_ist der WP machen, wenn diese in der spallte Name nicht eindeutig ist? Der Name "vl_temp_ist" hat es in der CSV-Datei mehrmals:
- Zeile 12 für die WP
- Zeile 185 für die Heizgruppe
Ich freue mich auf euer Antworten
LG
Hallo zusammen,
ich wusste nicht ob ich jetzt einen eigenen Thread aufmachen soll oder ob es Euch lieber ist alles unter "Inbetriebnahme" zu haben.
Erst einmal Danke für den großartigen Adapter 3! Es hat alles sehr gut funktioniert und der Adapter läuft bzw. es kommen Daten von der Heizung an.
Ich habe folgende Installation: Debian 11, Installation über das Debian-Repository.
Nun wollte ich mit MQTT anfangen (das ist alles Neuland für mich). Ich habe im log-file von ebusD folgenden Fehler:
2021-11-22 14:40:31.481 [mqtt error] invalid mosquitto version 2 instead of 1
2021-11-22 14:40:31.482 [main error] error registering data handlers
Hier https://github.com/john30/ebusd/issues/443 sehe ich, dass John demnächst auch ein Update für das Debian-Repository machen wird (https://github.com/john30/ebusd/releases/tag/v21.3).
Soweit scheint der Fehler ,,gelöst" zu sein, wenn ich alles richtig verstanden habe.
Ich warte einfach auf das Update.
Jetzt habe ich aber noch eine blöde Frage (als ebus-Adapter und MQTT Neuling):
Ich habe den MQTT Broker auf einer eigenen virtuellen Maschine mit Debian. Muss ich jetzt auf der Debian-Maschine auf der ebusD läuft noch irgendwas installieren, wenn ich die Version von ebusD mit MQTT Unterstützung installiert habe? Braucht es da noch was um von der ebusD-Maschine auf den Broker zu publishen? Oder ist das in der eBusD Installation alles drin?
Vielen Dank für Eure Hilfe.
vg, Bernd
Zitat von: hallozuerich am 22 November 2021, 14:14:06
siehe https://forum.fhem.de/index.php/topic,80888.msg1188734.html#msg1188734 (https://forum.fhem.de/index.php/topic,80888.msg1188734.html#msg1188734)
Doppelposts sind schlecht ....
Gruß
Andreas
Zitat von: moe_054 am 23 November 2021, 08:02:26
Jetzt habe ich aber noch eine blöde Frage (als ebus-Adapter und MQTT Neuling):
Ich habe den MQTT Broker auf einer eigenen virtuellen Maschine mit Debian. Muss ich jetzt auf der Debian-Maschine auf der ebusD läuft noch irgendwas installieren, wenn ich die Version von ebusD mit MQTT Unterstützung installiert habe? Braucht es da noch was um von der ebusD-Maschine auf den Broker zu publishen? Oder ist das in der eBusD Installation alles drin?
Vielen Dank für Eure Hilfe.
vg, Bernd
Bin der Meinung in diesem Wiki-Beitrag (https://wiki.fhem.de/wiki/EBUS-MQTT2) werden dir diese Fragen beantwortet.
Zitat von: Reinhart am 22 November 2021, 11:55:03
also ich verstehe jetzt nicht genau wo das Problem ist, kannst du das näher erklären?
{'eBusSet.sollcurve'=>'Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.30,0.35,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70','eBusSet.sollwater'=>'HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0'}
wenn ich den uzsuDropdown so definiere (alles mit 2 Nachkommastellen) dann kann ich die doch auswählen und auch der Variablen "sollcurve" ordentlich übergeben.
<>,<Name>,< Ist>,< Soll>
MQTT2_ebusd_430:<%message_tendency_steady>,<Heizkurve>,Hc1HeatCurve_curve_value,<sollcurve>
MQTT2_ebusd_430:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_temp1_value,<sollwater>
oder per setlist so wie im letzten Bild:
state:0.20,0.30,0.35,0.40,0.50,0.60,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70
Hier siehst du auch das dieser Wert ordentlich abgesetzt wurde. Der linke Wert ist der ausgelesene Istwert.
LG
Wenn man direkt die Heizkurve abfragt:
ebusctl read -V Hc1HeatCurve
bekommt man:
720 Hc1HeatCurve =0.45 [heating curve of Hc1]
Das ist auch völlig richtig, allerdings ist das Reading in fhem 0.4, und nicht 0.45.
Ich habe auch folgendes versucht:
attr stateFormat {sprintf("Heizkurve: %.2f", ReadingsVal($name,"Heizkurve",0))}
Das funktioniert auch nicht, die zweite Kommastelle fehlt einfach im Reading. Das Set funktioniert einwandfrei, auch mit zweiter Nachkommastelle.
Hallo zusammen,
habe meinen Adapter schon etwas Zeit in Betrieb und läuft prima. Die FHEM Integration über MQTT wird immer intensiver/besser.
Eine Abfrage geht bei mir nicht. Betrifft "PrEnergySumHc1".
Über "ebusctl find -V" sehe ich:
bai PrEnergySumHc1 = (ERR: invalid position for ff08b509030df400 / 020000) [ZZ=08, lastup=2021-11-27 22:37:50, active read]
Kann es sein, dass in der aktuellen CSV (in welcher eigentlich?) speziell für diesen Wert ein Fehler vorliegt ?
Der Aufbau und die Abhängigkeiten voneinander (was wann geladen / benutzt wird) sind mir noch nicht klar. Zu diesem Detail komme ich sicherlich erst später wenn ich soweit fortgeschritten bin dass es ans eingemachte gehen kann.
Für Tipps wie man sich am Besten dieses Wissen dazu aneignet, wäre ich auch dankbar.
LG,
Heiko
was wann geladen wird ist ganz einfach, der Dämon scannt ja beim Start alle Adressen durch und findet so die Geräte mit HW, PROD und SW am eBus.
Hier ein Beispiel der 08.bai.csv, je nachdem was da gefunden wurde, wird das entsprechende CSV File dann nachgeladen, dort sind dann die Definitionen hinterlegt. Ganz unten siehst du dann bei welcher Hardware welches CSV (inc) dann geladen wird, somit werden die verschiedenen Geräte und Definitionen unterschieden und die CSV kombiniert.
Bei den PrEnergySumHc1 ist es leider so, dass nicht alle Geräte die wirklich liefern, mein Heizgerät gibt da auch nix zurück. Warum das so ist, weiß vermutlich nur der Hersteller oder es ist schlicht bei bestimmten Typen nicht vorgesehen. Bei deiner "invalid position" sieht es allerdings so aus, dass bei deiner Hardware die Definition im CSV nicht exakt übereinstimmt.
# type (r[1-9];w;u),circuit,name,[comment],[QQ]
#,BAI00,generic file for all BAI types,,
*[PROD],scan,id,,product
*[HW],scan,,,HW
[PROD='0010002315';'0010002316';'0010002317']!load,bai.0010002315.inc,,,
[PROD='0010003958';'0010003959';'0010003960';'0010003961';'0010003962';'0010003963';'0010003964';'0010003965';'0010003966';'0010003967';'0010003968';'0010003969';'0010003970';'0010003971';'0010003972';'0010003973';'0010003974';'0010003975';'0010003976';'0010003977';'0010003991';'0010004015';'0010004016']!load,bai.0010002465.inc,,,
[PROD='0010003857';'0010003858';'0010003860';'0010003861';'0010003862';'0010003863';'0010003864';'0010003865';'0010003869';'0010003872';'0010003874';'0010003875';'0010003876';'0010003877';'0010003878';'0010003881';'0010009340';'0010009341';'0010009342';'0010009343';'0010009344';'0010009345';'0010009346';'0010009347';'0010009348';'0010009349';'0010009350']!load,bai.0010003857.inc,,,
[PROD='0010003882';'0010003883';'0010003886';'0010003887';'0010009351';'0010009352';'167']!load,bai.0010003886.inc,,,
[PROD='0010004110';'0010004111';'0010004112';'0010004113';'0010004114';'0010004121';'0010004122';'0010004123';'0010004124';'0010004125';'209']!load,bai.0010004121.inc,,,
[PROD='0010004126';'0010004127';'0010010384']!load,bai.0010004150.inc,,,
[PROD='0010005400';'0010005401';'0010005402';'0010005403';'0010005404';'0010005405';'0010005406';'0010005407';'0010005408';'0010005409']!load,bai.0010005400.inc,,,
[PROD='0010006080';'0010006081';'0010006082';'0010006083';'0010006084';'0010006085';'0010006086';'0010006087';'0010006088';'0010006089';'0010006090';'0010006091';'0010006092';'0010006093';'0010006094';'0010006095';'0010006096';'0010006097';'0010006098';'0010006099';'0010006100';'0010006101';'0010006102';'0010006103';'0010006104';'0010006105';'0010006106';'0010006107';'0010006108';'0010006109';'0010006110';'0010006111';'0010006112';'0010006113';'0010006114';'0010006115';'0010006118';'0010006119';'0010006120';'0010006121';'0010006122';'0010006123';'0010006126';'0010006127';'0010006129';'0010006130';'0010006131';'0010006134';'0010006135';'0010006136';'0010006137';'0010006138';'0010006139';'0010006140';'0010006141';'188';'BAI__';'']!load,bai.0010006101.inc,,,
[PROD='0010006341']!load,bai.0010006341.inc,,,
[PROD='0010007508';'0010007510';'0010007512';'0010007514';'0010007516';'0010007518';'0010007520';'0010007522';'0010007524';'0010007526';'0010007688';'0010007692';'0010007696';'0010007700';'0010007704']!load,bai.0010007508.inc,,,
[PROD='0010010674';'0010010676';'0010010678';'207']!load,bai.0010010674.inc,,,
[PROD='0010014629';'0010014630';'0010014631';'0010014632';'0010014633';'0010015596';'0010015597';'0010015598';'0010015599';'0010015600';'0010015601';'0010015602';'0010015603';'0010015604';'0010015605';'0010015606';'0010015607';'0010015608';'0010015609';'0010015610';'0010015611';'0010015612';'0010015613';'0010015614']!load,bai.0010015600.inc,,,
[PROD='0020066007';'187']!load,bai.0020066007.inc,,,
[PROD='0010004276';'0010004277';'0010004279';'0010004280';'0010004281';'0010004282';'0010004283';'0010004285';'0010004286';'0010004288';'0010004289';'0010004290';'0010004291';'0010004292';'0010004336';'0010004337';'0010004338';'0010004339';'0010004340';'0010005466';'0010005467';'0010005468';'0010005469';'0010010392';'0010010393';'0010010394';'0010010400';'0020051714';'0020051715';'0020051716';'0020051717';'174']!load,bai.308523.inc,,,
#fallbacks:,,,,
[HW=6701]!load,bai.0010003886.inc,,,
[HW=0902]!load,bai.0010004121.inc,,,
[HW=8801]!load,bai.0010006101.inc,,,
[HW=0702]!load,bai.0010010674.inc,,,
[HW=9602]!load,bai.0010015600.inc,,,
[HW=8701]!load,bai.0020066007.inc,,,
[HW=7401]!load,bai.308523.inc,,,
!load,bai.308523.inc,,,
!include,hcmode.inc,,,
LG
Reinhart
Danke für die Erklärung!!!
Lässt sich der deutsche Kommentar in den .csv-File (z.B via MQTT) auch irgendwie verwenden? Oder schaut man einfach ins csv-File um dann die Übersetzung quasi für sich zu kennen?
Danke Reinhart !,
Wenn ich es richtig verstanden habe wird z.B. bei einem erkannten PROD (Produktcode ??) von
'0010002315' oder '0010002316' oder '0010002317' die bai.0010002315.inc Datei
geladen.
Wird die Hardware
6701
erkannt, wird zusätzlich die bai.0010003886.inc geladen, richtig ?
ZitatBei deiner "invalid position" sieht es allerdings so aus, dass bei deiner Hardware die Definition im CSV nicht exakt übereinstimmt.
Wie könnte ich denn vorgehen um dieses Problem zu lösen ? Ich weiß, die Frage ist evtl. etwas verfrüht weil ich mich mit den tiefen Internas des eBus noch nicht eingehend beschäftigt habe.
Aber vllt. kannst du eine kleine "Roadmap" dafür skizzieren.
LG,
Heiko
Zitat von: john30 am 06 November 2021, 10:06:14
dazu hilft auch "ebusctl grab result decode", was für alle gegrabbten unknown für jeden Datentyp und jede mögliche und im Resultat gültige Position den dekodierten Wert ausgibt, z.B. so:
Sorry, dass ich wieder frage: ich habe es leider nicht verstanden (habe auch im Wiki geschaut).
Wenn ich obigen Befehl eingebe, kommt:
root@512bb76debe5:/# ebusctl grab result decode
grab disabled
Also starte ich mit:
root@512bb76debe5:/# ebusctl grab
grab started
... und dann nochmals
root@512bb76debe5:/# ebusctl grab result decode
done
Mehr als done kommt bei mir anscheinend nicht. Wie mach ich das richtig?
Vielen Dank und beste Grüße
rob
Zitat von: rob am 02 Dezember 2021, 08:09:00
... und dann nochmals
root@512bb76debe5:/# ebusctl grab result decode
done
Mehr als done kommt bei mir anscheinend nicht. Wie mach ich das richtig?
nach dem grab start muss man natürlich warten, bis nicht dekodierte Nachrichten auftauchen, das passiert ja nicht sofort
hallo!
würde gerne von v21.2 auf v21.3 updaten, wie kann man das am einfachsten machen?
warum werden die neuen csv's nicht automatisch (ohne update) geladen?
lG
Zitat von: MassiveAttack am 15 Dezember 2021, 08:32:26
würde gerne von v21.2 auf v21.3 updaten, wie kann man das am einfachsten machen?
warum werden die neuen csv's nicht automatisch (ohne update) geladen?
wenn das repo eingerichtet ist, dann apt-get update && apt-get upgrade.
z.B. weil es ein reload Kommando dafür gibt
Zitat von: Arek am 23 November 2021, 11:40:07
Wenn man direkt die Heizkurve abfragt:
ebusctl read -V Hc1HeatCurve
bekommt man:
720 Hc1HeatCurve =0.45 [heating curve of Hc1]
Das ist auch völlig richtig, allerdings ist das Reading in fhem 0.4, und nicht 0.45.
Ich habe genau das gleiche Problem, allerdings nicht in FHEM, sondern in Ip-Symcon. Das setzen der Hc1HeatCurve über MQTT funktioniert in 0.05er Schritten tadellos. Wird er sofort danach wieder gelesen, dann ist er ebenfalls in 0.05er Schritten. Aber kurze Zeit später ist er dann plötzlich auf 0.1er Schritte gerundet.
In Debug des MQTT Brokers von Symcon sieht es so aus:
TXT: 24.02.2021, 11:14:46 | MQTT:TX:PUBLISH (Forward) | TXT: 24.02.2021, 11:14:49 | MQTT:TX:PUBLISH | Topic: ebusd/700/Hc1HeatCurve/get, Payload:
TXT: 24.02.2021, 11:14:49 | MQTT:TX:PUBLISH | Sending to ebusd_3.4_20027 (192.168.178.100:36934)
TXT: 24.02.2021, 11:14:50 | BUFFER IN | 0@<NUL><SYN>ebusd/700/Hc1HeatCurve{<LF> "0": {"name": "", "value": 0.65}}
TXT: 24.02.2021, 11:14:50 | MQTT:RX:PUBLISH | Topic: ebusd/700/Hc1HeatCurve, Payload: {<LF> "0": {"name": "", "value": 0.65}}
TXT: 24.02.2021, 11:14:50 | BUFFER IN | 0�<STX><NUL><DC2>ebusd/bai/Status01{<LF> "0": {"name": "temp1", "value": 29.0},<LF> "1": {"name": "temp1", "value": 27.5},<LF> "2": {"name": "temp2", "value": 15.562},<LF> "3": {"name": "temp1", "value": null},<LF> "4": {"name": "temp1", "value": 61.0},<LF> "5": {"name": "pumpstate", "value": "off"}}0?<NUL><SYN>ebusd/700/Hc1HeatCurve{<LF> "0": {"name": "", "value": 0.6}}
TXT: 24.02.2021, 11:14:50 | MQTT:RX:PUBLISH | Topic: ebusd/bai/Status01, Payload: {<LF> "0": {"name": "temp1", "value": 29.0},<LF> "1": {"name": "temp1", "value": 27.5},<LF> "2": {"name": "temp2", "value": 15.562},<LF> "3": {"name": "temp1", "value": null},<LF> "4": {"name": "temp1", "value": 61.0},<LF> "5": {"name": "pumpstate", "value": "off"}}
TXT: 24.02.2021, 11:14:50 | MQTT:RX:PUBLISH | Topic: ebusd/700/Hc1HeatCurve, Payload: {<LF> "0": {"name": "", "value": 0.6}}
TXT: 24.02.2021, 11:14:54 | BUFFER IN | 0�<ETX><NUL><DC1>ebusd/bai/SetMode{<LF> "hcmode": {"value": "auto"},<LF> "flowtempdesired": {"value": 29.5},<LF> "hwctempdesired": {"value": null},<LF> "hwcflowtempdesired": {"value": null},<LF> "disablehc": {"value": 0},<LF> "disablehwctapping": {"value": 0},<LF> "disablehwcload": {"value": 0},<LF> "remoteControlHcPump": {"value": 0},<LF> "releaseBackup": {"value": 0},<LF> "releaseCooling": {"value": 0}}
TXT: 24.02.2021, 11:14:54 | MQTT:RX:PUBLISH | Topic: ebusd/bai/SetMode, Payload: {<LF> "hcmode": {"value": "auto"},<LF> "flowtempdesired": {"value": 29.5},<LF> "hwctempdesired": {"value": null},<LF> "hwcflowtempdesired": {"value": null},<LF> "disablehc": {"value": 0},<LF> "disablehwctapping": {"value": 0},<LF> "disablehwcload": {"value": 0},<LF> "remoteControlHcPump": {"value": 0},<LF> "releaseBackup": {"value": 0},<LF> "releaseCooling": {"value": 0}}
TXT: 24.02.2021, 11:14:54 | BUFFER IN | 0?<NUL><SYN>ebusd/700/Hc1HeatCurve{<LF> "0": {"name": "", "value": 0.6}}
TXT: 24.02.2021, 11:14:54 | MQTT:RX:PUBLISH | Topic: ebusd/700/Hc1HeatCurve, Payload: {<LF> "0": {"name": "", "value": 0.6}}
TXT: 24.02.2021, 11:14:58 | BUFFER IN | 0<EM><NUL><DC3>ebusd/global/uptime2384
TXT: 24.02.2021, 11:14:58 | MQTT:RX:PUBLISH | Topic: ebusd/global/uptime, Payload: 2384
Vielleicht hat ja noch jemand eine Idee.
Burkhard
Leider komme ich mit der Inbetriebnahme des eBUS Adapter 3.0 nicht weiter.
Ich nutze den Adapter auf dem Raspberry PI 4. Ich hab den zwar als Netzwerkversion gekauft mich aber dann umentschieden und eine Sockelleiste aufgelötet und die Jumper umgestellt. Die Umkonfiguration im RPI habe ich auch wie in der Anleitung vorgenommen.
Die grüne LED blink auch und es scheinen eBUS Signale vorhanden zu sein. Ich hatte auch vor Jahren mal einen anderen Adapter am Ebus am laufen. Insofern sollte die Verbindung zur Heizung passen.
Ich starte zum Test den Ebus wie folgt:
ebusd -f --loglevel=debug -d enh:/dev/ttyAMA0 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=ff --readonly --accesslevel=*
Leider wird kein Signal erkannt und die Ausgabe von ebusctl info lautet wie folgt:
ebusctl info
version: ebusd 21.3.v21.3
device: /dev/ttyAMA0, enhanced, readonly
access: *
signal: no signal
reconnects: 0
masters: 0
messages: 11
conditional: 0
poll: 0
update: 4
Der Jumper auf dem Adapter steht auf Enhanced Mode wie in der Auslieferung.
Ich bin nun mit meinem Latein am Ende. Wie kann ich hier den Fehler weiter eingrenzen.
Ich danke Euch schonmal für Eure Mühe. Ich hab auch den ganzen Thread gelesen aber keinen Anhaltspunkt für Fehlereingrenzung erhalten.
Lass mal das --readonly weg. Das hat bei mir am Anfang auch zu Problemen geführt.
Das ändert leider nichts. Fast diesselbe Ausgabe:
ebusctl info
version: ebusd 21.3.v21.3
device: /dev/ttyAMA0, enhanced
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
mach doch bitte einmal den Gegentest und schließe den Adapter per USB an, Jumper setzen und Config anpassen.
Wenn das funktioniert bist du sicher, dass durch das einlöten des RPI Connectors nix beleidigt wurde.
Wenn das alles klappt, dann kann der Fehler nur am ttyebus Treiber zu suchen sein der am Raspi4 eventuell Probleme verursachen könnte.
LG
Das kann ich gerne mal probieren. Muss ich noch einen ttyebus installieren?
Ich habe nur den ebus installiert und dann die Konfiguration wie auf der Website durchgeführt. Dort ist nichts von einem ttyebus Treiber erwähnt.
vielen Dank
Sorry habe ich übersehen, du hast ja schon einen V3 Adapter, da brauchst du keinen ttyebus Treiber!
Ach ja, kannst du kurz ein Foto vom Adapter reinstellen?
Der eingelötete RPI Conector muss nach unten wegstehen (https://adapter.ebusd.eu/img/smd-3drpi.jpg)!
LG
Anbei das Foto. Ich hab das aber schon richtig angelötet und auch die nötigen Erfahrungen da ich jahrelang in einer Elektronikfirma gearbeitet haben und dort selbst Platinen bestückt und verlötet habe.
Aber ist schon richtig dass Du nachfragst. Die gelbe LED ist ja auch an, wewegen die Stromversorgung für den PIC ja da sein muss. Die grüne LED blinkt auch deswegen denke ich dass über den ebus auch was kommt.
Vielen lieben Dank, dass Ihr hier versucht mir zu helfen.
also der Adapter und der RPI-Connector sieht gut aus, aber du hast immer noch den Jumper auf eth gesetzt (der blaue), der muss raus!
Ansonsten checke ob der ttyAMA0 wirklich auf PL011 gemappt ist.
pi@raspberrypi4:~ $ dmesg| grep tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M smsc95xx.macaddr=DC:A6:32:05:9C:3A vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=a26e8757-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.000698] console [tty1] enabled
[ 0.837722] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, base_baud = 0) is a PL011 rev2
[ 0.841036] fe215040.serial: ttyS0 at MMIO 0x0 (irq = 36, base_baud = 62500000) is a 16550
[ 8.736928] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ 8.743027] usb 1-1.3: ch341-uart converter now attached to ttyUSB0
[ 8.753030] cdc_acm 1-1.4:1.2: ttyACM1: USB ACM device
[ 8.755760] cdc_acm 1-1.4:1.4: ttyACM2: USB ACM device
Ansonsten sollte die /boot/config.txt so aussehen:
[all]
enable_uart=1
dtoverlay=disable-bt
also interne serielle Schnittstelle ein und Bluetooth deaktiveren das der die serielle nicht belegt.
Bitte aufpassen, dass du den Adapter nicht auf den Raspi drückst, vielleicht mit Klebeband unten etwas abkleben damit es zu keinem Kurzschluss kommen kann. Wir liefern die RPI mit einem Abstandhalter aus, welcher in das Loch am Adapter gesteckt wird. Kannst vielleicht auch eine M3 Kunstoffschraube im Loch befestigen.
LG
Hallo Reinhart,
super für die Beobachtung. Ich hab den blauen Jumper entfernt und nun klappt es. Ich hab nur den Bereich der Anleitung Raspi geschaut und nicht den vom Ehternet. Dann wäre mir das aufgefallen.
Vielen lieben Dank auch für Euren tollen Einsatz. Ich werde jetzt mal weiter testen und basteln.
... deshalb ist ein Foto immer besser weil man sich ein besseres Bild machen kann.
Wenn du keinen Abstandhalter hast, dann nimm einfach eine Plastikschraube mit zwei Muttern.
Freut mich das dein Adapter nun funktioniert!
LG
hier mal ein Beispiel wie man einfache Graphen mit DOIF in Fhem realisieren kann.
define di_Vorlauf DOIF ##
{package ui_Table;;}
card([Vorlauf:Vorlauf:col12],"Vorlauf","temp_outside",20,60,undef,undef,"°C",\&temp_hue,undef,180)|
card([VorlaufSoll:VorlaufSoll:col12],"VorlaufSoll","temp_outside",20,60,undef,undef,"°C",\&temp_hue,undef,180)
card([Ruecklauf:Ruecklauf:col12],"Rücklauf","temp_outside",20,60,undef,undef,"°C",\&temp_hue,undef,180)|
card([HMS100T_9163:temperature:col12],"Vorlauf EG","temp_outside",20,60,undef,undef,"°C",\&temp_hue,undef,180)|
LG
Inbetriebnahme esera Bus-Adapter (USB)
Hallo,
ich wurde aus einer anderen Diskussion auf diese hier verwiesen. Aber ich habe das Fertigprodukt von esera (https://www.esera.de/produkte/ebus/135/1-wire-hub-platine?c=20) und nicht das Selbstbauprojekt. Nach Installation vom ebusd sehe ich Werte:
pi@pi4:/usr/bin $ ebusctl info
version: ebusd 21.3.v21.3
update check: OK
device: /dev/ttyUSB0
signal: acquired
symbol rate: 23
max symbol rate: 277
min arbitration micros: 1516
max arbitration micros: 1516
min symbol latency: 5
max symbol latency: 6
reconnects: 1
masters: 3
messages: 643
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0407;HW=7603", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=72000;SW=0122;HW=7703", loaded "vaillant/15.720.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
pi@pi4:/usr/bin $ ebusctl scan
done
pi@pi4:/usr/bin $ ebusctl r -f HcHours
706
Allerdings wundere ich mich, das ich bei "ebusctl find" fast nur "no data storred" als Antwort bekomme, da haben mir auch die 370 Beiträge dieser Diskussion nicht weitergeholfen. Letztendlich möchte ich so eine Anzeige wie von Reinhard in Beitrag 10 bzw. 368 gezeigt auch für meine Theme nutzen.
Die Seite https://wiki.fhem.de/wiki/EBUS-MQTT2 zeigt ja viele Schritte an, aber bei mir tauchen viele Fragen dazu auf:
- ist mqtt notwendig oder nur Option um so eine anzeige wie von Reinhard zu bekommen? (FHEM läuft)
- Zitat: "Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen."
also die reale IP (192.168.xxx.xxx) oder geht auch localhost bzw. 127.0.0.1? Weil die reale IP könnte sich ja ändern...
- "mit erweiterten JSON-Optionen erstellen wollen" Was ist JSON? Ich kenne das nur als NAS-bezogenen Begriff, was hat das hier zu suchen?
- "müssen entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden." = Bahnhof...
- "FHEM-Interner Server. Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert." Also in der FHEM-Befehlszeile eingeben?
- "dass die CID dem Basispfad des Topic-trees entspricht" = CID??? Topic-Tree????
- "Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:" (das Bild darunter): Einfach Eintippen? Wo? Das Bild zeigt jedenfalls nicht eine FHEM-Standart-Installation - die ist gelb-grün...
- "Zur Kontrolle bitte prüfen ob hier auch die ,,bridgeRegexp" vom Template richtig gesetzt wurde." Das folgende Bild sowie die Codezeile darunter ergeben für mich keinen Zusammenhang. Wofür sind die 3 Zeilen? Was soll damit passieren?
- " IO-Device" - mir schwirrt der Kopf, vielleicht habe ich den roten Faden verloren, aber was ist jetzt IO-Device?
- "setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut ,,autocreate" auf ,,complex"." Das Bild darunter sieht FHEM-ähnlich aus, aber was soll es mir sagen?
- "Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden." Nur zur Sicherheit: In die Kommandozeile von FHEM eintippen (kopieren)?
- Ist das von Reinhard erwähnte Bild/Anzeige nach dieser Anleitung erstellt worden oder nach einer anderen Verfahrensweise?
- In Beitrag 10 (vom 7.2.2021) wird eine "Tabletui3" angesprochen.
Schon mal Danke für die Antworten..
Thomas
Zum Thema Visualisierung und Steuerung siehe:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Visualisierung_und_Steuerung:_Heiztherme
Im Anhang meine aktuelle Übersicht mit Raumtemperaturen ( https://wiki.fhem.de/wiki/DOIF/Automatisierung#Steuerung_von_Raumthermostaten_f.C3.BCr_mehrere_R.C3.A4ume_mit_GUI)
Zitat von: tho-mas am 12 Februar 2022, 18:34:22
Nach Installation vom ebusd sehe ich Werte:
(...)
Sehr schön, das sieht gut aus. Der Adapter scheint grundsätzlich schon mal zu laufen.
Zitat von: tho-mas am 12 Februar 2022, 18:34:22
Allerdings wundere ich mich, das ich bei "ebusctl find" fast nur "no data storred" als Antwort bekomme, da haben mir auch die 370 Beiträge dieser Diskussion nicht weitergeholfen.
Das liegt daran, dass in Deiner jetzigen Konfiguration der ebusd im wesentlichen nur den Bus belauscht. Die einzelnen Komponenten der Heizung tauschen Informationen aus, und ebusd liest das mit. Folglich kennt der ebus (erstmal) nur die Werte, die in diesen Informationen vorhanden waren.
Interessierst Du Dich für Werte, die dort nicht bereits enthalten waren, kannst Du sie vom ebusd aktiv über den Bus abfragen lassen. Entweder einmalig immer dann, wenn Du den Wert gerade brauchst, oder Du kannst auch ein "polling" einstellen, damit der ebusd für Dich interessante Werte von sich aus in einem bestimmten zeitlichen Raster selber abfragt. Dazu, und zur Problematik, wieviele Werte man wie oft abfragen lassen sollte, steht in diesem Thread schon viel.
Zum Rest Deiner Fragen kann ich nicht viel sagen, weil ich den ebusd gar nicht zusammen mit FHEM, sondern mit dem ioBroker verwende.
@tho-mas
Generell entspricht der Esera Adapter einem V1.x Adapter, aber die verschiedenen Visualisierungen in FHEM sind ja Adapter unabhängig.
Ich würde dir unbedingt empfehlen vorerst nicht MQTT (bzw. MQTT2) einzusetzen da dies 90% deiner Fragen betrifft und du dort noch unsicher bist. Nimm doch vorerst ECMD und gehe Schrittweise vor.
Also einen Wert in der Konsole abfragen, wenn das funktioniert taucht er erstens mit "find" auf und dann versuche das in ECMD einzubinden. Da brauchst du keinen MQTT2 Server oder Client zu definieren. Der eBus gibt dir von selbst nur Broadcast Meldungen, alles andere musst du erfragen.
Wenn dir das alles noch zu kompliziert ist, dann mach es doch mit GAEBUS, da kannst du alles per Mausklicks zusammen stellen und alle möglichen Messwerte tauchen in einer Liste auf und nehmen dir viel Arbeit ab.
Beispiel GAEBUS:
define ebus1 GAEBUS deine_IP:8888 240
das ist alles und gib das in der Befehlszeile ein, setze noch einen "room" damit das wieder findest.
Zitat von dir:
Allerdings wundere ich mich, das ich bei "ebusctl find" fast nur "no data storred" als Antwort bekomme, da haben mir auch die 370 Beiträge dieser Diskussion nicht weitergeholfen. Letztendlich möchte ich so eine Anzeige wie von Reinhard in Beitrag 10 bzw. 368 gezeigt auch für meine Theme nutzen.
hat dir chris371 schon beantwortet, ebusctl find listet dir eigentlich so nur die Broadcats auf, das sind eben jede Daten die automatisch vom eBus kommen.
Die Seite https://wiki.fhem.de/wiki/EBUS-MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2) zeigt ja viele Schritte an, aber bei mir tauchen viele Fragen dazu auf:
- ist mqtt notwendig oder nur Option um so eine anzeige wie von Reinhard zu bekommen? (FHEM läuft)
nein ist nicht notwendig, nur eine Option
- Zitat: "Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen."
also die reale IP (192.168.xxx.xxx) oder geht auch localhost bzw. 127.0.0.1? Weil die reale IP könnte sich ja ändern...
du kannst dein DHCP Adresse ja reservieren oder statisch machen.
- "mit erweiterten JSON-Optionen erstellen wollen" Was ist JSON? Ich kenne das nur als NAS-bezogenen Begriff, was hat das hier zu suchen?
JSON ist das Format wie das Telegram von MQTT ankommt.
- "müssen entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden." = Bahnhof...
gilt nur für MQTT
- "FHEM-Interner Server. Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert." Also in der FHEM-Befehlszeile eingeben?
Nein als define angeben
- "dass die CID dem Basispfad des Topic-trees entspricht" = CID??? Topic-Tree? ???
gilt nur für MQTT
- "Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:" (das Bild darunter): Einfach Eintippen? Wo? Das Bild zeigt jedenfalls nicht eine FHEM-Standart-Installation - die ist gelb-grün...
das Template aus dem Dropdownlistenfeld auswählen
- "Zur Kontrolle bitte prüfen ob hier auch die ,,bridgeRegexp" vom Template richtig gesetzt wurde." Das folgende Bild sowie die Codezeile darunter ergeben für mich keinen Zusammenhang. Wofür sind die 3 Zeilen? Was soll damit passieren?
gilt nur für MQTT und sollte definiert werden.
- " IO-Device" - mir schwirrt der Kopf, vielleicht habe ich den roten Faden verloren, aber was ist jetzt IO-Device?
- "setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut ,,autocreate" auf ,,complex"." Das Bild darunter sieht FHEM-ähnlich aus, aber was soll es mir sagen?
- "Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden." Nur zur Sicherheit: In die Kommandozeile von FHEM eintippen (kopieren)?
alles was an Beispielen ist kannst du in die Befehlszeile eingeben, eben definieren so wie bei allen Devices in Fhem die nicht automatisch angelegt werden.
- Ist das von Reinhard erwähnte Bild/Anzeige nach dieser Anleitung erstellt worden oder nach einer anderen Verfahrensweise?
- In Beitrag 10 (vom 7.2.2021) wird eine "Tabletui3" angesprochen.
das ist eine Möglichkeit zur Visualisierung für Tabletts oder Handy
@Reinhard,
danke für deine Antwort. Wegen der langen Arbeitszeit meinerseites werde ich die Infos erst im Laufe der Woche abarbeiten.
Thomas
Ich musste heute meine PI neu aufsetzen. Leider werden die Configfiles nicht geladen.
ebusctl info
version: ebusd 22.1.v22.1
update check: OK
device: /dev/ttyUSB0
signal: acquired
symbol rate: 23
max symbol rate: 151
min arbitration micros: 408
max arbitration micros: 649
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 3
messages: 3
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0614;HW=6903"
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--configpath=http://ebusd.eu/config/ -d /dev/ttyUSB0 -p 8888 --latency=0 --receivetimeout=100000 -l /var/log/ebusd.log --scanconfig=full --httpport=8889 --htmlpath=/var/ebusd/html"
EBUSD_OPTS="--scanconfig=full --configpath=/etc/ebusd/ -d /dev/ttyUSB0 -p 8888 --latency=0 --receivetimeout=100000 -l /var/log/ebusd.log --httpport=8889 --htmlpath=/var/www/"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Die Geräte werden anscheinend erkannt. Nur die Files nicht geladen.
Zitat von: Cihan am 26 Februar 2022, 15:29:50
Ich musste heute meine PI neu aufsetzen. Leider werden die Configfiles nicht geladen.
EBUSD_OPTS="--scanconfig=full --configpath=/etc/ebusd/ -d /dev/ttyUSB0 -p 8888 --latency=0 --receivetimeout=100000 -l /var/log/ebusd.log --httpport=8889 --htmlpath=/var/www/"
sind denn die files in /etc/ebusd/ ?
Hi,
da der letzte Beitrag schon recht lange her ist, bin ich mir nicht ganz sicher ob meine Frag hier nicht richtig ist ... aber erstmal so ... nen neuen Beitrag kann ich immer noch machen.
Ich bekomme meine Emus Adapter leider nicht wirklich zum laufen. Ich erhalte keine IP Adresse über LAN, und der Adapter geht scheinbar auch offline.
Ich habe auch schon versucht anstatt über DHCP über meinen Router eine IP zuzuweisen, klappt jedoch auch nicht.
Ich sehe die MAC Adresse des Adapters im Router und das war es.
Die faule LED leuchtet so wie im Wiki beschrieben. Jumper auch nochmal kontrolliert und neu gesetzt
Jemand eine Idee ?
Ich schnalle leider nicht wirklich wie ich über den Bootloader gehe und eine feste IP zuweisen kann.
Über jeden Tipp und jede Idee dankbar.
Grüße Und Danke
Totti
Zitat von: TottiToad am 23 September 2022, 16:22:25
Ich bekomme meine Emus Adapter leider nicht wirklich zum laufen. Ich erhalte keine IP Adresse über LAN, und der Adapter geht scheinbar auch offline.
Ich habe auch schon versucht anstatt über DHCP über meinen Router eine IP zuzuweisen, klappt jedoch auch nicht.
was sagt denn dein router, was der adapter für eine Adresse hat? Und was ist es für ein router?
Zitat von: TottiToad am 23 September 2022, 16:22:25
Die faule LED leuchtet so wie im Wiki beschrieben. Jumper auch nochmal kontrolliert und neu gesetzt
ich nehme an "blau" war gemeint?
Zitat von: TottiToad am 23 September 2022, 16:22:25
Ich schnalle leider nicht wirklich wie ich über den Bootloader gehe und eine feste IP zuweisen kann.
steht doch recht ausführlich hier beschreiben (https://adapter.ebusd.eu/picfirmware.html):
adapter stromlos machen, Aufsteckmodule entfernen, auf USB jumpern, an J11 Pins 3-4 verbinden, USB einstecken.
Dann ebuspicloader starten und mit entsprechenden Parametern IP Adress setzen.
mal ein lob an die gemeinde der autoren !
habe vor einem jahr die 3.0-platine bekommen und die ist im sommer halt rumgelegen - nona wer heizt schon im sommer ;-)
mich heute früh hingesetzt, am abend ist die vaillant ecotec und der 370er schon gesteuert.
2 stunden mit jumpern & flashen gespielt, neuesten ebusd zur sicherheit auch vom git, dann mal den ebusd-config-jungel bis das neueste repo drauf war (muss sagen, bin kein debian-fan, lebe eher mit fedora)
naja, von einer vanilla-debian-installation dauert es etwas, bis licht am ende des tunnels ist.
es ist abend, für rudimentäre fernsteuerung ist gescriptet genug ....
---
root@awdeb:~# ./VAItemp
13.11.2022 370 R Date
23:41:47 370 R Time
-2 - - seconds deviation
21.81 370 R DisplayedRoomTemp
Vorlauftemperatur;Rücklauftemperatur;Aussentemperatur;;WWTemperatur;SpeichertemperaturPumpenstatus;;;;;
31.0;31.0;-;19.5;20.5;off bai R Status01
Betriebsart;Maximaltemperatur;ReglerCurrentTemp;Maximaltemperatur;ReglerCurrentTemp
auto;60;75.0;70;65.0 bai R Status02
10.00 370 R ActualRoomTempDesiredHc1
10.0 370 R DisplayedHc1RoomTempDesired
0.0 370 R Hc1ActualFlowTempDesired
0.00 bai R FlowTempDesired
31.19;ok bai R FlowTemp
1.736;ok bai R WaterPressure
root@awdeb:~# ./VAItemp 15
13.11.2022 370 R Date
23:41:47 370 R Time
-21 - - seconds deviation
21.81 370 R DisplayedRoomTemp
Vorlauftemperatur;Rücklauftemperatur;Aussentemperatur;;WWTemperatur;SpeichertemperaturPumpenstatus;;;;;
31.0;31.0;-;19.5;20.5;off bai R Status01
Betriebsart;Maximaltemperatur;ReglerCurrentTemp;Maximaltemperatur;ReglerCurrentTemp
auto;60;75.0;70;65.0 bai R Status02
10.00 370 R ActualRoomTempDesiredHc1
10.0 370 R DisplayedHc1RoomTempDesired
15.00 370 W Hc1DayTemp
15.00 370 W Hc1NightTemp
10.00 370 R ActualRoomTempDesiredHc1
10.0 370 R DisplayedHc1RoomTempDesired
0.0 370 R Hc1ActualFlowTempDesired
0.00 bai R FlowTempDesired
31.19;ok bai R FlowTemp
1.736;ok bai R WaterPressure
root@awdeb:~#
(bei änderungen des setpoints f. tag- und nachttemperatur gibt es offensichtlich eine latenzzeit. ;-) ev. weiss ja wer wie/wo das im vaillant-imperium managbar ist)
---
ein bisschen arbeit ist wohl noch notwendig, den schmalen grat des explorierens all dieser wahnsinnig vielen und wenig dokumentierten werte zu gehen, sodass einigermassen anspruchsvolles herauskommt, die heizungssteuerung aber nicht bei zuviel forschergeist gebrickt wird ;-)
eine zweite vaillant, diesmal mit mischer etc. wird nächste woche angegangen
danke an all die ebusd-menschen und -macher und supporter und und und, die diesen moloch ebus-protocol halbwegs bezähmt haben !!! danke.
Hallo zusammen,
Vielleicht eine triviale Frage, aber trotzdem.
Leider finde ich keine passende Info zu Home Assistant und muss mein Weg selber tun.
Ich habe mein eBUSd vorkonfiguriert und zeigt er mir ständig:
2022-11-24 16:35:24.383 [network info] [05898] client connection opened 172.30.32.2
2022-11-24 16:37:24.392 [network info] [05899] connection closedIst ja positiv, oder?
Läuft bei mir auch mein Mosquitto Broker. Er hat sogar mein Adapter erkannt (?).
Er sagt
Device info: ebusd.eu
Firmware: 22.4
Und zeigt 5 Signale die Ständig aktualisiert sind: Running, Scan, Signal, Updatecheck und Uptime.
- Kann ich davon ausgehen, dass der Adapter richtig installiert ist?
- Das bedeutet, dass ich nur die Konfiguration für meine Wolf-Lüftung benötige?
Zitat von: eldarmusin am 24 November 2022, 17:29:57
Ich habe mein eBUSd vorkonfiguriert und zeigt er mir ständig:
2022-11-24 16:35:24.383 [network info] [05898] client connection opened 172.30.32.2
2022-11-24 16:37:24.392 [network info] [05899] connection closed
das zeigt nur, dass die Verbindung von einem client zu ebusd klappt, z.B. wenn ebusctl verwendet wird.
Zitat von: eldarmusin am 24 November 2022, 17:29:57
Device info: ebusd.eu
Firmware: 22.4
Und zeigt 5 Signale die Ständig aktualisiert sind: Running, Scan, Signal, Updatecheck und Uptime.
das zeigt nur, dass MQTT auch so weit richtig konfiguriert ist.
Zitat von: eldarmusin am 24 November 2022, 17:29:57
Kann ich davon ausgehen, dass der Adapter richtig installiert ist?
"richtig installiert" ist hier ein weitläufiger Begriff. Entscheidend ist, ob ebusd auch signal: acquired reportet, erst dann kannst Du mit Geräten am Bus kommunizieren.
Zitat von: eldarmusin am 24 November 2022, 17:29:57
Das bedeutet, dass ich nur die Konfiguration für meine Wolf-Lüftung benötige?
die brauchst Du auf jeden Fall
Hallo, danke für dein Input.
Zitat von: john30 am 26 November 2022, 08:28:00
"richtig installiert" ist hier ein weitläufiger Begriff. Entscheidend ist, ob ebusd auch signal: acquired reportet, erst dann kannst Du mit Geräten am Bus kommunizieren.
Also, habe ich gemeint dass HA und eBUS Adapter miteinander kommunizieren. Anderes gesagt, HW-Verbindung vorhanden ist.
Brauche ich schlussendlich "nur" die richtige Konfiguration aufspielen.
Wenn das wirklich so ist, dann gehe ich "weiter spielen"
Da sich beim Raspberry Pi OS (früher: Raspbian) wieder einmal etwas bei der Zuordnung der UARTs geändert hat, gibt es auch in Bezug auf den eBUS Adapter neue Erkenntnisse.
Das betrifft vor allem Benutzer des Raspberry Pi 3, der zwar zwei UARTs besitzt, aber davon nur einen vollwertigen.
Hier kann es bei Benutzung des Enhanced Protokolls und der Wahl des falschen UARTs zu Problemen kommen.
Genaueres findet sich in der aktualisierten Doku: https://adapter.ebusd.eu/raspberrypi.html (https://adapter.ebusd.eu/raspberrypi.html)
LG Eduard
Hallo eBus Adapter Gemeinde,
ich habe letzte Woche einen eBUS Adapter 3 erhalten.
Version direkt auf den RPI aufsteckbar (Pin 1 ... )
So habe ich mich gestern auf den Weg gemacht den Adapter in Betrieb zunehmen - leider ohne Erfolg.
PI Version: Raspberry Pi 3 Model B Rev 1.2
Durchgeführte Schritte (hier in den letzten Minuten zur Dokumentation nochmals durchgeührt):
a.) eBUS Adapter 3 auf den PI gesteckt - eBus Adapter LED Grün und Gelb leuchten, LED Blau blinkt alle ca. 4 Sec.
b.) In config.txt
folgendes aufgenommen:
# set serial0 to ttyAMA0 statt ttyS0
dtoverlay=pi3-miniuart-bt
folgendes geprüft
enable_uart=1
c.) in raspi-config in serial
shell disable --> No
serial port HW enabled --> Yes
--> Ergebnis nach boot mit dmesg|grep ttyAMA0:
[ 2.937934] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 114, base_baud = 0) is a PL011 rev2
d.) ebus V23.1 debian package installiert.
e.) in /etc/default/ebusd folgende Konfiguration eingetragen:
EBUSD_OPTS="--scanconfig -d ens:/dev/ttyAMA0 --latency=50"
f.) den ebus service gestartet ( sudo service ebusd start ) gestartet:
--> /var/log/ebusd.log
---
2023-01-08 17:07:01.934 [main notice] ebusd 23.1.23.1 started with auto scan on enhanced device /dev/ttyAMA0
2023-01-08 17:07:02.377 [bus error] unable to open /dev/ttyAMA0: ERR: generic device error
2023-01-08 17:07:02.378 [bus notice] bus started with own address ff/04
2023-01-08 17:07:02.378 [bus notice] device invalid
2023-01-08 17:07:07.378 [bus error] unable to open /dev/ttyAMA0: ERR: generic device error
2023-01-08 17:07:07.379 [bus notice] device invalid
2023-01-08 17:07:12.379 [bus error] unable to open /dev/ttyAMA0: ERR: generic device error
2023-01-08 17:07:12.379 [bus notice] device invalid
2023-01-08 17:07:17.379 [bus error] unable to open /dev/ttyAMA0: ERR: generic device error
2023-01-08 17:07:17.380 [bus notice] device invalid
---
Was habe ich sonst getan/versucht/beobachtet:
pi@raspberrypi:~ $ ebuspicloader /dev/ttyAMA0
unable to lock /dev/ttyAMA0
pi@raspberrypi:~ $ ebuspicloader /dev/ttyUSB0
unable to opened /dev/ttyUSB0
Starten des eBus mit (statt als service):
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyAMA0
Ergbnis gleich:
2023-01-08 17:13:11.492 [bus error] unable to open /dev/ttyAMA0: ERR: generic device error
2023-01-08 17:13:11.492 [bus notice] bus started with own address 31/36
2023-01-08 17:13:11.493 [bus notice] device invalid
eBus selbst nicht angeklemmt.
Versuchweise habe ich einmal angeklemmt. EBus Adapter Board (LED grün blinkt, gelb an, Blau war glaube unverändert alle 4 sec blink
Verhaten ebusd.log unverändert.
Wo liegt meine Fehler?
Frank
Zitatc.) in raspi-config in serial
shell disable --> No
serial port HW enabled --> Yes
Die shell sollte doch eigentlich disabled sein, also "shell disable -->Yes" ?
Zitat von: john30 am 26 November 2022, 08:28:00
Entscheidend ist, ob ebusd auch signal: acquired reportet, erst dann kannst Du mit Geräten am Bus kommunizieren.
Laut Logs, habe ich was, siehe Bild, oder?
Zitat von: john30 am 26 November 2022, 08:28:00
die brauchst Du auf jeden Fall
Wenn Auto Scan nicht geht, wie kann ich das sonst tun?
Forcieren? Manuell eintragen?
Meine HA Installation scheint in einem Docker zu sein, da ich kein eBUSd weder Parameterfiles sehe. Wie kann ich das weitermachen?
Danke im Voraus
Zitat von: eldarmusin am 09 Januar 2023, 16:40:02
Laut Logs, habe ich was, siehe Bild, oder?
Ja, sieht gut aus.
Zitat von: eldarmusin am 09 Januar 2023, 16:40:02
Wenn Auto Scan nicht geht, wie kann ich das sonst tun?
Forcieren? Manuell eintragen?
Das --readonly weglassen.
Wenn sich im letzten Jahr da nichts wesentliches geändert hat, macht --scanconfig zusammen mit --readonly kaum einen Sinn, siehe ggf. hier (https://forum.fhem.de/index.php/topic,118143.msg1185357.html#msg1185357).
Du kannst auch statisch konfigurieren (d.h. --scanconfig weglassen), aber davon würde ich vorerst abraten, solange Du nicht genau weißt, welche config-files Du für speziell Deine Anlage brauchst.
Zitat von: eldarmusin am 09 Januar 2023, 16:40:02
Meine HA Installation scheint in einem Docker zu sein, da ich kein eBUSd weder Parameterfiles sehe. Wie kann ich das weitermachen?
Ich fürchte ich verstehe die Frage nicht. Du warst doch offenbar in der Lage den ebusd zu starten...
Zitat von: galileo am 09 Januar 2023, 16:15:29
Die shell sollte doch eigentlich disabled sein, also "shell disable -->Yes" ?
Um die shell zu disablen muss in der raspi-config folgende Frage verneint werden, damit diese disabled ist.
"Would you like a login shell to be accessible over serial?"
Ergebnis ist dann: "The serial login shell is disabled"
Habs gerade sicherheitshalber am PI geprüft.
Hi Chris,
danke für deine Unterstützung.
Zitat von: chris371 am 09 Januar 2023, 18:28:38
Wenn sich im letzten Jahr da nichts wesentliches geändert hat, macht --scanconfig zusammen mit --readonly kaum einen Sinn, siehe ggf. hier (https://forum.fhem.de/index.php/topic,118143.msg1185357.html#msg1185357).
Ich habe es noch mal durchgeführt, Full Log ist anbei. Hier zitiere ich nur was ich relevant finde.
s6-rc: info: service legacy-services successfully started
> ebusd --foreground --mqtthost=core-mosquitto --mqttport=1883 --mqttuser=addons --mqttpass=xxx --scanconfig --mqttjson --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqtttopic=ebusd --device=/dev/ttyUSB1 --log=all:debug --log=main:debug --log=bus:debug --log=update:debug --log=network:debug --log=other:debug
2023-01-09 21:27:27.157 [main notice] ebusd 23.1.p20230106 started with auto scan on device /dev/ttyUSB1
2023-01-09 21:27:27.157 [main info] loading configuration files from https://cfg.ebusd.eu/
[...]
2023-01-09 21:27:28.342 [main info] read config files, got 11 messages
2023-01-09 21:27:28.347 [bus notice] bus started with own address 31/36
[...]
2023-01-09 21:27:28.353 [mqtt debug] connection requested
2023-01-09 21:27:28.353 [main info] registered data handlers
2023-01-09 21:27:28.389 [bus notice] signal acquired
2023-01-09 21:27:28.835 [mqtt notice] connection established
2023-01-09 21:27:28.835 [mqtt debug] publish ebusd/global/version "ebusd 23.1.p20230106"
2023-01-09 21:27:28.835 [mqtt debug] publish ebusd/global/running true
2023-01-09 21:27:38.354 [mqtt debug] publish ebusd/global/scan "finished"
2023-01-09 21:27:44.366 [mqtt debug] publish ebusd/global/uptime 16
[...]
2023-01-09 21:28:48.462 [mqtt debug] publish ebusd/global/uptime 80
2023-01-09 21:28:51.857 [network info] [00001] connection closed
2023-01-09 21:28:51.858 [network info] [00001] client connection opened 172.30.32.2
2023-01-09 21:28:52.859 [network debug] dead connection removed - 0
Zitat von: chris371 am 09 Januar 2023, 18:28:38
Ich fürchte ich verstehe die Frage nicht. Du warst doch offenbar in der Lage den ebusd zu starten...
Ich meine, dass ich mit SSH im Bash, kein eBUSd finde, keine Konfigdatei, kein ebusctl...
Zur Info.
Ich habe eine Wolf CWL-F-150 und ein Bedienmodul BM-2 die mittels eBUS richtig kommunizieren.
Adapter v3.0
Raspberry Pi 4 mit Home Assistant drauf.
MQQT holt nur die Boardstatus info (? uptime, version, etc.), nichts anderes.
Hättest du noch Ideen was ich tun kann?
Vielleicht gibts kein Konfig-Datei dafür und muss ich den eBus untersuchen?
Moin,
ich habe Anfang der Woche meinen 3.0 USB Adapter bekommen.
Dieser soll einen älteren v2 ersetzen.
Also fix den Raspi 3 neu aufgesetzt mit bullseye und den Adapter per USB ran.
eBus dran und los. So weit so gut.
Allerdings finde ich nun meine Wärmepumpe (08.hmu) nicht mehr auf dem Bus. Mit dem alten Adapter läuft alles.
Dafür taucht eine ec SOL auf. Besitze allerdings keine Solarstation.
Meine Anlage besteht aus der Wärmepumpe (Vaillant flexoTherm exclusive), 2 Außeneinheiten, einer Frischwasserstation, VR71 und VRC700.
EBUSD_OPTS="--scanconfig=full --accesslevel=* -d ens:/dev/ttyUSB0 --latency=20 --httpport=8080"
pi@ebuspi:~ $ ebusctl scan result
05;Vaillant;VR921;2706;5703
0a;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
12;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
15;Vaillant;70000;0614;6903;21;20;11;0020266797;0082;017405;N5
26;Vaillant;VR_71;0104;0503;21;19;25;0020184846;0082;007468;N3
e0;Vaillant;OMU00;0131;5202;21;19;15;0010016715;0001;005937;N6
e1;Vaillant;OMU00;0131;5202;21;19;15;0010016715;0001;005933;N2
ec;Vaillant;SOL00;0614;6903;21;20;11;0020266797;0082;017405;N5
fc;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
pi@ebuspi:~ $ ebusctl info
version: ebusd 23.1.23.1
update check: OK
device: /dev/ttyUSB0, enhanced, firmware 1.1[8419].2[847f]
access: *
signal: acquired
symbol rate: 23
max symbol rate: 130
min arbitration micros: 388
max arbitration micros: 491
min symbol latency: 7
max symbol latency: 8
reconnects: 0
masters: 4
messages: 887
conditional: 113
poll: 1
update: 8
address 00: master #1
address 05: slave #1, scanned "MF=Vaillant;ID=VR921;SW=2706;HW=5703"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"
address e1: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e1.omu.1.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0614;HW=6903", loaded "vaillant/ec.sol.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
Hat hier jemand einen Tipp, wo ich ansetzen kann?
Danke & Gruß
Edit:
Hab nochmal den alten Adapter v2.? aufgesteckt. Hier die Ergebnisse:
EBUSD_OPTS="--scanconfig=full -d /dev/ttyebus --httpport=8080 --latency=20 --accesslevel=*"
pi@ebuspi:~ $ ebusctl scan result
05;Vaillant;VR921;2706;5703;21;22;39;0020260962;0938;072166;N4
08;Vaillant;HMU00;0307;0403;21;19;13;0010016423;0001;005097;N9
0a;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
15;Vaillant;70000;0614;6903;21;20;11;0020266797;0082;017405;N5
26;Vaillant;VR_71;0104;0503;21;19;25;0020184846;0082;007468;N3
76;Vaillant;VWZ00;0307;0403
e0;Vaillant;OMU00;0131;5202;21;19;15;0010016715;0001;005937;N6
e1;Vaillant;OMU00;0131;5202;21;19;15;0010016715;0001;005933;N2
fc;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
pi@ebuspi:~ $ ebusctl info
version: ebusd 23.1.23.1
device: /dev/ttyebus
access: *
signal: acquired
symbol rate: 66
max symbol rate: 197
min arbitration micros: 1
max arbitration micros: 8
min symbol latency: 4
max symbol latency: 6
reconnects: 0
masters: 6
messages: 861
conditional: 113
poll: 0
update: 10
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=VR921;SW=2706;HW=5703"
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"
address e1: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e1.omu.1.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
Hallo zusammen,
mein ebus Adapter ist letztens gekommen und ich bin noch in der absoluten Anfängerphase d.h. ich habe meine Lüftung Vaillant Recovair 275/350 und WP Ochsner GMDW 13 plus angeschlossen. Durch viel suchen und try und error habe ich dir Datei c0.wtw04.csv gebastelt und zumindest aus der Lüftung ein paar sinnvolle Werte lesen können und vermute das sich hier im Forum das größte Schwarm wissen verbirgt. Es laufen aber noch ganz viele weitere Meldungen im Log auf wo mir der Ansatz für eine passende csv fehlt oder wie da die folgenden Schritte sind.
Hat vielleicht jemand funktionierende csv´s für die Ochsner WP und kann diese zur Verfügung stellen?
version: ebusd 23.1.23.1
device: 10.41.1.103:9999, enhanced, firmware 1.1[8419].2[847f]
access: *
signal: acquired
symbol rate: 87
max symbol rate: 130
min arbitration micros: 3
max arbitration micros: 98
min symbol latency: 7
max symbol latency: 8
reconnects: 0
masters: 6
messages: 159
conditional: 0
poll: 0
update: 4
address 00: master #1
address 01: master #6
address 03: master #11
address 04: slave #25, ebusd
address 06: slave #6, scanned "MF=TEM;ID=MB61;SW=0044;HW=0000"
address 07: master #16
address 08: slave #11, scanned "MF=TEM;ID=WE_1 ;SW=3632;HW=3030"
address 0c: slave #16, scanning
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=VAI00;SW=0124;HW=8901", loaded "vaillant/15.vai00.csv"
address c0: slave, scanned "MF=Vaillant;ID=WTW04;SW=0127;HW=9001", loaded "vaillant/c0.wtw04.csv"
address ff: master #25, ebusd
2023-02-18 16:24:11.069 [update notice] received unknown MS cmd: 10c0b50903290e00 / 030e0000
2023-02-18 16:24:11.343 [update info] received MS cmd: 10c0b50903290900 / 03090000
2023-02-18 16:24:11.343 [update notice] received unknown MS cmd: 10c0b50903290900 / 03090000
2023-02-18 16:24:11.659 [update info] received MS cmd: 10c0b503020001 / 0affffffffffffffffffff
2023-02-18 16:24:11.659 [update notice] received unknown MS cmd: 10c0b503020001 / 0affffffffffffffffffff
2023-02-18 16:24:11.894 [bus debug] ERR: SYN received during receive response, switching to ready
2023-02-18 16:24:12.027 [update info] received MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:12.027 [update notice] received unknown MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:12.124 [bus debug] ERR: SYN received during receive response, switching to ready
2023-02-18 16:24:12.396 [bus error] device status: eBUS comm error: framing
2023-02-18 16:24:12.527 [update info] received MS cmd: 10c0b509040e0a0001 / 00
2023-02-18 16:24:12.528 [update notice] received write wtw04 Waermerueckgewinnung QQ=10: EIN
2023-02-18 16:24:12.692 [update info] received BC cmd: 10fe050d0a00c4c4009b9b9b9b9b9b
2023-02-18 16:24:12.692 [update notice] received unknown BC cmd: 10fe050d0a00c4c4009b9b9b9b9b9b
2023-02-18 16:24:12.968 [update info] received MS cmd: 10c0b509060e0000780100 / 00
2023-02-18 16:24:12.969 [update notice] received write wtw04 Roomtemp QQ=10: 23.50
2023-02-18 16:24:13.300 [update info] received MS cmd: 10c0b50903294d00 / 044d00a551
2023-02-18 16:24:13.301 [update notice] received read wtw04 Ertrag_Gesamt_kWh QQ=10: 20901
2023-02-18 16:24:13.456 [update info] received BC cmd: 10fe080208000000320000001e
2023-02-18 16:24:13.456 [update notice] received unknown BC cmd: 10fe080208000000320000001e
2023-02-18 16:24:13.599 [update info] received MS cmd: 10c0b50903290f00 / 030f0000
2023-02-18 16:24:13.599 [update notice] received unknown MS cmd: 10c0b50903290f00 / 030f0000
2023-02-18 16:24:13.915 [update info] received MS cmd: 10c0b503020002 / 0affffffffffffffffffff
2023-02-18 16:24:13.916 [update notice] received unknown MS cmd: 10c0b503020002 / 0affffffffffffffffffff
2023-02-18 16:24:14.154 [bus debug] ERR: SYN received during receive command, switching to ready
2023-02-18 16:24:14.242 [update info] received MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:14.242 [update notice] received unknown MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:14.252 [mqtt debug] publish ebusd/wtw04/Roomtemp {
"temp": {"value": 23.50}}
2023-02-18 16:24:14.252 [mqtt debug] publish ebusd/wtw04/Waermerueckgewinnung {
"0": {"name": "", "value": "EIN"}}
2023-02-18 16:24:14.319 [update info] received MM cmd: 031005030a01000000471dff3f0000
2023-02-18 16:24:14.319 [update notice] received unknown MM cmd: 031005030a01000000471dff3f0000
2023-02-18 16:24:14.389 [bus error] device status: eBUS comm error: framing
2023-02-18 16:24:14.530 [update info] received MM cmd: 031005030a01000000471dff3f0000
2023-02-18 16:24:14.530 [update notice] received unknown MM cmd: 031005030a01000000471dff3f0000
2023-02-18 16:24:14.652 [update info] received MS cmd: 10c0b509040e0a0001 / 00
2023-02-18 16:24:14.653 [update notice] received write wtw04 Waermerueckgewinnung QQ=10: EIN
2023-02-18 16:24:15.021 [update info] received MS cmd: 10c0b509060e0000780100 / 00
2023-02-18 16:24:15.022 [update notice] received write wtw04 Roomtemp QQ=10: 23.50
2023-02-18 16:24:15.297 [update info] received MS cmd: 10c0b50903290e00 / 030e0000
2023-02-18 16:24:15.297 [update notice] received unknown MS cmd: 10c0b50903290e00 / 030e0000
2023-02-18 16:24:15.387 [bus error] device status: eBUS comm error: framing
2023-02-18 16:24:15.579 [update info] received MS cmd: 10c0b50903290900 / 03090000
2023-02-18 16:24:15.579 [update notice] received unknown MS cmd: 10c0b50903290900 / 03090000
2023-02-18 16:24:16.077 [update info] received MS cmd: 10c0b503020001 / 0affffffffffffffffffff
2023-02-18 16:24:16.077 [update notice] received unknown MS cmd: 10c0b503020001 / 0affffffffffffffffffff
2023-02-18 16:24:16.353 [update info] received MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:16.353 [update notice] received unknown MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:16.622 [update info] received MS cmd: 10c0b509040e0a0001 / 00
2023-02-18 16:24:16.622 [update notice] received write wtw04 Waermerueckgewinnung QQ=10: EIN
2023-02-18 16:24:16.991 [update info] received MS cmd: 10c0b509060e0000780100 / 00
2023-02-18 16:24:16.991 [update notice] received write wtw04 Roomtemp QQ=10: 23.50
2023-02-18 16:24:17.273 [update info] received MS cmd: 10c0b50903294d00 / 044d00a551
2023-02-18 16:24:17.273 [update notice] received read wtw04 Ertrag_Gesamt_kWh QQ=10: 20901
2023-02-18 16:24:17.551 [update info] received MS cmd: 10c0b50903290f00 / 030f0000
2023-02-18 16:24:17.551 [update notice] received unknown MS cmd: 10c0b50903290f00 / 030f0000
2023-02-18 16:24:17.867 [update info] received MS cmd: 10c0b503020002 / 0affffffffffffffffffff
2023-02-18 16:24:17.867 [update notice] received unknown MS cmd: 10c0b503020002 / 0affffffffffffffffffff
2023-02-18 16:24:18.041 [bus debug] ERR: SYN received during receive response, switching to ready
2023-02-18 16:24:18.226 [bus debug] ERR: SYN received during receive response, switching to ready
2023-02-18 16:24:18.378 [bus error] device status: eBUS comm error: framing
2023-02-18 16:24:18.407 [update info] received MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:18.407 [update notice] received unknown MS cmd: 10c0b509050e15000d02 / 00
2023-02-18 16:24:18.675 [update info] received MS cmd: 10c0b509040e0a0001 / 00
2023-02-18 16:24:18.676 [update notice] received write wtw04 Waermerueckgewinnung QQ=10: EIN
2023-02-18 16:24:18.847 [main debug] performing regular tasks
2023-02-18 16:24:18.847 [bus info] scan 05 cmd: ff05070400
2023-02-18 16:24:18.864 [bus debug] start request ff
2023-02-18 16:24:18.864 [bus debug] arbitration start with ff
2023-02-18 16:24:18.954 [update info] received MS cmd: 10c0b509060e0000780100 / 00
2023-02-18 16:24:18.955 [update notice] received write wtw04 Roomtemp QQ=10: 23.50
2023-02-18 16:24:18.963 [bus debug] arbitration won
2023-02-18 16:24:18.963 [bus debug] arbitration delay 9 micros
2023-02-18 16:24:18.963 [bus debug] switching from ready to send command
2023-02-18 16:24:18.971 [bus debug] send/receive symbol latency 7 ms
2023-02-18 16:24:18.979 [bus debug] send/receive symbol latency 7 ms
2023-02-18 16:24:18.987 [bus debug] send/receive symbol latency 7 ms
2023-02-18 16:24:18.995 [bus debug] send/receive symbol latency 7 ms
2023-02-18 16:24:18.995 [bus debug] switching from send command to send command CRC
2023-02-18 16:24:19.003 [bus debug] send/receive symbol latency 7 ms
2023-02-18 16:24:19.004 [bus debug] switching from send command CRC to receive command ACK
2023-02-18 16:24:19.049 [bus debug] notify request: ERR: SYN received
2023-02-18 16:24:19.049 [bus debug] ERR: SYN received during receive command ACK, switching to ready
2023-02-18 16:24:19.050 [main error] scan config 05: ERR: read timeout
2023-02-18 16:24:19.050 [mqtt debug] publish ebusd/global/scan "running"
Danke und Gruß
Frank
Zitat von: Hendrik-HOB am 21 Januar 2023, 01:34:17
Allerdings finde ich nun meine Wärmepumpe (08.hmu) nicht mehr auf dem Bus. Mit dem alten Adapter läuft alles.
Dafür taucht eine ec SOL auf. Besitze allerdings keine Solarstation.
das könnte am Timing bei der Arbitrierung liegen. Schau mal, ob im Log was zu scan der 08 steht.
die EC ist m.W. immer da, sobald man irgendeine andere Komponente in der Richtung hat. Aber auch da einfach mal schauen, wie der Scan läuft.
Ich versuche schon seit einiger Zeit meinen ebus-Adapter (mit Ethernet) zum Leben zu erwecken, leider ohne Erfolg. Hoffentlich kann mir jemand dabei helfen.
Konfiguration:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20 -d enh:192.168.1.30:9999 --address=ff"
Log:
2023-02-27 16:17:19.050 [main notice] ebusd 23.1.23.1 started with auto scan on enhanced device 192.168.1.30:9999
2023-02-27 16:17:20.033 [bus error] unable to open 192.168.1.30:9999: ERR: generic I/O error
2023-02-27 16:17:20.034 [bus notice] bus started with own address ff/04
2023-02-27 16:17:20.034 [bus notice] device invalid
version: ebusd 23.1.23.1
update check: OK
device: 192.168.1.30:9999, enhanced, invalid
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
Der Adapter ist mit der neuesten Firmware ausgestattet.
Am Adapter selbst blinkt die blaue LED 3x in Intervallen.
Zitat von: dave_dvb am 27 Februar 2023, 16:42:31
Ich versuche schon seit einiger Zeit meinen ebus-Adapter (mit Ethernet) zum Leben zu erwecken, leider ohne Erfolg. Hoffentlich kann mir jemand dabei helfen.
Stimmt denn die IP-Adresse? Funktioniert ein Ping?
Ich habe selbst zwar keine Version mit Ethernet, habe aber mitbekommen, dass es diesbezüglich Unterschiede zwischen den Versionen 3.0 und 3.1 des Adapters gibt. Siehe ggf.
https://adapter.ebusd.eu/#ethernet (aktuell) für V3.1 vs.
https://adapter.ebusd.eu/v30/#ethernet für V3.0
Zitat von: dave_dvb am 27 Februar 2023, 16:42:31
Konfiguration:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20 -d enh:192.168.1.30:9999 --address=ff"
Wenn Du die neueste Hardware und die neueste Firmware hast, muss man glaube ich "ens" statt "enh" zur Protokollauswahl nehmen.
Ansonsten deutet die Fehlermeldung ja darauf hin, dass ebusd bereits am Aufbauen der Netzwerk-Verbindung zur angegebenen IP-Adresse+Port scheitert. An der Stelle ist das Protokoll wohl noch egal, d.h. da ist noch was anderes im Argen.
Die IP-Adresse ist korrekt; die Durchführung eines Pings ist erfolgreich.
Mein eigener Verdacht wäre auch dass der Port 9999 geschlossen ist, aber in einem lokalen Netzwerk wüsste ich nicht wie?
ZitatIch versuche schon seit einiger Zeit meinen ebus-Adapter (mit Ethernet) zum Leben zu erwecken, leider ohne Erfolg. Hoffentlich kann mir jemand dabei helfen.
Wenn das ein 3.1 Adapter ist, dann gilt folgendes:
Es muss "ens:" und nicht "enh:" spezifiziert werden.
Am J12 muss(!!) Pin 5-6 gesetzt sein, das bringt den USR-ES1 erst zu Leben.
Am J12 sollte Pin 1-2 gesetzt sein, das selektiert das Enhanced Protokoll.
Mit diesen Einstellungen solltest du beim Einschalten die orange LED am USR-ES1 flackern sehen (das ist die Ethernet Negotiation). Wenn das nicht ist dann gibt es mit der Verbindung ein Problem. Leider kann man auch nicht ganz ausschließen dass der USR-ES1 ein Problem hat, es sind vereinzelt auch schon welche mit kalten Lötstellen aufgetaucht.
Sollte das alles nichts helfen, dann melde dich bitte per PN bei mir.
LG Eduard
Es handelt sich um einen Adapter der Version 3.0 mit der Firmware-Version 20221231. Allerdings funktionierte er auch nicht mit einer älteren Firmware-Version.
Die Pinbelegung J12 ist wie beschrieben (1-2 & 5-6)
Ich werde die LED nochmals überprüfen
Status-LEDs auf der ESR-Platine:
- grün: leuchtet ständig
- rot: leuchtet durchgehend
- orange: blinkt gelegentlich
Status-LEDs Hauptplatine:
- orange: leuchtet durchgehend
- blau: blinkt im Intervall
- grün: blinkt schnell
EDIT: Nachdem ich das RPI (und den Adapter) für eine gewisse Zeit ausgeschaltet und neu gestartet hatte, konnte ich die Verbindung zum Adapter wiederherstellen. Seltsam, dass dies der Weg ist um die Verbindung herzustellen.
Jetzt muss ich weiter herausfinden, wie ich den Adapter weiter verwenden kann. (mit OpenHAB...)
Zitat von: john30 am 26 Februar 2023, 08:25:44
das könnte am Timing bei der Arbitrierung liegen. Schau mal, ob im Log was zu scan der 08 steht.
die EC ist m.W. immer da, sobald man irgendeine andere Komponente in der Richtung hat. Aber auch da einfach mal schauen, wie der Scan läuft.
Im Log steht gar nichts zum scan der 08. Default steht die Arbitrierung auf 200. Muss ich es eher in Richtung weniger oder mehr versuchen?
Was mir im Log noch aufgefallen ist:
[main error] scan config 04: ERR: read timeoutAllerdings habe ich gar keine 04 im scan.
ebusctl scan result
05;Vaillant;VR921;2706;5703
0a;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
12;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6
15;Vaillant;70000;0614;6903;21;20;11;0020266797;0082;017405;N5
26;Vaillant;VR_71;0104;0503;21;19;25;0020184846;0082;007468;N3
e0;Vaillant;OMU00;0131;5202;21;19;15;0010016715;0001;005937;N6
e1;Vaillant;OMU00;0131;5202;21;19;15;0010016715;0001;005933;N2
ec;Vaillant;SOL00;0614;6903;21;20;11;0020266797;0082;017405;N5
fc;Vaillant;PMW01;0206;8302;21;19;29;0010014312;3110;011687;N6ebusctl info
version: ebusd 23.1.23.1
device: 10.84.10.80:9999, enhanced, firmware 1.1[8419].2[847f]
access: *
signal: acquired
symbol rate: 34
max symbol rate: 123
min arbitration micros: 1
max arbitration micros: 37
min symbol latency: 7
max symbol latency: 16
reconnects: 0
masters: 5
messages: 888
conditional: 113
poll: 1
update: 8
address 00: master #1
address 05: slave #1, scanned "MF=Vaillant;ID=VR921;SW=2706;HW=5703"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"
address e1: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e1.omu.1.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0614;HW=6903", loaded "vaillant/ec.sol.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address ff: master #25Edit: Hatte das Log nicht auf debug. Hier die Info zum scan der 08:
2023-03-11 17:37:30.757 [bus info] scan 08 cmd: 3108070400
2023-03-11 17:37:30.757 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-03-11 17:37:30.757 [bus debug] start request 31
2023-03-11 17:37:30.757 [bus debug] arbitration start with 31
2023-03-11 17:37:31.402 [bus debug] arbitration won
2023-03-11 17:37:31.402 [bus debug] arbitration delay 3 micros
2023-03-11 17:37:31.402 [bus debug] switching from ready to send command
2023-03-11 17:37:31.410 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:37:31.418 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:37:31.426 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:37:31.434 [bus debug] send/receive symbol latency 8 ms
2023-03-11 17:37:31.434 [bus debug] switching from send command to send command CRC
2023-03-11 17:37:31.442 [bus debug] send/receive symbol latency 8 ms
2023-03-11 17:37:31.442 [bus debug] switching from send command CRC to receive command ACK
2023-03-11 17:37:31.527 [bus debug] notify request: ERR: read timeoutHier noch was zur 76, die auf dem alten PI gefunden wird und mit dem neuen Adapter nicht:
2023-03-11 17:39:09.423 [bus info] scan 76 cmd: 3176070400
2023-03-11 17:39:09.423 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-03-11 17:39:09.423 [bus debug] start request 31
2023-03-11 17:39:09.423 [bus debug] arbitration start with 31
2023-03-11 17:39:10.067 [bus debug] arbitration won
2023-03-11 17:39:10.067 [bus debug] arbitration delay 4 micros
2023-03-11 17:39:10.067 [bus debug] switching from ready to send command
2023-03-11 17:39:10.075 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:39:10.083 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:39:10.091 [bus debug] send/receive symbol latency 8 ms
2023-03-11 17:39:10.099 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:39:10.099 [bus debug] switching from send command to send command CRC
2023-03-11 17:39:10.107 [bus debug] send/receive symbol latency 8 ms
2023-03-11 17:39:10.107 [bus debug] switching from send command CRC to receive command ACK
2023-03-11 17:39:10.112 [bus debug] ERR: NAK received during receive command ACK, switching to send command
2023-03-11 17:39:10.120 [bus debug] send/receive symbol latency 7 ms
2023-03-11 17:39:10.128 [bus debug] notify request: ERR: wrong symbol received
Hallo Frank,
hast du schon etwas für Ochsner auftreiben können?
Brauche auch csv für meine GMWL14+.
Recht viele Daten bekomme ich auch nicht.
root@debian:/home/pi# ebusctl find -d -v
21576 status.heatpump = group=53;value=1;type=00;unit=0;max=25.5;min=0.0;status=Switched off
21576 temperature.buffer.flow = group=96;value=0;type=0d;unit=°C;max=100.0;min=0.0;temperature=28.7
21576 temperature.hotwater = group=4;value=0;type=0d;unit=°C;max=100.0;min=0.0;temperature=48.6
21576 temperature.outside = group=0;value=0;type=0d;unit=°C;max=50.0;min=-50.0;temperature=7.2
21576 unknown.02c60040 = group=70;value=65;type=04;unit=40;max=-0.1;min=0.0;status=212
21576 unknown.02c80040 = group=72;value=65;type=04;unit=42;max=143.9;min=0.0;status=212
broadcast datetime = outsidetemp=7.199;time=16:20:35;date=28.03.2023
master 10u0503 = status=1;state=0;maxmin=0;boiler=0.0;buffer1=0;buffer2=1
master data1 = buffer=28.699;boiler=-;bwr=0;pump=0;buffer1=0;buffer2=0;loading=0;boiler=0;tbfconnect=0;return=27.398
master data2 = buffer=0.000;boiler=53.000;expected=0;device=0;error=0
scan.06 = MF=TEM;ID=MB61;SW=0045;HW=0000
scan.08 = MF=TEM;ID=WE_1 ;SW=3632;HW=3030
scan.15 = MF=TEM;ID=20279;SW=0362;HW=0110
scan.18 = MF=TEM;ID=WE_2 ;SW=3632;HW=3030
...15.21576.csv und bis zum ioBroker gar nichts... muss mich mal einlesen.
Hallo,
ich bäuchte bitte mal eure Hilfe.
Ich hab den Adpter 3.0 schon eine Weile liegen und wollte nun eigentlich loslegen.
Scheitere aber schon an dem Update per PIC, hab den Adapter soweit mit den Jumpern richtig eingestellt und die blaue LED leuchtet auch dauerhaft.
Hab ihn an meine Laptop angesteckt und cmd per admin geladen.
Wenn ich nun den Befehlt eingebe, bekomme ich folgende Meldung.
ebuspicloader-windows>ebuspicloader -f firmware.hex /dev/USB0
unable to open /dev/USB0
Ich habe die aktuelle Firmware geladen und die Datei umgenannt und in das Verzeichnis gelegt.
Kann es sein das ich den flaschen Namen für die USB Schnittstelle habe, aber welchen muss man dort benutzen. Welchen Namen muss man aus dem Gerätemanager verwenden?
Danke für eure Hilfe.
kommt folgende Meldung
Hab den Fehler gefunden, hatte keinen Treiber installiert. Hab das leider nirgends lesen können.
Hallo,
ich habe über das Netzwerk die Verbindung zum Ebus aufbauen können.
Der Adapter 3.0 hat folgendes in der config stehen:
EBUSD_OPTS="--scanconfig --configpath=http://ebusd.eu/config/ --accesslevel=* --latency=20000 -d ens:192.168.150.50:9999 --logfile=/var/log/ebusd.log --loglevel=debug --address=ff"
Das sagt die Info:
/etc/default $ ebusctl info
version: ebusd 23.1.23.1
device: 192.168.150.50:9999, enhanced, firmware 1.1[8419].1[0a6c]
access: *
signal: acquired
symbol rate: 23
max symbol rate: 114
min arbitration micros: 6
max arbitration micros: 72
min symbol latency: 8
max symbol latency: 20
reconnects: 0
masters: 5
messages: 509
conditional: 0
poll: 0
update: 10
address 00: master #1
address 03: master #11
address 04: slave #25, ebusd
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=2801;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0305;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0305;HW=0403"
address ff: master #25, ebusd
ebus Status:
/etc/default $ sudo service ebusd status
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2023-04-04 22:53:51 CEST; 37min ago
Process: 2326 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 2327 (ebusd)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/ebusd.service
└─2327 /usr/bin/ebusd --scanconfig --configpath=http://ebusd.eu/config/ --accesslevel=* --latency=20000 -d ens:192.168.150.50:9999 --logfile=/var/log/ebusd.log --loglevel=debug --address=ff
Apr 04 22:53:51 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Apr 04 22:53:51 raspberrypi ebusd[2326]: 2023-04-04 22:53:51.185 [main notice] replaced old configPath http://ebusd.eu/config/ with new one: http://cfg.ebusd.eu/
Apr 04 22:53:51 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
Leider bekomme ich keinen Log, in die Datei (/var/log/ebusd.log).
Wenn ich die Datei öffne, bekomme ich immer die Meldung das diese schreibgeschützt ist.
Es steht nur etwas äteres drin, was schon Stunden zurück liegt. Ich habe aber alles auch schon neu gestartet.
Habt Ihr vielleicht einen Tipp wie ich das lösen könnte, fehlen für diese Datei die Berechtigungen?
Dank
Hallo,
ich habe gestern meine "neue" usb/Raspi Platine zum ersten mal in Betrieb genommen. Bisher hatte ich immer eine ältere auf einem Raspi per Stiftleiste und ttyebus treiber am laufen.
Nun habe ich ein neues System auf einem anderen Rechner aufgesetzt ebusd installiert bekomme aber kein Signal
Config EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20 -d enh:/dev/ttyUSB0 --address=ff"
root@pve:~# ebusctl info
version: ebusd 23.1.23.1
update check: OK
device: /dev/ttyUSB0, enhanced
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
Leider habe ich aber kein Signal. Die Platine blinkt und die blaue blinkt in 4 Sek?. abständen auch immer.
Wo liegt der Fehler was habe ich vergessen?
der Log sieht so aus
2023-04-10 13:22:10.892 [main notice] ebusd 23.1.23.1 started with auto scan on enhanced device /dev/ttyUSB0
2023-04-10 13:22:12.123 [bus notice] device status: resetting
2023-04-10 13:22:12.124 [bus notice] bus started with own address ff/04
2023-04-10 13:22:12.145 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.235 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.325 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.413 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.501 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.546 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.635 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.723 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.812 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.900 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:12.989 [bus error] device status: missing enhanced byte 2
2023-04-10 13:22:13.078 [bus error] device status: missing enhanced byte 2
Update habe es hin bekommen indem ich den Jumper auf highspeed gestellt habe.
Hallo,
hab meinen ebusd Adapter (v5) am laufen, nur bin ich mir nicht ob ich was falsch mache oder die Heizung (Ochnser GWSM) einfach nicht mehr Daten liefert
pi@raspberry:~ $ ebusctl i
version: ebusd 23.1.23.1-8-g9c0af7b9
device: 192.168.200.245:9999, enhanced, firmware 1.1[3501].1[3501]
access: *
signal: acquired
symbol rate: 43
max symbol rate: 100
min arbitration micros: 0
max arbitration micros: 32
min symbol latency: 7
max symbol latency: 34
reconnects: 0
masters: 4
messages: 137
conditional: 0
poll: 0
update: 9
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=TEM;ID=MB61;SW=0044;HW=0000"
address 08: slave #11, scanned "MF=TEM;ID=WE_1 ;SW=3632;HW=3030"
address 10: master #2
address 15: slave #2, scanned "MF=TEM;ID=19469;SW=0359;HW=0110"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
pi@raspberry:~ $ ebusctl find -d -v
21576 status.heatpump = group=53;value=1;type=00;unit=0;max=25.5;min=0.0;status=Switched off
21576 temperature.buffer.flow = group=96;value=0;type=0d;unit=°C;max=100.0;min=0.0;temperature=30.1
21576 temperature.hotwater = group=4;value=0;type=0d;unit=°C;max=100.0;min=0.0;temperature=54.1
21576 temperature.outside = group=0;value=0;type=0d;unit=°C;max=50.0;min=-50.0;temperature=29.1
21576 unknown.02c60040 = group=70;value=65;type=04;unit=40;max=-0.1;min=0.0;status=57
21576 unknown.02c80040 = group=72;value=65;type=04;unit=42;max=143.9;min=0.0;status=56
broadcast datetime = outsidetemp=29.098;time=13:44:26;date=07.07.2023
broadcast error = error=SE60 E OK
master 10u0503 = status=1;state=0;maxmin=0;boiler=0.0;buffer1=1;buffer2=1
master data1 = buffer=30.098;boiler=-;bwr=0;pump=0;buffer1=0;buffer2=0;loading=0;boiler=0;tbfconnect=0;return=24.301
master data2 = buffer=0.000;boiler=54.000;expected=0;device=0;error=0
scan.06 = MF=TEM;ID=MB61;SW=0044;HW=0000
scan.08 = MF=TEM;ID=WE_1 ;SW=3632;HW=3030
scan.15 = MF=TEM;ID=19469;SW=0359;HW=0110
Was meint ihr?
Ev. fehlt dir die -mqttint?
https://github.com/john30/ebusd/wiki/MQTT-integration
Hi!
Gestern ist unsere AroTherm von Vaillant gekommen. Bislang habe ich unsere Wolf Gasheizung damit erfolgreich ausgelesen.
Das noch viele Nachrichten unentschlüsselt sind ist nicht das eigentliche Problem.
Ich würde gerne erst mal die entschlüsselten über MQTT empfangen, so wie das mit der Wolftherme bislang gut geklappt hat.
Speziell geht es um folgende Daten:
received read hmu Status01 QQ=10: 55.0;55.0;-;-;-;offentschlüsselt durch die Datei hcmode.inc durch folgende Zeile:
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
Diese einzelnen Werte werden nicht als readings in FHEM angelegt, vermutlich weil es mehrere Werte in einem Feld sind.
Die readings durch den scan und outsidetemp_temp2_value werden angelegt.
Muss ich was neues in die ReadingList eintragen oder etwas an anderer Stelle ändern?
Hier eine gekürzte Ausgabe von ebusd:
sudo ebusd -d enh:192.168.2.54:9999 --latency=2000 --address=01 --configpath=/etc/ebusd/en --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=localhost --mqtttopic=ebusd/%circuit/%name --pollinterval=10 --enablehex --enabledefi -f --scanconfig=full
2023-07-28 14:26:27.117 [main notice] ebusd 23.2.23.2 started with full scan on device: 192.168.2.54:9999, enhanced
2023-07-28 14:26:27.164 [bus notice] device status: resetting
2023-07-28 14:26:27.165 [bus notice] bus started with own address 01/06
2023-07-28 14:26:27.171 [mqtt notice] connection established
2023-07-28 14:26:27.179 [bus notice] signal acquired
2023-07-28 14:26:27.663 [bus notice] device status: reset
2023-07-28 14:26:29.350 [bus notice] new master 10, master count 2
2023-07-28 14:26:29.427 [bus notice] new master 03, master count 3
2023-07-28 14:26:29.663 [bus notice] new master 71, master count 4
2023-07-28 14:26:37.167 [main notice] starting initial full scan
2023-07-28 14:26:38.679 [bus notice] new master 00, master count 5
2023-07-28 14:26:38.679 [bus notice] scan 05: ;Vaillant;VR921;2801;5703
2023-07-28 14:26:38.679 [update notice] store 05 ident: done
2023-07-28 14:26:38.679 [update notice] sent scan-read scan.05 QQ=01: Vaillant;VR921;2801;5703
2023-07-28 14:26:38.679 [bus notice] scan 05: ;Vaillant;VR921;2801;5703
2023-07-28 14:26:39.755 [bus notice] scan 08: ;Vaillant;HMU00;0902;5103
2023-07-28 14:26:39.755 [update notice] store 08 ident: done
2023-07-28 14:26:39.755 [update notice] sent scan-read scan.08 QQ=01: Vaillant;HMU00;0902;5103
2023-07-28 14:26:39.755 [bus notice] scan 08: ;Vaillant;HMU00;0902;5103
2023-07-28 14:26:46.083 [bus notice] scan 15: ;Vaillant;CTLV2;0514;1104
2023-07-28 14:26:46.083 [update notice] store 15 ident: done
2023-07-28 14:26:46.083 [update notice] sent scan-read scan.15 QQ=01: Vaillant;CTLV2;0514;1104
2023-07-28 14:26:46.083 [bus notice] scan 15: ;Vaillant;CTLV2;0514;1104
2023-07-28 14:26:47.171 [main error] unable to load scan config 05: no file from vaillant with prefix 05 matches ID "vr921", SW2801, HW5703
2023-07-28 14:26:47.171 [main error] scan config 05: ERR: element not found
2023-07-28 14:26:49.177 [main notice] read common config file vaillant/scan.csv
2023-07-28 14:26:49.177 [main notice] read common config file vaillant/general.csv
2023-07-28 14:26:49.178 [main notice] read common config file vaillant/broadcast.csv
2023-07-28 14:26:49.182 [main notice] read scan config file vaillant/08.hmu.csv for ID "hmu00", SW0902, HW5103
2023-07-28 14:26:49.183 [main notice] found messages: 67 (0 conditional on 0 conditions, 0 poll, 10 update)
2023-07-28 14:26:51.795 [update notice] sent scan-read scan.08 id QQ=01:
2023-07-28 14:26:54.731 [bus notice] scan 08: ;21;23;20;8000013856;1610;008133;N5
2023-07-28 14:26:59.319 [update notice] sent scan-read scan.15 id QQ=01:
2023-07-28 14:26:59.759 [update notice] sent scan-read scan.15 id QQ=01:
2023-07-28 14:27:00.282 [update notice] sent scan-read scan.15 id QQ=01: 21;22;48;0020260914;0953;065368;N5
2023-07-28 14:27:00.282 [bus notice] scan 15: ;21;22;48;0020260914;0953;065368;N5
2023-07-28 14:27:00.283 [main notice] read scan config file vaillant/15.ctlv2.csv for ID "ctlv2", SW0514, HW1104
2023-07-28 14:27:00.283 [main notice] found messages: 69 (0 conditional on 0 conditions, 0 poll, 10 update)
2023-07-28 14:27:04.201 [bus notice] scan 76: ;Vaillant;VWZIO;0901;5103
2023-07-28 14:27:04.201 [update notice] store 76 ident: done
2023-07-28 14:27:04.201 [update notice] sent scan-read scan.76 QQ=01: Vaillant;VWZIO;0901;5103
2023-07-28 14:27:04.201 [bus notice] scan 76: ;Vaillant;VWZIO;0901;5103
2023-07-28 14:27:05.040 [bus notice] max. symbols per second: 111
2023-07-28 14:27:06.503 [update notice] sent scan-read scan.76 id QQ=01:
2023-07-28 14:27:07.063 [update notice] sent scan-read scan.76 id QQ=01:
2023-07-28 14:27:08.775 [update notice] sent scan-read scan.76 id QQ=01: 21;22;50;0010023609;3110;013522;N2
2023-07-28 14:27:08.775 [bus notice] scan 76: ;21;22;50;0010023609;3110;013522;N2
2023-07-28 14:27:08.777 [main error] unable to load scan config 76: no file from vaillant with prefix 76 found
2023-07-28 14:27:52.999 [update notice] sent scan-read scan.76 QQ=01: Vaillant;VWZIO;0901;5103
2023-07-28 14:27:52.999 [bus notice] scan 76: ;Vaillant;VWZIO;0901;5103
2023-07-28 14:29:12.400 [update notice] received read hmu State QQ=71: 0;51;192;0
2023-07-28 14:29:19.196 [update notice] received unknown MS cmd: 0376b51206130010000005 / 0200ff
2023-07-28 14:29:19.292 [update notice] received read hmu State QQ=71: 0;51;192;0
2023-07-28 14:29:19.416 [update notice] received read hmu Status01 QQ=10: 54.5;54.0;-;-;-;off
2023-07-28 14:29:19.680 [update notice] received unknown MS cmd: 1076b5110101 / 096cfff316ff6a0000ff
2023-07-28 14:29:19.944 [update notice] received unknown MS cmd: 1076b512030f0001 / 07510300630310ff
2023-07-28 14:29:20.220 [update notice] received update-write hmu SetMode QQ=10: auto;0.0;-;-;1;1;1;0;0;0
2023-07-28 14:29:20.484 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2023-07-28 14:29:21.556 [update notice] received unknown MS cmd: 7108b51a03043632 / 0e3607c0cfc07b3c00b01b20000000
2023-07-28 14:29:22.000 [update notice] received unknown MS cmd: 7108b51a03043733 / 0e370000c083020000000000000000
2023-07-28 14:29:22.376 [update notice] received unknown MS cmd: 7108b51a03043834 / 0e38cf2000c0022101001800061800
2023-07-28 14:29:22.748 [update notice] received unknown MS cmd: 7108b51a03043935 / 0e3900000000000100900100001000
2023-07-28 14:29:23.152 [update notice] received unknown MS cmd: 7108b51a03043a36 / 0e3a00000000000000000000000000
2023-07-28 14:29:23.614 [update notice] received read hmu State QQ=71: 0;51;192;0
2023-07-28 14:29:27.040 [update notice] received read hmu State QQ=71: 0;51;192;0
2023-07-28 14:29:27.176 [update notice] received unknown MS cmd: 0376b51206130010000005 / 0200ff
2023-07-28 14:29:29.676 [update notice] received unknown MS cmd: 1076b5110101 / 096cfff316ff6a0000ff
2023-07-28 14:29:29.934 [update notice] received unknown MS cmd: 1076b512030f0001 / 07510300620310ff
2023-07-28 14:29:30.192 [update notice] received update-write hmu SetMode QQ=10: auto;0.0;-;-;1;1;1;0;0;0
2023-07-28 14:29:30.456 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2023-07-28 14:29:30.549 [update notice] received read hmu State QQ=71: 0;51;192;0
2023-07-28 14:29:33.940 [update notice] received read hmu State QQ=71: 0;51;192;0
und hier noch meine ReadingList:
ebusd/global/version:.* version
ebusd/global/running:.* running
ebusd/global/uptime:.* uptime
ebusd/global/updatecheck:.* updatecheck
ebusd/global/signal:.* signal
ebusd/broadcast/sollw:.* { json2nameValue($EVENT, 'sollw_', $JSONMAP) }
ebusd/broadcast/datetime:.* { json2nameValue($EVENT, 'datetime_', $JSONMAP) }
ebusd/broadcast/error:.* { json2nameValue($EVENT, 'error_', $JSONMAP) }
ebusd/broadcast/ertraege:.* { json2nameValue($EVENT, 'ertraege_', $JSONMAP) }
ebusd/broadcast/temp:.* { json2nameValue($EVENT, 'temp_', $JSONMAP) }
ebusd/broadcast/solar:.* { json2nameValue($EVENT, 'solar_', $JSONMAP) }
ebusd/master/dateTimeMeldung:.* { json2nameValue($EVENT, 'dateTimeMeldung_', $JSONMAP) }
ebusd/scan\x5c\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }
ebusd/scan\x5c\x2e75/:.* { json2nameValue($EVENT, 'scan.75_', $JSONMAP) }
ebusd/scan\x5c\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }
ebusd/scan\x5c\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
ebusd/scan\x5c\x2e76/:.* { json2nameValue($EVENT, 'scan.76_', $JSONMAP) }
ebusd/broadcast/Unbekannt:.* { json2nameValue($EVENT, 'Unbekannt_', $JSONMAP) }
ebusd/solar/ruecklauftemp:.* { json2nameValue($EVENT, 'ruecklauftemp', $JSONMAP) }
ebusd/solar/durchfl:.* { json2nameValue($EVENT, 'durchfl', $JSONMAP) }
ebusd/solar/ertraege:.* { json2nameValue($EVENT, 'ertraege_', $JSONMAP) }
ebusd/solar/Gesammtertrag_Wh:.* { json2nameValue($EVENT, 'ertraege_', $JSONMAP) }
ebusd/solar/Gesamtertrag_kWh:.* { json2nameValue($EVENT, 'ertraege_', $JSONMAP) }
ebusd/solar/Gesamtertrag_MWh:.* { json2nameValue($EVENT, 'ertraege_', $JSONMAP) }
ebusd/solar/SolarErfolg:.* { json2nameValue($EVENT, 'ertraege_', $JSONMAP) }
ebusd/ISM7/Automatik:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
ebusd/ISM7/Sommer:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
ebusd/ISM7/Heizbetrieb:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
ebusd/ISM7/Absenkbetrieb:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
ebusd/ISM7/Standby:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
ebusd/scan\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }
ebusd/scan\x2e75/:.* { json2nameValue($EVENT, 'scan.75_', $JSONMAP) }
ebusd/scan\x2e76/:.* { json2nameValue($EVENT, 'scan.76_', $JSONMAP) }
ebusd/global/scan:.* scan
ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }
ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }
ebusd/scan\x2e08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/scan\x2e05/:.* { json2nameValue($EVENT, 'scan.05_', $JSONMAP) }
ebusd/scan\x2e05/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }
ebusd/scan\x2e15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/scan\x2e76/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/broadcast/ident:.* { json2nameValue($EVENT, 'ident_', $JSONMAP) }
ebusd/scan\x2eec/:.* { json2nameValue($EVENT, 'scan.ec_', $JSONMAP) }
ebusd/scan\x2eec/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/broadcast/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/hmu\Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
Gruß,
Burkhard
Hi!
So, ich habe in der hcmode.inc die Zeile wie folgt abgeändert:
r,hmu,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01 ,VorlaufTemp,,temp1,,, ,RuecklaufTemp,,temp1,,, ,AussenTemp,,temp2,,, ,WWTemp,,temp1,,, ,SpeicherTemp,,temp1,,, ,Pumpenstatus,,pumpstate,,, Wichtig ist auch der ciricut name, in diesem Beispiel hmu.
In der Readinglist in fhem habe ich folgendes hinzugefügt:
ebusd2/hmu/Status01:.* { json2nameValue($EVENT, 'hmu_', $JSONMAP) }
Nun werden die readings mit dem namen der Felder angelegt.
Gruß,
Burkhard
Hallo Leute,
ich habe "leichte" Probleme meinen ebus-WIFI mit esp (V3) zum Laufen zu bringen.
Leider sind bei div. Anleitungen die Links und Bilder nicht mehr verfügbar.
ich habe eine https-Verbindung.
die LEDs blinken. ebus ist angeschlossen, aber ich bekommen offensichtlich kein Signal.
Hostname: ebus
Up time: 145
Free heap: 24504
ebusd connected: yes (inactive)
eBUS signal: no signal
habt ihr Tipps für mich?
danke
lG
Jürgen
Guten Morgen liebe EBus-Adapter Gemeinschaft, O:-)
bei mir hakt es, gefühlt an allen Ecken. Aber letztendes scheitert es zunächst an der augenscheinlich fehlenden Software, die hinter dem Link "ebuspicloader-windows.zip" auf der GitHub Seite
https://github.com/john30/ebusd/blob/master/src/tools/README.md
runterladbar sein soll. Hieraus soll eine ebuspicloader.exe zu extrahieren werden. Die finde ich auch nirgendwo. Zu guter letzt soll ich dann nach Anweisung auf GitHub die cygwin Software runterladen um via USB mit dem Adapter kommunizieren zu können? Oder funktioniert das auch in der normalen Kommandozeile von Windows (cmd.exe)?
Kommt mir so vor, dass ich der Einzige bin der das hier nicht richtig gerafft bekommt obwohl ich technisch vorbelastet bin. Linux habe ich überhaupt keine "Basis-"Kenntnisse.
Ich hoffe jemand kann mir kurz beistehen und diese schreckliche Zeit angenehmer machen. :)
An die Hersteller trotzdem, vielen vielen Dank dass Ihr Zeit und Mühe in dieses günstige Projekt gesteckt habt, welches viele Techniker-Herzen höher schlagen lässt.
Zitat von: Jürgen2000 am 10 August 2023, 19:04:52Leider sind bei div. Anleitungen die Links und Bilder nicht mehr verfügbar.
die sind vielleicht verschoben, schau halt auf die Startseite https://adapter.ebusd.eu/
Zitat von: Jürgen2000 am 10 August 2023, 19:04:52ich habe eine https-Verbindung.
von wo nach wo? Der Adapter kann kein HTTPS.
Zitat von: Jürgen2000 am 10 August 2023, 19:04:52die LEDs blinken. ebus ist angeschlossen, aber ich bekommen offensichtlich kein Signal.
wie lautet der device string, den Du an ebusd übergeben hast?
Zitat von: djd1983 am 04 Oktober 2023, 10:09:58bei mir hakt es, gefühlt an allen Ecken. Aber letztendes scheitert es zunächst an der augenscheinlich fehlenden Software, die hinter dem Link "ebuspicloader-windows.zip" auf der GitHub Seite
https://github.com/john30/ebusd/blob/master/src/tools/README.md
die links haben sich geändert, ist korrigiert.
Moin zusammen auch ich darf mich nun als stolzer Besitzer eine eBus Adapter(5.0) zählen. Ich habe die Ethernet Variante und die Verbindung zu unserer neuen aroTHERM plus funktioniert auch grundsätzlich. Das einzige was ich noch nicht richtig verstehe ich das setzen von Werten über MQTT. Denn manchmal funktioniert es und manchmal nicht. Es ist egal ob ich das aus FHEM oder aus MQTT Explorer abschicke. Was aber immer geht ist wenn ich es über die Console per ebusctl ausführe. Hat jemand eine Idee was ich prüfen könnte?
Zum Aufbau:
Einen eigenen Mosquitto Broker im LXC Container und folgenden Einstellungen in der ebusd Config:
EBUSD_OPTS="-d enh:192.168.178.113:9999 --configpath=/home/fort/ebus/ebusd-configuration/ebusd-2.1.x/en --scanconfig=full -l /var/log/ebusd.log --latency=10 --log='all error' --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.178.181 --mqtttopic=ebusd/%circuit/%name"
Mein Adapter läuft noch seit der Testphase störungsfrei.
Habe jetzt allerdings nach einem kleineren Problem mit ebusd (hat aus unerfindlichen Gründen nach dem reboot vom Host keine configs geladen) alles aktualisiert und noch eine Frage zum ens Modus. Leider geht das nicht eindeutig aus der Dokumentation hervor.
Unter welchen Bedingungen genau lässt sich dieser Modus nutzen?
Welche Vorteile bietet ens gegenüber enh?
Genutzt wird der W5500 Adapter auf der v3.0.
Gruß
Irgendwie komm ich mit dem ebusd Werten von meiner Ochsner-Wärmepumpe (TEM Steuerung) nicht weiter.
Wer kann mir weiterhelfen wie ich die Daten interprerieren kann bzw. was die nächsten Schritte sind.
DANKE
Folgende Rückmeldung erhalte ich:
pi@raspberry:~ $ ebusctl i
version: ebusd 23.2.23.2
device: 192.168.200.245:9999, enhanced, firmware 1.1[3501].1[3501]
access: *
signal: acquired
symbol rate: 44
max symbol rate: 74
min arbitration micros: 4
max arbitration micros: 39
min symbol latency: 14
max symbol latency: 27
scan: finished
reconnects: 0
masters: 4
messages: 137
conditional: 0
poll: 0
update: 9
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=TEM;ID=MB61;SW=0044;HW=0000"
address 08: slave #11, scanned "MF=TEM;ID=WE_1 ;SW=3632;HW=3030"
address 10: master #2
address 15: slave #2, scanned "MF=TEM;ID=19469;SW=0359;HW=0110"
address 31: master #8, ebusd
address 36: slave #8, ebusd
pi@raspberry:~ $ ebusctl grab result all
031005030a010000002d15ff3f0000 = 26: master 10u0503
10fe070009800c27382130100123 = 7: broadcast datetime
10fe0801089a16008000004d15 = 7: master data1
10fe0802080000000a0000001e = 7: master data2
10fefe010a53453630202045204f4b = 1: broadcast error
1003050a00 = 3
3106070400 / 0a104d4236310000440000 = 1: scan.06
3108070400 / 0a1057455f312036323030 = 1: scan.08
3115070400 / 0a10313934363903590110 = 1: scan.15
100305020101 = 3
10fe050d0a1bcece00a5a5a5a5a5a5 = 3
10fe100a0e1000e200d500e200000000020000 = 20
10fe100a0c11017d000000000000005000 = 21
100305010a00000a0c000000000000 = 10
011506210407890046 / 0a89434d0284036400dc00 = 1
0115062104028a0046 / 0a0a01800cb40000000000 = 1
011506210403b20046 / 0ab2410900f30000000100 = 1
011506210403ce0046 / 0ace01042863ffabb0abb0 = 1
011506210400800046 / 0a00800d02f4010cfe7d00 = 1
011506210400810046 / 0a01800d02f40100000080 = 1
011506210400820046 / 0a02800d02e8030000e200 = 1
0115062104068e0040 / 0a0e430000020001000100 = 1
011506210401940046 / 0a94800200010000000000 = 1
011506210400800040 / 0a00800d02f4010cfe7d00 = 31: 21576 temperature.outside
011506210400840040 / 0a04800d02e80300000002 = 30: 21576 temperature.hotwater
011506210400e00040 / 0a60800d02e8030000e200 = 32: 21576 temperature.buffer.flow
011506210402b50040 / 0a35810000ff0000000000 = 32: 21576 status.heatpump
011506210402c60040 / 0a46410428ffff0000acb0 = 32: 21576 unknown.02c60040
011506210402c80040 / 0a4841042a9f0500001205 = 32: 21576 unknown.02c80040
Zitat von: xerion am 27 Oktober 2023, 21:13:51Moin zusammen auch ich darf mich nun als stolzer Besitzer eine eBus Adapter(5.0) zählen. Ich habe die Ethernet Variante und die Verbindung zu unserer neuen aroTHERM plus funktioniert auch grundsätzlich. Das einzige was ich noch nicht richtig verstehe ich das setzen von Werten über MQTT. Denn manchmal funktioniert es und manchmal nicht. Es ist egal ob ich das aus FHEM oder aus MQTT Explorer abschicke. Was aber immer geht ist wenn ich es über die Console per ebusctl ausführe. Hat jemand eine Idee was ich prüfen könnte?
Zum Aufbau:
Einen eigenen Mosquitto Broker im LXC Container und folgenden Einstellungen in der ebusd Config:
EBUSD_OPTS="-d enh:192.168.178.113:9999 --configpath=/home/fort/ebus/ebusd-configuration/ebusd-2.1.x/en --scanconfig=full -l /var/log/ebusd.log --latency=10 --log='all error' --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.178.181 --mqtttopic=ebusd/%circuit/%name"
was schickst du denn via MQTT? Beim Schreiben zusammen mit --mqttjson gibt es (noch) die Einschränkung, dass dann trotzdem das Format geschickt werden muss, das auch ebusctl, versteht. Steht auch im wiki AFAIK
Zitat von: Rainer1 am 28 Oktober 2023, 07:24:32ich frage mich, ob hier was falsch läuft: es sind 6 identische Prozesse "ebusd" aktiv - gibt es jemand der sich auskennt ?
ich schätze mal, dass du die Threads anzeigst und nicht die Prozesse
Zitat von: hErMeS am 29 Oktober 2023, 10:13:10Mein Adapter läuft noch seit der Testphase störungsfrei.
Habe jetzt allerdings nach einem kleineren Problem mit ebusd (hat aus unerfindlichen Gründen nach dem reboot vom Host keine configs geladen) alles aktualisiert und noch eine Frage zum ens Modus. Leider geht das nicht eindeutig aus der Dokumentation hervor.
Unter welchen Bedingungen genau lässt sich dieser Modus nutzen?
Welche Vorteile bietet ens gegenüber enh?
Genutzt wird der W5500 Adapter auf der v3.0.
Gruß
der adapter muss halt auf enhanced gestellt sein (siehe v3 Doku). In der Netzwerkvariante macht enh und ens keinen Unterschied
Hallo,
ich muss jetzt auch noch einmal zur Integration von MQTT nachfragen.
Ich habe den eBUS Adapter 5, kann auf dessen Webseite zugreifen.
Wenn ich auf github die Anleitung lese finde ich dort "In order to support discovery features of MQTT tools such as Home Assistant, an MQTT integration configuration can be activated with the --mqttint option."
Wie oder wo aktiviere ich den die --mqttinit?
Hallo,
John hat mir auf die Sprünge geholfen. Ich muss natürlich den ebusd auf dem Raspberry installieren.
Jetzt habe ich dort aber das Problem dass er nicht startet.
pi@ioBroker:~ $ sudo service ebusd start
Job for ebusd.service failed because the control process exited with error code.
See "systemctl status ebusd.service" and "journalctl -xe" for details.
░░ A start job for unit ebusd.service has finished with a failure.
░░
░░ The job identifier is 7658 and the job result is failed.
Dec 18 07:32:01 ioBroker CRON[5192]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec 18 07:32:01 ioBroker CRON[5193]: (root) CMD (/bin/mount -a > /dev/null 2>&1)
Dec 18 07:32:01 ioBroker CRON[5192]: pam_unix(cron:session): session closed for user root
Dec 18 07:32:04 ioBroker systemd[1]: ebusd.service: Scheduled restart job, restart counter is at 103.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ Automatic restarting of the unit ebusd.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Dec 18 07:32:04 ioBroker systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
░░ Subject: A stop job for unit ebusd.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit ebusd.service has finished.
░░
░░ The job identifier is 7723 and the job result is done.
Dec 18 07:32:04 ioBroker systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
░░ Subject: A start job for unit ebusd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit ebusd.service has begun execution.
░░
░░ The job identifier is 7723.
Dec 18 07:32:04 ioBroker ebusd[5195]: /usr/bin/ebusd: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory
Dec 18 07:32:04 ioBroker systemd[1]: ebusd.service: Control process exited, code=exited, status=127/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit ebusd.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 127.
Dec 18 07:32:04 ioBroker systemd[1]: ebusd.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit ebusd.service has entered the 'failed' state with result 'exit-code'.
Dec 18 07:32:04 ioBroker systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
░░ Subject: A start job for unit ebusd.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit ebusd.service has finished with a failure.
░░
░░ The job identifier is 7723 and the job result is failed.
Kann mir da bitte jemand einen Tipp geben?
ich hab den ebus adapter 3.1, letzte firmware und funktioniert soweit auch alles.
konfiguriert hab ich eine fixe ip, mir ist jetzt aber was komisches aufgefallen.
scheinbar gib es trotz konfigurierter fixer ip laufend dhcp requests.
lt. meiner firewall
DROP Bridge A1-DHCP-3: forward: in:ether2(ether2) out:ether5, src-mac ae:b0:53:32:15:10, dst-mac ff:ff:ff:ff:ff:ff, eth-proto 0800, UDP, 10.0.0.7:68->255.255.255.255:67, len 299
kommt im prinzip jede minute 1x
hat da jemand vielleicht eine idee dazu??
Zitat von: Flatron am 04 April 2023, 14:08:15Hab den Fehler gefunden, hatte keinen Treiber installiert. Hab das leider nirgends lesen können.
Kannst du sagen welchen Treiber du installiert hast? Ich habe aktuell das selbe Problem.
Danke dir. Grüße
Hallo!
Ich habe meinen eBus Adapter 3.0 seit 2021 mit einer Wolf CGB-2 im Einsatz.
Da ich die WLAN Variante verwendet, habe ich --latency immer auf 100 gestellt.
Normalerweise möchte ich nur Werte auslesen. Für einen einzigen Usecase würde ich aber gerne die Solltemperatur für das Warmwasser setzen. Das Schreiben auf dem Ebus hat aber nie geklappt und ist bei Wolf auf Grund der nicht so perfekten CSVs viel Trial & Error.
Jetzt hab ich mich wieder drangesetzt und dabei festgestellt, dass ich plötzlich schreiben kann, wenn ich die --latency auf 10000 erhöhe. Ist das "normal" / erklärebares Verhalten?
Weiter ist mir aufgefallen, dass ich die --latency auf 100 (wie bisher) oder auf 10000 setzen kann. Wenn ich sie aber auf 1000 setze, dann startet mir der ebusd nicht mehr (Debian Bullseye Pakete auf Raspi, aktuelle Version).
Viele Grüße,
weini