RE: [Upcycle It] WiFi Connected Smoke Detector #4: Monitor Design Decisions - MQTT + Node.js + Slack

DAB — Sun, 16 Apr 2017 18:07:41 GMT

As with any system, you will need to refine your operation, alert and response issues over time based upon the actual performance of the devices.

I think you have a good start.

Are you planning to include a test feature to verify connections and operating sensors?

DAB

RE: [Upcycle It] WiFi Connected Smoke Detector #4: Monitor Design Decisions - MQTT + Node.js + Slack

mcb1 — Sun, 16 Apr 2017 08:00:57 GMT

It always sounds simple, until you need to include all the exceptions and error checking. [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-471ec9a4-a5e1-46ca-9f2c-1dfce2e62bbf/contentimage_5F00_2516.png:16:16]

We utilise the same principle in our monitoring system, where we expect communication and then report when it exceeds a preset time.

The next big choice is what happens when it hasn't had any smoke alarms reporting in.

In a true "Fail To Safety" situation the devices would assume the worst and de-power, etc.

If you had two sensors in the same area, you could decide that the minimum number reporting in is 1, but that requires some configuration.

What happens when the only detector is in 'maintenance' or removed.

It's when this happens and there is a bypass that things tend to go wrong. [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-471ec9a4-a5e1-46ca-9f2c-1dfce2e62bbf/contentimage_5F00_4751.png:16:16]

You may be able to have an override function that allows it to work for x hours and can only be 'over-riden' x times.

I'm looking forward to the next bit.

Mark