Practical setup path
Users, billing, units, sensors, permissions, and final checks before customer handover.
Use this guide as an implementation checklist: account and permissions first, then units, trip settings, fuel, sensors, groups, and handover checks.
A practical administrator guide for creating users, configuring billing, preparing units, and handing over a clean monitoring setup.
Use it as a setup path for a first customer setup.
Move from account structure to unit data and only then to reports and handover.
Keep the guide open during setup and tick off each control point.
Each page focuses on one administrative decision, the action sequence, and the risk to check before moving on.
Read the section label first: CMS, Units, Trip, Fuel, Sensors, Groups, or Handover.
Use the action box for the exact work path.
Use the bottom checks to decide whether the page is complete.
The user list is where customer access, ownership, balance, limits, and login state start.
Open the Users area in CMS.
Scan owner, legal person, balance, lock balance, all units, active units, blocked status, and last entry.
Use filters before editing when the list grows.
A customer user should be understandable to another administrator months later.
Click Create a user.
Fill login, email, legal person, and ownership fields consistently.
Set contact fields only with data that support can trust.
Save, then reopen the user to confirm persisted values.
Administrator access determines whether the user can open the CMS admin panel.
Decide whether the person is an operator, customer admin, reseller admin, or CMS admin.
Enable administrator rights only when CMS access is required.
Record who approved elevated access.
Test login from the intended user role.
Billing decides what the platform charges for and how object count is interpreted.
Open the Billing tab.
Choose billing by active units, all units, or the contract-specific model.
Confirm the meaning of removed or inactive units.
Save the model before setting prices and limits.
The billing period controls when balance is debited and how quickly blocks can happen.
Choose daily billing when usage should be charged every day.
Choose monthly billing when balance is debited on the monthly cycle.
Confirm the first billing date with the customer agreement.
Document special exceptions.
Balance keeps the account financially active; lock balance defines the stop line.
Enter the starting balance.
Set lock balance if service must stop below a threshold.
Review blocked status after saving.
Check whether alerts or manual notifications are expected.
Transaction and price screens explain why money moved and which unit types cost what.
Open transactions when auditing balance changes.
Use prices for units to define item pricing.
Match prices to unit type and billing model.
Keep notes for manual corrections.
Menu visibility shapes what the customer sees during onboarding.
Open the Menu tab.
Hide modules outside the current contract or training scope.
Keep core monitoring paths visible.
Write down intentionally hidden modules.
Monitoring options decide which operational tools the user can reach after login.
Open the Monitoring tab.
Enable only the features required for the customer role.
Check report, object, and map-related options.
Test with a real login after saving.
Logs and service information help explain what happened after a user says something is missing.
Check service state before blaming permissions.
Review recent sessions when investigating access reports.
Use logs to confirm changes or errors.
Keep troubleshooting notes short and factual.
The Units list is the working table for monitored assets.
Open Units and scan name, owner, IMEI, model, unit type, and last message.
Use search before editing.
Check last message to confirm the tracker is alive.
Open the object only after confirming you selected the right row.
Create the monitored object before configuring its device, counters, trip rules, and sensors.
Click Create unit.
Enter a production name, not a temporary label.
Choose a unit type that matches reporting needs.
Save the object and reopen it for module settings.
Name, unit type, manufacturer, owner, and phone fields make the object recognizable and supportable.
Fill name and unit type first.
Add manufacturer or phone only when the data is reliable.
Set owner when several organizations share CMS.
Keep optional fields empty rather than wrong.
The unique ID or IMEI connects the CMS unit to the tracker data stream.
Copy the ID from a trusted source.
Choose the correct hardware model.
Check protocol-specific requirements if data does not arrive.
Confirm live data in monitoring.
Counters translate raw movement data into operational totals.
Review odometer and mileage counters.
Choose the source that matches tracker quality.
Check whether counters should start from existing vehicle values.
Verify the first report after real movement.
Engine-hour logic depends on a reliable ignition or equivalent signal.
Confirm the ignition sensor exists.
Choose when engine time should count.
Check idling scenarios with the customer.
Validate on a period where ignition changes occurred.
Maintenance and custom fields store context that is not part of live telemetry.
Add maintenance rules only when someone will use them.
Use custom fields for stable business identifiers.
Avoid duplicating information already present in unit name or owner.
Review fields during handover.
Commands and repeaters are powerful controls, so they should be configured deliberately.
Open the Commands and Repeater tabs.
Enable only commands that match the device and customer role.
Check repeater targets before activating data forwarding.
Document any remote-control capability.
Object groups are the clean way to scale access from one unit to many.
Create groups that match the customer's departments, branches, or fleets.
Assign each unit to the correct group.
Grant users access through groups where possible.
Review group membership after adding new objects.
Trip detector settings decide when the system considers movement to be a trip.
Choose a movement source: GPS speed, ignition, or odometer.
Keep the first setup conservative.
Review stop and movement thresholds.
Validate using real trips, not only stationary data.
The movement source should match what the tracker sends reliably.
Use GPS speed when position data is stable.
Use ignition when engine state is the business definition of movement.
Use odometer when distance changes are the cleanest signal.
Explain the selected logic in handover notes.
Thresholds remove noise and decide what is too small to count.
Review minimum trip duration or distance.
Set stop and parking logic carefully.
Use filters to remove false jumps.
Compare with map playback after the first trips.
Fuel settings define consumption logic, refueling, drains, and filtering.
Open Fuel consumption.
Review minimum refueling and drain volumes.
Check maximum consumption interval logic.
Keep initial values simple until real fuel data is reviewed.
Minimum volumes decide whether a change in level is an event or noise.
Set minimum refueling volume according to the vehicle tank.
Set minimum drain volume according to expected noise.
Review event grouping interval.
Compare events with known refueling records.
Filtering masks navigation and sensor noise, but it cannot fix broken hardware.
Start with the recommended moderate filtering level.
Increase only when real data shows unstable readings.
Check whether the sensor itself needs service.
Document changes for future support.
Locavist can combine several fuel level sensors into a summary value.
Create or import each fuel level sensor.
Check how the system should behave if one sensor stops sending values.
Choose average, separate, or combined behavior according to the customer need.
Validate tank totals with real data.
Sensors convert raw device parameters into values customers can understand.
List required outcomes first: ignition, fuel, doors, temperature, PTO, or custom signals.
Import from a similar unit when possible.
Create manually when the tracker setup is unique.
Name sensors for operators, not engineers only.
Importing sensors saves time when several units share the same hardware and wiring.
Click Import Sensors from Unit.
Choose a known-good source unit.
Import, then review every sensor name and parameter.
Validate after the first live messages arrive.
Manual creation starts with the sensor type, then the parameter and display rules.
Click Create in the sensors area.
Choose the sensor type first.
Select or enter the source parameter.
Set measurement units when relevant.
Save and check the live value.
Validation filters values that should not reach the customer or reports.
Identify impossible raw values.
Set upper or lower limits where the device sends error codes.
Use validation to protect reports from corrupted points.
Record why each rule exists.
Conversion turns raw readings into useful units such as liters, degrees, or states.
Use conversion tables for fuel calibration.
Check unit of measurement.
Test low, middle, and high values.
Review the final displayed value in monitoring.
The Show option controls whether a sensor is visible to the customer.
Show values that operators should act on.
Hide intermediate sensors used only for calculations.
Use clear names for every visible value.
Check customer UI after changing visibility.
Object groups organize the fleet for monitoring, permissions, and support.
Create group names that match customer structure.
Assign units immediately after creation.
Review groups before onboarding additional users.
Avoid duplicate groups with near-identical meaning.
Command groups decide which remote actions users can run.
Create command groups around roles, not around convenience.
Include only allowed commands.
Assign command groups to the correct users.
Test with a limited account.
Before handover, review the account as if you were the customer using it tomorrow.
Log in with the intended user role.
Open monitoring and confirm the unit appears.
Check live data, trips, and sensor values.
Run one basic report if enough data exists.
Confirm hidden modules are intentionally hidden.
A short handover note keeps setup decisions visible after the installer moves on.
Record user role and billing model.
Record enabled and hidden modules.
Record unit ID, tracker model, and configured sensors.
Record known phase-two tasks.
Attach the first validation result.
Use this final checklist before telling the customer the account is ready.
User and role are correct.
Billing, balance, lock balance, prices, and limits are checked.
Menu and monitoring visibility match the contract.
First unit has correct name, owner, device ID, and model.
Tracker data is arriving.
Trip detector and first reports are validated.
Fuel settings and required sensors are validated.
Object groups, command groups, and permissions are checked.
Handover note is written.
After the customer starts using Locavist, support should have a clear path for questions, corrections, and future changes.
Confirm who receives customer questions.
Keep the handover note available to support.
Log configuration changes with date, reason, and owner.
Recheck permissions after adding users or object groups.
Review the setup after the first real reporting cycle.