The pi is a whole different situation. I had one early adopter with the same problems and he loaded his Emoncms instance onto a windows machine. Problems went away. I don’t doubt that given enough time, the response will come. The problem is that IotaWatt blocks and doesn’t sample while waiting for that response. So it’s a tradeoff. Some amount of retries vs more frequent sampling. 500ms seems to work for Emoncms.org.
Maybe that’s another good reason to take another look at asynchronous posting.
Just to include some info.
I have a local emonpi and a new iotawatt. this morning the iotawatt was not posting data but other devices were.
I logged into the iotawatt and changed the “webserver” to “none” then saved and then back to “emoncms” and it started posting again with no other changes.
here is a snipit of the log
10/31/17 05:25:36 EmonService: GET failed. HTTP code: read Timeout
10/31/17 05:26:36 Resending EmonCMS data.
10/31/17 05:26:36 EmonService: GET failed. HTTP code: read Timeout
10/31/17 05:27:36 Resending EmonCMS data.
10/31/17 05:27:36 EmonService: GET failed. HTTP code: read Timeout
10/31/17 05:28:36 Resending EmonCMS data.
10/31/17 05:28:36 EmonService: GET failed. HTTP code: read Timeout
10/31/17 05:29:36 Resending EmonCMS data.
10/31/17 05:29:36 EmonService: GET failed. HTTP code: read Timeout
10/31/17 05:30:36 Resending EmonCMS data.
10/31/17 05:30:36 EmonService: GET failed. HTTP code: read Timeout
10/31/17 05:31:36 EmonService: stopped.
10/31/17 05:31:36 EmonService: started.url: 192.168.1.215/emoncms, node: IotaWatt, post interval: 10, unsecure GET
10/31/17 05:31:36 EmonService: Emonlog file created.
10/31/17 05:31:36 EmonService: Start posting from 1509427895
Thanks for the info. I’m looking into this problem. Can you verify the version of iotawatt software you are running?
Firmware version: 02_02_21
I have also noticed something similar and offer the following in the hope it may useful.
The IoTaWatt was started pm on 23rd November but during the evening of 31st the desktop PC appeared to loose connection with iotawatt.local. Checking with an Ipad (2ft away from the IoTaWatt) gave the same result. Eventually it was decided to restart the unit. Although connection with iotawatt.local was established only the voltage configuration setting was present and this indicated 120V instead of 240V! Since then, connection with iotawatt.local can only be described as erratic and variable. The Firmware version is indicated as 02_02_21. I have managed to get a copy of the log file covering the period 11/1/17 08:50:08 to 11/1/17 10:13:12. A ping check to iotawatt.local reveals: rtt min/avg/max/mdev = 78.351/158.996/260.102/61.930 ms. A previous ping result prior to the current situation provided a fairly consistent figure of 13.1 ms.
Do you mean the configuration app stopped updating?
I know it sounds counterintuitive, but it doesn’t matter the distance between the Ipad and the IotaWatt. The IotaWatt is communicating through your WiFi router, so when you use the Ipad, the IotaWatt communicates with the router and the Ipad communicates with the router. There is no direct link. I have an IotaWatt in an outbuilding, and I can’t access it locally when it rains, even if I am outdoors right beside it. When the rain stops, the IotaWatt connects back up.
So I’d look to see the distance between your router and the IotaWatt. All the generic advice for WiFi range applies. If your IotaWatt is having connection issues, you will see the LED turn red from time to time. Also, the message log will have disconnect and connect messages.
The solution is to relocate the WiFi router, or install a range extender.
Your basic problems appear to be connectivity with the router, but this is troubling. There should be no alternative config file on your device. Are you sure you are not accessing the demo app at iotawatt.com?
The router and iotawatt are located in adjacent rooms and about 3.5m apart. What I find puzzling is why the problem started after 8 days of successful continuous operation.
That said, I think I may have stumbled upon a solution. A search suggested that there could be channel interference especially if the router is set to AUTO. This is exactly what I found, so I changed it to Channel 1 and rebooted the router. Thankfully, Iotawatt.local now responds more like it did and seems to be reliable as well.
As far as I can recall iotawatt.local was being used, but I also tried the IP address for the iotawatt.
Glad your problem is resolved.
Me too. 
Very resourceful. Any idea what channel was being used when the problems were present?
So let me understand this. You had a configured the IoTaWatt with multiple inputs configured. After the communications problems started, your configuration reverted to one with only a 120V VT channel 0 configured?
If that’s the case, I would very much like to see the logfile. You can download it using 
The left column will show your SD file system:
In the above example I previously clicked on the + next to the iotawatt directory entry to expand it. The message log is iotamsgs.txt. If you right click it, you will be able to select “download”. If you could upload a zip of that, I can look at the whole picture.
I checked all of the recent releases and didn’t see where a config file was distributed. There is no code that I recall that produces a barebones config. So this is very curious.
Did you subsequently reconfigure your IotaWatt or did your original configuration reappear?
I’m still having intermittent issues with the “Input Channels Status” coming up blank. When I logged on to emoncms today, it shows it hasn’t received anything for 37 hours.
iotalog.txt (255.5 KB)
Brian
@overeasy The problem is probably something else, but I would suggest that the code in the emon push service be updated to have a exponentially increasing timeout or at least a configurable timeout. Currently it is set to a fixed timeout of 500msec (http.setTimeout(500)) which may not be sufficient in all cases causing POST to timeout every time where it would otherwise work if waiting for longer.
I came across this in my homebrew PVOutput push service. I found it kept timing out just because the http request had a long response time. I understand that waiting for a long time will reduce accuracy since it stops sampling during this period, but some of us living with large ping times will at least still be able to use it. It could also help remove this as a possible cause of issues.
Also as a much larger improvement later in the future, to improve accuracy with long timeouts you could move to an async http request instead of a synchronous one.
Brian,
There’s something else going on here that I’m following up on several fronts. But first:
Don’t change your server away from Emoncms. If you do, it won’t upload that 37 hours when you get past this.
Try going back to unsecured GET.
You can try restarting. Look closely after restart. Even though it may be logging timeouts, it may still be succeeding on retries. Check the Emoncms inputs to see if it’s posting.
Try looking at your data with the local graph app. It should all be there.
I have a diagnostic release in the oven that I want you to load. It does a little more with the reytries and increases the timeout after several retries. At this point, I don’t think that’s your issue, but it will be good to know.
Another user had similar issues and changed the default channel that his WiFi is using. I have never had trouble with that, but it might be worth a try. I’m looking into adding some WiFi statistics including channel to the status screen.
Keep me posted.
All good suggestions. I already have a diagnostic version that has increased timeout on retries. Also, treating a single successful retry as business as usual and not logging it. That’s 99% of the log entries, except like Brian’s case where it just seems to be locked up. The new version will restart after an hour of failed communication.
I’m looking into Async TCP, but sometimes the cure is worse than the disease. We’ll see. On the one hand, long blocking I/O’s supress sampling. On the other, interrupts during sampling cannot be tolerated. I’ve tried disabling interrupts during sampling but am plagued with wdt events after re-enabling. The IotaWatt is sampling 66% of the time, so the odds of interrupting sampling for asynchronous events are high. Best I can do right now is detect when the sampling was interrupted and discard the sample.
That’s one of the reasons I’d eventually like to move to the ESP32 - dual core.
So far, these communication problems are not epidemic. I’m going to work through the details and hopefully iron them out quickly.
I researched this and found that, at least in my case, most transactions were completing in about 260ms +/- 20ms. Then all of a sudden I would get one of these timeouts. So I increased the timeout to 1000ms. - same thing. All of the successful transactions were in the 260ms range, but now the timeout was > 1000ms. Conclusion - I could wait till the cows come home and never get a response. Back when I had the timeout lower, increasing to 500 was helpful, but I think that strategy has reached the point of diminishing return. Seems to work much better to just cut losses at 500ms and resend.
All that said, there could be other things increasing the time in someone else’s circumstance. In the case above, the input status screen doesn’t respond, and the log shows problems with connecting to the update server. So I’m suspicious of a problem with the WiFi connection.
Once access to iotawatt.local had been re-established, I checked the settings and found it was not necessary to reconfigure anything.
I reviewed the log. The communications are a disaster of errors that reek of poor WiFi connection, yet it appears the device was still making headway uploading. On the restart on 11/1 17:00, it seems to have updates to nearly current over the previous 17 hours. Don’t know when you captured this log, but seemed to be running reasonably well at the last entry 11/1 23:11.
When you graph it on Emoncms, is it all there?
As far as I could tell there was no missing data. Unfortunately, whilst continuing to set up emoncms I somehow managed to lock it up and had to start from the beginning to rectify the situation 
Thankfully, things seem to be working OK at the moment.
hello EVERYBODY,
THANK YOU ! for this great job to create IOTAWATT !
recently, we was buy one piece at my company site office.
we are very happy with tool/software, but also need some help from all of users if is possible:
- first of all, display of numerical values of measurements is changing too quickly, so can t read the value at one moment; unfortunately, display of those numerical values is freezing after some time
- we understood very well principle of DERIVED REFERENCE measuring in three phase; what is not clear for the moment is how we can have measurement/graphic recording from all 3 three phases as voltage .
- difficult for us to choose/understood (the way to) web service on EMONCMS based in credential that we have at the moment that we was buy an IOTAWATT hardware as soon as lot of CT’s.
thank you for all persons who can help us with firs problems faced .
You might be better off posting on the IoTaWatt forum for support specific to those devices.
There is also a list of resource links on the OEM shop sales page for IoTaWatt
we can certainly help you with any emoncms type issues (for example).