Docs: Service Communication, Troubleshooting

[philip-larose]

In sensor-device-communication.md ("Service Communication"), under "Troubleshooting communication", the third paragraph has a placeholder "If the LED is ?, more than likely the firewall is blocking the communications." What LED color should be indicated here?

Also, the first paragraph of "Troubleshooting communication" says that a red LED indicator indicates that the device failed to communicate with (send data to) the service, and then says "this is different than the device sending a message and the service responding back with an error or an acknowledgement." Is there a different color LED to indicate the service responded with an error? This isn't clear.

(The whole "Troubleshooting communication" section may need review to be sure it's accurate.)

[kyle-nrs]

I don't know if the Orange is currently implemented/how hard it would be to do so.

There isn't a different color to say the device didn't connect to the service in the first place. I think it just goes red during the boot process (never white).

@raulrodriguez1 I think you are in the best place to answer this as to what the device is doing/fact check this page.

[philip-larose]

Removing the following lines from the Troubleshooting section, based on Kyle's comment:

"If the LED on the device is red, this means the device attempted to send the data to the service and failed. It was unable to communicate with the service. (This is different than the device sending a message to the service and the service responding back with an error or an acknowledgment.) "

[philip-larose]

For the sentence formerly reading "If the LED is ?, more than likely the firewall is blocking the communications", I'm now putting "red" in for the ? placeholder. This should be verified whether or not it's correct.

[philip-larose]

Note regarding @kyle-nrs's remarks about the orange and white indicators (orange maybe isn't implemented and "never white" during the boot process): I'm leaving in the full table of LED color indicators for now, but that definitely needs to be checked for relevance and accuracy.

[philip-larose]

One more note: the LED colors are also referenced on the VapeDetect management page, so that would need to be updated as well.

[raulrodriguez1]

Orange is not implemented.
Blue is burst mode. However, it doesn't send anymore data than normal. Burst mode acknowledges that something is happening with the sensor readings. Triggers can only happen when in burst mode and only one trigger event can happen per burst mode event.
Under red, the device sends data every 5 seconds no matter what. Also, the LED will flash red for a second every time it tries and fails to send data.

[philip-larose]

I've removed orange from the LED Color Indicators table.

I've also updated the description of red to say every 5 seconds, but surely that means that burst mode (blue) should also say every 5 seconds? According to this page as currently written:

1. The device normally checks sensors every second, and every 10 seconds sends an average of the results to the service.
2. If elevated levels are detected, the device goes into burst mode (turning the LED blue), sending all of the every-second samples of the last 10 seconds to the service and then continuing to send one-second sample results every second.
3. At some point it'll stop detecting elevated levels, and then it reverts to sending an average every 10 seconds.

Based on @kyle-nrs and @raulrodriguez1's comments, I'm not clear on whether white is in use and whether the rest of the table is accurately describing how the device and its LEDs work.

[kyle-nrs]

White is correct as is. It means that it was able to get through the boot process and is communicating with the service properly.

Blue is an acknowledgement that vaping may be occurring, through our sensor. To stop it from sending multiple vape alerts, we only send it once per burst(blue) period.

I think "Burst Mode" is more or less outdated at this point. The device uses burst mode to help mitigate abnormalities in the sampling of the data.

I made a PR #33 with my suggested change.