[Upcycle It] WiFi Connected Smoke Detector #3: Connecting dots - MQTT + Node.js + Slack

Hi Jason,

Thank you a lot for the feedback.

I've started coding. I'll publish my Node.js code this week. Here is the part responsible for subscription to smoke detector alarms state/connection state from any location.

client.on('connect', () => {
  //subscription to smoke detector alarms and connection states from any location
  client.subscribe('+/alarm/smoke/+')
  //subscription to alarms monitors connection states from any location
  //this subscription is useful for logging/testing
  client.subscribe('+/alarm/monitor/+')
  
  const monitor_topic = 'home/alarm/monitor/connected';
  // publish a message to a topic - "The home alarm monitor is connected"
  client.publish(monitor_topic, 'true', function() {
    console.log("Home alarms monitor connected");
  });
})

I prefer not to set device name at root of topic tree as devices may change over time. This change may force changes to all connected devices, which need to publish to any topics on the tree. Please note, that current MQTT standard only allows use of wildcards for subscriptions, but not for publications. So to limit any significant impact of such changes the topic structure should be more stable at least near root of the tree.

MQTT specification includes Keep Alive feature. And Mosquitto implements it as well. In addition to Keep Alive, there is a Last Will and Testament (LWT). It allows MQTT client request the broker to publish a message to a specified topic when connection get unexpectadly lost. Here is a good description when it gets triggered:

• An I/O error or network failure is detected by the server.
• The client fails to communicate within the Keep Alive time.
• The client closes the network connection without sending a DISCONNECT packet first.
• The server closes the network connection because of a protocol error.

# are multi level

+ are single level

so subscribing to #/sensor/smoke/# would have been better.

I have one node running ESPEasy (outdoor temperature) and it is odd in how it reports.  Wild cards do not work correctly on it.

Hi Jason what's the difference between # and + in the wildcards?

Very good write up and thought into your topic.  I really like the idea, and I have never done this, is put in if a device type, assuming it is only doing one function.   But in reality, the MQTT topic for each sensor inside a device and be specific to what it does.  Then in the future you can monitor based off this structure.  So your Node application, can listen for #/#/smoke/state and get state changes for all locations.  Then query a database to see what to do based off the structure of the topic.  Only suggestions I would make would be the following.

1. Work in a device name or indicator to the structure. I think this would be at the start of the structure, since it is the most broad level you will have.  For example, I have a light controller in my basement, well it also monitors current flow to my 80 tower, so I know when power is out to the tower.  It controls lights for several devices around my home.  So all of it's MQTT topics start with rpi01/...  This way I know what device is doing what and do not need to refer to a document to find what device has that message and command.  Full example like you gave above based off an Edison with IP reservation ending in 138:
   "Eddy138/kitchen/alarm/smoke/connected"
2. With this example a device might have several locations or might not.  Most likely it will have several functions, like sensor or alarm or power. Also several types and commands|state
3. Not really MQTT topic structure important, but it will be done via MQTT. One needs to know when sensors are not responding, so I think the best way to do that is with heartbeats being sent out on a regular basis. Last thing you want is a fire that was not detected, because a sensor has stopped working two months ago. If the Edison stops working or gets powered off, it does not send out it's heartbeat and a process at central command can monitor for this heartbeat and alert you when a device is non-responsive.  Two ways to do this:
   1. Every minute send out a MQTT topic of <devicename>/heartbeat with a message of "alive"
   2. Have a process that responds to alive queries, like a master node that publishes <device>/query/status and the device then responds with <device>/alive with a message of "yes", maybe also report battery level, etc.

Once again, great job on getting this started and let me know if we want to roll in a device name.

Thank you for your encouragement and motivation!