MQTT problems with mobile phone

General
1

I know I've asked before but this is the next step/stage.

I use TASKER for my phone and apps.
I've installed the MQTT part for it and things seem to work. But not always.

The story:
At certain battery levels the phone sends messages to Node-Red.
(Note WiFi is not always on, but I'll get to that soon.)

There are x conditions:
Battery low - stage 1
Battery low - stage 2
Power connected
Batter full
Power removed.

Pretty easy.

Of course power can be connected/removed when ever.
And usually only stage 1 is invoked.

So:
The battery gets low.
"Battery low - stage 1" sent.
An LED is turned on. (Orange)
Power connected.
LED turns YELLOW.
Bater full
LED turns GREEN.
Power removed.
LED goes out.

Normally this works - in testing.

But not always.

What got me initially is that I have to turn on the phone's WiFi and wait 8 seconds before sending the message.
Fair enough I guess. Allows negotiation to happen, etc.

But the other night I connected power, the LED went YELLOW.
An hour or so later it went GREEN - Battery full.
A few minutes later I got up and removed the power.

LED didn't go out.

I invoked the phone to run the code again and it didn't go out.

This morning I did it and it did go out.

So there seems to be something else happening in MQTT, or the negotiation/comms side.

Sorry, I guess this is not the right place. It is probably more on the phone side of things.
But I have to start somewhere.

2

Where is node-red running?

Where is the mqtt broker running (and what broker are you using)?

Where is the LED that is changing colour? Dashboard? Real LED? Other?
If the LED is on the dashboard where is the browser running?

If the broker is not on the phone then are you monitoring the LWT messages from the phone so you know whether it is connected?

On the phone what will happen if it attempts to send a battery state indication to MQTT but it cannot access the broker at that time?

3

Sorry: NR on a RasPi.
MQTT Broker: RasPi.
LED driven by RasPi GPIO pin.

On the phone, I turn on the WiFi, wait 8 seconds then publish the message.

I used to have it a lot less but it seemed problematic so I increased it to 8 seconds.

I may try 10 - or greater.

Most of the time it does work if I invoke it manually.

But - as with everything I say - not always.

As to the last part: I don't know.

If it isn't connected to the broker, I think it just hangs there and waits.
But my question is given that the WiFi is in range.

4

You haven't answered that. Just because the wifi is connected does not necessarily mean it has connected to MQTT. You could flash the LED when the LWT message indicates not connected (or something else, whatever you fancy).

What makes you think that will happen? I doubt that very much, more likely it will just get lost.

Also what QoS are you using when you publish the state. If you want to guarantee it gets through (when connected) then use QoS 1 or more.

I suggest that the best thing would be to repeatedly publish the state (in the phone) maybe every minute, then you know that it will always catch up when the connection recovers (if that is the problem).

5

I'll be honest. I don't know how to do what you mean, which is probably why I am having the problem.

The code doesn't have anything written to deal with that happening.

QOS is 1

6

You have used LWT messages previously haven't you? Just make sure the client on the phone has them enabled and subscribe to them in node-red. Then you get a message each time it disconnects and another when it connects.

7

LWT only fires if it disconnect unexpectedly - it won't fire if it disconnects cleanly.

8

Yes, but not in the way you are talking.

Or I don't think so.

I have touched on something like this but for other things and the idea is way on the back burner so I am not up to speed with it.

Just saw dceejay has posted so I'll stop here.

9

I think I need a nice way/thing/trick I can use to tell the phone it is connected and the MQTT pipe is open and ready to receive.

Because now it is a bit wishy washy on how that is done.

10

True, though the node-red client allows configuration of a message on clean disconnect too. So it depends on the client. I agree, LWT may not be the full solution here.

@Trying_to_learn the simplest solution is to publish the message routinely every 30 seconds or 1 minute, or whatever you think appropriate.

11

I don't know if the Tasker app does the same. This isn't really a Node-RED question.

12

dceejay,

You may be right.

Sorry. I have to ask to work out where the demarcation lines are.

I'll have to look at it form Tasker's perspective.

Colin,

I don't want to publish it every 30 seconds. That means the WiFi is on longer than needed.
It is off unless needed.
Having a low battery isn't conducive to have/leaving on the WiFi.

I'll attack this from another angle.

But thanks both.

13

I had missed the fact that you are turning it off again. When do you turn it off?

14

The code (tasker):
turn on the WiFi - to my home network,
waits 8 seconds.
Publishes message and beeps. (makes the phone make a noise just to help me know things are happening.)
waits 8 seconds.
turns off wifi.

Most of the time it works.

Just now and then it doesn't.

I may change it to 10 seconds.... or 16.... Something bigger.

But not wanting to go crazy and leave it on for a long time.

15

In order to check whether that is the problem change it to 60 seconds before and after. Once you determine if that is the problem then you can turn it down again. If that doesn't fix it then you know that is not the problem and can look for another explanation.

Edit: Does the phone beep in the situations where it fails?

16

Yes the phone beeps even when the message isn't published.

Which only confuses me more.
I was kind of wanting that to help me know if the message was/not sent.

But yes, I shall try a bigger value and see what happens.

17

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.