I'm just starting a similar project to monitor my home. I decided on using esphome.io based devices connected to my Home Assistant setup. Spark Fun has a great ecosystem [1] of sensors and carriers [2] that are just plug and play as far as the hardware goes (no soldering). You would just need to DIY a case.
You could probably also find off the shelf Bluetooth sensors that would interface with Home Assistant for data logging and visualization.
Typical counting of things starts from 0. If you count apples you implicitly start at zero and add 1 for each apple. If you count age, you start at birth (0) and count years; one for each birthday. That isn't zero based. The difference is the index of the item between the starting point and the next item. In zero based this item is number 0, in one based, this item is number 1. The first year of life is generally considered the year following birth.
This is a philosophically deep point which took me a long time to grasp.
There is a narrowing from "nothing at all" to "zero apples" which doesn't happen 'in the world' but is a necessary precondition to counting apples. The existence of any apple is a requirement for there to be zero of them before you put anything in the basket.
I just dealt with this problem(how to store periodic events(including birthdays)). It is a surprisingly difficult problem. After reading up on postgres interval types my latest attempt uses them to store events, where a per year event(like a birthday) is stored as "2 months 15 days". it turns out the postgres project has put quite a bit of thought into making interval types work as expected with regards to months, not an easy task when you consider how difficult it is to treat dates mathematically.
The nice part is that now February 29 "just works" the downside is the impedance between how months and days are numbered and a how an offset from the epoch(beginning of the year) is defined. January 3rd(1-3) is stored as "0 months 2 days" as when it hits, 0 months have passed and 2 days have passed.
So the specific case of February 29 hits when 1 month has passed and 28 days have passed. 3 years out of 4 this will be the same as "2 months 0 days"(3-1) but every forth year this will be(2-28). As an aside, and the specific reason I went with interval types, every event past feburary 29 works just fine with or without a leapyear, that is, the extra day in the middle does not mess up the offset to days after it.
Honestly I curse a little as I wish months and days were 0-based. At least clocks get this right, almost, 12 hour clocks are a special breed of stupid. start at 12, then go to 1 and proceed up to 11. 24 hour clocks properly start at 0. The worst part about 12 hour clocks is that it is almost correct, replace the 12 with a 0 and it every thing be the same but now it makes sense from a moduler math point of view.
You're just 1/4 of the age of everyone else born the same year. You have the same number of laps around the sun as those people, but you've definitely had fewer birthdays. It's a common joke for leap year babies.
I cannot find anywhere listing road temperatures nearing 175 F. Do you have a source?
Most I find are like this [1], which would allow a max road surface temp at 100F air temp at the equator with the sun directly overhead on a perfectly clear day to reach around 148F. (see equation 17 in the paper).
The rest of the literature I have found is similar. I doubt roads in the US south reach 175, and likely not even 150.
>Dr Howard Robinson, chief executive of the Road Surface Treatments Association, says most roads in the UK that experience a reasonable amount of traffic will start softening at 50C.
>[...]
>And dark road material can absorb a lot of heat. The typical summer ground temperature is higher than air temperature. Robinson says roads "regularly" reach a temperature of 50C and above. (http://www.bbc.co.uk/news/magazine-23315384) //
50 deg C is 122F; but this is UK with air temps of ~30 deg C
Yeah, I read that too. 30C is 86 F. The OP above mentioned a 100 degree day, 14 degrees warmer, and the formula and paper I referenced above would put the surface temp of the road would also only rise 14 degrees, to 136 F on a 100 degree day.
The OP claimed 150-175 is common on a 100 degree day. No research I can find (except one single author) is anywhere near that amount.
First, this is an unattributed claim, and it's referencing 120F ambient, not 100 ambient the above claimed. (Well, it's vaguely attributed to a company trying to sell a solution....)
Given the all time high temp in Phoenix was 122F [1], I suspect this article is playing loose with the facts implying this temperature is a common occurrence, casting more doubt on the accuracy of the 170 claim. From a quick search, only two months in history recorded temperatures above 120, while the article implies this is common. It is not.
So yes, you can find people (like the above) stating these temps without attribution. I've not found anything in academic research with temperatures anywhere near that high, and there is a lot of papers on exactly this topic, with plenty comparing models to actual measured temps. I've been unable to find anything empirical in such papers near these claims.
I'm beginning to think these numbers are more folklore than fact.
If the OSM database is used as is and not used to modify any of their existing data, the existing data wouldn't have to be released.
IANAL, but it seems to me that the data could be used in conjunction with existing data for the purposes of rendering tiles and not require releasing any other data sources.
I think it is being used quite appropriately. If someone decides to create a service that uses this library to interface with an LTE network, they have to open source their software. If they went with GPL they wouldn't have to.
I think what he is getting at is if the patent owner ascribes no value to the patents for tax purposes, then the same lack of value applies if they attempt to collect damages for IP infringement.
This would force the patent troll to set the value to something balances so that they can afford the taxes while still recouping enough infringement damages.
You could probably also find off the shelf Bluetooth sensors that would interface with Home Assistant for data logging and visualization.
[1]: https://www.sparkfun.com/categories/tags/qwiic [2]: https://www.sparkfun.com/products/17724