Possible mismatch between binary_sensor in HA and MSR
-
So I can see that HA reported the initial state of that sensor on connection as "off" (line 2110 of your
hass_state.json.oldfile). The first mention of the device in yourreactor.logis at line 4449 time 12:14:32.197Z, where it looks like you did ax_hass_template.reloadfrom 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.
-
Well, it seems to do that, but it also seems to expose some odd initialization from the HA side. Digging in...
-
Can you post or upload your template configuration (from HA)?
-
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
-
Does that sensor reliably come up "off" when you restart HA?
-
-
OK I've just done some digging: When HA restarts, all three sensors
sensor.rachel_primary_regionGo '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.505ZTIA
C
-
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.
-
@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
-
I don’t know if setting to null it’s better for reactor. @toggledbits here is the best source of truth.
-
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.









