Not sure, especially if you’re using Pio… should be pretty solid.
Master branch of emonESP from GitHub right?
The plot thickens.
Having success with Tasmota I thought I would try the EmonESP sonoff firmware.
I used the precompiled version here.
That works perfectly and I have not had a reset for about 10 minutes so far.
excellent.
The ‘timer’ branch of emonESP is designed to work with the smart plugs.
Unfortunately I need the branch that works with EmonTx.
Thanks Dan
First I tried compiling with your platform ini. Compile still fails with:-
xtensa-lx106-elf-g++: internal compiler error: Aborted (program as)
Please submit a full bug report,
Then I used your firmware & spiffs uploaded with this command
esptool.py write_flash 0x000000 firmware.bin 0x7B000 spiffs.bin
Sadly the ESP starts ok but then resets.
EmonESP 12884640
Firmware: 2.3.1
Starting APScan: 10 networks found
AP IP Address: 192.168.4.1
Server started
Commencing factory reset.
ÿactory reset complete! Resetting...
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vbb28d4a3
~ld
I then re-flashed the ESP with timer branch precompiled firmware and spiffs and that works perfectly.
I can only conclude something is still not quite right with EmonTx branch of the ESP software.
what exactly are you connecting to the Tx?
what firmware is the Tx running?
The ESP-MOD modules sold in the shop have a 4MB flash size, meaning the command to flash them would be:
esptool.py write_flash 0x000000 firmware.bin 0x300000 spiffs.bin
Hi Dan
I am connecting Wemos DI mini ESP modules. I have used these without problems in the past and have 3 running perfectly.
I have used both 4MB and 16MB modules.
The firmware on the Tx is fine.
To double check everything I went back to basics this morning. I deleted the EmonESP directory and cloned emonESP from github again.
It compiled and uploaded without any problems.
Still the same result, starts AP scan and then resets.
Out of interest I also did the same and tried with checking out timer branch.
This will definitely no longer compile. Could somebody confirm this or should I just raise this as an issue on Github?
Hi Ian,
Downloading the master branch from github just won’t work with PIO because the .ini is old, and will download the most recent ESP framework. Any framework above v2.5.0 won’t work with emonESP as it now stands.
I’ve only ever successfully compiled emonESP master with ArduinoIDE.
emonESP timer compiles fine with PIO, but not Arduino.
Maybe try compile emonESP master with ArduinoIDE.
Otherwise yes, raise a github issue and someone will have a look at updating the .ini to compile in PIO successfully again.
1 Like
Hi Dan
That’s curious.
I can compile emonESP master with PIO but I get the reset problem.
I cannot compile emonESP timer with PIO it faults out.
Raised github issue.
I will try ArduinoIDE again.
Hi Dan
Which ESP framework version are you using in arduino IDE?
Ian
v2.4.2
There’re are a few libraries to download for ArduinoIDE.
PubSubClient
Async…
Hi Dan
Some progress. I have managed to compile using Arduino.
Now the ESP starts APScan and does not reset. This kind of confirms there are issues with the platformIO compiling.
Sadly I now see the device on my smart phone but all I get when I try to connect is:-
Obtaining IP address…
Then after a considerable time it gives up showing on the phone:-
IP Configuration Failure
I did erase the ESP before uploading the new firmware and SPIFFS.
Now totally stuck!
That’s a similar problem I had with the 2.5.2 framework of esp8266 for arduino.
You’ve definitely selected the correct version, version 2.4.2, in the boards manager?
Thanks Dan
That was it. I am sure I had selected 2.4.2 framework but it was on 2.5.2.
Corrected that and the problem with resetting is fixed. I can now access EmonESP and everything should be fine. Sadly its not. I cannot get it to connect to my server. I have no idea why. I have other EmonESP units running and I have copied the server settings from them and pasted the write key from my server.
Is there any way to debug the running EmonESP. I have it connected with a serial port but all it shows is:
EmonESP 2056056
Firmware: BUILD_TAG
Connecting to SSID: studiooutside
Connected, IP: 192.168.1.53
Server started
Webpage connection shows:-
There’s a debug.h header, a tab should be viewable in Arduino.
debug.h seems designed for use with PIO. I’ve never used it. A quick look may suggest uncommenting this might help:
//#define DEBUG
Hi Dan
Many thanks. I am now working!
I changed debug and went through the complete firmware upload again and now it is working. However it may have been OK all the time. I filled in all the parameters and hit Save.
Response was:-
Connected: No
For some reason at that stage I hit the HTTP link below the latest data window
http://192.168.1.110/input?string=CT1:3935,CT2:325,T0:20.5
Immediately all the EmonESP windows cleared and response was Connected:Yes.
I looked at my emoncms inputs and there was the data.
I refreshed the EmonESP http connection and the Emoncms windows had information apart from apikey which always shows blank.
So I think the issue was my expectation of connected showing yes on save not realising the connection was not checked until data was sent.
1 Like
Good to know, Ian. emonESP dev in ongoing and it’s worth maintaining… ESP8266 was released quite a while ago now and Sonoff and others show no sign of switching to anything else. Some discussion here about the value of smartplugs in general also.
You’re using them to shut down things on a room per room basis it seems!
Makes a great deal of sense for offices especially I think.
I’ve seen the issue you’ve raised on github regarding pio compile. I will probably get that looked at when dev start again. Cheers.
@danbates - is there any merit in looking to create a component for something like ESPHome so all the Network, MQTT, board definitions etc are done by the underlying ecosystem?
Not something I’m able to do, but I am impressed with these systems.
I like them also, espHome looks nice, I saw ESPeasy which seems a similar idea.
The idea with PIO is that the compiler settings take care of all the under-the-bonnet stuff.
We’ll keep going with PIO I’m sure. Extra modules should be made ledgible in the creation and differentiation of .cpp/.h libraries anyway, which is how I like to do it. Then what happens is someone mushes new development into src.ino and hits commit. For lack of a better word: lol.
1 Like