Problems using RSMB 1.2.0 on NSLU2 (Unslung)...

[Per Kreipke]

Hi,

I suspect I'm out of luck finding an updated version but I've installed and run the RSMB 1.2.0 build from the IBM DeveloperWorks site - no other build for Unslung seems to exist of the newer code post-move to mosquito.

It runs successfully, is configurable and handles pub/sub events from stdin/stdout using the supplied command line test tools.

However, if I try to connect with the Paho Python client, I never succeed in connecting properly. The socket seems to be created: I get " Socket error on socket 4, peer address 127.0.0.1:4476; ending connection" from RSMB when I kill the paho process on the other end.

But "on_connect()" never fires in paho. When I bump up the trace levels in the RSMB config, I still don't see anything useful.

So, wondering:

- has anyone has successfully compiled the latest RSMB for Unslung on the NSLU2?

- does anyone know what might be wrong? Protocol version, etc?

- can I bump up the debug / trace level in Paho too?

- I can't figure out which MQTT protocol version rsmb 1.2.0 is running that might cause this

The NSLU2 has been a nice useful box for a long time and is kind of perfect for my kids to use their python skills and playing with home automation and MQTT. Sure, I could get a different "always" on box to use but hey, had this one sitting handy :-) Perhaps should junk it and use cloud MQTT server but I'm a hoarder.

Thanks for any advice,

Per

[Roger Light]

Hi Per,

Could you try setting the Python protocol version to MQTTv31 when you
connect? The client connects with MQTTv311 by default, but then if the
broker disconnects it with an "incorrect protocol version" message
will retry with MQTTv31. If RSMB just disconnects clients with the
incorrect protocol version, then it can't detect this and will attempt
to reconnect without any changes. I'm not entirely sure what the best
general solution should be!

You could do:

import paho.mqtt.client as paho

c = paho.Client(protocol=paho.MQTTv31)
...

Cheers,

Roger

> --
> To learn more about MQTT please visit http://mqtt.org
> ---
> You received this message because you are subscribed to the Google Groups
> "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.

[Per Kreipke]

Roger,

Thanks for your time and attention, much appreciated.

c = paho.Client(protocol=paho.MQTTv31) 

Continued testing using the Paho Python client paho.mqtt.publish on my NSLU2:

- added protocol=pah.MQTTv31 to publish() call: no change

- switched to full paho.mqtt.client based code (e.g. wired up all events, did separate connect() and loop_forever()): no change

Then installed Mosquitto on my Mac.

Double checked - same Paho Python client from NSLU2 to Mac:

- worked fine, published to the mosquito server

Ran Paho Python client on Mac to broker on NSLU2:

- same problem, hung

So, seems to confirm it's a problem with the broker.

Then turned on "trace_level stdout", and ran everything on NSLU2 again. This sequence here seems to be the problem:

- using this codebase as a reference to "guess" at what's under the covers

https://github.com/doceme/org.eclipse.mosquitto.rsmb/blob/master/rsmb/src/MQTTProtocol.c

- since missing from "stack trace" below, it seems like the connect handler is never called

Regards,

Per

20140806 122513.159   (2)> MQTTProtocol_checkPendingWrites:340

20140806 122513.219   (2)< MQTTProtocol_checkPendingWrites:357

20140806 122513.219   (2)> MQTTProtocol_timeslice:394

20140806 122513.219 4 unknown About to read packet for peer address 192.168.1.163:55717

20140806 122513.219    (3)> MQTTPacket_Factory:118

20140806 122513.219     (4)> Socket_getch:751

20140806 122513.219      (5)> SocketBuffer_getQueuedChar:190

20140806 122513.219      (5)< SocketBuffer_getQueuedChar:209 (-2)

20140806 122513.219      (5)> SocketBuffer_queueChar:270

20140806 122513.219      (5)< SocketBuffer_queueChar:294

20140806 122513.219     (4)< Socket_getch:772 (0)

20140806 122513.219     (4)> MQTTPacket_decode:248

20140806 122513.219      (5)> Socket_getch:751

20140806 122513.219       (6)> SocketBuffer_getQueuedChar:190

20140806 122513.219       (6)< SocketBuffer_getQueuedChar:209 (-2)

20140806 122513.219       (6)> SocketBuffer_queueChar:270

20140806 122513.219       (6)< SocketBuffer_queueChar:294

20140806 122513.219      (5)< Socket_getch:772 (0)

20140806 122513.219     (4)< MQTTPacket_decode:263 (0)

20140806 122513.219     (4)> Socket_getdata:790

20140806 122513.219      (5)> SocketBuffer_getQueuedData:150

20140806 122513.241      (5)< SocketBuffer_getQueuedData:175

20140806 122513.241      (5)> SocketBuffer_complete:245

20140806 122513.241      (5)< SocketBuffer_complete:255

20140806 122513.241     (4)< Socket_getdata:824

20140806 122513.241    (3)< MQTTPacket_Factory:150 (0)

20140806 122513.241   (2)< MQTTProtocol_timeslice:469

20140806 122513.241   (2)> add_prefix:746

20140806 122513.241   (2)< add_prefix:753

[Ian Craggs]

Per,

can you compile programs for the NSLU2?  If so, you can build RSMB, or maybe Mosquitto for it from the Eclipse Mosquitto repositories.  As far as I remember, there were different versions or types of the OS run on the NSLU2.  Builds for one OS didn't necessarily run on another - sometimes the symptoms were exactly as you describe.

Ian

[Per Kreipke]

Ian,

Good point. I was pretty sure this build was listed on developerworks as being for the Unslung O/S but their site is down last I went to double check. Will check again.

No, I can't cross compile for Unslung on the NSLU2, nor gotten native compiling to work yet. In fact, in all my years of programming, never cross-compiled anything :-). But that was going to be my next step since I see no other RSMB builds out there for this old device before I ditch it and buy a RPi.

If I get it working, will let you know.

Which broker should I try for: RSMB or Mosquitto?

Thanks,

Per

[Per Kreipke]

Ian,

From Developerworks:

"Unslung (Linksys NSLU2)"

But I see your point - there were a bunch of different architecture folders in the zip file and perhaps I've chosen the wrong one. I chose the broker in the "slug" folder but there were also:

linux_ARM_glibc

linux_ARM_uslibc

linux_ia32

linux_ia64

zlinux

First thing I did was run the "broker" in the "mac" folder and it worked almost perfectly: I was able to connect to it using the same paho publish and client python test scripts. To Roger's point, I got a protocol error, even when I set the protocol down to mqttc.MQTTv31:

20140806 181920.266 CWNAN0032W Connection attempt using unsupported protocol MQTT version 4 received

20140806 181920.287 CWNAN0033I Connection attempt to listener 1883 received from client per on address 192.168.1.30:4523

But the pub / sub worked (subscriber was the stdoutsub executable, also on the Mac).

I'm going to figure out if one of the others listed above works - I'll admit my ignorance at this point to the correct architecture to use.

Per

[Per Kreipke]

linux_ARM_glibc

linux_ARM_uslibc

linux_ia32

linux_ia64

None worked. 

 

zlinux

IBM z systems, didn't work either :-) 

Per