Zamel LEM-30 i ESPHome

Inaczej nie da się utworzyć pętli prądowej i zalet jej stosowania.
Próbowałem zrobić wytłumaczenie na Twoim poziomie pojmowania ale to raczej, na razie niemożliwe :slight_smile:
Musisz przyjąć na wiarę, że tak trzeba.

Oba wytłumaczenia mi odpowiadają :wink:
[dodano po 14h]
Panowie. Koledzy. Już chciałem odtrąbić wielki sukces. A tu takie coś:


Witki mi opadły poniżej poziomu podłogi. Chyba już nie ma sensu gnębić to hardware’owo i trzeba odsiać to sofware’owo,

Filtrowanie programowe zamiast znalezienia problemu źródłowego to takie chowanie głowy w piasek.

Mówisz, że zdarzenia te są losowe, ale zastanów się co się mogło stać o tych konkretnych godzinach, gdzie masz piki, poprzednio też to było wieczorem.

Jeśli jesteś w stanie powiązać piki z działaniem, włączaniem lub wyłączaniem jakiegoś urządzenia elektrycznego, to możesz wywołać jego działanie/włączenie/wyłączenie celowo by potwierdzić/zaprzeczyć diagnozę.

Droga ostatniej deski ratunku to podpięcie ESP na stałe to włączonego komputera (z wyłączonym usypianiem) i nazbieranie logów z ESP po UART’cie abyś mógł przeanalizować tylko te fragmenty z okolic czasu zdarzeń, bo jak wiadomo w przyrodzie się nic bez przyczyny nie dzieje.

PS Dołożyłeś do YAMLa choćby te najprostsze sensory diagnostyczne, które wspominałem gdzieś wyżej? Choćby sam uptime, żeby można było stwierdzić czy w okolicy pików ESP się nie rebootuje.

Jeszcze zanegowałbym wejście, bo w tym układzie impuls zamast 30ms trwa od 0 do niekończoności.
Nie wiem co dokładnie siedzi w programie ale może dochodzic do “przekręcenia” jakiś liczników i program się wywala.
W przewodach płynie trwale 3-10mA , trzeba by spawarki aby go zakłócić. Trzeba szukać gdzieś indziej.

Trochę podejrzewałem piekarnik, ale piki trafiają się również w nocy.
Poniżej obrazek z ostatniej godziny. Wpisy pojawiają się również w logu w tym samym czasie.

Nazbierałem po WiFi: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

W logu jest również uptime.

W jaki sposób zanegować?

Opcja inverted dla ustawień GPIO

Bez jaj, szanuj nasz czas, chyba nie sądzisz, że ktoś będzie analizował logi o wielkości takiej, że musiałeś użyć wetransfera by je wysłać, znasz godziny zdarzeń - do analizy potrzeba tylko fragmentów np. mniej-więcej od 17:29 do 17:32 dla piku ze środka obrazka (dysponujesz w HA dokładniejszymi danymi, więc można nieco zawęzić, ważne dane są wstecz zwykle nie dalej niż dwukrotna szerokość piku i pojedyncza po, no chyba że był restart itp. no sam będziesz widział jakieś anomalie).


Gdzie jest wykres sensora uptime dla tego sprzętu i z tego czasu?

Po to sugerowałem sensor uptime, aby było łatwo go zwizualizować razem z pikami na 2 powiązanych wykresach (najprościej używając panelu historii)


Źródłem zakłóceń może być coś na co nie masz wpływu, oczywiście najpierw należy szukać czegoś blisko, no nie mam pojęcia czego musisz szukać, przykłady z życia wzięte

  • hydrofor
  • stara lodówka (podkreślam stara, bo takie potrafią generować zakłócenia w losowych momentach)
  • generalnie sprzęt AGD uruchamiany automatycznie lub ręcznie (zmywarka, pralka, odkurzacz, ogrzewacz wody, terma itd.)
  • piec z podajnikiem ślimakowym (tu szczególnie widać powiązanie z pogodą/temperaturą na zewnątrz)
  • sąsiad “spawacz”
  • sąsiad krótkofalowiec ze źle zestrojonym sprzętem, albo pseudo-fanatyk CB-radia (w dzisiejszych czasach to rzadkość, kiedyś bywało inaczej)
  • w bloku to generalnie sąsiedzi, którzy potrafią robić dziwne rzeczy o dziwnych porach
  • pobliska nietypowa działalność gospodarcza
  • pobliska jednostka wojskowa lub lotnisko

Wydaje się, że to rozwiązało problem. Znaczy zdażają się jakieś “duchy” ale po 40W w minutę, więc jestem w stanie to zaakceptować.

Pojawił się jednak kolejny problem, albo ja nie rozumiem jak to działa. Chodzi o sensor/pomocnik

total_daily_energy

Czy jego wartość nie powinna się kasować o północy? U mnie ona narasta - bez końca:


Natomiast sensor:

total

“Pamięta” dane do ostatniego resetu (właściwie do wgrania nowego yamla):


Tu jestem skłonny się zgodzić z tym “zapominaniem”.

Masz dodany komponent time?

# Enable time component to reset energy at midnight
time:
  - platform: homeassistant
    id: homeassistant_time

Osobiście to mam obiekcje do trwałego zapamiętywania czegokolwiek w pamięci flash MCU.
Ciekawe po ilu zapisach (jakim czasie) zabijesz ESP?

Cały ten projekt jest jakiś “kwadratowy” ? - najpierw różniczkuje energię aby uzyskać moc, po to aby ją całkować dla uzyskania energii :exploding_head:

Tak. Ale nie platform: homeassistant.

Nie wiem.
A ten: https://esphome.io/cookbook/power_meter jest również “kwadratowy”? Oczywiściem w linku nie jest nic “prosto z mostu” - w sensie - przekopiuj i korzystaj, tylko kilka wrzutek po drodze, które są ze sobą powiązane ale nie jest tam powiedziane co całkować a co różniczkować i w jakiej kolejności. Na esphome.io, w “wątku” o total_daily_energy jest odwołanie go gotowego sensora/urządzenia (hlw8012) przez co opis jest nieco oderwany od mojego przypadku.
Niby w linku rozwiązanie identiko, a właśnie klepię 69-go posta w tym przypadku.

Czy tę encję stworzyłeś w HA używając pomocnika licznik mediów?

To raczej normalne zachowanie w przypadku ESPHome.

Osobiście przy tworzeniu konfiguracji dla licznika wody dodałem w HA pomocnika licznik mediów bez okresy zerowania, czyli stworzyłem licznik total, przyrostowy na bazie sensora total z ESPHome. Analogicznie pozostałe liczniki już cykliczne.

Zawsze bardzo mnie to drażniło w dokumentacji ESPHome, przypomina rozsypane puzzle. Zaczynałem przygodę z ESP od Tasmota i tam jak coś już czytasz to układa się w logiczny ciąg. Przeciwnicy narzekają na rozwlekłą tabelę komend ale przynajmniej jest do przejrzenia i zastosowania w locie z dokładnym opisem przypadków użycia. Natomiast ESPHome to zlepek przypadkowych klocków, z których metodą prób i błędów dochodzisz do mniej lub lepiej działającego YAML, a po jakimś czasie odnajdujesz przypadkowo informację, że jednak można było to zrobić zupełnie inaczej i lepiej.

Próbuję całość ogarnąć w ESPHome, gdyż:

  1. W Cookbook działało.
  2. Inne gniazdka (ale bardziej smart - np. Gosundy)
  3. Chciałbym zachować “czystość rasy”.

Dla jasności poniżej pełny kod, który ewoluował w trakcie tej dyskusji:

substitutions:
  devicename: "licznik-el-wyspa"
  friendly_name: "Licznik en. el. - wyspa"

esphome:
  name: "licznik-el-wyspa"
  friendly_name: $friendly_name

esp8266:
  board: d1_mini #_mini_lite #d1_mini


# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

wifi:

  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: on
  manual_ip:
    # Set this to the IP of the ESP
    static_ip: 192.168.1.226
    # Set this to the IP address of the router. Often ends with .1
    gateway: 192.168.1.1
    # The subnet of the network. 255.255.255.0 works for most home networks.
    subnet: 255.255.255.0

captive_portal:
    
time:
  - platform: sntp
    timezone: Europe/Warsaw
    servers:
      - 0.pl.pool.ntp.org
      - 1.pl.pool.ntp.org
      - 2.pl.pool.ntp.org
    id: sntp_time
  - platform: homeassistant
    id: homeassistant_time
    
# Enable Web server
web_server:
  port: 80    

binary_sensor:
  - platform: status
    name: "${friendly_name} Node Status"
    id: system_status
    
sensor:
  - platform: pulse_meter
    name: 'Jakaś moc'
    id: sensor_pulse_meter # Optional ID, necessary if you want to calculate the total daily energy
    unit_of_measurement: 'W'
    device_class: power
    state_class: measurement
    accuracy_decimals: 0
    internal_filter: 200ms
    pin:
      number: GPIO12
      mode:
        input: true
      inverted: true
#        pullup: true    
    filters:
      - multiply: 60 
      - throttle_average: 10s
      - filter_out: NaN
    total:
      name: "Electricity Total"
      unit_of_measurement: "kWh"
      device_class: energy
      state_class: total_increasing
      accuracy_decimals: 3
      filters:
        - multiply: 0.001  # (1/10000 pulses per kWh)


#  - platform: total_daily_energy
#    name: "${devicename} - Todays Usage"
#    power_id: "power_wattage"
#    filters:
#      # Multiplication factor from W to kW is 0.001
#      - multiply: 0.001
#    unit_of_measurement: kWh

  - platform: total_daily_energy
    name: "Total Daily Energy"
    id: sensor_total_daily_energy
    power_id: "sensor_pulse_meter"
    unit_of_measurement: kWh
    state_class: total_increasing
    device_class: energy
    accuracy_decimals: 3
    filters:
      # Multiplication factor from W to kW is 0.001
      - multiply: 0.001
  - platform: uptime
    name: "${friendly_name} - Uptime"
    entity_category: diagnostic
  - platform: wifi_signal
    name: "${friendly_name} - sygnał WiFi"
    update_interval: 60s
    entity_category: diagnostic

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "${friendly_name} IP Address"
# pozostałe informacyjnie
    scan_results:
      name: "${friendly_name} - Latest Scan Results"
    ssid:
      name: "${friendly_name} - Connected SSID"
    bssid:
      name: "${friendly_name} - Connected BSSID"
    mac_address:
      name: "${friendly_name} - Mac Wifi Address"

Przychylam się do tego stwierdzenia, jednak dlaczego total_daily_energy nie kasuje się, skoro total na daną chwilę równa się zero? Pewnie dogłębne przestudiowanie kodu ESPHome dałoby na to odpowiedź, lecz dla mnie zachowanie jest nieintuicyjne. [EDIT]. Chyba jednak coś znowu zrozumiałem. Total nie ma tu znaczenia. total_daily_energy przechowywane jest zapewne w innej zmiennej, która właśnie całkuje po czasie wszystkie wskazania do północy.

Hmm. A więc “starzy wyjadacze” również podzielają moje zdanie. Łudzę, się, że od przypadku do przypadku w końcu złapię ich tok rozumowania i w ogóle składnię kodu z uwzględnieniem kolejności stawiania klocków - vide powyższe całkowanie z różniczkowaniem.

1 polubienie

Tak zastanawiam się nad domyślnym ustawieniem opcji timeout dla pulse meter sensor. Jest to 5 min i rodzi się pytanie, jak zachowa się logika dla małych poborów gdzie generowanie impulsu może trwać dłużej niż 5 min.

  • timeout (Optional, Time): If we don’t see a pulse for this length of time, we assume 0 pulses/s. Defaults to 5 min.

Jakby ktoś jeszcze miał siły, to poniżej kolejna zagwozdka:


Ki czort, że przy włączeniu TV, zużycie dzienne startuje od (dziś) 0,67kWh? Wczoraj było podobnie, tyle że start był od 0,38kWh.

…być może źle przepisałeś z przykładu?. Z wykresów wynika, że z niewłaściwego sensora liczy daily.
O ile total wygląda poprawnie to daily liczy nawet gdy power jest bliski 0.

Z tego co ja rozumiem, total_daily_energy ma pobierać dane z:

sensor:
  - platform: pulse_meter
    name: 'Jakaś moc'
    id: sensor_pulse_meter

id w - platform: total_daily_energy jest chyba zupełnie zbędne. No chyba, że jest odwrotnie i do tego nawiązywałeś w “kwadraturach”.

No właśnie - gdzieś może to jest napisane, a każdy rozumie jak umie :slight_smile:

Sprawdź czy zero mocy jest dokładnie 0.000

Rozwiń proszę.

Myślałem, że może dodaje stałą wartość, ale wczoraj startowa była inna niż dzisiaj. Może mnoży? Tylko dlaczego. Reszta wykresów wydaje się być w porządku.

Masz rację total wygląda dobrze - gdy moc =0 wykres jest płaski.
Przerzuć obliczanie daily do HA przy użyciu utility_meter.

Moja teoria - strefy czasowe w HA i ESPHome się rozjechały i reset nie następuje o północy, ale to tak sobie strzelam, bo nie mam pomysłu z czego wynika problem

YAML dla ESPHome, który korzysta z polskich pul serwerów NTP i naszej strefy czasowej

time:
  - platform: sntp
    timezone: Europe/Warsaw
    servers:
      - 0.pl.pool.ntp.org
      - 1.pl.pool.ntp.org
      - 2.pl.pool.ntp.org
    id: sntp_time
1 polubienie