Vivek, one issue you will have is for very long ways. Returning the OSMid for a long way will inhibit that whole way being used, rather than a possible simple route around the problem area.
If your area is not huge, (city size) you may want to consider PG_Routing as you can dynamically update the routing tables for an individual segment based on a lat long look up using PostGis functions.
Alternatively, you could build the sensor positions into the routing graph easily and then just weight those with a High Cost in real time
PG_routing is not a particularly fast performer, but it is great for these types of requirements as it is all in the database and very flexible.
I am discussing a Graphhopper/Pg_Routing bridge on the Graphhoper list. The reason is that I want to be able to dynamically route at the country level (disaster and seasonal related changes like roads unavailable in rainy seasons, etc) and GraphHopper is a very good performer, but it only works on the XML files, which means rebuilding the graph, or updating an in memory table on a regular basis from the database and modifying the GraphHopper Source to look at the in memory table it and apply the weights.
Again, Graphhopper keeps the OSMId for the way, which can be very long in some circumstances, so you risk making an entire freeway non routeable where as a simple diversion might be all that is necessary in all practicality to get around the polluted area.
For smaller areas, I just use PG_Routing and I have all my data in a PostGIS database already.