Läuft: Heizung mit eBus-Schnittstelle

[lewej]

schick mir doch mal ein bisschen von deinem ebusd log file, vielleicht lässt sich da was erkennen.
Grundsätzlich ist das Auslesen via eBUS natürlich eine gewisse Störung, es sei denn mal liest nur mit. Des weiteren verändert auch der bloße Anschluss an den Bus physisch die Eigenschaften durch Verdrahtung, Impedanz, Lasten etc.
Wie verhält es sich denn mit der Vorgängerversion von ebusd?

Hallo john,

das liegt wohl nicht an der Version. Wie es scheint, verliert mein Raspberry die Verbindung zum ebus Koppler. Ich habe den converter von eservice. Hat jemand evtl auch solche Probleme gehabt. Anbei der Fehler:

Code Auswählen Erweitern



Mar 28 10:14:58 smarthome kernel: [240230.740508] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:19:50 smarthome kernel: [240522.773968] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:20:50 smarthome kernel: [240583.434989] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:24:23 smarthome kernel: [240796.109272] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:24:34 smarthome kernel: [240807.203525] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:26:19 smarthome kernel: [240911.913675] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:40:22 smarthome kernel: [241755.042497] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:40:45 smarthome kernel: [241777.826670] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:55:56 smarthome kernel: [242689.340429] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:56:24 smarthome kernel: [242717.059484] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:58:57 smarthome kernel: [242870.580593] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:05:50 smarthome kernel: [243282.987591] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:06:13 smarthome kernel: [243306.397362] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:06:48 smarthome kernel: [243341.165453] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 11:12:57 smarthome kernel: [243710.436558] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:13:17 smarthome kernel: [243729.865004] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 11:13:51 smarthome kernel: [243763.796175] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:16:27 smarthome kernel: [243919.744466] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:30:01 smarthome kernel: [244733.752663] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:31:20 smarthome kernel: [244813.062187] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:31:30 smarthome kernel: [244823.342173] ftdi_sio ttyUSB1: failed to get modem status: -71


Gruß
lewej

[lewej]

Hallo Zusammen,

läuft bei jemanden der ebus Koppler von eservice an einem PI 3 und einem aktiven HUB stabil?

Ich habe folgende Hardware:

- PI hängt an einem meanwell 5V 6A Schaltnetzteil, an diesem hängt auch ein aktiver HUB
- der ebus Koppler hängt am USB HUB

Ich bekomme weder den ebus Koppler von eservice noch den selbst gebauten aus dem Forum stabil ans laufen.
Meine anderen Usb Devices, laufen alle ohne Probleme. Deshalb kann ich ein Strom Problem ausschliessen.

Hat jemand eine Idee?

Gruss
Lewej

[jkriegl]

@NemoN habe eine vergreichbare Konfiguration.
Habe SumFlowSensor nur in einer csv. (Habe allerdings noch csv's aus den Anfängen)
Da grep bei Dir zwei Einträge liefert, musst Du den circuit angeben.
Prüfe mal mit ebusctl f -f SumFlowSensor die Auflösungen.
ebusctl r -c hc SumFlowSensor funtioniert bei mir.

[lewej]

Hallo Zusammen,

ich hab ein Problem mit dem ebusd und mqtt, nach einer Weile hört ebusd was an den MQTT Broker zu publishen.
Hat jemand auch diese Probleme. Leider konnte ich das ganze noch nicht eingrenzen. Ich habe jetzt das logging hochgeschraubt.

@john:
Hast eine Idee, was das sein kann?

Gruß
lewej

[Binnesmann]

Guten Tag zusammen,

ich habe eine Wolf Heizung mit einem R2 BM. Der ebus läuft sauber und ich speicher fleissig Daten. Mein Ziel ist es, die Daten vom Bus per "ebusctl r Parameter" auszulesen und in eine Datenbank zu speichern. Auf den Bus senden möchte ich nicht. Durch dieses Forum und Google bin ich schon gut auf dem Weg. Vielen Dank für die geleistete Arbeit.

Zum Schluss habe ich noch folgende Zeile offen:

2017-03-31 08:24:47.690 [update notice] unknown MM cmd: 03f10800084d27000e00030037
2017-03-31 08:25:01.168 [update notice] unknown MM cmd: 1003050709bb0175020080ff6eff
2017-03-31 08:25:06.174 [update notice] unknown MM cmd: 10030800084d27000e80010037

Ich habe für beide Slaveadressen 03 und f1 jeweils eine .csv Datei im gleichen Unterverzeichniss wie die anderen. Weder beim Neustart noch bei ebusctl reload gibt es einen Hinweis auf einen Öffnungsversuch der Dateien. Die Adressen lassen den deamon kalt. Was muss ich tun??

Ein ebusd --checkconfig läuft ohne Fehler durch.

Die Befehle 0507 und 0800 sind auch in der broadcast.csv hinterlegt. Dürfen die nur einmal vorhanden sein?

Viele Grüße

Binnesmann

[schka17]

Hallo Zusammen,

ich hab ein Problem mit dem ebusd und mqtt, nach einer Weile hört ebusd was an den MQTT Broker zu publishen.
Hat jemand auch diese Probleme. Leider konnte ich das ganze noch nicht eingrenzen. Ich habe jetzt das logging hochgeschraubt.

@john:
Hast eine Idee, was das sein kann?

Gruß
lewej

Ich habe auch das Problem das über MQTT keine updates bekomme, allerdings nicht der ebusd hört auf zu publishen, sondern die MQTT Devices in FHEM bekommen die publish nicht mit, wenn ich direkt mit einem mosqutitto client  lausche dann sehe ich alle updates. Das schräge dabei ist aber, das betrifft nur die MQTT DEVICES die ich aus dem ebusd topic subscribe, alle anderen funktionieren.


Sent from my iPad using Tapatalk

[john30]

Möchte für andere Nutzer einer Zeotherm die ersten Erkenntnisse meiner Versuche aufzeigen, da es doch etwas mühsam war die Parameter zuzuordnen:

Nachdem Du der einzige mit bekannte mit einer Zeotherm bist: Könntest Du bitte mal folgende Abfrage mit ebusd machen:

Code Auswählen Erweitern

ebusctl hex 50b509030d3c00
Damit wird hoffentlich der Typ des Heizkreises abgefragt.
Merci, john

[john30]

Ich habe für beide Slaveadressen 03 und f1 jeweils eine .csv Datei im gleichen Unterverzeichniss wie die anderen. Weder beim Neustart noch bei ebusctl reload gibt es einen Hinweis auf einen Öffnungsversuch der Dateien. Die Adressen lassen den deamon kalt. Was muss ich tun??

Ein ebusd --checkconfig läuft ohne Fehler durch.

Die Befehle 0507 und 0800 sind auch in der broadcast.csv hinterlegt. Dürfen die nur einmal vorhanden sein?

schick mir das log file, dann schau ich mal rein

[john30]

ich hab ein Problem mit dem ebusd und mqtt, nach einer Weile hört ebusd was an den MQTT Broker zu publishen.
Hat jemand auch diese Probleme. Leider konnte ich das ganze noch nicht eingrenzen. Ich habe jetzt das logging hochgeschraubt.

@john:
Hast eine Idee, was das sein kann?

ist denn noch signal da? nachdem dein ftdi device wohl ärger macht, könnte sowas evtl. sein.

[john30]

das liegt wohl nicht an der Version. Wie es scheint, verliert mein Raspberry die Verbindung zum ebus Koppler. Ich habe den converter von eservice. Hat jemand evtl auch solche Probleme gehabt. Anbei der Fehler:

Code Auswählen Erweitern


Mar 28 10:14:58 smarthome kernel: [240230.740508] ftdi_sio ttyUSB1: failed to get modem status: -71


genau das gleiche hatte ich im januar auch mal über mehrere wochen. immer wieder spontan aufgetreten. hab dann den hersteller angeschrieben, aber nie eine antwort bekommen. ein paar wochen später war das phänomen dann einfach weg. total merkwürdig.

[john30]

ich habe mich in der Kennzeichnung geirrt, ich habe eine geotherm 81/3. In meiner hcmode.inc, finde ich diese Optionen nicht, kannst mir sagen wie ich das ändern muss?

das ist ja bizarr. aber okay. Ändere mal in hcmode die folgende Zeilen:

Code Auswählen Erweitern


*r,,,,,,"B504",,,,,,,
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,


in das hier:

Code Auswählen Erweitern


*r,,,,,,"B504",,,,,,,
*u,,,,,,"B510",,,,,,,
r;u,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,


[lewej]

genau das gleiche hatte ich im januar auch mal über mehrere wochen. immer wieder spontan aufgetreten. hab dann den hersteller angeschrieben, aber nie eine antwort bekommen. ein paar wochen später war das phänomen dann einfach weg. total merkwürdig.

Hallo John,

wie immer Danke für deine Mühe, dein Support ist echt klasse.

Seit ca. 3 Tagen tritt der Fehler nicht mehr in der häufigkeit auf und der ebusd verliert auch seine Verbindung nicht mehr.

Was habe ich gemacht:

- Wie es scheint, sollte man mehrere  usb-serial converter nicht am gleichen aktiven usb hub betreiben, sobald ich beide an einem hängen habe, gibt es fehler( mal weniger mal mehr, konnte es bis jetzt nicht einkreisen)
- getrennte usb hubs mit Schaltznetzteil 6A Stromversorgung
- raspi jessy auf aktuelleste Version upgedatet
- raspi firmware upgedatet

Bis heute scheint die Verbindung stabil zu laufen, das mqtt Problem bin ich noch am beobachten.

Gruss lewej

[Binnesmann]

Hallo John,

den Teil des logs ab dem reload findest Du im Anhang. Ich bin übers Wochenende leider nicht weiter gekommen.

Wenn ich es schaffe, stelle ich auch noch meine csv's ein.

Grüße

Binnesmann

Edit: Ich habe die csv's angehängt und ich verwende Version 2.2.65328e5 - alt, aber läuft stabil und kann alles was ich brauche

[john30]

Ich habe für beide Slaveadressen 03 und f1 jeweils eine .csv Datei im gleichen Unterverzeichniss wie die anderen.

Der Fehler ist, dass 03 und f1 beides Master Adressen sind und keine Slaves.
D.h. Dateien umbenennen in die korrespondierende Slave Adresse wird helfen (08 bzw. f6).

Das Log zeigt das eigentlich auch schon:

Code Auswählen Erweitern

2017-03-30 22:02:42.532 [main error] unable to load scan config 08: no file from /etc/ebusd/kromschroeder with prefix 08. found
2017-03-30 22:02:50.602 [main error] unable to load scan config f6: no file from /etc/ebusd/kromschroeder with prefix f6. found

[john30]

Könnte mal bitte jemand mit einer SOLSY oder VR630 prüfen, ob die quick Kommandos dort auch greifen?
Also insbesondere auf Adresse 25 für HWC. Dazu einfach an die 25.*.hwc.csv noch "!include,quick.inc" als neue Zeile dranhängen, dann reload und am Ende schauen ob bspw. "ebusctl w -c hwc load on" die Speicherladung startet.
Auch interessant wäre, ob save/party ebenfalls auf Adresse 25 funktionieren würden.
VG John