Läuft: Heizung mit eBus-Schnittstelle

[john30]

@Reinhart:
Werden die Rechte des PID Files durch Dein init Script noch verändert?
Bei mir hatte das File wie erwartet 0644, also für jeden lesbar.
Was gibt denn "umask" bzw. "sudo umask" bei Dir aus?

[Reinhart]

@john30

Nein, habe jetzt dein Original Script verwendet, es ist eigentlich alles von dir vom letzten Download und Compile.

Code Auswählen Erweitern


pi@raspberry2 /run $ umask
0022


LG

[john30]

@Reinhart:
Rätsel gelöst, es hat noch "/run" im Pfad des via autoconf eingestellten PID Files gefehlt. Das File wurde dadurch fälschlicherweise unter /usr/local/var/ebusd.pid abgelegt (sofern das Verzeichnis existiert).

Jetzt wandert es in /usr/local/var/run/ebusd.pid oder mit "./autogen.sh --localstatedir=/var" wie gewünscht in "/var/run/ebusd.pid".

LG John

[MilanK]

@MilanK:
Ein Dump File hilft hier nicht wirklich, weil das Timing daraus nicht ersichtlich wird und das ist das einzig wichtige. Besser wäre, den ebusd eine gewisse Zeit lang laufen zu lassen und im Log nach Problemen zu suchen.

Ach so. Ich benutze Arch Linux auf RPi B+, speichere beide Log und Dump auf Netzplatte (solange durch sshfs, später plane ich Samba dafür) und ich sehe keine Probleme (I/O,  CPU).

[Reinhart]

@John

habe das jetzt so gemacht wie du geschrieben hast und die autogen mit den Parametern aufgerufen, hat sich aber nichts geändert dadurch.

das Pidfle liegt ja schon korrekt in der /run und wird ja auch richtig beschrieben, da kann ich dir jetzt gedanklich nicht folgen.
Du brauchst dich jetzt aber nicht mehr bemühen, funktionieren tut es ja schon.

Ich bin aber gerne bereit weiter zu testen wenn du es benötigst. Oder hätte ich nochmals die Files vom Git holen müssen?

LG
Reinhart

[Reinhart]

hier noch die autogen, da gabs ein Warning.

Code Auswählen Erweitern

pi@raspberry2 ~/ebusd-master $ sudo ./autogen.sh --localstatedir=/var
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking for pthread_setname_np in -lpthread... yes
checking for pselect... yes
checking for ppoll... yes
checking for doxygen... no
configure: WARNING: Doxygen not found - continuing without Doxygen support.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking dependency style of g++... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking whether make supports nested variables... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating docs/Makefile
config.status: creating src/lib/utils/Makefile
config.status: creating src/lib/ebus/Makefile
config.status: creating src/lib/ebus/test/Makefile
config.status: creating src/ebusd/Makefile
config.status: creating src/tools/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
pi@

[john30]

@MilanK:

... und ich sehe keine Probleme (I/O,  CPU).

Super, vielen Dank für die Info!

[john30]

@Reinhart:

hier noch die autogen, da gabs ein Warning.

Code Auswählen Erweitern

pi@raspberry2 ~/ebusd-master $ sudo ./autogen.sh --localstatedir=/var
...
checking for doxygen... no
configure: WARNING: Doxygen not found - continuing without Doxygen support.
...


Das macht nichts, dann bekommst Du halt nicht die Source-Code Dokumentation

[john30]

@Reinhart:

@John

habe das jetzt so gemacht wie du geschrieben hast und die autogen mit den Parametern aufgerufen, hat sich aber nichts geändert dadurch.

das Pidfle liegt ja schon korrekt in der /run und wird ja auch richtig beschrieben, da kann ich dir jetzt gedanklich nicht folgen.
Du brauchst dich jetzt aber nicht mehr bemühen, funktionieren tut es ja schon.

Ich bin aber gerne bereit weiter zu testen wenn du es benötigst. Oder hätte ich nochmals die Files vom Git holen müssen?

Also eigentlich konnte es vorher noch nicht stimmen, weil "/run" im Pfad gar nicht enthalten war. Insofern bin ich etwas überfragt, warum bei Dir ohne frisches git pull das PID file unter /run/ebusd.pid vom binary erstellt wird. Bist Du sicher, dass das nicht ein init script tut?

LG John

[kawa0815]

Ist das wirklich so, d.h. könnte ich über ebusd tatsächlich einen Vorlauf von 150°C einstellen?
Das würde mir ganz und gar nicht gefallen. Ich dachte bisher immer, ich bewege mich hier innerhalb hardwareseitiger Grenzwerte, auf die ich keinen Zugriff habe und auch gar nicht haben will!
Selbst bei Fehlbedienung erwarte ich, dass meine Therme nur so heiß wird wie technisch sicher möglich?
D.h. gebe ich 150°C vor, dann macht die Therme halt maximal 75°C?

Ja, das ist wirklich so, man kann die 150 ° vorgeben.
Allerdings gibt es in der Therme einen Hardwareschutz "Sicherheitstemperaturbegrenzer (kurz STB). Der löst bei Übertemperaturen, in der Regel bei 110° aus.
Es reicht aber schon wenn ein bösartiger Mensch die Speicherladetemperatur auf 90° setzt oder den Legionellenschutz aktiviert.
Da kommen dann 90° aus dem Wasserhahn.

Fakt ist, das der ebusd über Telnet im heimischen Netzwerk hängt.
Jedem sollte schon klar sein, das alles was in der *.cfg parametriert ist auch über Telnet zugänglich und veränderbar ist.
Die *.cfg liegen aber in /etc/ebusd und sollten normalerweise dort nur vom root änderbar sein.

Ich hatte hier ja schon mal nach SSH gefragt, da allerdings eine recht rüde Antwort bekommen.

Jeder kann mit einem einfachen Scan feststellen wie viele Fritzboxen noch nicht gepatcht sind.
Hat man seinen Raspberry hinter so einer nicht gepatchten Box im Homenetz und setzt eine der *.csv mit allen set-Befehlen ein, ist das hochgradig leichtsinnig.

[john30]

@kawa0815:
Wenn Dir der Transport der Daten über eine Klartext-Verbindung in Deinem Netz nicht sicher genug ist, kannst Du das ja völlig problemlos über SSH Tunneln (ebusd mit Option "--localhost" starten). Dafür braucht niemand irgendeinen Code ändern.
Die Sicherheit der Config Files liegt ja auch in Deinen Händen. Und ganz ehrlich: Wenn man eine Fritzbox dafür verwendet, dann öffnet man natürlich potentiell Tür und Tor für böswillige Leute.
Ganz abgesehen davon ist alles, was wir mit ebusd anstellen, generell gefährlich für die Anlage, weil wir in ein an sich geschlossenes System eingreifen. Darüber sollte man sich schon im Klaren sein.
LG John

[Reinhart]

@John

habe alles nochmals gecheckt, aber entscheidend ist eigentlich nur /etc/init.d und hier liegt deine Dämonstartroutine!
Auch in .depend.start ist nur der "ebusd" eingetragen. meine ursprünglichen Files mit Namen "ebusd.debian" habe ich auch alle gelöscht.

Ich habe auch das letzte Firmware-Update auf beiden Raspi mit 3.18.5 drauf.

Code Auswählen Erweitern

pi@raspberry2 /etc/init.d $ uname -a
Linux raspberry2 3.18.5+ #744 PREEMPT Fri Jan 30 18:19:07 GMT 2015 armv6l GNU/Linux


wegen /run, das ist auf dem Raspi ja ein Link auf /var/run, deshalb vermute ich hat er es vorher auch schon gefunden. Das eigentliche Problem war ja nicht der Pfad, sondern nach dem Anlegen war es nicht mehr beschreibbar. Dies Problem hast du ja schon in der vorletzten Version schon gefixt.

Code Auswählen Erweitern

pi@raspberry2 /var $ ls -al
insgesamt 102444
drwxr-xr-x 11 root root      4096 Jun 20  2014 .
drwxr-xr-x 23 root root      4096 Jan 31 18:12 ..
drwxr-xr-x  2 root root      4096 Jan 14 06:25 backups
drwxr-xr-x 10 root root      4096 Jan  1  1970 cache
drwxr-xr-x 39 root root      4096 Jan  1  1970 lib
drwxrwsr-x  2 root uucp      4096 Apr 30  2014 local
lrwxrwxrwx  1 root root         9 Jan  1  1970 lock -> /run/lock
drwxr-xr-x  8 root root      4096 Feb  1 06:25 log
drwxrwsr-x  2 root mail      4096 Jun 20  2014 mail
drwxr-xr-x  2 pi   root      4096 Jan 30 15:38 opt
lrwxrwxrwx  1 root root         4 Jan  1  1970 run -> /run
drwxr-xr-x  4 root root      4096 Jan  1  1970 spool
-rw-------  1 root root 104857600 Jun 20  2014 swap
drwxrwxrwt  2 root root      4096 Apr 30  2014 tmp
pi@raspberry2 /var $


Vergiss bitte nicht die Version noch zu korrigieren, damit keine Verwechslungen mehr aufkommen, die steht noch auf 0.5.0!

Code Auswählen Erweitern

pi@raspberry2 /var $ ebusd -V
ebusd 0.5.0


Auf jeden Fall danke nochmals für deinen Fix, der Dämon funktioniert bei meinem Raspi nun bestens!
Vielleicht testet heikoh das jetzt auch nochmals, bei dem hat es ja auch nicht funktioniert.

schöne Grüße
Reinhart

[MilanK]

Ich hatte hier ja schon mal nach SSH gefragt, da allerdings eine recht rüde Antwort bekommen.

Wie anderen gesagt haben: start ebusd mit --localhost um die anderen Computern am LAN zu blockieren. Dann benutz einfach:

Code Auswählen Erweitern

[ ich@irgendwo_in_lan ]$ ssh user@ebus_comp ebusctl read OutsideTemp
1.062
Man kann auch ein SSH Schlüssel verwenden so dass keine Passwort nötig ist. Es is auch möglich die SSH Komandos weiter zu beschränken mit "command" in $HOME/.ssh/authorized_keys, um z.B. "ebusctl write -h" nicht zu benutzen können.
http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding
Ja, est kann ein bischen Overkill für ebusd Computer sein...

[MilanK]

Weiß jemand, ob dass möglich ist, die bestehende Leistung der Therme in kW abzulesen? (Vaillant / Protherm)

I habe nichts im Servicehandbuch (die Koden d.XX ) gefunden - nur die maximale Leistungbegrenzung. Doch, das Thermedisplay zeigt bis zu 5 Stuffen.
(Als Umgehung des Problems könnte ich wahrscheinlich die Gebläsedrehzahl kalibrieren.)

[Prof. Dr. Peter Henning]

Diese Leistung ergibt sich doch ganz automatisch aus dem Gasverbrauch pro Zeiteinheit.

LG

pah