Trying to close the gap I am trying to understand some more of the API details, leading me to these questions:
1/ Is there a overview of the API changes that were introduced since pyamplipi was created (May 2022)? Anything with slightly more API focus detail than Releases · micro-nova/AmpliPi · GitHub ?
2/ About the /load on status and presets
(2a) Just to be sure - avoid my initial confusion: naming wise the /api/status/load (== up-loading or setting the fulls tatus-config) has quite different semantics than the /api/preset/{pid}/load (executing, making the preset config identified by {pid} effective)
(2b) For the /status/load there seems to be an info section expected in the request body → this seems odd as the content of that part seems to be known/intrinsic/built-in (thus non-writeable) on the side of the amplipi server (running the version and firmware that it is) – the schema documentation is not entirely clear: only the ‘version’ element seems to be required. But still?
Might be just me, but it feels like that part should just not be there, or is going to be ignored by the server anyway?
Put down as questions:
What will happen if that info section is not present in those messages?
What will happen if the content of that section is not matching the actual versions up on the server?
I went ahead and tried out this /status/load with a config backup at hand.
However I am now getting a
AmpliPi api error: API returned status code '422: Unprocessable Entity' with body: {"detail":[{"loc":["body"],"msg":"field required","type":"value_error.missing"}]}
This surely sounds like something is missing in the json schema, but it is far from clear what that is: What exact field, where in the json struct?
@linknum23 any ideas on how to figure that out? I have just been using the GET /status as input (although parsed through the pydantic models of the lib.)
Also: I’ve setup ssh into the amplipi so I could check local log files (I remember asking to trim those to the minimum but now fail to see how I could re-enable-then-disable those for temporary debugging)
Just to be sure - avoid my initial confusion: naming wise the /api/status/load (== up-loading or setting the fulls tatus-config) has quite different semantics than the /api/preset/{pid}/load (executing, making the preset config identified by {pid} effective)
That’s right. The reason they are both called load is that they do similar things to the system. Sorry this is confusing.
(2b) For the /status/load there seems to be an info section expected in the request body → this seems odd as the content of that part seems to be known/intrinsic/built-in (thus non-writeable) on the side of the amplipi server (running the version and firmware that it is) – the schema documentation is not entirely clear: only the ‘version’ element seems to be required. But still?
This field is marked as Optional in the amplipi/models.py since it is readonly. It should not be required by the api. We will need to square up the differences between amplipi’s models.py file and pyamplipi’s models.py file. If I recall there are already some small differences.