I’m pretty shellshocked with my Iotawatt experience… Have been dealing with it refusing to accept DHCPOFFERs half of the time for a over a year though I could work around it using the zeroconf iotawatt.local address. Many hours with no solutions to what seems to be some kind of general ESP32 type problem. Moved all of the data to a new SDcard w/no difference. Read/verify on the 8g card in it didn’t have any problems. Plenty of space on the card, though data getting to about 1.6g.
The real fun started when I replaced the battery. Now I can’t even get it to associate with my wireless access point. I connect to the captive portal, configure the wireless network, and it just keeps bringing up the captive portal. It’s more or less a brick.
I’m going to pull it out and recheck everything, i.e. that the replacement battery was actually good, etc. but looking for some information from anyone that has looked into what else is out there on the market. The Emporia setup seems to be popular, though depends on a cloud server but can be integrated into homeassistant, though I don’t know if that’s a direct connection to the unit or their cloud (which I do not want), though I admit a phone interface would be nice, but I’ve had too many products that depend on the “cloud” disappear over the years and the devices become bricks.
Feedback appreciated, I’m going to move it to the bench and give it another go before tossing it into the fire.
I never understood why you can’t enter a static IP into these things also.
Background is that you purchased the unit in 2020 and had no issues reported until 2024 when you reported essentially this same problem. At that time, I offered to have you send it in for diagnosis. I quoted a worst-case scenario of $80 if I had to replace the PCB. Never heard from you again.
This problem is a WiFi issue. Possibly the IoTaWatt has a hardware issue, but that is very rare bordering on non-existent.
It’s not the battery as it is only connected to the RTC to maintain the time when the unit isn’t powered by the USB supply.
Given that you didn’t avail yourself of my previous offer to diagnose, and that your inclination is to instead trash the IoTaWatt on this forum, I would recommend you get an Emporia.
Understand though that while the IoTaWatt has reliably collected your usage data through all of the WiFi issues, the Emporia will simply fail to send the data to their server during any outage and it will be lost. Maybe not a good idea until you determine that your WiFi will be reliable with their ESP based unit.
Don’t put it in the fire, especially with the battery.
You seem to be having an issue with your Wi-Fi. Having had them, I know how frustrating they can be.
IotaWatt is based on the esp8266 so it can only be as good as the underlying platform. I have about 30 of them (esp controlled devices) in my house and scattered around the barnyard. They generally work fine, but they REQUIRE a good network. My network has been marginal at some points and my experience with many of my esp devices was less than great at those times. With a good network, my experience with all of them has been great.
The emporia uses an esp32, so I doubt that it is more tolerant of a bad network. You can convert the emporia to esphome, but I don’t believe it will work better than an IotaWatt.
If you still want to put it in the fire, send it to me instead. If you are in the US, I will pay for the postage.
As a followup on this I finally had time to dig in more; I plugged it in and it worked fine. In the interim I’d rebuilt my dns/dhcp (using pihole’s dnsmasq) but I was using a much shorter dhcp lease time than I was using before. and basically the same software just on an rpi5 instead of an rp2. Since I’d done this I’d used a lower lease time of 1 day instead of the previous 7 day lease time.
Wondering if the esp has a problem in there with longer lease times, have not had an issue since using 1d leases and will probably keep it there.
Never any sign of any wireless issues I could always see the dhcp traffic after it associated with the wlan, it would just never reply after receiving the dhcpoffer, and it would always autoconf to a 169.254 address which responded on .local.
I guess if someone else is having this sort of problem they might try lowering their dhcp lease time to see if it makes a difference, I found many espxx articles out there with people having this same problem but noone really had any insight on a solution for it.
Looking at the network traffic I see something that I must have missed before. The IotaWatt does a dhcp discover, then does a dhcprequest, dnsmasq sends a dhcpoffer with an IP (and registers it w/dns) but the iota watt responds with another dhcprequest for “0.0.0.0”, which dnsmasq sends a NACK with “wrong network”, after which the iota watt continuously makes dhcpdiscovers periodically, dnsmasq sends dhcpoffers, and never gets a reply back. The Iotawatt eventually autoconfs to 169.254.x.x which is unreachable from HomeAssistant.
from the dhcp.c if (dhcp_option_given(dhcp, DHCP_OPTION_IDX_SERVER_ID))
and ip_addr_set_ip4_u32(&dhcp->server_ip_addr, lwip_htonl(dhcp_get_option_value(dhcp, DHCP_OPTION_IDX_SERVER_ID)));
Then backtracking to verify that it’s reading in the right option case (DHCP_OPTION_SERVER_ID): LWIP_ERROR("len == 4", len == 4, return ERR_VAL;); decode_idx = DHCP_OPTION_IDX_SERVER_ID;
which shows option 54 and is correct #define DHCP_OPTION_SERVER_ID 54
So this is all correct, when an offer is received, ah light bulb moment, now I see.
When the ESP32 boots it’s starting off with a request for it’s previous address, and the logic to remember the dhcp server IP is only available in an offer response.
Fortunately I did see a work around from another thread to do a discover on bootup:
Well in light of the dhcp bug, I reasoned the iotawatt was able to get a dhcp address when I started digging in to it again was because I’d changed the IP address of the dhcp server. I started another dhcp server and added an IP reservation for it which it took immediately. I shut that down and did the same on the original dhcp server and it took that immediately. Theoretically it should stay there, I assume the bug triggers when it gets a different IP address. If not I’ll give it an indefinite lease.
I know part of the documentation recommends you to do this but for the wrong reasons; it’s written as if you are creating a manual dns entry pointing to the dhcp assigned address, or going under the idea that the TTL of the dns record is causing the client to hold on to it when the address changes.
Switched the update channel to alpha, maybe it will pull down an updated firmware from there? Can’t seem to find where the dhcp code actually lives.
Maybe this will help someone else who runs into this issue.