Current News

Moderator: Mmiscool

Is any one still using the ESP-01 modules? Should I still support these.

User avatar
By forlotto
#54719 You need to replace 01's with 12's ? Hrmmm dunno I think the modules are hardware specific are they not ? I know that it is possible to make 01's work by adding more memory but aside from that can't really say for sure if it is the same hardware that would be rather interesting. From what I am aware of is the hardware pin wise differs rather substantially while it would work the best option would be to upgrade the spi flash this would make it useful for any version of espbasic.

If anyone were going to develop a product with espbasic I think FCC compliance would be an important thing, as many consumers would likely hail from the US I would imagine. While it is nice to have smaller I agree I think it is important to note. To squeeze the esp12 into smaller spaces there are smaller variations of say the nodemcu amica seems a bit smaller than say lolin. One thing a guy could do is desolder the pins and solder wire direct to shorten the height. Earlier in this posting I posted a link to purchase spi flash chips 50 of them for like 12bucks ...

I guess I don't quite understand your question though as you asked " Is there any boards to convert the esp12 to an esp01?" Seems like an odd thing to do unless you just want a board to mount the esp12 to that has the same pin out of the esp01 this is possible but I think upgrading flash is the cheapest option pick up some flux and use an iron to lift a side at a time or hot air station and some kapton tape and some flux. Give it a whirl there are videos on youtube just search smt rework. They will give you ideas on how to accomplish the task. Unless you are wanting FCC approval and the same profile? Now that would make since. But yes your own board would likely be the best route in this case I have not came across anything of that sort yet.

Electrogaurd your work is far from dead I think you are doing a great job and many people will use your work as long as he maintains the options in branches for now. Maybe a renaming of the branch would help unscare people from using it like 512k branch 1MB branch and 4MB branch. I agree modules would be cool but maybe not quite as practical it would require an entire rewrite of the code most likely to automate this process and a lot more overhead. Look at the LUA builds frightitanic for more you can slim it down to nothing but your builds are sent an email when the build is ready it is a great thing maybe we could get that dev to help us out ? This would be cool anyone care to give it a try and get ahold of this user who has automated the build process and what is all required to do so. Nothing out there holds a candle to a fully integrated system like yours at current for automation via udp. So I doubt your work will be lost in the shuffle. Much of driving lessons still applies and it applies fully if you do not want all the extra bloat. I believe it is possible to communicate between versions of firmware on UDP as well so you can use the older firmware for some items and the newer firmware for others after all you are going to have a mesh of devices and if this is explained I think you can give it a go rather than giving up on such a nice project. I'd still love to see your video. All is not for nothing buddy just roll on with it we have branches and who knows it is not impossible to implement fixes to other branches maybe bugs could help here or I'm sure someone could figure it out there is nothing stopping anyone from doing so and if there is a lull in the action maybe mmiscool might get a wild hair and do some bug fixes on the other branches.

One last thing I'd like to see on 2.x branch to polish things up is to fix the syntax so that it matches the 3.x syntax for basic things just without the websockets this would eliminate some hurdles.

I guess what are some of the things you'd like to see fixed to make explanation and continuation of your project a reality?

I think it is important to remember here that communications are not version specific I still have a 1.x device that communicates with my devices just fine there was a change in code from 1.x to 2.x and my code ran best on 1.x so I kept the 1.x on my device ;)

Hopefully you take this as inspirational rather than argumentative I am not trying to tell you anything negative or tell you what to do or how you have to do it. Just trying to give you logical paths and possibilities. I really have no say either way other than my vote just joining in a discussion and I hardly think you have been ignored nor has your work you've done a brilliant job. It was recognized and pinned as a good piece of reference material and code and project/example. All this rambling is to hopefully help you see even at current things are not an impossible dream. I still await your video... but don't do it out of force do it because you enjoy doing it or don't I totally understand your position. I felt the same way after writing my material I have since updated some of it can't promise that all is current or correct but little by little I will likely chip away maybe this winter.

I think the thing that should be done is elimination of 2.x syntax for all versions this would make this type of project easier to develop and explain the workings of not having to juggle explaining 2 different syntax versions of something if you wanted to add an upgraded device. Stability has continued to improve as of late as bugs have been found many have been addressed where and when possible while I am sure there are bits still remaining out there I don't think anyone could honestly argue that there have not been improvements and bug fixes after 43+ iterations in the 3.x branch many times there were multiple bugs corrected in each build or improvements to how things were handled.

For me in 2.x I would like to see the updated settings page and 3.x syntax in the name of keeping things easy for the branches.

What would you folks like to see?


Interesting you fixed some things with IR I am rather curious why you failed to share they are two separate branches I'm sure the fix could be added to version 2.x providing it is not of a personal nature in which case no matter how you slice it some things are DIY if you want it done your way so to speak.

There are many things I'd love to see but they are personal while I feel others would likely use them they would be personal and add bloat.

Like the ability to add weekly timers 50 of them to be exact like so.

wtimer(1,Moday,+6,15:00,[sub]) or anotherwards wtimer(timer_number,Day,Timezone_adjust,SubroutineToExecute)

Would be cool but it is personal and would add bloat not for everyone so I have been looking into doing it through basic myself a little bit at a time.

There are many other things like the way things are handled in the interface like a password requirement to edit or view code for instance to keep family or friends from unwillingly accessing this stuff through the file manager and deleting it and causing more service calls then needed.

But you see these things are of a personal nature not useful in most cases so I simply have kept rather quiet about these things mostly as I am sure many would not care to have the extra bloat.

Again this is not to be opposition or directional in any way I've made my vote I just think the feedback and discussion is somewhat important to the whole picture to see logic and reasoning in decisions. I thank everyone for participation in this post and in the community you all make it a fun thing to play with for me at least. Its been and continues to be a good learning experience for me and many others.
User avatar
By aphawk
#54730 After reading what Forlotto wrote , I decided to put my opinions too. Excuse for my bad English...

I understand that there are two things that must be ended. First, the 512K and 1M ESP-01 support. Second, the branch 2.0 developing.

And if someone had a commercial product that uses the ESP-01 with ESP8266Basic, these peoples don't have the right to make money, because this is a free program! It's a shame.

If only the branch 3.0 will be supported and upgraded with more features, like more than one timer, adding "event timer" as Forlotto had proposed, more sensors support, and more interesting functions, I will happily buy 5 more ESP-12 and throw away my ESP-01 modules. No discussions about this.

And I think that the developers will be very glad too.

And if the developers can sell these ESP-12 modules ( or other modules too ) with a little overprice and sell then in Ebay and can be shipped to all world, I will be glad to buy to make my contribution to continuing these wonderful job.

Today, the fact that can be shipped only to USA is a very bad thing.

I'm an old Bascom user, and have throw away many small capacity Attiny microcontrollers when the price for an Atmega48 family (Atmega88, Atmega168, Atmega328) has dropped and the new Bascom releases had adding many interesting functions that worked only with new Atmega microcontrollers. And the cost of each "old microcontrolller" that I have decided to replace was much more than one ESP-01 ....

With the release of the much more powerful ESP32, I think that in some time ahead we will have a kind of ESP32Basic, that will be a evolution of actual 3.0 branch. Evolution is the key.

Evolution is one fact that can't be ignored.

User avatar
By Electroguard
#54740 ESP_Basic would be unstoppable if mmiscool had a clone army of minnions to help him. But with cicciocb gone, mmiscool is just one very busy overloaded person, so any other contributions that can add interest or focus to ESP_Basic can only be beneficial for it.

I have tried to demonstrate the potential useful practicallity of ESP_Basic, and perhaps my contributions have been wasted effort and not appreciated, but they certainly don't deserve to be incorrectly and unjustly denegrated as selfish exploitation.

Don't confuse developing and producing practical projects with commercialism.
I developed an ESP_Basic PIR node where none had been published before, then turned that into a practical version using ESP_01 which allows me to produce as many as I need to provide coverage of my 4000 m2 property. And that same working product was due to be published as a project for the benefit of any interested forum members, along with the contributions of everything else I've done in the past and everything else planned for the future.

Those contributions are my only way of trying to help ESP_Basic to succeed, so don't mistake my sticking my own neck out to warn of an unnoticed impending crisis as negativity.

Of course progress can never be stopped, and it is pointless to even try, but it can certainly be steered in better directions than might otherwise be taken by the unwary. Evolution takes advantage of extinction, it doesn't cause it. I have tried pointing out the implications of what dropping 1Mb device support is likely to have on any practical usage of ESP_Basic.

But if practical use of ESP_Basic is not an important consideration for the majority of users then it will answer mmiscool's poll and help him make his decision regarding continued support of 1mb device much easier and quicker.

I don't envy him that task, because it is not possible to please everyone, but at least it will be a decision made with the full awareness of all concerned, and it will be a clear pointer to everyone about what direction ESP_Basic is aiming in, and therefore who it will be most suitable for.
User avatar
By Mmiscool
#54773 512k module support is back for 3.0 branch.
Some features are disabled.