A call for help :)

[grovkillen]

We're getting really close to an official release of our beloved ESP Easy operating system. I know a lot of people have been asking for a changelog. We will create an official change log for each stable release, nightly releases will have the auto generated commits as a change log.

So this is the deal, we want to have a change log for what we have changed/added/removed comparing R120/R147 with the current 2.1-beta1.

The syntax we're wanting is the RST way of coding:

Code: Select all

.. versionchanged:: 2.1
  ...

  |added|
  Stuff added 1

  |added|
  Stuff added 2

  |added|
  Stuff added 3

  |improved|
  Improved 1

  |improved|
  Improved 2

  |removed|
  Removed thing 1

  |removed|
  Removed thing 2

  |fixed|
  Fixed thing

.. versionchanged:: 2.0
  ...

  |removed|
  2.0 was never released.

.. versionadded:: R147
  ...

  |added|
  Legacy branch.

.. versionadded:: R120
  ...

  |removed|
  Never branched.

It would render like attached screenshot.

Thank you so much you whoever find the time to help us compile such a list I will make sure your name gets in the upcoming hall of fame (Special mentions).

[Domosapiens]

With all respect for what you guys/developers do ..

getting really close to an official release

I hope not ..
- with all those WatchDog reboots ...
- with all those DS18B20 problems (talking about 3 wire connection)..
A deadline is just a deadline ... in your mind.
Be aware of the ESPEasy reputation.

[grovkillen]

Dallas is fixable, WD is not that easy since it depends on you WiFi environment to a large extent.

We need to get a release out there and start getting nightly releases as it's suppose to be. I mean, now we're not allowed to do major overhaul because our users are using those nightly releases as "stable releases". We are in a catch 22 state which we need to get out of. I hope you understand.

[TD-er]

- with all those DS18B20 problems (talking about 3 wire connection)..

Those are fixable, like Jimmy said.
The WD reboots have been worked on for many months now and I seriously don't think we can get it fixed in due time.
Every time I seem to fix one cause, there are still others left.
The main cause for WD reboots now, seems to be related to bad wifi reception, but I really don't have a clue how to properly fix it for all circumstances.

And like Jimmy said, right now we're working on becoming the next project always in "beta" mode.
Also we really need to get to some proper release cycle for which it is clear to anyone what the status is and what build to use for what purpose (PWM issues for example)
The nodes running here have not had any WD reboot since the last power outage (December 5th) and I got the impression the number of bugreports is also getting lower (2 active ones of the last 2 weeks)
I'm not saying we will put a release label on it tomorrow, since there is still a number of (doable) things I want to have fixed.
For example there is still a number of small issues with the GPIO handling and I want to make sure what's going on with some modules not able to connect to WiFi (mainly Sonoff basic R2).

And Jimmy is just asking for help on collecting all the changes since the last stable. That's also something which may take some time

[ThomasB]

Regarding the change log for the Mega release, there have been a huge number of amendments to the R120 code. So I'd be fine if the official Mega release is described as a "Massive rewrite of R120. Includes new and enhanced plugins." Then begin the detailed change log after the official release.

Be aware of the ESPEasy reputation.

I totally agree. I'm concerned that a continuation of the instability (reset) issues may provoke a community mutiny.

WD is not that easy since it depends on you WiFi environment to a large extent.

I agree fixing watchdog resets isn't easy. But I don't agree it is largely due to the WiFi environment because I never experienced watchdog issue on R120. I don't have the coding talent to fix the wdog problems, but I do my best to provide feedback on the ongoing fixes.

The nodes running here have not had any WD reboot since the last power outage (December 5th)

I'm not so lucky. Running the latest release, still reboots each day. WiFi environment here is clean, strong RSSI from router.

I got the impression the number of bugreports is also getting lower (2 active ones of the last 2 weeks)

That's the old "No news is good news" proverb, but in reality "No news is no news." That's because sometimes frustrated users stop providing feedback.

I appreciate everything the developers are doing to improve ESPEasy and accentuate its features. But for now I don't see the utility in extending efforts to the Official Release goal. I believe it would add more value if you imposed a full shutdown of ESPEasy plugin change submissions, or anything else not related to solving instability. Use the forced quiet period to find the main causes of the resets and fix them.

I don't want to sound like a negative Nelly and earn a bad reputation around here. Just the opposite, I'm a huge ESP Easy fan. So please don't get frustrated/angry from my comments; I just felt the need to share the perspective from a fan boy.

- Thomas

[grovkillen]

Regarding WD on R120. Are these none reported WD or are they actually that clean running? And regarding an upset community, will you think bad of us for releasing an official frozen version. I can live with calling it a feature freeze instead of stable. By the way, I'd say we're not adding any plugin functionality as of last two months, only fixes and some added functionally on mainly the 7 digit plugin that went from testing to normal state.

Not a defense talk really, only added info.

The change log, the depth of it is up to whoever feel called to compile it.

[ThomasB]

Regarding WD on R120. Are these none reported WD or are they actually that clean running?

My R120 installations were two Sonoffs TH10's. Before migrating them to Mega I often checked their system run times; Stable, no reboots months at a time.

Not a defense talk really, only added info.

I did not intend to put you in a defensive position. I'm just a user that is sharing his feelings regarding your announcement of the official release goal.

Both you and TD-er are the main collaborators for the ESPEasy project. The community helps too, but we need guys like you at the helm to guide this ship. So as long as it remains an open source community project I'll support whatever direction you go that keeps you motivated to work on it. Please pardon my interruptions when I stop by and share how I feel as we travel along.

- Thomas

[Domosapiens]

I understand the need for a frozen version.
But if it's there and not thoroughly tested, users come with a bug report, and you have to point them to .... try the latest ...
If you offer a frozen version it needs to be good for (say) 90% of the community.

I remember a proud post from grovkillen .... running for 150 days! (on my disk: ESPEasy_mega-20180323 reported as 150 day stable.zip)
When I was lazy, I would choose that release.

A massive amount of testers is very useful/needed, as we can see now:
TDer sees hardly any problems in his test set-up.
The few (???) users of the latest releases do have problems ...



Searching for a pattern, I stopped a few days with upgrades.
My results:
Since 19-12-2018 evening counter reset:

No 14: 2 reboots mega-20181128 Wemos D1 mini batch 1 Jul 2017
No 18: 8 reboots mega-20181128 Wemos D1 mini batch 2 Febr 2018
No 19: 2 reboots ESP82xx Core 2.5.0-beta1 Wemos D1 mini batch 2
No 21:11 reboots mega-20181120 Wemos D1 mini batch 2
No 23: 6 reboots mega-20181128 Wemos D1 mini batch 3 Oct 2018
No 24: 3 reboots mega-20181128 Wemos D1 mini batch 3
No 28: 3 reboots mega-20181128 LOLIN D1 mini V3.1.0 batch 4 Nov 2018

All have strong (-60dB) to extreem strong (-35dB) RSSI
All have Wemos marking (looks as no clone), No 28 has the new LOLIN marking.

All running this configuration:
viewtopic.php?f=2&t=5955&p=32477#p32473
Power Supply: TSP-05 or HLK-PM01
with different plugged configurations of
- 0 or 2 DS18B20
- no PWM active
- No 18: with flow counter

For reference, ... running problem free:
#3 NodeMCU units with ESPEasy_v2.0.0-dev11 (July 2017!!) and a Rule for the 49 day reboot, are running trouble free with #8-12 DS18B20 sensors in the same WiFi network as today's tests. Up-time follows the 49 day Rule, and hardly any NAN on display.

My noob conclusion is that the improved performance/timing effort has had a bad influence on WiFi and DS18B20.
As I understood from the Github discussions, the DS18B20 timing is not obeyed (and it worked in the past due to slower performance..??).
For WiFi, I already suggested earlier: offer a temporarily switch back to 802.11 B/G, to rule out bad WiFi conditions.

Or ... is it Wemos ???

[TD-er]

I can add a force flag to force the wifi to B/G mode, or maybe even in N mode but with forced smaller bandwidth.

I guess the last option would be the least troublesome one, since it does not require the AP to switch between modes. (which will cause issues with a lot of AP's)

About the stability issues between core 2.3.0 and the later ones. The WiFi/IP-stack has changed a lot between those core versions.
I can try to make ESPeasy being built again on core 2.3.0, but then a lot of users will get all kinds of warnings/errors in their browser since the chunked transfer we use was not fully supported back then.
This chunked transfer is what makes our handling so much faster.

[ThomasB]

I can try to make ESPeasy being built again on core 2.3.0, but then a lot of users will get all kinds of warnings/errors in their browser since the chunked transfer we use was not fully supported back then.

I don't mind verifying that core 2.3 is the main reason for stability success. So if you are game, then please build a "mega_testing_core_230_ESP8266_4096.bin" to try out.

- Thomas

[Domosapiens]

I can add a force flag to force the wifi to B/G mode

A GUI selection? Just G or N makes comparison tests possible.

or maybe even in N mode but with forced smaller bandwidth.

That does not help for the Rx/Tx gain.
G gives 3dB more Tx/Rx gain:

https://github.com/letscontrolit/ESPEasy/issues/2012

Or ... is it Wemos ???

TD-er ... do you have Wemos also in your test set-up?

@grovkillen ... sorry for stealing your post.

[manjh]

I don't want to go into the discussion about the details of open issues, but would like to add my two-cents about release-strategy.
Because that is the core of it all: a predefined and transparent plan of how to deal with main releases, followed by urgent bug-fixes, and periodical small maintenance releases.
The average end-user should stay away from the very frequent beta or even alpha releases, but stick to the main release line.

It is the dream of every developer to make an error-free release of the software available. It will stay a dream. Every release will contain bugs. Look at Windows, Microsoft has been trying for perhaps 35 years, and still every new release will contain (new) bugs.
So put a stake in the ground, set your sights on the planned release, and freeze.
The release bulletin Jimmy is planning is a very good idea. I would offer my help, but I don't have the information. This should come from the developers that worked on the release.
Ideally, this list should grow organically during the development phase, and can then be rendered into something suitable for the endusers.

[TD-er]

I can try to make ESPeasy being built again on core 2.3.0, but then a lot of users will get all kinds of warnings/errors in their browser since the chunked transfer we use was not fully supported back then.

I don't mind verifying that core 2.3 is the main reason for stability success. So if you are game, then please build a "mega_testing_core_230_ESP8266_4096.bin" to try out.

- Thomas

I've been trying to get our sketch to build with 2.3.0 the whole morning, until now.
Throwing around lots of #ifdef's to exclude some used functions not present in core 2.3.0
But I cannot get the binary to be linked.
I keep running into the iram limits, even with all plugins, controllers and notifications disabled and the minimal build flag selected (to disable even more)

So I think we must forget about core 2.3.0 for testing, since it already took me 5+ hours today and still no success.
I think there has been some changes in the build tools, which result in not being able anymore to build 2.3.0 builds and I don't want to open that box in manually changing build tools.

[ThomasB]

@TD-er:

So I think we must forget about core 2.3.0 for testing, since it already took me 5+ hours today and still no success.

I'm sorry to hear you wasted several hours on this. It may have been a useful test but certainly not worth that kind of effort.

- Thomas

[grovkillen]

Ok, I feel we come to a conclusion and we'll make a released version in due time. I'm happy we got eager fans

Back on topic, anyone feel the urge to help us?

[TD-er]

@TD-er:

So I think we must forget about core 2.3.0 for testing, since it already took me 5+ hours today and still no success.

I'm sorry to hear you wasted several hours on this. It may have been a useful test but certainly not worth that kind of effort.

- Thomas

Well in the process I shaved 4k off the build size

[Domosapiens]

Back on topic, anyone feel the urge to help us?

I try to understand what you are asking and how to do that.

The latest Release_notes in Blame mode gives a full overview
https://github.com/letscontrolit/ESPEas ... _notes.txt

In Raw mode:
https://raw.githubusercontent.com/letsc ... _notes.txt

That are 4800 lines !!


Assumption of your request:
- filter as good as possible what it is about
- classify them (?)
My classification suggestion: Main, Config, Controllers, Hardware, Devices, Rules, Notifications, Tools, GUI, module name (f.i. _C001.ino), Flash/OTA support, Build support
- distribute it over
|added|
|improved|
|removed|
|fixed|

for Release notes
- R120/R147 (not on Github ??)
merged into (?)
- v2.0.0-dev7 -- v2.0.0-dev13
merged into (?)
- v2.0-20180110 --v2.0-20180510
merged into (?)
- mega-01022018--mega-20181220

Release notes v2.0.0-dev7 -- v2.0.0-dev13__v2.0-20180110 --v2.0-20180510__mega-01022018--mega-20181220.JPG (176.97 KiB) Viewed 9315 times

Is my understanding correct?

[grovkillen]

Add changes that has been added since R147, only add to the 2.1 "mega" release note. The rest will be displayed as per my suggestion. And yes, it's a huge task. If I don't get help I'll do it myself.

[Domosapiens]

Sorry,
Willing to help...but..

don't understand your
1)

Add changes that has been added since R147, only add to the 2.1 "mega" release note.

and not understood:
2)

The rest will be displayed as per my suggestion.

What goes in what section?

3)
- R120/R147 (not on Github ??)
See bottom of this file: https://raw.githubusercontent.com/letsc ... _notes.txt

4)
To ...Changed in version 2.0 section ?
- v2.0.0-dev7 -- v2.0.0-dev13
- v2.0-20180110 --v2.0-20180510

5)
To ...Changed in version 2.1 section ?
- mega-01022018--mega-20181220

6)
Do you agree with

My classification suggestion:
Main, Config, Controllers, Hardware, Devices, Rules, Notifications, Tools, GUI, module name (f.i. _C001.ino), Flash/OTA support, Build support

7)
what maximum characters of text are available to express the added/improved/removed/fixed

Please advice on 1) ...to... 7)

[grovkillen]

1)
You will not add anything to these:
R120
R147
2.0

You leave the text as I already posted in the first message (opening of this topic/thread)

2)
You can add the sections you suggested and add the type of change to each row (i.e. |fixed| |added| etc)

3)
Don't write anything about these (as described in no1)

4)
You don't have to care about nightly tags. All will go in the 2.1 change log entry.

5)
All changes added to the 2.0 branch will be listed in the 2.1 change entry (as described in no4).

6)
Sounds good to me, easy to read.

7)
No limit but good if it's possible to explain in one sentence. But more sentences are okay too.

[Domosapiens]

Ok. I think I understand it.

What I will do:
- make a collection of all release notes in one Excel file file
- add a column R120, R147, 2.0, 2.1 section
- add a column |fixed| |added| etc to it
- add a column with the classification to it
- add a column with the description/resume

I will send the Excel file to you for review/correction

After that:
- Within each section R120, R147, 2.0, 2.1 ....
- I will sort it primary on: |fixed| |added| etc, secondary on: the classification, tertiary on: description
- Remove all superfluous info/text
- Send the Excel file to you

You convert/extract it to the RST way of coding.

Yes? Any suggestions ?

[grovkillen]

Ok. I think I understand it.

What I will do:
- make a collection of all release notes in one Excel file file
- add a column R120, R147, 2.0, 2.1 section
- add a column |fixed| |added| etc to it
- add a column with the classification to it
- add a column with the description/resume

I will send the Excel file to you for review/correction

After that:
- Within each section R120, R147, 2.0, 2.1 ....
- I will sort it primary on: |fixed| |added| etc, secondary on: the classification, tertiary on: description
- Remove all superfluous info/text
- Send the Excel file to you

You convert/extract it to the RST way of coding.

Yes? Any suggestions ?

Solid workflow! Thumbs up!