I tried this with both the 1.14.3 version and 1.15.0-dev version, but I am unable to upload the firmware via OTA.
Checking size /data/3rd_bedroom_lamp/.pioenvs/3rd_bedroom_lamp/firmware.elf
RAM: [===== ] 46.0% (used 37724 bytes from 81920 bytes)
Flash: [==== ] 41.1% (used 420636 bytes from 1023984 bytes)
Creating BIN file "/data/3rd_bedroom_lamp/.pioenvs/3rd_bedroom_lamp/firmware.bin" using "/data/3rd_bedroom_lamp/.pioenvs/3rd_bedroom_lamp/firmware.elf"
========================= [SUCCESS] Took 35.74 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of 3rd_bedroom_lamp.local
INFO Address in use when adding 169.254.114.152 to multicast group, it is expected to happen on some systems
INFO Address in use when adding 169.254.217.137 to multicast group, it is expected to happen on some systems
INFO -> 10.16.0.52
INFO Uploading /data/3rd_bedroom_lamp/.pioenvs/3rd_bedroom_lamp/firmware.bin (424784 bytes)
Uploading: [= ] 2%
ERROR Error sending data: [Errno 32] Broken pipe
After trying to upgrade the firmware attempt, the notification of new firmware availability goes away , I still see in the device logs that the device is reporting to be using 1.14.3. I don’t think that the firmware is loaded successfully as the changes do not get reflected in the logs
It looks like 3rd_bedroom_lamp.local is not resolvable by DNS. What happens when you ping that name?
Do you get a correct IP address?
EDIT: Did not look close enough. It either is your DNS or your DHCP server. Maybe your DNS server is translating the hostname correct but resolves a 169 address because the device did not get a good IP address from your DHCP server. Look into those two things.
1 Like
I think the IP address is getting assigned correctly.
I am also able to ping the domain name successfully
PING 3rd_bedroom_lamp.local (10.16.0.52) 56(84) bytes of data.
64 bytes from 10.16.0.52 (10.16.0.52): icmp_seq=1 ttl=255 time=3.29 ms
64 bytes from 10.16.0.52 (10.16.0.52): icmp_seq=2 ttl=255 time=2.84 ms
64 bytes from 10.16.0.52 (10.16.0.52): icmp_seq=3 ttl=255 time=4.14 ms
This is my yaml file
esphome:
name: 3rd_bedroom_lamp
platform: ESP8266
board: esp01_1m
wifi:
manual_ip:
# Set this to the IP of the ESP
static_ip: 10.16.0.52
# Set this to the IP address of the router. Often ends with .1
gateway: 10.16.0.1
# The subnet of the network. 255.255.255.0 works for most home networks.
subnet: 255.255.255.0
fast_connect: false
domain: .local
power_save_mode: NONE
reboot_timeout: 5min
networks:
- password: <<redacted>>
ssid: <<redacted>>
use_address: 3rd_bedroom_lamp.local
logger:
api:
ota:
web_server:
port: 80
light:
- platform: binary
name: "3rd_bedroom_lamp"
output: output_component1
# Ensure the light turns on by default if the physical switch is actuated.
restore_mode: ALWAYS_ON
output:
- platform: esp8266_pwm
id: output_component1
pin: GPIO5
Your IP range is class a, which normally uses subnet 255.0.0.0.
Subnet 255.255.255.0 is class c and in normal households is used with a 192.168.x.x ip range.
Maybe you can try to connect the device via USB and use DHCP to see what the device gets.
I also suggest you to slim down your config to the minimum, build your config back up piece by piece to track down the problem. You could also check your other wireless devices what kind of ip configuration they get.
Good luck!
I am trying to migrate all my devices to 192.168.x.x. Which is why I started to redo the configurations, and have been running into issues. Some of my devices are smart switches(already mounted in the walls) and do not have access to the pins, so USB access will be difficult. I will try trimming down the file and build it from bare minimum and see how that goes. Will keep you posted
@heartkingz, I do not think there’s any IP connectivity issues. This same configuration has worked for almost a year in the past. Plus, I have other Wi-Fi devices in my home and they seem to work fine. There’s something that has either changed in the HA release or in the esphome code. Which I can not figure out.
I tried slimming down the config, on a smart plug(different than the original device in the logs above), get the error.
Here are the logs -
[12:31:21][D][ota:072]: Starting OTA Update from 10.16.0.13...
[12:31:23][D][ota:243]: OTA in progress: 0.1%
[12:31:24][D][ota:243]: OTA in progress: 0.7%
[12:31:26][D][ota:243]: OTA in progress: 0.8%
WARNING Disconnected from API: Timeout while waiting for message response!
INFO Address in use when adding 172.30.32.1 to multicast group, it is expected to happen on some systems
INFO Address in use when adding 169.254.114.152 to multicast group, it is expected to happen on some systems
INFO Connecting to frontdoor_lamp.local:6053 (10.16.0.55)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Address in use when adding 172.30.32.1 to multicast group, it is expected to happen on some systems
INFO Address in use when adding 169.254.114.152 to multicast group, it is expected to happen on some systems
INFO Connecting to frontdoor_lamp.local:6053 (10.16.0.55)
INFO Successfully connected to frontdoor_lamp.local
I figured it out. I did not need to upgrade to the dev branch. I just had to change the settings on the WiFi Router to use 802.11g mode instead of mixed mode. I had read it somewhere else on one of the GitHub pages for esphome issues
Here is the link - https://github.com/esphome/issues/issues/156
2 Likes
@heartkingz Thanks for your suggestions. It pushed me in the right direction for the solution!
1 Like
Perfect! Glad you came back and posted the solution. That’s how we can help others. Thank you!
1 Like
