Raphael Dumas

Ittttt would be nice to have a Slack message notifying of success of all the tasks so someone can review that tables were properly created.

This is looking good. Wondering if the HERE trigger task should use the same logic from Bluetooth or Miovision to just replace the trigger instead of sending the slack message....

Interesting that Class 1 & 2 have significant change in number of links in this edition vs. last upgrade.

Because the LRT is running down the middle of the street

See [readers_not_working_yesterday](https://github.com/CityofToronto/bdit_data-sources/blob/blip_status/bluetooth/readersdown/readers_not_working_yesterday.sql) to find which detectors weren't working yesterday. Now we want to automate creating that lookup table identifying the `detector_name` that are part of each `analysis_id` as a VIEW.

A more useful version of [`bluetooth.readers_not_working_yesterday`](https://github.com/CityofToronto/bdit_data-sources/blob/blip_status/bluetooth/readersdown/readers_not_working_yesterday.sql) would be the status of all detectors that should be installed and operational based on the `bluetooth.detector_history` table to be created https://github.com/CityofToronto/bdit_data-sources/issues/196#issue-449358417

Just updated the language in the comment at the top so the tables referred to here and in #250 are the same

@KatiRG @chmnata if you could review the route updating documentation here that would be great.

`check_brokenreaders.py` should be renamed to `bluetooth_check_readers.py` so that the data source is the first word. I should update the documentation to specify a standard for how we name DAGs.

Just in case future spelunkers come here. `wifi = TRUE` on highways where the problems associated with using WIFI observations are reduced. `reversed` was a flag to identify segments had...