umqtt vs/and socket connection

[fishjoe]

Hi everyone.

I'm using pico w.

I'm trying to write some code respond to both umqtt and direct socket connection via LAN (DSC).

Now if I wasn't wrong, umqtt subscription and msg_check library were written with socket as well, wasn't it?

Therefore, when I write code to check message, can I write one piece of code to check any incoming msg, and determine if it is mqtt msg or wlan DSC msg, then parse through the message body and respond on it?

I haven't start testing. But I think in one loop if I let the code to check both umqtt and DSC would it cause some crash, or extra power consumption on the device?

Any explanation would be appreciated.

Zhou

[peterhinch]

What you want to do is possible, but it does need some grasp of asynchronous coding. You'll need to run an asynchronous MQTT client concurrently with your asynchronous code for maintaining communications on the LAN port. This will probably need to use nonblocking sockets, as used in the asynchronous MQTT library.

[cwalther]

While asyncio will certainly make things easier in the long run, and Peter’s MQTT client has other advantages over umqtt, it is totally possible to do other things concurrently using umqtt and without asyncio. You just call MQTTClient.check_msg(), which does not block, periodically instead of MQTTClient.wait_msg().

You don’t “check any incoming msg, and determine if it is mqtt msg or wlan DSC msg”, you make your own socket for your own messages, on a different port. There is no interference between the two, you just need to check both.

[peterhinch]

The official clients are not truly asynchronous. For example, publications with qos==1 block until the handshake is complete.

[cwalther]

Good to know, thanks. That’s a case I haven’t used myself.

[fishjoe]

Thank you everyone I have got it working.

Just to add a little bit of info, as I have discovered an issue:

I'm using HiveMQ, When I put MQTTClient.wait_msg() in the loop, it works at the beginning then stoped responding to my message after a while. I guess there is a timeout function on the server which disconnect when it is not responding. I wish to know if there is a better way to avoid this happen.

What I'm doing know is adding another line : MQTTClient.subscribe("test") before MQTTClient.wait_msg()

By resubscribe to the same topic it sort of wakes up the connection.

[peterhinch]

The broker will time out if it has no communication with the client for longer than the "keep alive" time. The client should detect that it hasn't communicated for a while and send send a PINGREQ packet to prevent the timeout from occurring. The official clients do not do this. What you are doing is a workround. It is probably OK so long as you don't plan to use the "last will" feature of MQTT.