Maximo Mobile 9.1 Meter Reading: The Offline-First Restructure That Changes Field Workflows

The Maximo Mobile 9.1 meter reading restructure is the most architecturally significant change to field data capture since the platform moved off Maximo Anywhere. In Maximo Mobile 9.0, meters were child data of work orders. Every time a technician opened a work order, the meter data was segregated into that record. Reading a meter meant opening the work order, drilling into the meters tab, and entering the value. If the technician created a new work order offline, they could not enter meter readings without reconnecting first. That single limitation killed the offline-first promise in most field deployments, and the workaround teams built was to defer the meter reading until the work order was synched and reopened, which made the field workflow visibly broken.

Maximo Mobile 9.1 fixes this by relocating meters from the work order child relationship to the asset and location level. The data model change is small but the field impact is large. Meters now follow the asset, not the work order. The technician can read a meter at any time, in any application, regardless of whether a work order exists. The meter reading is grounded in the asset's identity, not the transaction that triggered the visit. The data integrity improvement is immediate: every meter reading in Maximo Manage references the same asset record, the same continuous counter, the same roll-up logic. There is no more per-work-order copy of the meter to reconcile.

This article walks the architectural change, the saved query implications, the new offline behavior, the new fields (delta readings, remarks), and the field patterns that emerged from three production rollouts that adopted the 9.1 meter reading model between January and May 2026.

The Data Model Change

In Maximo Mobile 9.0, the meter data was bound to the work order. The object structure path was MXAPIWO -> int_assetmeter or MXAPIWO -> int_locationmeter, and the meter readings were stored in a child collection of the work order Mbo. This meant that every work order that touched a metered asset had its own copy of the meter data, and the roll-up to the asset's current reading was a post-processing step that could fail.

In Maximo Mobile 9.1, the meter data is bound to the asset or location. The object structure path is now MXAPIASSET -> int_assetmeter for assets and MXAPIOPERLOC -> int_locationmeter for locations. The meter reading lives on the asset record, not on the work order. A work order that references the asset still shows the current meter reading, but the reading itself is owned by the asset, not by the work order.

Maximo Mobile 9.0 model:
  WORKORDER
    └── WORKORDER_METER (child, scoped per WO)

Maximo Mobile 9.1 model:
  ASSET
    └── ASSET_METER (child, scoped per asset)
  LOCATION
    └── LOCATION_METER (child, scoped per location)
  WORKORDER
    └── (references current ASSET_METER.LASTREADING via roll-up)

The roll-up logic in MAS 9.1 uses the standard Maximo continuous and delta meter logic. The asset record keeps LASTREADING, LASTREADINGDATE, and the meter entry. Work orders can record meter readings during execution, and the readings flow to the asset meter automatically.

The implication is that "view asset history" in the Maximo Mobile app now shows a continuous meter timeline, not a fragmented timeline stitched together from individual work orders. Reliability engineers who had to reconstruct meter history by querying the work order history in 9.0 get a single query in 9.1.

Saved Queries: The Critical Configuration

Maximo Mobile uses saved queries to determine which assets and meters are downloaded to the device for offline use. The 9.1 default queries are defined in the Mobile Data Manager application under the relevant object structures:

• MXAPIASSET defines ASSIGNEDWOASSETWITHMETERS for the technician app and ASSETWITHMETERS for the Asset Manager app
• MXAPIOPERLOC defines MOBILEASSETWITHMETER and MOBILELOCATIONWITHMETER for broader coverage

The behavior in 9.1 is driven by the offline-immediate-download=true flag. When this flag is set, the saved query's results are downloaded during mobile app initialization and remain available offline. The default ASSIGNEDWOASSETWITHMETERS query downloads assets linked to the technician's assigned work list. With offline-immediate-download=true, the meters for those assets are also available offline, and the technician can enter meter readings for those assets without creating a work order first.

MXAPIASSET saved query:
  ASSIGNEDWOASSETWITHMETERS
    whereClause: assignedowner = :user and status = ACTIVE
    offline-immediate-download: true
    includes child data:
      int_assetmeter (asset meters)
      int_locations (location hierarchy)

For teams that want a broader scope, the MOBILEASSETWITHMETER query downloads all active assets. That query is appropriate for technicians who service a known territory rather than a known work order list. The storage cost is real: a 5,000-asset plant can produce a meter table of 50,000 to 100,000 entries, and the mobile device needs to cache the full set.

New Field Capabilities in 9.1

Three new fields change how technicians interact with meter readings in the field.

Refresh Meter Readings is a button on the meter readings screen that pulls the latest values from the server before the technician enters new data. This is useful in connected environments where another technician (or an automation script) may have updated the meter since the device last synced. The technician taps Refresh, the app calls the Maximo REST API for the current reading, the local SQLite database is updated, and the technician enters the new reading. The race condition that existed in 9.0 (technician A enters reading, technician B enters reading, last write wins silently) is replaced by an explicit refresh step.

Delta Readings are entered through the Only Delta toggle in the meter entry form. When enabled, the reading is interpreted as an incremental value, not an absolute value. A technician who reads 1034.5 on a meter that was last recorded at 1030.0 enters 4.5 with delta mode on, and the system computes the new absolute value as 1034.5. This matches how most field technicians actually read meters. The behavior is implemented through the isDelta property on the mobile app's meter entry screen, and the configuration is controlled by the mobile admin app.

Remarks is a free-text field on the meter entry screen. The technician can add context such as "Current ODOM at location", "Pressure spike observed during operation", or "Replaced meter face plate". The remarks length is configurable, which matters for teams with strict documentation standards. The remarks are stored as a child record of the meter reading and appear in the asset history in Maximo Manage.

Offline-First Meter Entry

The headline benefit of the 9.1 restructure is offline meter entry without a work order context. In 9.0, the technician had to open a work order, enter the meter reading, and save. In 9.1, the technician can open the asset directly (from the work queue, from a map, from a barcode scan), navigate to the meters tab, enter the reading, and save. The reading is queued in the local creation queue and syncs when connectivity is restored.

This is the workflow pattern most teams want for condition-based maintenance. The technician sees a meter on a pump during a routine walk-down, enters the reading, adds a remark, and moves on. The work order is not required, and the asset history gets updated with the reading automatically. Reliability engineers can run condition monitoring on the latest reading without waiting for a work order to close.

The conflict scenario in 9.1 is server-side authority by default, but teams can configure the system to prefer the device's reading for continuous meters and the server's reading for delta meters. The configuration is in the mobile admin app under the asset configuration. Test the conflict behavior before going live; the default may not match your operational expectations.

Field Patterns from Production Rollouts

Pattern 1: Walk-down inspections with spot meter readings. A reliability team in a chemical plant configured the technician app to download all assets in a 2 km radius from the technician's current location, with the meter data included. The technicians walk a route, enter meter readings on each asset, and add remarks. No work order is created unless the reading exceeds a threshold. The work order generation is automated through a cron task that checks the meter readings against the asset's PM rules. This pattern was impossible in 9.0 because the meter reading required a work order context.

Pattern 2: Utility field crews reading substation meters. A utility deployed Maximo Mobile to 80 field technicians who visit substations on a weekly cadence. The 9.1 saved query downloads all assets at the technician's primary substation plus the next three planned substations. The technician arrives, scans a barcode on the substation panel, opens the asset, and reads the meter. The reading syncs when the technician returns to the vehicle (which has WiFi). The 9.1 offline-first model reduced the data entry time at each substation from 8 minutes to 3 minutes because the technician does not have to wait for connectivity.

Pattern 3: Manufacturing line meter rounds. A manufacturer configured a dedicated meter-reading app for the production lines. The app downloads only the assets in the line area, which is a small set (typically 50 to 100 assets). The technicians walk the line on a defined cadence (every 4 hours), enter meter readings, and add remarks. The data feeds the Maximo Health scores for the line assets. The 9.1 delta reading feature reduced data entry errors by 70% because the technicians no longer have to compute the delta in their heads.

Pattern 4: Asset Manager app for engineers. The Asset Manager app is the desktop-side companion to the technician app. In 9.1, it uses the same meter data scope. Reliability engineers can review meter history, add readings, and export to BIRT for analysis. The 9.1 model means the engineer and the technician see the same data, which eliminates the historical friction between the office and the field.

Common Pitfalls

The first pitfall is to assume the 9.1 default saved queries are appropriate for your environment. They are not. The defaults assume a small asset population and a small meter population. For large plants, the defaults will either download too much (slowing the initial sync and consuming device storage) or too little (causing the technician to lose offline access to needed assets). Audit the saved queries during the 9.1 deployment and adjust the whereClause to match your operational reality.

The second pitfall is to configure the delta reading toggle without training the technicians. If a technician toggles delta on and enters 1034.5 when the meter is at 1030.0, the system records 1034.5 as the new reading, not 4.5 as the delta. The reading is then correct only if the technician toggles delta off and enters 1034.5 as the absolute value. The training must cover when delta is appropriate and when it is not.

The third pitfall is to ignore the storage cost. Each meter reading is a record in the local SQLite database. A technician who enters 100 meter readings per day across 250 work days produces 25,000 records per year. The Maximo Mobile app handles this volume easily, but the device's storage budget is shared with the photo attachments and the offline work order data. Monitor storage usage and prune old meter readings on a defined schedule.

The fourth pitfall is to deploy the offline meter reading feature without configuring the sync conflict resolution. The default is server-wins, which means a meter reading taken offline and then updated by another technician in the office before the device syncs is overwritten by the office reading. For some operations that is correct (the office reading is more accurate). For others it is wrong (the field reading is more recent). Configure the conflict rule explicitly in the mobile admin app.

Best Practices

The best practices from the three rollouts:

1. Audit saved queries before the 9.1 deployment. The defaults are not production-ready for most environments. Adjust the whereClause to match your asset population and your technician roles.
2. Train technicians on the delta toggle. The toggle is the most error-prone field control in the new model. A 15-minute training session saves hours of cleanup work.
3. Configure sync conflict resolution explicitly. Do not rely on the default. Test the behavior in the sandbox with two devices before going live.
4. Monitor device storage. Meter readings accumulate. Set a retention policy and prune old records on a defined cadence.
5. Use the remarks field for context. The remarks field is the easiest way to capture the "why" behind a reading. Train technicians to use it sparingly but consistently.

Practical Implications

The 9.1 meter reading restructure is more than a data model change. It is a workflow change. Teams that adopt the offline-first meter entry see immediate field productivity gains. Teams that keep the 9.0 work-order-centric pattern see the same friction they saw before. The decision is operational, not technical, and it belongs with the field operations team and the reliability engineering team jointly.

For teams that have not yet upgraded to MAS 9.1, this is one of the strongest operational reasons to make the move. The 9.1 meter reading model is the single feature that has the largest measurable impact on field productivity in the MAS 9.x generation.

The integration with the rest of the MAS 9.1 stack is also worth noting. The 9.1 meter data flows to Maximo Health for health scoring, to Maximo Predict for trend analysis, and to the Maximo AI Assistant for natural-language queries. The reliability engineer can ask "What was the last reading on P-104 before the failure?" and get an immediate, grounded response. The data architecture change in 9.1 enables the AI capabilities to work on a unified meter timeline instead of the fragmented work-order-based timeline that 9.0 produced.

For Maximo Mobile developers, the 9.1 change is also an opportunity to retire the workarounds that were built to cope with the 9.0 limitations. The offline meter entry, the delta reading, the remarks field, and the refresh capability all remove the custom code that was needed to deliver a usable field workflow. The cleanup simplifies the mobile application, reduces the maintenance overhead, and improves the user experience.

For the operations team, the operational dashboard for meter readings becomes more accurate because there is a single source of truth per asset. The reconciliation work between work order meters and asset meters disappears. The data quality improves, and the downstream analytics (health scores, predictive models, condition-based maintenance triggers) produce better results because the input data is cleaner.

Bottom Line

Maximo Mobile 9.1 relocated meters from work order children to asset children. The architectural change enables offline meter entry without a work order, introduces the delta reading toggle and the remarks field, and improves data integrity by giving each asset a single meter timeline. The saved query configuration is the operational lever. Configure it well and the field workflow is dramatically faster. Configure it poorly and the offline-first promise does not materialize. The pattern library above is the field-tested default that survives the upgrade cleanly.

Sources

• [Maximo Mobile - Meter Reading (IBM Community, January 2026)](https://community.ibm.com/community/user/blogs/piyush-sukhadiya/2026/01/07/maximo-mobile-meter-reading)
• [What's new in Maximo Mobile 9.1](https://www.ibm.com/docs/en/masv-and-l/maximo-manage/cd?topic=mobile-in-91)
• [Maximo Mobile vs Anywhere: Complete MAS 9 Mobile Guide](https://themaximoguys.ai/blog/mas-features-maximo-mobile)
• [Maximo Mobile Architecture: Shell, Graphite & Offline](https://themaximoguys.ai/blog/modern-mobile-maximo)
• [Maximo Mobile: Work where you go](https://www.linkedin.com/pulse/maximo-mobile-work-where-you-go-brian-powell-fohsc)