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

jasonwier92 — Mon, 10 Apr 2017 10:35:02 GMT

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.

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"
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
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.

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

DAB — Sun, 09 Apr 2017 17:07:27 GMT

Nice update and explanation of your planned implementation.

You have a good structure to build upon.

DAB

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

mcb1 — Sun, 09 Apr 2017 00:03:16 GMT

Good post setting out all the options.

On our systems we have the four states, connected, stale (not there), alarms, okay.

These states can be expanded to include :- local (tech working on it), bypass, on battery and quite a few others.

You may wish to ensure that the detection end will respond correctly without having to individually check each state.

ie when a smoke detector goes off (*/alarm/smoke/state/true), you want to shut down power on every connected device, or just the workshop.

Mark