Het grote ESPhome topic

[Septillion]

Wat is ESPhome?

ESPhome is een toolchain om gebaseerd op een configuratieomschrijving firmware voor een microcontroller te schrijven. Van oorsprong bedoelt om IoT of "smart" devices mee te maken maar het kan in princiepe ook voor een stand alone toepassing gebruikt worden.

In plaats van code te schrijven benoem je componenten in een gestructureerd yaml-bestand waarmee de tool de werkelijke code maakt. Op de achtergrond wordt de hele configuratie vertaalt naar C++ en daarna gecompileerd en geprogrammeerd. Laatste kan zowel via een kabel of Over The Air ofwel OTA (als er eenmaal firmware op draait).

Voor complexe taken biedt ESPhome nog de mogelijkheid om lambda's te schrijven. Dit zijn stukken C++ code waarmee je direct de achterliggende C++ objecten aan kunt spreken.

ESP only?

De naam geeft het al weg, maar de basis voor ESPhome was de ESP serie van microcontrollers van Espressif. Eerst de "oer-ESP" ESP8266 maar later ook de smaken van de ESP32. Maar ondertussen is ESPhome bruikbaar op meer dan alleen ESP's. Ook de RP2040 van Raspberry Pi, de BK7231T en BK7231N van Beken en de RTL8710BN en RTL8710BX Realtek worden ondersteund. De BK72xx en RTL87xx lopen via het LibreTiny (vroeger LibreTuya) project.

HA Only?

ESPhome is als losstaand project ontstaan maar is tegenwoordig onderdeel van Nabu Casa, het bedrijf achter Home Assistant. Voor Home Assistant is dan ook een directe API en integratie beschikbaar waardoor ze makkelijk en uniform te integreren zijn. Maar dit betekend niet dat het niet bruikbaar is om losstaand of met een andere smart home platform te gebruiken.

Installeren / draaien

De meest makkelijke manier om ESPhome te draaien is via de ESPhome addon in Home Assistant . Hierdoor krijg je een ESPhome-dashboard in Home Assistant vanaf waar je al je ESPhome devices kunt onderhouden.

Daarnaast is er een Docker container beschikbaar maar ook een handmatige installatie (via Python) is mogelijk. Ook via die opties is het mogelijk om het (web) ESPhome Dashboard te draaien.

Quick start

In plaats van via het Dashboard (of commandline) een lege config aa te maken kan je ook een initiële firmware op een device zetten via de Web uploader. Deze upload volledig via de browser Kickstarter firmware waarmee de Wifi ingesteld kan worden en waarna hij beschikbaar komt in het ESPhome Dashboard. Hierna zijn updates via OTA te doen. Voor ESPhome Web is een Chromium browser nodig en alleen ESP of RP2040 zijn ondersteund.

Ook zijn er enkele tooltjes die ook al de Kickstart firware kunnen uploaden zoals bijvoorbeeld de Tuya Cloudcutter.

Kookboeken, ideeën en links

• ESPhome Cookbook (Kookboek met algemene voorbeelden)
• ESPHome Device Configuration Repository (kant en klare (maar aanpasbare) configuraties voor bestaande devices)

Helpen?

Zoals je ziet is deze startpost nog redelijk beknopt. Ik wilde vooral een plek buiten het Home Assistant topic maken voor specifiek vragen (en ideeën) rond ESPhome. Dit omdat het toch wel twee losse dingen zijn.

Mocht je willen helpen met het uitbreiden van de start post, graag! Neem dan even contact op via DM.

Code delen

Wil je code delen in je post, plaats deze dan tussen YAML-code tags. Gebruik hiervoor [code=yaml]jecode[/code]. Geen plaatjes van code!

secrets.yaml

Zeker als je code deelt is het handig als hier geen "geheime" informatie in staat zoals je wifi wachtwoord of je API-key. Hiervoor kent ESPhome een secrets.yaml. Standaard wil ESPhome hier al je Wifi SSID en password in zetten maar dit is uit te breiden naar alles wat je geheim of centraal wilt houden. Hiervoor kun je de secrets.yaml aanpassen zoals:

YAML:

wifi_ssid: "Hacker WiFi"
wifi_password: "Sup3r S3cr3t!"
api_key: "HeIZEX4PlyoVNtZuomxYt89RC+ugqkvwnfhEYa57Glg="
erg_gevoelig: "Dit mag niemand weten"

Waarna je in een device kunt doen:

YAML:

esphome:
  name: esphome-web-24df1c
  friendly_name: Super device
  comment: !secret erg_gevoelig

api:
  encryption:
    key: !secret api_key

Enige nadeel van de API key in de secrets.yaml hebben is dat alle devices dan dezelfde key gebruiken.

[ Voor 16% gewijzigd door Septillion op 07-10-2024 18:30 ]

[vso]

mooi dat er een apart topic is !

Zou mooi zijn als er een "tweakers github" is met code examples
- baseline voor bv je "secrets" file (met passwords en bv fixed IP's )
- baseline/generieke yaml "start" met gewoon nuttige definities met de secrets
- complexere code die we kunnen delen onderling

(dus ook hoe post je code zonder wachtwoorden)

De documentatie van ESP home is wel duidelijk maar ik zelf loop vaak tegen issues aan met combineren van meerdere functies denk hierbij aan:
- je wilt led verlichting in 3 standen hebben + via de app en een schakelaar bedienen


kortom wellicht dat de startpost wat minder "hoe start je' (genoeg examples al op internet) maar meer gericht op hoe combineren wij nu meerdere zaken met elkaar

daarbij is misschien wel handig dat we ook 3d prints/of hoe verbind je zaken met elkaar (wire-wrap/solderen / connectoren)

Dit zijn de zaken waar ik tot op heden tegenaan gestoten ben in elk geval

[Septillion]

Grom, schijnbaar niet op versturen geklikt voor ik wat anders ging doen...

Maar ik heb links toegevoegd aan kookboeken enzo. Als je nog andere leuke weet, geeft maar door. Liever zet ik die niet in de startpost, dan wordt het een ratjetoe. Maar het staat gebruikers vrij om wat te delen.

Misschien kan wel een voorbeeld default config komen. Maar ook daar geldt dat het erg persoonlijk is wat je wilt. Maar misschien wat basic + wat uitleg wat het is zou wel kunnen. Maar wil verder ook geen echte tutorial worden, die zijn er ook genoeg.

Een stukje over secrets is wel nog handig voor onder code delen.

Nu kan er best wat over hardware en behuizingen gekletst worden maar primair ligt de focus op de software / config. Anders wordt het toch meer een ding voor in MME (los of topic 100% daar).

[AUijtdehaag]

Hee leuk een ESPhome topic!

Ik wil het toch "even" over hardware hebben zonder reclame te maken.
De produkten van m5stack en combinatie ervan bieden vaak al een kant en klare oplossing ipv eigen brouwsels van componenten. Simpel grove m5stack i2c kabeltje (verschillende lengtes verkrijgbaar) en je hebt een werkende esp + sensor(en)
Zoals esp32 (atoms3 lite) en:
- modbus via RS485
- ultrasone sensor
- CO2 (scd40/41)
- Temp en humidity (ENVIII en IV)
- enz

De layout (pins) van de grove kabel is echter wel verschillend tussen m5stack en dfrobot.
Uiteraard blijft experimenteren met een eigen breadboard ook leuk.

Terug naar de code...
Om diverse hardware configuraties te maken, kan je ook alles in losse bestanden zetten ipv in 1 yaml.
Zo kan je makkelijker combineren vanuit een basis bestand.

Voorbeeld:

YAML:

# Choose the correct type for your Brink model, so the correct max flow can be setup with a slider.
# In order to use other language or a different ESP chip, fix file names below.
# Currently supported languages are en, nl. 
# ESP32 is a mh-et-live or wemos d32 mini, esp8266 is a wemos d1 mini, esp32s3 is a lilygo ESP32S3-T7
# Be carefull not to upload the wrong code to the wrong chip. This could brick your ESP chip.

packages:
  remote_package:
    url: https://github.com/fonske/Brink-flair-modbus
    ref: main
    refresh: 0s
    files: [ esphome/type/brink-325.yaml,
             esphome/labels/.brink-labels-en.yaml, 
             esphome/.brink.base.yaml, 
             esphome/boards/board-esp32S3.yaml,
             esphome/sensors/sensor-enviii-i2c-m5stack.yaml,
             esphome/sensors/sensor-brink_hum_sensor.yaml,
             esphome/sensors/sensor-brink_co2_1_sensor.yaml
           ]
    ## options are: 
      # esphome/type/.brink-325.yaml
      # esphome/type/.brink-400.yaml
      # esphome/type/.brink-450.yaml
      # esphome/type/.brink-600.yaml
      # esphome/labels/.brink-labels-en.yaml
      # esphome/labels/.brink-labels-nl.yaml
      # esphome/.brink.base.yaml
      # esphome/boards/board-esp32.yaml
      # esphome/boards/board-esp32S3.yaml
      # esphome/boards/board-esp8266.yaml
      # esphome/boards/board-esp8266-d1-mini-pro.yaml
      # esphome/boards/board-m5stack-atom.yaml
      # esphome/boards/board-m5stack-atoms3-lite.yaml
      # esphome/sensors/sensor-scd41-i2c-dfrobot.yaml
      # esphome/sensors/sensor-scd41-i2c-m5stack.yaml
      # esphome/sensors/sensor-enviii-i2c-m5stack.yaml
      # esphome/sensors/sensor-enviv-i2c-m5stack.yaml
      # esphome/sensors/sensor-dht22.yaml
      # esphome/sensors/sensor-brink_hum_sensor.yaml
      # esphome/sensors/sensor-brink_co2_1_sensor.yaml
      # esphome/sensors/sensor-brink_co2_2_sensor.yaml
      # esphome/sensors/sensor-brink_co2_3_sensor.yaml
      # esphome/sensors/sensor-brink_co2_4_sensor.yaml

# for local developing/testing, uncomment local includes and comment out remote_package part.
#packages:
#  substitutions: !include labels/.brink-labels-nl.yaml
#  device_base1: !include .brink.base.yaml
#  device_base2: !include boards/board-m5stack-atoms3-lite.yaml
#  device_base3: !include type/brink-325.yaml
#  device_base4: !include sensors/sensor-scd41-i2c-m5stack.yaml

Via github kan je alles up-to-date houden als je code deelt met anderen zonder je druk te maken over de verschillende configuraties die mogelijk zijn.

Ik mis toch soms wel de overeenkomst tussen hoe het in home assistant in yaml gedaan wordt en het soms net wat anders is in esphome opgesteld

[vso]

dit is mijn default header (sort of), wel ingekort wegens leesbaarheid

note ik gebruik 2 wifi hotspots (dus netwerk is iets gewijzigd dan je default zou kunnen verwachten) dit is meer om "traffic" te identificeren van home automation in het algemeen, maar dat is een andere discussie

YAML:

# v4.0 attic-light-control esp32-wroom 
################
substitutions:
  ###### Board specifics
  core: dev
  arduino: recommended
  platform: ESP32
  board: nodemcu-32s # https://esphome.io/devices/nodemcu_esp32.html ESP32-DevkitC
  ###### web portal 
  web_port: "80"
  web_version: "2"
  ###### Identity
  devicename: atticlight
  friendlyname: Attic Light Controller
  upper_devicename: AtticLight
  logger_level: DEBUG # default DEBUG, options = NONE,ERROR,WARN,INFO,VERBOSE,VERY_VERBOSE
  # https://esphome.io/components/logger.html?highlight=logger
  ###### Pins (used in project) 
  pwmpin1: GPIO21 # light1 (0-10v light1)
  ###### Variables:
  DefaultLightSetting: "60"

# set some globals when system boots up 
globals:
  - id: light1setpercentpwm  
    type: float
    restore_value: no
    initial_value: "0" 
 

esphome:
  name: $devicename
  friendly_name: $friendlyname
  name_add_mac_suffix: true # this sucks 
  on_boot:
    then:
      - script.execute: boot_script
  project:
    name: "vso.pwm_attic_project"
    version: "1.1.0"
# to be researched
# psram:
#  mode: octal
#  speed: 80mhz \

esp32:
  board: $board
  framework:
    type: arduino

# Enable logging
logger:
  level: $logger_level
#  logs:
#    mqtt.component: DEBUG
#    mqtt.client: ERROR

script:
  - id: boot_script
    then:
      - logger.log:
          format: "Boot_script started"
          level: INFO
      - logger.log:
          format: "Waiting for API connection"
          level: INFO
      - wait_until:
          condition:
            api.connected:
      - logger.log:
          format: "API is connected"
          level: INFO


# Enable Home Assistant API
api:
  #port: 6053 # set port defaults to 6053
  encryption:
    key: !secret api_ecryption_key 
  reboot_timeout: 0s # default 15min
  on_client_disconnected:
    - logger.log: "API client disconnected!"

time:
  - platform: homeassistant
    id: homeassistant_time

ota:
  password: !secret ota_password
  # send log updates
  on_state_change:
    then:
      - if:
          condition:
            lambda: return state == ota::OTA_STARTED;
          then:
            - logger.log: "OTA start"
      - if:
          condition:
            lambda: return state == ota::OTA_IN_PROGRESS;
          then:
            - logger.log: "OTA_IN_PROGRESS"
      - if:
          condition:
            lambda: return state == ota::OTA_COMPLETED;
          then:
            - logger.log: "OTA_COMPLETED"
      - if:
          condition:
            lambda: return state == ota::OTA_ERROR;
          then:
            - logger.log: "OTA_ERROR"                 
  on_error:
    then:
      - logger.log:
          format: "OTA update error %d"
          args: ["x"]
          
network: 
    enable_ipv6: False

wifi:
 # use_address: !secret IP_adrress116 
  networks:
  - ssid: !secret wifi_ssid
    password: !secret wifi_password
  - ssid: !secret wifi_ssid2
    password: !secret wifi_password2
  manual_ip:
    static_ip: !secret IP_address116
    gateway: !secret IP_gateway
    subnet: !secret IP_subnet
    dns1: !secret IP_dns1
# Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: $devicename " Hotspot"
    password: !secret wifi_AP_key

captive_portal:
  
web_server:
  port: $web_port
  version: 2
  local: True

text_sensor:
  - platform: wifi_info
    ip_address:
      name: ${devicename} IP Address
    ssid:
      name: ${devicename} Connected SSID
    bssid:
      name: ${devicename} Connected BSSID
    mac_address:
      name: ${devicename} Mac Wifi Address
    # scan_results:
    #  name: ${devicename} Latest Scan Results

dit is meer een quality of life/code dingetje


mijn secrets (zonder geheimen) ik heb een 2de lan waar geen DHCP op draait, zo eten mijn ESPHome projectjes geen kostbare wifi ip-adressen op (poormans solution)

YAML:

# Your Wi-Fi SSID and password
wifi_ssid: "<someSSID1>"
wifi_password: "<someSSID1password>"
wifi_ssid2: "<someSSID2>"
wifi_password2: "someSSID2password"
ota_password: "<otapassword>"
api_ecryption_key: "<api-encryption_key>"
wifi_AP_key: "<APpassword>" # als router wifi wegvalt

IP_gateway: 10.168.131.254 # ander (v)lan 
IP_subnet: 255.255.255.0
IP_dns1: 10.168.131.254
IP_adrress120: 10.168.132.120 #
IP_adrress119: 10.168.132.119 # cam-streamer

[Septillion]

@vso Voor mij is dat dus al een te specifieke, zeker nu ik ook LiobreTiny devices heb.

En je modem kan geen tweede DHCP aan?

En zie volgens mij ook veel logger dingen die toch normaal al via de logger komen of niet?

YAML:

name: ${devicename} IP Address

Dit moet je alleen niet meer doen, daar krijg je sinds een tijd dubbel de device name in je entiteit. Bij je entiteiten alleen nog maar een toevoeging plaatsen of none als je geen toevoeging wilt (en dus alleen device name wilt gebruiken).

[vso]

Septillion schreef op vrijdag 16 februari 2024 @ 11:57:
@vso Voor mij is dat dus al een te specifieke, zeker nu ik ook LiobreTiny devices heb.

voordat ik reageer wellicht iets uitgebreider je standpunt of focus toelichten is wel handig,

En je modem kan geen tweede DHCP aan?

fritzbox ? niet dat ik weet .. en permanente leases zijn ook niet echt een optie. dit werkt dus ..

En zie volgens mij ook veel logger dingen die toch normaal al via de logger komen of niet?

YAML:

name: ${devicename} IP Address

Dit moet je alleen niet meer doen, daar krijg je sinds een tijd dubbel de device name in je entiteit. Bij je entiteiten alleen nog maar een toevoeging plaatsen of none als je geen toevoeging wilt (en dus alleen device name wilt gebruiken).

Dit is specifiek voor de webportal .. in de cel zie je <naam> ip adres met de volgende cel het IP

[Septillion]

vso schreef op vrijdag 16 februari 2024 @ 12:28:
[...]

voordat ik reageer wellicht iets uitgebreider je standpunt of focus toelichten is wel handig,

Bedoelde meer dus om aan te geven hoe persoonlijk een default config dus is.

Dit is specifiek voor de webportal .. in de cel zie je <naam> ip adres met de volgende cel het IP

Maar dat mag dus niet meer voor HA. Dan krijg je in HA nu "[naam] [naam] IP adres" omdat HA zelf al het device name pre-fixt aan een entity.

[edit]
Of mja, HA doet het met het echte device name (aka friendly name). Dus je voorbeeld zal dan als entiteit in HA krijgen "Attic Light Controller atticlight IP Address" en vanaf daar entity id sensor.attic_light_controller_atticlight_ip_address.

[ Voor 19% gewijzigd door Septillion op 16-02-2024 12:34 ]

[vso]

Septillion schreef op vrijdag 16 februari 2024 @ 12:32:
[...]

Bedoelde meer dus om aan te geven hoe persoonlijk een default config dus is.


[...]

Maar dat mag dus niet meer voor HA. Dan krijg je in HA nu "[naam] [naam] IP adres" omdat HA zelf al het device name pre-fixt aan een entity.

check & check

niet voor de webportal (dit specifieke ding), maar het is geen discussie om het dubbel(op) te vinden daar ben ik het dan ook direct mee eens.

ik gebruik deze "header" voor al mijn esphome projecten, dat maakt de code die eronder staat ook direct makkelijk(er) te lezen/debuggen

[Septillion]

@vso Het klopt dat in de webinterface er geen device naam voor komt dan. Sterker nog, in de device view van HA dan ook niet. Maar overal anders (incl entity id) plakt HA er dus zelf het (friendly) device name voor.

[JER00N]

Leuk, bij mijzelf hangt er al twee jaar een ESP32 met ESPhome in de meterkast om mijn gasverbruik te monitoren. Dit doe ik met een magneetveldsensor die het magneetje in het telwerk van de gasmeter detecteert. Dit werkt helemeaal top in combinatie in Home Assistant. Ik had twee jaar geleden wel problemen om de software erop te krijgen geloof ik, zowel OTA als via USB, dit lijkt nu wel beter te gaan.

Ik heb inmiddels ook een PCB ontworpen waar de ESP (in dit geval een Wemos S3 mini) op kan, samen met een netvoedinkje en wat status-LEDs en een hoop aansluitmogelijkheden. Er kan ook een LCDtje op gemonteerd worden, of een opsteekprintje voor bijvoorbeeld een relais.



(printje is momenteel nog in productie)

[CodeCaster]

Ik gebruik ESPHome met name om Tuya-stekkers te flashen, met als meest recente slachtoffer de Denver SHP-102 die voor € 6,99 te koop waren.

Ik bak één firmware die ik voor alle stekkers wil gebruiken; ik heb geen zin om er een config per stekker op na te houden, noch om het beoogde gebruik of de locatie te hardcoden.

Vraag: hoe voorkom ik, met één firmware die op meerdere stekkers geflasht wordt, dat ik numerieke suffixes op m'n sensors krijg?

Het is wel mogelijk om de laatste zes tekens van het mac-adres in de naam van het device te krijgen. Kan dit ook voor sensors, op een of andere manier?

[Septillion]

@CodeCaster Als je (onderdeel van) het mac adres toevoegt aan de friendly name vertaald zich dat ook naar de entities.

Maar als je echt dezelfde firmware voor elke stekker gebruikt kan je ze ook niet updaten en monitoren vanuit het Dashboard. Is het niet makkelijker om 99% gewoon in een package te gooien? Dat wil ik hier in ieder geval doen voor een set pluggen. En dan alleen naam en kalibratie zaken per device en dan include van device package.

[CodeCaster]

Septillion schreef op zaterdag 17 februari 2024 @ 12:58:
@CodeCaster Als je (onderdeel van) het mac adres toevoegt aan de friendly name vertaald zich dat ook naar de entities.

Maar als je echt dezelfde firmware voor elke stekker gebruikt kan je ze ook niet updaten en monitoren vanuit het Dashboard. Is het niet makkelijker om 99% gewoon in een package te gooien? Dat wil ik hier in ieder geval doen voor een set pluggen. En dan alleen naam en kalibratie zaken per device en dan include van device package.

Ik heb Home Assistant in Docker op een machine zonder WiFi. ESPHome draai ik in Docker op een NUC, naast LibreTiny tuya-cloudcutter voor flashen. Ik heb dus niet het ESPHome-dashboard in Home Assistant.

Ik heb getwijfeld over België packages, includes en andere manieren van configs delen, maar ik heb geen zin om voor acht stekkers acht verschillende firmwares te bakken, dat doet pijn aan mijn softwareontwikkelaarshart.

Ik heb firmware gebouwd met (grof geknipt) deze config:

YAML:

substitutions:
  device_name: slimmestekker-denver

esphome:
  name: ${device_name}
  name_add_mac_suffix: true

bk72xx:
  board: generic-bk7231t-qfn32-tuya

sensor:
  - platform: hlw8012
    model: BL0937
    cf_pin:
      number: P7
      inverted: true
    cf1_pin:
      number: P8
      inverted: true
    sel_pin:
      number: P24
      inverted: true
    current:
      name: BL0937 Current

En ja, eigenlijk moet ik de BL0937 tunen per stekker voor de precisie, en als je het goed doet, bouw je maar één keer een firmware per stekker, maar ik wil redundantie voorkomen.

Deze firmware op meerdere stekkers zorgt in HASS dus voor de volgende devices en sensors:

• slimmestekker-denver-a54321
  • sensor.bl0937_current_4
  • sensor.bl0937_voltage_4
  • sensor.bl0937_power_4
• slimmestekker-denver-f12345
  • sensor.bl0937_current_5
  • sensor.bl0937_voltage_5
  • sensor.bl0937_power_5
• slimmestekker-denver-abcabc
  • sensor.bl0937_current_6
  • sensor.bl0937_voltage_6
  • sensor.bl0937_power_6

Omdat dit BL0937-gebruikers nummer 4, 5 respectievelijk 6 waren.

Wat ik zou willen, is dat de naam van het device wordt verwerkt in die van de sensor, om dubbelingen (en dus door HASS gegenereerde, numerieke suffixen) te voorkomen.

Bijvoorbeeld:

code:

slimmestekker-denver-a54321
 * sensor.denver_a54321_current
 * sensor.denver_a54321_voltage
 * sensor.denver_a54321_power

Zonder dat ik dit per device in de YAML moet aangeven.

[ Voor 7% gewijzigd door CodeCaster op 17-02-2024 13:43 ]

[Septillion]

@CodeCaster Je weet dat LibreTiny nu in ESPhome zelf zit en je het dus niet meer beide hoeft te draaien?

Maar ook als je het stand alone draait kan je het dashboard tonen toch? Alleen dan los en niet in HA.

Maar ja, dat je wat basic dingen niet on the fly in kunt stellen op ESPhome blijft voor mij ook wel een nadeel vs bijvoorbeeld Tasmota.

In je config geef je geen friendly name op, die wordt door HA gebruikt om ze uniek te maken. Maar weet niet of je die makkelijk uniek kunt maken met enkele firmware...

Dus denk dat het beste is dat je die wel instelt naar iets generieks. En dan steeds voor je het volgende device koppelt aan HA de friendly name van het device aanpast naar wat je wilt en dan aangeeft dat entity is'd ook geüpdatet moeten worden.

[CodeCaster]

Septillion schreef op zaterdag 17 februari 2024 @ 13:32:
@CodeCaster Je weet dat LibreTiny nu in ESPhome zelf zit en je het dus niet meer beide hoeft te draaien?

Maar ook als je het stand alone draait kan je het dashboard tonen toch? Alleen dan los en niet in HA.

Maar ja, dat je wat basic dingen niet on the fly in kunt stellen op ESPhome blijft voor mij ook wel een nadeel vs bijvoorbeeld Tasmota.

In je config geef je geen friendly name op, die wordt door HA gebruikt om ze uniek te maken. Maar weet niet of je die makkelijk uniek kunt maken met enkele firmware...

Dus denk dat het beste is dat je die wel instelt naar iets generieks. En dan steeds voor je het volgende device koppelt aan HA de friendly name van het device aanpast naar wat je wilt en dan aangeeft dat entity is'd ook geüpdatet moeten worden.

Excuus, ik bedoel tuya-cloudcutter, die draai ik op dezelfde machine als m'n ESPHome-compiler. Die machine staat meestal uit, dus heeft ook geen nut om daar een dashboard in te hangen

Het zou fijn zijn als ze in ESPHome meer "global substitutions" zouden hebben, al was het maar "$mac_suffix" zodat je die in andere namen en omschrijvingen kunt gebruiken.

Ik hernoem de sensors nu in HA maar na het toevoegen van een stekker, maar ideaal is anders. Ook omdat het renamen van een sensor nog steeds dingen lijkt te slopen die daaraan gekoppeld waren, met name Riemann sums...

[Septillion]

@CodeCaster Ah, CloudCutter is logischer

Maar je moet de rename ook wel gelijk doen na het toevoegen. Niet eerst er automations en helpers mee maken. Want ja, als je voor entity id rename kiest dan gaat het dan stuk ja.

En ik snap je wens, maar andere kant, devices gewoon een logische naam geven lijkt mij nog steeds veel gebruikersvriendelijk dan uniek gegenereerde namen hebben. Dus dat is denk ik ook de gedachten van ESPhome voor gekochte devices.

En qua dashboard, het maakt niet uit naar mijn idee of dat in HA is of dat het 24/7 draait of niet. Maar het geeft je gewoon een makkelijke plek om een device een update te geven als je dat wilt. Maar ja, het is dan wel recompile per device.

[CodeCaster]

Septillion schreef op zaterdag 17 februari 2024 @ 13:52:
@CodeCaster Ah, CloudCutter is logischer

Maar je moet de rename ook wel gelijk doen na het toevoegen. Niet eerst er automations en helpers mee
maken. Want ja, als je voor entity id rename kiest dan gaat het dan stuk ja.

Achteraf kijk je een koe in z'n kont.

Ik weet de volgorde nu, maar als je het allemaal aan het uitzoeken bent (leuk!) en je flasht je eerste stekker (spannend!) en hangt hem in HA (nuttig!) en gaat een Riemann maken (interessant!) en na een paar weken weet je pas wat je met die stekker gaat doen, hernoemt hem en ziet dan in het energy dashboard missende sensor, dan is dat geen leuke ervaring.

En ik snap je wens, maar andere kant, devices gewoon een logische naam geven lijkt mij nog steeds veel gebruikersvriendelijk dan uniek gegenereerde namen hebben. Dus dat is denk ik ook de gedachten van ESPhome voor gekochte devices.

Duidelijk.

En qua dashboard, het maakt niet uit naar mijn idee of dat in HA is of dat het 24/7 draait of niet. Maar het geeft je gewoon een makkelijke plek om een device een update te geven als je dat wilt. Maar ja, het is dan wel recompile per device.

Ik ga eens kijken naar het dashboard, thanks.

Van mijn wens bestaat trouwens al een feature request: GitHub: esphome / feature-requests: #1840 Option to prepend device name to all entity names at runtime

[Septillion]

@CodeCaster Zeker, maar dat heb je met elk device dat je in HA koppelt en pas na alle opwinding hernoemt naar iets nuttigs

Maar eigenlijk is de feature request niet correct. Want ESPhome geeft geen entity id's door, alleen namen. En op basis van de friendly names maakt HA entity id's aan. Ook prefixt HA een entity naam met de device name en maakt dan het entity id. Het grote probleem is dus eigenlijk dat ESPhome gescheiden "device name" en "friendly name" kent waarbij HA niets doet met het device name... Dan zou ESPhome het ook mogelijk moeten maken om mac toe te voegen aan de friendly name. Dat zou nog wel een aardige zijn.

[Septillion]

@Dwazer Pssst, zou de ESPhome vraag even hier weg halen en stellen in Het grote ESPhome topic

Done, volgorde wat raar maar goed

[ Voor 16% gewijzigd door Septillion op 20-02-2024 16:04 ]

[PeteSplit]

[ Voor 99% gewijzigd door PeteSplit op 20-02-2024 16:53 ]

[Dwazer]

PeteSplit schreef op dinsdag 20 februari 2024 @ 13:39:
[...]


Heb je bij de settings in add-ons ook ESPhome geinstalleerd in HA, dan kun je daarmee flashen en ook opnieuw de wifi secrets toevoegen.

Ja, die Add-on heb ik in HA
Maar moet in het ESP-topic gepost worden, hoorde ik net

[Dwazer]

Ander vraagje:
Along the way ben ik een ESP32 module "kwijt geraakt" omdat ik die opnieuw geflasht had.
Tot mijn grote verbazing, staat alles er nog in (Als ik de ESP32 via USB aansluit) er qua config nog in, alleen het OTA "password" is eruit (verdwenen).
Kan ik zelf een OTA aanmaken, die in de config zetten, opnieuw flashen via USB en dat het daarna weer via OTA kan? Of wordt de OTA enkel en alleen tijdens de eerste keer flashen aangemaakt en zal deze vanaf 0 opgebouwd moeten worden (met een kopie config daarna eroverheen natuurlijk ) ?

[Septillion]

@Dwazer Maar had je de config nog gewoon in je dashboard (aka, de yaml file)? Want deze staat niet in je device dus zou anders niet weten hoe je dashboard opeens je config weet...

Op zich is OTA password optional dus je zou hem in moeten kunnen stellen en dan een OTA geven

[Dwazer]

Septillion schreef op dinsdag 20 februari 2024 @ 16:07:
@Dwazer Maar had je de config nog gewoon in je dashboard (aka, de yaml file)? Want deze staat niet in je device dus zou anders niet weten hoe je dashboard opeens je config weet...

Op zich is OTA password optional dus je zou hem in moeten kunnen stellen en dan een OTA geven

In de Add-on ESPHome van HA, bleef desbetreffende ESP32 'offline' (Omdat ik issues met het wifi netwerk blééf houden).

Wel kon ik op de 'Edit' button drukken en kwam ik op de config-file uit van desbetreffende ESP module.
En dáár zag ik wel deze staan:

YAML:

esphome:
  name: esp32-proxy*
  friendly_name: ESP32*
  comment: ESP32*
  platform: ESP32
  board: esp32dev

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: *

ota:


wifi:
  manual_ip:
    static_ip: 1*
    gateway: 1*
    subnet: 2*
    dns1: 1*
  ssid: !secret *
  password: !secret *

Dus als ik em met een USB kabel aan mijn HA host hang, kan ik er prima bij en niets aan de hand.
Maar die "OTA" optie, is er toch om 'updates Over Tha Air" te regelen?
En die is bij mij "spontaan door kaboutertjes" verdwenen (* Dwazer had waarschijnlijk een borrel gehad ).

Concreet:
Stel, ik "verzin" een OTA PW, flash de ESP opnieuw, zouden de OTA's het ook weer moeten doen?

[TheFes]

Dwazer schreef op dinsdag 20 februari 2024 @ 16:56:
[...]

In de Add-on ESPHome van HA, bleef desbetreffende ESP32 'offline' (Omdat ik issues met het wifi netwerk blééf houden).

Wel kon ik op de 'Edit' button drukken en kwam ik op de config-file uit van desbetreffende ESP module.
En dáár zag ik wel deze staan:

YAML:

esphome:
  name: esp32-proxy*
  friendly_name: ESP32*
  comment: ESP32*
  platform: ESP32
  board: esp32dev

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: *

ota:


wifi:
  manual_ip:
    static_ip: 1*
    gateway: 1*
    subnet: 2*
    dns1: 1*
  ssid: !secret *
  password: !secret *

Dus als ik em met een USB kabel aan mijn HA host hang, kan ik er prima bij en niets aan de hand.
Maar die "OTA" optie, is er toch om 'updates Over Tha Air" te regelen?
En die is bij mij "spontaan door kaboutertjes" verdwenen (* Dwazer had waarschijnlijk een borrel gehad ).

Concreet:
Stel, ik "verzin" een OTA PW, flash de ESP opnieuw, zouden de OTA's het ook weer moeten doen?

Die edit knop geeft je gewoon de lokale file, dat hoeft niet per se de file op het device te zijn.

Als je hem via USB aansluit, kun je die config wel naar je device sturen

[Dwazer]

TheFes schreef op dinsdag 20 februari 2024 @ 17:22:
[...]


Die edit knop geeft je gewoon de lokale file, dat hoeft niet per se de file op het device te zijn.

Als je hem via USB aansluit, kun je die config wel naar je device sturen

Dus als ik een 'my-self-generated' OTA PW maak, opnieuw flash, dan is dat correct?
Want ik weet niet hoe deze normaliter opgebouwd zijn (misschien middels MAC address, diverse componenten, knip, plak = OTA PW).

Wellicht opnieuw de handshake doen in HA, maar die heb ik nog wel

[BThomas]

Ik heb een sensor samengesteld middels een esp8266, DHT22, pmsx003 en MH-Z19 en in een mooi case gestopt met gaten tbv toevoer en afvoer. Alles mooi aangesloten en werkend, maar de temperatuur waardes slaan nergens op. Ik krijg waardes in de woonkamer van 30 graden bij de MH-Z19 en -8,4 van de DHT22.

Wat gaat er fout?

YAML:

 esphome:
  name: luchtkwaliteit
  friendly_name: Luchtkwaliteit

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "#####"

ota:
  password: "####"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Luchtkwaliteit Fallback Hotspot"
    password: "#####"

captive_portal:

uart:
  - tx_pin: GPIO12
    rx_pin: GPIO13
    baud_rate: 9600
    id: pmsuart
  - rx_pin: GPIO5
    tx_pin: GPIO4
    baud_rate: 9600
    id: mhz19uart


sensor:
  - platform: pmsx003
    type: PMSX003
    uart_id: pmsuart
    pm_1_0:
      name: "Particulate Matter <1.0µm Concentration"
    pm_2_5:
      name: "Particulate Matter <2.5µm Concentration"
    pm_10_0:
      name: "Particulate Matter <10.0µm Concentration"
    update_interval: 120s
  - platform: dht
    pin: GPIO2
    temperature:
      name: "Air quality meter Temperature"
    humidity:
      name: "Air quality meter Humidity"
    update_interval: 20s
  - platform: mhz19
    uart_id: mhz19uart
    co2:
      name: "esp32s2 MH-Z19 CO2 Value"
    temperature:
      name: "esp32s2 MH-Z19 Temperature"
    update_interval: 20s
    automatic_baseline_calibration: true



switch:
  - platform: gpio
    pin: 
      number: GPIO0 
    id: pms_set
    name: "Start measuring"
  
interval:
  - interval: 120s
    then:
      - switch.turn_on: pms_set
      - delay: 20s
      - switch.turn_off: pms_set

[vso]

BThomas schreef op dinsdag 20 februari 2024 @ 22:03:
Ik heb een sensor samengesteld middels een esp8266, DHT22, pmsx003 en MH-Z19 en in een mooi case gestopt met gaten tbv toevoer en afvoer. Alles mooi aangesloten en werkend, maar de temperatuur waardes slaan nergens op. Ik krijg waardes in de woonkamer van 30 graden bij de MH-Z19 en -8,4 van de DHT22.

Wat gaat er fout?

YAML:

 esphome:
  name: luchtkwaliteit
  friendly_name: Luchtkwaliteit

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "#####"

ota:
  password: "####"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Luchtkwaliteit Fallback Hotspot"
    password: "#####"

captive_portal:

uart:
  - tx_pin: GPIO12
    rx_pin: GPIO13
    baud_rate: 9600
    id: pmsuart
  - rx_pin: GPIO5
    tx_pin: GPIO4
    baud_rate: 9600
    id: mhz19uart


sensor:
  - platform: pmsx003
    type: PMSX003
    uart_id: pmsuart
    pm_1_0:
      name: "Particulate Matter <1.0µm Concentration"
    pm_2_5:
      name: "Particulate Matter <2.5µm Concentration"
    pm_10_0:
      name: "Particulate Matter <10.0µm Concentration"
    update_interval: 120s
  - platform: dht
    pin: GPIO2
    temperature:
      name: "Air quality meter Temperature"
    humidity:
      name: "Air quality meter Humidity"
    update_interval: 20s
  - platform: mhz19
    uart_id: mhz19uart
    co2:
      name: "esp32s2 MH-Z19 CO2 Value"
    temperature:
      name: "esp32s2 MH-Z19 Temperature"
    update_interval: 20s
    automatic_baseline_calibration: true



switch:
  - platform: gpio
    pin: 
      number: GPIO0 
    id: pms_set
    name: "Start measuring"
  
interval:
  - interval: 120s
    then:
      - switch.turn_on: pms_set
      - delay: 20s
      - switch.turn_off: pms_set

Zou kijken naar calibratie (als het mogelijk is) en bv wellicht een te lage voeding oid (capicitor/weerstand die er tussen moet ?)

[heintjeput]

BThomas schreef op dinsdag 20 februari 2024 @ 22:03:
Ik heb een sensor samengesteld middels een esp8266, DHT22, pmsx003 en MH-Z19 en in een mooi case gestopt met gaten tbv toevoer en afvoer. Alles mooi aangesloten en werkend, maar de temperatuur waardes slaan nergens op. Ik krijg waardes in de woonkamer van 30 graden bij de MH-Z19 en -8,4 van de DHT22.

Wat gaat er fout?

Zoals eigenlijk altijd meet een temperatuursensor niet de luchttemperatuur maar zijn eigen temperatuur. In de ideale wereld is dit hetzelfde, maar als het component zelf of iets in de buurt energie verbruikt en zichzelf opwarmt kan dit snel anders zijn, een probleem wat selfheating genoemd wordt. Voor de MH-Z19 is dit waarschijnlijk zo, die verbruikt best een beetje energie en wss zit de tempsensor ergens in het doosje en meet dus daar. Ik meet ook 10 degC verschil tussen de MH-Z19 en een BME690 die er naast zit.
Voor de DHT22, mijn gok zou zijn dat hij stuk is. De DHTxx sensoren die ik heb gehad waren altijd klote, kapot, de luchtvochtigheid klopt nooit etc.
Met beide sensoren is het wel zo, ze geven een waarde of niet. Als je geen waarde krijgt kun moet je kijken waar het aan ligt. Als je wel een waarde krijgt dan is dat het vaak. Nou kun je bij de het selfheating probleem er nog wel wat aan doen, dat is namelijk het (gemiddelde) verbruik verlagen. Voor een andere sensor die ik heb, heb ik de ESP zo ingesteld dat hij 55 van de 60 seconde slaapt en dus alle componenten 90% van de tijd uit staan. Of dit met de MH-Z19 icm ESPhome ook kan weet ik zo niet.

[Septillion]

@BThomas Zowel de DTH22 als de MH-Z19 staan volgens mij niet erg bekend om heel nauwkeurig te zijn qua temperatuur. Misschien de DTH22 vervangen door een BME680 ofzo?

[Batino]

BThomas schreef op dinsdag 20 februari 2024 @ 22:03:
Ik heb een sensor samengesteld middels een esp8266, DHT22, pmsx003 en MH-Z19 en in een mooi case gestopt met gaten tbv toevoer en afvoer. Alles mooi aangesloten en werkend, maar de temperatuur waardes slaan nergens op. Ik krijg waardes in de woonkamer van 30 graden bij de MH-Z19 en -8,4 van de DHT22.

Wat gaat er fout?

Ter aanvulling/bevestiging, de DHT22 wordt inderdaad veel gebruikt omdat deze zo goedkoop is, maar helaas geeft deze vaak slechte waarde geeft. Je kunt deze nog een offset geven (schaalt namelijk zo goed als lineair) met onderstaande yaml, maar het blijft matig. De MHZ-19 sensor heeft een grove temperatuur nodig voor zijn eigen calibratie, maar is dus ook niet nauwkeurig. De BME680 is inderdaad een goede suggestie!

YAML:

sensor:
  # DHT Sensor Configurations
  - platform: dht
     temperature:
      name: "DHT Temperature"
      filters:
        - lambda: return x +15.0;
     humidity:
          ... etc.

[ Voor 0% gewijzigd door Septillion op 21-02-2024 08:56 ]

[stevenP]

Ik heb 2 18B20 tempsensoren op aanvoer/retour zitten. Ook wil ik de delta direct als variabele meenemen.

YAML:

# Delta T
  - platform: template
    name: "Td"
    id: delta_t
    update_interval: 20s
    unit_of_measurement: "°C"
    lambda: |-
      return (id(tin).state - id(tout).state);
    accuracy_decimals: 1

Werkt goed! Ik merk alleen dat als de WP uitstaat er vaak een waarde van "-0.0" uitrolt. Vind ik niet heel sexy. Ik heb ChatGTP gevraagd me hierbij te helpen, maar is dit nu inderdaad de correcte syntax/manier?

YAML:

  lambda: |-
    float delta = id(tin).state - id(tout).state;
    if (delta <= 0.1) {  // Adjust the threshold as needed
      return 0.0;
    } else {
      return delta;
    }

[ Voor 24% gewijzigd door stevenP op 26-02-2024 10:02 ]

[Septillion]

@stevenP Op zich zou dat moeten werken maar ik zou wat kleinere threshold (kleiner dan je decimalen) nemen en twee kanten op

YAML:

  lambda: |-
    float delta = id(tin).state - id(tout).state;
    if (abs(delta) <= 0.001) {  // Adjust the threshold as needed
      return 0.0;
    } else {
      return delta;
    }

Op zich wel raar dat C hier schijnbaar geen standaard implementatie voor heeft.

[ThinkPad]

AUijtdehaag schreef op zondag 4 juni 2023 @ 22:14:
[...]

Na een dagje puzzelen is het dit (grofweg) geworden om te uploaden naar pvpoutput via esphome
Code kan vast beter, maar als het werkt...
Morgen eens kijken of het weer wakker wordt van 10 watt.

[...]

Heb je dit nog steeds naar tevredenheid draaien? Ik heb het nu draaien via Tasmota ThinkPad in "Datalogging: PV systemen" en dat werkt prima, maar ESPHome heb ik ook al e.e.a. in draaien en is wel makkelijker centraal te beheren natuurlijk.... Met mijn Tasmota setup maak ik gebruik van componenten die niet allen tegelijkertijd aanwezig zijn in de standaardbuilds, dus ik moet zelf telkens een nieuwe firmware compileren als ze een update uitbrengen. Met ESPHome is dat één druk op de knop...

[ Voor 17% gewijzigd door ThinkPad op 27-02-2024 22:03 ]

[vso]

ik zit met een uitdaging

situatie:
- lamp A + B (warm wit + dimbaar met 0-10v) met relais(s)
- ledstring C+D (RGBWW) met relais(s) Virtueel 2=1 lamp E
- touchsensor
- HA (remote control)


doel
Als ik de touchsensor aanraak, dan moet de lampen A + B aangaan op 60% elke volgende touch +10% behalve 0% (uit) tot 50% en dan 10seconden geen reactie geven (ofzo) + als lamp C,D, aanstaan moeten ze uitgezet worden.

via HA wil ik elke lamp apart kunnen bedienen en eventueel lichteffecten met de ledstring, liefst in HA een "Sfeer" setting maar dat is nog even ver van mijn bed show

de code (te veel voor hier) voordat je klikt --> het is 1 van de itteraties die ik geprobeert heb

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[CodeCaster]

Ik heb vandaag weer eens geoefend met solderen. Ik kan het nog steeds niet.

M'n Qnect QN-WP04 (onder andere te koop bij Gamma en Karwei) stekker (10A max, geen metingen) was niet OTA te flashen, dus ik heb 'm opengewurmd en wilde de firmware uitlezen en overschrijven.

Aansluiten terwijl het WB2S-bord op het hoofdbord zat, lukte niet dus ik heb het hele dochterbord gedesoldeerd. Daarna gebackupt, geflasht, getest en geprobeerd terug te solderen.

Het goede nieuws is dat er geen rook uit de stekker kwam en dat het bordje opstart: de ESPHome-kickstart draait. Het slechte nieuws is dat nog niet alle banen even goed contact maken; ik denk dat ik een paar spoortjes heb weggesmolten.

Dit resulteert in een relais dat 0,5-30 seconden open blijft en daarna weer dichtklapt, al dan niet gevolgd door een crash van de firmware.

Bottomline: de door mij uitgelezen firmware is wel opgenomen in tuya-cloudcutter, dus de volgende stekker van dit type kan OTA geflasht worden.

[pistole]

vso schreef op dinsdag 27 februari 2024 @ 23:10:
ik zit met een uitdaging

situatie:
- lamp A + B (warm wit + dimbaar met 0-10v) met relais(s)
- ledstring C+D (RGBWW) met relais(s) Virtueel 2=1 lamp E
- touchsensor
- HA (remote control)


doel
Als ik de touchsensor aanraak, dan moet de lampen A + B aangaan op 60% elke volgende touch +10% behalve 0% (uit) tot 50% en dan 10seconden geen reactie geven (ofzo) + als lamp C,D, aanstaan moeten ze uitgezet worden.

via HA wil ik elke lamp apart kunnen bedienen en eventueel lichteffecten met de ledstring, liefst in HA een "Sfeer" setting maar dat is nog even ver van mijn bed show

de code (te veel voor hier) voordat je klikt --> het is 1 van de itteraties die ik geprobeert heb

***members only***

Kan dit niet 'gewoon' met een automation of script in HA?

[Septillion]

@vso Ik moest wel de config bekijken om te zien wat je nu werkelijk had, En ook daar heb je aardig je best gedaan om verwarrende namen te gebruiken naar mijn idee Je hebt geen 0-10V sturing en voor de strips zijn het datapinnen... En wat is met all die globals, sensors etc? Waarom niet gewoon een light? Volgens mij kan echt 50%+ er gewoon uit...

Volgens mij wil je in de basis gewoon:
- 2x een light (noemen we even A en B ) via monochrome platform (met PWM output + relay/PSU pin)
- 2x een light (noemen we even C en D) via neopixelbus platform
- 1x een (virtual) light (noemen we even E) via partition platform (werkelijk een combie van de twee hierboven)
- 1x digital input (touch regel je via externe hardware? Je gebruikt in ieder geval niet build in touch support)
- HA via API

Alleen dan nu, wat wil je?

Als ik de touchsensor aanraak, dan moet de lampen A + B aangaan op 60%

Neem aan aanraak indien (beide?) uit?

A en B zijn gewoon altijd gekoppeld? Of hoe moet er omgegaan worden als ze ook los instelbaar zijn?

elke volgende touch +10% behalve 0% (uit)

Dus full cycle ofwel bij touch op 100% weer naar 10%.

tot 50% en dan 10seconden geen reactie geven (ofzo)

Dus je wilt dat als A en B op 50% ingesteld wordt dat de input voor 10 seconden niet meer reageert?

+ als lamp C,D, aanstaan moeten ze uitgezet worden.

En als A en B 50% worden dan C en D uit. Of moeten ze beide aan staan voor ze uit mogen?

[vso]

Septillion schreef op woensdag 28 februari 2024 @ 12:47:
@vso Ik moest wel de config bekijken om te zien wat je nu werkelijk had, En ook daar heb je aardig je best gedaan om verwarrende namen te gebruiken naar mijn idee Je hebt geen 0-10V sturing en voor de strips zijn het datapinnen... En wat is met all die globals, sensors etc? Waarom niet gewoon een light? Volgens mij kan echt 50%+ er gewoon uit...

het is een paar maanden geleden, en ik heb wat iterates in de history staan van github (zal het helaas niet veel duidelijker maken voor je)

sommige zaken zijn meer om het script op andere esp's simpel toe te kunnen passen .. en de pinout(s) te wijzigen, moet het wel inderdaad wat netter maken.

de pwmpin(en) in het script werken voor zowel 0-10v als voor de ledstrip(s) ik heb extern een pwm --> 0-10 converter (jij wees me er 2 maanden geleden op dat ik een direct tegenover gesteld dingus had .. kwa HW) dus 0-10v --> pwm .. dus ik heb nu de juiste HW in huis

De uitdaging zit hem meer in de code die voor onderstaande tekst / antwoord verantwoordelijk moet zijn.

Volgens mij wil je in de basis gewoon:
- 2x een light (noemen we even A en B ) via monochrome platform (met PWM output + relay/PSU pin)
- 2x een light (noemen we even C en D) via neopixelbus platform
- 1x een (virtual) light (noemen we even E) via partition platform (werkelijk een combie van de twee hierboven)
- 1x digital input (touch regel je via externe hardware? Je gebruikt in ieder geval niet build in touch support)
- HA via API

klopt, ik gebruik een externe "touch" sensor maar elke knop doet het dat betreft wel

Elke lamp "apart" via HA in te stellen (99% doelend op C,D en E ) dus niet echt bijster spannend.

de 0-10v is 10 stappen

Alleen dan nu, wat wil je?
[...]
Neem aan aanraak indien (beide?) uit?
A en B zijn gewoon altijd gekoppeld? Of hoe moet er omgegaan worden als ze ook los instelbaar zijn?
[...]
Dus full cycle ofwel bij touch op 100% weer naar 10%.
[...]
Dus je wilt dat als A en B op 50% ingesteld wordt dat de input voor 10 seconden niet meer reageert?
[...]
En als A en B 50% worden dan C en D uit. Of moeten ze beide aan staan voor ze uit mogen?

ik probeer het "kort" op te schrijven

als je de kamer in loopt, wil je de lamp (A+B) natuurlijk aanzetten, (korte "klik")
voorwaarde 2 = als lamp C of D aanstaat --> uitzetten C + D
voorwaarde 1 = niet 100% maar 60% (default)

lange klik = uit

schort push (2de optie)
voorwaarde = als A+B aanstaan
+ 10 %
dus 60% word 70% -->80% -->90% --> 100% --> 10% -->20% -->30% -->50% --> (start cyclus opnieuw?? of 10sec inactief)

[Opifex]

Leuk dat er een ESPHome topic bestaat! Ik heb het recentelijk ook ontdekt en wil het gebruiken in combinatie met Home Assistant (zoals de meeste vermoed ik?).

Het eerste wat ik aan het proberen ben is een R503 vingerafdruk scanner uitlezen, in de hoop deze te gebruiken als bediening voor onze garagepoort. Het huidige keypad is namelijk al een tijdje defect.
De ledring laten oplichten bij verschillende events was vrij eenvoudig. Ook events van- en naar HA sturen lukt. Maar het vreemde is dat hij bij elke gescannede vinger (zelfs wanneer niet enrolled) het event "match found" triggert, maar dan met een confidence van 0? Dat houdt toch geen steek? Waarvoor dient het "no match found" event dan?

Ben er nog wat mee aan het spelen. Vanavond een prototype bordje solderen, want ik heb ook de indruk dat er ergens nog een slecht contact in de draden spaghetti zit, wat er voor zorgt dat hij soms in z'n geheel niets meer doet.

[Septillion]

@vso Ik heb even een versie gemaakt waarbij ik veel weggesloopt heb zodat ik wat overzicht had en een compile kon doen. Ik heb niet de hardware dus verder niet echt getest. Maar ik zou het een beetje doen als dit.

Waarbij enkele tap:
- Indien A en B uit zijn, ze aan gaan op 60%
- Anders, indien de lamp aan, deze 10% omhoog gaat of naar 10% indien op 100% stond

Verder geen link tussen de twee lampen. Dus als A op 30% staat en B op 100% dan zal een tap resulteren in 40% en 10%.

Moest voor de huidige brightness ook wel even zoeken zeg. Maar niet getest maar dit zou de brightness op moeten leveren van 0.0 tot 1.0. En om geen stomme float vergelijkingen te doen maar even naar 0-100 als int. Waarbij ik nog wel een relative dimstap doe indien bijvoorbeeld nu op 95% staat. Ik neem aan dat ESPhome daar dan al 100% van maakt. Maar andere tientallen geen afronding.

Helaas is if / else-if in ESPhome een beetje stom geïmplementeerd waardoor dat steeds een niveau meer indenteert

[Septillion]

@Opifex Geen ervaring met de sensor maar code delen is altijd handig. En anders misschien alleen event sturen bij confidence >50%?

[vso]

Septillion schreef op woensdag 28 februari 2024 @ 18:59:
@vso Ik heb even een versie gemaakt waarbij ik veel weggesloopt heb zodat ik wat overzicht had en een compile kon doen. Ik heb niet de hardware dus verder niet echt getest. Maar ik zou het een beetje doen als dit.

Waarbij enkele tap:
- Indien A en B uit zijn, ze aan gaan op 60%
- Anders, indien de lamp aan, deze 10% omhoog gaat of naar 10% indien op 100% stond

Verder geen link tussen de twee lampen. Dus als A op 30% staat en B op 100% dan zal een tap resulteren in 40% en 10%.

Moest voor de huidige brightness ook wel even zoeken zeg. Maar niet getest maar dit zou de brightness op moeten leveren van 0.0 tot 1.0. En om geen stomme float vergelijkingen te doen maar even naar 0-100 als int. Waarbij ik nog wel een relative dimstap doe indien bijvoorbeeld nu op 95% staat. Ik neem aan dat ESPhome daar dan al 100% van maakt. Maar andere tientallen geen afronding.

Helaas is if / else-if in ESPhome een beetje stom geïmplementeerd waardoor dat steeds een niveau meer indenteert

Dank! ik zie wat je gedaan hebt dat is inderdaad wat handiger / duidelijker
Het is een andere manier van code(n) wat dit topic voor mij waardevol maakt!!

Betreft de verschil in brightness (en wellicht de oorzaak van de warrige code) is dat ik een 3de variable ervoor toegevoegd had.

Het idee is dat ik bv meerdere "afstandsbedieningen" heb voor de verlichting virtueel of fysiek maar eind resultaat blijft het zelfde .. zodra je die 1ne "touchsensor" aanraakt is het aan en/of +10% en longpress = uit
heb je nu tussentijds de brightness verandert of een ledstrip(s) geactiveerd worden de ledstrips uitgeknald en naar de "huidige waarde" gezet. voordat je de cyclus induikt ..

Anyway je hebt me ander inzicht gegeven dus ik ga er tzt weer eens mee verder spelen, zat een beetje vast en ja die indents maken het niet makkelijker.

ik vind het code(n) voor esphome niet echt de meest ideale taal

[vso]

over esphome en code

wat wel jammer is dat esphome niks met SD kaartjes kan doen (file transfer bv)

o schiet me net te binnen ik had wel een methode gevonden trouwens om via visual studio + https://wokwi.com/ een esp32 met ESPhome te simuleren (2 maanden terug) hier ergens op GOT ook een howto gepost ..

Fijne ervan is dat je ook dan je HW tot op zekere hoogte kan emuleren die je op een esp32 aan wilt sluiten. (was wel erg basic) zal tzt de status eens bekijken van wokwi

[Opifex]

Septillion schreef op woensdag 28 februari 2024 @ 19:01:
@Opifex Geen ervaring met de sensor maar code delen is altijd handig. En anders misschien alleen event sturen bij confidence >50%?

Ik zou inderdaad dat event kunnen filteren op confidence >50%. Maar... dan zouden er nog steeds geen unmatched events komen, want dat is een heel andere trigger. Hier een snippet van mijn code:

YAML:

fingerprint_grow:
  sensing_pin: GPIO0
  on_finger_scan_start:
    - fingerprint_grow.aura_led_control:
        state: GRADUAL_OFF
        color: RED
        speed: 100
        count: 2
  on_finger_scan_invalid:
    - homeassistant.event:
        event: esphome.test_node_finger_scan_invalid
  on_finger_scan_matched:
    - fingerprint_grow.aura_led_control:
        state: BREATHING
        speed: 200
        color: GREEN
        count: 1
    - homeassistant.event:
        event: esphome.test_node_finger_scan_matched
        data:
          finger_id: !lambda 'return finger_id;'
          confidence: !lambda 'return confidence;'
  on_finger_scan_unmatched:
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: RED
        count: 2
    - homeassistant.event:
        event: esphome.test_node_finger_scan_unmatched
  on_finger_scan_misplaced:
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: PURPLE
        count: 2
    - homeassistant.event:
        event: esphome.frontdoor_finger_scan_misplaced
  on_enrollment_scan:
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: BLUE
        count: 2
    - homeassistant.event:
        event: esphome.test_node_enrollment_scan
        data:
          finger_id: !lambda 'return finger_id;'
          scan_num: !lambda 'return scan_num;'
    - fingerprint_grow.aura_led_control:
        state: GRADUAL_OFF
        speed: 100
        color: PURPLE
        count: 1
  on_enrollment_done:
    - fingerprint_grow.aura_led_control:
        state: BREATHING
        speed: 100
        color: BLUE
        count: 2
    - homeassistant.event:
        event: esphome.test_node_enrollment_done
        data:
          finger_id: !lambda 'return finger_id;'
  on_enrollment_failed:
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: RED
        count: 4
    - homeassistant.event:
        event: esphome.test_node_enrollment_failed
        data:
          finger_id: !lambda 'return finger_id;'

Het is eigenlijk niet zo heel verschillend van de samplecode vanop de documentatiepagina.

Ik vind het zo bizar dat hij die trigger getriggerd wordt bij een confidence van 0. Dat houdt geen steek lijkt me. Maar mogelijks mis ik nog iets?

FYI: ik ben een complete noob wat betreft esphome en HA.

EDIT: dit is trouwens een voorbeeld van een event:

code:

event_type: esphome.test_node_finger_scan_matched
data:
  device_id: 992630b35ac2<......>
  finger_id: "10"
  confidence: "0"
origin: LOCAL
time_fired: "2024-02-28T22:13:39.387471+00:00"
context:
  id: 01HQRWFJX<......>
  parent_id: null
  user_id: null

(Beetje redacted. Waarschijnlijk niet nodig, maar... je weet maar nooit )


EDIT2: Mhmmm... volgens mij heb ik exact dit issue: https://github.com/esphome/issues/issues/2542

De eerste comments zijn hoopvol, maar de comment die het ticket deed sluiten is minder bemoedigend...

EDIT3: Sorry voor de eindeloze edit-spam, maar jullie als klankbord gebruiken heeft geholpen!

Ik las in bovenstaand ticket dat het te maken had met de ledring. Die deed de sensor foute triggers triggeren. De ledring uitzetten zou helpen, rapporteren Github gebruikers.
Jammer dat ik niet meer onder het ticket kan commenten, want... ik heb het opgelost door:
1) on_finger_scan_start volledig uit te zetten. Deze trigger heeft eigenlijk geen functie en deed bij mij niets meer dan een groen ledje tonen.
2) De volgorde van event sturen en leds oplichten omwisselen. Ik stuur nu eerst het event, en dan pas activeer ik de ledring.

Hierna werkt het. Wel geen idee welk van de twee het kunstje nu juist heeft geklaard. En ik ben bang om het terug stuk te maken door de wijzigingen weer ongedaan te maken

[ Voor 18% gewijzigd door Opifex op 28-02-2024 23:34 ]

[xtrme]

waarschijnlijk doe ik iets heel simpels fout maar ik krijg het niet voor elkaar

ik heb bij ome ali een esp32 relay module gekocht deze (esp32-wroom-32e)
https://aliexpress.com/item/1005005599324679.html

dacht eerst lekker makkelijk via de usb header flashen maar helaas deze is puur voor de 5v voorziening

dus toen dacht ik hang hem aan mijn esp programmer
deze
https://aliexpress.com/item/1005004609383559.html

ik sluit de
Programmer ESPrelay
TX - RX (ook TX - TX geprobeerd)
RX -TX (ook RX- RX geprobeerd)
GND GND
3v 3V
i00 i00 (volgens mij overbodig)

vervolgens houd ik de flash knop in en plug de usb in
en dan ziet web.esphome.io iets van een esp
maar het daadwerkelijk connecten en flashen wil niet

wat doe ik verkeerd

Schopje naar de buren

[ Voor 5% gewijzigd door Septillion op 01-03-2024 16:26 . Reden: Link cleanup ]

[Septillion]

@xtrme Je drukt wel de knop je Wroom in toch?

En geen USB dan in je Wroom?

Als je hem overigens met de pinnen op de gele header verbind geeft dat al de ESP kant aan aka Rxo / Txi. Dus Rx <=> Rx en Tx <=> Tx als je wat aansluit.

[xtrme]

Septillion schreef op vrijdag 1 maart 2024 @ 16:33:
@xtrme Je drukt wel de knop je Wroom in toch?

En geen USB dan in je Wroom?

Als je hem overigens met de pinnen op de gele header verbind geeft dat al de ESP kant aan aka Rxo / Txi. Dus Rx <=> Rx en Tx <=> Tx als je wat aansluit.

Zowel via de wroom als via de programmer
Maar mssn is het gewoon een aantal keer trial and error
Hoeft maar 1x te lukken daarna kan alles ota

[vso]

@xtrme lukt het wel/niet de esp te flashen ? let op dat je bij de esp in flash-modus (meestal knopje of GPIO0 met gnd verbinden) zetten daarna kan je via OTA updates zonder handeling updaten.

[The Fatal]

Om even in te haken. Indirect wel ESPHome gerelateerd.
Hoe regelen jullie voeding voor de ESP voor je veld apparatuur?
Batterijen/accu of vaste voeding, usb is niet altijd handig. En op sommige plekken is geen WCD voorhanden.
Welke optimalisatie voor voeding wordt er gebruikt?

[ Voor 8% gewijzigd door The Fatal op 03-03-2024 07:49 ]

[stevenP]

The Fatal schreef op zondag 3 maart 2024 @ 07:46:
Om even in te haken. Indirect wel ESPHome gerelateerd.
Hoe regelen jullie voeding voor de ESP voor je veld apparatuur?
Batterijen/accu of vaste voeding, usb is niet altijd handig. En op sommige plekken is geen WCD voorhanden.
Welke optimalisatie voor voeding wordt er gebruikt?

Ik heb vaak een stepdown voedinkje gepakt zodat ik een random 12v adapter kan pakken. Wemos heeft een mooi shieldje daarvoor, heb je direct alle goede voltages.

Meerdere bordjes hebben een 18650 batterij houder erop, of lipo laadfuncties, dan kan er zo'n kleine telefoonaccu aan en prik je 'm eens per week wel even aan de stroom

[_ferry_]

Eens met hierboven.
Daarnaast zijn er powerbanks van bijvoorbeeld voltaic, welke continu 5v leveren. Niet het meest efficiënt of goedkoop, wel eenvoudig met USB kabeltje en klaar.
(Veel gewone powerbanks gaan uit als de stroom afname te laag is)

[Septillion]

xtrme schreef op zaterdag 2 maart 2024 @ 12:57:
[...]


Zowel via de wroom als via de programmer
Maar mssn is het gewoon een aantal keer trial and error
Hoeft maar 1x te lukken daarna kan alles ota

Dus knop indrukken op de module en dan pas de USB in je prog bordje. En dan draden zoals ik vermeldde.

[Septillion]

Hier hangen alles ESPhome devices aan de netspanning. Zelfbouw via USB en standaard modules als een Sonoff via ingebouwde voeding.

Voor IoT heb ik geen zin om met accute klooien. Zodra de Zigbee chips gemeengoed worden in ESPhome (of alternatief) wil ik wel weer eens proberen. Maar wifi op accu is voor mij te veel geklooi voor IoT.

[Opifex]

Zoals ik hierboven reeds zei is het me vorige week gelukt om m'n vingerafdrukscanner aan de praat te krijgen. Heb er nog wat mee zitten experimenteren, en werkt echt verrassend goed!

Maar één ding lijkt toch niet helemaal goed te werken. Ik kan met de event listener de events opvangen. Dat is geen probleem. Nu wou ik deze events met een logbook loggen. Maar dat blijkt enkel te gaan met een entity? En dat heeft mijn ESPhome niet merk ik? Hij is wel geregistreerd als device, maar er zitten geen entities in?

Iemand enig idee hoe dat komt?

Toen ik er een BMP208 aan had hangen, of toen ik het onboard ledje als output gebruikte had ik wél een entity in HA.

[ Voor 199% gewijzigd door Opifex op 04-03-2024 11:39 ]

[Septillion]

@Opifex Mja, dit is een beperking van HA. Daarom zelf ook nog steeds niet zo'n fan van events voor buttons etc

Op zich is het wel logisch om alleen events te gebruiken, immers heeft het geen staat en is daarmee dus geen entiteit. Maar ze zijn gewoon lastiger te gebruiken en dus niet standaard in het logbook. Naar mijn idee loopt de implementatie dus wat achter.

Je zou dit zelf op kunnen vangen door een template sensor in ESPhome aan te maken en hier ook een status naartoe te pushen.

[Opifex]

Mhmmm, wacht. Eens kijken of deze rookie het goed begrijpt

Ik maak in dezelfde Yaml voor de vingerafdruksensor een extra entry voor een dummy sensor aan. Deze moet dan naar de events luisteren en die opnieuw uitsturen? Begrijp ik dat goed?

[Septillion]

@Opifex Onder het component van je scenner heb je al een on_finger_scan_matched event waar je dingen mee kunt doen. Daar zou je een actie neer kunnen zetten die je template sensor een waarde geeft dmv sensor.template.publish.

De voorbeeldcode van de grow sensor geeft daar zelfs al een voorbeeldje van (bovenste deel). Eventueel zou je dus de 'confidence' ook als voorwaarde kunnen geven, weet even niet hoe je dar nu verder doet

[Opifex]

Ohja, ik zie het nu!
Volgens mij heb ik dat stukje code al in m'n YAML gehad, maar er intussen weer uitgehaald omdat het toen niet werkte. Ga er vanavond nog eens mee spelen! Thanks Septillion!

Voorlopig heb ik nog niets conditioneel geprogrammeerd. Zit nog maar in het experimenteerstadium
Ik was aan het denken om het verwerken van event-->actie in HA te laten gebeuren, ipv. op de ESP. Want één nadeel van deze sensor (vind ik) is dat je "enrolled" vingerafdrukken niet kan "deactiveren". Bvb. je wil de buurvrouw toegang geven om de planten water te geven terwijl je op reis bent, maar na je reis wil je de toegang weer afnemen. Zoals deze sensor werkt moet je dan de hele afdruk verwijderen. Dat is jammer, want als in de toekomst opnieuw toegang verleend moet worden dan moet die vinger weer toegevoegd worden...

Daarom dacht ik een tabel te maken van vingers, met daarin een boolean die zegt of ze toegang mogen hebben of niet. Die tabel kan dan zelfs in noodgevallen vanop afstand aangepast worden, zodat er in nood toegang verleend kan worden. Die tabel moet dan in HA zelf verwerkt worden, dus kan de confidence ook ineens daar in rekening gebracht worden.

(Nu... in de praktijk merk ik wel dat de confidence niet echt uitmaakt. Onbekende vingers hebben altijd al 0 gegeven, terwijl gekende vingers steevast een waarde tussen 800 en 2000 geven. Het verschil is dus echt wel groot)

[Septillion]

@Opifex Op zich heb je binnen ESPhome dezelfde functionaliteit als in HA mits je maar niet op elke 'match' gelijk dingen uitvoert. Je kan immers in ESPhome ook zien wie er een match was (via finger_id) en daar dan wel of niet op handelen. Toegegeven, in HA dit dit waarschijnlijk wat makkelijker maar het kan wel.

Eventueel zou je dit alleen voor een vaste set vingers (die van jezelf) in de ESP kunnen doen zodat dit altijd werkt (ook zonder HA) en dat andere vingers wel alleen door HA laten doen voor de flexibiliteit.

[Wirehead]

The Fatal schreef op zondag 3 maart 2024 @ 07:46:
Om even in te haken. Indirect wel ESPHome gerelateerd.
Hoe regelen jullie voeding voor de ESP voor je veld apparatuur?
Batterijen/accu of vaste voeding, usb is niet altijd handig. En op sommige plekken is geen WCD voorhanden.
Welke optimalisatie voor voeding wordt er gebruikt?

Indien je echt off-grid will gaan, kan je met deep-sleep, een zonnepanneeltje en een 18650-cell heel ver raken.
Zo heb ik vorige zomer met een Xiao ESP32-C3 (die ingebouw battery management heeft) een zwembad-temperatuurmonitor in gebruik gehad, die mits het zonnepaneeltje, de 18650 cell mooi bijlaadde. Na de zomer, en dag en nacht gebruik, was de cell nog altijd mooi volgeladen

[Opifex]

Septillion schreef op maandag 4 maart 2024 @ 12:18:
@Opifex Op zich heb je binnen ESPhome dezelfde functionaliteit als in HA mits je maar niet op elke 'match' gelijk dingen uitvoert. Je kan immers in ESPhome ook zien wie er een match was (via finger_id) en daar dan wel of niet op handelen. Toegegeven, in HA dit dit waarschijnlijk wat makkelijker maar het kan wel.

Eventueel zou je dit alleen voor een vaste set vingers (die van jezelf) in de ESP kunnen doen zodat dit altijd werkt (ook zonder HA) en dat andere vingers wel alleen door HA laten doen voor de flexibiliteit.

Sure, maar dan zou je je ESPHome al moeten laten connecteren naar een database, of een GoogleSheets. Zeker gezien ik een ESP-01 gebruik lijkt me wat misbruik maken van het beestje Mijn HA daarentegen draait op een Pi5 met SSD. Die kan zonder problemen naar een Google Sheets pollen of een databaseje aanmaken.

[Septillion]

@Opifex Neuh, zo complex hoef je het niet te doen. Goed, alleen jezelf zou je vast kunnen programmeren.

Maar ook dynamisch zou met vliegwerk te doen zijn. Eerste waar ik aan dacht was een template text sensor te maken en daar dan een komma gescheiden lijst in bij te houden van toegestane finger ids. En dan een template number en twee buttons (toevoegen en verwijderen) om een finger id toe te voegen of juist te verwijderden uit die lijst. Niet heeeeeel mooi maar zou wel werken.

Vandaar dat ik mezelf nog wel hard coded erin zou doen en dan de rest via HA zou regelen. Maar goed, als je het extern wilt bijhouden is dat in HA ook al wel een uitdaging hoor

[xtrme]

xtrme schreef op vrijdag 1 maart 2024 @ 16:18:
waarschijnlijk doe ik iets heel simpels fout maar ik krijg het niet voor elkaar

ik heb bij ome ali een esp32 relay module gekocht deze (esp32-wroom-32e)
https://aliexpress.com/item/1005005599324679.html

dacht eerst lekker makkelijk via de usb header flashen maar helaas deze is puur voor de 5v voorziening

dus toen dacht ik hang hem aan mijn esp programmer
deze
https://aliexpress.com/item/1005004609383559.html

ik sluit de
Programmer ESPrelay
TX - RX (ook TX - TX geprobeerd)
RX -TX (ook RX- RX geprobeerd)
GND GND
3v 3V
i00 i00 (volgens mij overbodig)

vervolgens houd ik de flash knop in en plug de usb in
en dan ziet web.esphome.io iets van een esp
maar het daadwerkelijk connecten en flashen wil niet

wat doe ik verkeerd

[mbr]Schopje naar de buren[/mbr]

usb op de relay is alleen voor 5v voorziening geen data
het bordje heeft ook geen programmer chip CP of CH

het is gelukt

het prog board aangesloten op de relay
TX - RX
RX -TX
GND GND
3v 3V
i00 i00
5V 5V

intern op het bordje I00 vast verbonden met de GND
daarna wilde hij zonder problemen flashen

@Septillion thnx voor meedenken
btw; je kunt verplaatste berichten niet editten


ben aan het proberen /leren om de smartdoor V2 van zuidwijk naar dit bordje te krijgen
nu nog even de COM aan GPIO5 (G5) en Bell over de GPIO4 (G4) en hij doet het denk ik (eerst ff meten voordat de trafo erop gaat
https://github.com/zuidwi...main/smart-doorbell2.yaml

en ik heb hem werkend

code:

esphome:
  name: doorbell
  project:
    name: zuidwijk.smart-doorbell
    version: "2.0"

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

wifi:
    ssid: !secret wifi_ssid 
    password: !secret wifi_password


captive_portal:

improv_serial:

esp32_improv:
  authorizer: none

#doesnt work together with captive_portal
esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

web_server:
  port: 80

dashboard_import:
  package_import_url: github://zuidwijk/esphome-doorbell/smart-doorbell.yaml@main
  import_full_config: true

time:
  - platform: homeassistant
    id: homeassistant_time
 
text_sensor:
  - platform: version
    name: Doorbell ESPHome Version
  - platform: wifi_info
    ip_address:
      name: Doorbell IP
    ssid:
      name: Doorbell SSID
    bssid:
      name: Doorbell BSSID
 
sensor:
  - platform: uptime
    name: Doorbell Uptime
  - platform: wifi_signal
    name: Doorbell WiFi Signal
    update_interval: 60s
 
globals:
  - id: chime
    type: bool
    restore_value: true
    initial_value: 'true'
 
switch:
  - platform: gpio
    pin:
      number: GPIO16
      inverted: false
    name: "Doorbell Relay"
    id: relay
    internal: true
    icon: mdi:alarm-bell
  - platform: restart
    name: "Doorbell Restart"
  - platform: template
    name: Doorbell Chime Active
    id: chime_active
    restore_mode: disabled
    turn_on_action:
      - globals.set:
          id: chime
          value: 'true'
    turn_off_action:
      - globals.set:
          id: chime
          value: 'false'
    lambda: |-
      return id(chime);
     
binary_sensor:
  - platform: gpio
    pin:
      number: GPIO4
      mode: INPUT_PULLUP
      inverted: true
    name: "Doorbell"
    filters:
      # Small filter, to debounce the button press.
      - delayed_on: 25ms
      - delayed_off: 25ms
    on_press:
      # Only turn on the chime when it is active.
      then:
        if:
          condition:
            - switch.is_on: chime_active
          then:
            - switch.turn_on: relay
    on_release:
      # On release, turn of the chime.
      - switch.turn_off: relay        
 
  - platform: status
    name: "Status Doorbell"

mijn setup op dit moment een fan relay

input power is 12v 2a adapter met dc plug
DC plug naar +/- kabeltje
https://nl.aliexpress.com/item/1005004522593726.html
relay esp32 bordje
https://aliexpress.com/item/1005005599324679.html

espkabels
DC12v+ op de VCC
VCC naar 12v 12v Fan Chime
DC12v- GND
GND naar COM
NO naar GND Fan of chime)

Deurbel of pushbutton
tussen GP04 and GND op ESP

[ Voor 64% gewijzigd door xtrme op 08-03-2024 11:34 ]

[bauk]

Wat tof, net terwijl ik begin met fröbelen met Shelly's, esphome en pulsdrukkers is er net een nieuw topic helemaal hieraan toegewijd. Bookmarkje erbij

Waar gaat het om:
Shelly 1
Jung 531U
ESPhome 2024.2.1


Wat ik namelijk heb gedaan: ik heb een shelly1 via een intermediar firmware (Tasmota) geflashed met ESPhome. Deze wil ik namelijk gebruiken om in geval van uitvallen van wifi, of home assistant, de (hue) lichten gewoon hard uit en aan te zetten, conform deze "officiële" documentatie: https://devices.esphome.i...-push-button-light-switch

Alleen, als ik dit zo upload, kom ik niet verder dan een on state of off state:

code:

[23:06:16][D][binary_sensor:036]: 'slimmewandknopaenb button': Sending state ON
[23:06:17][D][binary_sensor:036]: 'slimmewandknopaenb button': Sending state OFF
[23:06:17][D][binary_sensor:036]: 'slimmewandknopaenb button': Sending state ON
[23:06:17][D][binary_sensor:036]: 'slimmewandknopaenb button': Sending state OFF

Ik heb de code eens uitgekleed om te kijken of hij überhaupt een on_double_click of een on_multi_click registreert. Krijg 't niet voor elkaar de logs blijven werken. Ik heb een on_press event getest, dan gaat 't licht aan.

Ik ben een beetje at a loss waar ik het moet zoeken. Ik heb de code zoals onder de link 1 op 1 geprobeerd (uiteraard alleen wifi aanpassend), maar no way Jose.

Hebben jullie enig idee tegen welke boom ik aan moet blaffen?

[Opifex]

Septillion schreef op maandag 4 maart 2024 @ 11:59:
@Opifex Onder het component van je scenner heb je al een on_finger_scan_matched event waar je dingen mee kunt doen. Daar zou je een actie neer kunnen zetten die je template sensor een waarde geeft dmv sensor.template.publish.

De voorbeeldcode van de grow sensor geeft daar zelfs al een voorbeeldje van (bovenste deel). Eventueel zou je dus de 'confidence' ook als voorwaarde kunnen geven, weet even niet hoe je dar nu verder doet

Dit is gelukt!

Door de waardes via een sensor template te publishen kan ik ze inderdaad in het logbook van dat device zien. Probleem is dat ik hiermee slechts één waarde kan teruggeven. Ik heb ook geprobeerd om de scan_tag functionaliteit te gebruiken, maar het lijkt me dat je dan elke tag afzonderlijk in HA moet configureren? Dat is wel heel omslachtig... Om het min of meer administratief overzichtelijk te maken zou je zelfs in HA én Esphome moeten configureren, want anders krijg je enkel de ID's van de "tags" te zien.

Ik ben uiteindelijk beland bij de text_sensor. Daarmee kan ik de twee waardes aan elkaar plakken en op die manier doorgeven.
Heb gisteren geprobeerd er een automation van te maken, maar hoe ik die textuele waardes terug kon parsen geraakte ik niet meteen uit. Maar een nachtje slapen heeft me op het idee gezet om er gewoon een JSON string van te maken. Die kan ik vast wel parsen in HA, om de parameters dan te gebruiken in een automation!

[Septillion]

@Opifex Welke twee waardes wil je doorgeven? Je kan namelijk natuurlijk ook gewoon twee template sensoren maken

[Opifex]

Finger_id en confidence.

Twee template sensoren doorgeven had ik nog niet eens aan gedacht... Dat is misschien nog niet zo'n slecht idee...?

[Septillion]

@bauk Ik denk dat ook jij tegen het probleem aan loopt dat events niet zo gebruikersvriendelijk zijn in HA...

Want die binary_sensor zal alleen aan of uit zijn. Maar de presses gaan alleen va events. Daarvan weet ik niet zo zeker of ze standaard in de log komen. Heb je in HA ook werkelijk eens geluisterd naar het vent esphome.button_pressed (via Dev tools => Events)?

Of anders zou je eens als extra action een log kunnen doen met logger.log bij de presses.

[bauk]

@Septillion
To be honest, ik krijg op dit moment even helemaal niets uit het dat ding, ik ben nu helemaal naar een kale config waarin ik gewoon een log wil zien op on_boot:. Kijken of ik daarvandaan ook een event kan sturen naar home assistant.

Bijna aan het overwegen om het project opnieuw te beginnen maar dat lijkt me echt vreemd dat dat nodig zou zijn.

[stevenP]

Opifex schreef op dinsdag 5 maart 2024 @ 08:37:
Finger_id en confidence.

Twee template sensoren doorgeven had ik nog niet eens aan gedacht... Dat is misschien nog niet zo'n slecht idee...?

Met behulp van log entries kan je heel veel in je log posten, die je live kan bekijken via de ESPHome addon in HA.
Ik had bijvoorbeeld tijdelijk deze erin staan, zodat ik de interface van mijn speedcontrol kon testen. Wel zo makkelijk voor debuggen.

YAML:

    on_turn_on:
      - logger.log: "Fan Turned On!"
      - switch.turn_on: relay
    on_turn_off:
      - logger.log: "Fan Turned Off!"
      - switch.turn_off: relay

Kan je in tekst uitleggen wat je wil zien / loggen? Je hebt finger_id en confidence.

• 'finger_id' altijd de laatst gemeten vinger 0-254
• 'confidence' is dat een check of hij klopt of niet? Binary?

Hoogstwaarschijnlijk kunnen beiden via een template geregistreerd worden en deze zullen als sensor exposed zijn aan HA, waarna die netjes gelogd worden bij iedere change.

[Septillion]

@bauk Opnieuw compilen en uploaden is genoeg. Maar wat is nu wat je hebt geüpload?

En wat zie je in HA? Screenshotje?

[Septillion]

@stevenP Volgens mij zag hij dat wel netjes al in de ESPhome log maar de events komen irritant genoeg niet in de device logs in HA. En dat is volgens mij wat hij wilde.

[stevenP]

Septillion schreef op dinsdag 5 maart 2024 @ 10:43:
@stevenP Volgens mij zag hij dat wel netjes al in de ESPhome log maar de events komen irritant genoeg niet in de device logs in HA. En dat is volgens mij wat hij wilde.

Ik lees een stukje terug en zie ook de vraag rondspoken om vanuit HA frontend variabelen door te geven aan de ESP.

Dat kan op de volgende manier toch?

YAML:

sensor:  
- platform: homeassistant
    name: "Buurvrouw nr39"
    id: "buurvrouw39"
    entity_id: binary_sensor.buurvrouw39

Met in HA een helper binary toggle waarbij je de buuf van nr 39 on/off toggled.

In ESP moet dan wel nog de goede vinger aan de goede entity gekoppeld worden, en dat wil je misschien wel via arrays laten checken oid - in ieder geval niet allemaal handmatig erin moeten zetten..

[Opifex]

@stevenP die logger heb ik nog niet geprobeerd. Dat ziet er mij inderdaad ook nuttig uit! Ga ik vanavond eens proberen
Maar in principe had ik al een soort rudimentaire logging werkend door gebruik te maken van het logbook op de entity pagina. Voor development volstaat dat.

Finger_id is inderdaad tussen 0 en 255, maar confidence is geen boolean maar een integer waarde. (Vermoed ik toch, gezien ik al waardes van boven de 2000 heb gezien)
Ik zou beide waardes tot in HA willen krijgen zodat ik daarna (1) een beslissing kan maken op basis van de confidence (bvb. alles onder 100 wordt genegeerd), en (2) op één of andere manier in HA een look-up laten gebeuren in één of andere tabel (bvb. een Google Sheets die gecached wordt) en op basis daarvan een beslissing maken of de garagepoort een puls gegeven moet worden of niet.

[stevenP]

Opifex schreef op dinsdag 5 maart 2024 @ 11:02:
@stevenP die logger heb ik nog niet geprobeerd. Dat ziet er mij inderdaad ook nuttig uit! Ga ik vanavond eens proberen
Maar in principe had ik al een soort rudimentaire logging werkend door gebruik te maken van het logbook op de entity pagina. Voor development volstaat dat.

Finger_id is inderdaad tussen 0 en 255, maar confidence is geen boolean maar een integer waarde. (Vermoed ik toch, gezien ik al waardes van boven de 2000 heb gezien)
Ik zou beide waardes tot in HA willen krijgen zodat ik daarna (1) een beslissing kan maken op basis van de confidence (bvb. alles onder 100 wordt genegeerd), en (2) op één of andere manier in HA een look-up laten gebeuren in één of andere tabel (bvb. een Google Sheets die gecached wordt) en op basis daarvan een beslissing maken of de garagepoort een puls gegeven moet worden of niet.

Oke, even debuggend meedenken dan.

- je legt je vinger op de reader
- op de ESP website (192.168 .. ) zie je de value veranderen
- in de log zie je niks
- in HA wordt de value niet bijgewerkt?

Als dit het geval is dan registreerd de ESP het correct, maar werkt de passthrough niet lekker. Als hij bijvoorbeeld lokaal ook niet lekker aangeeft dan kan het zijn dat je reader nog niet goed geconfigt of aangesloten is.

Je kan ook nog debug log aanzetten. Overigens is de log ook te volgen via de lokale site van de esp.

YAML:

#logging
logger:
  level: debug

[Septillion]

@stevenP Je kan nog makkelijker ook gewoon een tempalte switch in ESPhome maken. Probleem is dat dit niet schaalt. Je zal dus voor elke extra vinger dus de ESPhome code aan moeten passen, compilen en dan komt er een entity bij.

Dit in HA doen geeft je wel meer vrijheid.

[Opifex]

stevenP schreef op dinsdag 5 maart 2024 @ 11:07:

- op de ESP website (192.168 .. ) zie je de value veranderen

Die gebruik ik niet. Heb hem in het begin eens geprobeerd, maar werkte niet. Sindsdien niet meer geprobeerd omdat al de rest wel werkt.

- in de log zie je niks

Welke log bedoel je? In mijn huidige implementatie kan ik het logbook in HA wel degelijk een entry laten geven wanneer de sensor waarde een update geeft.

- in HA wordt de value niet bijgewerkt?

Jawel, die wordt bijgewerkt nu.

Je kan ook nog debug log aanzetten. Overigens is de log ook te volgen via de lokale site van de esp.

YAML:

#logging
logger:
  level: debug

Die heb ik moeten uitzetten. Ofja... eigenlijk net niet. de logger uitzetten zette ook om onverklaarbare reden de UART uit. Ondanks dat die afzonderlijk is gedefinieerd met een eigen baudrate en pinconfig. Ik heb de logger nu op enkel het hoogste niveau gezet zodat hij bijna nooit iets zou sturen.

De reden waarom ik de logger (via UART ten minste) moest uitzetten is omdat deze sensor ook via UART communiceert. (En ik jammergenoeg geen extra pinnen vrij heb om ergens anders een software uart te implementeren)

[Septillion]

@Opifex Ik dacht dat ze standaard al wel als event naar HA ging maar vind ik zo ook even niet terug...

maar zag je echt niets van de sensor in de ESPhome logger verschijnen? Dat had ik wel verwacht.

Let wel, de ESPhome logger en de HA event logger zijn echt twee verschillende dingen.

[Opifex]

Ik vermoed dat ik die ESPHome logger heb moeten uitschakelen (zie hierboven).

[Septillion]

@Opifex De webpagina krijg je als je deze aan hebt gezet met het web_server: component.

De logger kan je (standaard) op drie manieren zien. Via de webpagina als deze aan staat, in ESPhome dashboard bekijken met de knop "Logs" en via UART.

Gezien je een sensor gebruik wil je logger via UART uit hebben. Dit doe je door

YAML:

logger:
  baud_rate: 0

Dit zet alleen logger via UART uit maar via dashboard en webpage is deze dan gewoon aan

Hierna kan je vrij met een uart object je sensor gebruiken op uart0. Indien je een ESP gebruikt met meerdere UART kan je ook een andere uart voor je sensor pakken.

[Opifex]

Dat had ik inderdaad in de docs gelezen. De praktijk heeft me echter geleerd dat dit niet werkt zoals ik verwachtte. baud_rate op 0 zetten in de logger zorgde er ook voor dat mijn sensor niet meer werkte. Zelfs als de uart apart gedefinieerd stond met zijn eigen baudrate. Door de baud_rate niet te definieren in de logger, maar het loglevel hoog te zetten werkte alles terug wel.

[Septillion]

@Opifex Heb je daar de code van? En netjes op laatste ESPhome versie? Want ook hier ESP's met UART sensoren (een P1 en een PZEM) waar de logger via UART uit staat maar verder aan

[Opifex]

Ik zal het vanavond als ik thuis ben nog eens bekijken, en eventueel een code snippet droppen

Misschien was er ergens anders een conflict dat dit vreemde gedrag veroorzaakte.

[stevenP]

@Opifex de web_server samen met log entries werkt echt super. Je kan dan via web, op het ip adres van je ESP gemakkelijk alles volgen. Zo kan je checken of het lokaal goed verwerkt wordt, en daarmee aantonen dat het dus aan de communicatie met HA ligt. Elimineren van factoren is key voor debuggen

Voorbeeldje van de interwebs, omdat ik extern niet een eigen screenshot kan maken

[Opifex]

Ik zal dat vanavond ook nog eens proberen opzetten. Ziet er inderdaad nuttig uit

[bauk]

Septillion schreef op dinsdag 5 maart 2024 @ 08:52:
@bauk Ik denk dat ook jij tegen het probleem aan loopt dat events niet zo gebruikersvriendelijk zijn in HA...

Ik ben toch, door inderdaad recompile regeltje voor regeltje code opbouwen toch gekomen waar ik wilde zijn, alleen relevante blok:

YAML:

 Shelly 1 detached switch config with multi click options and fallback in case of wifi or api fail
binary_sensor:
  - platform: gpio
    pin:
      number: GPIO5
    name: ${device_name} button
    internal: True
    id: button
    on_multi_click:
      - timing:
          - ON for at most 1s
          - OFF for at most 1s
          - ON for at most 1s
          - OFF for at least 0.2s
        then:
          - if:
              condition:
                and:
                  - wifi.connected:
                  - api.connected:
              then:
                - homeassistant.event:
                    event: esphome.button_pressed
                    data:
                      title: ${device_name} double clicked
              else:
              # There is no network flash light to tell (and return to previous state), only single short will provide on/off
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
      - timing:
          - ON for at most 1s
          - OFF for at most 1s
          - ON for at most 1s
          - OFF for at most 1s
          - ON for at most 1s
          - OFF for at least 0.2s
        then:
          - if:
              condition:
                and:
                  - wifi.connected:
                  - api.connected:
              then:
                - homeassistant.event:
                    event: esphome.button_pressed
                    data:
                      title: ${device_name} triple clicked
              else:
              # There is no network flash light to tell (and return to previous state), only single short will provide on/off
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
      - timing:
          - ON for 1s to 2s
          - OFF for at least 0.5s
        then:
          - if:
              condition:
                and:
                  - wifi.connected:
                  - api.connected:
              then:
                - homeassistant.event:
                    event: esphome.button_pressed
                    data:
                      title: ${device_name} long clicked
              else:
              # There is no network flash light to tell (and return to previous state), only single short will provide on/off
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
      - timing:
          - ON for at most 1s
          - OFF for at least 0.5s
        then:
          - if:
              condition:
                and:
                  - wifi.connected:
                  - api.connected:
              then:
                - homeassistant.event:
                    event: esphome.button_pressed
                    data:
                      title: ${device_name} double clicked
              else:
              # No connection, going hardwire
                - switch.toggle: shelly_relay   
      - timing: 
          - ON for at least 1s
        then:
          - if:
              condition:
                and:
                  - wifi.connected:
                  - api.connected:
              then:
                - while: 
                    condition: 
                      binary_sensor.is_on: button
                    then: 
                      - homeassistant.event:
                          event: esphome.button_pressed
                          data:
                            title: ${device_name} dim_up
                      - delay: 1s
              else:
              # There is no network flash light to tell (and return to previous state), only single short will provide on/off
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
      - timing: 
          - ON for at most 1s
          - OFF for at most 1s
          - ON for at least 1s
        then:
          - if:
              condition:
                and:
                  - wifi.connected:
                  - api.connected:
              then:
                - while: 
                    condition: 
                      binary_sensor.is_on: button
                    then: 
                      - homeassistant.event:
                          event: esphome.button_pressed
                          data:
                            title: ${device_name} dim_down
                      - delay: 1s
              else:
              # There is no network flash light to tell (and return to previous state), only single short will provide on/off
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay
                - delay: 1s
                - switch.toggle: shelly_relay

Dat, met een event in home assistant opgevangen wordt om een hue aan te sturen.

Wel jammer dat ik dat je de connectie if niet om de multi heen kunt zetten, zo veel ifjes ertussen is niet heel elegant

Wat ik alleen gaaf zou vinden is dat de automaten wat meer zou doen met event data, title allen en eventueel een payload dat aangeeft dat er gedimd moet worden, dubbelklik, zodat ik meer in één automatie kan verwerken. Wordt anders zo'n rommeltje in Home Assistant

[vso]

stevenP schreef op dinsdag 5 maart 2024 @ 13:22:
@Opifex de web_server samen met log entries werkt echt super. Je kan dan via web, op het ip adres van je ESP gemakkelijk alles volgen. Zo kan je checken of het lokaal goed verwerkt wordt, en daarmee aantonen dat het dus aan de communicatie met HA ligt. Elimineren van factoren is key voor debuggen

Voorbeeldje van de interwebs, omdat ik extern niet een eigen screenshot kan maken
[Afbeelding]

ik heb een restart en andere info voor de esp erbij staan

YAML:

web_server:
  port: $web_port
  version: 2
  local: True

text_sensor:
  - platform: wifi_info
    ip_address:
      name: ${devicename} IP Address
    ssid:
      name: ${devicename} Connected SSID
    bssid:
      name: ${devicename} Connected BSSID
    mac_address:
      name: ${devicename} Mac Wifi Address
    # scan_results:
    #  name: ${devicename} Latest Scan Results

switch:
  # (HA and webportal) restart ESP device button
  - platform: restart  
    name: ${devicename}" Restart" 
    icon: "mdi:pulse" 

wellicht handig, wellicht niet

[Septillion]

@bauk Top!

Zou wel aanraden om ${device_name} uit de namen van elementen te halen. HA zet namelijk de naam van het device er al voor. Imn dit geval niet heel boeiend omdat hij internal is maar toch.

En mja, klopt wel. Maar komt vooral omdat je pas een if-action kan gebruiken zodra het echt over actions gaat. Hele on_multi_click is gewoon een configuratie parameter. Je zou het nog wat op kunnen ruimen door de acties naar een los script te verplaatsen.

Maar wat bedoel je met het laatste? Nu je het in HA hebt kan je toch doen en laten wat je wilt?

@vso Device name deel geldt ook voor jou

[vso]

Septillion schreef op dinsdag 5 maart 2024 @ 15:16:
@vso Device name deel geldt ook voor jou

voordat je attendeert .. let wel waar in de code het displayed!

bijvoorbeeld op de webportal zie je de variable wel omvormen tot de device naam (zie je niet in HA terug)

maar thx voor de reminder

[ Voor 4% gewijzigd door vso op 05-03-2024 15:44 ]

[Septillion]

@vso In de webportal zie je inderdaad alleen de naam van component, dat klopt. Maar in HA zal dit een samentrekking zijn met friendly name van device.

Dus een device met als friendly name "Foo" heeft, als devicename "Bar" en als component dat als name "${devicename} Restart", dan zal deze in HA dus nu "Foo Bar Restart" gaan heten.

[stevenP]

vso schreef op dinsdag 5 maart 2024 @ 15:02:
[...]

ik heb een restart en andere info voor de esp erbij staan

YAML:

web_server:
  port: $web_port
  version: 2
  local: True

text_sensor:
  - platform: wifi_info
    ip_address:
      name: ${devicename} IP Address
    ssid:
      name: ${devicename} Connected SSID
    bssid:
      name: ${devicename} Connected BSSID
    mac_address:
      name: ${devicename} Mac Wifi Address
    # scan_results:
    #  name: ${devicename} Latest Scan Results

switch:
  # (HA and webportal) restart ESP device button
  - platform: restart  
    name: ${devicename}" Restart" 
    icon: "mdi:pulse" 

wellicht handig, wellicht niet

Als je bij die variabelen diagnostic toevoegd:

YAML:

 #Wifi strength
  - platform: wifi_signal
    name: "WiFi Signal dB"
    id: wifi_signal_db
    update_interval: 60s
    entity_category: "diagnostic"

dan komen ze netjes bij je diagnostics te staan in HA. Vind ik overzichtelijker, gescheiden van de daadwerkelijke controls/sensors.




Ik kan wat @Septillion zegt beamen; in HA wordt altijd de devicename voor je sensorid gezet.
Dus id "wifi_signal_db" wordt in HA sensor.esphome_web_3aeac6_wifi_signal_db

[ Voor 10% gewijzigd door stevenP op 05-03-2024 16:04 . Reden: toevoeging benaming ]

[bauk]

Septillion schreef op dinsdag 5 maart 2024 @ 15:16:
@bauk Top!


Maar wat bedoel je met het laatste? Nu je het in HA hebt kan je toch doen en laten wat je wilt?

ik ga eens kijken het is wel netter ja.

Scripts kan idd wat inkorten, ook daar kijken.

Waar ik vooral op doelde is dat je bij automations soms iets meer wilt doen, ik heb ergens iets gelezen over dat je variabelen kunt inzetten om je automation specifieker te maken zonder veel te moeten herhalen.

Een mockup van de code wat je dan zou willen uitnutten:

YAML:

  - homeassistant.event:
      event: esphome.button_pressed
         data:
            title: [s]${device_name}[/s] press
            payload: dim_down

Dat je dus in je automation op of neer gaat. Nu zijn het losse blokken in HA. Ga ergens ook weer van uit dat het probleem tussen toetsenbord en stoel zit qua kennis

[EDIT: ik heb test yaml met ~100 regels met een script in kunnen korten (hij wordt valide bestempeld), alleen nog niet kunnen installeren/testen. maar zie potentie tot succes ]

[ Voor 8% gewijzigd door bauk op 05-03-2024 21:56 ]

[Septillion]

@bauk Zo te zien mag er onder data gewoon een mapping zitten. Dus wat je schrijft zou moeten kunnen. Zou ik het wel wat duidelijkere namen geven, iets als:

YAML:

  - homeassistant.event:
      event: esphome.button_pressed
         data:
            device_name: ${device_name}
            pressed: double

Dan krijg je gewoon een event met als data childs 'device_name', 'pressed' en 'device_id'. Laatste bedenkt HA zelf dus vind ik minder handig.

Zou het zelf ook meer beschrijvend houden wat er op de device gebeurde en niet wat er moet gebeuren. Die vertaling doe je dan gewoon lekker in HA maar houd je het universeel.

[bauk]

Kan het niet laten om te melden @Septillion : de Shelly hangt inmiddels in het plafond. Het werkt behoorlijk, maar ben nu aan het spelen met de vele mogelijkheden met de trigger data.

Het is voor ons slaapkamerlicht (met hue nachtlampjes...). MIjn betere wederhelft ligt daar nu te slapen. Het jeukt om de firmware aan te passen om de data inderdaad volgens jouw concept in de home assistant automation te verwerken en gelijk te testen. Ik kom daarmee in de problemen als ik dat doe .

Als ik het nou een beetje werkend heb: is dit topic dan ook de plek om een dergelijke yaml uit HA te delen? Ga niet beloven dat ik dat deze week al heb hoor . But: just asking...

[bauk]

Ik ben druk bezig met het versimpelen van het script in de esphome yaml file.

Voor het dimmen heb ik nu een "code" ingebouwd voor de knop. Ingedrukt houden is feller (dim_up) en dubbelklik en ingedrukt houden is zachter. Alleen, ik zou het liefst de dimknop een tikje slimmer willen maken: ingedrukt houden is de ene keer feller en de keer erna zachter.

Daartoe heb ik een Global variabel aangemaakt:

YAML:

# create variable for dimming up or down
globals:
  id: dim_up
  type: bool
  restore_value: no
  initial_value: 'false'

Wat ik daarna heb is in een binary sensor die in een while loop een call doet naar home assistant. En afhankelijk van de waarde van dim_up wordt de call "dim_up" of "dim_down". (ja ergens onduidelijk dat de variabele en de action hetzelfde heten. Mocht je suggesties hebben...

YAML:

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO5
    name: ${device_name} button
    internal: True
    id: button
    on_multi_click:
      ###### snip andere patronen #####
      # Hold
      - timing: 
          - ON for at least 1s
        then:
      # Hold
      - timing: 
          - ON for at least 1s
        then:
          # flip value for next time
          - globals.set:
              id: dim_up
              value: !lambda return ! id(dim_up)
          # resend hold status
          - while: 
              condition: 
                binary_sensor.is_on: button
              then: 
                - lambda: |- 
                    if (id(dim_up)) { ESP_LOGD("custom", "This is a if debug message"); }
                    else { ESP_LOGD("custom", "This is a else debug message"); }
                - delay: 0.5s

De reden dat ik een lambda heb in de while-lus, is omdat if statements niet genest mogen worden (in ieder geval wordt die niet als valide bestempeld). Overigens: voor nu een ESP_LOGD, als dit werkt ga ik verder met de aanroep van een script.

En lambda zoals hierboven wel. *MAAR*: het compilet niet, stelselmatig gedoe over ; of anders dat er op duidt.

De fout:

code:

/config/esphome/slimmewandknopaenb.yaml: In lambda function:
/config/esphome/slimmewandknopaenb.yaml:165:31: error: expected ';' before '}' token
  165 |           - while:
      |                               ^
      |                               ;
  166 |               condition:
      |                                
Compiling .pioenvs/slimmewandknopaenb/lib3ff/ESP8266mDNS/LEAmDNS_Control.cpp.o
*** [.pioenvs/slimmewandknopaenb/src/main.cpp.o] Error 1
========================= [FAILED] Took 10.96 seconds =========================

Wat gaat hier toch mis?

[Septillion]

@bauk Lambda's zijn puur C++ incl dat je een statement af moet sluiten met een ;

[bauk]

Septillion schreef op maandag 11 maart 2024 @ 11:22:
@bauk Lambda's zijn puur C++ incl dat je een statement af moet sluiten met een ;

FML... Ik zat in de verkeerde lambda te zoeken naar een ;. het zat 'm in regel 21 van de code, niet in het while lusje. Eerst dacht ik dat je tip echt niets opleverde.. tot ik verder keek.

Thanks! hij compilet, dus kan weer lekker verder knutselen

[heintjeput]

Ik heb al een hele tijd een ESP draaien om mijn Solis4G omvormer uit te lezen. Eerst een ESP8266 en inmiddels een echt bordje met een ESP32-C3, hierin gebruik ik ook de deepsleep om hem uit te schakelen tussen cycli door. Ik hoef maar 1x per 2 minuten de data te hebben. Ik heb hier wat mee geexperimenteerd en het leek er in eerste instantie op dat een on-time van 3 seconde genoeg zou zijn.

Helaas merkte ik dat ik nog maar de helft van de dag data kreeg, dus ik heb het inmiddels verlengt naar 6 seconde en wat logging toegevoegd. Het lijkt er op dat om de een of andere reden de loop time x2 / x3 gaat. Ik heb geprobeerd het te correleren aan de data die ik binnen krijg, maar daar niks in kunnen vinden. Hebben jullie een idee hoe ik de diagnostiek kan toevoegen / waar het aan kan liggen.

YAML:

substitutions:
  devicename: "omvormer"

globals:
  - id: ota_mode
    type: int
    restore_value: no
    initial_value: '0'

esphome:
  name: "omvormer"
  friendly_name: omvormer
  platformio_options:
    board_build.flash_mode: dio

  on_boot:
    priority: 600
    then:
      - text_sensor.template.publish:
          id: online_template
          state: "booted"
  on_shutdown:
    priority: 200
    then:
      - text_sensor.template.publish:
          id: online_template
          state: "shutdown"

esp32:
  board: esp32-c3-devkitm-1
 

# Enable logging
logger: 
  level: DEBUG

# Enable Home Assistant API
api:
  encryption:
    key: #secret

ota:
  password: #secret
  on_end:
    then:
    - lambda: |-
        id(ota_mode) = 0;
    - mqtt.publish:
        topic: "$devicename/ota"
        payload: "OFF"
        retain: true

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: 192.168.178.197
    gateway: 192.168.178.1
    subnet: 255.255.255.0
    dns1: 192.168.178.1
  fast_connect: True

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "omvormer Fallback Hotspot"
    password: "14jdpJVsJPXC"

captive_portal:

deep_sleep:
  id: deep_sleep_1
  run_duration: 6s
  sleep_duration: 124s

mqtt:
  id: mqtt_cli
  broker: !secret homeassistant_ip
  username: !secret mqtt_username
  password: !secret mqtt_password
  discovery: false
  discovery_retain: false
  birth_message:
  will_message:
  on_message:
    - topic: $devicename/ota
      payload: 'ON'
      then:
        - deep_sleep.prevent: deep_sleep_1
        - lambda: |-
           id(ota_mode) = 1;
    - topic: $devicename/ota
      payload: 'OFF'
      then:
        - deep_sleep.allow: deep_sleep_1
        - lambda: |-
           id(ota_mode) = 0;


# PCB pin out
# 5 - TX
# 6 - Flow
# 7 - Rx
# 18 - SDA
# 19 - SCL

i2c:
  - sda: 18
    scl: 19
    #scan: True
    #id: bus_a
    #frequency: 10kHz

uart:
  baud_rate: 9600
  tx_pin: 5
  rx_pin: 7
  parity: NONE
  stop_bits: 1
  id: mod_uart

modbus:
  send_wait_time: 200ms
  uart_id: mod_uart
  id: mod_bus
  flow_control_pin: 6

modbus_controller:
  - id: mbc
    #address: 0x01
    modbus_id: mod_bus
    #command_throttle: 100ms
    #setup_priority: -10
    update_interval: 5s

debug:
  update_interval: 1s

text_sensor:
  - platform: template
    name: "Online sensor"
    id: online_template

sensor:
  - platform: wifi_signal
    name: "WiFi Signal Sensor"
    update_interval: 5s

  - platform: aht10
    variant: aht20
    temperature:
      name: "AHT21Temperature"
    humidity:
      name: "AHT21Humidity"
    update_interval: 5s
    id: aht21
    address: 0x38

  - platform: modbus_controller # Read current AC power as Unsigned 32-Bit
    modbus_controller_id: mbc
    name: "InvAcWatt"
    address: 3004
    register_type: "read"
    value_type: U_DWORD
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    id: InvAcWatt
    
  - platform: modbus_controller # Read current DC Voltage as Unsigned 16-Bit
    modbus_controller_id: mbc
    name: "InvDcVolt"
    address: 3021
    register_type: "read"
    value_type: U_WORD
    unit_of_measurement: "V"
    filters:
      - multiply: 0.1
    accuracy_decimals: 1
    device_class: voltage
    state_class: measurement
    id: InvDcVolt
   ... meer modbus items ...

  - platform: debug
    # free:
      # name: "Heap Free"
    # fragmentation:
      # name: "Heap Fragmentation"
    # block:
      # name: "Heap Max Block"
    loop_time:
      name: "Loop Time"
    # psram:
      # name: "Free PSRAM"

De volledige yaml staat hier op github