IotaWatt 4.0

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