Advice for a esphome newbie

mafrosis · June 29, 2020, 11:56pm

Hi folks

Just tried esphome last couple of days and coming from Espurna there is a lot to like in esphome!

However, I am having a few problems

After the first few flashes, I found that the device will not come fully online. It connects to my LAN, but I can’t re-flash via port 8266, or telnet to that port. No MQTT messages show up in HA.

Is there anything obvious I’m doing wrong? Does my device have insufficient RAM? Can I get detailed logging without a serial connection?

The only way I can currently recover the device is by turning off my wifi network and forcing the device into fallback AP mode…

FYI: I’m currently not interested in the native API component as I’m trying to go like-for-like in switching from Espurna.

I’m using one of these (full config below):

---
esphome:
  name: c0a4b4
  platform: ESP8266
  board: esp8285

substitutions:
  devicename: Kogan Plug 1

wifi:
  ssid: *******
  password: ********
  fast_connect: true

  manual_ip:
    static_ip: 192.168.20.217
    gateway: 192.168.1.1
    subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: c0a4b4 Fallback Hotspot
    password: *********

captive_portal:

logger:

ota:

time:
  - platform: sntp
    timezone: Australia/Melbourne

mqtt:
  broker: ringil
  keepalive: 60s
  discovery: true

# ----------------------------------------

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode: INPUT_PULLUP
      inverted: true
    name: ${devicename} Power Button
    on_press:
      - switch.toggle: relay

  - platform: status
    name: ${devicename} Status

switch:
  - platform: gpio
    id: green_led
    pin:
      number: GPIO13
      inverted: true
    restore_mode: ALWAYS_OFF

  - platform: gpio
    name: ${devicename}
    pin: GPIO14
    id: relay
    restore_mode: ALWAYS_OFF

sensor:
  - platform: hlw8012
    sel_pin:
      number: GPIO12
      inverted: true
    cf_pin: GPIO04
    cf1_pin: GPIO05
    current:
      name: ${devicename} Current
      unit_of_measurement: A
    voltage:
      name: ${devicename} Voltage
      unit_of_measurement: V
    power:
      id: kogan_plug_1_wattage
      name: ${devicename} Power
      unit_of_measurement: W
    current_resistor: "0.00087"  # HIGHER VALUE GIVES LOWER WATTAGE
    voltage_divider: "2030"      # LOWER VALUE GIVES LOWER VOLTAGE
    change_mode_every: 8
    update_interval: 5s

  - platform: total_daily_energy
    name: ${devicename} Daily Energy
    power_id: kogan_plug_1_wattage
    filters:
      - multiply: 0.001
    unit_of_measurement: kWh

tom_l · June 30, 2020, 2:59am

You can get logging OTA in ESPHome.

Try specifying the mqtt broker by IP address.

mafrosis · June 30, 2020, 3:53am

Looks to me like only MQTT and direct serial are available for logging. If my node is not coming up properly, then my logs will not be available via MQTT.

A telnet option would be wonderful if it exists.

I tried building a new config and going through the time consuming fallback AP dance - and now I’m getting “not enough space”

After a couple of days of having a bad time with esphome, I think I’ll just go back to espurna for now. Shame espurna doesn’t support SM16716

tom_l · June 30, 2020, 4:23am

Looking at the config you posted above there is no way it would be using all the available memory.

Yes, if you have no wifi connection then logging OTA will not function.

You can suggest a telnet logging feature here: https://github.com/esphome/feature-requests/issues?utf8=✓&q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

As to your issue, there are some problems with the current release of ESPhome. Try the DEV version (available in the same repository). Just make sure to stop the regular ESPhome addon first.

mafrosis · June 30, 2020, 4:37am

Thanks @tom_l

The binaries I’m producing are 439KB - and I’ve been flashing 511KB espurna bins with no problems. No idea why esphome doesn’t like this. After another 30 mins of messing, it looks like I will need to open this device and get soldering to get espurna back on there

Most times when I try this fallback OTA flash, I simply get a connection reset at around 100% upload - not even an error message.

cooljimy84 · June 30, 2020, 6:00am

Unless you have some rather advances routing, you can’t have the gateway 192.168.1.1 and a device IP 192.168.20.217.
They need to be on the same subnet…
I.e. both on 192.168.1.X or 192.168.20.X

I would correct that first (unless it was intentional)

Troon · June 30, 2020, 6:31am

Exactly this.

Your subnet mask says that with a gateway of 192.168.1.1, your local network is from 192.168.1.0 to 192.168.1.255, but your static IP for the plug is outside this range. So you need one of:

Static IP and gateway should have the same first three octets (numbers), aligned to whatever your router is set to; or
Subnet mask of 255.255.0.0 for a \16 network, and if you don’t understand exactly what that means, this is not the bullet point solution you’re looking for.

Also, it’s likely that your router will be giving out IP addresses via DHCP. If you’re setting static addresses for your devices (which is a good idea), you should make sure that you either set a static reservation in your router or restrict its DHCP range and set the static IP outside that range. Otherwise the router might give out your static address to another device (phone, for example), whereupon weird things will happen.

mafrosis · June 30, 2020, 7:09am

The network configuration is intentional. 192.168.1.1 is routable from 192.168.20.x.

You are right @Troon that the subnet mask is probably incorrect in this case - I don’t actually remember now why I was bothering with manual_ip in the first place…

Would that config stop the device from connecting to MQTT?

mafrosis · June 30, 2020, 7:18am

Ah that was it. If I don’t include manual_ip, then the upload fails with (example from a different node):

INFO Resolving IP address of 6c8595.local
ERROR Error resolving IP address of 6c8595.local. Is it connected to WiFi?
ERROR (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
ERROR Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -3] Temporary failure in name resolution

Above is correct as mDNS will definitely not work across different subnets.

tom_l · June 30, 2020, 7:19am

If you don’t have a network connection it’s not going to be able to communicate with the mqtt broker.

It’s advisable to use static IP addresses if you can. Makes OTA updates more reliable.

mafrosis · June 30, 2020, 7:22am

I guess the manual_ip option is being used in two different contexts. One is from one’s dev machine when uploading OTA firmware (just the IP address is important), and then the second is when the device has its static IP config set at startup (IP, subnet & gateway).

mafrosis · June 30, 2020, 7:26am

I could see the device appearing in my router UI. It is available on the network.

mafrosis · June 30, 2020, 7:50am

Thanks folks for the advices - seems the manual_ip block was indeed the culprit. I have removed that and now have a working bulb.

Incidentally, and for future readers, on my network "6c8595.local" will not resolve, but "6c8595" will.

This in my config fixed the DNS resolution during an upload (rather than setting manual_ip; which applied incorrectly and broke everything):

wifi:
    ssid: xxxxx
    password: xxxxx
    domain: ""

mafrosis · June 30, 2020, 7:58am

Another one for future readers. The correct manual network configuration is the following (as reported in the logs of a different healthy device):

[07:54:48][I][app:101]: ESPHome version 1.15.0-dev compiled on Jun 30 2020, 07:53:52
[07:54:48][C][wifi:416]: WiFi:
[07:54:48][C][wifi:284]:   SSID: 'xxxxxx'
[07:54:48][C][wifi:285]:   IP Address: 192.168.20.174
[07:54:48][C][wifi:297]:   Subnet: 255.255.255.0
[07:54:48][C][wifi:298]:   Gateway: 192.168.20.1
[07:54:48][C][wifi:299]:   DNS1: 192.168.20.1

Troon · June 30, 2020, 8:17am

Looks like you’re running VLANs or a separate network for IoT items? The key difference here to your original post is that the gateway is now in 192.168.20.x, which aligns with the subnet mask.

It’s still worth setting manual_ip if you have a setup that now works. You’ll find other posts here where things suddenly stop working because DHCP leases have expired and the router’s given out different IPs.

mafrosis · June 30, 2020, 8:28am

Thanks for the tip @Troon

Yes I have multiple VLANs, the “iot” SSID is hidden and has various firewalls in place. Funnily enough I had never configured a static IP since putting this setup in, and so made a beginner’s error