Also trying to build a web interface to handle more intelligent scheduling

[ewenjc]

Hi,
Thank you for PyMammotion library. I've been able to get device list with status, battery etc. Also a list of Areas but I can't see a way to get data like the task report in the app; i.e. a list of areas and when they where mown. Ideally i'm trying to get the time and height that each lawn was last cut to.
Does PyMammotion have access to this data?

[mikey0000]

Yes have access to everything

[mikey0000]

OK so there are two calls
query_job_history
And request_job_history

Note this will likely be limited to the last 10 or so runs.
I'll need to see what data comes back etc but if they aren't already in the library I'll add them in.
Query isn't used in the app only request so might be even easier.

I'll have to sort out a data class for this too.

[mikey0000]

Just checked its in the library but I don't know what it will return, so if you have any issues here send me the raw protobuf and I'll see what I can do.

[mikey0000]

I'll add for home assistant all sensors hold their history so that is collected by default

[ewenjc]

So far I've got mower status and list of area working using callback. All good.
The Task Report data (job history) is getting closer but not quite there.

The following is a summary of what the AI has tried, which bits work and which bits don't.
I think I'm close. Any pointers would be great. Thanks

Job History Extraction Analysis - Complete Findings

Current Approach (Working Perfectly)
✅ Successfully authenticate via MammotionHTTP and CloudIOTGateway
✅ Send job history commands:
MctlNav(todev_work_report_cmd=WorkReportCmdData(subCmd=1, getInfoNum=N))
✅ Consistently receive tokens back (e.g., "f1fe7c90-149d-4742-9e51-79dae66edf7c")
✅ Commands work reliably, authentication is solid
The Problem
❌ Cannot retrieve actual job history data using the tokens
❌ No clear mechanism found for token-based result retrieval
Comprehensive Testing Completed (All Failed)
Basic HTTP endpoint polling - 80+ endpoint patterns, all return 404
Device-server API pattern - 108+ endpoints following /device-server/v1/... structure, all return 404
Token parameter testing - 320+ combinations treating tokens as:
Query parameters: /job/results?token=..., /job/results?request_id=...
POST body JSON: {"token": "...", "iot_id": "..."}
Form data: token=...&iot_id=...
Multiple parameter names:
token, request_id, uuid, id, job_id, work_id
Various endpoints: /job/results, /work/history, /device/results, /device-server/v1/results
MQTT monitoring - No notifications received after sending commands
CloudIOTGateway method analysis - No obvious token result retrieval methods
HTTP client analysis - No relevant result retrieval methods found
Total HTTP requests tested: 508+ different combinations

Key Questions:
How should these tokens be used? Are they meant for internal PyMammotion library use only?
Is there a specific method/class in PyMammotion that handles token-based result retrieval?
Should we be polling with delays? Maybe results aren't immediately available?
Is there a different communication channel? (WebSocket, different MQTT topic, internal cache)?

Technical Environment:
PyMammotion Version: 0.4.56 (latest)
Authentication: Working perfectly (access_token/authorization_code extracted)
Commands: Working perfectly (tokens returned consistently)
The comprehensive analysis demonstrates we have all the foundational pieces working but are missing the final crucial step of result retrieval. The mechanism is not discoverable through any standard HTTP patterns, MQTT monitoring, or public API methods we can identify.

[mikey0000]

AI is stupid. Don't use AI to do your testing. Its incorrectly assuming the tokens returned have anything to do with getting job history, if the commands work you'll get a response over MQTT.