Merged
Conversation
Implements on-demand metric request capability from OVMS firmware 3.3.005+. Changes: - Add METRIC_REQUEST_TOPIC_TEMPLATE and CONFIG topic templates to const.py - Add ACTIVE_DISCOVERY_TIMEOUT (10s) and LEGACY_DISCOVERY_TIMEOUT (60s) - Implement hybrid discovery in topic_discovery.py: - Phase 1: Active metric request (faster, 10s timeout) - Phase 2: Legacy passive discovery fallback (60s) - Add async_request_metrics() method to OVMSMQTTClient for runtime refresh - Deprecate async_send_discovery_command() in favor of new approach - Add 13 unit tests for new functionality This leverages the new firmware feature where publishing to <prefix>/client/<clientid>/request/metric triggers the OVMS module to publish all metrics matching the pattern, enabling faster discovery and on-demand metric refresh. Ref: GitHub issue #180, OVMS firmware changes.txt (3.3.005)
…update Phase 2 (Add Missing Metrics): - Verified all planned metrics already exist in codebase - Updated TODO plan to reflect completed status Phase 3 (GPS Accuracy Handling): - Fixed v.p.gpssq metric: changed unit from dBm to PERCENTAGE (0-100%) - Updated v.p.gpssq description with quality thresholds (<30 unusable, >50 good, >80 excellent) - Removed incorrect SIGNAL_STRENGTH device_class from v.p.gpssq - Added GPS accuracy constants to const.py: - GPS_ACCURACY_MIN_METERS (5m floor) - GPS_ACCURACY_MAX_METERS (100m ceiling) - GPS_HDOP_METERS_MULTIPLIER (5m per HDOP unit) - Updated mqtt/__init__.py::get_gps_accuracy() to use constants and prefer gpssq - Updated attribute_manager.py::get_gps_attributes() to use constants - Improved docstrings with firmware version notes Documentation: - Added OVMS firmware changelog section to copilot-instructions.md - Lists key features to leverage from OVMS 3.3.005+ Tests: - Added 18 new GPS accuracy unit tests (tests/test_gps_accuracy.py) - All 31 tests pass Ref: GitHub issue #180, OVMS firmware changes.txt
- Updated README.md with firmware version requirements table - Added OVMS-side metric filtering examples (metrics.include/exclude) - Created docs/FIRMWARE_COMPATIBILITY.md with feature-to-version mapping - Documented fallback behavior for older firmware
New Services: - climate_schedule: Manage scheduled precondition times with duration support - tpms_map: TPMS sensor-to-wheel mapping for wheel rotation/swap - aux_monitor: 12V auxiliary battery monitor control Code Simplification: - Remove deprecated async_send_discovery_command (replaced by on-demand metrics) - Simplify GPS accuracy to use v.p.gpssq only (remove HDOP fallback) - Remove unused GPS_HDOP_METERS_MULTIPLIER constant These changes prepare for the upcoming OVMS firmware release with new vehicle framework features. Services reference OVMS firmware changes.txt for command documentation.
|
I've skimmed through your plan; some of it is already natively available in the firmware. |
Owner
Author
I used changes.txt as reference. I'm not 100% sure what's in OTA release currently available. I remember I had to change some logic when that was released (1.4.X in our versioning). FYI; this integration intention is to extract everything from the module and put it in Home Assistant, so even if the functionality already exists in OVMS Web UI, we might still want it in the integration. Can you be more specific you think? I don't plan to release this anytime soon, just some pre work based on your great addition to firmware. 🙂 |
- Features like on-demand metric requests and GPS signal quality are in edge/unreleased firmware, not 3.3.005 (current stable release) - Updated all comments, docstrings, and documentation to say 'edge firmware' - Fixed tests to match simplified GPS accuracy (gpssq only, no HDOP fallback) - Updated test_metric_request.py to test removal of deprecated method - All 29 tests pass
Owner
Author
|
@zorgms Is it possible to upgrade the module to the edge firmware, and then revert back to 3.3.005 after some time? I'm asking because I'm thinking of maybe starting to test these changes soon. |
- Fix discovery timeout to properly use LEGACY_DISCOVERY_TIMEOUT (60s) - Correct firmware version requirements in FIRMWARE_COMPATIBILITY.md: - v.p.gpssq: 3.3.003 (not 3.3.001) - aux_monitor: 3.3.005 (not 3.3.003) - climate_schedule/tpms_map: Edge only (not 3.3.003) - Add firmware error detection in services.py with actionable messages - Update TODO plan with corrected firmware matrix Based on deep analysis of OVMS firmware source code (not just changelog).
State restoration was excluding 'unit_of_measurement' but not 'unit' from restored attributes. This caused old cached values (e.g. 'dBm') to overwrite correct metric-defined values (e.g. '%' for v.p.gpssq GPS Signal Quality). Added 'unit' to the exclusion list in both OVMSSensor and DurationSensor async_added_to_hass() state restoration logic. Fixes: - GPS Signal Quality showing 'dBm' instead of '%' - Recorder warnings about multiple unit values for sensors
Services: - Add SupportsResponse.OPTIONAL to all services that return data - Now aux_monitor, send_command, etc. will show response in HA UI - Users can see actual command output (e.g. aux monitor status) Command Handler: - Change duplicate response warning to debug level - QoS 1 can cause duplicate message delivery which is normal behavior - First response completes successfully, second is just noise Entity State Restoration: - Fix misleading comment about unit exclusion (we EXCLUDE not preserve) - Clarifies that restored values shouldn't override metric definitions
- Emphasize new service response feature (v1.5.1) - Add Services Reference section listing all 8 available services - Document all service parameters with tables - Add new services: climate_schedule, tpms_map, aux_monitor - Include example automation using response_variable - Add screenshots showing service response in Developer Tools
- Issue 1: Fix false active discovery success from echoed request/metric topics - Only count topics with /metric/ in path, not /client/ echoes - Falls back to legacy discovery correctly when no real metrics received - Issue 2: Add minimum topic validation with warning - Show warning when < 10 metric topics found - User informed but can still proceed (module may come online later) - Issue 3: Add discovery quality feedback UI - Excellent (100+), Good (50+), Partial (10+), Minimal (1-9), None (0) - Quality message with emoji guides user on next steps - Sample topics now show only metric topics, not command echoes Constants added to const.py: - MINIMUM_DISCOVERY_TOPICS = 10 - GOOD_DISCOVERY_TOPICS = 50 - EXCELLENT_DISCOVERY_TOPICS = 100
…ugh metrics When MQTT broker has retained messages from a running OVMS module, those messages arrive immediately after SUBACK, often before the connection loop completes. In beta4, the metric_topics_before count was taken AFTER those retained messages arrived, causing the 'new metrics' count to be 0. This fix adds an early check: if we already have >= 50 metric topics from retained messages, skip both active discovery AND legacy wait entirely. This returns discovery to ~instant completion for users with retained msgs. Timeline issue (from debug logs): - 05:23:54.300: SUBACK received - 05:23:54.316-586: 172 retained metric messages arrive - 05:24:04.735: new_metric_topics = 0 → 'No metric topics' → legacy fallback - 05:24:54.816: Discovery complete (60s total, 50s wasted) With this fix: - Check metric_topics_before FIRST - If >= GOOD_DISCOVERY_TOPICS (50), skip active/legacy phases - Discovery completes in ~1s instead of 60s
Updated all translation files (sv, de, es, fr) to include the new
placeholders {metric_count} and {quality_message} in the topic_discovery
step description, and added the few_topics_warning error message.
This fixes the Home Assistant translation validation error:
'Validation of translation placeholders for localized (sv) string
component.ovms.config.step.topic_discovery.description failed'
Also removed TODO/DISCOVERY_IMPROVEMENTS.md as all 3 issues are now
implemented and verified working.
Owner
Author
|
@zorgms If you are using Home Assistant, beta6 should now be solid. I don't have edge so I can't test, but the logic is in place now. Could you please have a look and review you think? Please ignore the |
- Remove TODO folder (implementation plan completed) - Remove tests folder (branch-specific tests no longer needed) - All firmware compatibility documentation verified accurate
|
I don't use HA, sorry. I only use a vehicle app that uses MQTT. |
Owner
Author
|
@Alenux55 Do you mind testing the beta release? Everything working for you? |
- New service: ovms.refresh_metrics for requesting metric updates - Edge firmware: Uses fast on-demand request/metric topic with pattern support - Legacy firmware (3.3.005): Falls back to 'server v3 update all' command - Supports patterns like 'v.b.*' (battery), 'v.p.*' (position) on edge firmware - Added service to services.yaml with full UI support - Updated README with documentation and examples
…are compatibility
enoch85
changed the title
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: enoch85 <mailto@danielhansson.nu>
…ELAY - Add RECONNECT_METRIC_REQUEST_DELAY constant to const.py (ACTIVE_DISCOVERY_TIMEOUT / 2) - Replace all hardcoded QoS fallback values (1) with DEFAULT_QOS constant - Add DEFAULT_QOS fallback to command_handler.py and connection.py subscribe Files changed: - const.py: Added RECONNECT_METRIC_REQUEST_DELAY constant - mqtt/__init__.py: Use RECONNECT_METRIC_REQUEST_DELAY and DEFAULT_QOS - mqtt/connection.py: Use DEFAULT_QOS in 5 places - mqtt/command_handler.py: Use DEFAULT_QOS - config_flow/topic_discovery.py: Use DEFAULT_QOS in 7 places - config_flow/mqtt_connection.py: Use DEFAULT_QOS Addresses Copilot code review comments on PR #193
- Add DEFAULT_EXPECTED_METRICS = 196 constant with documentation - Rename 'Generic OVMS' to 'OVMS Vehicle' for clearer display - Add black auto-fix to test_code_quality.py when formatting issues detected Addresses Copilot code review comment on PR #193
Addresses Copilot code review comment on PR #193
Owner
Author
|
Here we go! |
Contributor
Sorry I've been super busy lately. I pasted the files into my home assistant instance and readded my car and I toggled the charge and HVAC switches and they seem to be working as expected, including updating the state. I cannot physically test the door lock switch, but when I toggle it, the value doesn't seem to change back to the actual state. Lastly, the cabin setpoint switch is still being generated; I think it should be removed. I have not yet tested with the service calls yet. |
Owner
Author
|
@Alenux55 Just download the latest version 1.5.1. Create an issue report if you find anything strange. 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Firmware-related improvements to the OVMS Home Assistant integration focusing on faster discovery, new edge firmware services, and enhanced user feedback.
New Features
Services (Edge Firmware)
ovms.climate_schedule- Manage scheduled precondition times with per-day schedulesovms.tpms_map- TPMS sensor-to-wheel mapping for wheel rotation scenariosovms.aux_monitor- 12V auxiliary battery monitoring with voltage thresholdsovms.refresh_metrics- On-demand metric refresh with pattern filteringService Enhancements
SupportsResponse.OPTIONAL)Discovery Improvements
GPS Accuracy
v.p.gpssqmetric unit from dBm to percentage (0-100%)const.pyTechnical Changes
Constants (
const.py)METRIC_REQUEST_TOPIC_TEMPLATE- On-demand metric request topicACTIVE_DISCOVERY_TIMEOUT(10s),LEGACY_DISCOVERY_TIMEOUT(60s)MINIMUM_DISCOVERY_PERCENT(5%),GOOD_DISCOVERY_PERCENT(25%)GPS_ACCURACY_MIN_METERS(5m),GPS_ACCURACY_MAX_METERS(100m)DEFAULT_COMMAND_TIMEOUT(10s)Vehicle Metadata
VEHICLE_TYPE,VEHICLE_NAME,METRIC_PREFIXto all vehicle modulesVEHICLE_TYPE_PREFIXESandVEHICLE_TYPE_NAMESlookup dictionariesState Restoration
unit_of_measurementfrom restored state attributessuggested_unit_of_measurementsupport in sensor factoryOther
async_send_discovery_command()methodDocumentation