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.
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.
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.
@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.
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.
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:~ $