Thanks, Joe, for the insight—and sorry to hear you got dinged with that bill!
Quick question: is there any reason I couldn’t just use the same API key I already use with OwnTracks app written by @lpakula ? I’m guessing the only downside would be that OwnTracks would no longer give an accurate count of usage out of the 10,000 free requests, since there’s no way to distinguish between requests from OwnTracks and HD+.
Still, if that’s the only catch, it might be the simplest way to get things going again—at least for now.
They did a reduction from 40k/mo to 10k/mo starting on March 1. Do you have that key configured to do reverse geocode address lookup? I got dinged $20 because I had OwnTracks recorder silently processing every incoming location.
When you log into the Google Cloud Dashboard, you can see which API was the offender.
Thanks -- yeah I stopped paying attention of all of those Google Cloud emails so it's my fault for probably missing it.
It's the static maps key in my case. I had a limit setup but that must have been set for the 40k a month.. I wonder how many other people were caught in a similar situation!
Hmm.. I'm not sure - maybe? I think Google lets you create 10 or so projects so it might be cleaner to just create a new one and just enable the Google Maps Static Map API. But, if you already have a project and just want to add/enable the Static Maps API that should work too.
I will try to clean up and simplify the process around how to do all of this when I get some time.
HD+ uses MakerAPI so I'd guess you can re-generate that API key. If you set (or change) the Hubitat username/password that'll work to keep anyone from logging in again
I just wanted to double-check that I'm setting things up correctly.
In Google Cloud, under the HD Dashboard Map project (I created) within Google Maps Platform / APIs & Services, I see a list of various map products—some enabled by default, others not. Am I correct that the only one I need to enable is the Maps Static API?
that's right.. this API takes a lat/lng from the device (Life360, Owntracks, etc) and returns a static map image which is displayed on the dashboard.
There's another API for the interactive map, which is seen when you click on the tile to view it full screen.
Navigating Google's Cloud Console page is a real pain IMO.. but buried in there somewhere is also a Quota page which lets you set how many times an API can be called per day. If the limit is 10k free you could set that to 322 or so calls per day just to ensure you'll never get charged (well until Google decides to change the limit that is lol)
Also, should I disable everything else that is enabled?
Yes, if it enabled more than that you could. I think I did that as well just to be safe
Hi @jpage4500,
Nevermind - my aging memory must be failing me. I didn't remember setting up a different map tile for your app. Sorry for the confusion.
After trying it out, HD will display the iFrame using it as a custom 'HTML' tile. When it's done that way I'm assuming that HD takes the web address and just renders the map, so it shouldn't need the API, correct? Unfortunately, it does still have the Google Maps junk on it but that may be an option if the API limit is becoming an issue.
Just wondering— is that a different API, or is it still the Maps Static API? Just want to make sure I don't disable it.
Yes, that was hard to find—LOL. I used Gemini to help track it down.
I believe it’s listed as Unsigned requests (if URL signing secret is defined) per day, since during my testing, that was the only one showing a count under current usage.
Hi @jpage4500, checking in to see if you have made a decision on whether or not you are going to change the thermostat tile as suggested in this post and the subsequent post.
Whatever your decision, thank you for considering it and for the fantastic app!
Sorry you caught me right before going on vacation so I haven't had time to really think it through. I'm good with making the change to have the primary value be the actual temp and not the setpoint. I just wanted to make sure it wasn't going to break things for anyone. I did briefly see the ideas above but also want to keep the tiles fairly consistent with placement of things and today at least I'm using that bottom-right corner for a few different status icons (low battery, device updating)
Anyway, unrelated to this but I made some pretty big changes to how the app does background work.. it'll affect things like background location checking, widgets and some new areas. But, in a nutshell I need a little more time than usual to test it all out before pushing out the next update.
I took a stab at changing this and it's part of a bunch of changes coming soon. I wanted to try and document what I did. Basically:
show current temp as the main value in a tile (example 1)
IF user is adjusting the temp, the setpoint will be displayed as the main text so users can see the changes they're making. After ~5 seconds that will change back to the current temp again (example 2)
I'm always showing the setpoint in the status/label.. I prefix it with "Cool:" or "Heat:" so it's a little more obvious. If the system is actively cooling or heating I just say "Set:" since cooling or heating is already displayed (example 3)
I didn't make as many changes when in 'auto' mode.. I basically show both heating and cooling setpoints in the status.
I know it's not exactly what was described but wanted to get something in since I'm also working on several other changes too and don't want to hold everything up too long.
refactoring background services (widgets, location checking).. this is the change that's risky and hard to test but necessary to support the latest Google API's
It'll show the temp as the primary value. The only time the setpoint is displayed instead of the temp is when you're actively changing the setpoint. So, 99% of the time it'll be the temp
