@ralphhughes wrote:

I’ve bought these bulbs from amazon:

They use the tuya smart app so I hoped they would flash ok without me having to open them up. Downloaded tuya-convert onto my pi4 and flashed them with esphome no problem. Trouble is the example config I used is for a mirabello bulb that I hoped was similar and now although I can turn the bulb on and off and dim it via esphome\home assistant I cannot control the colour at all, which was working fine through the tuya app.

When I did my first flash with tuya-convert it had the following info:

Getting Info from IoT-device
VTRUST-FLASH 1.5
(c) VTRUST GMBH https://www.vtrust.de/35c3/
READ FLASH: http://10.42.42.42/backup
ChipID: 64e234
MAC: EC:FA:BC:64:E2:**
BootVersion: 7
BootMode: normal
FlashMode: 1M QIO @ 40MHz
FlashChipId: 1540c8
FlashChipRealSize: 2048K
Active Userspace: user2 0x81000

My current config that doesn’t work with RGB is:

output:
  - platform: esp8266_pwm
    id: output_red
    pin: GPIO4
  - platform: esp8266_pwm
    id: output_green
    pin: GPIO12
  - platform: esp8266_pwm
    id: output_blue
    pin: GPIO14
  - platform: esp8266_pwm
    id: output_white
    pin: GPIO5

light:
  - platform: rgbw
    name: "rgbw_01"
    id: light1
    red: output_red
    green: output_green
    blue: output_blue
    white: output_white

Has anybody got a working esphome config for these bulbs or could advise me on how to make my own?

Posts: 7

Participants: 2

Read full topic

@SpikeyGG wrote:

I’m using ESPHome with a device I put together to monitor water pressures before and after my whole house filter. I really want to use the two sensors to measure the pressure drop of the filter system but with the filters I’ve established the two sensor values come in very asynchronously and the pressure of the two changes much more rapidly than I originally assumed so the delta/difference value marches all over the place.

I’d like to set up my ESPHome configuration to push sensor values on both sensors at the same time if either sensor’s filter is triggered. It seems like this should be possible, maybe with the on_value and lambda publish_state() function but I’m having a hard time wrapping my brain around it…

The two sensor configurations currently looks like this:

sensor:
  - platform: ads1115
    multiplexer: 'A0_GND'
    gain: 6.144
    name: "Incoming Water Pressure"
    id: incoming_water_pressure
    update_interval: 5s
    unit_of_measurement: "psi"
    icon: "mdi:gauge"
    accuracy_decimals: 1
    filters:
      - throttle: 10s
      - or:
        - heartbeat: 600s
        - delta: 0.04
      - lambda: return x * 42.3 - 18;
  - platform: ads1115
    multiplexer: 'A1_GND'
    gain: 6.144
    name: "Outgoing Water Pressure"
    id: outgoing_water_pressure
    update_interval: 5s
    unit_of_measurement: "psi"
    icon: "mdi:gauge-low"
    accuracy_decimals: 1
    filters:
      - throttle: 10s
      - or:
        - heartbeat: 600s
        - delta: 0.04
      - lambda: return x * 47.3 - 22;

Posts: 9

Participants: 2

Read full topic

@19roland70 wrote:

I am making a dimmer with ESPHome.
An ESP12e with rotary encoder.
I can dim the LED with the rotary encoder, I can dim with the slider in the menu.
The only problem is that the slider does not move when I turn the rotary encoder.
I once made this with push buttons and the slider does move with it.
How can I fix this?
This is my code:

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

sensor:
  - platform: rotary_encoder
    name: "Rotary Encoder"
    pin_a: D1
    pin_b: D2
    min_value: 0
    max_value: 52
    resolution: 4
    filters:
      - or:
        - debounce: 0.1s
        - delta: 10
      - lambda: |-
          if (x < 0.0) return 0.0;
          if (x > 52.0) return 52.0;
          return x;
    on_value:
      then:
        - output.set_level:
            id: pwm_output
            level: !lambda "return x/53.0;"
            
        - logger.log:
            format: "pwm_output set to %.1f%s"
            args: [ 'x*100/53.0', '"x"' ]
          
    
output:
  - platform: esp8266_pwm
    pin: D6
    inverted: true
    frequency: 1000 Hz
    id: pwm_output
    
light:
  - platform: monochromatic
    output: pwm_output
    name: "LED-Lamp"

Posts: 6

Participants: 3

Read full topic

@Salmoneus wrote:

Hi

I would like to compare two temperatures measured with dallas sensors, and I guess that some kind of template sensor with a lambda would be the way to go. But I cannot find out how to do it.

difference = (float value 1) - (float value 2)

What would the code be?

Posts: 5

Participants: 2

Read full topic

@Linwood wrote:

I built a fridge/freezer alarm, or will finish it when more sensors come from Amazon, but I have a hardware question and hope it might be tolerated as it is not exactly esphome specific.

I have been buying sensors that look like this:

sensor514×627 38.5 KB

I put them on the end of a cable with shrink wrap protecting the connectors but also some larger shrink wrap to protect the sensor. As in here:

But I realized I do not actually know what the sensors look like. Is cutting a hole on the front grate enough? What is the big flat metal plate on that back PCB? My impression is that PCB is just a convenience and all the sensors are inside the white plastic.

Bottom line question: Is wrapping it as shown going to impact its use or accuracy or more likely latency?

By the way - ESPHome remains one of the most impressive parts of Home Assistant. It’s just amazing how easily one can build functional wifi devices with OTA.

Posts: 4

Participants: 3

Read full topic

@shved86 wrote:

Good afternoon!
I breaded to make a battery-powered watch with an OLED SSD1306 screen on an ESP 32 that goes into deep sleep. I managed to send the board to sleep, but at the moment when the board falls asleep the screen continues to light. Tell me how you can turn off the screen when the board falls asleep

Posts: 1

Participants: 1

Read full topic

@Kuzma30 wrote:

I have 2 sensors - temperature and pulse counter (I control temperature and water flow in water cool system for CNC spindel). I need something like this:
IF temperature is defined range AND pulse counter > predefined value THEN set GPIOXX to 1, ELSE set GPIOxx to 0

sensor:
  - platform: pulse_counter
    pin: GPIO21
    name: "Pulse Counter"
    update_interval: 5s
    id: pump_speed

    on_value:      
      if:
        condition:
          sensor.in_range:
            id: pump_speed
            above: 0
            below: 30            
        then:
        - switch.turn_on: PUMP_ERR
        - switch.turn_off: PUMP_OK
        else:
        - switch.turn_on: PUMP_OK
        - switch.turn_off: PUMP_ERR

  - platform: ntc
    sensor: resistance_sensor
    id: ntc_sensor
    calibration:
      - 10.0kOhm -> 25°C
      - 950Ohm -> 100°C
      - 21.2kOhm -> 12°C
    name: NTC Temperature

  # Example source sensors:
  - platform: resistance
    id: resistance_sensor
    sensor: source_sensor
    configuration: DOWNSTREAM
    resistor: 10kOhm
    name: Resistance Sensor
  - platform: adc
    id: source_sensor
    attenuation: 11db
    pin: GPIO34
    update_interval: never
    
    on_value:      
      if:
        condition:
          sensor.in_range:
            id: ntc_sensor
            above: 0
            below: 60
        then:
        - switch.turn_on: Temp_OK
        - switch.turn_off: Temp_ERR
        else:
        - switch.turn_on: Temp_ERR
        - switch.turn_off: Temp_OK

#Automations
on_value_range:
   if:
    condition:
      and:
        sensor.in_range
          id: pump_speed
          above: 0
          below: 30            
        sensor.in_range
          id: ntc_sensor
          above: 0
          below: 60
    then:
      - switch.turn_on: ALL_OK
    else:
      - switch.turn_off: ALL_OK
      
switch:
  - platform: gpio
    pin: GPIO19
    id: ntc_vcc
    
  - platform: gpio
    pin: GPIO26
    id: Temp_OK
    name: "Temp_OK"

  - platform: gpio
    pin: GPIO17
    id: Temp_ERR
    name: "Temp_Error"
    
  - platform: gpio
    pin: GPIO16
    id: PUMP_OK
    name: "Pump_OK"

  - platform: gpio
    pin: GPIO15
    id: PUMP_ERR    
    name: "Pump_error"
    
  - platform: gpio
    pin: GPIO23
    id: ALL_OK    
    name: "ALL_OK"
    
  - platform: gpio
    pin: GPIO18
    id: FUN1    
    name: "FUN1_ON"
    
  - platform: gpio
    pin: GPIO22
    id: FUN2    
    name: "FUN2_ON"
    
interval:
  - interval: 30s
    then:
      - switch.turn_on: ntc_vcc
      - component.update: source_sensor
      - switch.turn_off: ntc_vcc

I get such error

INFO Reading configuration /config/esphome/esp.yaml...
ERROR Error while reading config: Invalid YAML syntax. Please see YAML syntax reference or use an online YAML syntax validator:

mapping values are not allowed here
  in "/config/esphome/esp.yaml", line 95, column 13:
              id: pump_speed

Posts: 2

Participants: 2

Read full topic

@ashscott wrote:

I need to have a ‘WiFi connected’ LED for my ESP32.

I can figure out how to use the wifi.component in a condition but how do I use to turn on an LED when connected and off when disconnected.

This is probably really simple but I’m stuck.

Any ideas?

Posts: 5

Participants: 3

Read full topic

@jorgenn wrote:

Hi
I’m trying to get a custom_component to work on ESPHome,
I will try to get an instrument that sends data in NMEA 0183 (it’s not a GPS) via rs232 ttl adapter to uart on a esp32.

I’m a bit stuck, I’m new to this platform.

So far I have done this:
From my YAML file:

uart:
  id: wind
  tx_pin: GPIO1
  rx_pin: GPIO3
  baud_rate: 19200
  
custom_component:
- lambda: |-
    auto Windsonic = new Windsonic(id(wind));
    return {Windsonic->retning, Windsonic->hastighet}; 

From my Windsonic.h file

#include "esphome.h"

class Windsonic : public Component, public UARTDevice {
 public:
  Windsonic(UARTComponent *parent) : UARTDevice(parent) {}
  float retning = 0;
  float hastighet = 0;
  
  void setup() override {
    // nothing to do here
  }
  void loop() override {
    // Use Arduino API to read data, for example
    String line = readStringUntil('\n');
    retning = parse_float(line.substring(8, 10));
	hastighet = parse_float(line.substring(15, 19));
    
    }
    // etc
  
 // void update() override {
//	retning->publish_state(retning);
//	hastighet->publish_state(hastighet);
//  }
};

From my compile log:

src/main.cpp:113:3: warning: multi-line comment [-Wcomment]
   //   lambda: !lambda "auto Windsonic = new Windsonic(id(wind));\nreturn {Windsonic->retning,\
   ^
In file included from src/main.cpp:14:0:
src/windsonic.h: In member function 'virtual void Windsonic::loop()':
src/windsonic.h:15:41: error: invalid initialization of reference of type 'const string& {aka const std::__cxx11::basic_string<char>&}' from expression of type 'String'
     retning = parse_float(line.substring(8, 10));
                                         ^
In file included from src/esphome/core/application.h:8:0,
                 from src/esphome/components/api/api_connection.h:4,
                 from src/esphome.h:2,
                 from src/main.cpp:3:
src/esphome/core/helpers.h:44:17: note: in passing argument 1 of 'esphome::optional<float> esphome::parse_float(const string&)'
 optional<float> parse_float(const std::string &str);
                 ^
In file included from src/main.cpp:14:0:
src/windsonic.h:16:40: error: invalid initialization of reference of type 'const string& {aka const std::__cxx11::basic_string<char>&}' from expression of type 'String'
  hastighet = parse_float(line.substring(15, 19));
                                        ^
In file included from src/esphome/core/application.h:8:0,
                 from src/esphome/components/api/api_connection.h:4,
                 from src/esphome.h:2,
                 from src/main.cpp:3:
src/esphome/core/helpers.h:44:17: note: in passing argument 1 of 'esphome::optional<float> esphome::parse_float(const string&)'
 optional<float> parse_float(const std::string &str);
                 ^
src/main.cpp: In lambda function:
src/main.cpp:121:28: error: expected type-specifier before 'Windsonic'
       auto Windsonic = new Windsonic(wind);
                            ^
src/main.cpp:122:55: error: could not convert '{<expression error>, <expression error>}' from '<brace-enclosed initializer list>' to 'std::vector<esphome::Component*>'
       return {Windsonic->retning, Windsonic->hastighet};  
                                                       ^
*** [/data/vind/.pioenvs/vind/src/main.cpp.o] Error 1

I need som advice on how to get this right.

Posts: 2

Participants: 2

Read full topic

@pflaugh wrote:

Hi,

As the title states, I am looking for a solution that will successfully allow climate control of a Tosot 8000BTU Window AC from HA. So far I have used the ESPHome Remote Transmitter and Remote Receiver to capture some of the remote codes and then replay them from a simple switch in HA. Awesome, we have basic control; off and on, swing off and on, etc. The hardware I am using is a NodeMCU 8266 with an IR LED and an TSOP38238 receiver. HA is Hass.io on an RPi3.

I would like to now take all these remote codes and find a way to parse the code i need to send to the IR Transmitter. I would like to have a Climate entity that can be controlled on the HA side, then send the requested state to the IR Transmitter to control the AC.

The kicker in this whole situation is that the remote for this AC unit is one of those that transmits the ENTIRE state of the AC unit with every button press. So this complicates things as now there is a specific code for every combination of states that the unit can be in. (Probably around 200 or so once you figure in a 20 degree range of temps to select, 4 different modes, swing on or off, main display on or off, etc)

Some things I have tried already;

I have looked at trying to use the MQTT HVAC component as the HA front end. But, I’ve had a hard time finding a way to take all the separate state command topics, combine them into one parse-able string or payload, then narrow down the exact code that needs to be transmitted based on what values are requested in the MQTT topic.

I looked at NodeRed to be a middle man between HA and ESPHome, but I couldn’t figure out if this was going to be the best way to tackle this.

Could anyone give me any pointers or ideas on how to go about doing this?? I also feel like there is probably something already out there that I’ve missed that would make doing things so much easier that I’m just missing.

Thanks in advance for any help!

Posts: 2

Participants: 2

Read full topic

@InToSSH wrote:

Hi guys,
I just wanted to share a little project I have been working on.
I have an exterior venetian blind with a single motor which controls both position and tilt (when button down pressed, the blind first tilts to closed then starts moving down, when button up pressed, the blind first tilts open then starts moving up).

I wanted to use the time_based cover in ESPHome to track the position, which is accurate enough.
My blind also has built in endstops, which I cannot read directly in ESPHome, but there is a workaround using the power draw detected by Shelly2.5. This is why the time_based cover has “has_built_in_endstop” set to true, to be able to “synchronize” the blind position with the position tracked by “time_based” cover in case it gets inaccurate over time, this way each time the blind is fully open or closed, the position gets synchronized and the cover component is stopped based on the detected power draw.
Unfortunatelly time_based cover doesn’t support tilt, so what you are actually controlling via the buttons or HA is the template cover, which synchronizes position state with the time_based cover and controlls it, but also adds the tilt function. I meassured that it takes around 1s to tilt open/close the blind, to synchronize the position (without a need for some custom component tracking the tilt status based on the previous movement of the blind) it just opens/closes the tilt for 1s to make sure it’s either fully open/closed, then it applies the percentage of tilt you requested (in worst case this means the blind will move up/down a bit).

Features

• Support for HW buttons connected to Shelly2.5 - short press used for tilt (activates the blind momentarily), long press for opening/closing the blind (latches in the on state until second press in either direction)
• Position of the cover tracked using time_based cover
• Tilt controlled by template_cover - tilt position synchronizes first to fully open/closed, the moving to specified position
• has_built_in_endstop enabled to allow the blind to move to fully open/closed position to synchronize the software time based position.
• Endstops of the blind detected by power draw from the Shelly2.5

Just for completeness my blind is based on the Somfy WT motor.
It is not perfect, but works good enough, altough any improvements or fixed you might think about are welcome For example I don’t like the idea of the lambda used on the template_cover to check the position that quickly, I think it slows it down a bit, but a delay cannot be added because it looks like this lambda is evaluated in the main loop and if I add a delay, it freezes the whole device.

The code

substitutions:
  device_name: Living Room Cover
  
esphome:
  name: living_room_blind
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_pass
  fast_connect: true
  power_save_mode: none
  manual_ip:
    static_ip: 10.10.3.25
    gateway: 10.10.3.1
    subnet: 255.255.255.0


  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}
    password: !secret ap_pass


# Enable logging
logger:
  level: DEBUG
  esp8266_store_log_strings_in_flash: False

# Enable Home Assistant API
api:
  password: !secret api_pass

ota:
  password: !secret api_pass
  
i2c:
  sda: GPIO12
  scl: GPIO14

globals:
  - id: cover_moving #This is for the HW buttons to determine if a press should stop the blind or start moving it (this could probably be done without this var by reading id(time_cover).current_operation)
    type: bool
    initial_value: "0"

cover:
  - platform: time_based # Time based cover to track the position of the blind based on the time (unfortunatelly this doesn't support tilt)
    name: ${device_name} - Time Cover
    internal: True
    id: time_cover
    has_built_in_endstop: True # The controller in my blind automatically stops the motor in it's endpoints, this is set to True to be able to synchronize the zero position based on time with the actual position when the blind is either fully closed or open
                               # The power meter in the Shelly2.5 is then used to determine when the blind has stopped, sending a "cover.stop" action to this cover.
    open_action:
      - globals.set:
          id: cover_moving
          value: "true"
      - script.execute: detect_endpoint
      - switch.turn_off: motor_down
      - switch.turn_on: motor_up
    open_duration: 54sec # Set the correct time for your specific blind

    close_action:
      - globals.set:
          id: cover_moving
          value: "true"
      - script.execute: detect_endpoint
      - switch.turn_off: motor_up
      - switch.turn_on: motor_down
    close_duration: 53sec # Set the correct time for your specific blind

    stop_action:
      - globals.set:
          id: cover_moving
          value: "false"
      - script.stop: detect_endpoint
      - switch.turn_off: motor_up
      - switch.turn_off: motor_down
      
  - platform: template # Template cover which synchronizes position with the time_cover, but also supports tilt.
    name: ${device_name}
    id: template_cover
    lambda: |-
      if (id(template_cover).current_operation != id(time_cover).current_operation)
      {
        id(template_cover).current_operation = id(time_cover).current_operation;
      }
      return id(time_cover).position;
    has_position: true
    assumed_state: True
    open_action: 
      - cover.open: time_cover
    close_action:
      - cover.close: time_cover
    stop_action:
      - cover.stop: time_cover
    position_action:
      - cover.control:
          id: time_cover
          position: !lambda |-
            return pos;
    tilt_action:
      - lambda: |-
          if (tilt == 1) {
            auto call1 = id(time_cover).make_call();
            call1.set_command_open();
            call1.perform();
            delay(1000);
            auto call2 = id(time_cover).make_call();
            call2.set_command_stop();
            call2.perform();
            
          } else if (tilt == 0) {
            auto call1 = id(time_cover).make_call();
            call1.set_command_close();
            call1.perform();
            delay(1000);
            auto call2 = id(time_cover).make_call();
            call2.set_command_stop();
            call2.perform();
            
          } else {
            if (tilt > 0.5) {
              auto call1 = id(time_cover).make_call();
              call1.set_command_open();
              call1.perform();
              delay(1000);
              auto call2 = id(time_cover).make_call();
              call2.set_command_stop();
              call2.perform();
              delay(500);
              auto call3 = id(time_cover).make_call();
              call3.set_command_close();
              call3.perform();
              delay(1000 - (tilt*1000) + 50);
              auto call4 = id(time_cover).make_call();
              call4.set_command_stop();
              call4.perform();
              
            }
            if (tilt <= 0.5) {
              auto call1 = id(time_cover).make_call();
              call1.set_command_close();
              call1.perform();
              delay(1000);
              auto call2 = id(time_cover).make_call();
              call2.set_command_stop();
              call2.perform();
              delay(500);
              auto call3 = id(time_cover).make_call();
              call3.set_command_open();
              call3.perform();
              delay(tilt*1000 + 200);
              auto call4 = id(time_cover).make_call();
              call4.set_command_stop();
              call4.perform();
              
            }
          }
          
          
          id(template_cover).tilt = tilt;
          id(template_cover).publish_state();

script:
  - id: detect_endpoint # Used to detect the endpoint of the blind based on the power draw, the blind automatically stops in it's endpoints, this might not be needed, but I don't like the idea of leaving the relay on when "has_built_in_endstop" is used on the cover.
    then:
      - delay: 5sec # Delay to wait for the power sensor to read the value
      - wait_until:
          sensor.in_range:
            id: power_down
            below: 20
      - wait_until:
          sensor.in_range:
            id: power_up
            below: 20
            
      - cover.stop: template_cover
        
        
switch:
  - platform: gpio
    pin: 4
    name: ${device_name} - Motor UP
    id: motor_up
    interlock: [motor_down]
    interlock_wait_time: 100ms
    restore_mode: always off
  - platform: gpio 
    pin: 15
    name: ${device_name} - Motor DOWN
    id: motor_down
    interlock: [motor_up]
    interlock_wait_time: 100ms
    restore_mode: always off
    
binary_sensor:
  - platform: gpio  # Physical button on the wall to move the blind UP
    pin: 5
    name: ${device_name} - Button UP
    on_press:
      then:
        - if:
            condition:
              lambda: 'return !id(cover_moving);'
            then:
              - cover.open: template_cover

    on_click:
      - min_length: 1ms
        max_length: 999ms
        then:
          - cover.stop: template_cover

          
  - platform: gpio # Physical button on the wall to move the blind DOWN
    pin: 13
    name: ${device_name} - Button DOWN
    on_press:
      then:
        - if:
            condition:
              lambda: 'return !id(cover_moving);'
            then:
              - cover.close: template_cover
              
    on_click:
      - min_length: 1ms
        max_length: 999ms
        then:
          - cover.stop: template_cover
          
        
sensor:          

  - platform: ade7953
    voltage:
      name: ${device_name} - Voltage
    current_a:
      name: ${device_name} - Current Down
      internal: True
    current_b:
      name: ${device_name} - Current Up
      internal: True
    active_power_a:
      name: ${device_name} - Power Down
      id: power_down
    active_power_b:
      name: ${device_name} - Power Up
      id: power_up
      filters:
        - multiply: -1
    update_interval: 5s

Posts: 1

Participants: 1

Read full topic

@mrrodge wrote:

Probably a silly question.

If I have an automation in my YAML that turns on a switch, then an automation on the switch so that on_turn_on it delays for 20 minutes and then turns off, how does it handle extra turn_ons?

For example I have a PIR to turn on a relay, then the relay starts its 20 minute delay before turning back off. If the PIR triggers again after ten minutes will ESPHome register a second on_turn_on event and start the 20 minutes again resulting in the relay being on for 30 minutes, or will the turn_on be ignored as the switch is already on?

Thanks!

Posts: 1

Participants: 1

Read full topic

@Giuseppe-P wrote:

I am trying to understand this YAML language .. I am trained in C ++ .... it is explained very badly in esphome

how can i run a script use this lambda?

.state: Retrieve the current state of the binary sensor.

// Within lambda, get the binary sensor state and conditionally do something

if (id(my_binary_sensor).state) {
  // Binary sensor is ON, do something here
} else {
  // Binary sensor is OFF, do something else here
}

Posts: 4

Participants: 2

Read full topic

@bean wrote:

I have a d1 mini configured to a reed sensor; copy/pasted from another project. I am trying to modify the project so the sensor will power a relay. I have tried many combinations but can not get the correct code. I did have the switch showing in home assistant but it did not control the relay so I removed the code.

What is the code for the switch and then how does the switch power the relay on/off with the status of the binary_sensor?

 esphome:
  name: esphome_freezer_door
  platform: ESP8266
  board: d1_mini
 
wifi:
  ssid: 'ssid_here'
  password: 'password_here'
  fast_connect: true
  manual_ip:
    static_ip: 192.168.1.145
    gateway: 192.168.1.1
    subnet: 255.255.255.0
    dns1: 192.168.1.1
    dns2: 192.168.1.1
  
api:
 
ota:
 
web_server:
  port: 80
 
logger:
 
binary_sensor:
- platform: gpio
  pin:
    number: GPIO13
    mode: INPUT_PULLUP
    inverted: False
  name: "Freezer Door"
  device_class: door
  filters:
    - delayed_on: 20ms

The binary_sensor is working correctly, just need to have it control the relay. The relay is stacked on the D1 mini.

The switch should be named “Freezer Light” and will be GPIO5. I want it to turn on when the binary_sensor: “Freezer Door” opens and remain off when the binary_sensor: “Freezer Door” is closed.

Hope this makes sense, any help appreciated.

Posts: 5

Participants: 2

Read full topic

@ashscott wrote:

ESPHome time is out by one hour so ESPHome automations are happening 1 hour late.

In HA I have:

sensor:
  - platform: time_date
    display_options:
      - 'time'
      - 'date'
      - 'date_time'
      - 'time_date'
      - 'time_utc'

I also have the correct timezone set in HA.

And in ESPHome i have:

time:
  - platform: homeassistant
    id: homeassistant_time

Time displays correctly in Home Assistant.

I’m pretty sure this is due to the clocks going forward last weekend.

What setting am I missing to take account for the change to summer time?

Posts: 4

Participants: 2

Read full topic

@blessani wrote:

I’ve got a load of Digoo 433MHz PIR sensors that work really well - and I’ve made some of my own plug-in multisensors (light/temp/humidity/pressure/microwave/pir).

Problem is, the PIR I used is prone to the occasional false positive (once or twice a day). I’ve been looking round and there’s a number of possible solutions (eg. combine the microwave with PIR to activate) - but I wanted to see if it were possible to make the PIR only determine if it were on with a few activation’s in a fixed window.

I managed to figure it out,

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

binary_sensor:
  - platform: template
    name: "Landing PIR 1"
    device_class: motion
    id: landing_pir_1

  - platform: gpio
    pin: D3
    device_class: motion    
    id: landing_pir_sensor_trigger
    internal: true
    on_multi_click:
    - timing:
      - ON for 0.1s to 5s
      then:
       - lambda: |-
          id(pir_trigger_count) += 1;
          if (id(pir_trigger_count) >= 2) {
            id(landing_pir_1).publish_state(true);
          }             
    - timing:
      - OFF for at least 3s
      then:
       - lambda: |-
          id(pir_trigger_count) = 0;
          id(landing_pir_1).publish_state(false);

So the code above says that if there are 2 PIR activation’s within a 3 second window - then that qualifies as it being a real activation.

I’ll be able to fine tune it - but this should be enough to stop a single PIR activation from triggering.

I thought I’d just share this with others.

Posts: 2

Participants: 2

Read full topic

@ajcooper72 wrote:

(topic withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Posts: 1

Participants: 1

Read full topic

@Linwood wrote:

I’m not even sure where to start, and when that happens I start here.

Running ESPHome 1.14.3 on HA .107.7 I built a D1 Mini with two AM2302’s, and it works fine except after doing a flash. When it boots after an OTA (and i think direct USB flash also, but I did that only once) I get an error that one sensor is not responding and possibly wired incorrectly.

But after a power off boot it works fine, and continues working fine for days. It is quite consistent.

I tried a different D1, and a NodeMCU, same result.

Here’s working log:

[10:47:19][D][dht:048]: Got Temperature=23.8°C Humidity=61.4%
[10:47:20][D][dht:048]: Got Temperature=23.5°C Humidity=55.8%
[10:47:29][D][dht:048]: Got Temperature=23.8°C Humidity=61.4%
[10:47:30][D][dht:048]: Got Temperature=23.5°C Humidity=55.8%
[10:47:39][D][dht:048]: Got Temperature=23.8°C Humidity=61.3%
[10:47:39][D][sensor:092]: 'AC Split Cold Temp': Sending state 23.79955 °C with 1 decimals of     accuracy
[10:47:39][D][sensor:092]: 'AC Split Cold Humidity': Sending state 61.36577 % with 0 decimals of accuracy
[10:47:40][D][dht:048]: Got Temperature=23.5°C Humidity=55.8%
[10:47:40][D][sensor:092]: 'AC Split Ambient Temp': Sending state 23.49995 °C with 1 decimals of accuracy
[10:47:40][D][sensor:092]: 'AC Split Ambient Humidity': Sending state 55.79984 % with 0 decimals of accuracy
[10:47:49][D][dht:048]: Got Temperature=23.8°C Humidity=61.4%
[10:47:50][D][dht:048]: Got Temperature=23.5°C Humidity=55.8%

Same code with a fresh OTA:

[10:49:09][D][dht:048]: Got Temperature=23.5°C Humidity=55.8%
[10:49:10][W][dht:126]: Requesting data from DHT failed!
[10:49:10][W][dht:060]: Invalid readings! Please check your wiring (pull-up resistor, pin number).
[10:49:19][D][dht:048]: Got Temperature=23.5°C Humidity=55.8%
[10:49:20][W][dht:126]: Requesting data from DHT failed!
[10:49:20][W][dht:060]: Invalid readings! Please check your wiring (pull-up resistor, pin number).
[10:49:29][D][dht:048]: Got Temperature=23.6°C Humidity=55.8%
[10:49:30][W][dht:126]: Requesting data from DHT failed!
[10:49:30][W][dht:060]: Invalid readings! Please check your wiring (pull-up resistor, pin number).
[10:49:39][D][dht:048]: Got Temperature=23.6°C Humidity=55.8%
[10:49:39][D][sensor:092]: 'AC Split Ambient Temp': Sending state 23.56667 °C with 1 decimals of accuracy
[10:49:39][D][sensor:092]: 'AC Split Ambient Humidity': Sending state 55.80000 % with 0 decimals of accuracy

It never seems to fix itself (though I confess here “never” is measured in minutes of waiting). A power cycle immediately fixes it, when it comes up it doesn’t miss a single read.

The code is below.

Any idea what would cause this sort of behavior? While I don’t anticipate doing an OTA frequently it is a bit of a paint to climb up and power cycle it (it’s in the ceiling).

Note I have one with the same basic structure but one sensor and it works fine after an OTA. It’s only the double.

sensor: 
  - platform: dht
    pin: 
      number: D5
      mode: INPUT_PULLUP
    model: AM2302
    update_interval: 10s
    temperature:
      name: "AC Split Ambient Temp"
      filters:
        - sliding_window_moving_average:
            window_size: 3
            send_every: 6
            send_first_at: 6
    humidity:
      name: "AC Split Ambient Humidity"
      filters:
        - sliding_window_moving_average:
            window_size: 3
            send_every: 6
            send_first_at: 6
  - platform: dht
    pin: 
      number: D4
      mode: INPUT_PULLUP
    model: AM2302
    update_interval: 10s
    temperature:
      name: "AC Split Cold Temp"
      filters:
        - sliding_window_moving_average:
            window_size: 3
            send_every: 6
            send_first_at: 6
    humidity:
      name: "AC Split Cold Humidity"
      filters:
        - sliding_window_moving_average:
            window_size: 3
            send_every: 6
            send_first_at: 6

Posts: 1

Participants: 1

Read full topic

@michel72 wrote:

Hi, just got myself this curtian rail from zemismart.

Tuya converted succesfully then flashed Tasmota and tried this:

https://tasmota.github.io/docs/TuyaMCU-Devices/#zemismart-curtain-motor

Specifically:

From the tasmota command line:

• change to TuyaMCU with module 54 (will reboot)
• Switch from U0RX/TX to U1RX/TX with backlog gpio1 0; gpio3 0; gpio15 107; gpio13 108 (will reboot)
• Treat DpId 0x65 as a Dimmer with tuyamcu 21,101
• Allow the dimmer to get down to 1% with setoption69 0

The curtain motor now presents as a Dimmer, with 100% full brightness = fully closed, and 0% full darkness = fully open.

The curtain motor also presents DpId 0x66 as a single event “Full Open” 00 , “Full Close” 01 , and “Stop” 02 command; but as of September 2019, I can’t see how to get that working.

The curtain motor also presents DpId 0x67 as a Boolean. I have only seen value 0x01 in all my prodding. 55 aa 00 07 00 05 67 01 00 01 01 75 = 07 Status, 0005 length, 67 DpId, 01 type, 0001 length, 01 value, 75 checksum

How to translate that to esp home?

Got this:

substitutions:
  devicename: zs_curtain_01
  upper_devicename: Zemismart Curtain controller - 01

esphome:
  name: $devicename
  platform: ESP8266
  board: esp01_1m
  
wifi:
  ssid: !secret esphome_wifi_ssid
  password: !secret esphome_wifi_password
  # enable the fallback hotspot
  ap:
    ssid: $devicename
    password: "qwe12345"

captive_portal:
  
api:
  password: !secret esphome_api_password

ota:
  password: !secret esphome_ota_password
  
web_server:
  port: 80
  
logger:
  baud_rate: 0

uart:
  rx_pin: GPIO13
  tx_pin: GPIO15
  baud_rate: 9600

# Register the Tuya MCU connection
tuya:

and then logged:

Datapoint 101: int value (value: 51)
Datapoint 102: enum (value: 2)
Datapoint 103: switch (value: ON)
Product: ‘8wq8cNNPt1bbXgYC1.0.0’

How to proceed from there?

Posts: 1

Participants: 1

Read full topic

@Nathan909 wrote:

I’m having an issue at the bottom where I’m trying to turn_off multiple lights at the bottom of this code, it only turns off the first light, not sure the proper way to express this.

binary_sensor:
  - id: spa_button
    name: Spa Button
    platform: gpio
    pin: GPIO4
    on_click:
    - min_length: 70ms
      max_length: 1290ms
      then:
        - switch.turn_off: spa_heater
    - min_length: 1300ms
      max_length: 4200ms
      then:
        - homeassistant.service:
            service: scene.turn_on
            data:
              entity_id: scene.bright_backyard
    - min_length: 4220ms
      max_length: 8500ms
      then:
        - homeassistant.service:
            service: scene.turn_on
            data:
              entity_id: scene.dim_backyard
    - min_length: 8520ms
      max_length: 13000ms
      then:
        - homeassistant.service:
            service: light.turn_off
            data:
              entity_id: light.backyard_lights
        - homeassistant.service:
            service: light.turn_off
            data:
              entity_id: light.backyard_patio_lights
        - homeassistant.service:
            service: light.turn_off
            data:
              entity_id: light.backyard_porch_lights

Posts: 6

Participants: 2

Read full topic