john30 / ebusd

daemon for communication with eBUS heating systems
GNU General Public License v3.0
560 stars 130 forks source link

mqtt server only receives "false" on ebusd/global/running #231

Closed AnhDuc85 closed 5 years ago

AnhDuc85 commented 5 years ago

Hi, ebusd has been built by using the wiki page including libmosquitto-dev. Whenever I start ebusd with mqtt options: ebusd -d /dev/ttyebus -p 8888 --loglevel=info -l /var/log/ebusd.log --scanconfig --configpath=http://ebusd.eu/config/ --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=192.168.2.80 --mqtttopic=ebusd/%circuit/%name --mqttuser=ebusd --mqttpass=PASSWORD --foreground ...all I receive on my mqtt host is: "false" on ebusd/global/running. There's no problem when running ebusd from the docker image. Any idea?

Here's the output of ./autogen.sh:

autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 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 configure.ac:135: installing 'build/ar-lib' configure.ac:9: installing 'build/compile' configure.ac:133: installing 'build/install-sh' configure.ac:133: installing 'build/missing' src/ebusd/Makefile.am: installing 'build/depcomp' autoreconf: Leaving directory.' checking for gcc... gcc 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 gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes 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 minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define EXTENSIONS... yes checking for g++-6... g++-6 checking whether we are using the GNU C++ compiler... yes checking whether g++-6 accepts -g... yes checking whether g++-6 supports C++11 features by default... 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 clock_gettime in -lrt... yes checking for pselect... yes checking for ppoll... yes checking linux/serial.h usability... yes checking linux/serial.h presence... yes checking for linux/serial.h... yes checking for argp_parse... yes checking argp.h usability... yes checking argp.h presence... yes checking for argp.h... yes checking for mosquitto_lib_init in -lmosquitto... yes checking for direct float format conversion... 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 whether make supports nested variables... yes checking dependency style of gcc... gcc3 checking dependency style of g++-6... gcc3 checking for ar... ar checking the archiver (ar) interface... ar checking for ranlib... ranlib checking whether make supports nested variables... (cached) yes checking that generated files are newer than configure... done 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 src/lib/ebus/contrib/Makefile config.status: creating src/lib/ebus/contrib/test/Makefile config.status: creating config.h config.status: executing depfiles commands

I receive 2018-12-16 11:39:50.210 [mqtt notice] connection established when I start ebusd.

Any idea?

schka17 commented 5 years ago

same issue here, wanted to move my smarthome installation to another box and followed the wiki to compile ebusd with mqtt option. I'm running latest debian and mosquitto version, the "old" ebusd from the old machine can connect and is pushing, but the new compiled ebusd doesnt push any message. i tried to run ebusd --scanconfig -f -d 192.168.255.70:5000 --enablehex --mqtthost=192.168.99.19 --mqtttopic=ebusd/%circuit/%name --mqttchanges --latency=10000 --receivetimeout=100000 --sendretries=3 -p 8888 -l /var/log/ebusd.log but i did not receive any message on the mqtt server

john30 commented 5 years ago

what is the version of libmosquitto-dev? what does ebusd report regarding mqtt? any errors?

schka17 commented 5 years ago

libmosquitto-dev/stable,stable,now 1.4.10-3+deb9u2 amd64 [installed]

absolutely no errors from ebusd, working without problem and receiving messages from the device, gaebus (FHEM) is connecting and working, but nothing pushed to mqtt. But i have the same issue with the docker container. looking in the mosquitto log i cant see any connection, not even an error, testing with mosquitto_pub and sub verify that mqtt is working and i can see the connections in the logfile

AnhDuc85 commented 5 years ago

same here: 1.4.10-3+deb9u2 grep 'mqtt' ebusd.log -> [mqtt notice] connection established thats all regarding mqtt

john30 commented 5 years ago

does your MQTT server require authentication or TLS?

schka17 commented 5 years ago

not in my case, no tls, no authentication. just checked my old server installed 2years or so ago is using 2018-12-15 14:19:48.159 [main notice] ebusd 3.0pre.15d5500 started, same config, is working

schka17 commented 5 years ago

new server

root@hal9000tng:~#  cat /var/log/ebusd.log |grep connec
2018-12-16 12:35:17.572 [mqtt notice] connection established
2018-12-16 12:40:45.377 [mqtt notice] connection established
2018-12-16 12:46:08.441 [mqtt notice] connection established
2018-12-16 12:51:32.900 [mqtt notice] connection established
2018-12-16 13:00:11.737 [mqtt notice] connection established
2018-12-16 14:35:41.459 [mqtt notice] connection established
root@hal9000tng:~# cat /var/log/ebusd.log |grep started
2018-12-16 12:32:08.314 [main notice] ebusd 3.2.v3.2-21-g7d10104 started with auto scan
2018-12-16 12:32:08.535 [bus notice] bus started with own address 31/36
2018-12-16 12:35:17.308 [main notice] ebusd 3.2.v3.2-21-g7d10104 started with auto scan
2018-12-16 12:35:17.560 [bus notice] bus started with own address 31/36
john30 commented 5 years ago

I guess it is related to the mqtt server or library version. since you seem to have both available, please check the versions and also check if the new server maybe has some firewall active. can you publish/subscribe directly from the ebusd host by using mosquitto tools?

AnhDuc85 commented 5 years ago

I've install mosquitto tools on my pi zero where I'm running the ebusd and no problem to publish a message with this command: mosquitto_pub -h 192.168.2.80 -m "TEST" -t ebusd/global/running -u ebusd -P PASSWORD My broker receives the message.

No firewall, no TLS, just user and password.

schka17 commented 5 years ago

old server hal9000 192.168.99.9 new server hal9000tng 192.168.99.19

new server: no firewall, Verfied -> mosquitto_pub and mosquitto_sub is working local and from remote machine. versions: libmosquitto-dev/stable,stable,now 1.4.10-3+deb9u2 amd64 [installed] libmosquitto1/stable,stable,now 1.4.10-3+deb9u2 amd64 [installed,automatic]

starting ebus on the new server connecting to mqtt on old server: ebusd --scanconfig -f -d 192.168.255.70:5000 --enablehex --mqtthost=192.168.99.9 --mqtttopic=ebusd/%circuit/%name --mqttchanges --latency=10000 --receivetimeout=100000 --sendretries=3 -p 8888 --loglevel=info -l --configpath=http://ebusd.eu/config/ -l /var/log/ebusd.log

no messages.

start ebus from old server to mqtt on new server: root 4964 1 0 19:56 ? 00:00:00 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig -d 192.168.255.70:5000 --mqtthost=192.168.255.19 --enablehex --mqttport=1883 --mqtttopic=ebusd/%circuit/%name --latency=10000 --receivetimeout=100000 --sendretries=3 -p 8888 -l /var/log/ebusd.log

i can see the messages on the new mqtt server: ebusd/700/PrEnergySumHc 20 ebusd/700/HwcTempDesired 55.00 ebusd/bai/PowerValue 10 04 53 14 64 18 ebusd/700/OpMode auto ebusd/700/Hc2Status 1 ebusd/bai/HwcDemand no ebusd/700/Hc1FlowTemp 66.94 ebusd/700/Hc2FlowTemp 44.94

old ebusd is publishing on old and new server new ebusd is doing neither

john30 commented 5 years ago

not sure if I understand your comment thoroughly. you write "i can see the messages on the new mqtt server" so does that mean it works or what?

schka17 commented 5 years ago

No, doesnt work, i mean the ebusd daemon on the old server can publish to the new server as well,but the new ebusd on the new server doesnt publish anyhing, neither the new server nor the old server i even cannot see any traffic with tcpdump. Just wanted to clearify if the issue is with the mqtt server on the new server, which is not the case.

AnhDuc85 commented 5 years ago

thank you, works like a charm