[abgeschlossen] eBUS Adapter 3.0 Betatest

[hErMeS]

Toten Stille traf es nicht, war ja weiterhin mit seiner alten IP erreichbar.
Das Lease müsste sich trotzdem erneuern im Falle von DHCP.
Fixed ist was anderes, dynamic sollte dementsprechend behandelt werden.
Im DHCP Mal schnell eine IP ändern ist ja schnell gemacht. Dementsprechend sollte auch die neue IP bezogen werden. Zugriff erfolgt mit DNS Namen anstatt fester IP bei mir im Netz.

Wenn jemand einen Router tauscht und hierdurch andere Subnetze genutzt werden, muss man zwingend den eBus Adapter neu bestromen. Ist in meinen Augen nicht sehr Consumer freundlich wenn man weiß jedes Gerät holt sich seine neuen Adressen von selbst. Naja, ist auch nicht wirklich ein Consumer Gerät 
Ich sehe es als gravierenden Fehler in der Protokoll Implementierung bzw verhalten an da es nicht dem normalen Verhalten entspricht und auch mich ins Grübeln brachte

[Reinhart]

Einstellungen am Raspi betreffend dem USB + Rpi Betrieb!

Bitte "raspi-config" aufrufen und die seriellen Einstellungen checken, siehe dazu die Bilder unten. Dann Kontrolle der config.txt und der cmdline.txt.
Bitte auch unbedingt den ttyebus Treiber sofern dieser für die Version 2.x installiert wurde.

Code Auswählen Erweitern

cd ~/ttyebus
sudo make uninstall

Code Auswählen Erweitern

### config.txt ###
[all]
enable_uart=1
dtoverlay=pi3-miniuart-bt

### cmdline.txt ###
console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes root   
relevante Einstellung der config.txt und cmdline.txt ( console ) .

Code Auswählen Erweitern

### ls -al /dev ###
crw--w----  1 root tty       4,   7 Dez 14 21:17 tty7
crw--w----  1 root tty       4,   8 Dez 14 21:17 tty8
crw--w----  1 root tty       4,   9 Dez 14 21:17 tty9
crw-rw----  1 root dialout 204,  64 Dez 14 21:17 ttyAMA0
crw-------  1 root root      5,   3 Dez 14 21:17 ttyprintk
crw-------  1 root root     10, 239 Dez 14 21:17 uhid
crw-------  1 root root     10, 223 Dez 14 21:17 uinput
crw-rw-rw-  1 root root      1,   9 Dez 14 21:17 urandom
Check ob ttyAMA0 auftaucht!

Code Auswählen Erweitern


### lsusb ###
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210                                    x family]
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Auf der Platine richtig jumpern und Platine über USB Kabel anschließen.

ACHTUNG: Viele USB Kabel haben nur Power belegt und schleifen die beiden Data Leitungen nicht durch, solche Kabel sind ungeeignet!

Bei mir ist mindestens jedes 2.Kabel nicht geeignet, das sind meist jene die einem Steckernetzteil beiliegen!

LG

[HeikoGr]

Braucht man die Anpassungen auch für den USB Betrieb?

Von meinem Verständnis benötigt man die Änderungen doch nur, wenn man die Ebus Platine aufsteckt, oder?

Und das Overlay pi3-minuart-bt ist deprecated, soweit ich weiss.
Heisst nur noch

Code Auswählen Erweitern

minuart-bt

[Reinhart]

ob der miniart-bt so notwendig ist weis ich nicht, einfach austesten, die schreibt ja der raspi-config. Ich habe die Einstellungen von einem Raspi 2B mit Buster entnommen und so funktioniert bei mir auch alles und die notwendigen Schnittstellen tauchen auf.

LG

[john30]

Ich sehe es als gravierenden Fehler in der Protokoll Implementierung bzw verhalten an

pfff, solche Sätze verderben mir echt den Spaß an so einem Projekt

[HeikoGr]

ah ok, ich sehe das Problem. Im Moment ist es ja so, dass ebusd mit einer fixen IP Adresse arbeitet. Insofern ist das Szenario "aus Netz A abstecken und im Netz B anstecken" eh nicht relevant, weil dazu ebusd entsprechend neu konfiguriert werden müsste. Ich hatte jetzt eher eine kurze Unterbrechung aber am gleichen Netz im Sinn.
Das könnte man schon im PIC implementieren, aber aus meiner Perspektive bringts nichts.
Oder sehe ich das falsch?

Ich nutze auch einen DNS Namen und keine IP-Adresse. Insofern wäre das Feature auch für mich relevant.

@john30: Ich kann dich verstehen. Aber du könntest es auch sportlich nehmen. Laut Wikipedia *kann* ein DHCP Client eine neue IP-Adresse anfordern, wenn der DHCP Server verschwindet. Er *darf* seine IP-Adresse noch bis zum Ablauf der Lease Zeit behalten. (Ich hab's jetzt nicht gegen die x-DHCP RFC's gegengelesen...). Zeigt mir bitte ein Gerät, welches die umfassenden DNS/DHCP RFC alle einhält :-D

[hErMeS]

pfff, solche Sätze verderben mir echt den Spaß an so einem Projekt

Ich möchte niemanden angreifen oder schlecht machen.

Es würde doch mit zwei/drei Bedingungen im Code zumindest behebbar seien, so dass es zum neuen Request kommt? (Register abfragen, gegenprüfen lost Link und up again, request initialisieren)
Dass es hier nie eine konforme Behandlung von DHCP geben wird ist mir klar aufgrund des begrenzen ROM. Die lease time wäre mir auch egal.
Ich will auch die ganze Arbeit nicht schlecht reden, im Gegenteil ein großes Lob über das Erreichte.
Aber sind wir nicht da um so etwas auszutesten?

[fuso2001]

Ich nutze auch einen DNS Namen und keine IP-Adresse. Insofern wäre das Feature auch für mich relevant.

Hallo Heiko,

der DNS Name hilft dir auch nur mit fester IP bzw DHCP Reservierung. Einen DNS Refresh wird der Adapter nicht machen wenn er bei nem Stromausfall ne neue Lease/IP bekommt. Oder sehe ich das falsch?

LG
Frank

[HeikoGr]

Jein. Bei Stromausfall geht auch der Adapter aus

Und da bei mir die Fritzbox sowohl DHCP, als auch DNS macht hab ich auch bei einer geänderten IP keine Probleme

[mr_petz]

@John30,@Reinhart

Ich habe mal DI+ und DI- vom Chip bis USB Buchse durchgeprüft. Sind durchgängig.(Bildanhang Leiterbahnen))
Habe auch nochmal nach Anleitung von Reinhart alles am Pi gecheckt. Es bleibt dabei. kein neues Gerät. Ich habe den Adapter auch mal an den PC gesteckt, keine Reaktion von Windoof.
Ansonsten Status wie hier im Beitrag:
https://forum.fhem.de/index.php/topic,116418.msg1111745.html#msg1111745
k.a. was da los ist.

Jetzt zum Ethernetmodus.
Config sieht so aus:

Code Auswählen Erweitern

EBUSD_OPTS="--scanconfig=full --accesslevel=* -l /var/log/ebusd.log --latency=20000 -d enh:192.168.0.217:9999 --loglevel=debug --mqttjson --mqtthost=192.168.0.253 --mqttport=1883 --mqtttopic=ebusd/%circuit/%name --address=ff"

ebusd startet nicht mit folgender Meldung:

Code Auswählen Erweitern

Job for ebusd.service failed because the control process exited with error code.
See "systemctl status ebusd.service" and "journalctl -xe" for details.


im log steht nix drin.
mit "systemctl status ebusd.service" kommt folgendes:

Code Auswählen Erweitern

â ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Fri 2020-12-18 15:27:22 CET; 25s ago
  Process: 1564 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=64)

Dec 18 15:27:22 FEHM-Server systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Dec 18 15:27:22 FEHM-Server systemd[1]: ebusd.service: Unit entered failed state.
Dec 18 15:27:22 FEHM-Server systemd[1]: ebusd.service: Failed with result 'exit-code'.


mit "journalctl -xe" kommt folgendes:

Code Auswählen Erweitern

--
-- Unit ebusd.service has begun starting up.
Dec 18 15:29:54 FEHM-Server ebusd[1601]: /usr/bin/ebusd: unrecognized option '--mqttjson'
Dec 18 15:29:54 FEHM-Server ebusd[1601]: Try `ebusd --help' or `ebusd --usage' for more information.
Dec 18 15:29:54 FEHM-Server systemd[1]: ebusd.service: Control process exited, code=exited status=64
Dec 18 15:29:54 FEHM-Server systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
-- Subject: Unit ebusd.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has failed.
--
-- The result is failed.
Dec 18 15:29:54 FEHM-Server systemd[1]: ebusd.service: Unit entered failed state.
Dec 18 15:29:54 FEHM-Server systemd[1]: ebusd.service: Failed with result 'exit-code'.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Dec 18 15:30:24 FEHM-Server systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
-- Subject: Unit ebusd.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has finished shutting down.
Dec 18 15:30:24 FEHM-Server systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
-- Subject: Unit ebusd.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has begun starting up.
Dec 18 15:30:24 FEHM-Server ebusd[1607]: /usr/bin/ebusd: unrecognized option '--mqttjson'
Dec 18 15:30:24 FEHM-Server ebusd[1607]: Try `ebusd --help' or `ebusd --usage' for more information.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Control process exited, code=exited status=64
Dec 18 15:30:24 FEHM-Server systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
-- Subject: Unit ebusd.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has failed.
--
-- The result is failed.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Unit entered failed state.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Failed with result 'exit-code'.
Dec 18 15:30:35 FEHM-Server sudo[1609]:       pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/journalctl -xe
Dec 18 15:30:35 FEHM-Server sudo[1609]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
lines 2817-2859/2859 (END)


Ich verwende diese Version:

Code Auswählen Erweitern

ebusd 3.4.v3.3-51-g57eae05
Die habe ich auch aktuell im Einsatz mit FDTI UART und Adapter v2.2.
Brauche ich eine andere ebusd Version?
Hatte auch nochmal die ebusd-3.4_armhf-stretch.deb neu gezogen und installiert.

Einen Ping kann ich an das USR-ES1 Modul senden...
Komme gerade nicht weiter
Ich hoffe ich stelle mich nicht zu dumm an. erst USB und jetzt das...

gruß Thomas

[HeikoGr]

"journalctl -xe" gibt bei folgendes (mit) aus:

Code Auswählen Erweitern

unrecognized option '--mqttjson'

@john30: hast du das Debian Paket ohne mqtt gebaut?

https://github.com/john30/ebusd/releases/tag/v3.4

Code Auswählen Erweitern

Variants of each binary with MQTT support have an additional "mqtt0" (for libmosquitto0) or "mqtt1" (for libmosquitto1) suffix in the name. Those without MQTT support don't have such a suffix.

@mr_petz: du musst das mqtt Paket nehmen

[john30]

@john30: hast du das Debian Paket ohne mqtt gebaut?

für das neue enhanced protocol muss wie hier schon geschrieben der enhanced_device Branch selbst compiliert werden. binaries/release gibt es noch nicht.
also:

Code Auswählen Erweitern

git clone https://github.com/john30/ebusd
cd ebusd
git checkout enhanced_device
./autogen.sh
make install


[HeikoGr]

für das neue enhanced protocol muss wie hier schon geschrieben der enhanced_device Branch selbst compiliert werden.

Stimmt. Ich hab mich nur auf die Fehlermeldung konzentriert. Der Fehler wegen "enh:" wäre dann beim nächsten mal gekommen...

[mr_petz]

für das neue enhanced protocol muss wie hier schon geschrieben der enhanced_device Branch selbst compiliert werden. binaries/release gibt es noch nicht.
also:

Code Auswählen Erweitern

git clone https://github.com/john30/ebusd
cd ebusd
git checkout enhanced_device
./autogen.sh
make install


Ok jetzt läufts. Hatte nicht das make install ausgeführt. wollte erst mit der alten Version den USB Standardmodus testen...

[JimKnopf]

Jein. Bei Stromausfall geht auch der Adapter aus

Jein, bei mir hängt eine Powerbank dazwischen.

Gruß,
Burkhard