eBUS Adapter 3.0 Inbetriebnahme

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

Vorheriges Thema - Nächstes Thema

Reinhart

#30
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.
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

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)
FHEM im Proxmox Container

Reinhart

#32
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
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

Danke schonmal, werde ich morgen angehen.
FHEM im Proxmox Container

Reinhart

#34
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}}
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Mitch

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.
FHEM im Proxmox Container

DerFranke

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?

john30

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.
author of ebusd

Reinhart

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 für die visuelle Anzeige veröffentlicht, oder hier, 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
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Gurker

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.




Mitch

Heute Nacht ist der Adapter wieder ausgestiegen.
Da hilft nur ein Neustart.

Einstellungen sind genau wie im Wiki.

Defekter Adapter?
FHEM im Proxmox Container

Reinhart

leuchtet dann die blaue Led am Adapter?

blinkt die grüne Led am Adapter weiter?

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

Mitch

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
FHEM im Proxmox Container

Reinhart

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
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Gurker

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