MQTT reconnect help

I'm testing against test.mosquitto.org. Every so often I get disconnected - which I imagine is from the server and is to be expected, as I think they regularly rollout the latest version.

I have a disconnect event I can listen on, and currently I reissue mqtt.connect() in the events callback. My problem with this approach is that I'm losing memory. It might survive one reconnect, but not two. I have duplicated message listeners which I imagine is part of the memory problem.

I considered another approach would be to save to memory and fire the reset() function, to bring the board and whole program back up?

But is there any pattern/approach that I could use to recover without a restart?

Edit: I've just considered that maybe I should unbind the listeners in the disconnect event callback too?

I think I need unsubscribe, to clean up, then reconnect

Could be... I wonder if you're keeping a reference to the MQTT connection somewhere? Any reference would mean that all the listeners and everything would be kept around, even after the disconnection?

You could try trace() and see if you could figure out what was referencing your functions? It's a bit cryptic, but if you posted the results here I might be able to help.

@Gordon, very likely, and I think the way I've setup my code is not helping me clear and reinstantiate it. I'll have a look at that first before I waste any of your time here.

Yes. The way I was setup I could destroy the object but then I lost the listeners, so I've moved the whole thing including require, connect and the listener bindings into their own wrapper method which I recall on disconnect event. Appears to be working well with my triggering disconnect, so hopefully works when server triggers it. Thanks for the steer @Gordon

Almost 24 hours now. Best I had before was about 14, so I'm hoping I can ride out server disconnections now :)

hey @Ollie would you mind sharing the code how do you do it. I am haveing the same exact problem.

Thanks
Navas

I think you've got the tinyMQTT module yes? That's the best code I have, although there's a bit of activity in the issues re "keep alive".

I've had long running connections with the module, others have too, but I haven't used it a quite a while

@Ollie, thanks for fixing the double reconnect and activating the keepalive.

Appreciate much!

Thanks
Navas

@navas thanks, but wasn't me. A couple of pull requests have improved it - authors mentioned in the credits.

Great to hear it's better though. Still fairly small at 1.45kb too :)

right, that's what making it special, so that I can run in ESP-01 (1MB) version

Hi Ollie

I'm somewhat behind you on this having just gotten MQTT working - and discovered the same thing as you - it disconnects, doesn't reconnect and doesn't keep the subscribes. Care to share to save hours of duplicated effort??

Pete.

@Scargill. Hello there! How are you approaching it? Generally, I put a call to connect in the disconnect event handler. Which module are you using? Myself and others have had good success with this cut down module (https://github.com/olliephillips/tinyMQT­T).

So something like this:

mqtt.on("disconnected", function(){
	console.log("disconnected");
	mqtt.connect();
});

At the time of the espruino to ESP8266 port, there wasn't the room for the full MQTT module, though we now have 1700 jsvars I think some have squeezed it in, but can't save much application code.

Hi there Ollie

That looks good - can't test it - I've put my stuff away for travelling.... that looks good -but - and this is a guess - should that routine now also include any subscribes that you have lost... and if so is there a way to call that routine normally so that we don't duplicate code.. so perhaps that on disconnect could call a routine with the connect and subscribes - and that routine could also be used at startup??? I'm assuming in all of this that the WIFI reconnects automatically?

Hopefully early next week I can settle down in my office in Spain and try all of this out.

I'm also at a loss as to why the limited space for code - given that the ESP12 has 3 meg spare? I wonder if there are any plans to check for that and expand user space accordingly?

Re space - I think a part of it is that the port was designed to accommodate the entire ESP8266 family, including the ESP8266-01. You can use that flash, but as a key/val store. save() doesn't use it all.

Re the module, and subscribe reconnection. It's been a while since I've used, but I seem to think subscriptions resume or at least aren't cancelled by the disconnection, but don't hold me to that. Please feedback how you get on.

BTW the Espruino Gitter channel might be useful. There are people in there who know more about the ESP8266 port than I, so could advise what might be possible on the space front, there's also one user of ESP8266/tinyMQTT who's been managing his home with it for 12 months, so he'd be a good person to pick up with.

@Scargill

I'm also at a loss as to why the limited space for code - given that the ESP12 has 3 meg spare? I wonder if there are any plans to check for that and expand user space accordingly?

The esp8266 has bags of FLASH, but bugger all RAM. There is only 80K and a lot of this is taken up by the OS and interpreter. Quite a bit of work has been done to strings into flash to free up precious RAM. The amount of save() code space is 12K compressed, so this works out to be about 20K of js code.