Subject: Presence + Motion Sensor Configuration - Guest Detection Issue

[superdarco78]

Subject: Presence + Motion Sensor Configuration - Guest Detection Issue

Hello,

I need your expert advice on properly configuring Versatile Thermostat to handle a specific scenario with presence and motion detection. I'll provide detailed information about my setup and the exact problem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MY CURRENT SETUP

Hardware:

• Thermostat: Shelly BLU TRV (Bluetooth thermostatic valve)
• Motion Sensor: binary_sensor.czujnik_ruchu_salon (PIR sensor in living room)
• Presence Detection: Phone GPS tracking (500m home zone)
  • person.dariusz (my phone)
  • Planning to add: person.edyta, person.jakub (wife and son)

VTherm Configuration:

• Type: over_climate (controlling Shelly BLU TRV)
• Central Configuration Mode: Enabled
• With presence detection: person.dariusz
• With motion sensor: binary_sensor.czujnik_ruchu_salon
  • Motion preset: Comfort
  • No motion preset: Eco

Temperature Presets:

• Comfort: 21°C (when motion detected)
• Eco: 19°C (no motion, but home)
• Eco away: 17°C (nobody home)
• Sleep: 16°C (night mode)

Schedule (Activity mode):

• Active: 08:00 - 16:00 daily
• Uses: Comfort (21°C) with motion / Eco (19°C) without motion

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

THE PROBLEM - DETAILED SCENARIO

Situation: I leave home but guests remain in the living room.

What happens step by step:

1. 08:00 - I'm home, Activity schedule starts
   • My phone: person.dariusz = home ✓
   • Motion sensor: binary_sensor.czujnik_ruchu_salon = on ✓
   • VTherm behavior: Comfort preset → 21°C ✓ CORRECT

2. 10:00 - I leave home, guests stay
   • My phone: person.dariusz = not_home (GPS detects I'm >500m away) ✗
   • Motion sensor: binary_sensor.czujnik_ruchu_salon = on ✓ (guests moving)
   • VTherm behavior: Away preset → 17°C ✗ WRONG!
   • Expected: Should stay at 21°C because motion is detected

3. Guests are cold because temperature dropped to 17°C even though:
   • Motion sensor clearly detects activity ✓
   • People are actually in the room ✓
   • But VTherm only checks phone presence ✗

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

WHY THIS HAPPENS (my understanding)

VTherm seems to prioritize presence sensor over motion sensor:

• When presence sensor shows "not_home", it immediately uses "away" preset
• Motion sensor is ignored when presence = away
• This makes sense for energy saving, but not for guest scenarios

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MY QUESTIONS TO YOU

1. Is this the intended behavior?
   • Should motion sensor be ignored when presence = away?
   • Or is there a configuration I'm missing in VTherm settings?

2. What's the CORRECT way to configure this scenario?
   Should I:
   • Create a template sensor combining presence + motion detection?
   • Use motion sensor as presence override somehow?
   • Configure VTherm differently (different settings/options)?
   • Use automations with helper entities?
   • Use a group of person entities?
   • Something else entirely?

3. Multi-person presence:
   • I'm planning to add wife and son's phones
   • Should I create a group of all persons first?
   • Then use that group as VTherm presence sensor?
   • How does VTherm handle multiple person entities?

4. Best practice question:
   • What's the recommended approach for "guest detection"?
   • Should motion sensor be enough to indicate presence?
   • Or should presence always be primary and motion secondary?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FILES I CAN PROVIDE FOR ANALYSIS

I'm ready to share complete configuration files so you can analyze my exact setup:

Configuration Files:

• VTherm full configuration (JSON export from integration)
• configuration.yaml (relevant sections)
• template.yaml (if templates are needed)
• automations.yaml (current automations)
• Helper definitions (input_boolean, input_number)

Diagnostic Information:

• VTherm debug logs during the problem
• Entity states timeline (presence + motion changes)
• Screenshots of VTherm settings and behavior
• Sensor attributes and device classes

Whatever else you need:

• Any specific files or logs you want to see
• Test scenarios results
• Detailed entity information

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

WHAT I NEED FROM YOU

Please provide:

1. Recommended configuration approach for this guest scenario
2. Example configuration (templates, automations, VTherm settings)
3. Step-by-step setup instructions if possible
4. Best practices for combining presence + motion detection
5. Which files you need to analyze my setup
6. Is this possible with current VTherm features or needs enhancement?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

IDEAL BEHAVIOR (what I want to achieve)

Goal: Fully automatic guest detection with zero manual intervention

Desired behavior:

• I'm home: Normal operation (21°C with motion / 19°C without motion)
• I leave + guests present: Keep comfort temperature (21°C) because motion detected
• I leave + no guests: After 30 minutes no motion → switch to away (17°C)
• I return home: Automatically resume normal operation
• Fully automatic: No manual switches, no buttons to remember

Current result:

• When I leave, temperature immediately drops to 17°C even with motion
• Guests are uncomfortable
• Motion sensor is ignored when phone presence = away

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ADDITIONAL CONTEXT

Technical Details:

• Home Assistant: 2024.11.x (latest stable)
• Versatile Thermostat: [version from HACS]
• Shelly BLU integration: via Bluetooth
• Phone tracking: Home Assistant Companion app (GPS based)
• Zone radius: 500 meters
• Motion sensor: Zigbee PIR (Aqara/Sonoff type)

Important notes:

• This is a common real-world scenario (guests visiting while owner is away)
• I want to follow VTherm best practices, not create workarounds
• I'm willing to reconfigure everything if needed
• Multiple people will be tracked (adding family members soon)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

REQUEST

Could you please provide:

• The correct way to configure this in VTherm
• Example configuration files (templates, automations, settings)
• Any recommendations for my specific use case

Which files should I send you to help analyze my current setup?

I really appreciate your work on this integration - it's incredibly powerful! I just want to make sure I'm using it correctly for this scenario.

Thank you very much for your time and help!

[jmcollin78]

The V8.0 released yesterday have many improvements about multiple detection. Are you in v8.0 ? If not I recommend to install it and check if your issue is still there.

[superdarco78]

Hi jmcollin78,

Thank you very much for the quick reply and the suggestion to try Version 8.0!

I have installed the latest version 8.0 via HACS as recommended. However, I've run into a new error that prevents me from testing the presence/guest scenario further.

After updating to Version 8.0, I am consistently seeing the following error in my Home Assistant logs:

Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
  File "/config/custom_components/versatile_thermostat/thermostat_climate.py", line 596, in _async_climate_changed
    new_hvac_mode = VThermHvacMode(new_state.state)
  File "/config/custom_components/versatile_thermostat/vtherm_hvac_mode.py", line 40, in init
    raise ValueError(f"Unsupported HVAC mode: {hvac_mode}")
ValueError: Unsupported HVAC mode: unavailable
This error, which was not present before the 8.0 update, suggests that Versatile Thermostat is unable to process the unavailable state from one of the underlying climate entities (most likely my Shelly BLU TRV or a related helper).

Could you please advise on why this Unsupported HVAC mode: unavailable error is occurring in Version 8.0? I need to resolve this first before I can properly test the presence and movement detection logic for the guest scenario.

Once this issue is resolved, I will be happy to provide feedback on the guest scenario with the new version.

Thank you again for your time and support!

[superdarco78]

My primary goal is to configure guest detection correctly.My Setup:TRV: Shelly BLU TRV (over_climate mode).Presence: person.dariusz (my phone GPS). I will soon add group.domownicy.Motion: binary_sensor.czujnik_ruchu_salon.VTherm Settings: With presence detection: person.dariusz, With motion sensor: binary_sensor.czujnik_ruchu_salon.Presets: Comfort (21°C) on motion, Eco (19°C) no motion, Eco away (17°C) no one home.The Problem (Current Behavior):I leave home (person.dariusz $\rightarrow$ not_home).Guests remain in the living room (binary_sensor.czujnik_ruchu_salon $\rightarrow$ on).VTherm immediately switches to Eco away (17°C), ignoring the active motion sensor.My Question:Is this intended behavior (where GPS presence detection has absolute priority over motion)?What is the recommended best practice to configure VTherm to achieve the following: If motion is detected, ALWAYS keep the heating in Comfort/Eco mode, regardless of the owner's GPS presence state.Should I use a Template Binary Sensor that combines group.domownicy OR motion_sensor as the single, authoritative presence_detection entity for VTherm?I would appreciate your guidance on the correct configuration approach for this common scenario, once the v8.0 bug is addressed.Thank you!

[superdarco78]

Ten błąd pochodzi z niestandardowej integracji.

Rejestrator: homeassistant
Źródło: custom_components/versatile_thermostat/vtherm_hvac_mode.py:40
integracja: Termostat VTherm (dokumentacja, Problemy)
Pierwsze zdarzenie: 19:53:58 (4 wystąpienia)
Ostatnio zalogowany: 19:53:58

Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
File "/config/custom_components/versatile_thermostat/thermostat_climate.py", line 596, in _async_climate_changed
new_hvac_mode = VThermHvacMode(new_state.state)
File "/config/custom_components/versatile_thermostat/vtherm_hvac_mode.py", line 40, in init
raise ValueError(f"Unsupported HVAC mode: {hvac_mode}")
ValueError: Unsupported HVAC mode: unavailable

[jmcollin78]

ValueError: Unsupported HVAC mode: unavailable

Your underlying climate is not working. It is unavaible, si VTherm will not be able to control it.

[superdarco78]

I am writing to strongly confirm the bug I reported. This critical ValueError was NOT present in the previous version (v7.x), and it started appearing immediately after updating to version 8.0.

The error consistently reports:

ValueError: Unsupported HVAC mode: unavailable
This means that my Versatile Thermostat is currently unusable because it cannot handle the standard unavailable state of an underlying entity (like my Shelly BLU TRV).

Could you please investigate this regression? It appears to be a check missing in the new version.

I really appreciate your work and hope for a quick fix so I can continue testing the integration. Thank you!

[jmcollin78]

This is not a regression. This is your device that is unavailable. It cannot work event with the previous release if your device is unavailable.

I will do something for the error log but you have to fix your device.

[jmcollin78]

See #1228 for changing the error log.

[superdarco78]

need urgent assistance with a v8.0ValueError: Unsupported HVAC mode: unavailable error. I can offer you temporary remote access to my Home Assistant application (e.g., via a secure account) to diagnose and fix the issue directly. Please let me know what time and what kind of access you require. Thank you!

[jmcollin78]

Is your device up and running ? Give me your custom attributes as explained here: https://github.com/jmcollin78/versatile_thermostat/blob/main/documentation/en/reference.md#custom-attributes

[jmcollin78]

Hello can you please try this : https://github.com/jmcollin78/versatile_thermostat/releases/tag/8.0.2.beta1

You should force the release with HACS to install it (2 dots, download, ..).

[superdarco78]

?

[superdarco78]

Hello,
I'm experiencing an issue with Versatile Thermostat when using MQTT climate entities (Shelly BLU TRV valves) as heaters.
Problem:
When Home Assistant restarts, VTherm crashes with the following error:
Rejestrator: custom_components.versatile_thermostat.vtherm_hvac_mode
Źródło: custom_components/versatile_thermostat/vtherm_hvac_mode.py:44

Unsupported HVAC mode: 'unavailable'. It may be temporary at startup. Your VTherm will be set to OFF mode.
And:
File "/config/custom_components/versatile_thermostat/thermostat_climate.py", line 752
Error doing job: Task exception was never retrieved
TypeError: str returned non-string (type NoneType)
Root Cause:

My MQTT climate entities have availability: configured
At HA startup, MQTT topics don't have data yet (no MQTT retain enabled)
The underlying climate entities show state "unavailable" for a few seconds (5-30s)
VTherm loads immediately and tries to read the HVAC mode
VTherm receives "unavailable" instead of "heat" or "off"
This causes VTherm to crash

Timeline:

HA restarts (t=0s)
VTherm loads (t=1s) → reads heater entity → sees "unavailable" → CRASH
MQTT automation runs (t=3s) → queries gateway
MQTT entities become available (t=5-10s) → data arrives
Too late - VTherm already crashed

Current Configuration:

4x Shelly BLU TRV valves connected via MQTT
Each valve is configured as MQTT climate entity with modes: ["heat", "off"]
VTherm configured as "Thermostat over climate" using these MQTT entities
Additional features: window sensors, presence detection, schedules
Automation queries gateway every 2 minutes + on HA start (with 3s delay)

Current Workaround:
Removing availability: section from MQTT configuration makes entities always "online", which prevents the crash. However, this means I can't detect when devices are actually offline.
Questions:

Is there already a configuration option in VTherm to add a startup delay before reading underlying entity states? Something like:

yaml startup_delay_seconds: 10

Is there a way to configure VTherm to wait/retry if underlying entity is unavailable at startup instead of immediately crashing?
Could VTherm handle the "unavailable" state more gracefully (e.g., treat it as temporary condition and auto-recover)?
Feature Request: Would it be possible to add a configuration option like:

yaml climate:
- platform: versatile_thermostat
name: "Living Room"
heater: climate.mqtt_trv_salon
startup_delay: 10 # Wait 10s after HA restart before initializing
availability_retry: true # Retry if heater unavailable at startup
availability_timeout: 30 # Wait max 30s for heater to become available
Ideal Solution:
VTherm should either:

Have a configurable startup delay to wait for MQTT entities to populate
Retry checking the heater state until it becomes available (with timeout)
Treat "unavailable" as temporary condition and auto-recover when entity becomes available
Or at minimum: don't crash, just log warning and retry later

Setup Details:

Home Assistant Core: 2024.11+
Versatile Thermostat: (latest custom_component version)
MQTT Broker: Mosquitto
Devices: Shelly BLU Gateway Gen3 + Shelly BLU TRV valves

Why This Matters:
This is a common scenario with MQTT devices - they need a few seconds to publish states after broker connection. Having a startup delay option would make VTherm much more robust with MQTT-based heaters.
Thank you for this great integration! It works perfectly once the initial startup phase is complete. Any guidance on handling this startup issue would be greatly appreciated.
Best regards

🔍 GDZIE SZUKAĆ ROZWIĄZANIA W KODZIE:
Możesz też sam sprawdzić czy jest taka opcja:

Otwórz: /config/custom_components/versatile_thermostat/
Szukaj w plikach:

const.py - stałe konfiguracyjne
config_schema.py - dostępne opcje konfiguracji
init.py - inicjalizacja

Szukaj słów kluczowych:

delay
startup
wait
retry
availability

[superdarco78]

Smart Home Optimization: Presence vs. Motion
My current automation schedule is set for Monday to Friday, 8:00 AM – 4:00 PM, where the primary method for detecting activity is the Motion Sensor.

I want to change this by introducing a detection hierarchy and an energy-saving (Eco) mode:

1. Operation Hierarchy and Modes 🚦
   Mode 1: Presence Priority (Comfort)

When the Presence Sensor detects that I am present or guests have remained (meaning constant presence is detected), the Comfort Mode should be active.

Question: Is it possible to use the Presence Sensor and the Motion Sensor simultaneously within one system/automation, such that presence is the priority? (The answer is yes, this is standard practice in smart home systems where presence (e.g., UWB detection) maintains comfort mode, and motion (PIR) is used for activation or as a backup).

Mode 2: Motion Detection (Out of Zone)

When I leave the presence zone (my presence is no longer detected), the system should switch to Motion Detection (e.g., for guests).

When the Motion Sensor detects movement, it should still maintain the Comfort Mode.

Mode 3: Eco Mode (No Activity)

If:

Presence is not detected (I/guests have left the zone) AND

Motion has not been detected for a specified period (no movement),

The system should switch to Eco Mode (energy saving, e.g., turning off lights, lowering temperature).

2. Schedule and Logic Adjustment
   I want the system to operate between 8:00 AM and 4:00 PM, Monday to Friday:

The system should first check for presence (if I am home), then switch to motion (for guests) when my presence is gone, and finally switch to Eco (when no one is detected).

Request for assistance: I need help in configuring the logic in my automation so that the Presence Sensor acts first, and only then does the system switch to the Motion Sensor when I leave the house (and guests remain).

[superdarco78]

Short Query for the Author/Expert
How can I optimally implement the hierarchical switching between presence and motion detection in a smart home automation system?

I need a solution that automatically switches the system from the Presence Mode (Comfort) to the Motion Detection Mode the moment my constant presence is lost. Subsequently, after the cessation of movement, it should transition into Eco Mode.

What automation logic or platform function (e.g., Home Assistant) is the most effective for this?

[superdarco78]

I have a setup with Versatile Thermostat and I'm trying to implement the
following logic:

Current Configuration:

• 4 rooms with VTherm over_climate (Shelly BLU TRV valves)
• Schedule with "activity" preset (Mon-Fri 8:00-16:00)
• Activity uses motion sensors (different per room)
• Global presence sensor (binary_sensor.obecnosc)

Problem:
When someone is at home and the schedule is in "activity" mode, VTherm uses
motion sensors instead of the global presence sensor. This means that rooms
without motion switch to Eco, even though someone is at home.

What I want to achieve:

• When global presence = ON → Force Comfort (ignore activity/motion)
• When global presence = OFF → Use activity preset (motion sensors work)

My Current Solution:
I created an automation that:

1. Monitors the presence sensor state
2. When presence ON + room has is_presence_configured = true →
   calls climate.set_preset_mode with preset_mode: comfort
3. When presence OFF → does nothing (VTherm schedule takes control)

Code:

alias: VTherm Presence Override
mode: restart
trigger:
  - platform: state
    entity_id: binary_sensor.obecnosc
action:
  - variables:
      presence_on: "{{ is_state('binary_sensor.obecnosc', 'on') }}"
  - repeat:
      for_each:
        - climate.salon
        - climate.dzieci
        - climate.kuchnia
        - climate.lazienka
      sequence:
        - choose:
            - conditions:
                - "{{ presence_on }}"
                - "{{ state_attr(repeat.item, 'is_presence_configured') }}"
                - "{{ not is_state(repeat.item, 'off') }}"
              sequence:
                - service: climate.set_preset_mode
                  target:
                    entity_id: "{{ repeat.item }}"
                  data:
                    preset_mode: comfort

Questions:

1. Is this the correct approach, or is there a better way within VTherm configuration?
2. Could this automation cause conflicts with VTherm's internal logic?
3. Should I disable motion detection in VTherm and handle it differently?
4. Is there a way to set priority hierarchy: presence > activity > motion
   in VTherm settings?
5. Are there alternative solutions you would recommend for this use case?
6. Would it be better to use VTherm's built-in features differently, or is
   an external automation the right approach?

I noticed in the documentation that "presence management" exists, but it seems
to only switch between "home" and "away" temperatures, not override the activity
preset during scheduled activity periods.

The automation works, but I want to ensure I'm not fighting against VTherm's
design and that this won't cause issues in the long term.

Thank you for this excellent integration!

Best regards