Комментарии 23
После реализации подобного импульсного счётчика, стал замечать о серьёзную погрешность, набегающую в ошибку.
Проблема в дребезге контактов геркона.
Подбирал несколько месяцев фильтр в строке 72
#снятие показаний со счетчика через датчик импульсов IN-Z61
#коричневый ------------ GND
#зеленый --+-- 10k -- VCC 3v3
#. |
#. +--------- GPIO14 (D5) ESP8266
# WeMos D1 ESP-Wroom-02 ESP8266 Nodemcu WiFi Module With 18650 Battery Charging
substitutions:
pulse_pin: D2
esphome:
name: gas-bk-g4t
esp8266:
board: d1_mini
restore_from_flash: true
preferences:
flash_write_interval: 60min
# включаем отладку для поиска причины перезагрузки через лог
debug:
logger:
# Enable Home Assistant API
api:
services:
# для устаноки начального значения счетчика
- service: update_counter_pulses
variables:
counter_pulses: float
then:
- globals.set:
id: pulses_sum
value: !lambda 'return counter_pulses;'
reboot_timeout: 0s # иначе перезагружается при отключении от hassio
ota:
- platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "GAS-BK-G4T Fallback Hotspot"
password: !secret ota_pass
reboot_timeout: 0s # иначе перезагружается при потере wifi
captive_portal:
globals:
- id: pulses_sum
type: int
restore_value: yes
initial_value: '1000000'
binary_sensor:
- platform: gpio
id: internal_pulse_counter
pin:
number: ${pulse_pin}
mode: INPUT
name: "Live-Impuls"
filters:
- delayed_on_off: 200ms
on_press:
then:
- lambda: id(pulses_sum) += 1;
- lambda: id(gas_cons).publish_state(id(pulses_sum));
sensor:
- platform: template
name: "Gas consumption"
id: gas_cons
device_class: gas
unit_of_measurement: "m³"
state_class: "total_increasing"
icon: "mdi:fire"
accuracy_decimals: 2
filters:
lambda: |-
return x * 0.01;
# для отслеживания времени работы esp
- platform: uptime
name: Uptime Sensor
id: uptime_sensor
update_interval: 60s
internal: true
on_raw_value:
then:
- text_sensor.template.publish:
id: uptime_human
state: !lambda |-
int seconds = round(id(uptime_sensor).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return (
(days ? to_string(days) + "d " : "") +
(hours ? to_string(hours) + "h " : "") +
(minutes ? to_string(minutes) + "m " : "") +
(to_string(seconds) + "s")
).c_str();
text_sensor:
- platform: template
name: Uptime Human Readable
id: uptime_human
icon: mdi:clock-start
RC фильтр не проще было впаять для устранения дребезга?
И обратите внимание на esp32-c3 mini:
для одного входа такой огромный боард.
Столкнулся с тем, что ESP32 Super mini имеет гораздо худший прием WiFi. У модуля компактные размеры - в т.ч. и антенны
В дальних углах лучше ставить "большие" варианты модулей на ESP32
Я тоже пробовал реализовать подсчет через binary_sensor, но добиться корректных показаний не смог. Казалось бы, какая разница через что писать в глобальные переменные.
А по поводу дребезга контактов - подтверждаю, тоже пришлось поиграться, но только параметром debounce. 10 мс в моем случае было достаточно.
А как обстоят дела при отключении электроэнергии? Насколько я понял, устройства не имеют автономного источника питания и, в случае сбоя в электропитании, придется обновлять начальные показания счётчиков.
Есть waterius, тоже тут на хабре пишут статьи и у них понадежнее решение для газа и воды.
Ватериус - это законченное решение. Но кому-то не хочется иметь зависимость от внешних сервисов. ESPhome позволяет таким людям сделать свое устройство внутри HomeAssistant.
Ватериус опенсорсный, исходники на гитхабе, отправляет в ваш HomeAssistant, собирается так же на esp. Про какую зависимость вы говорите? Может вы просто не в курсе про возможности?
Я писал в поддержку ватериуса по поводу совместимости с выходом "открытый коллектор". Они сказали что не поддерживается.
Для счетчиков воды их можно рассмотреть, но для моего счетчика газа - не факт.
Купив плату ESP32 за 300 р я получил работающее решение.
Купить устройство в 10 раз дороже и потом его пытаться допилить? Избавляться от возможных некорректных измерений?
Вот когда они сделают устройство под ключ и под мой счетчик газа - тогда цена будет оправдана.
После пропажи питания (либо перезагрузки устройства) будет выводиться последнее записанное в глобальную переменную globals: значение. Да, возможны небольшие погрешности (например счетчик не записал импульс перед отключением), но тут выбирает каждый сам для себя. Если перебои с электроснабжением частые, то нужно организовывать независимое питание. Если как у меня - отключения крайне редкие, а когда нет света, то и воды тоже нет, то можно показания счетчиков раз в год и подкрутить к фактическим.
У меня для аналогичной задачи аналогично мало опыта, но очень хочется сделать счётчик в deep-sleep, отправляя по mqtt только изменения раз в час если они вообще говоря были и раз в сутки статус "я жив".
Deep sleep хочется чисто из-за возможности жить по полгода от одной батарейки
https://habr.com/ru/companies/timeweb/articles/827248/#comment_27062038
Я использовал счётчик воды элехант. Он не имеет никаких выводов (даже экрана), но передаёт все показания по Bluetooth пакетами Advertising.
Предполагается получение показаний через их лагучее приложение на телефоне, но я пошел другим путём.
На Raspberry принимал пакеты и парсил, потом в influxDB, визуализировал графики в Grafana. Ещё встречал скрипт для HA на гитхабе (оттуда собственно и разобрался, что собственно посылает счётчик). Преимущество данной схемы в том, что кроме счётчика и Raspberry не нужно дополнительных устройств.
У элехант, кстати, есть и на газ счётчики.
Оффтопно, у вас большие карточки, я у себя все сгруппировал более компактно с помощью room-card
картинка
Расскажите, пожалуйста, подробнее про учет ресурса фильтров. Как ваша реализована карточка с фильтрами, отображается ли там остаточный ресурс, есть ли напоминание о замене?
Я воспользовался интеграцией из HACS Variables.
Потом создал переменные по каждому фильтру:
# Переменная показания счетчика фильтра к5 при его замене
filter_counter_k5:
initial_value: 0
icon: mdi:air-filter
# Переменная дата замены фильтра к5
filter_k5_change_date:
initial_value: '22.09.2021'Ну а потом завел переменную расхода в template, где 4000 это принятый мной ресурс фильтра:
- platform: template
sensors:
filter_k5:
friendly_name: "Ресурс фильтра грубой очистки К5"
value_template: "{{ 4000 - states('sensor.water_count_saved_total_filter_water_consumption')|float + states('var.filter_counter_k5')|float }}"
unit_of_measurement: 'л'
unique_id: filter_k5Код карточки ниже. В нем, я думаю, что все понятно:
type: entities
show_header_toggle: false
entities:
- entity: sensor.filter_k5
icon: mdi:numeric-5-box-multiple-outline
double_tap_action:
action: call-service
confirmation:
text: Ты уверен что хочешь сбросить ресурс фильтра к5?
service: script.5
type: custom:secondaryinfo-entity-row
secondary_info: "Дата замены: [[ var.filter_k5_change_date ]]"Напоминание о замене картриджей не делал - надобности нет, но есть куча других напоминалок, например оформление ОСАГО в Telegram.
alias: ОСАГО Sorento
description: ""
mode: single
triggers:
- at: "08:00:00"
trigger: time
conditions:
- condition: numeric_state
entity_id: sensor.day_sorento_insurance_remain
below: 30
actions:
- data:
message: >-
Необходимо оформить ОСАГО на Sorento. Страховка будет действовать еще
{{ states('sensor.day_sorento_insurance_remain') }} дн.
title: ОСАГО
action: notify.group_notify
Публикации
Счетчики газа и воды на ESP32 в Home Assistant