Future plans/thoughts....

[nardev]

As i pushed Wiegand support, i realized the code structure so.. i realize we could improve it for everyone's good.

Honestly, i would love to make many changes. What do you think about following:

1. Automate combine & compress css, js and html pages? (i already have a method that i use, i can easily add this)

2. Restructure the web page, more use of jquery, this approach is quite messy and bit later on, it will be hard to follow changes. The whole process of saving the settings and populating the form in settings page i can do in 10-20 lines of code with jquery, in a smart way.

3. Extract functions for RFID readers and make auto build for each different reader, so that the code will be light and only what is required in one certain version. (This would be very easy if we move code to PlatformIO, just set platform.ini as we need it)

4. Move to PlatformIO?

5. I propose to have official hardware, and as i already mentioned, i have a version, which i can easily adjust so that it can accept all kinds of readers, have relay, door status input button for buzzer and input for some extra sensors like PIR sensor for silent alarm etc. (what do you think?)

[omersiar]

These are great suggestions, for 1, i was already looking for a solution, i started working on a solution for 2 but i did not have solution for 1 at that time so i ditched it for later, especially 3 is needed when we have a official hardware, because i do not want to abandon the DIY community for the sake of official hardware.

PlatformIO is perfect solution for this project, i realize that we need to move forward and begin to benefit from PlatformIO.

Commit access granted to you, thank you for your contributions to this project.

@rneurink, @thunderace, @zeraien, @nardev Please let me show you my appreciation, I think of sharing donations if you can share your Bitcoin Cash addresses.

You can get a Bitcoin Cash wallet easily at Bitcoin.com.

[nardev]

Since you are already working on 1. I just write some ideas I have so you pick what ever you think is good... Give me some time...

Yes I think and feel the same way about DIY. Should always be helped and always have that in mind...

I'm not sure for now... But if I remember correctly it's possible to have one file.. Able to be built through platformio and arduino ide..will check...

[thunderace]

For 2, i have already something : only one html file with show/hide panels. It's faster because js files are loaded only once. But i have some work to do to make a PR because it's done on the mqtt branch (with some enhancements that i have to remove). @omersiar : thank you, but no, I just want to help.

[omersiar]

Let's merge MQTT to master. I will do it tonight. @thunderace i give you commit access too, since i have a little time.

[thunderace]

For 1 (only for required.* files) and 4 see the new platformio branch. Tested on Windows (sorry) platform. I will test on linux (debian) this night. Try and report please.

[omersiar]

@nardev Does your solution for 1 work with un-minified files? Does it combines multiple files into one big file? and gzip them?

Guys at OpenEvse does it in a way that does not even require SPIFFS file system.

https://github.com/OpenEVSE/ESP8266_WiFi_v2.x

https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/tree/stable/scripts/css_html_js_minify

Also OpenEvse's web pages looks delicious, we can inspire from them.

[thunderace]

@omersiar The OpenEvse have really good scripts. Cnd combines multiple html/js files in one cannot be done automatically (i think...) We have to minify html/js/css files only in release mode to be able to modify them via the SPIFFS editor.

[omersiar]

I always assumed the SPIFFS Editor to be dropped at least on first release. For about half a year I did not convinced that i can make a release without proper security (at least PICC_Password), so it stayed this far, also it's good for debugging, maybe I can code an ESP-RFID hardware emulator on node.js, so we can make tests before make a release.

Let's focus on switching to platformio, it will lead more robust building system eventually.

[nardev]

@omersiar it's actually modified script from web server for ESP

check this: https://gist.github.com/nardev/754ccebd6d31e27b6b2f6fee1f76603d

it requires nodejs and few modules.. but keep in mind, it's only for developers.. so IMHO it's not a problem for DIY guys...

you put all files in onde document, and just before the build, you run the script and .. all files are gzipped and moved in data directory.. and images are only copied.. etc...

p.s. On a second thought.. maybe it would be very smart to move to PlatformIO first.. and than plan all those other BIG changes.. because, from there it's easier to make all this from there...

[nardev]

@omersiar as i see @thunderace already made nice python script for gzip files.. .. just need to add all of those files and perhaps current required.js and required.css should not be minified before.. the python script should do that, gzip it and moved to data/

@thunderace could you please:

1. merge few changes i pushed to master branch (some changes in settings.htm and set.js_

2. I suggest to make some file names more intuitive:

   • name of "extra_script.py" maybe "prepare.py" or "compress.py"
   • name "spiffs_src/" maybe "datafiles/"

Also, @thunderace should we use .cpp instead of .ino?.. i already do like that.. so much more cpp like?

[thunderace]

1 : done 2 : done

• extra_script.py to scripts/pio_script.py (because there are before and after spiffs/firmware build hooks)
• spiffs_src renamed to datafiles

  should we use .cpp instead of .ino?

I agree i hate ino but keep it to let users with arduino IDE build the firmware no?

[nardev]

What @omersiar about keeping Arduino IDE support?

Since it's already tricky with python script and that workflow.. i don't know if keeping .ino would help much.

I would rather write detailed, step by step instructions how to build it with PlatformIO than keep ino..

@thunderace would you be able to add some compiler instructions in platformio.ini so that we can use Preprocessor directives to build separately version for his reader type? We would save some space .. i would adapt web interface for that.....Also we could extract those functions in out into separate header, per reader type.... there is also 523 module, wou could support that one too...

[omersiar]

No need to support Arduino IDE. You guys making great progress, thank you.

[nardev]

@thunderace so, go ahead.. moving to .cpp

[nardev]

I just made version with main.cpp instead but there is an issue with arduino 2.4rc and platform io..

if you upload the code, it damages files and if you upload the files., the code vanishes.. who knows what registers overlaps and why does it happen...

anyone have similar issue?

p.s. after adding some flags to buildfs it works:

build_flags = -Wl,-Tesp8266.flash.4m.ld

[thunderace]

No problem here. Warning, with this ld file (esp8266.flash.4m.ld) you have no SPIFFS space...

[nardev]

@thunderace .. i thought the same .. but it works in my nodemcu

[omersiar]

I always get some error with all these ld scripts, I guess there must be a solution for nodemcu targets. Let me check this.

[omersiar]

Let's merge all these ideas on projects.