I want to use RCC-ACIS to access historical weather data. It’s decent API with a lot of useful data… but it wants the station ID and (more problematically) the date in the post payload. I thought this would be no problem, but… it looks like the payload is just a string. I think maybe I’ll be able to do this as a really ugly resource_template and GET, but not all APIs will have that option — and it would be WAY cleaner to have the payload separated from the endpoint.
Ugh, I’ve been trying to figure out how to get the pretty-complex payload into GET format for, like, an hour now. I’m very close to giving up and sticking it all in a SQL db and using that integration instead. It’s not like the past weather is going to change.
But it does seem like this limitation would hamper a lot of API usage. Am I just missing something?
I bumped into this exact same problem: My electricity company has a nice API to retrieve the current price (I’m on an per-hour plan), but it uses a REST API with POST parameters. I need to supply the date I want thhe prices for, but I haven’t found a way (yet) to do just that.
The frustrating thing is, that I can use a template for the payload in a rest_command configuration, but that doesn’t do anything with the responses (at least: I haven’t figured it out yet).
I will add a feature request; maybe this will lead to something
For my particular case, since it’s historical data, what I did was download everything and put it into a sqlite3 file, and then use the sql integration to get it. This is not a good general solution.
Unless there’s interest in working on this generally in HA, I think maybe the best thing to do would be to develop a generic rest2mqtt bridge, for basically anything beyond the basic functionality HA supports. (I found GitHub - krambox/rest2mqtt: Simple rest to mitt bridge, but it seems a bit too rudimentary.)
It’d be nice to also have more flexible scheduling — not just an interval between checks, but specific times, and rules like “check hourly until there’s an update, then wait until the next day”. And also options to cover situations like this one, where I want to create a HA sensor update when the remote timestamp attribute changes, regardless of whether the value changes. (Right now, you can have it treat the sensor as updated when the value changes or on every check, which isn’t ideal.)
