While I am sure there is formal guidance available in various Scrum and PO guides, I am not sure this is an issue of your PO not knowing what their role is, but rather their enthusiasm (fire, as you said) or ambition in other aspects as well. A common team and organizational issue.
I think a great way would be to not focus on all the extra stuff your PO is working on, but only on solving the problems you are facing because of the lack of PO stuff that they should be working on. It would make sense to schedule a one-on-one session as well as a session with your full team where you could highlight specific challenges you might be facing - such as lack of sufficient user stories, lack of proper prioritization, ineffective Sprint planning sessions due to these reasons, loss of face with customer if applicable, etc.
Two observations I have made about software teams - irrespective of whether they follow Scrum or Kanban or other methods -
The biggest issue Dev teams have is not knowing what exactly is the priority of work they should take up. This is because the PO (or product manager) have a tough job on their hands about getting stakeholder agreement on what the next set of features or user stories need to be worked on next. Depending on your context, these could be external customers, internal customers such as Sales or Support or Marketing, or business users in a corporate IT context.
There isn’t enough focus or visibility for the work a PO needs to do in order to ensure a regular and timely availability of the right work for the Dev team to work on. The process of defining and managing a product/ application roadmap, and prioritizng a specific set of features or enhancements release after release, is often not understood either by the PO or the rest of the stakeholders and the Dev team.
Consequently, there is always friction between the PO/ PM group and the Dev team, with missed features/ release dates due to communication failure between the two groups. As a product manager for my company, I have faced this challenge and have spoken about it in several events. Here's one of my presentations that might be of help - https://www.slideshare.net/maheshsingh01/visual-requirements-management-with-kanban-v2
We solved this problem with our transition to Kanban - and specifically when we set up an "upstream" Kanban board for our PM team, supported by a couple of meetings - a bi-weekly Replenishment Meeting and a Monthly/ Quarterly Planning/ Strategy Review meeting. The latter helped all stakeholders - including the Dev Team - understand overall priority for the organization and the team, as well as specifically identifying the high-level themes and epics for the quarter/ month. The replenishment meeting serves as a Release planning and a mid-release course-correction meeting, and they ensure that each release is by and large delivering the stuff we need to deliver, and everyone is in agreement on that. Our release schedule is roughly 4-6 weeks.
Here's how our Kanban boards look - a Roadmap Planning board and a Dev Board -
The PO (PM for us) is responsible for this board - and making sure that user stories flow to the Dev board in a timely manner -
The Dev manager owns this board -
While the idea is not to dump a Kanban board at your situation, I suspect helping your PO might be done either by specifically discussing your Dev team's challenges or by trying to get the PO to understand their own process, so they can better focus on doing all the PO stuff they need to be doing (using the Kanban board above as an example). Or you can do both!
Hopefully, this will help you get their efforts focused with better outcomes for your Dev team. At the same time, the PO will have got a few tools to manage their own work better - and also highlight challenges they face in their own processes.