Het grote ESPhome topic

[Septillion]

@Toppe Heb je nog een extra PC?

Want 99% zeker dat dit of een netwerk issue is of een PC issue.

En qua files, filename boeit niet. Je kan twee verschillende files hebben voor dezelfde device, enige dat telt is de name (voor mDNS) of een use_address.

[Toppe]

Septillion schreef op donderdag 2 januari 2025 @ 11:22:
@Toppe Heb je nog een extra PC?

Want 99% zeker dat dit of een netwerk issue is of een PC issue.

En qua files, filename boeit niet. Je kan twee verschillende files hebben voor dezelfde device, enige dat telt is de name (voor mDNS) of een use_address.

Dat zou niet verklaren waarom de apparaten in Esphome zelf ook op offline staan.

[Septillion]

@Toppe Onterecht offline in de builder heb ik ook met regelmaat.

En anders blijft voor mij toch echt alleen een netwerk issue over...

[sjorsjuhmaniac]

Septillion schreef op donderdag 2 januari 2025 @ 12:38:
@Toppe Onterecht offline in de builder heb ik ook met regelmaat.

Bij mij ook. Echt netwerk en firewall als eerste troubleshooten.

[jj85]

@Toppe hier ook wel last van gehad (lange tijd geleden).
Dit opgevolgd, dat hielp
https://github.com/esphom...41#issuecomment-534156628

[Septillion]

@jj85 Maar dan zou op IP (dus zonder mDNS) wel gewoon moeten werken.

[jj85]

Septillion schreef op donderdag 2 januari 2025 @ 15:46:
@jj85 Maar dan zou op IP (dus zonder mDNS) wel gewoon moeten werken.

Ah ja ok. Dacht dat het enkel ging om offline devices in de Dashboard

[Toppe]

jj85 schreef op donderdag 2 januari 2025 @ 16:19:
[...]

Ah ja ok. Dacht dat het enkel ging om offline devices in de Dashboard

Dat ook. Heel irritant maar goed na een reconnect in UniFi doen ze het weer.

Ik heb alle dubbele apparaten uit Esphome gegooid, hoe die er gekomen zijn? Geen idee. Maar nu lijkt het probleem opgelost.

Toch geen netwerk issue

[Aziona]

Ter informatie: Ik had het probleem dat Espresense niet wilde werken op mijn ESP32's. Ze connecten niet met wifi, of reconnecten niet meer na de eerste reboot. Vreemd genoeg met ESP32's die al maandenlang goed werkten en temperatuurmetingen leverden via DS18B20-sensoren aan mijn MQTT-broker. Toen ik echter Espresense erop zette, wilden de meesten niet meer (opnieuw) verbinding maken met wifi.

Ik had geen van deze problemen toen ik de ESP32-DS18B20-MQTT-code van Random Nerder Tutorials gebruikte.
Ik heb meerdere dagen/weken besteed aan het oplossen van het probleem. Omdat ik ook iets las over foutieve ontwerpen met de ch340 serieel naar usb-converter, heb ik vijf nieuwe esp32's besteld met de CP2102 USB naar serieel converter in plaats van ch340 en tevens een wat duurdere versie, op Aliexpress.
Ik heb zojuist Espresense op alle vijf geïnstalleerd en alle vijf werken perfect, ook nadat ik ze meerdere keren opnieuw heb opgestart.
De vorige maakten helemaal geen verbinding of maakten na de eerste reboot geen verbinding meer.

Ik had ook zowel micro-usb als usb-c versies van ESP32. Het leek erop dat het probleem vooral in de usb-c versies zat. Ik denk dat dat verklaard kan worden doordat de versies die ik had bijna allemaal de ch340 converter gebruikten in plaats van de CP2102.

Bermuda is voor mij geen optie omdat ik Domoticz gebruik met de Espresense plug-in en ik weet niet hoe ESPhome werkt, werk alleen met de Arduino IDE.

Afijn, als mensen zoeken op Espresense en wifi dan komen ze wellicht deze post tegen en hebben ze er hopelijk iets aan.

[Septillion]

@Aziona kan dat het de CH340 is acht ik wel klein want deze wordt helemaal niet gebruikt met wifi. Dan zou er wat fout moeten gaan met flashen. Maar dat kan je dus makkelijk proberen door ze te programmeren via een externe converter (zou de CP2102 van de goede kunnen zijn).

Zelf wel eens gewoon brakke Wemos bordjes gehad met of brakke ESP's of brak geheugen ofzo. Want die wilde ook met externe converter nooit lekker. Ook vage problemen welk programma wel en welk niet goed wilde draaien.

[Aziona]

Septillion schreef op zaterdag 11 januari 2025 @ 18:36:
@Aziona kan dat het de CH340 is acht ik wel klein want deze wordt helemaal niet gebruikt met wifi.

Heeft iets te maken met een brak design, als je rechtstreeks 5v op vin/gnd zet dan gaat het ook al een stuk beter. Door voor 2102 te kiezen verklein je het risico dat je die in handen krijgt.

[Septillion]

@Aziona Mja, dat vind ik dus een beetje te kort door de bocht. De brakke ESP chip kan ook gewoon op de andere borden zitten. En an sich vind ik de CH340 de meest probleemloze USB-serial converter die er is.

[fvhemert]

Na het lezen van bovenstaande krijg ik het gevoel iets soort gelijks te hebben gezien.

Ik heb recentelijk een aantal M5Stack devices in gebruik genomen met Bermuda in HA. Veel geëxperimenteerd en meerdere malen de configuratie via ESPhome naar de devices geflashed. Dit ging een aantal dagen prima maar in een keer gingen de devices één voor één offline en waren ze met geen mogelijkheid meer met WiFi te verbinden. Geen problemen met compileren of uploaden, geen tussentijdse updates van ESPhome of HA en geen veranderingen in de code die eerder prima werkte. Alleen een aantal WiFi gerelateerde foutmeldingen in de device log. Totaal onverklaarbaar.

Na heel veel troubleshooten heb ik het probleem gevonden. Halverwege mijn testen ben ik een andere USB-C kabel gaan gebruiken en nadat ik ben terug gegaan naar de eerder gebruikte kabel verdween het probleem als sneeuw voor de zon. Het probleem is reproduceerbaar op alle devices: kabel 1 is geen probleem, kabel 2 geen WiFi.

Wat ik nog steeds niet begrijp is dat alleen de WiFi functionaliteit kapot gaat, al het andere blijft draaien zonder foutmeldingen.

Wellicht is dit gerelateerd en heb je er iets aan.

[magnifor]

Ik ben aan het spelen met ESPHome, heb een ESP8266 bordje gekocht maar krijg met geen enkele mogelijkheid een nieuwe firmware geupload op het apparaat. Ik volg de documentatie van ESPHome maar ook de handleiding die wordt geleverd door de leverancier van het bordje maar zonder succes:

https://cdn.shopify.com/s...62f9fd57.pdf?v=1721119260

Zowel op Linux als met Windows krijg k de volgende melding:

A fatal esptool.py error occurred: Failed to connect to ESP8266: Invalid head of packet (0x6F)

Zowel onder Ubuntu als Windows met 4 verschillende kabels. Heb ik te maken met een defect examplaar of moet hij nog in een soort van flash modus? Op het apparaat zit namelijk een flash button.

Geen HA => schopje naar ESPHome topic

[ Voor 3% gewijzigd door Septillion op 16-01-2025 13:16 ]

[Yelti]

magnifor schreef op donderdag 16 januari 2025 @ 11:42:
Ik ben aan het spelen met ESPHome, heb een ESP8266 bordje gekocht maar krijg met geen enkele mogelijkheid een nieuwe firmware geupload op het apparaat. Ik volg de documentatie van ESPHome maar ook de handleiding die wordt geleverd door de leverancier van het bordje maar zonder succes:

https://cdn.shopify.com/s...62f9fd57.pdf?v=1721119260

Zowel op Linux als met Windows krijg k de volgende melding:

A fatal esptool.py error occurred: Failed to connect to ESP8266: Invalid head of packet (0x6F)

Zowel onder Ubuntu als Windows met 4 verschillende kabels. Heb ik te maken met een defect examplaar of moet hij nog in een soort van flash modus? Op het apparaat zit namelijk een flash button.

Normaal zou je 2 knoppen moeten hebben, flash en boot. Normaal is het beide indrukken en boot/reset loslaten en flash ingedrukt houden, daarna loslaten.
Als je enkel flash hebt, zou ik denken flash ingedrukt houden, bord connecteren met usb en daarna flash loslaten. Dan komt deze in flashboot mode.

De andere optie is om gpio0 te verbinden met de ground tijdens het connecteren van de usb kabel.

Ook best even nakijken dat de esp correct word herkend in de devicemanager als com poort.

[Rouwette]

magnifor schreef op donderdag 16 januari 2025 @ 11:42:
Ik ben aan het spelen met ESPHome, heb een ESP8266 bordje gekocht maar krijg met geen enkele mogelijkheid een nieuwe firmware geupload op het apparaat. Ik volg de documentatie van ESPHome maar ook de handleiding die wordt geleverd door de leverancier van het bordje maar zonder succes:

https://cdn.shopify.com/s...62f9fd57.pdf?v=1721119260

Zowel op Linux als met Windows krijg k de volgende melding:

A fatal esptool.py error occurred: Failed to connect to ESP8266: Invalid head of packet (0x6F)

Zowel onder Ubuntu als Windows met 4 verschillende kabels. Heb ik te maken met een defect examplaar of moet hij nog in een soort van flash modus? Op het apparaat zit namelijk een flash button.

Boot knopje ingedrukt ouden als je de USB inprikt en dan ingeduwd houden totdat hij klaar is met de upload

[magnifor]

Yelti schreef op donderdag 16 januari 2025 @ 11:59:
[...]


Normaal zou je 2 knoppen moeten hebben, flash en boot. Normaal is het beide indrukken en boot/reset loslaten en flash ingedrukt houden, daarna loslaten.
Als je enkel flash hebt, zou ik denken flash ingedrukt houden, bord connecteren met usb en daarna flash loslaten. Dan komt deze in flashboot mode.

De andere optie is om gpio0 te verbinden met de ground tijdens het connecteren van de usb kabel.

Ook best even nakijken dat de esp correct word herkend in de devicemanager als com poort.

Ik heb een flash button en een rst button, flash ingedrukt houden, usb connecten en daarna loslaten maakt geen verschil. De flash button het hele upload process ingedrukt houden geeft een timeout error bij het uploaden. Aan de achterkant van het apparaat staat dat ik 9600 baud moet gebruiken maar in Arduino IDE wanneer ik het juiste bord selecteer zie ik nergens een optie voor 9600? Direct aan Linux bak gehangen met de handmatig baud 9600 opgegeven zelfde meldingen.

Probeer een Luna Firmware te flashen met de NODEMCU Firmware Programmer met de aanbevolen instellingen (dus 9600 baud etc), het enige wat er gebeurd is het blauwe ledje gaat uit (normaal knippert deze) en er staat AP MAC en STA MAC waiting, in de log files staat

Note:Serial port connected.
Note:Begin find ESP8266.

[ Voor 16% gewijzigd door magnifor op 16-01-2025 12:25 ]

[Septillion]

Rouwette schreef op donderdag 16 januari 2025 @ 11:59:
[...]

Boot knopje ingedrukt ouden als je de USB inprikt en dan ingeduwd houden totdat hij klaar is met de upload

Dat is in ieder geval nooit nodig Alleen tijdens boot (incl na reset) is de state van de pin van belang en dat duurt fractie van een seconde.

Dus betere methode is dan flash indrukken, reset indrukken, reset loslaten, flash loslaten.

[ Voor 11% gewijzigd door Septillion op 16-01-2025 13:21 ]

[Septillion]

@magnifor Dat zou hier overigens niet nodig moeten zijn want een NodeMCU Lonin v3 heeft auto reset erop zitten.

Maar je zo eens de web installer / kickstarter kunnen proberen (in een Chomium browser).

Wees je ook verzekerd van de juiste poort. In de web installer makkelijk te checken door eerst op "Connect" te klikken en daarna pas de USB erin te doen. Dan is heel duidelijke welk device erbij komt.

En kan nooit kwaad om je te verzekeren dat je de juiste drivers gebruikt.

[Aziona]

fvhemert schreef op dinsdag 14 januari 2025 @ 09:05:
Wellicht is dit gerelateerd en heb je er iets aan.

In het topic van Espresence en op Reddit waren er gebruikers die het wijten aan de gebruikte CH340 chip. Toen ze de vcc-line doorknipten (dus usb kabel niet meer bruikbaar) en rechtstreeks 5v op vin zette werkte het wel.

@Septillion Don't shoot the messenger: het is alleen wat ik heb gelezen, geen idee of het ook feitelijk met die chip te maken heeft.

[Septillion]

@Aziona Ik verwacht heel erg van niet. In mijn ogen is de CH340 de minst problematische chip.

Een extra ding dat gebeurd op de meeste modules als je Vin of 5V gebruikt voor de power is dat je nu een hogere spanning hebt. Want de V_BUS zit vaak met een diode aan de Vin / 5V.

[magnifor]

Septillion schreef op donderdag 16 januari 2025 @ 13:20:
[...]

Dat is in ieder geval nooit nodig Alleen tijdens boot (incl na reset) is de state van de pin van belang en dat duurt fractie van een seconde.

Dus betere methode is dan flash indrukken, reset indrukken, reset loslaten, flash loslaten.

Bordje was gewoon DOA. Ik heb een nieuwe besteld en deze werkt wel, ouwe gaat retour.

[Knappa]

Heeft iemand ervaring met rotary encoders in ESPHome?
Ik wil met een rotary encoder een dimbaar licht regelen. Klikken op de switch zou het licht moeten togglen en draaien aan de knop de intensiteit regelen. Dat werkt allemaal. Ik heb echter een randgeval: als het licht uit is, wil ik dat het licht aangaat op de minimale stand, als er één klik clockwise wordt gedraaid en het licht op maximale stand aangaat, als er één klik counterclockwise wordt gedraaid.
Of denken jullie dat ik dat beter kan bereiken in Home Assistant met behulp van b.v. node Red?

edit:

YAML:

binary_sensor:
  - platform: gpio
    id: rotary_switch
    pin:
      number: 2
      mode: INPUT_PULLUP
      inverted: True
    name: "Rotary switch"
    on_press:
      then:
        - if: 
            condition: 
              - lambda: 
                  'return id(testRotaryEncoder).state == 0;'
            then: 
              - logger.log:
                  format: "The temperature sensor reports value %.1f and humidity %.1f"
                  args: [ 'id(testRotaryEncoder).state', 'id(testRotaryEncoder).state' ]
            else: 
              - logger.log:
                  format: "The temperature sensor reports value %.1f and humidity %.1f"
                  args: [ 'id(testRotaryEncoder).state', 'id(testRotaryEncoder).state' ]
    

sensor:
- platform: rotary_encoder
  id: testRotaryEncoder
  name: "Rotary Encoder"
  pin_a: 1
  pin_b: 3
  min_value: 0
  max_value: 10
  on_clockwise:
    - logger.log: "Turned Clockwise"     
  on_anticlockwise:
    - logger.log: "Turned Anticlockwise"

Extra vraag: hoe kan ik de waarde van de rotary encoder gebruiken in de switch? Met die id(testRotaryEncoder).state krijg ik 'nan' (not a number), maar id(testRotaryEncoder).value werkt niet.

[ Voor 53% gewijzigd door Septillion op 18-01-2025 12:09 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Septillion]

@Knappa Zou zeggen dat het prima in ESPHome moet kunnen. Maar laat de code eens zien

[Knappa]

Septillion schreef op zaterdag 18 januari 2025 @ 11:12:
@Knappa Zou zeggen dat het prima in ESPHome moet kunnen. Maar laat de code eens zien

Zie edit hierboven, je antwoordde te snel :-)

Ik zie net dat m'n logging messages nog niet juist zijn, maar ik wilde gewoon iets van output kunnen zien. Ik laat het voorlopig even zo staan, maar in m'n omgeving zijn die al aangepast.

[ Voor 27% gewijzigd door Knappa op 18-01-2025 11:30 . Reden: opmerking over logging toegevoegd ]

[Septillion]

@Knappa Je kunt onder on_clockwise en on_anticlockwise ook conditional acties hangen. Dus wanneer rotatie clockwise, en lamp staat uit => zet lamp aan op 100%.

[Knappa]

Septillion schreef op zaterdag 18 januari 2025 @ 12:19:
@Knappa Je kunt onder on_clockwise en on_anticlockwise ook conditional acties hangen. Dus wanneer rotatie clockwise, en lamp staat uit => zet lamp aan op 100%.

Kan je me een tip geven hoe ik kan zien dat de lamp aan is? Deze is nl. niet op deze ESP aangesloten, maar op een andere. Deze is in HA terug te vinden als light.bureaulamp. Ik zal heel dit topic eens doorploegen ondertussen, aangezien de documentatie van ESPHome me een beetje op m’n honger laat op dit vlak.
Ik heb al een paar nodes gemaakt, maar die bevatten geen ‘logica’ en duiden enkel wat lichten, buttons en sensors aan.

[Septillion]

@Knappa ahhhhh, dat krijg je dus als je niet de volledige code deelt maar een snippet. Dan moet je aannames maken

Dan zou je een HA event aan de CW en CCW kunnen hangen. Dus een event template in ESPhome maken met event types CW en CCW. Dan kan je daar in HA makkelijk een automation aan breien. Eventueel zet je er in ESPhome een filter op zodat je het aantal events per seconde verlaagd.

Andere optie zou zijn om in HA dus gewoon naar de Rotary sensor waarde te kijken. En dan een automation op state change. Met een template en de from en to state van de trigger variable kan je dan checken of de waarde toenam (CW) of afnam (CCW).

[Knappa]

Septillion schreef op zaterdag 18 januari 2025 @ 21:41:
@Knappa ahhhhh, dat krijg je dus als je niet de volledige code deelt maar een snippet. Dan moet je aannames maken

Mijn oprechte nederige excuses. Het was een evenwichtsoefening om niet te veel (irrelevante) info te posten, maar toch genoeg.
Ter info, geef ik nog wat extra info mee, die ik gebruik in Node Red: de binnenkomende waarde gaat een switch binnen: bij waarde 0 wordt light.turn_off aangeroepen. Bij een andere waarde wordt de binnenkomende waarde (tussen 1 en 10) gemapt naar een waarde tussen 20 en 100. Deze wordt dan gebruikt als ‘brightness_pct’ bij het aanroepen van light.turn_on. Het intensiteitsverschil tussen 10 en 20% is nl. te klein wat mij betreft.
PS: als dit laatste off-topic is, mag je verwijderen. Het zou gewoon relevant kunnen zijn voor de volgende die iets gelijkaardigs zou willen doen.

[magnifor]

Ik heb mijn ESP8266 + DHT22 werkend, nu wil ik dit laten werken via een power bank echter is het probleem veel powerbanks na een tijdje zichzelf uitschakelen als het verbruikte power te laag is. Zijn er power banks die een always on mode hebben?

[u_nix_we_all]

@magnifor
De action had een tijd geleden van deze:

Zijn maar klein en weinig capaciteit maar blijven wel 5V geven bij laag verbruik. Ik zie ze alleen niet meer bij de Action.

Hier staan ook nog wat tips: u_nix_we_all in "Het grote ESPhome topic"

[JT]

Ik had een ESP8266 bordje met Type C, een Wemos D1 Mini (ik denk dat dit een ali kloon is) gesoldeerd aan een modbusbordje met een specifieke stekker om de omvormer uit te lezen in HA. Werkte perfect. Nu had ik een andere kloon gekocht met een uFl (zo heette dat volgens mij) aansluiting voor een externe antenne. Ik heb deze van exact dezelfde code voorzien, op dezelfde punten gesoldeerd, pin 12 was geconfigureerd voor rx en 14 voor tx. Ik krijg niks in ESPHome terug. Ik blijf de melding krijgen dat er geen antwoord komt. Kijk ik naar het rs485-bordje dan zie ik zowel tx als rx lampjes knipperen.

• Verbinding tussen ESP en RS485 doorgemeten met diode stand, 002 is de waarde voor tx en rx zo een beetje. Lijkt mij sua niks aan de hand.
• Ik heb in ESPHome ook al geprobeerd om de pinwaardes te vervangen met D5 en D6. Volgens de documentatie is dit hetzelfde als 12 en 14.
• Waardes omgewisseld (12 <>14 en D5<>D6) maar ook niks
• Draadjes opnieuw gesoldeerd

Je ne sais pas Iemand een idee hoe ik dit verder uit kan lopen?

magnifor schreef op zondag 19 januari 2025 @ 22:33:
Ik heb mijn ESP8266 + DHT22 werkend, nu wil ik dit laten werken via een power bank echter is het probleem veel powerbanks na een tijdje zichzelf uitschakelen als het verbruikte power te laag is. Zijn er power banks die een always on mode hebben?

Er zijn de nodige powerbanks die low power laden ondersteunen voor bijvoorbeeld smart watches. Ik denk dat je daar wel mee weg komt.

[ Voor 4% gewijzigd door JT op 20-01-2025 15:52 ]

[JT]

Opgelost. Het lijkt erop dat de 2 RS485-bordjes waar ik mee werkte beide kaduuk waren. Nieuw bordje genomen en alles opnieuw gesoldeerd en voila, alles werkte

[RC Stuntpiloot]

Beste Tweakers, ik ben al een paar dagen aan het tobben met een ShineWifi-X stick van Growatt om daar alternatieve software op ze zetten waarmee ik de Growatt inverter kan besturen met Home Assistant. Uitlezen ging al prima middels de Growatt server integration, maar limiteren van het vermogen of uitschakelen gaat daarmee niet.
Ik heb het geprobeerd met: https://github.com/OpenInverterGateway/OpenInverterGateway maar kreeg dat in Home Assistant niet aan de praat. Er was info zichtbaar op MQTT als ik het juiste topic afluisterde, maar daarna ben ik vastgelopen.
Ik probeer het nu via ESPHome maar daar krijg ik nog geen data mee in Home Assistant.
https://community.home-as...att-shinewifi-s/369171/10

Heeft iemand misschien een werkende yaml file waarmee de inverter ook te besturen is?

Schopje naar ESPHome topic

[ Voor 2% gewijzigd door Septillion op 26-01-2025 12:15 ]

[Patrick89]

RC Stuntpiloot schreef op zondag 26 januari 2025 @ 12:01:
Beste Tweakers, ik ben al een paar dagen aan het tobben met een ShineWifi-X stick van Growatt om daar alternatieve software op ze zetten waarmee ik de Growatt inverter kan besturen met Home Assistant. Uitlezen ging al prima middels de Growatt server integration, maar limiteren van het vermogen of uitschakelen gaat daarmee niet.
Ik heb het geprobeerd met: https://github.com/OpenInverterGateway/OpenInverterGateway maar kreeg dat in Home Assistant niet aan de praat. Er was info zichtbaar op MQTT als ik het juiste topic afluisterde, maar daarna ben ik vastgelopen.
Ik probeer het nu via ESPHome maar daar krijg ik nog geen data mee in Home Assistant.
https://community.home-as...att-shinewifi-s/369171/10

Heeft iemand misschien een werkende yaml file waarmee de inverter ook te besturen is?

YAML:

substitutions:
  device_description: Growatt Inverter
  name: growatt-inverter-5kw
  friendly_name: Growatt Inverter 5kw
  
esphome:
  name: growatt-inverter-5kw

esp8266:
  board: esp07s

# Enable logging
logger:
  baud_rate: 0

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

ota:
  - platform: esphome
    password: "123"

wifi:
  ssid: "123"
  password: "123"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Growatt-Inverter-5Kw"
    password: "123"

captive_portal:
  
web_server:
  port: 80

time:
  - platform: homeassistant
    id: homeassistant_time

output:
# Blue Led
  - id: light_bl
    platform: gpio
    pin: 16
# Green Led
  - id: light_gr
    platform: gpio
    pin: 0
# Red Led
  - id: light_rd
    platform: gpio
    pin: 2

uart:
  id: mod_bus
  tx_pin: 1
  rx_pin: 3
  baud_rate: 115200
  
modbus:
  id: modbus1
  uart_id: mod_bus
  
modbus_controller:
  - id: growatt
# the Modbus device addr
    address: 0x1
    modbus_id: modbus1
    setup_priority: -10 
    update_interval: 20s
    
number:
  - platform: modbus_controller
    name: "${friendly_name} Active Power Rate"
    id: poweroutput
    address: 3
    value_type: U_WORD
    min_value: 0
    max_value: 100
    entity_category: config

sensor:
  - platform: modbus_controller
    name: "${friendly_name} DcPower Total"
    address: 1
    register_type: "read"
    unit_of_measurement: W
    device_class: power
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} DcPower PV1"
    address: 5
    register_type: "read"
    unit_of_measurement: W
    device_class: power
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
        
  - platform: modbus_controller
    name: "${friendly_name} DcVoltage PV1"
    address: 3
    register_type: "read"
    unit_of_measurement: V
    device_class: voltage
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
    
  - platform: modbus_controller
    name: "${friendly_name} DcInputCurrent PV1"
    address: 4
    register_type: "read"
    unit_of_measurement: A
    device_class: current
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} DcPower PV2"
    address: 9
    register_type: "read"
    unit_of_measurement: W
    device_class: power
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
        
  - platform: modbus_controller
    name: "${friendly_name} DcVoltage PV2"
    address: 7
    register_type: "read"
    unit_of_measurement: V
    device_class: voltage
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
    
  - platform: modbus_controller
    name: "${friendly_name} DcInputCurrent PV2"
    address: 8
    register_type: "read"
    unit_of_measurement: A
    device_class: current
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} AcFrequency"
    address: 37
    register_type: "read"
    unit_of_measurement: Hz
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.01
  
  - platform: modbus_controller
    name: "${friendly_name} AcVoltage"
    address: 38
    register_type: "read"
    unit_of_measurement: V
    device_class: voltage
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
  
  - platform: modbus_controller
    name: "${friendly_name} AcOutputCurrent"
    address: 39
    register_type: "read"
    unit_of_measurement: A
    device_class: current
    icon: mdi:flash
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} AcPower Total"
    address: 35
    register_type: "read"
    unit_of_measurement: W
    device_class: power
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} AcPower"
    address: 40
    register_type: "read"
    unit_of_measurement: W
    device_class: power
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
    
  - platform: modbus_controller
    name: "${friendly_name} EnergyToday"
    address: 53
    register_type: "read"
    unit_of_measurement: kWh
    device_class: energy
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
    
  - platform: modbus_controller
    name: "${friendly_name} EnergyTotal"
    address: 55
    register_type: "read"
    unit_of_measurement: kWh
    state_class: total_increasing
    device_class: energy
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} EnergyToday PV1"
    address: 59
    register_type: "read"
    unit_of_measurement: kWh
    device_class: energy
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
    
  - platform: modbus_controller
    name: "${friendly_name} EnergyTotal PV1"
    address: 61
    register_type: "read"
    unit_of_measurement: kWh
    state_class: total_increasing
    device_class: energy
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} EnergyToday PV2"
    address: 63
    register_type: "read"
    unit_of_measurement: kWh
    device_class: energy
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1
    
  - platform: modbus_controller
    name: "${friendly_name} EnergyTotal PV2"
    address: 65
    register_type: "read"
    unit_of_measurement: kWh
    state_class: total_increasing
    device_class: energy
    icon: mdi:flash
    value_type: U_DWORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} Inverter temperature"
    address: 93
    register_type: "read"
    unit_of_measurement: C
    device_class: temperature
    icon: mdi:thermometer
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} Inside temperature"
    address: 94
    register_type: "read"
    unit_of_measurement: C
    device_class: temperature
    icon: mdi:thermometer
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1

  - platform: modbus_controller
    name: "${friendly_name} Boost temperature"
    address: 95
    register_type: "read"
    unit_of_measurement: C
    device_class: temperature
    icon: mdi:thermometer
    value_type: U_WORD
    accuracy_decimals: 1
    filters:
    - multiply: 0.1    

[ Voor 0% gewijzigd door Septillion op 26-01-2025 12:43 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Septillion]

@Patrick89 Het is tegenwoordig (al even) een slecht idee om friendly_name te herhalen bij de componenten. Dat zat HA er namelijk zelf al voor. Dus als je dit device nu nieuwe toevoegt heet een entity dus bijvoorbeeld "Growatt Inverter 5kw Growatt Inverter 5kw Boost temperature".

[RC Stuntpiloot]

Patrick89 schreef op zondag 26 januari 2025 @ 12:15:
[...]


[

Super, hier ga ik eens mee experimenteren!

[KabouterSuper]

Vraagje, ik heb een esp32 devboard waarmee ik met esphome de temperatuur uitlees (met een ds18b20 sensor). Nu wilde ik graag de onboard led even laten knipperen als ik de sensor uitlees. De (blauwe) led zit op gpio2, en die kan ik prima aanzetten of uitzetten, bijv afhankelijk van de temperatuur. Maar het lukt me niet om alleen tijdens het uitlezen van de sensor de led aan te zetten. Is er een manier om dat te doen?

[jj85]

KabouterSuper schreef op vrijdag 31 januari 2025 @ 09:13:
Vraagje, ik heb een esp32 devboard waarmee ik met esphome de temperatuur uitlees (met een ds18b20 sensor). Nu wilde ik graag de onboard led even laten knipperen als ik de sensor uitlees. De (blauwe) led zit op gpio2, en die kan ik prima aanzetten of uitzetten, bijv afhankelijk van de temperatuur. Maar het lukt me niet om alleen tijdens het uitlezen van de sensor de led aan te zetten. Is er een manier om dat te doen?

Dit?
https://esphome.io/compon...ndex.html#sensor-on-value

[KabouterSuper]

jj85 schreef op vrijdag 31 januari 2025 @ 09:26:
[...]

Dit?
https://esphome.io/compon...ndex.html#sensor-on-value

Aargh. Dit had ik geprobeerd, maar het was me geheel ontgaan dat mijn probeersel niet werkte vanwege een effect: pulse die niet ondersteund werd. Anyway, thanks om me te triggeren om het nog eens te proberen.

Zo werkt het prima:

YAML:

sensor:
- platform: dallas_temp
  address: 0x240000005139c728
  name: "Aanvoer groep 1"
  unit_of_measurement: "°C"
  icon: "mdi:thermometer"
  device_class: "temperature"
  state_class: "measurement"
  accuracy_decimals: 2
  update_interval: 60s
  filters:
  - skip_initial: 1
  - filter_out:
      - 85.0
  on_value:
      then:
        - switch.turn_on: s_blue_led
        - delay: 0.6s
        - switch.turn_off: s_blue_led
        - delay: 0.5s
        - switch.turn_on: s_blue_led
        - delay: 0.6s
        - switch.turn_off: s_blue_led


output:
  - platform: ledc
    id: o_blue_led
    pin:
      number: GPIO2
      inverted: false
      mode: OUTPUT

light:
  - platform: monochromatic
    id: blue_led
    output: o_blue_led
    name: "Blue led"


switch:
- platform: template
  name: "Switch Blue led"
  optimistic: yes
  id: s_blue_led
  internal: true
  turn_on_action:
        - light.turn_on: 
            id: blue_led
  turn_off_action:
    - light.turn_off: blue_led

[jj85]

KabouterSuper schreef op vrijdag 31 januari 2025 @ 13:56:
[...]

Aargh. Dit had ik geprobeerd, maar het was me geheel ontgaan dat mijn probeersel niet werkte vanwege een effect: pulse die niet ondersteund werd. Anyway, thanks om me te triggeren om het nog eens te proberen.

Zo werkt het prima:

YAML:

sensor:
- platform: dallas_temp
  address: 0x240000005139c728
  name: "Aanvoer groep 1"
  unit_of_measurement: "°C"
  icon: "mdi:thermometer"
  device_class: "temperature"
  state_class: "measurement"
  accuracy_decimals: 2
  update_interval: 60s
  filters:
  - skip_initial: 1
  - filter_out:
      - 85.0
  on_value:
      then:
        - switch.turn_on: s_blue_led
        - delay: 0.6s
        - switch.turn_off: s_blue_led
        - delay: 0.5s
        - switch.turn_on: s_blue_led
        - delay: 0.6s
        - switch.turn_off: s_blue_led


output:
  - platform: ledc
    id: o_blue_led
    pin:
      number: GPIO2
      inverted: false
      mode: OUTPUT

light:
  - platform: monochromatic
    id: blue_led
    output: o_blue_led
    name: "Blue led"


switch:
- platform: template
  name: "Switch Blue led"
  optimistic: yes
  id: s_blue_led
  internal: true
  turn_on_action:
        - light.turn_on: 
            id: blue_led
  turn_off_action:
    - light.turn_off: blue_led

Mooi!

Gebruik je Light / Switch Blue led elders nog ergens?

Je zou volgens mij regel 17 ook kunnen vervangen door
- output.turn_on: o_blue_led

YAML:

  on_value:
      then:
        - output.turn_on: o_blue_led
        - delay: 0.6s
        - output.turn_off: o_blue_led
        - delay: 0.5s
        - output.turn_on: o_blue_led
        - delay: 0.6s
        - output.turn_off: o_blue_led

En dan het hele stukje light en switch weglaten.

[Septillion]

En het stuk light.

Een output in een light in een switch is niet per se logisch.

[KabouterSuper]

jj85 schreef op vrijdag 31 januari 2025 @ 14:07:
[...]

Mooi!

Gebruik je Light / Switch Blue led elders nog ergens?

Je zou volgens mij regel 17 ook kunnen vervangen door
- output.turn_on: o_blue_led

YAML:

  on_value:
      then:
        - output.turn_on: o_blue_led
        - delay: 0.6s
        - output.turn_off: o_blue_led
        - delay: 0.5s
        - output.turn_on: o_blue_led
        - delay: 0.6s
        - output.turn_off: o_blue_led

En dan het hele stukje light en switch weglaten.

Septillion schreef op vrijdag 31 januari 2025 @ 15:56:
En het stuk light.

Een output in een light in een switch is niet per se logisch.

Goede punten, thanks. Ik heb de switch eruit gehaald en de sensor laten verwijzen naar de led. Het light gebruik ik nu nog wel om te kijken of de esp nog met ha communiceert. Maar als alles gesoldeerd is, kan deze er ook wel uit.

[stevenP]

Bij uitvallend netwerk (vooral na stroomstoring / groep die uitvalt) heb ik nu niet altijd mijn ESP's weer netjes in de lucht. Het voelt voor mij dat de esptjes die ik heb sneller booten dan mijn Unifi AP's. Of ESP dan direct de conclusie trekt dat het gekozen netwerk niet beschikbaar is, weet ik niet goed..

ik zit te lezen in de knowledge base, maar klopt het dat:

- als ik een ap als fallback heb opgezet hij hier dus inschiet ipv (blijven) zoeken naar mijn eigen netwerk?
- doordat ik geen ap_timeout gezet heb, hij na 60s dus al naar die modus schiet. Dit verhogen naar 6000s zou ervoor zorgen dat er 10min lang gezocht wordt en dán pas in AP schiet
- als alternatief, bovenstaande uitzetten en een reboot_timeout op 5min te zetten, waardoor hij na 5min disconnected gewoon gaat rebooten - en dit blijft herhalen totdat hij wél verbinding krijgt

[Dutchess_Nicole]

stevenP schreef op maandag 3 februari 2025 @ 20:07:
Bij uitvallend netwerk (vooral na stroomstoring / groep die uitvalt) heb ik nu niet altijd mijn ESP's weer netjes in de lucht. Het voelt voor mij dat de esptjes die ik heb sneller booten dan mijn Unifi AP's. Of ESP dan direct de conclusie trekt dat het gekozen netwerk niet beschikbaar is, weet ik niet goed..

ik zit te lezen in de knowledge base, maar klopt het dat:

- als ik een ap als fallback heb opgezet hij hier dus inschiet ipv (blijven) zoeken naar mijn eigen netwerk?

Hoogstwaarschijnlijk. Dit is natuurlijk te testen door een ESP-tje even van de stroom te halen en te kijken of hij inderdaad een AP aanmaakt.

- doordat ik geen ap_timeout gezet heb, hij na 60s dus al naar die modus schiet. Dit verhogen naar 6000s zou ervoor zorgen dat er 10min lang gezocht wordt en dán pas in AP schiet

6000 seconden is 100 minuten, maar verder, ja, klopt

- als alternatief, bovenstaande uitzetten en een reboot_timeout op 5min te zetten, waardoor hij na 5min disconnected gewoon gaat rebooten - en dit blijft herhalen totdat hij wél verbinding krijgt

uiteraard ook een optie. Het is maar net wat je makkelijker vindt of liever hebt.

[gastje01]

Ik probeer een DMX signaal uit mijn ESP te krijgen met behulp van een TTL naar RS485 adapter. Gebruik deze code: https://github.com/andyboeh/esphome-dmx512

Zo te zien werkt mijn config, k zie het TX lampje op de TTL converter knipperen wanneer er commando's verzonden worden, maar mijn DMX apparaat (dimpack) geeft geen knipperend DMX lampje Wat zou duiden op geen signaal. Na dit punt loop ik een beetje vast met troubleshooten. 3.3v of 5v maakt geen verschil.

Ik heb geen twisted pair gebruikt, maar een kort kabeltje van 15cm. Zou dit nog impact kunnen hebben op zo'n korte afstand?

Enige punt dat nog overblijft zou een 120Ohm weerstand zijn, aan de converter kant zit deze volgens mij al op de print volgens onderstaand schema:

[Freezhost]

Mogelijk zit ik in het verkeerde topic, maar hoe sluiten jullie de sensoren etc aan op de ESP's? In eerste instantie had ik jumper wires, maar dat was niet betrouwbaar, echt dan wel dan niet. Nu heb ik ze gesoldeerd, maar dat wordt het gelijk wat stugger allemaal.

Welk draad gebruiken jullie? En hoe doen jullie het als je meerdere sensoren hebt met de ground en 3/5 volt?

[Septillion]

@Freezhost Voor test, jumper. Als het een enkele sensor ofzo is, lekker direct solderen. En als het iets complexer is maak ik een printje. Gewoon protoprint als het snel moet en/of simpel is. En anders slinger ik Kicad aan en bestel ik wat.

[Freezhost]

Septillion schreef op woensdag 19 februari 2025 @ 09:34:
@Freezhost Voor test, jumper. Als het een enkele sensor ofzo is, lekker direct solderen. En als het iets complexer is maak ik een printje. Gewoon protoprint als het snel moet en/of simpel is. En anders slinger ik Kicad aan en bestel ik wat.

En wat voor draad gebruik je? En welke jumperwires want er is veel zooi wat slecht contact maakt.

[Septillion]

@Freezhost Gewoon goedkope. Voor wat testopstellingen heb ik daar niet zo veel problemen mee. En denk ik dat ze wat losjes zitten => prullenbak.

Voor solderen verschilt een beetje qua lengte. Maar als het er gewoon bij moet gebruik ik wat siliconen draad.

[Yelti]

Freezhost schreef op woensdag 19 februari 2025 @ 09:10:
Mogelijk zit ik in het verkeerde topic, maar hoe sluiten jullie de sensoren etc aan op de ESP's? In eerste instantie had ik jumper wires, maar dat was niet betrouwbaar, echt dan wel dan niet. Nu heb ik ze gesoldeerd, maar dat wordt het gelijk wat stugger allemaal.

Welk draad gebruiken jullie? En hoe doen jullie het als je meerdere sensoren hebt met de ground en 3/5 volt?

Ik zet de jumper cables vast met hot glue. werkt ook heel goed.

[kitao]

gastje01 schreef op zaterdag 15 februari 2025 @ 18:10:
Ik probeer een DMX signaal uit mijn ESP te krijgen met behulp van een TTL naar RS485 adapter. Gebruik deze code: https://github.com/andyboeh/esphome-dmx512

Zo te zien werkt mijn config, k zie het TX lampje op de TTL converter knipperen wanneer er commando's verzonden worden, maar mijn DMX apparaat (dimpack) geeft geen knipperend DMX lampje Wat zou duiden op geen signaal. Na dit punt loop ik een beetje vast met troubleshooten. 3.3v of 5v maakt geen verschil.

Ik heb geen twisted pair gebruikt, maar een kort kabeltje van 15cm. Zou dit nog impact kunnen hebben op zo'n korte afstand?

Enige punt dat nog overblijft zou een 120Ohm weerstand zijn, aan de converter kant zit deze volgens mij al op de print volgens onderstaand schema:

[Afbeelding]

Hi, ik heb zelf geen ESP en nooit gehad dus weet daar niks van maar ben wel bezig met Uart, Spi e.d. en hoewel ik geen direkt antwoord heb op je vraag kan ik je mogelijk wel een tip geven. Voor foutzoeken of als ik bepaalde onderdelen niet heb of gewoon voor het gemak pas ik regelmatig een simulator toe. Helaas kan ik op Proteus (demo) en op Simulide geen
https://www.ti.com/lit/ds/symlink/sn65176b.pdf
vinden dus die vlieger gaat nu niet op maar misschien kan je daar de schakeling wel opdelen of minimaliseren.
https://simulide.com/p/

Je schrijft dat je onder andere naar de led kijkt als signaal indicatie. Heb je al een logic analyzer overwogen ?
kitao in "[Discussie] Arduino-topic"
Dat zou kunnen helpen om een beter beeld te krijgen van de uitgangssignalen.

[Septillion]

@gastje01 Voor klein testje zou ik ook nog wel verwachten dat je zonder terminator weg komt maar je zou net ongeluk kunnen hebben.

Maar waar heb je de DMX print dan vandaan? En waar heel je VCC vandaan?

[gastje01]

kitao schreef op woensdag 19 februari 2025 @ 10:48:
[...]


Hi, ik heb zelf geen ESP en nooit gehad dus weet daar niks van maar ben wel bezig met Uart, Spi e.d. en hoewel ik geen direkt antwoord heb op je vraag kan ik je mogelijk wel een tip geven. Voor foutzoeken of als ik bepaalde onderdelen niet heb of gewoon voor het gemak pas ik regelmatig een simulator toe. Helaas kan ik op Proteus (demo) en op Simulide geen
https://www.ti.com/lit/ds/symlink/sn65176b.pdf
vinden dus die vlieger gaat nu niet op maar misschien kan je daar de schakeling wel opdelen of minimaliseren.
https://simulide.com/p/

Je schrijft dat je onder andere naar de led kijkt als signaal indicatie. Heb je al een logic analyzer overwogen ?
kitao in "[Discussie] Arduino-topic"
Dat zou kunnen helpen om een beter beeld te krijgen van de uitgangssignalen.

Nope, maar zo diep gaat mijn technische kennis op het gebied van electronica ook niet, waarschijnlijk kan ik daar niet veel nuttigs mee.

Septillion schreef op woensdag 19 februari 2025 @ 12:33:
@gastje01 Voor klein testje zou ik ook nog wel verwachten dat je zonder terminator weg komt maar je zou net ongeluk kunnen hebben.

Maar waar heb je de DMX print dan vandaan? En waar heel je VCC vandaan?

Het gaat om een XY-017 TTL adapter (gewoon RS485). Die heb ik getest op de 3.3v en op de VCC (5V) pin van de Wemos D1 ESP32 en een D1 8266, zelde resultaat. Deze ligt er al een tijdje en komt van een Growatt omvormger die een tik heeft gehad, mogelijk is ie gewoon stuk, heb een nieuwe besteld om te zien wat dat doet.

Het ontvangende apparaaat is een simpele 1 kanaals 10A stage-dimmer die straks een boiler element mag dimmen tussen 0-2000W op basis van mijn PV overschot. Deze heeft een snel knipperend DMX lampje wanneer er signaal binnen komt. Ik meende dat ik dit even heb zien gebeuren, maar na alle gerommel begin ik zels hier aan te twijfelen.

[kitao]

@gastje01
Ok, nou, zoals ik het lees met al de typenummers die je noemt heb je er meer kennis van als mij.
Ik dacht in eerste instantie dat je een test schakeling had, op breadboard oid omdat je naar Github verwees en jouw schema een erg basis standaard chip vertoont, de 74HC14.
https://www.ti.com/lit/ds/symlink/sn74hc14.pdf
Maar nu begrijp ik, geloof ik, dat het om hardware gaat met daarin een print dat defekt is ? In dat geval is het een stuk lastiger daar een L.A. op aan te sluiten.

[ Voor 5% gewijzigd door kitao op 19-02-2025 14:40 ]

[Barfman]

Ik kreeg net een melding van ESPHome:

code:

Please remove the `platform` key from the [esphome] block and use the correct platform component. This style of configuration has now been removed.

YAML:

esphome:
  name: ${device_name}
  comment: "${device_description}"
  platform: ESP8266
  esp8266_restore_from_flash: true
  board: d1_mini
  name_add_mac_suffix: false
  project:
    name: zuidwijk.slimmelezer
    version: "1.0"

Moet ik dan deze hele lijn verwijderen?

code:

platform: ESP8266

ESPhome is geen HA => schopje

[ Voor 3% gewijzigd door Septillion op 19-02-2025 18:28 ]

[Septillion]

@Barfman platform is geen onderdeel meet van esphome maar zelfstandig geworden.\

Aanpassen naar:

YAML:

esphome:
  name: ${device_name}
  comment: "${device_description}"
  name_add_mac_suffix: false
  project:
    name: zuidwijk.slimmelezer
    version: "1.0"

esp8266:
  board: d1_mini
  restore_from_flash: true

[Barfman]

Septillion schreef op woensdag 19 februari 2025 @ 18:27:
@Barfman platform is geen onderdeel meet van esphome maar zelfstandig geworden.\

Aanpassen naar:

YAML:

esphome:
  name: ${device_name}
  comment: "${device_description}"
  name_add_mac_suffix: false
  project:
    name: zuidwijk.slimmelezer
    version: "1.0"

esp8266:
  board: d1_mini
  restore_from_flash: true

Top bedankt voor je hulp, dacht het is HAOS gerelateerd dus vandaar dat ik het daar als vraag plaatste.
In ieder geval werkt het nu weer

[scholten45]

Hallo,
Ik ben nieuw hier in dit topic en heb een vraagje.
Ik heb homeassistant draaien met esphome, binnen esphome heb ik 2 esp8266 draaien voor een airco.
Dit werkt prima tot na de laatste update, dat wil zeggen ze werken nog steeds maar ik krijg een foutmelding bij het updaten van de esp moduels:

code:

INFO ESPHome 2025.2.0
INFO Reading configuration /config/esphome/airco-job.yaml...
INFO Updating https://github.com/fonske/MHI-AC-Ctrl-ESPHome/@master
Failed config

sensor.custom: [source /config/esphome/airco-job.yaml:168]
  
  The "custom" component has been removed. Consider conversion to an external component.
  https://esphome.io/guides/contributing#a-note-about-custom-components.

YAML:

  platform: custom
  lambda: return ((MhiAcCtrl*)id(airco_job))->get_sensors();
  sensors: 
    - name: Error code
      web_server: 
        sorting_group_id: Status
        sorting_weight: 8
    - name: Outdoor temperature
      web_server: 
        sorting_group_id: Operation
        sorting_weight: 5

Dit krijg ik als melding.
Is het nu zo dat de persoon die dit gemaakt heeft:
https://github.com/fonske/MHI-AC-Ctrl-ESPHome/
een update aan zijn kant moet doen of moet ik de confir weg halen, dan de esp modules updaten en de config weer terug zetten?

mvg jos

[ Voor 1% gewijzigd door Septillion op 20-02-2025 13:01 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[RobertMe]

scholten45 schreef op donderdag 20 februari 2025 @ 12:40:
Hallo,
Ik ben nieuw hier in dit topic en heb een vraagje.
Ik heb homeassistant draaien met esphome, binnen esphome heb ik 2 esp8266 draaien voor een airco.
Dit werkt prima tot na de laatste update, dat wil zeggen ze werken nog steeds maar ik krijg een foutmelding bij het updaten van de esp moduels:

INFO ESPHome 2025.2.0
INFO Reading configuration /config/esphome/airco-job.yaml...
INFO Updating https://github.com/fonske/MHI-AC-Ctrl-ESPHome/@master
Failed config

sensor.custom: [source /config/esphome/airco-job.yaml:168]

The "custom" component has been removed. Consider conversion to an external component.
https://esphome.io/guides...e-about-custom-components.
platform: custom
lambda: return ((MhiAcCtrl*)id(airco_job))->get_sensors();
sensors:
- name: Error code
web_server:
sorting_group_id: Status
sorting_weight: 8
- name: Outdoor temperature
web_server:
sorting_group_id: Operation
sorting_weight: 5

Dit krijg ik als melding.
Is het nu zo dat de persoon die dit gemaakt heeft:
https://github.com/fonske/MHI-AC-Ctrl-ESPHome/
een update aan zijn kant moet doen of moet ik de confir weg halen, dan de esp modules updaten en de config weer terug zetten?

mvg jos

Lijkt er op dat je deze component nu als custom component gebruikt, en die methode werkt niet meer, je moet nu een external component gebruiken (zie release notes van ESPHome, die worden niet voor niets geschreven). Als ik van die component die je gebruikt de example.yaml er bij pak staat daarin een external component. Dus ik denk dat je jouw yaml gewoon even moet syncen met de example.

Ergo: mogelijk heeft de ontwikkelaar van de component wijzigingen moeten doen zodat het blijft werken. Maar in ieder geval ben jij nu aan de beurt om weer voor de juiste config/yaml te zorgen zodat de "nieuwe" manier ook daadwerkelijk gebruikt wordt. Dit is dus geen probleem in de component (meer), maar een probleem in jouw config.

[Septillion]

@scholten45 Beide niet, je hebt wel wat meer te doen. Het hele concept van custom components stond al een tijd op de deprecated lijst en is nu werkelijk uit ESPHome. Dus platform: custom bestaat niet meer.

Je zal het om moeten zetten naar een external component. Zie in de example.yaml op die Gitbub dit ook netjes staan dus de maker is er klaar voor. Jij zal je config aan moeten passen met je huidige config en de example in de hand.

[Gizz]

Gisteren was er een live ESPHome Release Party - New Year Edition op youtube:

Zelf heb ik het niet gezien en ik heb ook geen zin om anderhalf uur aan video te kijken Om toch iets mee te krijgen heb ik de transcript van deze video laten samenvatten door ChatGPT, wellicht ook interessant voor anderen. Het lijkt voor 80% vooral terugblikken te zijn en maar een klein beetje een vooruitblik:

### **Introductie en Doel**
- De livestream werd georganiseerd door Missy (Community Manager van Home Assistant), Jesse (hoofdontwikkelaar van ESPHome), Keith (ESPHome-ontwikkelaar), en Clyde (bijdrager en specialist in displays).
- Dit was de eerste ESPHome-release van 2025 en een terugblik op de ontwikkelingen sinds de laatste livestream in juni 2024.

### **Grote Updates Sinds Juni 2024**
#### **Juli 2024**
- **Micro Wake Word**: Lokale spraakdetectie werd geïntroduceerd, zodat ESPHome-apparaten zelf spraakcommando’s kunnen herkennen zonder continue streaming naar Home Assistant.
- Dit verbeterde privacy en netwerkbelasting.

#### **Augustus 2024**
- **LVGL Display-ondersteuning**: Een grote update waarmee geavanceerde gebruikersinterfaces op ESPHome-apparaten mogelijk werden. Hiermee kunnen gebruikers touchscreens en grafische weergaven toevoegen.
- **Online Afbeeldingen**: ESPHome-apparaten kunnen nu afbeeldingen van een URL ophalen, wat dynamische UI-mogelijkheden biedt.

#### **September 2024**
- **UDP-communicatie**: Directe communicatie tussen ESPHome-apparaten zonder tussenkomst van Home Assistant werd geïntroduceerd. Dit maakt het mogelijk om bijvoorbeeld sensordata direct naar een andere ESPHome-unit te sturen.

#### **Oktober 2024**
- **Audio DAC Core**: Een nieuwe kerncomponent voor audioweergave en verwerking werd toegevoegd. Dit was een grote stap in de richting van betere audio-integratie en stemassistenten.

#### **November 2024**
- **OpenTherm-ondersteuning**: Gebruikers kunnen ESPHome nu inzetten om OpenTherm-thermostaten en verwarmingssystemen uit te lezen en aan te sturen.
- **Verbeteringen aan Bluetooth-functionaliteit**: Er kwamen nieuwe mogelijkheden voor Bluetooth-integratie, mede dankzij bijdrager "BDraco".

#### **Februari 2025 Release**
- **Audio ADC Core**: Microfoonondersteuning werd toegevoegd als tegenhanger van de DAC-component.
- **Nieuwe Media Player**: Er werd een nieuwe manier geïntroduceerd om audio af te spelen zonder afhankelijkheid van Arduino.
- **Verbeteringen aan afbeeldingen en displays**: Afbeeldingen kunnen nu efficiënter worden verwerkt en beter worden weergegeven.
- **Breaking Changes**:
- **Verwijdering van oude platformconfiguratie**: De verouderde manier om ESP-chips te specificeren in YAML werd volledig verwijderd.
- **Custom Components vervangen door External Components**: Dit maakt het eenvoudiger om externe componenten te gebruiken zonder complexe aanpassingen.
- **Verwijdering van ondersteuning voor ARMv7 in Docker**: ESPHome kan niet langer worden gecompileerd op oudere Raspberry Pi’s (bijv. Pi 2 en 32-bit Pi 3).

### **Wat brengt de toekomst?**
- **ESP32-C6**: Ondersteuning voor deze chip is in ontwikkeling. Dit model ondersteunt Zigbee en Thread, wat potentieel meer integratiemogelijkheden biedt voor ESPHome in de toekomst.
- **Mogelijke uitbreiding van Bluetooth-ondersteuning**: Er wordt gekeken naar manieren om directe ESP-naar-ESP-communicatie via Bluetooth te ondersteunen.

### **Afsluiting**
- ESPHome blijft groeien en uitbreiden dankzij bijdragen van de gemeenschap.
- Gebruikers worden aangemoedigd om Home Assistant Cloud te ondersteunen, aangezien dit ESPHome mede financiert.
- De volgende livestream wordt later aangekondigd.

Mocht iemand het wel gekeken hebben en zien dat er iets essentieels in de samenvatting ontbreekt, laat het dan vooral weten

[AUijtdehaag]

@scholten45
Dat is van mijn github.

Platform: custom is vervallen en moeten naar external components omgebouwd worden.
Dit kan even duren voordat het voor elkaar is.

Simpelste is op de vorige versie van esphome compileren
Zie ook https://github.com/ginkag...3#issuecomment-2669511186

[ Voor 26% gewijzigd door AUijtdehaag op 21-02-2025 19:44 ]

[Bockelaar]

ik weet het nog niet met deze nieuwe release. Ik heb 2 Athom Echo's draaien maar die yaml is wel een heel groot stuk veranderd. Heb er uiteindelijk een aan de praat gekregen, alleen is nu het volume van de speaker heel, heel zacht.
Ben niet heel blij met deze grote verandering waar ook nog eens niets over gedocumenteerd is, kost weer uren zoeken en debuggen... *zucht*

[Gizz]

Bij een van mijn ESPHome-bouwsels wordt de S8 niet meer uitgelezen, maar ik snap niet waarom. Het geheel ligt al twee jaar ergens boven op een kast in een projectdoosje, niemand heeft het doosje überhaupt aangeraakt En opeens werkt de S8 niet meer, terwijl de andere sensoren (BME680 en SPS30, beide via I2C) het wel gewoon doen.

Het relevante stukje in de yaml, maar dit is al jaren hetzelfde:

YAML:

uart:
  rx_pin: 16
  tx_pin: 17
  baud_rate: 9600

sensor:
  - platform: senseair
    co2:
      name: "CO2 kantoor"
    update_interval: 60s

Foutmeldingen in de logs:

code:

[14:52:38][E][uart:015]: Reading from UART timed out at byte 8!
[14:52:38][W][senseair:024]: Reading data from SenseAir failed!
[14:52:38][W][component:157]: Component senseair.sensor set Warning flag: unspecified
[14:52:38][W][component:237]: Component senseair.sensor took a long time for an operation (128 ms).
[14:52:38][W][component:238]: Components should block for at most 30 ms.

Bovenstaande krijg ik elke keer dat de S8 uitgelezen zou worden. Soms is de time out ook op een andere byte, bijvoorbeeld 12.

Heel soms (1 op de 20 keer of zo) krijg ik in plaats van bovenstaande:

code:

[14:50:38][W][senseair:032]: Invalid preamble from SenseAir! c1080000 00000000 037a9609 06

of

code:

[14:53:38][W][senseair:049]: SenseAir checksum doesn't match: 0x00!=0xE246

Wat ik heb geprobeerd:

• Alles visueel nagelopen. Ik zie wel de led in de S8 elke minuut oplichten, dus hij lijkt wel netjes te meten
• Andere Dupontkabeltjes geprobeerd
• Andere GPIO's voor UART op de ESP32 (natuurlijk ook aangepast in de yaml)
• Andere voedingen

Iemand suggesties?

[Septillion]

@Gizz Misschien eens op andere locatie? Gezien het random op een byte gebeurd lijkt me dat iets de communicatie verstoord. Dus of slechte verbinding of het oppikken van storing.

[Gizz]

@Septillion andere locatie werkte niet. Al heb ik in een andere kamer nogmaals wat dupontkabeltjes vervangen en toen werkte het wel. Toen ik echter een klein beetje tegen het doosje stootte deed opeens de BME680 het niet meer. Dus ergens zit er iets niet lekker

Het is me gelukt om alles weer bovenop de kast te leggen met alle sensoren werkend. Ooit zal ik er nog eens goed naar kijken, wellicht met een versie ESP32 met versgesoldeerde pinheaders. Maar niet vandaag

[Septillion]

@Gizz Klinkt een beetje naar wat ik hier vaker roep, Dupont is leuk om te testen maar voor permanent kan je beter een (proto) printje solderen.

[Bockelaar]

Bockelaar schreef op vrijdag 21 februari 2025 @ 20:04:
ik weet het nog niet met deze nieuwe release. Ik heb 2 Athom Echo's draaien maar die yaml is wel een heel groot stuk veranderd. Heb er uiteindelijk een aan de praat gekregen, alleen is nu het volume van de speaker heel, heel zacht.
Ben niet heel blij met deze grote verandering waar ook nog eens niets over gedocumenteerd is, kost weer uren zoeken en debuggen... *zucht*

om mezelf dan maar te helpen: de Echo's zijn natuurlijk gewoon een device in HA en dus hebben een grafisch config scherm waar je de volumeslider naar 100 kunt zetten. Die is dus met de nieuwe config default terug naar 50, en dat is dan veel te zacht,
Andere wijzigingen zijn dat de wake word engine location nu default op de Echo zit ipv in HA. Dat betekent iets met je echo config tov de vroegere.

Voor future reference, mijn config nu:

YAML:

substitutions:
  name: m5stack-atom-echo-b83020
  friendly_name:  Atom Echo Huiskamer
  micro_wake_word_model: hey_mycroft  #okay_nabu alexa, hey_jarvis, hey_mycroft are also supported

esphome:
  name: ${name}
  name_add_mac_suffix: False
  friendly_name: ${friendly_name}
  min_version: 2025.2.0

esp32:
  board: m5stack-atom
  framework:
    type: esp-idf
    version: 4.4.8
    platform_version: 5.4.0

logger:
api:
  encryption:
    key: 3l1t3-3ncrypt10n-k3y!

ota:
  - platform: esphome
    id: ota_esphome

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

captive_portal:

button:
  - platform: factory_reset
    id: factory_reset_btn
    name: Factory reset

i2s_audio:
  - id: i2s_audio_bus
    i2s_lrclk_pin: GPIO33
    i2s_bclk_pin: GPIO19

microphone:
  - platform: i2s_audio
    id: echo_microphone
    i2s_din_pin: GPIO23
    adc_type: external
    pdm: true

speaker:
  - platform: i2s_audio
    id: echo_speaker
    i2s_dout_pin: GPIO22
    dac_type: external
    bits_per_sample: 32bit
    channel: right
    buffer_duration: 60ms

media_player:
  - platform: speaker
    name: None
    id: echo_media_player
    announcement_pipeline:
      speaker: echo_speaker
      format: WAV
    codec_support_enabled: false
    buffer_size: 6000
    files:
      - id: timer_finished_wave_file
        file: https://github.com/esphome/wake-word-voice-assistants/raw/main/sounds/timer_finished.wav
    on_announcement:
      - if:
          condition:
            - microphone.is_capturing:
          then:
            - if:
                condition:
                  lambda: return id(wake_word_engine_location).state == "On device";
                then:
                  - micro_wake_word.stop:
                else:
                  - voice_assistant.stop:
            - script.execute: reset_led
      - light.turn_on:
          id: led
          blue: 100%
          red: 0%
          green: 0%
          brightness: 100%
          effect: none
    on_idle:
      - script.execute: start_wake_word

voice_assistant:
  id: va
  microphone: echo_microphone
  media_player: echo_media_player
  noise_suppression_level: 2
  auto_gain: 31dBFS
  volume_multiplier: 2.0
  on_listening:
    - light.turn_on:
        id: led
        blue: 100%
        red: 0%
        green: 0%
        effect: "Slow Pulse"
  on_stt_vad_end:
    - light.turn_on:
        id: led
        blue: 100%
        red: 0%
        green: 0%
        effect: "Fast Pulse"
  on_tts_start:
    - light.turn_on:
        id: led
        blue: 100%
        red: 0%
        green: 0%
        brightness: 100%
        effect: none
  on_end:
    - delay: 100ms
    - script.execute: start_wake_word
  on_error:
    - light.turn_on:
        id: led
        red: 100%
        green: 0%
        blue: 0%
        brightness: 100%
        effect: none
    - delay: 2s
    - script.execute: reset_led
  on_client_connected:
    - delay: 2s  # Give the api server time to settle
    - script.execute: start_wake_word
  on_client_disconnected:
    - voice_assistant.stop:
    - micro_wake_word.stop:
  on_timer_finished:
    - voice_assistant.stop:
    - micro_wake_word.stop:
    - wait_until:
        not:
          microphone.is_capturing:
    - switch.turn_on: timer_ringing
    - light.turn_on:
        id: led
        red: 0%
        green: 100%
        blue: 0%
        brightness: 100%
        effect: "Fast Pulse"
    - wait_until:
        - switch.is_off: timer_ringing
    - light.turn_off: led
    - switch.turn_off: timer_ringing

binary_sensor:
  # button does the following:
  # short click - stop a timer
  # if no timer then restart either microwakeword or voice assistant continuous
  - platform: gpio
    pin:
      number: GPIO39
      inverted: true
    name: Button
    disabled_by_default: true
    entity_category: diagnostic
    id: echo_button
    on_multi_click:
      - timing:
          - ON for at least 50ms
          - OFF for at least 50ms
        then:
          - if:
              condition:
                switch.is_on: timer_ringing
              then:
                - switch.turn_off: timer_ringing
              else:
                - script.execute: start_wake_word
      - timing:
          - ON for at least 10s
        then:
          - button.press: factory_reset_btn

light:
  - platform: esp32_rmt_led_strip
    id: led
    name: None
    disabled_by_default: true
    entity_category: config
    pin: GPIO27
    default_transition_length: 0s
    chipset: SK6812
    num_leds: 1
    rgb_order: grb
    rmt_channel: 0
    effects:
      - pulse:
          name: "Slow Pulse"
          transition_length: 250ms
          update_interval: 250ms
          min_brightness: 50%
          max_brightness: 100%
      - pulse:
          name: "Fast Pulse"
          transition_length: 100ms
          update_interval: 100ms
          min_brightness: 50%
          max_brightness: 100%

script:
  - id: reset_led
    then:
      - if:
          condition:
            - lambda: return id(wake_word_engine_location).state == "On device";
            - switch.is_on: use_listen_light
          then:
            - light.turn_on:
                id: led
                red: 100%
                green: 89%
                blue: 71%
                brightness: 60%
                effect: none
          else:
            - if:
                condition:
                  - lambda: return id(wake_word_engine_location).state != "On device";
                  - switch.is_on: use_listen_light
                then:
                  - light.turn_on:
                      id: led
                      red: 0%
                      green: 100%
                      blue: 100%
                      brightness: 60%
                      effect: none
                else:
                  - light.turn_off: led
  - id: start_wake_word
    then:
      - wait_until:
          and:
            - media_player.is_idle:
            - speaker.is_stopped:
      - if:
          condition:
            lambda: return id(wake_word_engine_location).state == "On device";
          then:
            - voice_assistant.stop
            - micro_wake_word.stop:
            - delay: 1s
            - script.execute: reset_led
            - script.wait: reset_led
            - micro_wake_word.start:
          else:
            - if:
                condition: voice_assistant.is_running
                then:
                  - voice_assistant.stop:
                  - script.execute: reset_led
            - voice_assistant.start_continuous:

switch:
  - platform: template
    name: Use listen light
    id: use_listen_light
    optimistic: true
    restore_mode: RESTORE_DEFAULT_ON
    entity_category: config
    on_turn_on:
      - script.execute: reset_led
    on_turn_off:
      - script.execute: reset_led
  - platform: template
    id: timer_ringing
    optimistic: true
    restore_mode: ALWAYS_OFF
    on_turn_off:
      # Turn off the repeat mode and disable the pause between playlist items
      - lambda: |-
              id(echo_media_player)
                ->make_call()
                .set_command(media_player::MediaPlayerCommand::MEDIA_PLAYER_COMMAND_REPEAT_OFF)
                .set_announcement(true)
                .perform();
              id(echo_media_player)->set_playlist_delay_ms(speaker::AudioPipelineType::ANNOUNCEMENT, 0);
      # Stop playing the alarm
      - media_player.stop:
          announcement: true
    on_turn_on:
      # Turn on the repeat mode and pause for 1000 ms between playlist items/repeats
      - lambda: |-
            id(echo_media_player)
              ->make_call()
              .set_command(media_player::MediaPlayerCommand::MEDIA_PLAYER_COMMAND_REPEAT_ONE)
              .set_announcement(true)
              .perform();
            id(echo_media_player)->set_playlist_delay_ms(speaker::AudioPipelineType::ANNOUNCEMENT, 1000);
      - media_player.speaker.play_on_device_media_file:
          media_file: timer_finished_wave_file
          announcement: true
      - delay: 15min
      - switch.turn_off: timer_ringing

select:
  - platform: template
    entity_category: config
    name: Wake word engine location
    id: wake_word_engine_location
    optimistic: true
    restore_value: true
    options:
      - In Home Assistant
      - On device
    initial_option: On device
    on_value:
      - if:
          condition:
            lambda: return x == "In Home Assistant";
          then:
            - micro_wake_word.stop
            - delay: 500ms
            - lambda: id(va).set_use_wake_word(true);
            - voice_assistant.start_continuous:
      - if:
          condition:
            lambda: return x == "On device";
          then:
            - lambda: id(va).set_use_wake_word(false);
            - voice_assistant.stop
            - delay: 500ms
            - micro_wake_word.start

micro_wake_word:
  on_wake_word_detected:
    - voice_assistant.start:
        wake_word: !lambda return wake_word;
  vad:
  models:
    - model: ${micro_wake_word_model}

[gastje01]

Mijn DMX bouwsel doet het inmiddels ook, de TTL naar RS485 converter had de geest gegeven (of heeft nooit goed gewerkt), nieuwe er aan klikken en direct werkt alles zoals verwacht.

Twijfel nu een beetje om er een 'mooi' printje voor te maken, of dat ik alles netjes soldeer en in een doosje druk. Ik heb verder geen ervaring met printontwerp dus ik zal het met een sleur&pleur programma moeten maken, 3 printbaantjes moet nog wel lukken.

[RobertMe]

gastje01 schreef op maandag 24 februari 2025 @ 15:49:
Mijn DMX bouwsel doet het inmiddels ook, de TTL naar RS485 converter had de geest gegeven (of heeft nooit goed gewerkt), nieuwe er aan klikken en direct werkt alles zoals verwacht.

Twijfel nu een beetje om er een 'mooi' printje voor te maken, of dat ik alles netjes soldeer en in een doosje druk. Ik heb verder geen ervaring met printontwerp dus ik zal het met een sleur&pleur programma moeten maken, 3 printbaantjes moet nog wel lukken.

ESPHome en DMX? Wat doe je daar dan mee / wat kan ESPHome met DMX?

* RobertMe heeft tijdje terug voor iemand anders iets met een Wemos + RS485 bordje + WLED gedaan voor aansturen twee LED controllers. Intussen liggen er sinds afgelopen weekend twee Athom Tech WLED controllers, maar niet helemaal tevereden (zijn 4 led strips rondom in een koof, met 2 strips per controller, controllers in twee diagonale hoeken, en met effecten zie je een kleine vertraging doordat ze over wifi in sync moeten lopen).

[gastje01]

RobertMe schreef op maandag 24 februari 2025 @ 16:05:
[...]

ESPHome en DMX? Wat doe je daar dan mee / wat kan ESPHome met DMX?

* RobertMe heeft tijdje terug voor iemand anders iets met een Wemos + RS485 bordje + WLED gedaan voor aansturen twee LED controllers. Intussen liggen er sinds afgelopen weekend twee Athom Tech WLED controllers, maar niet helemaal tevereden (zijn 4 led strips rondom in een koof, met 2 strips per controller, controllers in twee diagonale hoeken, en met effecten zie je een kleine vertraging doordat ze over wifi in sync moeten lopen).

Ik ga hem gebruiken om een ‘domme’ boiler te dimmen en er enkel mijn PV overschot in te dumpen (tot ie warm is uiteraard). Off-the shelf oplossingen worden aangeboden voor honderden euro’s terwijl ik nu voor 80 euro klaar ben, komt de TVT wel ten goede en verder was het ook een leuk knutsel project.

De reden dat ik voor DMX ben gegaan is simpelweg beschikbaarheid van (goedkope) dimmers die 10A aankunnen. Snelheid/latency heb ik niet getest, zit wel iets van vertraging in, maar dat heeft ook met het opschalen van de dimmer te maken, transition staat op 1s, geen idee hoe snel dat kan.

Ik heb er verder niet veel verstand van, maar zoals ik DMX begrijp heb je 512 kanalen waar je een waarde van 0-255 kan instellen, of je nog met de snelheid van de bus zelf kan klooien weet ik zo niet, dat is voor mijn toepassing niet nodig.

[RobertMe]

gastje01 schreef op maandag 24 februari 2025 @ 18:28:
Snelheid/latency heb ik niet getest, zit wel iets van vertraging in, maar dat heeft ook met het opschalen van de dimmer te maken, transition staat op 1s, geen idee hoe snel dat kan.

offtopic:
Latency issue zijn dus 2 WLED nodes met direct de strip er aan. De latency zal dan zitten in de wifi route waarbij de "master" een broadcast stuurt en de ander op moet reageren. De route met een zelf geknutselde DMX oplossing / hardware met dan (standaard) WLED firmware die op 2 adressen de DMX controllers aanstuurt werkte prima en latency vrij. Maar best logisch. Want gewoon 1 DMX kabel die is doorgelust tussen de twee DMX controllers. Da's zo snel als het elektrische signaal die paar meter overbrugde Wifi heen en weer via een access point gaf dan meer latency, leek het. Maar afgelopen weekend voornamelijk aangesloten en nog niet uitgebreid getest.

Maar ik wist dus uberhaupt niet dat ESPHome iets met DMX kan. RS485 ondersteuning ligt uiteraard voor de hand (en modbus is volgens mij ook RS485? dus semi een vereiste om ESPHome interessant te maken voor vele toepassingen). Maar DMX vind ik niet voor de hand liggen. Vooral gezien de semi complexiteit als je alles / meer wilt doen. Dus echt light entities aansturen met DMX etc (devices (op een "offset") kanalen (binnen het apparaat), kleuren vertalen naar kanalen, ...)

[Gondelier]

Bockelaar schreef op maandag 24 februari 2025 @ 11:59:
[...]


om mezelf dan maar te helpen: de Echo's zijn natuurlijk gewoon een device in HA en dus hebben een grafisch config scherm waar je de volumeslider naar 100 kunt zetten. Die is dus met de nieuwe config default terug naar 50, en dat is dan veel te zacht,
Andere wijzigingen zijn dat de wake word engine location nu default op de Echo zit ipv in HA. Dat betekent iets met je echo config tov de vroegere.

Voor future reference, mijn config nu:
[code=yaml]
substitutions:
name: m5stack-atom-echo-b83020
friendly_name: Atom Echo Huiskamer
micro_wake_word_model: hey_mycroft #okay_nabu alexa, hey_jarvis, hey_mycroft are also supported
[...]

@Bockelaar
Hier ben ik U heel erg dankbaar voor , Kopieeren, plakken, api veranderen en lopen als een trein.
Betr: "De future reference,voor de m5stack-atom-echo config : YAML:"
Ik had al even zitten pielen, maar kreeg te veel rode lijntjes.

Nu ben ik ook nog op zoek naar een goede .YAML voor de ESP32-S3-BOX-3
Dat durf ik nog niet aan met mijn kennis, deze staat in een ziekenboeg en moet het (altijd) doen.
Mocht hier nog iemand zijn die dat wil plaatsen heel graag.
Nogmaals Bockelaar bedankt.

[ Voor 0% gewijzigd door Septillion op 24-02-2025 19:55 . Reden: quote fix ]

[Flappie]

Ik vraag het ook even hier, had het ook al in het Home Assistant topic gevraagd maar misschien is het ook wel een ESPHome dingetje

Ik heb een ESP32 die via Modbus een kWh meter uitleest.
Als de groep waar die kWh meter aanzit eruit klapt, dan blijft ESPHome de laatste waarde blijkbaar doorsturen naar Home Assistant.

In mijn geval was dus rond 12.00 uur mijn zonnepanelen groep geklapt maar in Home Assistant krijg ik dan deze lijn:


Die vlakke blauwe lijn in het rode gedeelte bleef Home Assistant registreren terwijl er eigenlijk helemaal geen opwek was.

Iemand een idee hoe ik dit kan voorkomen?
Ik zou graag de waarde naar 0 hebben en in Home Assistant iets triggeren waarmee ik dan een notificatie naar mezelf kan sturen.

[Septillion]

@Flappie Ik zou zeggen dat ESPHome dit zou moeten doen als je offline_skip_updates instelt. Maar of de waarde dan netjes 'unknown' wordt gemaakt durf ik niet te zeggen.

Anders zou je misschien via de on_offline trigger de sensor de waarde NaN kunnen geven via id(my_sensor).publish_state().

[AlfredPteD]

Ik heb een vraag over een esphome integratie in home assistant.

Achtergrond :
Ik draai HA in een docker op een raspberryPi. Werkt prima. Ik draai ESPHome in een docker op een andere machine. Ik upload een sketch naar mijn ESP32C boardje om de modbus van de quatt-warmtepomp uit te lezen. De sketch staat in een fork : https://github.com/AlfredDelft/Quatt-sniffer/tree/main. In deze fork heb ik alleen wat sensornamen gewijzigd tov het origineel.

Alles werkt prima: de data komt met grote regelmaat HA binnenstromen.

Ik laat de data ook rechtstreeks op mqtt publiceren, in eerste instantie om te onderzoeken hoe dat werkt en wat dat oplevert. Daartoe heb ik de yaml file in ESPHome aangepast :

YAML:

mqtt:
  broker: 192.168.178.65
  topic_prefix: warmtepomp/modbus/sniffer
  log_topic: warmtepomp/modbus/sniffer/log

Ook dat lijkt goed te lopen want er komt veel data binnen op het genoemde topic. Ook voor de binary_sensors, maar die berichten bevatten geen data maar slechts onderstaand bericht. Dat lijkt op een foutmelding (standaardbericht van HA?). voorbeeld :

code:

Topic: warmtepomp/modbus/sniffer/binary_sensor/hp1_4way_valve/state
{
    "test": "default"
}

De normale sensoren leveren wel data, bv :

code:

Topic: warmtepomp/modbus/sniffer/sensor/hp1_compressor_frequency_actual/state

30

Wat kan de reden zijn dat HA, of ESPHome, dit standaardbericht voor de binary_sensors doorstuurt ?

[Flappie]

Septillion schreef op woensdag 26 februari 2025 @ 17:16:
@Flappie Ik zou zeggen dat ESPHome dit zou moeten doen als je offline_skip_updates instelt. Maar of de waarde dan netjes 'unknown' wordt gemaakt durf ik niet te zeggen.

Anders zou je misschien via de on_offline trigger de sensor de waarde NaN kunnen geven via id(my_sensor).publish_state().

Heb hier vandaag even mee gestoeid maar krijg het niet voor elkaar.
Heb nu deze code:

YAML:

modbus_controller:
  modbus_id: modbus1
  id: sdm120
  update_interval: 5s
  address: 1
  command_throttle: 50ms
  setup_priority: -10
  on_offline:
    - logger.log: "SDM120M offline! Sensoren op unavailable zetten."
    - delay: 10s
    - lambda: |-
        id(modbus_status).publish_state(false);
    - sensor.template.publish:
        id: voltage
        state: !lambda "return NAN;"
    - sensor.template.publish:
        id: frequency
        state: !lambda "return NAN;"
    - sensor.template.publish:
        id: current
        state: !lambda "return NAN;"
    - sensor.template.publish:
        id: power
        state: !lambda "return NAN;"
    - sensor.template.publish:
        id: exported
        state: !lambda "return NAN;"
    - homeassistant.event:
        event: esphome.kwh_meter_offline
        data:
          message: "De SDM120M kWh-meter is offline!"

Als de Eastron kWh meter offline gaat (stroom eraf) zie ik heel even de waardes naar NA veranderen in zowel Home Assistant als de webinterface van de ESP. Daarna zie ik weer de oude waardes terugkomen.
Alsof de template sensoren toch weer overschreven worden met de oude waardes die via modbus als laatste werden uitgelezen.

Ik krijg wel de notificatie in de logging en in Home Assistant dus de on_offline werkt wel.

Enig idee?

[ Voor 2% gewijzigd door Septillion op 01-03-2025 22:26 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[AlfredPteD]

AlfredPteD schreef op vrijdag 28 februari 2025 @ 08:38:
Ik heb een vraag over een esphome integratie in home assistant.

Achtergrond :
Ik draai HA in een docker op een raspberryPi. Werkt prima. Ik draai ESPHome in een docker op een andere machine. Ik upload een sketch naar mijn ESP32C boardje om de modbus van de quatt-warmtepomp uit te lezen. De sketch staat in een fork : https://github.com/AlfredDelft/Quatt-sniffer/tree/main. In deze fork heb ik alleen wat sensornamen gewijzigd tov het origineel.

Alles werkt prima: de data komt met grote regelmaat HA binnenstromen.

Ik laat de data ook rechtstreeks op mqtt publiceren, in eerste instantie om te onderzoeken hoe dat werkt en wat dat oplevert. Daartoe heb ik de yaml file in ESPHome aangepast :

YAML:

mqtt:
  broker: 192.168.178.65
  topic_prefix: warmtepomp/modbus/sniffer
  log_topic: warmtepomp/modbus/sniffer/log

Ook dat lijkt goed te lopen want er komt veel data binnen op het genoemde topic. Ook voor de binary_sensors, maar die berichten bevatten geen data maar slechts onderstaand bericht. Dat lijkt op een foutmelding (standaardbericht van HA?). voorbeeld :

code:

Topic: warmtepomp/modbus/sniffer/binary_sensor/hp1_4way_valve/state
{
    "test": "default"
}

De normale sensoren leveren wel data, bv :

code:

Topic: warmtepomp/modbus/sniffer/sensor/hp1_compressor_frequency_actual/state

30

Wat kan de reden zijn dat HA, of ESPHome, dit standaardbericht voor de binary_sensors doorstuurt ?

Ik kon zelf geen oplossing vinden op internet. Wel heb ik een workaround bedacht. Ik heb een aantal binary_sensors omgezet naar gewone sensors, en daarmee werkt alles weer. De mqtt-berichten hebben we een keurige waarde (0 of 1), en daarmee kan ik verder.

code:

Topic: warmtepomp/modbus/sniffer/sensor/hp1_crankcase_heater/state

0

Eigenlijk hou ik niet van workarounds, maar als het niet kan zoals het moet, moet het maar zoals het kan.

[Septillion]

@AlfredPteD Ik heb net even getest met een ESP-C3 en ESPHome 2025.2.1, en daar krijg ik gewoon netjes een topic esp-C3/binary_sensor/boot/state met daarin OFF of ON.

Met welke versie heb jij getest? En zie je die binary sensor in HA (via de api) wel werken?

[Septillion]

@Flappie Dat is wel heel bijzonder. Kan je anders eens de meter loskoppelen, gebeurd het dan ook nog?

[AlfredPteD]

Septillion schreef op zaterdag 1 maart 2025 @ 19:56:
@AlfredPteD Ik heb net even getest met een ESP-C3 en ESPHome 2025.2.1, en daar krijg ik gewoon netjes een topic esp-C3/binary_sensor/boot/state met daarin OFF of ON.

Met welke versie heb jij getest? En zie je die binary sensor in HA (via de api) wel werken?

Dank voor je reactie.

Ik moet even op zoek gaan naar het versienummer van ESPHome. Ik werk vanaf de cli waar ik het niet kon vinden, en ik heb het dashboard herontdekt. Dat is wel zo makkelijk.
* ESPHome versie : 2024.12.4

De waarden van de binary_sensors in HA zijn goed (on/off). Wat bedoel je met "... via de api..." ?

Ik laat de ESP32 rechtstreeks (dat denk ik althans) publiceren naar mijn MQTT bus. Vanuit die bus worden de devices en entiteiten gezien door HA. Op de MQTT bus zie ik dus fouten in de berichten, maar HA ziet kennelijk toch wat anders want die heeft wel de juiste waarden.

Misschien gaat de routering van berichten vanuit de ESP32 zowel naar HA als naar mijn MQTT bus. Dat zou dat iig kunnen verklaren.

Toevoeging: ik zie nu dat ik geen HA api key heb gebruikt :

code:

# Enable Home Assistant API
api:
  password: ""

[ Voor 5% gewijzigd door AlfredPteD op 01-03-2025 21:26 ]

[Septillion]

@AlfredPteD Met de API bedoel ik dus het api component. Dan heb je geen mqtt meer nodig voor HA. MQTT discovery staat standaard dan ook uit.

De password optie is overigens al een tijd deprecated en vervangen door encryption - key. Maar encryption (en password) zijn optioneel.

[jj85]

AlfredPteD schreef op zaterdag 1 maart 2025 @ 21:24:
[...]


Misschien gaat de routering van berichten vanuit de ESP32 zowel naar HA als naar mijn MQTT bus. Dat zou dat iig kunnen verklaren.

Als je mqtt en api actief hebt, dan klopt jouw bovenstaande vermoeden.
De api communiceert rechtstreeks met HA, zoals @Septillion al aangeeft.

Blijft raar dat de binary sensor in HA goed binnen komt, maar via mqtt niet goed functioneert...

Hoe ziet je mqtt stuk in de yaml configuratie eruit?

[AlfredPteD]

jj85 schreef op zaterdag 1 maart 2025 @ 22:53:
[...]

Als je mqtt en api actief hebt, dan klopt jouw bovenstaande vermoeden.
De api communiceert rechtstreeks met HA, zoals @Septillion al aangeeft.

Blijft raar dat de binary sensor in HA goed binnen komt, maar via mqtt niet goed functioneert...

Hoe ziet je mqtt stuk in de yaml configuratie eruit?

Aha, jullie noemen de sketch een api !? De api staat op de ESP32 en communiceert met de buitenwereld ? Excuses dat ik het jargon niet beheers...

YAML:

mqtt:
  broker: 192.168.178.65
  topic_prefix: warmtepomp/modbus/sniffer
  log_topic: warmtepomp/modbus/sniffer/log

Dit staat dus in de configuratiefile quatt-sniffer.yaml

[jj85]

AlfredPteD schreef op zaterdag 1 maart 2025 @ 23:02:
[...]


Aha, jullie noemen de sketch een api !? De api staat op de ESP32 en communiceert met de buitenwereld ? Excuses dat ik het jargon niet beheers...

Nee, dit stukje activeert de api met HA. Zie ook de link van @Septillion

code:

# Enable Home Assistant API
api:
  password: ""

[AlfredPteD]

jj85 schreef op zaterdag 1 maart 2025 @ 23:23:
[...]

Nee, dit stukje activeert de api met HA. Zie ook de link van @Septillion

code:

# Enable Home Assistant API
api:
  password: ""

Ja, ik moest die link nog lezen.

Als gewezen architect heb ik altijd behoefte aan plaatjes. Ik heb dit plaatje gemaakt op basis van mijn huidige kennis. api: communiceert met HA. mqtt: communiceert met mijn MQTT bus.

Mijn gevoel zegt dat er geen interactie is via api:, maar dat HA zijn info plukt uit mijn MQTT bus.
(ik zeg steeds mijn MQTT bus, omdat er wellicht in HA ook nog een bus draait.)



Klopt dit een beetje ?

[jj85]

@AlfredPteD
Jouw schema ziet er logisch uit.

Waarom vermoed je dat hij in HA aanwezig is via MQTT en niet via de API?
Kijk even waar je de ESP32 terugvindt in HA.

Via api komen de devices onder


Via mqtt komen de devices onder

[AlfredPteD]

jj85 schreef op zondag 2 maart 2025 @ 08:51:
@AlfredPteD
Jouw schema ziet er logisch uit.

Waarom vermoed je dat hij in HA aanwezig is via MQTT en niet via de API?
Kijk even waar je de ESP32 terugvindt in HA.

Via api komen de devices onder
[Afbeelding]

Via mqtt komen de devices onder
[Afbeelding]

Nou precies om wat jij hier aangeeft: bij mij staan de esphome entities onder MQTT. Het hele 'device' ESPHome staat niet meer in mijn HA. Toen ik nog geen mqtt had 'enabled' was dat wel het geval. Maar ik heb wel een paar keer wat zooi moeten ruimen in HA omdat er dingen dubbel stonden, dus misschien heb ik die wel zelf verwijderd.

[Septillion]

@AlfredPteD Als je de API en MQTT (met discovery) aan zet dat krijg je dingen dubbel ja. Dus vermoed dat je dan zelf het device via de api weggegooid hebt.

Via de API is wel de voorkeurs manier voor ESPHome. Dus als je geen andere reden hebt voor MQTT zou ik gewoon MQTT uit zetten en de API gebruiken. Zal je zelf even de retained auto discovery berichten in MQTT moeten wissen.

Voor de API zou ik dan dus wel het deprecated password omzetten in encryption. Of weglaten als je geen encryptie hoeft.

Daarna kan je het device dan handmatig via de ESPHome integratie toevoegen (Settings => Devices => Add integration => ESPHome. Waarschijnlijk zie je dan al vanzelf het device. En anders kan je daar nog handmatig op IP / mDNS naam doen.

Qua plaatje, wat doet HA direct met de CiC? En de lijntjes voor modbus en MQTT zijn natuurlijk ook tweerichtingsverkeer.

[ Voor 7% gewijzigd door Septillion op 02-03-2025 09:57 ]

[AlfredPteD]

Septillion schreef op zondag 2 maart 2025 @ 09:55:
@AlfredPteD Als je de API en MQTT (met discovery) aan zet dat krijg je dingen dubbel ja. Dus vermoed dat je dan zelf het device via de api weggegooid hebt.

Via de API is wel de voorkeurs manier voor ESPHome. Dus als je geen andere reden hebt voor MQTT zou ik gewoon MQTT uit zetten en de API gebruiken. Zal je zelf even de retained auto discovery berichten in MQTT moeten wissen.

Voor de API zou ik dan dus wel het deprecated password omzetten in encryption. Of weglaten als je geen encryptie hoeft.

Daarna kan je het device dan handmatig via de ESPHome integratie toevoegen (Settings => Devices => Add integration => ESPHome. Waarschijnlijk zie je dan al vanzelf het device. En anders kan je daar nog handmatig op IP / mDNS naam doen.

Qua plaatje, wat doet HA direct met de CiC? En de lijntjes voor modbus en MQTT zijn natuurlijk ook tweerichtingsverkeer.

Dat verklaart het wel zo'n beetje. Ik had alles al draaiende via HA. Maar HA is voor mij een prima systeem met veel outputmogelijkheden, maar het past niet bij mijn andere registraties van weerstation, slimmemeter en zonnepanelen. Daarom heb ik een eigen omgeving met PostgreSQL waarin ik de data wil hebben. Vandaar dit experiment via MQTT.

Ik ben zeker onder de indruk van HA, ik ken pas 1% van het systeem, maar ik heb toch er een gevoel bij van een black box.

HA haalt de json-feed op van de CiC.

Ik begrijp van modbus dat ie een vraag moet stellen, en dat het device dan antwoord geeft. dat zou je als twee-richtingsverkeer kunnen zien, maar er gaat slechts informatie van de CiC naar het ESP32 board en niet v.v. Tenzij je schrijf-commando's bedoelt, maar die heb ik niet geïmplementeerd. Vandaar een pijltje met slecht één richting.

[AlfredPteD]

@Septillion en @jj85
Ik heb het lek gevonden. Ik draai als vele jaren een mqtt-monitor, die ik indertijd zelf in elkaar het gezet. Dat werkte altijd prima. Enkele jaren geleden had ik problemen met sonos2mqtt en heb die monitor even snel aangepast, en kennelijk niet goed getest. Je voelt m al aankomen: de melding van de default message kwam uit mijn eigen systeem. Het had dus niks met HA of ESPHome te maken.

Het lek is gedicht, en getest. De binary_sensors geven nu keurig de waarden "ON" of "OFF" weer.

Dank voor jullie reacties en excuses voor de onrust.

Nu nog de workaround terugdraaien...

[Eraser127]

Ik heb in ESPHome Builder een Wemos D1 mini met modbus die m'n WTW bestuurt. Nu is het platform iets
veranderd en wilde ik dit aanpassen in m'n config file, de oude code werkt nog wel. Nu kan ik de nieuwe code niet uploaden.
Oud:

YAML:

substitutions:
  name: brink
  friendly_name: ${name}
  
esphome:
  name: ${name}
  platform: ESP8266
  board: d1_mini

Nieuw wel werkend:

YAML:

esphome:
  name: brinkflair300
  comment: WTW ESP modbus controller
  area: Zolder
  
substitutions:
  name: brink
  friendly_name: ${name}
  
esp8266:
  board: d1_mini

Nu krijg ik de volgende foutmelding bij het uploaden:
[...]

Edit: Ik moet beter de documentatie lezen

[ Voor 66% gewijzigd door Eraser127 op 05-03-2025 19:55 ]

[jgsr]

Ok en wat was het probleem? Ter lering voor anderen?

[AlfredPteD]

Eraser127 schreef op dinsdag 4 maart 2025 @ 21:28:
Ik heb in ESPHome Builder een Wemos D1 mini met modbus die m'n WTW bestuurt. Nu is het platform iets
veranderd en wilde ik dit aanpassen in m'n config file, de oude code werkt nog wel. Nu kan ik de nieuwe code niet uploaden.
Oud:

YAML:

substitutions:
  name: brink
  friendly_name: ${name}
  
esphome:
  name: ${name}
  platform: ESP8266
  board: d1_mini

Nieuw wel werkend:

YAML:

esphome:
  name: brinkflair300
  comment: WTW ESP modbus controller
  area: Zolder
  
substitutions:
  name: brink
  friendly_name: ${name}
  
espressif8266:
  board: d1_mini

Nu krijg ik de volgende foutmelding bij het uploaden:
[...]

Edit: Ik moet beter de documentatie lezen

Ik moet zeggen dat ik hier niet veel kennis van heb, maar wat ik zie in de errorlog, is dat je een onderdeel mist. Volgens mij bestaat dat onderdeel niet. Volgens de documentatie zou je voor dat onderdeel esp8266 moeten invullen (regel 10 in je nieuwe yaml file)

espressif8266 => esp8266

[Eraser127]

@jgsr @AlfredPteD Ik had in de yaml idd geen esp8266, maar espressif8266 neergezet. Ik had het alleen nog verkeerd in de bovenstaande post gezet, dus deze even aangepast zodat anderen dit ook duidelijk hebben.

[AlfredPteD]

Eraser127 schreef op woensdag 5 maart 2025 @ 20:00:
@jgsr @AlfredPteD Ik had in de yaml idd geen esp8266, maar espressif8266 neergezet. Ik had het alleen nog verkeerd in de bovenstaande post gezet, dus deze even aangepast zodat anderen dit ook duidelijk hebben.

En werkt het nu ?

[Eraser127]

Zeker, draait gewoon weer als vanouds

[hansvk]

Ik heb een Waveshare 7.5 inch E-paper (V2). Nu probeer ik om hiermee sensorwaarden weer te geven en deze via partial refresh te laten updaten. Ik heb al veel gezocht naar code en voorbeelden maar het lukt me niet. Met wat ik probeer ververst het scherm steeds geheel met de bekende flikkering.

Nu wil ik he simpel houden als test om alleen tijd weer te geven, met als uitgangspunt:

YAML:

time:
  - platform: homeassistant
    id: homeassistant_time

display:
  - platform: waveshare_epaper
    cs_pin: GPIO17
    dc_pin: GPIO16
    busy_pin:
      number: GPIO25
      inverted: true
    reset_pin: GPIO26
    reset_duration: 2ms
    model: 7.50inv2p
    id: ePaper
    full_update_every: 60
    update_interval: never
    lambda: |-
      it.printf(10, 30, id(Arialn), "Tijd: %s", id(homeassistant_time).now().strftime("%H:%M").c_str());

Op https://esphome.io/components/display/waveshare_epaper.html wordt ik ook niet wijzer.

Wie kan mij op weg helpen?

[ Voor 0% gewijzigd door Septillion op 12-03-2025 16:57 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[jgsr]

hansvk schreef op woensdag 12 maart 2025 @ 16:04:
Ik heb een Waveshare 7.5 inch E-paper (V2). Nu probeer ik om hiermee sensorwaarden weer te geven en deze via partial refresh te laten updaten. Ik heb al veel gezocht naar code en voorbeelden maar het lukt me niet. Met wat ik probeer ververst het scherm steeds geheel met de bekende flikkering.

Nu wil ik he simpel houden als test om alleen tijd weer te geven, met als uitgangspunt:

code:

time:
  - platform: homeassistant
    id: homeassistant_time

display:
  - platform: waveshare_epaper
    cs_pin: GPIO17
    dc_pin: GPIO16
    busy_pin:
      number: GPIO25
      inverted: true
    reset_pin: GPIO26
    reset_duration: 2ms
    model: 7.50inv2p
    id: ePaper
    full_update_every: 60
    update_interval: never
    lambda: |-
      it.printf(10, 30, id(Arialn), "Tijd: %s", id(homeassistant_time).now().strftime("%H:%M").c_str());

Op https://esphome.io/components/display/waveshare_epaper.html wordt ik ook niet wijzer.

Wie kan mij op weg helpen?

Probeer eens 'datetime' ipv time. Dus id: datetime