Adding First Z-Wave Devices (using Aeotec Z-Stick 7)

Okay, that makes sense and I can do that. I’ll check on what I need to do for the key.

I don’t think the lock even thinks it’s enrolled. If it requires secure inclusion, that would make sense - and it would also most likely mean the lock doesn’t even think it’s enrolled or otherwise related to that instance of HA.

I didn’t expect that to, but I did unplug the Z-Stick for another reason: I can’t unenroll a darn thing! I can’t unenroll the two instances HA and the Z-Stick created when I tried to enroll the lock. I thought maybe if I unenrolled the Z-Stick, it would drop the whole network - but I couldn’t unenroll the Z-Stick because HA could still ping it. So I pulled the Z-Stick out and tried again. HA could still ping the Z-Stick at that point. (So there must be a battery in it or something - a backup or standby system?)

The problem is I can’t remove ANYTHING from the Z-Wave network. It can’t unenroll the two instances of the lock, node_2 and node_3. I get an error message when I try to remove either one (mentioned it upthread) and I can’t remove the Z-Stick.

I’ve created a new HAOS image on a new USB drive and I’m going to see what happens there. I’ve looked for other threads on removing Z-Wave devices that wouldn’t remove and it looks like it’s a mess. I’m just glad I ran into this NOW, before I had 20 items on that network! If this works, I’m still going to want to know how to remove a healthy node or an unresponsive one.

And it just hit me - I don’t think the lock has any info on the Z-Stick or my HA instance. If it were at all enrolled as node_2, I don’t think it would have created a node_3.

If it’s like the Gen5 stick then yes it does have a battery in it. With ZWave the node list is actually stored on the stick / controller. All Home Assistant or any other control system you use is doing is grabbing the node list from the stick, and then interviewing each node to find out about it’s capabilities etc - which it saves to cache so that future startups are quicker. The chances are that the node is in a weird state where the stick thinks it is included but the node does not. I would suggest a factory restore of the Stick. It doesn’t look like the ZWaveJS Server addon currently does generate a S2 key so you will need to do this and restart the addon.

Edit to add: The reason the stick has a battery in it - is so that you can unplug it, walk right up to the device you want to include and press the button on the stick for a few seconds. Now you can put the node in to inclusion mode and with the stick right next to it, that will happen quite quickly. You can then put the stick back in to the USB port, (probably) restart the add-on and let the interviewing process finish. You will need to wake up battery powered devices in order for the interview to complete.

Overall: Fixed it the hard way - and I wouldn’t have done this if I had more devices or automations or scenes set up. I made a new image and put it in a different Pi (which was convenience more than anything - I have a Pi in my Elecrow laptop I use for testing, so I just pulled stuff out of there and put it in the other Pi). It started up okay and I went through the beginning configuration. When it came to Z-Wave, I went in and manually added Z Wave JS. It wanted to add the Z-Stick at the same time, so I let it. During that process it asked for the Z-Wave network key. So I spent time Googling, found the terminal/ssh app, found that the key was not yet generated, so just let it add the Z-Stick without it.

(Note: This is something I’m putting in some setup notes as suggestions for setup issues in general.)

It installed the stick, but I found that three devices for Z Wave JS were’t enabled and I enabled them personally. When done, I checked the files again and the network key was generated and in place. Also, at this point, the node_2 and node_3 were seen as part of the network, but this time I was easily able to remove them from the network. First part of problem (removing the bad nodes) solved!

I had problems getting the mobile app to connect with HA again (and some notes on that, too). I did get it to connect, so I took it to the door with the lock and this time I used Secure Inclusion. It took time, but it worked. So second and last part of the problem solved!

Also another note I’m going to add for HA devs: The Schlage lock manual says NOTHING about secure integration. It would be nice if HA could somehow detect if a device requires it, or maybe if it can recognize a failure and ask to try again with secure inclusion if there’s a chance that’s the reason for failure.

That’s what I was thinking. I had read up on how the Gen5+ worked when I was looking for a stick. It took me a while to compare the two and I wondered why the Gen5+ had the button for easy inclusion like that and the 7 didn’t - until I read more about it. The Z-Stick 7 definitely has a battery in it, or at least some kind of non-volatile RAM.

Yeah according to the official comparison guide on their own site - it doesn’t have a battery: https://aeotec.com/z-wave-usb-stick/z-stick-7-vs-z-stick-gen5.html

It will definitely have flash memory though, because it needs to remember the nodes it knows. As you have already established, you can take the USB stick and plug it in to any device and with the right software, talk to the ZWave network (though it won’t do a lot, if you don’t have the same network key, that you added devices with).

When I first read that, this afternoon, I thought, “That makes sense. All it needs is flash memory to keep track of the devices.” But I’ve been thinking about it. When I had tried almost everything else - other than starting fresh, I had no luck. As an almost last-ditch attempt, I shut down HA, pulled the Z-Stick, then restarted it and tried to remove the Z-Stick as a device. HA wouldn’t let me, saying it could still ping the Z-Stick. At that point, it (the Z-Stick) was out of the Pi and not hooked up to anything.

So somehow, when disconnected from everything, it was still responding to a ping. I don’t know what was going on - just reporting what I saw.

Yeah, that’s some sort of glitch on the ZWaveJS software. Whether the Gen7 or the Gen5, it won’t respond to a ping when it is unplugged - no ZWave battery device will respond to a ping while it is asleep, otherwise the battery wouldn’t last very long at all.

One of the biggest problems with ZWave, is that the stick is in control, and the software talking to the stick - is left to the mercy of the stick. So for example, if you have a busy network, and communication fails with a node on the network a number of times, the STICK will mark the node as dead, at this point it doesn’t matter how many times the software tries to revive the node, the STICK will simply drop any attempts to communicate with what it considers to be a dead node. If the node is woken up, or made to transmit a ZWave message (for example turning a wall switch on) the stick, will temporarily mark the device as alive again, until the next time it misses a communication. The only reliable way to recover from this state, is to pull the stick out for a few seconds so it loses power, and then plug it back in (just rebooting the machine does not work, because the USB device stays powered)

So ZWave is a more complicated beast to troubleshoot than say Zigbee.

We built our house in 2017. I was on the site almost every single day, watching the contractors and doing a lot of site work. (The driveway is 1/3 of a mile to the house and 1/2 mile total, including going to the barn, and there was a lot of landscaping and other work to do with a tractor, chainsaw, and other outdoor tools!) Also, the new house is 45 minutes away from my old house, so those were long days.

That’s when I was researching home automation and, at the time, Z-Wave looked pretty good for several reasons. One was that it was not a protocol just one company was using. (Insteon, at the time, was all Insteon. If any other companies were making Insteon compatible devices, it was just a very, very few. Z-Wave was pretty well established and used by a number of companies.) There were other factors and I don’t remember why I didn’t start using Zigbee. I got an ISY-994i hub from Universal Devices, which works, but their Admin interface is kludgy. It does work with Z-Wave and with Insteon (if you buy a PLM to connect to it). At this point, due to Z-Wave upgrades, if I keep it working, I need to put in an upgraded Z-Wave board. (And, sadly, I realized that I had many more Insteon devices than I thought - Insteon seems stubborn sometimes!)

I was thinking of keeping that (the ISY) going, but once I started with Raspberry Pis for other uses, people told me about how well it worked for home automation and Home Assistant seems to leave Universal Devices way behind. I can use one HA instance to control wifi, Z-Wave, Insteon, Zigbee, and more. HA is much more versatile - it’s just taking me time to learn a new system.

I’m going to re-evalute some of my choices. I still have a lot of dimmers I haven’t installed yet that I’m going to use, but I still need fan controls for my ceiling fans and other devices. With something like HA, I’m glad I can use a lot of different systems with one hub.

I’m in much the same position. My entry in to home automation started with 433MHz sockets and a remote control. Then I discovered that with the USB tellstick I could send the on and off commands to the sockets without the remote control. Next came domoticz and the RFXTRX433 usb stick from RFXComm which allowed us to control the sockets and also receive data (the tellstick didn’t receive it was transmit only). Suddenly we could get data from our weather sensors and the electric meter for example. This was great but there was one downside… The 433MHz sockets, are receive only - so there is no confirmation that the command was actually received - and depending on humidity, air pressure, time of day, what direction the wind was blowing, how many fingers you had crossed etc sometimes the command did not get received.

So it was fine to look at how to fix the problem, and ZigBee didn’t really seem to be on the scene that I remember. So ZWave was the only way to go.

Initially, it was rubbish. Nodes kept being marked as dead. Heals weren’t working. Restarts took about 30 minutes to get the network talking again. But some well timed offers online for ZWave lightbulbs and ZWave sockets helped to stabilise the mesh (which I have to admit, given it is spanning 2 buildings, is rock steady reliable) - but yeah, it took putting a lot of mains powered devices in to make the system reliable.

Now that ZigBee is good, and much much cheaper, I was lucky that another well timed offer of packs of 2 ZigBee lightbulbs helped to jumpstart the ZigBee mesh :yum:

@mobile.andrew.jones : I remember in one thread you mentioned using GoControl thermostats. While I’m rather miffed I couldn’t get help from them to find out if I could replace parts on mine, I still have some working thermostats of theirs that are going flakey. I go into what’s wrong in another post I just put up. I’m having serious problems getting anything to work.

Could you look at this post and see if you have any insight into dealing with the GoControl thermostats? At this point, only two locks are working for me and I’m trying to find some way to get HA working at any basic level.

Sorry, I think you have the wrong person. I don’t have GoControl thermostats. I use Schedy in AppDaemon to automatically control my heating target, and Zigbee temperature sensors with a min_max sensor to get the average temperature of the house.

Also had a quick look at the thread - I see you say you are using the Gen 7 stick with a Pi4, this is a known bad combination. The Pi4 and the Gen 7 apparently don’t get on well. It’s something to do with interference from the Pi4’s USB port.

Wow. That’s the first response to anything I’ve had in a few days and it’s right on target for what I’m doing. I wonder if that could be causing problems with the Insteon stick as well. But immediately, that gives me several things to try:

  1. Plug it in a USB hub - that might distance it enough or it might mean a signal without the issues that get in the way.
  2. Change over to a Pi 3 for HA. (Have to check if that’s doable.)
  3. Switch to a Zooz Z-Stick, since I have some on hand. (Only problem - their size! Can’t plug it in with something in the port beside it.)

You may be the wrong person for the GoControl issue, but I’m glad I tagged you - you’ve given me something to work with. Also, I may end up looking at Zigbee and I’ll remember Schedy. I’m not thrilled with GoControl at this point.

This is the recommended first step, getting the stick a reasonable distance away from the PI, say 30cm - 1 meter. It is known to make a massive difference.

As for your general ZWave issues, my ZWave was always unreliable, until I took advantage of some offers on ZWave lightbulbs and sockets. This seriously stabilised the mesh and it’s been rock solid for nearly 2 years now.

As for Schedy - it’s YAML so you should be able to read what is going on here - but have a quick look at my config and you will see why I love it:

schedy_heating:  # This is our app instance name.
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat

  rooms:

    house:
      actors:
        climate.house:
      rescheduling_delay: 120
      watched_entities:
        - "input_boolean.heating_night_mode"
        - "input_boolean.home_state_home"
        - "sensor.cc_outside_temperature"
#        - "sensor.cc_30_min_gust"
        - "sensor.cc_rain_rate"
        - "input_boolean.heating_eco_mode"
        - "input_boolean.andy_is_sleeping"
        - "sensor.zigbee_bedroom_temperature_temperature"
        - "sensor.livingroom_temperature_temperature"
      friendly_name: House
      schedule:
        - v: 18.5
          rules:
            - x: "Add(-0.2) if is_on('input_boolean.heating_eco_mode') else Next()"
            - x: "Add(-0.2) if is_on('input_boolean.heating_night_mode') else Next()"
            - x: "Add(-0.1) if is_off('input_boolean.home_state_home') else Next()"
#            - x: "Add(+0.1) if float(state('sensor.cc_30_min_gust')) > 35 else Next()"
            - x: "Add(+0.025) if (float(state('sensor.cc_outside_temperature')) < 15.1 and float(state('sensor.cc_rain_rate')) > 0) else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < -9.9 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < -4.9 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 0.1 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 5.1 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 10.1 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 14.1 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 30.1 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 24.9 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 22.9 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 21.9 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 20.9 else Next()"
            - x: "Add(-0.1) if float(state('sensor.cc_outside_temperature')) > 16.8 else Next()"
            - x: "Add(+0.2) if float(state('sensor.livingroom_temperature_temperature')) < 17.5 and (time.hour < 23 and time.hour > 11) else Next()"
            - x: "Add(+0.2) if float(state('sensor.zigbee_bedroom_temperature_temperature')) < 17.4 and (time.hour < 9 or time.hour > 21) else Next()"
            - x: "Postprocess(lambda result: round(result, 1))"
            - { v: 18.4, start: "00:00", end: "01:00" }
            - { v: 18.2, start: "01:00", end: "02:00" }
            - { v: 18.0, start: "02:00", end: "03:00" }
            - { v: 17.8, start: "03:00", end: "04:00" }
            - { v: 17.7, start: "04:00", end: "05:00" }
            - { v: 17.6, start: "05:00", end: "06:00" }
            - { v: 17.7, start: "06:00", end: "07:00" }
            - { v: 17.8, start: "07:00", end: "08:00" }
            - { v: 17.9, start: "09:00", end: "10:00" }
            - { v: 18.0, start: "10:00", end: "10:30" }
            - { v: 18.1, start: "10:30", end: "11:00" }
            - { v: 18.2, start: "11:30", end: "12:00" }
            - { v: 18.3, start: "12:00", end: "12:30" }
            - { v: 18.4, start: "12:30", end: "13:00" }
            - { v: 18.5, start: "13:00", end: "14:00" }
            - { v: 18.6, start: "14:00", end: "15:00" }
            - { v: 18.7, start: "15:00", end: "16:00" }
            - { v: 18.8, start: "16:00", end: "18:00" }
            - { v: 18.9, start: "18:00", end: "20:00" }
            - { v: 18.8, start: "20:00", end: "21:00" }
            - { v: 18.7, start: "21:00", end: "22:00" }
            - { v: 18.6, start: "22:00", end: "23:00" }
            - { v: 18.5, start: "23:00", end: "00:00" }

    attic:
      actors:
        climate.attic_fans:
          hvac_mode_on: cool
      schedule:
        - v: 17.5
          start: "08:00"
          end: "22:00"
        - v: "OFF"
      friendly_name: Attic

The heating target is changed automatically based on time of day, but also other conditions, like the outside temperature.

Do you know much about how HA handles thermostats? I posted about an issue with my thermostats. Now I realize it might be a Z-Wave issue due to the interference, but I’m wondering about how HA handles the climate and thermostat issues overall.

If you can’t answer this, no problem, but I figure it won’t hurt to ask!

My thermostat has a built in range of 3° minimum between heating and cooling temp. So if I set the cooling at 70°, the heating has to be 67° or lower. I can set both through HA (when it all works), but I also see “Target Temperature” as an option. The thermostat itself doesn’t use that. I’m wondering if HA is smart enough that if I set a Target Temp, it’ll monitor the thermostat and temperature regularly and change the heating and cooling temps as needed or will directly control the thermostat in some other way to keep it at the target temp.

Do you know anything about that?

The target temperature is the temperature you set it to. But with the likes of my thermostat because it is a Generic one that just has a temperature sensor entity that it monitors and a switch entity that it controls, I also have a hystersis (I can’t spell it lol) for below and above the temperature. So it’s basically replicating what your thermostats manage themselves.

If I set my target to 18.5C, the heating will come on if it falls below 18.2C and will switch off after it reaches 18.9C.

So HA will do the monitoring and turning on heating or cooling as needed? In other words, it can take over the function of the thermostat itself?

With my old ISY system, I was eventually planning to write a Python script to handle that. During the summer and winter, it’s easy to just leave one set of automations running, since it’s either heating or cooling and I can just allow time for things to heat up or cool down. As spoiled or coddled as it sounds, 3°, on some days, can make the difference between comfortable and sleeping or sweating and not sleeping. I was planning on writing a script to focus on a range and to work with that 3° range on the thermostat and adjust it up or down as needed.

If HA can do that, then that saves me a good amount of work - providing I can get all the other things working!

1 Like

Yes, I just have a one wire relay board connected to the boiler, and a generic thermostat in home assistant, here is my thermostat in Home Assistant:

climate:
  - platform: generic_thermostat
    name: House
    heater: switch.house_boiler
    target_sensor: sensor.average_house_temperature
    min_temp: 14
    max_temp: 25
    min_cycle_duration:
      minutes: 15
    initial_hvac_mode: "heat"
    away_temp: 16.5
    cold_tolerance: 0.3
    hot_tolerance: 0.3
    keep_alive:
      minutes: 5
    precision: 0.1

As you can see the tolerance for hot and cold is what controls the hysteresis - this is everything Home Assistant needs.

As for Schedy, creating a schedule for summer and winter is very easy and covered in the documentation: The Basics: Static Schedules — hass-apps 0.20200319.0 documentation scroll down to “rules with sub schedules”. Schedy is very easy to use, and as long as you can provide HA with a sensor that is reporting the current temperature in the house, and point it at a switch it can turn on and off - then HA could take over the role of the Thermostat completely.

EDIT:
Here is cooling:

climate:
  - platform: generic_thermostat
    name: Attic_Fans
    heater: switch.aud_attic_fans
    target_sensor: sensor.auditorium_attic_temperature
    min_temp: 14
    max_temp: 40
    min_cycle_duration:
      minutes: 30
    initial_hvac_mode: "cool"
    cold_tolerance: 0.5
    hot_tolerance: 0.5
    target_temp: 16
    ac_mode: true
    precision: 0.1

That’s what I call a “Pondering Post.” I’m going to have to take some time to go over it and “ponder” on it. (Then I can say, “Pinky, are you pondering what I’m pondering?”)

When you talk about one-wire, do you mean the one-wire input on the Pi, or do you mean that’s how the thermostat connects to the HVAC system?

I did see a write-up somewhere on the internet (I’m sure I kept the link) where someone replaced his thermostat with a Raspberry Pi. That was before I was reviewing and checking out HA, so he might have even been using HA as part of that setup. I like that a Pi can do so many things. What frustrates me is that the Pi, itself, is $30-$35US, but by the time I get heatsinks, a case, and a power supply, it’s about $100US. I’m looking into Pi Zero for some uses. You can get them with the pins soldered in place for a pretty low price. Something like that can replace simple sensors for a decent price.

The one wire system, which the Pi can certainly join, is technically a 2 wire system, because there is a ground wire too. But the data and power can run down the same wire.

Our 1 wire system is actually running on Ethernet cable, because it spans 2 buildings. We could have used a Pi with a USB 1wire adaptor, but this was before things like that because popular. So we used an Embedded Systems One Wire Ethernet Server ( 3 channel ) it looks like this https://www.amazon.com/Embedded-Data-Systems-OW-SERVER-Ethernet/dp/B00S8SADV2

And then we have Temperature sensors across the Theatre on the 3 channels. One channel is all the theatre, one channel is the cafe and the foyer. The last channel is for the house - but really only has an 8 channel relay board, and a few temperature sensors on it. One of the temperature sensors is taped to the outgoing heating pipe from the boiler so that we can have a template sensor that turns on when the temperature of the pipe goes above a level, and then I have an alert if the heating switch has been turned on for 5 minutes, but the temperature of the water pipe has not gone above the threshold. Because it means either the boiler pressure is too low, or there is some other problem with the boiler.

The even cheaper way of doing temperature sensing - and we have 3 of them -
get ESP8266 boards ( commonly called NodeMCU ) Wire a DS18b20 to them. ESP Home built in to Home Assistant, will take you the rest of the way.

Here is an example I use, because of where it is situated, I also added a reed sensor so that we have a door contact sensor too.

substitutions:
  device_name: livingroom_thermo
  room_name: living_room
  light_level: '8.5'
  door_room_name: store_room
  thermo_light_switch: switch.store_room
  light_id: 'light.smart_led_light_bulb_level_7'
  dev_ip: '192.168.2.60'
  
esphome:
  name: ${device_name}
  platform: ESP8266
  board: nodemcuv2

wifi:
  ssid: 'DH-JM'
  password: !secret wifi_password
  domain: '.nptohc.co.uk'
  manual_ip:
    static_ip: ${dev_ip}
    gateway: 192.168.2.254
    subnet: 255.255.255.0
api:
  password: !secret api_password
  reboot_timeout: 15min

# Enable logging
logger:
  level: WARN
time:
  - platform: homeassistant
    id: homeassistant_time
    timezone: 'Europe/London'
    on_time:
      - cron: '0 0 * * * *'
        then:
          - script.execute: status_update
ota:
  password: !secret ota_password
sun:
  latitude: 55.70636
  longitude: -2.46281
dallas:
  - pin: D1
    update_interval: 15s
  
binary_sensor:
  - platform: template
    name: "${room_name} daytime"
    id: ${room_name}_thermo_daytime
    lambda: |-
      if (id(sun_elevation).state < ${light_level}) {
        return false;
      } else {
        return true;
      }
  - platform: gpio
    pin:
      number: D2
      mode: INPUT_PULLUP
      inverted: True
    name: "${door_room_name} door"
    id: "${device_name}_door"
    device_class: door
    on_multi_click:
      - timing:
          - ON for at most 3s
          - OFF for at most 3s
          - ON for at least 0.2s
        then:
          - script.execute: door_override_update
          - homeassistant.service:
              service: light.turn_on
              data:
                entity_id: ${light_id}
      - timing:
          - ON for at least 3.1s
        then:
          - script.execute: door_update
          - if:
              condition:
                - binary_sensor.is_off: ${room_name}_thermo_daytime
                - binary_sensor.is_on: ${device_name}_door
              then:
                - homeassistant.service:
                    service: light.turn_on
                    data:
                      entity_id: ${light_id}
      - timing:
          - OFF for at least 3.1s
        then:
          - script.execute: door_update
      
switch:
  - platform: gpio
    pin:
      number: D6
      mode: OUTPUT
      inverted: True
    name: "thermo_status_led"
    id: ${device_name}_thermo_status_led
  - platform: gpio
    pin:
      number: D7
      mode: OUTPUT
      inverted: True
    name: "boiler_status_led"
    id: ${device_name}_boiler_status_led
  - platform: gpio
    pin: 
      number: D4
      mode: OUTPUT
      inverted: True
    id: status_led
    name: "status_led"
    internal: true
    
script:
  - id: status_update
    then:
      - switch.turn_on: status_led
      - delay: 300ms
      - switch.turn_off: status_led
  - id: door_update
    then:
      - switch.toggle: ${device_name}_thermo_status_led
      - delay: 150ms
      - switch.toggle: ${device_name}_thermo_status_led
      - delay: 150ms
      - switch.toggle: ${device_name}_thermo_status_led
      - delay: 150ms
      - switch.toggle: ${device_name}_thermo_status_led
  - id: door_override_update
    then:
      - switch.toggle: ${device_name}_boiler_status_led
      - delay: 150ms
      - switch.toggle: ${device_name}_boiler_status_led
      - delay: 150ms
      - switch.toggle: ${device_name}_boiler_status_led
      - delay: 150ms
      - switch.toggle: ${device_name}_boiler_status_led

sensor:
  - platform: dallas
    index: 0
    name: "${room_name} temperature uncalibrated"
    filters:
      - filter_out: nan
      - sliding_window_moving_average:
          window_size: 6
          send_every: 4
          send_first_at: 4
      - delta: 0.1
      
    on_value:
      then:
        - script.execute: status_update
    on_raw_value:
      then:
        - sensor.template.publish:
            id: template_temperature
            state: !lambda 'return x;'
  - platform: template
    name: "${room_name} temperature"
    id: "template_temperature"
    filters:
      - filter_out: nan
      - sliding_window_moving_average:
          window_size: 6
          send_every: 4
          send_first_at: 4
      - delta: 0.1
      - calibrate_linear:
        - 0.0 -> 0.0
        - 20.3 -> 18.9
        - 20.4 -> 19.04
        - 20.5 -> 19.185
        - 20.6 -> 19.33
        - 20.7 -> 19.41
        - 20.8 -> 19.59
        - 20.9 -> 19.755
        - 21.0 -> 19.8625
    unit_of_measurement: "°C"
    icon: mdi:thermometer
  - platform: wifi_signal
    name: "${room_name} wifi"
    update_interval: 5s
    filters:
      - sliding_window_moving_average:
          window_size: 12
          send_every: 12
          send_first_at: 6
  - platform: uptime
    name: "${room_name} uptime"
  - platform: sun
    name: "sun_elevation"
    internal: true
    type: elevation
    id: sun_elevation

Now I have extra stuff going on in there than you would need - mostly flashing an LED to confirm that it registered the door being opened or closed or that a period of time has passed since the door was closed, and now the light in the room will be turned off. Additionally there is some detection of the door opening and closing quickly, which enables me to open, close, open within a few seconds to force the room light to turn on when it is dark outside but it’s not night time.

The important bits are:

dallas:
  - pin: D1
    update_interval: 15s
sensor:
  - platform: dallas
    index: 0
    name: "${room_name} temperature uncalibrated"
    filters:
      - filter_out: nan
      - sliding_window_moving_average:
          window_size: 6
          send_every: 4
          send_first_at: 4
      - delta: 0.1

So I filter out values that are nan which means not a number.
I then have a sliding window so that instead of the temperature going up and down in spikes, we get a temperature that is averaged across 6 samples - which at 15sec intervals is 1min 30secs. There is also a delta of 0.1 which means that we only update when the temperature we are going to send to home assistant, has changed since at least 0.1 since we last sent it.

Now in the longer code above you will notice there is calibrate_linear, which enables me to provide Home Assistant with a temperature that is closer to accurate - by providing ESPHome with known temperature values, versus what the Dallas sensor is reporting. ESPHome will then try and scale it’s output based on what temperature values it knows are correct.

Hope this helps a bit.

EDIT:
The 2 LEDs that are connected are red and green. The board has an inbuilt blue LED - which I flash when an update is sent to Home Assistant. The green LED is turned on when the heating switch in Home Assistant is turned on by the climate thermostat. And then the Red LED is turned on when the template sensor in Home assistant which tells us the boiler is working, because the water pipe has gone above 45C. This was the 3 of these that we have around the house, are reporting the heating and boiler status visually.