Hi Jan,
Stab from the past. I thought you were all set. Interest is picking up on three phase. Since you have been at it longer than anyone, maybe you could share some insights to other three phase users. For those who haven’t followed this thread, Jan built homebrew units with three native voltage inputs specifically for three phase. This was before I had developed the current approach of going straight into input channels with a simple adapter. Both seem to work equally well.
Communication issues seem to go with the territory with the ESP8266. I like to use the expression: “Things happen, it’s what you do about it”. So I’ll try to convey a little IoTaWatt philosophy to put this all in perspective.
The ESP8266 runs the WiFi stack in a separate layer of code that is pretty much independent of everything else. Whether the ESP is connected to WiFi or not seems to be more of an opinion than fact. The application can, and I do, register a callback to be notified of a change in status, yet I rarely get the call, and it always seems to be late. From the moment power is applied, the low level WiFi code starts working to establish and maintain the connection, even before the application is formally running. It does a pretty good job, seems to recover well, and is tenacious about retrying.
I could ask a dozen question to narrow this down, but the ultimate question is whether the data eventually gets uploaded completely. The latest release (02_02_27) is pretty robust. When starting the Emonservice, it reads the status of your Emoncms node from the server and picks up at the last known upload time. There should be no holes.
If the IoTaWatt is truly disconnected, i.e. the WiFistack has issued the disconnect callback, your LED will change from a dull green glow to a dull red glow. When the connection is restored, it will revert to green again. Throughout this, the integrity of the data upload will be preserved, and sampling to the local datalog will continue.
When data upload fails, there is a 10 retry sequence that takes up to an hour. During this sequence, the timeout is increased and the delay between retries increases progressively. Upon failure of the tenth retry, the IoTaWatt will restart.
I’ve got an IoTaWatt in an unheated outbuilding on the outer fringes of my WiFi coverage. It monitors my meter and it’s a trainwreck when it comes to communications. Doesn’t work for days in bad weather, rarely stays current for more than a few minutes, and connects and disconnects constantly. My feeling is that if this thing maintains data integrity to Emoncms, anything can. It pretty much does.
The key here is what the LED is doing. If it’s Red-Green-Green, then the firmware is running WiFiManager to connect. Regardless of whether you are accessing IoTaWatt as an AP or STA, you are using an IP to address it. The difference is that in AP mode, you are talking directly to the IoTaWatt (on IP 192.168.4.1) as opposed to an IP assigned by your WiFi router via DHCP. Sometimes there’s a latency after reboot where the IoTaWatt firmware has invoked WiFiManager to establish a connection, and the underlying WiFi stack has succeeded in reconnecting to the last known network. That does resolve after a few minutes. Once again, all of that is at lower levels, so you just have to go with the flow.
You’ve probably run into this already, but I have to caution you about the latest Git version and the appropriate core. Since02_02_24, I’ve been using the “staged” arduino/esp8266 core. I switched to this to get the Krack vulnerability fix, but this version of the core has a lot of other changes, some of which are not compatible with the older core. I had to change a few things in the process such that the latest version in the Git probably will have problems running on the old core. The platformio build using the staged-core is what’s reflected in the official releases. Anything else could have problems.
I’ve unilaterally decided that the plural of IoTaWatt is IoTaWatt, as in “I have three homemade IoTaWatt running.”.
) The 3th iota has this code on it (but i restarted it manually before it tried 10 times), so i’ll look what it does (and i’ll flash the others to this version if it solves the problem) 
) share the same type of pcb board, so they all have 3VT connected through a dedicated CT connection (basically a copy of the primary).
