eBus Schaltung V2 in Betrieb nehmen

[Prince]

@ Reinhart
Danke für die Swapped-Erläuterung.

Da tauschen wir lieber die Beschriftung im Schaltplan aus

Ich stimme dir zu, den Schaltplan zu ändern sieht am Besten aus.

@ john30
Das ging zügig. Vielen Dank, für dein Update. Ich habe jetzt eine WLAN-Verbindung. Der Wemo startet auch in der Erweiterungsplatine mit "offenem" D0. Dann kann es jetzt auf der Software-Seite bei mir weitergehen. TOP! Danke!

[MichaelV]

Nachdem meine Platine zusammengebaut ist und ein paar Problemchen beseitigt sind (hauptsächlich durch den vor dem Monitor verursacht) würde ich gerne anfangen zu testen.

Ich möchte meine Heizungsdaten in ioBroker verarbeiten. Dieser läuft auf einem Tinker Board unter Armbian Ubuntu. Habe dazu das armhf Paket von ebusd auf dem Tinker Board installiert. Jetzt möchte ich gerne die Verbindung zwischen der ebus Platine (per WLAN) und ebusd testen, ohne schon die Heizung angeschlossen zu haben. Geht das?

Aktuell sieht es bei mir so aus:

ebus platine mit angeschlossenem Wemos und aktueller Firmware:

Code Auswählen Erweitern

Welcome to eBUS adapter 2.0, build 20171225
ebusd device string: 192.168.10.34:8889
Press any key within 5 seconds to change the configuration...
Entering eBUS mode.

ebusd scheint auch zu laufen:

Code Auswählen Erweitern

root@tinkerboard:~# 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 Sa 2017-12-30 19:48:55 CET; 1min 8s ago
  Process: 32522 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 32523 (ebusd)
    Tasks: 4
   Memory: 484.0K
      CPU: 36ms
   CGroup: /system.slice/ebusd.service
           └─32523 /usr/bin/ebusd -d 192.168.10.34:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01 --loglevel info

Dez 30 19:48:55 tinkerboard systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 30 19:48:55 tinkerboard systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..


allerding sieht es für mich so aus, als ob keine Verbindung zur ebus Platine zustande kommt (oder doch?):

Code Auswählen Erweitern

2017-12-30 19:48:55.123 [main notice] ebusd 3.0pre.bbc4d04 started with auto scan
2017-12-30 19:48:55.123 [main info] loading configuration files from /etc/ebusd
2017-12-30 19:48:55.124 [main info] reading templates /etc/ebusd
2017-12-30 19:48:55.128 [main info] read templates in /etc/ebusd
2017-12-30 19:48:55.128 [main info] reading file /etc/ebusd/memory.csv
2017-12-30 19:48:55.129 [main info] successfully read file /etc/ebusd/memory.csv
2017-12-30 19:48:55.129 [main info] reading file /etc/ebusd/broadcast.csv
2017-12-30 19:48:55.131 [main info] successfully read file /etc/ebusd/broadcast.csv
2017-12-30 19:48:55.131 [main info] read config files
2017-12-30 19:48:55.287 [main info] registering data handlers
2017-12-30 19:48:55.287 [main info] registered data handlers
2017-12-30 19:48:55.287 [bus notice] bus started with own address 01/06
2017-12-30 19:49:16.724 [network info] [00001] client connection opened 127.0.0.1
2017-12-30 19:49:16.725 [network info] [00001] connection closed
2017-12-30 19:51:01.807 [main notice] update check: version 3.1 available, broadcast.csv: newer version available
2017-12-30 19:55:08.728 [bus notice] signal acquired
2017-12-30 19:55:12.003 [bus error] signal lost
2017-12-30 19:56:32.076 [bus notice] re-opened 192.168.10.34:8889


Wenn der letzte Eintrag im Log bedeutet, dass alles gut ist: Kann man das auch irgendwie an der ebus Platine/Wemos prüfen?

Bringt sonst noch jemand seine Heizungsdaten direkt in ioBroker und kann mir sagen wie (reicht der MQTT Adapter in ioBroker; wie konfiguriere ich den; benötige ich auch das ebusd Paket mit mqtt; ...)?

Vielen Dank für Eure Hilfe,
Michael

[Reinhart]

Wenn du über MQTT kommunizieren willst, dann musst du natürlich das Paket mit Mqtt installieren. Ich habe das Testweise einmal installiert, aber mir nur die JSON Strings angesehen die am Broker ankommen. Das hat alles soweit funktioniert, gesendet habe ich noch nichts damit.

Ohne eBus wirst du allerdings nicht viel testen können, weil ja auch nichts ankommt. Du musst außerdem die Opts ändern, hast du das Wiki von John dazu gelesen? Ich würde dir aber dringend anraten alles auf herkömmliche Art und Weise einmal in Betrieb zu nehmen und dann gleichzeitig die MQTT Telegramme am IOBroker einmal zu studieren. Sonst verläufst du dich im Dschungel.

Was ich im Log sehe, verlierst du die Verbindung vom Wemos zum eBus, oder hast du dazwischen abgeklemmt? Widerspricht sich eigentlich das du sagst, du hast nichts angeschlossen.

Teste doch einmal von deinem Tinker mit Telnet die Verbindung zum Wemos ohne ihn an die Platine anzuschließen, dann brauchst auch keinen eBus dafür. Ich mach das immer mit Putty.

Code Auswählen Erweitern

telnet 192.168.10.34 8889
Die Verbindung muss stehen bleiben!


Wenn das passt, dann den nächsten Schritt, Bus anklemmen und Dämon starten und wieder kontrollieren. Wie du siehst, hast du sehr viele Unbekannte zu überwinden, deshalb würde ich das aufsplitten und zunächst über den Uart kommunizieren und checken, dann weist du das die Platine grundsätzlich funktioniert, also immer Schritt für Schritt bis zu deinem gewünschten Ziel und nicht vergessen dazwischen immer die /etc/default/ebusd anzupassen.
Gleich via WLAN über MQTT ist sehr komplex wenn du nicht einmal sicher bist das die Basis Platine funktioniert. Wenn die Basisplatine funktioniert, ist der Punkt abgehackt und zum nächsten. So haben wir es in der gesamten Entwicklungsphase exerziert.


LG
Reinhart

[Reinhart]

@All

All jene die immer noch Schwierigkeiten mit dem AP von ESPEAsy haben, Letscontrolit hat jetzt eine GUI entwickelt welche die Settings schon beim Flashen festlegen kann.

Einfach die Binarys nach \ESP_Easy_Flasher-master\bin kopieren und schon werden sie im DropDownmenü angezeigt.

LG
Reinhart

[dkreutz]

So langsam wächst der Frust... auch der neue Wemos funktioniert nicht richtig. Ich habe nach ca. drei Tagen Betrieb den ebusd-esp Wemos rebooted, danach will er nicht mehr in den eBus-Mode gehen. Wie schon die anderen beiden Wemos, verliert auch dieser nach einigen Tagen bzw. Reboots die ebusd-dsp Konfiguration. 
Und zwar so gründlich, dass eine Neukonfiguration über das Webinterface nicht mehr funktioniert ("Check&Update" gefolgt von "Save&Reset"). Also wieder in den Keller, Adapter abbauen, neu flashen, ...   

Habe ich eine so ungewöhnliche WLAN-Umgebung (Fritzbox 7490 mit Fritz-WLAN-Repeater-450E im Mesh-Mode, IP des ebusd-esp Wemos fest auf die MAC verdrahtet)?
Liegt es daran, dass ich zum flashen einen iMac (OSX 10.11) und zum konfigurieren Firefox/Safari verwende?
Habe ich einfach Pech und alle drei Wemos haben einen defekten EPROM/Flash für die Konfiguration?
Hat mein eBus-Adapter eine Macke?

[PeMue]

Liegt es daran, dass ich zum flashen einen iMac (OSX 10.11) und zum konfigurieren Firefox/Safari verwende?
Habe ich einfach Pech und alle drei Wemos haben einen defekten EPROM/Flash für die Konfiguration?

Probier doch mal bei einen der Wemos D1 mini den Speicher komplett zu löschen, Anleitungen müsste es im Forum/Internet geben.

Gruß PeMue

[dkreutz]

Probier doch mal bei einen der Wemos D1 mini den Speicher komplett zu löschen, Anleitungen müsste es im Forum/Internet geben.

Ich benutze zum flashen esptool.py und führe immer erst ein erase_flash aus, bevor ich den eigentlich Flashvorgang mit write_flash durchführe. Oder meinst Du die Variante, wo man einen PIN am Wemos auf high/low legen soll (meiner Erinnerung nach waren sich da die von mir gefundenen Seiten nicht einig...)?

[PeMue]

Ich benutze zum flashen esptool.py und führe immer erst ein erase_flash aus, bevor ich den eigentlich Flashvorgang mit write_flash durchführe.

Genau das meinte ich, d.h. Deine Wemos sollten vor dem flashen keine Daten mehr haben. Wenn das Verhalten aber bei dreien identisch ist, würde ich woanders suchen ...

Gruß PeMue

[JHo]

Hallo zusammen,

bin am basteln mit meiner Wolf R12 und möchte einige der per ebus zu findenden Werte in fhem auswerten - auch, um noch fehlende Bereiche in den Konfigurations-CSVs zu befüllen. Jetzt habe ich aber ein vermutlich grundlegendes eBus/FHEM-Verständnisproblem.

Ebusd läuft auf einem Raspi Zero und loggt fleißig Broadcast-Meldungen mit - Sollwerte und Betriebsdaten laut CSV. Auf dem gleichen Pi Zero läuft FHEM und ist per Gaebus an den ebusd angebunden.

• Gibt es einen Weg, die Broadcastmeldungen, die im Abstand von wenigen Sekunden in ebusd einlaufen, nach FHEM zu bringen (push)?
• Ich möchte mir verschiedene (~10) Readings vom Gaebus ausgeben lassen, möglichst aktuell.
  Habe daher das Gaebus-Interval auf 20 (Sekunden) gestellt. Je mehr Readings ich damit im Intervall auslesen will, umso öfter bekomme ich
  [bus error] signal lost
  [bus error] send to f6: ERR: no signal
  etc. zwischen den broadcast-Meldungen. FHEM zeigt dann auch als Reading-Wert dieses ERR: no signal an.
  Woran könnte das liegen? Überfordere ich mit x > 2 Readings am Stück den eBus? Ist mein WLAN zwischen eBus-Adapter(v2) und dem Pi zu lahm? Ist das Kabel zwischen Adapter und R12 zu schlecht (Doppel-Litze, "Lautsprecherkabel")?
• Gibt es eine Möglichkeit, die Readings direkt vom ebusd zu pushen, statt sie aus FHEM zu pollen? Evtl. sogar mit sowas wie "event-on-change"?

Danke und einen guten Rutsch,
Jan

[Prince]

@dkreutz

Probier doch mal bei einen der Wemos D1 mini den Speicher komplett zu löschen

John hat in der Version von gestern (build 20171230) zwei möglicherweise interessante Features im Changelog:

- removed forced reset (by setting D0=HIGH during boot) again
- made "f" load factory defaults and only "F" erase the whole EEPROM

Beste Grüße

[dkreutz]

Hallo,

John hat in der Version von gestern (build 20171230) zwei möglicherweise interessante Features im Changelog:

Vielen Dank für den Hinweis, das klingt wirklich interessant. Das probiere ich aber nicht mehr in diesem Jahr aus 

Guten Rutsch ins neue Jahr
Dominik

[Reinhart]

@JHo

ich glaube du überforderst deinen eBus komplett, 10 Datenabfragen alle 20 Sekunden, d.h. du sendest ununterbrochen zum eBus (mit Parameter "forced") . Der eBus ist kein Netzwerk und wenn du dir die Spezifikation durchliest, kommst du schnell dahinter das Sendeanfragen sehr wohl zu Kollisionen führen können. Das ist auch der Grund warum John warnt nicht ununterbrochen einen Scan abzusetzen. Meist merkt dies der Anwender nicht, weil die Anfrage einfach wiederholt wird und sich quasi selbst heilt, aber in dieser Geschwindigkeit wundert es mich das der Rest der Heizanlage noch richtig kommunizieren kann.
Da eine Heizanlage stark verzögert arbeitet, kann ich mir persönlich auch keinen Bedarf von "aktuellen Daten" vorstellen. Ich polle nur alle 15 Minuten an den eBus und steuere meine ganze Heizung damit.

Alle Daten die der eBus automatisch liefert kannst du auch mit MQTT empfangen, dann hast du ein pushen an den Broker. Aber es sind nur jene Datensätze die als Broadcast kommen. Die kannst du aber auch von Fhem ununterbrochen abfragen ohne ein Senden einzuleiten (Parameter -m)

Code Auswählen Erweitern

ebusctl r -m 10 Status01

das ist der Unterschied zu -f (forced) die holst du direkt vom eBus ab und -m aus dem Cache des eBusd (letzter Wert vom Broadcast).

LG
Reinhart

[JHo]

Hallo Reinhart,

ein frohes neues Jahr und vielen Dank für den Schubser in die richtige Richtung! Dass ich den Bus überlaste, habe ich fast befürchtet. Gedanke war, die paar Einträge im normalen Betrieb zuzuordnen, die in dern Wolf-CSVs noch nicht benannt sind und sich verändern - einfach, indem ich sie mit plotte und die Zusammenhänge direkt sehe (z.B. Speicherladepumpe). Die Außentemperatur ("Unknown15") war damit ziemlich leicht rauszubekommen.

Im Broadcast stehen für den normalen Betrieb alle die Infos, bei denen mir 15 Minuten nicht ausreichen würden (Brennerstatus, z.B.). Wusste nicht, wie ich den nach FHEM bekomme - aber damit ist es klar. Die Cache-Variante reicht ja grundsätzlich aus, da ich alle "neueren", identischen Werte ja eh über event-on-change wieder rausfiltern würde. Ich sollte tatsächlich die Spezifikation lesen und mir nochmal die Unterschiede zwischen Gaebus und der ECMD-Einbindung in Ruhe, aber vollständig anschauen.

LG,
Jan

[john30]

Vielen Dank für den Hinweis, das klingt wirklich interessant. Das probiere ich aber nicht mehr in diesem Jahr aus 

Genau, ich würde auch vermuten, dass der hard reset via D0 auf H legen bei Dir die Ursache war. Allerdings kann ich mir nicht erklären, was bei Dir da so anders zu sein scheint, dass der greift.
Anyway. den hab ich in 20171230 ausgebaut und insofern wäre das ein Versuch wert.
Hoffe, das klappt dann besser...
Falls nicht müssten wir und das Thema ich-hab-nen-Mac unter die Lupe nehmen, damit konnte ich hier nichts testen, aber es sollte an sich keinen Unterschied machen. Irgendwo hab ich noch nen Mac rumliegen, mal in der Kiste wühlen...

[dkreutz]

Hallo John,

Genau, ich würde auch vermuten, dass der hard reset via D0 auf H legen bei Dir die Ursache war. Allerdings kann ich mir nicht erklären, was bei Dir da so anders zu sein scheint, dass der greift.
Anyway. den hab ich in 20171230 ausgebaut und insofern wäre das ein Versuch wert.
Hoffe, das klappt dann besser...
Falls nicht müssten wir und das Thema ich-hab-nen-Mac unter die Lupe nehmen, damit konnte ich hier nichts testen, aber es sollte an sich keinen Unterschied machen. Irgendwo hab ich noch nen Mac rumliegen, mal in der Kiste wühlen...

Mit ebusd-esp 20171230 behält der Wemos die Konfiguration über mehrere Kalt- und Warmstart hinweg, auch nach zwei Tagen Dauerbetrieb. Mit einem zweiten Wemos verhält es sich identisch.
Damit ist also mein Problem mit der verlorenen Konfiguration anscheinend gelöst.

Aber... jetzt findet ebusd nicht mehr den Adapter bzw erkennt meine Heizungsregelung nicht mehr (bisher hat er die als Master/Slave auf Adresse f1/f6 gefunden)

Code Auswählen Erweitern

ebusctl info
version: ebusd 3.0pre.bbc4d04
update check: version 3.1 available, broadcast.csv: different version available
signal: acquired
symbol rate: 5
max symbol rate: 206
min arbitration micros: 35
max arbitration micros: 208
min symbol latency: 5
max symbol latency: 34
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

Mit loglevel=debug gibt es während eines full scan folgende Einträge

Code Auswählen Erweitern

2018-01-02 12:50:37.534 [bus info] scan ef cmd: 31ef070400
2018-01-02 12:50:37.534 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2018-01-02 12:50:37.682 [bus debug] arbitration delay 71 micros
2018-01-02 12:50:37.682 [bus debug] switching from ready to send command
2018-01-02 12:50:37.688 [bus debug] send/receive symbol latency 5 ms
2018-01-02 12:50:37.693 [bus debug] send/receive symbol latency 5 ms
2018-01-02 12:50:37.698 [bus debug] send/receive symbol latency 5 ms
2018-01-02 12:50:37.704 [bus debug] send/receive symbol latency 5 ms
2018-01-02 12:50:37.704 [bus debug] switching from send command to send command CRC
2018-01-02 12:50:37.709 [bus debug] send/receive symbol latency 5 ms
2018-01-02 12:50:37.709 [bus debug] switching from send command CRC to receive command ACK
2018-01-02 12:50:37.774 [bus debug] notify request: ERR: read timeout


Während des Scan zeigt das eBus Adapter Webinterface den Status

Code Auswählen Erweitern

ebusd connected: yes
eBUS signal: no signal
Wenn der Scan beendet ist dann

Code Auswählen Erweitern

ebusd connected: yes (inactive)
eBUS signal: no signal

Die eBus-Verkabelung habe ich schon erneuert (Telefonkabel durch 0,75qmm Stromkabeladern ersetzt). Wenn ich die Heizungsregelung hochfahre blinken rote&grüne LED (die gelbe leuchtet dauerhaft). Nach ca. einer Minute hört die rote LED auf zu blinken und nur noch die grüne blinkt - das war aber vorher auch schon so.
Wo kann ich noch suchen?

VG
Dominik