Do you want to lift your home into space and check for launch acceleration?
Check status of laundry:
Lars
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
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.
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
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!
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 ). But among the new features are:
- Support for the MPU6050 Accelerometer and Gyroscope in case you want to check if the washing machine is running.
- Experimental support for the PCF8574 and PCF8575 I/O port expander. If you can verify the integration works, please contact me.
- A new simple switch that exposes any binary output component as a switch.
- A shutdown switch has been added so that you can protect your LiPo batteries from discharging too much.
- Scan an i²c bus for connected devices using the new
scan
parameter toApp.init_i2c
(docs) - ds18b20 and ADC sensor on the ESP8266 now leverage Home Assistant’s awesome entity registry feature. So now you can edit the friendly name of these sensor straight from the frontend.
Wow, really cool - need to try this!
Lars
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.
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.
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.
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
Yes, that should work without a problem 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 )
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.
Thanks for the reply.
Not really 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
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.
Ok, I understand 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!
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 ), 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 ) 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.
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.
Yes that seems like a fun use-case. I’ve now tried to make a generic “send if … or …” with a special “send if delta or time” filter. I’ll see if I can get it into 1.6.0
Absolute rotary encoders (the ones using a voltage divider circuit) should already be supported by the ADC Sensor (I think I’ll create a “cookbook” for 2nd order components sometime).
Basically, with absolute rotary encoders, you just measure the voltage on the pin between GND and VCC. That voltage you measure will be proportional to the angle. Something like this:
sensor:
- platform: adc
pin: A0
name: "Living Room Dimmer"
filters:
# Convert voltage to angle, depends on input voltage and encoder.
- lambda: (x / 3.3) * 360.0
# Tell Home Assistant the output value is in degrees
unit_of_measurement: "°"
Continuous rotary encoder (with digital signals) are currently not supported, but I’ll try to get it into the automation engine release as it makes most sense there.
Thanks for the info, and for looking into rotary encoder support - meant the digital continuous rotary encoders rather than pot.
These are useful because analogue input on a sonoff basic is not easy.
BTW this is my project - Analogue style rotary dimmer switch - Sonoff + ESPEasy + MQTT
@hijinx Rotary encoders are now supported with v1.5.3 https://esphomelib.com/esphomeyaml/components/sensor/rotary_encoder.html
sensor:
- platform: rotary_encoder
name: "Rotary Encoder"
pin_a: D1
pin_b: D2
@Petrica I’ve now also added support for heartbeat and delta sensor filters https://esphomelib.com/esphomeyaml/components/sensor/index.html#base-sensor-configuration Your use-case should be possible like this now:
sensor:
- platform: some_platform
# ...
filters:
- or:
- heartbeat: 5min
- delta: 5.0
This configuration will publish new states if either the absolute difference to the last reported value is at least 5.0
or if the last sent value is 5 minutes old.