@chathurangawijetunge, you should generalise this Q and consider HTML as a special case: when is it appropriate to store resources in LFS and when the alternatives are a better fit. Lua as a language can only support numeric, boolean and string constants in code; anything more complicated: array, function closures, have to be constructed at runtime. LFS stores Lua code so it can only support the former. It makes sense storing resources as string in LFS code if you need fast access paths, but there is a cost in readability and maintainability. So sometimes the alternatives can be better such as:
return file.getcontents('someresource.dat') -- or even
return sjson.decode(file.getcontents('someresource.dat'))Also remember than in terms of storing HTML, then it is well worth separating the true constant stuff: CSS JS and even some HTML furniture is constant files which you can run through gzip on the host and store the compressed form as file or even string resource-s on the ESP. Just use the Content-encoding: gzip response to that the browser knows to unpack it. This is good example of where leaving the compressed resource as a file is just so much easier.
When it comes to storing complex resources in strings:
- Consider preprocessing the resources host-side and using a small bash/Python/Lua script to generate the file automatically from the bare resources.
- You can use the
%qformat specifier to ensure than any such resource can be embedded in compilable format into the intermediate source format, but - You might find that base64 encoding is just so much more readable:
return encoder.fromBase64[[...]]
is there a way to update string (let’s say json) in a file without overwriting whole contents or appending line at the file end?
Think about it: a structure encoded in JSON has a very strict grammar; even something as simple as replacing a string value with another 1 byte longer is going insert an extra byte in the middle of the encoded string, so there is no practical way to do this with file primitives. It's a lot easier just to rewrite the entire file with the new version, say by doing a file.putcontents() with the new encoded string. Work internally in RAM with Lua structures and only serialise them to SPIFFS if you want to keep a non-volatile copy to persist over restarts.
tmr alarms
tmr.delay() function just calls a ROM bootloader delay function, which isn't masked to ISRs and so can be used safely up to a few mSec, but I would suggest doing an alarm for much more than that. This isn't a time critical delay so a wobble of a mSec or 2 won't make any difference.
tmr.c for an example of how to do this.
I’m not using
tmr.delay(), delay I meant in general - to put delay between doing tasks and for sure non-blocking, using tmrin this manner: tmr.create():alarm(10, tmr.ALARM_SINGLE, function(t_ads) adc1:startread(function(volt). Saying “not optimal” I meant that usually, when you have device library it should do these small tasks and you should be free of thining about “did I forgot to put delay between readouts”. I will do readings today using different timing and will return with results.
Uncompressing toolchain
the archive contains ro files
Setting IDF_PATH and re-invoking...
/bin/sh: 1: Syntax error: "(" unexpected
Makefile:21: recipe for target 'all' failed
make: * [all] Error 2
/bin/sh: 1: Syntax error: "(" unexpected
Makefile:334: recipe for target '/home/thomas/nodemcu-firmware/nodemcu-firmware/sdk/.pruned-3.0-e4434aa' failed
make: * [/home/thomas/nodemcu-firmware/nodemcu-firmware/sdk/.pruned-3.0-e4434aa] Error 2
make: Leaving directory '/home/thomas/nodemcu-firmware/nodemcu-firmware'
@tjakober What are your .h changes. I just used linux x64 w/o issue on default...
git clone --recursive https://github.com/nodemcu/nodemcu-firmware
cd nodemcu-firmware
make -j8
git show-ref | grep HEAD
71a182caa7841cbb478ed90ede526dc881943c80 refs/remotes/origin/HEADI showed the head ref, too just in case something was fixed before I posted.
Yeouch. I was just looking at 'smartconfig.' Man is it ugly for security, even using AES. In the situation where you are a company and you have pre-provisioned your devices with specific AES keys to deliver to the public customer, those keys live on the device. We all know how to dump the storage, find the programs, perform disassembly or whatever is needed to find the keys. Now after they are publicly shared some war driver can capture your packets (or your neighbor can do the same) and your network is passphrase is known. Even without capturing the AES key, an attacker can drop a device with battery to capture the info of the target. The device can then get on the network transmit its passphrase to "destination hosts somewhere belonging to 'chchchoo' (sorry had to sneeze) the attacker." The device erases itself to avoid detection or maybe reconfigures itself for some rapid or stealthy recon. It could just alter the key to send you on a fools errand when doing your response effort to figure out what someone did. Basically smartconfig will unwittingly put the networks of your customers at risk -- or your personal network if you use it yourself.
No matter what, good security practices indicate that you should pay attention to what hosts are on your network -- or use good provisioning techniques that meet your risk threshold for your Intellectual Property (which may or may not include smartconfig). I don't use it.
