Hot answers tagged

6

The message above decoded: MQIsdp{03}{02}{00}{14}{00}{11}evolan_12345678900!{00}{06}evolanHello eevoLAN!à{00} It is mixed Ascii/Hex (topic, clientID and payload are plain ascii, special chars are {hex}. It turns out, that this packet always contains the connect / disconnect option (refer to this table http://docs.solace.com/MQTT-311-Prtl-Conformance-Spec/...


6

Change the last line from client.start_loop() To client.loop_forever()


5

First question: The payload of the message is limited to 268,435,456 bytes (256Mb) (see the Stack Overflow question What is the maximum message length for a MQTT broker?) Your second question doesn't make sense, but basically assuming the whole g-code is in one message it will all be delivered or not. It's up to you how you to implement the taking a ...


4

Retained messages will only be delivered once (per connection). And there can only be 1 retained message on a given topic at any one time. So just connect, start the loop and subscribe to the topics you are interested in. When the message is delivered check the retained flag on the messages. If the message is retained then you can publish a new message ...


4

The code that handles the max_queued_messages is here if self._max_queued_messages > 0 and len(self._out_messages) >= self._max_queued_messages: message.info.rc = MQTT_ERR_QUEUE_SIZE return message.info This looks like it does not bump any messages out of the queue and the it is up to you to handle storing this new message if you still want ...


3

You are facing these build errors as you are missing the sysroot corresponding to the arm-gcc that you are using as your CC. You may try changing the Makefile as follows: diff --git a/Makefile b/Makefile index 49cbb13..1123f27 100755 --- a/Makefile +++ b/Makefile @@ -67,7 +67,7 @@ endif ifeq ($(OSTYPE),Linux) -CC ?= gcc +CC ?= /path/to/arm-linux-gnueabi/...


2

There may be paths with a MTU of 1280 in the way. Try 1100 or 1200 and see if that fixes it. If not, try to find an MTU finder app to try to find the MTU to your destination from your source.


2

Based on what we've seen in the comments and edits, I think it might be worth setting a lower MTU for the cellular link. Try running something like the following: nmcli con mod "user_apn" gsm.mtu 1300 This should cause the MQTT client (in combination with the network stack) to break packets up into smaller chunks which hopefully should be able to ...


2

The Paho Python library will work just fine via LTE. The library is built to interact with the OS's TCP/IP stack. It has no knowledge of the underlying hardware of how that TCP/IP stack talks to the outside world. If you want it to work you need to have the LTE connection presented as a network device to the OS, not just a serial port. I suggest you go ...


2

You should not be running long running (infinite loops) in the callbacks. All the callbacks run on the client network thread's main loop (the one started by client.loop_forever()). This means if the on_connect() thread never returns it will never get to handling the calls to client.publish() in the loop. The individual client.publish() calls work because ...


2

This is because the message payload is way bigger than will fit into a single TCP packet so the problem is that you are not starting the Paho client network loop which will chunk the message up and stream it out to the network. You have 2 choice. First start the network loop in the script. This is best if you are planning on sending multiple images. ...


Only top voted, non community-wiki answers of a minimum length are eligible