I have designed my own hardware based on the IoTaWatt published circuit, with minor changes. While awaiting my PCBs to arrive (on a slow-boat from China), I want to start modding and testing the f’ware to suit my changed h’ware.
I’m not a C++ programmer, but have passing familiarity with C programming. I find the sheer number of IoTaWatt source files intimidating, not to mention the C++ code! I have a few initial questions to point me in the right direction (I’ll almost certainly have many more, once I get further in to it!), and would appreciate any advice anyone can offer…
I note from the Documentation that IoTaWatt’s default IP address is 192.168.4.1. I’m assuming (hoping!) this can be changed through the ‘Configure WiFi’ menu (once I get access to that), but to save me the trouble, can anyone tell me where (which source file) that default IP is specified, so I can change the default?
On a related subject, does the WiFi config menu allow changing from DHCP to static IP address (which I prefer in my network)?
Why is an RTC used when the IoTaWatt has an Internet connection, and can thus access the NTP server pool, providing more accurate time than any crystal can keep? I understand there might be times when the Internet isn’t available (blackouts, for example), but a software clock based on the NodeMCU’s time-keeping should keep adequate time accuracy for a blackout duration.
Daniel,
interested: where in oz R U? (I am on N rivers, NSW).
Cannot help with the rest but I am happy with the unit I purchased. Just need to get it talking to EmonCMS now. (Only been working 24H:still finding my way!).
btw, read the docs. All will be clear on how it works then.
Doug, I’m in Gerroa, southern NSW, so some distance between us!
I have been through the manual, but it doesn’t answer my questions, otherwise I wouldn’t have asked. Of course, if I had a working unit I wouldn’t need to ask the first two, as I could play with it and find out.
Won’t have our solar system installed for some weeks yet, so trying to get my IoTaWatt-replacement ready before that.
This IP Address is only used for the initial setup. It broadcasts on its own AP on that address. Once you attach it to your own AP, it is not used. So, no need to change it.
No way to set a static within the UI. This can only be done via a reserve in your DHCP pool on your router, etc. Being open source you can set this up however you would like via your own code.
There are time or circumstances where one will have limited or no Internet access to the device, so it is important to get time initially from NTP (with routine updates), but the IoTaWatt can operate without requiring NTP access for quite some time. Think power outages, internet outages, remote locations without fast internet…
Again as Overeasy, the maker of the device, has said to those going the DIY route, customize it all you would desire, all the code is open and available for modification.
I’m assuming to ‘attach to my own AP’ I will first need to somehow connect to the firmware on the default IP address. It would be so much easier if that IP address could be within my network’s IP range.
That’s if I could understand the original code! If I can’t even find where the default IP address is specified, how can I hope to make significant changes to the rest of network code?
Yes, I acknowledged this in my question. But a typical crystal can provide a time-keeping accuracy of ±15 seconds per month, so once time has been initially set from an NTP server, an internal (firmware) clock based on the NodeMCU’s timekeeping should be adequate, with perhaps daily re-syncs from an NTP server. There are numerous Arduino NTP-synced clock projects freely available. (I demonstrated a modified one in my YouTube video at https://youtu.be/PyDerVMuXDI, which demonstrated the automatic adjustment for the end of daylight saving in Hungary.) I have since abandoned that ‘World clock’ project, but I could still adapt the basic code for my IoTaWatt derivative.
Reread @quella’s response concerning this. You seem to be disoriented with respect to the network topology during WiFi configuration and subsequent normal operation on the local LAN.
It’s a big complicated firmware with a lot of modules, but the WiFi connection is tone of them. IoTaWatt uses a class called WiFiManager to establish the WiFi connection. The red-herring IP address you are looking for is declared in that source. You can find it on Github here.
IoTaWatt keeps time using the internal clock of the ESP8266. It syncs to the internet hourly when possible. The RTC is there to quickly recover from power failures and allow operation without internet.
Thanks for your comments, and thanks again for making the code available under a GPL. Yes, it is big and complicated, and my 76YO brain struggles to comprehend sufficiently to change stuff. But maybe with your (and others’) help I’ll get there.
The two major changes I’ve made for my hardware are: (1) drop the RTC (batteries on a PCB are a pain), and (2) add a W5500-based Ethernet module, plus a jumper to a NodeMCU pin determining whether to use wi-fi or Ethernet.
I recognise that I’ll lose some minutes of data after a blackout, but most of our blackouts are quite short (several seconds, usually during storms), so the broadband modem on a UPS will sail through those, and not lose the Internet connection. For the longer blackouts, I’ll put up with the loss of time-stamped data-collection.
If I had the programming skills, what I would do is, when the system powers-up without an Internet connection, save data (perhaps in internal flash) with a ‘temporary’ timestamp (based on Arduino’s Millisecond timer), and when real-time is re-acquired, go back and correct those timestamps and transfer the collected data to SD card. Just a pipe-dream at this stage!
I haven’t been able to locate a good, up-to-date, PDF user guide for either VSCode or PlatformIO, so perhaps a reader familiar with this pair can enlighten me…
If I wish to add some C code to my IoTaWatt project, can I just drop new .C and .H files into the project’s IoTaWatt folder, and PlatformIO will automatically include them in the next Build, or must I edit some .mak file or similar?
Daniel, great that you are trying to develop a new fork with different features. That is what open source is all about.
Perhaps it would make you learning curve easier if you first get familiar with VSCode/PlatformIO with some simpler project. And "can I just drop new .C and .H " would suggest that you also need to understand general programming. Again simpler project will help.
Overeasy C writing is very advanced and very efficient. Trying to change the code to accommodate a W5500 will be very difficult. And frankly not necessary. Just add a wired bridged cheapo AP close to your unit.
The firmware, as is, will run fine without a RTC, but you will miss the best feature of this energy meter, gap-less measurements. And “batteries on a PCB are a pain”. Why?
Your comment (above), together with the earlier one from Bob:
give me great comfort!
After building the (unmodified) IoTaWatt firmware and downloading it to a stand-alone NodeMCU (I only received my PCBs today, and haven’t yet assembled one), I was worried when I saw (via the serial port) that the program hung when it couldn’t find an SD card. That in itself didn’t worry me, since that issue would be solved when I build my first prototype, but I worried that the same might apply when the firmware cannot find an RTC.
Your and Bob’s comments have allayed that fear.
As for adding a nearby AP, I had already decided to do that some time ago, recognising that I might take a long time to successfully modify the firmware to use an external Ethernet module. I have an unused VDSL modem/router/W-AP that I will plug-in to the existing Ethernet socket in the garage, where the inverter and WattsOn (my version of the IoTaWatt hardware, subtitled “The energy detective’s assistant” ) will be installed.
The router portion of that modem/router will also provide additional ports for later hard-wiring WattsOn and the inverter, if ever I manage that code modification (the inverter will also initially connect to my network via wi-fi).
Thanks for your suggestion about starting my VSCode/PlatformIO learning on a simpler project. I’ll have a look for some tutorials and give that a go, now that the time pressure is off for modifying the IoTaWatt firmware to suit WattsOn. (I should be able to operate from day one of my solar installation using just the standard IoTaWatt firmware, based on your and Bob’s comments.)
Batteries on a PCB are a pain because, sooner or later, they have to be changed! Worse still, sometimes they leak and damage the PCB, though that’s less likely with modern Lithium cells, assuming IoTaWatt warns when the battery needs replacing.
OK, having received my PCBs, I’m about to build my first WattsOn prototype.
But I first wanted to check how easy it might be to change the firmware to use my different pins for the diagnostic LEDs, or whether I should hack the board back to use the original pins. It looks like I can easily change the pin assignments (in iotawatt.h), but I’m confused by what I see there…
Looking at those numbers, I’m assuming they are ‘GPIO’ numbers. But the CS_ADC numbers don’t correspond to the circuit diagram (neither v4.4 nor 5)!
In the circuit, ADCCS0 comes from GPIO2, and ADCCS1 comes from GPIO0. Or am I missing something?
At the same time, I’m wondering why GPIO16 (also used for the NodeMCU’s ‘INBUILT’ LED) was used for the red LED, and GPIO0 (also shared with ADCCS1 according to the circuit) for the green, when there are unused GPIOs on the other side of the module (e.g. GPIO9 & 10)?
No, I meant WattsOn, which is what I have named my hardware, to distinguish it from IoTaWatt, being somewhat different (and also your registered trademark).
I’m glad I’m not going mad when comparing your schematic and firmware defines. And thanks for the info about the NodeMCU’s use of GPIO9 & 10 for flash memory – I didn’t know that important piece of information!
I’m experiencing problems with the NodeMCU modules I bought for this project. Once installed on the PCB, even with most of the other devices not yet installed, it comes on in boot-load (flashing) mode, no matter what I do.
Even a second stand-alone NodeMCU (not on my PCB, and not connected to anything other than the PC via USB) frequently gives ‘failed to connect’ errors (a few different messages) when trying to flash it, whether from VSC/PlatformIO or the Arduino IDE (simple ‘Blink’ program). I’m beginning to think the Lolin NodeMCU v3 implementation is a bit ‘flaky’.
Can anyone with experience of various NodeMCU brands/types recommend a specific brand/model that is reliable?
I’ve probably used six or more different nodeMCUs with ESP12E and ESS12S. Thousands with ESP12S. What I can say is that there is no model/manufacturer that has not worked fine. Sure I’ve had a several bad apples, but no pattern of particular model/manufacturers. I’d suggest you look elsewhere for the problem.
UPDATE: it occurs to me that one thing the units I have used have in common is that they all use the CP2110 USB to Serial chip. Also, there are nodeMCUs that use dubious unlabeled CP2110. That chip would be directly related to boot loading.
Bob, that’s very reassuring considering the number of NodeMCUs you have used. The Lolin NodeMCU v3 uses the CH340 USB chip. I wonder if that makes a difference? I’ll start looking for one with the CP2102 (I presume that’s the one you meant).
Even with one of these NodeMCUs in isolation (just sitting on the desk, connected only to the USB cable), I frequently get these sort of errors (sometimes other comms errors) from the Arduino IDE when trying to upload a simple Blink program:
esptool.py v2.8
Serial port COM17
Connecting…………………____Traceback (most recent call last):
File “C:\Users\Daniel\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4/tools/upload.py”, line 65, in
esptool.main(cmdline)
File “C:/Users/Daniel/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/tools/esptool\esptool.py”, line 2890, in main
esp.connect(args.before)
File “C:/Users/Daniel/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/tools/esptool\esptool.py”, line 483, in connect
raise FatalError(‘Failed to connect to %s: %s’ % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
the selected serial port _
does not exist or your board is not connected
While the IDE is trying to establish a connection, the NodeMCU’s blue LED blinks in short bursts, several times (presumably the IDE sending messages to try to connect), before the IDE gives up with the above message. But the blue LED is on D4/GPIO2/TX1, whereas USB comms go via RX/TX0, as I understand it.
I’ve tried a different USB cable and a different USB port, but still often (not always) get comms errors. I’m not sure where to look other than getting and trying a NodeMCU with CP2102 chip.
There are other differences between the V3 and V4, most noticeably the form factor. I have always used the V4. I had a few V3 early on, and as I recall the CH340 was a lot slower upload speed. With the CP2102 you can upload at 921600 and run the serial at 115200.
The form factor is probably going to be an issue for you as the V4 is narrower than the V3.
Thanks again for your further information, and your willingness to share – much appreciated. I now have some NodeMCU modules using the CP2102 on the way, expected in a few days, so I’ll see how they compare.
I’ve been trying to solve two separate problems with the NodeMCU:
Even stand-alone I often couldn’t ‘connect’ for uploading or downloading.
Mounted on my PCB with other modules/components, it wouldn’t run the loaded program, and seemed to always come up in flashing mode.
After much experimentation I’ve decided #1 is probably due to some Windows 7/USB port issue. I found that by repeatedly unplugging and re-plugging the USB cable, then testing, I could get the NodeMCU to talk to the Arduino IDE eventually, and once it did, I could upload and download at 115200pbs until the cows came home.
And issue #2 was indeed due to my additions. I had connected my W5500 Ethernet module to the NodeMCU’s SPI pins (S1, SC, S0, SK). But now I learned that those pins are used for the NodeMCU’s internal serial flash memory! I curse the amateurs who designed this module, and their absence of good documentation for it!
So I’m abandoning my wired Ethernet option, and will have to settle for the wi-fi-only comms, as you designed. With a separate wireless AP already installed in my garage (where the solar inverter and monitor will be), I don’t expect any serious comms issues.
The ESP32 has three SPI Busses. Like the ESP8266, one is used for the flash memory (it is documented in several places). The other two are available. There’s are several tutorials available that describe how to use an SPI Ethernet interface. Unfortunately, my ESP32 project uses both of them for other purposes.
One is used for continuous sampling of the ADCs by one of the processors that is dedicated to sampling. So at 100% utilization, not otherwise available.
The other is used for SDMMC to access the SD card. I don’t believe it’s possible, or at least practical, to try to support Ethernet simultaneously. I think the SPI needs to be dedicated, but not completely sure of that.
Yes, I did momentarily think about connecting the Ethernet module to share the SD card’s interface, but quickly abandoned it (before seeing your comments) thinking it might be too much for the software to keep up with.
So now I’ve disconnected the Ethernet module and reverted everything back to ‘IoTaWatt standard’ connections, though without an RTC (I’ll add that back in the next PCB revision, now I have the NodeMCU pins back).
So I compiled your program, successfully uploaded it to the NodeMCU, and started bench-testing (no CTs or VT connected), just to see if everything works correctly. I was able to connect to it via smartphone, and thereby connect it to my AP in the garage.
But when I try to log-in to http://iotawatt.local, my browser shows a white page with just this text on the first line:
Not found: GET, URI: /
The other symptom is that there is negligible LED illumination (the two LED colours are working fine, flashing various red/green errors as it worked through the setup steps). But now it’s almost (not quite) dark. There’s a very faint green illumination blinking short-long, then repeating (the long phase is about 3-4 seconds long).
Any suggestions on how to connect to IoTaWatt through the browser?
) will be installed.