Hi Ed, I missed this message. Thanks for the feedback! It sounds like a timeout problem. Can you try changing the keepAlive value (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349238) to see if that helps? I think this discussion is important to your problem https://github.com/knolleary/pubsubclient/issues/239. Hope that helps, Derek

I’m working on the MQTT examples in chapter 11 of the book. I’ve adapted them for my Raspberry Pi. Everything works except the MQTT Subscriber example shown in Listing 11-11 on pgs. 537-539 of Exploring Beaglebone.

My modifications for the RPi are simple: I changed the ADDRESS, CLIENTID and TOPIC to match my publisher program (based on your Listing 11-10). I also commented out the calls to writeGPIO.

The publisher program works great; I’ve been receiving sensor data from it using mosquito_sub for days.

Unfortunately, the subscriber program (Listing 11-11) seems to lose its connection when I publish a message using the publisher program. It prints “Connection lost, cause: (null).” Odd that the connlost() callback was passed a null pointer.

I think the connection may indeed be lost because the subscribe program does not respond to further messages from the publish program. It does end when entering Q, so it doesn’t appear to be crashed or hung.

Any thoughts?

Cheers,
Ed

This was the error message I got when trying to make cgicc-3.2.19:

pi@raspberrypi:~/cgicc/cgicc-3.2.19 $ make
Making all in cgicc
make[1]: Entering directory ‘/home/pi/cgicc/cgicc-3.2.19/cgicc’
(CDPATH=”${ZSH_VERSION+.}:” && cd .. && /bin/bash /home/pi/cgicc/cgicc-3.2.19/support/missing autoheader)
/home/pi/cgicc/cgicc-3.2.19/support/missing: line 81: autoheader: command not found
WARNING: ‘autoheader’ is missing on your system.
You should only need it if you modified ‘acconfig.h’ or
‘configure.ac’ or m4 files included by ‘configure.ac’.
The ‘autoheader’ program is part of the GNU Autoconf package:

It also requires GNU m4 and Perl in order to run:

Makefile:415: recipe for target ‘config.h.in’ failed
make[1]: *** [config.h.in] Error 127
make[1]: Leaving directory ‘/home/pi/cgicc/cgicc-3.2.19/cgicc’
Makefile:482: recipe for target ‘all-recursive’ failed
make: *** [all-recursive] Error 1

I do have 3.2.16 built so it’s not a necessity to build 3.2.19, but I do appreciate you having a look at it.

Cheers,
Ed

Hi Ed, Thanks for the great feedback. I checked my notes and I had no problem with 3.2.19 on the BB, so I’m at a bit of a loss. Have you tried a “sudo apt install autoconf”. I’m not sure why that should be missing. You should look at beginning the build in a fresh directory also (just in case!). Please send on the full message and I’ll have a look. Derek.

I was able to build 3.2.16 successfully using the steps you provided in the RPi book. They look to be the same as those on pg. 508 of the new Beaglebone book aside from the version. Yet I can’t get 3.2.19 to build due the make errors mentioned above.

Any thoughts?

Thanks for any help and for the great books!

Cheers,
Ed

Thanks Carl, really useful info. Hopefully you enjoy the new book. There is some overlap in content between Exploring Beaglebone and Exploring Raspberry Pi, particularly in the first few chapters. I have made a comparison page available on the Raspberry Pi website at http://exploringrpi.com/comparison/ so you can see what you are getting. Thanks for the support! Derek.

I’ve had a problem with WiFi for quite some time that I’ve simply lived with, but found the solution tonight, so I thought I’d share in-case anyone else has the same issue (or in-case I forget in the future!). I have had WiFi Dongle with the Ralink RT5370 chipset working on one dongle for a while…I’ve made many copies of my modified BBB image, and this dongle works on all of the devices I use (~10). Great…BUT…

When I ordered more WiFi dongles with the same chipset, none worked! I tried everything I could to fix, but nothing helped…Until tonight when I stumbled on an old piece of info on a Google Groups forum from 2013.

In it, there was the following suggestion by William Hill: “When a WiFi dongle is plugged in udev detects it and assigns it an interface name “wlan0” .. “wlan1” .. “wlan2″ etc in first come first served order. This interface name is linked to the dongle’s MAC address, so when you clone a system the new wifi dongle doesn’t get assigned the same interface name, and networking breaks. So edit the saved state file /etc/udev/rules.d/70-persistent-net.rules and delete the old entry. ”

I did exactly this and it worked perfectly, and I now can get all my various BBB systems up on Wifi using any of the dongles (provided I follow this step when not working)!

Thanks again for the great book and great site. I have pre-ordered your Exploring Raspberry Pi book and look forward to its’ release!

Carl – Michigan, USA

Hi Derek,

I did some more testing last night. I am using an android app called ‘fing’ to monitor local IP address allocation on my home network.

I have added the “ifup wlan0” in my .profile script.

If I boot the device by applying power over the 5vdc jack, I do not get an IP address appearing for the BBB.

If I connect over USB via 192.168.7.2 and login ( which causes the “ifup wlan0” to execute via my .profile script). I see an IP address appear.

Is there some other boot script, which executes prior to login, which I can add the “ifup” command to?