Unit down: green light, no sending, no webserver - resolved


Thank you for the fast answer. You are doing a great job.
As mentioned, the problems started on September 23rd. I concluded that because until then the records at emoncms worked. On the 26th of September, we came back from vacation and I tried the first time to bring Iotawatt back in operation. I turned off the power several times and turned it back on, switched off the Wi-Fi network and started IotaWatt as an AP and reconfigured the WLAN. Possibly this has destroyed the files when switching power on and off. I removed the SD card yesterday for the first time, of course, without power.
So I will insert a new SD card and see if the device works again.
Regarding RSSI: Iotawatt is mounted in an electric control cabinet. This is, unfortunately, an allmost perfect Faraday cage. The router is not far away, but there are still some concrete walls in between. I’ll see which devices are also transmitting on channel 11. How can I change the channel at IotaWatt?
I’ll contact you.
Thanks again for the great performance.

Update: Because I have no other SD card, I have reformatted the old card. I have uploaded the files. emoncms works again, the data are transferred. The green LED has green steady light and flickers. The blue LED close to the plug has steady light, the blue LED on the WLAN module flickers. I can not access the web app with Iotawatt.local. I can only call it with the IP address. Then the web interface with the four menu items appears. Mouseover will work as well, the menu items will appear, but the app will not respond to any commands (klicks).
I will send you the new SD-files PM.


I got the files, including the message log, thanks.

It looks like the IoTaWatt is sampling OK, recording the data in the datalog, and having some success posting to your local Emoncms. That’s good.

I see that you changed to WiFi channel 6 (or auto which resulted in 6) but the RSSI has not improved. -87db is terrible. I’m surprised that you are able to do anything, and that you are able to post to Emoncms. All of the functions you describe about the configuration app - mouse over, dropdown menu etc. are local javascript responses and don’t indicate any successful communication with the IoTaWatt. There are reasons why mDNS might not work (iotawatt.local) but if they have worked before and nothing changed with your browser, it’s probably the poor WiFi connection that is to blame. That protocol requires a broadcast to all devices on the network and a response from the named unit within a specific time.

As long as the IoTaWatt is enclosed in a metal cabinet, I expect you will continue to have problems. If it must be in a box, a plastic box is recommended. Getting the RSSI down to the mid 70’s would be the goal. In the meantime, the IoTaWatt does appear to be measuring, logging, and posting the data.


Now Iotawatt is 2 m next to the router and it does not change anything. The error remains. The whole installation worked well until September 23rd. It is unlikely that now the reception is suddenly too weak.
Unfortunately, I am not a GitHub specialist. I tried to find the history of the firmware updates, but did not come to any conclusion. My guess is that on September 23, an update has been made. Would that be a possibility?
Another possibility is that the file has become too large as described above and everything has been broken.
I see almost no other option than to re-play the firmware. Can I do that via the USB port? Maybe it would work again with a newer version. Or do you have another idea?


I never used mDNS until now, before I used allways the net adress. I took Iotawatt back home without the sensors, only with the reference voltage. This is perfect received from emoncms.


Your unit updated from 02_02_30 to 02_03_13 on September 12. It was initially unable to reconnect to WiFi after restarting with the new firmware, but did a self-restart after an hour and succeeded.

It then ran for without incident until sometime between September 23 and September 26. The message log is scrambled for this period. In any event, it had run perfectly for at least 10 days.

Sometime during that period, there was a power failure (or the unit was unplugged) and from there on problems developed. The last log that you posted does not contain full context, but shows the unit being powered up October 2 09:51. The datalog service did not start properly, so I am assuming the log was damaged. WiFi disconnected about 9:56.

The unit was powered up again a minute later, then restarted spontaneously after two minutes, apparently waiting for WiFi configuration/connection.

It was then powered on less than a minute later (9:59). There appeared to be a new datalog and history log. Posting to Emoncms began effective at 9:55. There was at least one successful posting to Emoncms.

There was a subsequent power cycle at 11:21. All indications are that prior to that it had been sampling and logging and posting to Emoncms right up to the power cycle. The restart was unremarkable, and posting was resumed as of 11:21. The RSSI was -84db at the time.

Everything has not been broken.

The firmware is running fine.

At this point my impression is that the problem is you are unable to use the local configuration utility. Is that right? The log that you posted shows that everything is working fine otherwise. Can you see your data on your Emoncms system and is it updating?

What happens if you browse to:

I appreciate that you are trying to take some initiative to get this going again, but you don’t have the benefit of understanding the fundamental operation of the device, and the full extent of the diagnostics that are in the firmware. I can work through these kinds of problems to solve them and to make the device better in the process, but it is a slow and understandably frustrating process for the user whose device isn’t working. There are a lot of variables that I haven’t touched upon yet that could be causing this, and I’m not sure I even understand what problem you are experiencing right now.


Sorry, I did not express myself well


I just started Iotawatt (switched power on) and made some screenshots from emoncms. You can see that communication is o.k.

It is difficulte to make a screenshot of the web app. I will try it.



Two things.

1.) I’m trying to diagnose the problem there.

  1. Looking at your emoncms feed list, I see that you have been using an unusually high amount of kWh:

Do you have any idea what happened there? Can I see an Emoncms plot of one of those feeds over the past month to see if that that happened as a result of this event and exactly when?


Yes, that is right, is correct.


It may happen because no sensors are connected. The sensors are in the electric cabinet at work, I am at home with Iotawatt.


Do you need something more from me?


OK, The feed list query worked fine, so there must be something else hanging up the application.

You said that the application loads OK and the mouseover works etc.

So what happens when you try to:
Display the message log?
Click on configure inputs?
Try to run the graph app?

Can you try:

The plot of the kWh feeds looks OK through Sept 21. Can you do it again including the period from Sept 23 to now where all this happened?



With mouseover the aditional menu items appear, with the klick on one it makes a slight movement but nothing happens. I have a short film but can not send it (mp4).


it may not be complete


OK, that shows corruption in the Emoncms kWh feed that occured on Sept 23 at 10:40 am. That’s consistent with the timeframe of the IoTaWatt problem. So your Emoncms kWh feed will need to be cleaned up. Not an expert there, but I believe you can delete them and they will be recreated, or if you have history that you want to keep, you can specify new feeds in the input process lists and start new feeds from now while leaving the old around.

I also suspect now that there is a similar problem in the IoTaWatt history file that is causing huge values to stop things from working. I can see how something like that can stop the status display, but I don’t see how it could effect, for instance, displaying the message log.

So can you try:

If that works, can you try refreshing the browser app and selecting Tools -> Message Log without anything else preceeding it?


That works


I did it: --> enter --> mouseover tools --> klick on message log
and nothing happend…


OK, one last thing: