WiFi events and strange going on's

That statement makes little sense to me. What is a 'channel'? What do you mean by the broker monitoring the channels?

I was wrong about the shutting down message as that is actually sent by the pi at a normal disconnection, such as a power down, I assumed you were talking about the actual LWT message, which is the Comms Failure one.

I see you have not got the Retain flag set on the LWT topics, so what I said about a client connecting later is also wrong. You can only rely on clients will only get those messages if they are actually connected when the event occurs, though I think the broker will buffer up some messages so you may get them if the event occurs during a temporary disconnection (of the client).

Urm, why do you want 2 WAPs? That seems overly complex and error prone. As you already point out, there is a decent chance they are already fighting each other for channels, especially if you live in a crowded environment as we do (surrounded by a mixture of professionals and students).

Just use your router which should (if it is a decent one) be much better able to manage the connections. Better still, ditch the usually relatively rubbish WiFi (but still likely better than using a Pi) on consumer routers for a dedicated AP such as the Ubiquiti Unifi AP's.

If you need to isolate IoT traffic, you should be able to use VLANs to do that.

Do you already have a name for your system? If not, i would call it:

Keep owner busy machine (Enterprise Edition v7)

:slight_smile:

3 Likes

The "channel" or TOPIC? Ok. Topic (from MQTT node)

TotallyInformation:
Why? Well there is the modem's WAP. That gives internet access to anything that connects.
I have a "local WAP" which is only connected to my network.
It will only have stuff like the Arduino connected, and other LOW TRAFFIC stuff.
These devices will not be visible on the bigger internet. Not being paranoid. But I wanted to learn about using the RPI as a WAP.
(Yeah, I'm trying too much probably.)

Yeah, VLANs are on the Radar for use. Just not there yet and weren't possible a long time ago.
So a separate WAP seemed the easy way to go.

Moebius.. Yup. I get it.
The RPI WAP Is called .... PiNet.
My main WAP is...... Oh, gee. I don't really know. All the devices which need to access it know the name, so I just connect when needed.

Here is another example of weird MQTT messages.

Though this isn't leading to the RPZ(w) being hung, the messages confused me to why they were sent.

This morning I turned on THIS machine. (NUC) Logged on to the RPZ NR page.
It is still running.

I turned THIS machine off about 7 minutes later.
Then around 12:20 for a while, then off soon there after.
And lastly at 16:.....

Look at the birth/death certificates. (SOM/EOM)

Yet neither of the two machines were turned off at those times.
It is still up and working.

Anyone one know why these messages would be sent?

Screenshot%20from%202019-07-05%2017-00-37

The Will message is sent when an mqtt client drops it's connection. The Birth message is sent when the mqtt node reconnects. That is it. There are no other events that would trigger those messages.

Therefore these events represent times when the client lost its connection and reconnected.

We cannot say any more then that. Something has caused the connection to drop. If you are sure the devices didn't reboot, then something else has interrupted their network connection.

You could check the Node-RED log and the broker logs you will see what they report around these times.

Thanks.

Just very interesting that these co-inside with me turning THIS machine on/off.

It has been suggested that the RPI says "There's no more happening, so I will close the MQTT connection".

Yeah, but every ..... 18 seconds there are broadcasts from the broker and that machine is subscribed to some of those channels.

I am looking at a log file I have logs from a device which are time stamped and I have them every minute from 06:00 today until now.

Longer but for the sake of what I just said.

So....... Interesting.
Why is it doing what it is doing?

I have looked at the node-red log/s and to the best of my knowledge there is nothing obvious there.

Where is the broker logs?

Googling node-red broker log I see stuff about logging data. Not too much about looking at the broker's log.

broker

mqtt broker log.

(I know.....)

bakman2...

pi@TelePi:~ $ mqtt broker log
-bash: mqtt: command not found
pi@TelePi:~ $ 

I've tried from a few places, but I don't know where I need to be.

I've looked and there are reverences to /etc/init.d/mosquitto Nothing there.

I'm lost.

@bakman2 please try to use full sentences when replying... Makes it much less likely to cause further confusion as you have just done.

@Trying_to_learn what broker are you using? Mosquitto? How did you install it? Have you googled for mosquitto logging or something similar? I don't know off the top of my head where mosquitto writes it's log file.

Nick,

Yes, I have tried, but the search results are about how to log data.

Other searches are talking about /etc/init.d/mosquitto
One

Two

Three

But none explain where the log file is - that I can find.

To the best of my knowledge it is the "standard" MQTT that comes with NR.
At worst, it would be one which was mentioned in link 3 - I think. I don't really remember as originally it was on stretch and I updated the machine to jessie and reinstalled NR.
So a lot has happened since then.

There is no such thing. Node-RED does not include an mqtt broker, you must have installed something.

Ok, I did. It works, and I did all the tests as per the third link.

This for instance:

Terminal window 1:

Code: Select all

mosquitto_sub -d -t hello/world

Terminal window 2:

Code: Select all

mosquitto_pub -d -t hello/world -m "Greetings from Terminal window 2!"

Works.

(Ok, it did work. I just tried them now and they don't work. But MQTT in NR is working.)

But when I do the mqtt broker log (be that a command) it doesn't work.

If it is a file..... where is it?

All the stuff I searched pointed to non-existent files.
eg: /etc/init.d/mosquitto

So I'm still in the dark, sorry.

Don't fret too much. I don't want/expect you to drop everything and answer the question here/now.

I'm just asking because I'm stuck with what is going on. I hope though that at the end I learn something and it is helpful to others.

I do not want to cause confusion, the 2nd link you found has a FAQ about the log:

more /var/log/mosquitto/mosquitto.log

(many logs can be found in /var/log).

The detail of logging can be configured in /etc/mosquitto/mosquitto.conf or /etc/mosquitto/conf.d/<filename>.conf by using the log_type option as described in the documentation

mosquitto.conf also specifies the log location (in case it is not in /var/log/mosquitto)
So if you do a cat /etc/mosquitto/mosquitto.conf you see something like:

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d
pi@TelePi:~ $ pwd
/home/pi
pi@TelePi:~ $ more /var/log/mosquitto/mosquitto.log
more: stat of /var/log/mosquitto/mosquitto.log failed: No such file or directory
pi@TelePi:~ $ 

Sorry. Not here.

pi@TelePi:~ $ cat /var/log/mosquitto/mosquitto.log
cat: /var/log/mosquitto/mosquitto.log: No such file or directory
pi@TelePi:~ $ cd /var/log
pi@TelePi:/var/log $ lf
apt/                   auth.log       btmp.1           debug.2.gz      kern.log       messages.2.gz             syslog.2.gz  user.log.2.gz
cups/                  auth.log.1     daemon.log       debug.3.gz      kern.log.1     messages.3.gz             syslog.3.gz  user.log.3.gz
lightdm/               auth.log.2.gz  daemon.log.1     debug.4.gz      kern.log.2.gz  messages.4.gz             syslog.4.gz  user.log.4.gz
samba/                 auth.log.3.gz  daemon.log.2.gz  dpkg.log        kern.log.3.gz  nodered-install.log       syslog.5.gz  wtmp
wicd/                  auth.log.4.gz  daemon.log.3.gz  dpkg.log.1      kern.log.4.gz  nodered-install.log.1     syslog.6.gz  wtmp.1
alternatives.log       boot.log       daemon.log.4.gz  dpkg.log.2.gz   lastlog        nodered-install.log.2.gz  syslog.7.gz  Xorg.0.log
alternatives.log.1     bootstrap.log  debug            faillog         messages       syslog                    user.log     Xorg.0.log.old
alternatives.log.2.gz  btmp           debug.1          fontconfig.log  messages.1     syslog.1                  user.log.1
pi@TelePi:/var/log $ 

Hereā€™s you old post where you were editing it

1 Like

Interesting indeed, could you check /etc/mosquitto/mosquitto.conf

Ah, but that is on a different machine.

That is TimePi. I am now asking why TelePi is sending these weird messages.

I shall go and look at TimePi if the file exists there - to be sure.

This is what I see:

pi@TimePi:/var/log $ ld
apache2/  apt/  lightdm/  mosquitto/  ntpstats/  samba/
pi@TimePi:/var/log $

Note: TimePi

Now TelePi:

pi@TelePi:/var/log $ ld
apt/  cups/  lightdm/  samba/  wicd/
pi@TelePi:/var/log $ 

There is mention of a mosquitto.config but I can't find it either.

MQTT is working on that machine.
0.93 is TelePi

Not only is it receiving data every .... 10 seconds. Every 18 seconds it transmits CPU temperature and CPU load back to 0.99 (TimePi)

I'm now getting confused.

Which machine is running mosquitto? Or are you running it on every one of your devices?