Esphomelib - library to greatly simplify Home Assistant integration with ESP32

esp8266
mqtt
Tags: #<Tag:0x00007fd078121588> #<Tag:0x00007fd078121358>

#58

My Mac just gives me a bluetooth port on the device list command. Am I missing a driver?

Lars


#59

Probably, yes. Most ESP8266 boards use one of two chipsets for the UART to USB bridge: CP2102 and FT232RL.

On a mac, installation is quite easy if you have homebrew:

# enable drivers tap
brew tap caskroom/drivers
# for CP2102
brew cask install silicon-labs-vcp-driver
# for FT232RL
brew cask install ftdi-vcp-driver

Otherwise, you’ll need to manually install the drivers from these links:


#60

Great, worked and above command now returns

/dev/cu.Bluetooth-Incoming-Port
-------------------------------
Hardware ID: n/a
Description: n/a

/dev/cu.usbmodem26300
---------------------
Hardware ID: USB VID:PID=0E8D:0003 LOCATION=20-4
Description: Product

/dev/cu.SLAB_USBtoUART
----------------------
Hardware ID: USB VID:PID=10C4:EA60 SER=0001 LOCATION=20-3
Description: CP2102 USB to UART Bridge Controller

which looks good to me. And it works now, even connected to my MQTT broker out of the box!

This is really a great contribution to make development of small IOT-like devices more efficient. Many thanks !

Lars


#61

Did someone by chance get an MPU6050 accelerometer working?

Lars


#62

Do you want to lift your home into space and check for launch acceleration? :rocket::see_no_evil:


#63

Check status of laundry:

Lars


#64

Hello,

got it to work and hooked up a DHT22. Yesterday it ran some time with good results until it suddenly started to report bogus values, even after restarting:

waschzimmer/debug b'\x1b[0;36m[D][sensor.dht:update:53]: Got Temperature=nan\xc2\xb0C Humidity=nan%\x1b[0m'
waschzimmer/debug b'\x1b[0;33m[W][sensor.dht:update:58]: Invalid Temperature: nan!C\x1b[0m'
waschzimmer/debug b'\x1b[0;33m[W][sensor.dht:update:63]: Invalid Humidity: nan%\x1b[0m'

Any ideas where this comes from ?

Lars


#65

My first guess would be something related to the wiring or the pull-up resistor. The library esphomelib is using for reading out the values from the DHT is, from what I know, widely used and quite battle tested, so I don’t expect the error to be there. How did you hook the sensor up? Do you have a 4.7kΩ pull-up resistor on the data pin and has anything changed since the error started to appear?

Possible other solutions: Hard-reset the ESP (by plugging the power, waiting a bit and plugging it back in), check the pin is correct and the wires all make good contact.


#66

sorry for the late reply!

thanks for your input. I’m running another esp32 wemos lolin32 without a resistor for months now and I assume I’m safe :wink:

one problem: due to the LWT message after the esp goes to sleep it is shown as unavailable in the HA frontend. I configured the sensor manually without an availability_topic topic and it is working. Maybe a “no LWT”-option would be useful…

Is it possible to configure some kind of “shutdown” if the ADC is below 3V? so I would be completly safe if the cell is empty.

Thanks again!


#67

Hi everybody!

I have just release another version of esphomelib/esphomeyaml: 1.4.0 (full changelog). The release is mostly for bug fixes (at least most of the time went there :smile:). But among the new features are:


#68

Wow, really cool - need to try this!

Lars


#69

I’m new to ESP32 development, so please excuse my ignorance. How are esphomelib and esphomeyaml related? Can I use esphomeyaml without esphomelib? The getting started guide on the git for esphomelib seems easy to follow, but the one for esphomeyaml is unclear. Sorry if I am missing something but this type of integration with HA is what I’ve been waiting for with these Arduino boards.


#70

Yeah the documentation is not too great ATM - it just takes so much time and I just like writing code much more :​P

Anyway, esphomelib is a C++ framework for creating ESP8266/ESP32 firmwares with just a few lines of C++ code. It also implements many of the common components of Home Assistant like sensor or lights and has pre-implemented integrations for a bunch of sensors/actuators.

esphomeyaml on the other hand, is a project that parses YAML configuration files and creates C++ code which is later compiled into a binary. This C++ code is what you would usually write manually by hand when using esphomelib (the C++ framework) directly.

I guess an example would explain the situation best: Given this input configuration file

esphomeyaml:
  name: kuche
  platform: espressif8266
  board: nodemcuv2

logger:
  level: verbose

wifi:
  ssid: [redacted]
  password: [redacted]
  manual_ip:
    static_ip: [redacted]
    gateway: [redacted]
    subnet: 255.255.255.0
ota:
web_server:
mqtt:
  broker: [redacted]
  username: [redacted]
  password: [redacted]

dallas:
  pin: D1

sensor:
  - platform: dallas
    address: 0x69041662d7f1ff28
    name: "Küche Raumtemperatur"

esphomeyaml will automatically generate this C++ code, compile it and finally upload it:

// Auto generated code by esphomeyaml
#include "esphomelib/application.h"

using namespace esphomelib;

void setup() {
  // ===== DO NOT EDIT ANYTHING BELOW THIS LINE =====
  // ========== AUTO GENERATED CODE BEGIN ===========
  App.set_name("kuche");
  auto *logger = App.init_log();
  auto *wifi = App.init_wifi("[redacted]", "[redacted]");
    wifi->set_sta_manual_ip(ManualIP{
      .static_ip = IPAddress([redacted]),
      .gateway = IPAddress([redacted]),
      .subnet = IPAddress(255, 255, 255, 0),
  });
  auto *ota = App.init_ota();
  ota->start_safe_mode();
  App.init_mqtt("[redacted]", 1883, "[redacted]", "[redacted]");
  App.init_web_server();

  auto *dallas = App.make_dallas_component(5);
  auto *dallas_sensor = dallas->get_sensor_by_address("Küche Raumtemperatur", 0x69041662D7F1FF28);
  App.register_sensor(dallas_sensor);
  // =========== AUTO GENERATED CODE END ============
  // ========= YOU CAN EDIT AFTER THIS LINE =========
  App.setup();
}

void loop() {
  App.loop();
  delay(1);
}

So, to answer your question, esphomeyaml uses esphomelib to create firmwares. esphomelib can be used on its own. Esphomeyaml however requires/builds on esphomelib.

Additionally, esphomeyaml also is kind of a nice wrapper for the whole build system so that the user doesn’t need to worry about complex platformio configurations.

Another nice bonus of esphomeyaml is that you can still manually create custom sensors by editing the generated C++ code if you wish to do so.

I hope this explanation can be understood and answers your question. I think I will start putting a lot more focus on documentation once I get some more essential features into esphomelib.


#71

That is a great explanation - thanks. It seems like you have put a lot of work into the project and I’m sure I will come to appreciate it more and more as I get farther along. I think it will make a lot more sense once I get my ESP32 boards in and platformio up and running.


#72

Hi,

Is there any possibility ADC values (in addition to measurement over a specified amount of time) could be sent to HA when delta between two consecutive readings is above a certain threshold (either relative or absolute value)?

For ESP32, multiple ADCs will work independently without locking the readings on the other ADC pins?

Thanks


#73

Yes, that should work without a problem :slight_smile: You can even have multiple ADC sensors pointing at the same pin (the reason for this is that esphomelib is purely software-timing based and tries to never use hardware timers for simplicity)

So, right now I think this would only be possible if you write custom Sensor Filter. It’s really not too complicated if you know a bit of C++ (see this and this for reference). For example: (haven’t tested, but something like this should work)

#include "esphomelib/application.h"
#include "esphomelib/sensor/filter.h"

class DeltaFilter : public sensor::Filter {
 public:
  DeltaFilter(float delta) : delta_(delta) {}

  Optional<float> new_value(float value) override {
    if (abs(value - this->last_value_) > this->delta_) {
      this->last_value_ = value;
      return value;
    }
    // skip value
    return Optional<float>();
  }

  float delta_;
  float last_value_{-1000.0f};
};

void setup() {
  // ...
  some_sensor->add_filter(new DeltaFilter(10.0f));
  // ...
  App.setup();
}

(this is kind of the great aspects of esphomelib, you can easily extend it if you know how to code :slight_smile: )

I’m currently in the process of creating a whole automation framework for esphomelib which will make this kind of stuff a lot easier. But it’s quite a big project and will probably take some more time to get completely ready & tested.


#74

Thanks for the reply.

Not really :slight_smile: In fact, I have no coding experience at all and I couldn’t tell of any difference between C, Java or Cobol whatsoever as they’re all written in Chinese :slight_smile:

I did manage to use examples to create quite a lot of complicated HA scripts and automations, although that’s an entirely different breed of animal.


#75

Ok, I understand :see_no_evil: Code can seem like a lot of garbled characters.

As such a delta filter would be relatively easy for me to implement, I think I can easily add. Only thing I would be interested in would be the exact use case (it helps a lot if you know what you’re actually try solve). Thanks!


#76

Hi,

For the ADC I’ve managed to use, until now, LDR (both as general light sensor to be able to trigger automations when bulbs need to be turned on/off using sun light as condition or as a feedback for a light command being sent by HA to bulbs - that is for bulbs that do not send acknowledgment to the commands received; I know that there are digital sensors for luminescence but it is easier, and more fun to put a LDR and a resistor to an ADC pin :slight_smile: ), load cell (for building a weighting device or as bed occupancy sensor), MQ-9 for carbon monoxide (at least I think it works as when placed near a glass of beer it immediately reacts :wink: ) and sound sensor. Obviously, there are many more different types of analog sensors but at least for these I found an immediate, effective use.

Each of these would require readings being sent to HA both when changes occur (by comparison to the previous stored value) and over a certain schedule (at 1/2/5/10 minutes, etc) - this would also serve as a heartbeat signal.


#77

Hi this is a great project! Do you have any intention to support rotary encoders?
I’m currently using espeasy for an mqtt “dimmer” using rotary encoder. I’d love to move to your solution.