# Template sensor z pomocnika (input\_number) - przy restarcie HA staje się 'unknown'

**URL:** <https://forum.arturhome.pl/t/template-sensor-z-pomocnika-input-number-przy-restarcie-ha-staje-sie-unknown/8127>\
**Category:** Home Assistant\
**Tags:** mariadb\
**Created:** [3 Luty 2023 22:07 UTC](https://forum.arturhome.pl/t/template-sensor-z-pomocnika-input-number-przy-restarcie-ha-staje-sie-unknown/8127 "2023-02-03T22:07:03Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Autor:** ![maciej1](https://forum.arturhome.pl/letter_avatar_proxy/v4/letter/m/c5a1d2/32.png) [@maciej1](https://forum.arturhome.pl/u/maciej1)\
**Data wpisu:** [3 Luty 2023 22:07 UTC](https://forum.arturhome.pl/t/template-sensor-z-pomocnika-input-number-przy-restarcie-ha-staje-sie-unknown/8127/1 "2023-02-03T22:07:03Z")

</div>

Mam template sensory, które biorą wartości z input\_number. Przy restarcie HA, wartość sensorów zmienia się na chwilę na ‘unknown’, a potem z powrotem na poprzednią. Przez to tworzą się zduplikowane wartość w bazie oraz timestamp ostatniej zmiany jest nieprawidłowy.

Definicja przykładowego sensora:

```auto
- name: Bieżnia dystans w km
  unique_id: bieznia_dystans_w_km
  availability: "{{ is_number(states('input_number.bieznia_dystans')) }}"
  state: >-
    {{ (states('input_number.bieznia_dystans')|float(0) / 1000)|round(2) }}
  unit_of_measurement: "km"

```

W bazie danych tworzy się para nowych rekordów:

 ![Clipboard02](https://forum.arturhome.pl/uploads/default/original/2X/3/345281e412d677f04508e78aedf774fa814bf74e.jpeg)

Pewnie ma to związek z tym, co widzę w logu po restarcie (czas ten sam co w bazie, godzina różnicy przez czas lokalny). Rekord ‘unknown’ w bazie pojawia się tuż po tych wpisach w logu.

```auto
2023-02-03 22:14:39.858 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform command_line is taking over 10 seconds.
2023-02-03 22:14:39.874 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform command_line is taking over 10 seconds.
2023-02-03 22:14:39.877 WARNING (MainThread) [homeassistant.setup] Setup of input_select is taking over 10 seconds.
2023-02-03 22:14:39.880 WARNING (MainThread) [homeassistant.setup] Setup of input_datetime is taking over 10 seconds.
2023-02-03 22:14:39.882 WARNING (MainThread) [homeassistant.setup] Setup of input_text is taking over 10 seconds.
2023-02-03 22:14:39.883 WARNING (MainThread) [homeassistant.setup] Setup of counter is taking over 10 seconds.
2023-02-03 22:14:39.885 WARNING (MainThread) [homeassistant.setup] Setup of zone is taking over 10 seconds.
2023-02-03 22:14:39.887 WARNING (MainThread) [homeassistant.setup] Setup of input_boolean is taking over 10 seconds.
2023-02-03 22:14:39.889 WARNING (MainThread) [homeassistant.setup] Setup of input_button is taking over 10 seconds.
2023-02-03 22:14:39.891 WARNING (MainThread) [homeassistant.setup] Setup of input_number is taking over 10 seconds.

```

Help! 🙂

EDIT:

Po różnych testach, wiem już coś więcej. Przede wszystkim: powtarzanie wartości stanów jest cechą HA, a nie bugiem, więc trzeba nauczyć się z tym żyć. Szybkość włączania się systemu nic do tego nie ma. Ja połączyłem bieżnię z HA (przez ESP32 i MQTT) i chciałem mieć podsumowania np. tygodniowe pokonanego dystansu, gdzie te powtórki przeszkadzały.

W przypadku niektórych encji, powtórki da się odróżnić od rzeczywistego nowego stanu, gdyż poprzedza ją zawsze rekord ze stanem unknown/unavailable, będący “parentem” (pole “old\_state\_id”). Tak jest przy sensorach MQTT i template. Można więc odfiltrować powtórzone stany; np. taki kod, po wklejeniu do integracji SQL (MariaDB), zwróci stany z historii template sensora, bez powtórek, pogrupowane tygodniami, jako 1 wiersz w formie tablicy:

```auto
select now() state, x.json_arr from (
with
	my_entity as (select * from states where entity_id = 'sensor.bieznia_dystans_w_km'),
	entity_bad as (
		select state_id from my_entity where state in ('unavailable', 'unknown')
	),
	entity_good as (
		select FROM_UNIXTIME(e.last_updated_ts) adate, state
		from my_entity e
		# wykluczam bad oraz te z parentem bad
		left join entity_bad eb on e.state_id = eb.state_id or e.old_state_id = eb.state_id
		where eb.state_id is null
	),
	entity_groupped as (
		select round(sum(state),2) st, Date(max(adate)) dt
		from entity_good
		# grupowanie tygodniami
		group by extract(week from adate)
		# max 6 ostatnich tygodni
		order by dt desc limit 6
	),
	arr_element as (
		# zamiana 2 kolumn na 1: [data, stan], plus data obok do posortowania
		select json_array(dt, st) el, dt
		from entity_groupped
	)
	# agregacja w jedną tablicę tablic, kolejność wg dat/tygodni w roku
	select json_arrayagg(el order by dt) json_arr from arr_element
) x;
Wynik (1 wiersz, 2 kolumny):
2023-02-14 11:05:44.000 [["2023-01-14", 50.67],["2023-01-21", 50.06],["2023-01-28", 50.89],["2023-02-04", 49.39],["2023-02-11", 52.46],["2023-02-12", 7.76]]

```

SQL jest długachny, ale CTE i komentarze trochę ratują 🙂 (mój faktyczny kod jest 2x dłuższy, ale integracja spoko to akceptuje). Zwracaną tablicę ładuję jako atrybut sensora SQL (brak ograniczenia ilości znaków), a kolumna state trafia do stanu sensora. Taki sensor nie potrzebuje już swojej historii, on tylko wyciąga dane. Potem w apexcharts:

```auto
series:
  - entity: sensor.bieznia_dystans_wg_tygodni_sql
    data_generator: |
      return JSON.parse(entity.attributes.json_arr)

```

![Clipboard02](https://forum.arturhome.pl/uploads/default/original/3X/0/a/0a68c3cebee6e7dc5a830ab6127fc9516019340a.jpeg)

Aha, jeszcze jedno: trzeba zwrócić uwagę na pierwszy liczbowy stan template sensora, po jego utworzeniu. W bazie zapisywana jest wówczas też para rekordów (bo sensor powstaje po restarcie HA/przeładowaniu template): rekord uknown/unavailable + pierwszy liczbowy stan. Więc albo akceptujemy pominięcie pierwszego stanu (przez kod SQL) albo - jeśli ten inicjujący stan liczbowy ma być wliczany - trzeba wyedytować zupełnie pierwszy rekord i zmienić unavailable/unknown na 0.