Advice for a esphome newbie

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 :smile:

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):

  name: c0a4b4
  platform: ESP8266
  board: esp8285

  devicename: Kogan Plug 1

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


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




  - platform: sntp
    timezone: Australia/Melbourne

  broker: ringil
  keepalive: 60s
  discovery: true

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

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

  - platform: status
    name: ${devicename} Status

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

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

  - platform: hlw8012
      number: GPIO12
      inverted: true
    cf_pin: GPIO04
    cf1_pin: GPIO05
      name: ${devicename} Current
      unit_of_measurement: A
      name: ${devicename} Voltage
      unit_of_measurement: V
      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
      - multiply: 0.001
    unit_of_measurement: kWh

You can get logging OTA in ESPHome.

Try specifying the mqtt broker by IP address.

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” :yawning_face:

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

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:✓&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.

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 :crying_cat_face:

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

Unless you have some rather advances routing, you can’t have the gateway and a device IP
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)


Exactly this.

Your subnet mask says that with a gateway of, your local network is from to, 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 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.

The network configuration is intentional. 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?

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:
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.

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.

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).

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

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):

    ssid: xxxxx
    password: xxxxx
    domain: ""
1 Like

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:
[07:54:48][C][wifi:297]:   Subnet:
[07:54:48][C][wifi:298]:   Gateway:
[07:54:48][C][wifi:299]:   DNS1:

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.

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 :smile:

1 Like