Arming Envisalink panel from MSR

[CatmanV2]

Copy attributes button

C

[toggledbits]

So I can see that HA reported the initial state of that sensor on connection as "off" (line 2110 of your hass_state.json.old file). The first mention of the device in your reactor.log is at line 4449 time 12:14:32.197Z, where it looks like you did a x_hass_template.reload from the UI. That completed with a successful response at 12:14:33.512Z. It stands to reason, however, that the action changed the state to "on", because your heating control rule set immediately after that.

On oddity that I haven't seen before is that HA apparently spit out several empty state change notices immediately after the template reload action. I've not seen that before, so it could be new HA behavior. I don't think that should matter, but I can't be sure until I really stare at the code, because usually blank state updates mean the entity has been deleted on the HA side, and that could have side-effects on the Reactor side (like unsubscribing from events).

Stay tuned. We're not done here.

[CatmanV2]

I did indeed do a reload. Never done it before, but was trying to work out how to get them back in sync as it were.

C

[toggledbits]

Well, it seems to do that, but it also seems to expose some odd initialization from the HA side. Digging in...

[toggledbits]

Can you post or upload your template configuration (from HA)?

[CatmanV2]

This was a Claude.AI creation ('cos obviously it's way beyond me!) The specific sensor is at the end but I've posted the whole thing in case...

#################################################
# OwnTracks MQTT Package (inregions-based)
# Phones: Catman & Rachel
#################################################

mqtt:
  sensor:



    ###############################################
    # CATMAN — iPhone
    ###############################################

    - name: "Catman In Regions"
      state_topic: "owntracks/catman/catmaniphone"
      icon: mdi:map-marker-multiple
      value_template: >
        {% if value_json._type == 'location'
              and value_json.inregions is defined %}
          {{ value_json.inregions | join(', ') }}
        {% else %}
          {{ states('sensor.catman_in_regions') }}
        {% endif %}

    - name: "Catman Primary Region"
      state_topic: "owntracks/catman/catmaniphone"
      icon: mdi:map-marker
      value_template: >
        {% if value_json._type == 'location'
              and value_json.inregions is defined
              and value_json.inregions | length > 0 %}
          {{ value_json.inregions[0] }}
        {% else %}
          away
        {% endif %}

    - name: "Catman Location Last Update"
      state_topic: "owntracks/catman/catmaniphone"
      device_class: timestamp
      value_template: >
        {% if value_json._type == 'location'
              and value_json.tst is defined %}
          {{ value_json.tst | int | timestamp_local }}
        {% else %}
          {{ states('sensor.catman_location_last_update') }}
        {% endif %}

    - name: "Catman At Home"
      state_topic: "owntracks/catman/catmaniphone"
      icon: mdi:home
      value_template: >
        {% if value_json._type == 'location'
              and value_json.inregions is defined %}
          {{ 'home' in value_json.inregions | map('lower') | list }}
        {% else %}
          {{ states('sensor.catman_at_home') }}
        {% endif %}

    ###############################################
    # RACHEL — iPhone
    ###############################################

    - name: "Rachel In Regions"
      state_topic: "owntracks/rachel/racheliphone"
      icon: mdi:map-marker-multiple
      value_template: >
        {% if value_json._type == 'location'
              and value_json.inregions is defined %}
          {{ value_json.inregions | join(', ') }}
        {% else %}
          {{ states('sensor.rachel_in_regions') }}
        {% endif %}

    - name: "Rachel Primary Region"
      state_topic: "owntracks/rachel/racheliphone"
      icon: mdi:map-marker
      value_template: >
        {% if value_json._type == 'location'
              and value_json.inregions is defined
              and value_json.inregions | length > 0 %}
          {{ value_json.inregions[0] }}
        {% else %}
          away
        {% endif %}

    - name: "Rachel Location Last Update"
      state_topic: "owntracks/rachel/racheliphone"
      device_class: timestamp
      value_template: >
        {% if value_json._type == 'location'
              and value_json.tst is defined %}
          {{ value_json.tst | int | timestamp_local }}
        {% else %}
          {{ states('sensor.rachel_location_last_update') }}
        {% endif %}

    - name: "Rachel At Home"
      state_topic: "owntracks/rachel/racheliphone"
      icon: mdi:home
      value_template: >
        {% if value_json._type == 'location'
              and value_json.inregions is defined %}
          {{ 'home' in value_json.inregions | map('lower') | list }}
        {% else %}
          {{ states('sensor.rachel_at_home') }}
        {% endif %}

#################################################
# TEMPLATE SENSORS (merged correctly)
#################################################

template:
  - sensor:
      - name: "Household Presence"
        icon: mdi:account-group
        state: >
          {% set catman = states('sensor.catman_primary_region') | lower %}
          {% set rachel = states('sensor.rachel_primary_region') | lower %}

          {% set cm =
            '🏠' if catman == 'home' else
            '🏢' if catman == 'office' else
            '🚗'
          %}

          {% set ra =
            '🏠' if rachel == 'home' else
            '🏢' if rachel == 'office' else
            '🚗'
          %}

          Catman {{ cm }} | Rachel {{ ra }}

  - binary_sensor:
      - name: "Someone Home"
        icon: mdi:home-account
        state: >
          {{ states('sensor.catman_primary_region') | lower == 'home'
             or states('sensor.rachel_primary_region') | lower == 'home' }}
            


        

C

[toggledbits]

Does that sensor reliably come up "off" when you restart HA?

[CatmanV2]

I don't believe so, It's been used in several places in HA without issue across restarts. I will see if I can double check that however, as it may simply not have been noticed if it's coming up 'off' and immediately tripping to the correct state.

C

[CatmanV2]

OK I've just done some digging: When HA restarts, all three sensors

sensor.rachel_primary_region

Go 'unknown'

Someone Home (fairly logically) goes 'Off'

The period of 'Unknown' is about 5-10 seconds before the correct status is realised.

Here's the data from the last restart

binary_sensor.someone_home	unknown	2026-05-19T12:06:55.461Z
binary_sensor.someone_home	off	2026-05-19T12:07:04.582Z
binary_sensor.someone_home	on	2026-05-19T12:07:11.505Z

TIA

C

[therealdb]

It may. I have similar behavior with other Template sensors being 0/null/off at boot.

As a defensive measure, I always make the condition to be sustained for at least 10 secs and/or avoid them being evaluated when ha has been restarted for the last 20 secs.

I rarely use ha templates, so my experience is anecdotal.

[CatmanV2]

Thanks, helpful input!

C

[therealdb]

I think you may just filter for unknown and return null. Tell that to my friend Claude

[CatmanV2]

@therealdb that would rather force (in this case) all the heating off (or on), wouldn't it?

I like the idea of a 30 second delay though.

C

[therealdb]

I don’t know if setting to null it’s better for reactor. @toggledbits here is the best source of truth.

[CatmanV2]

Of course. I'm not sure what I'd do without him!

C

[toggledbits]

OK. I can't prevent HA from starting up in an undefined state, and the effect that can have on the rules, but @therealdb is spot-on with an approach to dealing with that, since the corrected state usually comes pretty quickly after. Sometimes, you just have to debounce those switches a little.

Beyond that, there is definitely an opportunity for a race condition and I think I have a good general fix for that. The logs support that cause as well. Testing my updates now. Will likely do a build with the update tomorrow.

[CatmanV2]

Fabulous!

I've actually just put reset delays in the two rules that are triggered. The 'set' is heating on so it's the reset that's a PITA. That should cover it.

C

[toggledbits]

This is just a follow-up to link this conversation to the announcement for the build that addresses it, and expands generally on transient startup/outage states in HA integrations

[CatmanV2]

Thanks, installed and working.

Although after the first restart there were some virtual switches in HA that were not being accurately reflected in MSR, but I restarted MSR again, and everything looks fine.

Thanks again for your help. Next time I'll upload the logs to start with!

C