Try setting keepalive=60 as an argument for MQTTClient, that fixed it for me
umqtt.simple using websockets
I have an existing - working - MQTT application using Paho-MQTT and Websockets.
I am working on a new device, which lacks the memory to use Paho-MQTT, but I cannot get umqtt.simple to work with Websockets.
The only example I could find showed setting up the websocket, then setting e.g. cleitn=MQTTClient(<clientid>, <server>, sock=websocket, port=<port>), which fails irrespective of how "sock" is set.
Is there a way to use the websocket protocol with umqtt.simple?
Many thanks,
umqtt.simple not working with Mosquitto broker 2.0.15
Hi!
umqtt.simple fails to connect to mosquito 2.0.15. It throws back MQTTException: 2.
My mosquitto log without any errors. The logs displayed are the same as when connecting to the server using the MQTT debugger(An app), so, maybe my mpy device is connected to mosquiro broker? But how to fix it?
By the way, my MQTT debugger was able to successfully connect to the mosquito without any errors, including publish and subscribe messages
my device: nodemcu-8266(12F) from Espressif
my mqtt server: Mosquitto broker 6.2.0 in homeassistant(VMware)
thanks, it's working for me too
As Mosquitto is very common, maybe it makes sense to raise the default keepalive to that?
Afaik it's caused by an update to mqtt protocol that requires this argument to be specified. It's not related to the default value. But I don't understand it much
The official umqtt.simple from micropython-lib does not support setting the 'sock'.
Only client_id,server, port, user, password, keepalive, ssl is possible.
Also umqtt.simple uses a normal socket. When using Websockets, all MQTT packets are wrapped in a Websocket packet so it is not possible, without significant modifications, to use it in umqtt.simple.
I have made a async MQTT-client using Websockets. I use a patched version of aiohttp. The modifications to aiohttp were necessary because aiohttp does not accept headers (which are needed for almost every broker). Even then, aiohttp can still be blocking because the used getaddrinfo is still a blocking function, therefore I use my own developed, fully async, version of getaddrinfo.