re-entry and massive problems

[M*I*B]

Hello there,

I haven't done anything with ESPeasy for a very long time (more than 3 years) and obviously I missed a lot.

Today I flashed a SONOFF S20 with the ESP_Easy_mega_20210223_normal_ESP8266_1M.bin, another identical S20 still has mega-20191108 on it.

That works with the old firmware, not really with the new firmware ^^

Overall I have two problems:

1.: Old rule does not work in the new FW

Code: Select all

on [Taste#BTN] do
  if [Taste#BTN]=1
    gpio,12,1
  else
    gpio,12,0
  endif
endon

An other one:

Code: Select all

on System#Boot do
	LoopTimerSet,1,2
endon

on Rules#Timer=1 do
	if Temperatur#TMP < Dummy#SET -0.5 or Taste#BTN=1
		gpio,12,1
	elseif Temperatur#TMP>Dummy#SET +0.5 and Taste#BTN=0
		gpio,12,0
	endif
endon

That also don't work...
As I understand it, the ON Timer DO should be triggered every two seconds and the comparisons and tasks contained therein should be carried out... It just doesn't work also, with or without [brackets]...

What I also don't understand is that in some examples the brackets (? this one: []) are in use, on other not...

However, if I set gpio12 directly, then the relay switches.
The Taste#BTN value changes from 0->1 and when you press the button again from 1->0 Works well. But the rule never seems to apply.

2nd: New rules engine
I had switched the rules engine once, but actually didn't understand anything; How do you work with the new rule engine?

Is there anyone here who would like to update me? That would be really nice!

PS: The Devices on both S20

Bild_2022-12-17_213531817.png (37.72 KiB) Viewed 5415 times

[Ath]

Code: Select all

on [Taste#BTN] do

That's invalid syntax, should be:

Code: Select all

on Taste#BTN do

and

Code: Select all

	if Temperatur#TMP < Dummy#SET -0.5 or Taste#BTN=1
		gpio,12,1
	elseif Temperatur#TMP>Dummy#SET +0.5 and Taste#BTN=0

might need a couple of round braces and some square braces, like:

Code: Select all

	if [Temperatur#TMP] < ([Dummy#SET] -0.5) or [Taste#BTN]=1
		gpio,12,1
	elseif [Temperatur#TMP]>([Dummy#SET] +0.5) and [Taste#BTN]=0

Both wouldn't have (properly) worked in an older release of ESPEasy either...

Today I flashed a SONOFF S20 with the ESP_Easy_mega_20210223_normal_ESP8266_1M.bin, another identical S20 still has mega-20191108 on it.

Can you please install a more current ESPEasy release, not one that is almost 2 years old?

[TD-er]

1.: Old rule does not work in the new FW

Code: Select all

on [Taste#BTN] do
  if [Taste#BTN]=1
    gpio,12,1
  else
    gpio,12,0
  endif
endon

First line should be without the []
And while we're at it, better check for the eventvalue instead of looking for the state of the taskvalue.
The state of the task value may have changed in the mean time when the events are being processed, so better check for the eventvalue as that was the value the moment the event was created.

Code: Select all

on Taste#BTN do
  if %eventvalue1%=1
    gpio,12,1
  else
    gpio,12,0
  endif
endon

An other one:

Code: Select all

on System#Boot do
	LoopTimerSet,1,2
endon

on Rules#Timer=1 do
	if Temperatur#TMP < Dummy#SET -0.5 or Taste#BTN=1
		gpio,12,1
	elseif Temperatur#TMP>Dummy#SET +0.5 and Taste#BTN=0
		gpio,12,0
	endif
endon

Here you need to wrap Temperatur#TMP and Dummy#SET and Taste#BTN in []
When processing the rules, things within [] are being replaced with their respective values.
That's why you should not have the [] in the on..do line
But you really need to have it whenever you try to evaluate things.

[TD-er]

About the use of ESPEasy on a Sonoff S20...
I did install it myself last week and it is working very stable.
However, you need to have one of the latest test builds, as I have spent way more time on those Sonoff units than I want to admit.

For example use one of these: https://github.com/letscontrolit/ESPEas ... 3713792966

Or use the exact build I used on my S20: https://www.dropbox.com/s/nbcjknetw8djc ... C.bin?dl=0

[M*I*B]

WOW! That was comprehensive and quick input, as No.5 would say
Many thanks to all of you for that!
I'll do it tomorrow and try to implement what I just learned from you all.

Two things just struck me:
On the one hand, although the two S20 are structurally identical and are connected to an 18B20 at the same point, the ports with the new FW are different. With the old S20, GPIO-1 is 1wire, with the new FW it is GPIO-3. It took me a while to figure that out.Why is that?
On the other hand, I thought the FW I described as NEW would be the last available FW for it. Because I made an update from the FlashTool and there is nothing newer (see attachment). I thought this would show all available versions? That doesn't seem so...

For now I wish you all a good N8...

Bild_2022-12-18_000143752.png (351.54 KiB) Viewed 5409 times

[TD-er]

I have no idea why it would suddenly be connected to a different pin.

The only thing I can now think of is that you're not allowed to select a pin which is already assigned to something else.
The older firmware builds were a lot more forgiving in allowing to create settings which will not work.

Another thing which has changed in the Dallas plugin is that we now allow to have a separate pin for input and one for output.
But the last one is optional as you can still use it with 1 pin perfectly fine.
However this was needed for some ESP modules (I think it was some Shelly unit) which has added some isolation to protect its users. However such isolation is only for 1 direction and thus you need a separate pin for reading and one for writing.


No idea why things will not be updated in that flash tool.
It just parses the files in its bin folder. But maybe this parsing is only done when the application is started?

If you have issues flashing, you may also want to try the Espressif Download tool, which is also included in the (massive) ZIP download.
See the documentation on this tool: https://espeasy.readthedocs.io/en/lates ... nload-tool
The screenshots are for flashing ESP32, but for ESP8266 it isn't much different.
Just keep the "offset" at 0, just like in the screenshots.
Don't flash the .bin.gz files, but just the .bin file for ESP8266.

[M*I*B]

Good morning ...

... and you and your families a nice Sunday in Advent!

On the subject:
@TD-er: Don't get me wrong. I'm NOT talking about the hardware here with PinSwap. Both S20 have a completely identical structure (see attachment). A 3.5mm jack socket is installed for the 1W, which is plugged into the connections for flashing via a pin header (the pull-up is also present on the pin header; it is difficult to see). So either the 1W is plugged in there, or the interface converter while flashing. Thus, there is no way to somehow change the PIN for 1W. 1W was and is always on the RXD pin.
The changes must have crept into the firmware at some point.
As you can see here ....

Bild_2022-12-18_104105983.png (36.86 KiB) Viewed 5375 times

... the sensor has been running trouble-free on GPIO-1 (D10) = TXD with the old firmware for years. In the new firmware, however, TXD is labeled GPIO-3 (D9)... Maybe... but only maybe... I have read somewhere in the past that SONOFF have had a layout-error and swap the RXD/TXD on the PCB. But I don't remember if that was only the naming or a real hardware-swap...

RXD is always next to VCC in all SONOFFs that I have had my hands on so far, so the order is always VCC-RXD-TXD-GND.

Bild_2022-12-18_103833680.png (510.27 KiB) Viewed 5375 times

That with the 2nd Port for Dallas I have seen and now I know about why... Thanx for that info stopping me from wonder about


With the FlashingTool I haven't any trouble. That works like a smart.
Meanwhile I have download by hand "ESPEasy_binaries.zip" (created at 17.DEC.22) and extract them into the /bin. Now I have the new filez available in the Flasher. I will try to update it inside the next hours and call back here then...

[TD-er]

I guess the only way to be sure is to look at the soldering on the other board.
I am pretty sure I did not change anything recently (as in the last few years) regarding board layout definitions.

[TD-er]

Ah when looking online for Sonoff S20 pinout I came across several conflicting sources...
https://templates.blakadder.com/sonoff_S20.html
The text and image are conflicting.
The text on this image conflicts with your image: https://esphome.io/devices/sonoff_s20.html

I think it is confusing as some want to indicate what signal to connect to the pin and others may want to label the signal from the ESP side.

At least GPIO-3 = RX (seen from ESP)

So I think your labelling on your photo is correct.
You did connect it to the ESP RX pin as I just looked at my "Sonoff flash cable" and the programmer's RX pin is connected to the 4p header next to the GND. So the pin next to the GND on the Sonoff board should be TX.

[M*I*B]

hmmm, I will do that after I have my 2nd running ...

An other one:
If I like to connect to the S20 by TTY... What are the correct proto? I have try 8n1, ASCII, 115200, 57800, 9600, but nothing will work

[TD-er]

If you have something connected to GPIO-3 (or 1 ), you probably also have disabled "use Serial" on the tools->Advanced page.
You need to enable this (and disable the Dallas task) first.

The baud rate is what is set on the same tools->Advanced page, but typically this is 115200
Indeed you need to use 8n1.

[TD-er]

Oh and just to be sure, please measure the resistance between either mains pin and the GND of the board.
I know the S20 doesn't have power meter capabilities, but just to make sure the Dallas jack plug you made is safe to handle.
It is best to assume the parts inside the Sonoff devices are NOT isolated from mains.
They might be, but this is absolutely not guaranteed.

Also galvanic isolation in the Sonoff power supply part is only half of the equation.
I have no idea what isolation is being used on the mains wires, or if other safety requirements are being followed when designing this Sonoff device.
If the wires are not rated for 600V isolation, then there is no guarantee the rest of the circuit may be potential free from mains.

[M*I*B]

Yes, you are right. I can see the Bootup- message but after that ... quietness ... Now I know why

So, things going the wrong way today... I have flash "ESP_easy_mega_20221105_custom_ESP8266_1M.bin" That looks like the last newest usable file for the S20. Transfer WIFI- credentials by TTY haven't worked so I use the AP-mode... After that I have seen that nothing are in so I got the "great" idea to import the config from my running one... Now both have the same IP...
Ok, Have to go in my garage to temp disconnect the running one...

And ty for the hint, but GND inside is well connected to the protective conductor. Never have any problems with error-current so that one of my RCD (20mA) or RCPO (10mA) have to work...

[TD-er]

The debug log is only shown until the device has a WiFi connection.
This also indicates you have unchecked "Use Serial" on the Advanced page.

[TD-er]

[...]
And ty for the hint, but GND inside is well connected to the protective conductor. Never have any problems with error-current so that one of my RCD (20mA) or RCPO (10mA) have to work...

And the earth pin in the wall outlet is known to work?
Wouldn't be the first outlet where assumed safety appears to be a false assumption.

By the way are those 20 and 10 mA standard?
Here in the Netherlands the standard is 30 mA, which can be used upto 4 fuses/groups. (not sure about the English term)
For PV inverters there is an exception, only when those are not plugged in but have a direct connection (thus not using a socket). Those PV inverters are allowed upto 300 mA "leakage" current. Which isn't actually leakage, but more like "delayed" current, due to the nature of how inverters work.

[M*I*B]

And the earth pin in the wall outlet is known to work?
Wouldn't be the first outlet where assumed safety appears to be a false assumption.

Nope I have soldered a wire from PC to GND, to be correct a 47R|100n

By the way are those 20 and 10 mA standard?

20mA are now standard for central RCD but 10mA RCBO aren't. That I use for electrical local security as replacement for normal fuses.

The debug log is only shown until the device has a WiFi connection.

Ah... ok... good to know! Ty for that hint!


Ok then. Meanwhile the 2nd S20 are running now with the ESP_easy_mega_20221105_custom_ESP8266_1M.bin. I hope that one is the latest usable FW for the S20?

So I jump in with the last rule I like to use and experiment with:

Code: Select all

on System#Boot do
	LoopTimerSet,1,2
endon

on Rules#Timer=1 do
	if [Temperatur#TMP] < ([Dummy#SET] -0.5) or [Taste#BTN]=1
		gpio,12,1
	elseif [Temperatur#TMP] > ([Dummy#SET] +0.5) and [Taste#BTN]=0
		gpio,12,0
	endif
endon

So what's wrong with this?
According to my understanding, the "on Rules#Timer=1 do" should be executed every two seconds, shouldn't it?
And if so, why doesn't my construct work? If [Taste#BTN]=1 then the IF have to be run and switch GPIO-12 to on. But then he gives me the middle finger

EDIT: Ok... Now it works... Don't ask me why

EDIT 2:

Code: Select all

on System#Boot OR Taste#BTN do

That don't work / isn't allowed ... right?

[Ath]

You can add a LogEntry line in your rule:

Code: Select all

On Rules#Timer=1 Do
  LogEntry,"Temp: [Temperatur#TMP] Set: [Dummy#SET] Btn: [Taste#BTN]"
  ...

Then open a second tab in your browser, and watch the logs go via the Tools/Log option

[TD-er]

[...]
EDIT 2:

Code: Select all

on System#Boot OR Taste#BTN do

That don't work / isn't allowed ... right?

That's correct.
There can be only one event that matches a rules block (or using wildcards, but then there should be a partial match)

But if you want to avoid code duplication, you can try to create a new event.

Code: Select all

on System#Boot do
  asyncevent,MyOwnEventName=%eventvalue1%
endon

on Taste#BTN do
  asyncevent,MyOwnEventName=%eventvalue1%
endon

on MyOwnEventName do
 ...
endon

[M*I*B]

But if you want to avoid code duplication, you can try to create a new event.

OHH ok... Haven't know about this way... Great! That I will test. Looks like a "work around" for my missing OR

You can add a LogEntry line in your rule:

That's also a great hint! That I also stay in my hint-book then...

[TD-er]

Another great source of hints: https://espeasy.readthedocs.io/en/latest/index.html
Since you're an "old school" ESPEasy user, you might still have the wiki in your bookmarks, so better first look at the readTheDocs as that's being updated. But since not all info from the wiki has been transferred into the RTD docs, the wiki can still be useful.... outdated, but useful.

[M*I*B]

outdated, but useful.

You are right. I have that bookmarked a long time. But sometimes I don't find the things I'm looking for (maybe about my ugly english) or, if things goes wrong like this thread, it's better to ask professionals like you all... Last spoken also create an interactive communication between real human what you can often not replace by a manual, FAQ or what ever ...

For a question here I have a example:
I have search the whole ReadTheDocs how I can create a "Send to controller" as an event.
I only have one Controller set. It's for FHEM.
Now I have also a Dummy where I set the target temp. At the S20 you can't set that so I use the "set <devicename> taskvalueset 4 1 26" to set the Dummy#SET to 26°C. That work well.
But... If I have set the "interval" for the Dummy to zero I don't get the new value back. Ok, I can set the "interval" i.e. to 60, but that creates unnecessary traffic regardless of whether the value has been changed or not.

So I have searched for a way to create a single shot like ...

Code: Select all

on Dummy#SET do
  send-to-controller,1,[Dummy#SET]
 endon

With that I can leave "interval" and the traffic at zero and only send if the value is changed... You know what I'm mean?

... and while I just play around the next one I can't find in the RTD:
Can I store data into NVRAM/FLASH and recall it?
Problem is that the Dummy#SET comes up with zero after an power lost. So I like to store this value into the FLASH every time it has changed and recall it on BootUp like ...

Code: Select all

on System#Boot do
	LoopTimerSet,1,2
	Dummy#SET=%FlashMemory1%
endon

... blabla ...

on Dummy#SET do
  send-to-controller,1,[Dummy#SET]
  FlashMemory,1,[Dummy#SET]
 endon

EDIT 1:
Ok, "Let,x,y" seems to be the way? Is that right?

1st I have try this ...

Code: Select all

on Dummy#SET do
	Let,41,[Dummy#SET]
endon

... but that store the former value. Then now I have this ...

Code: Select all

on Dummy#SET do
	Let,41,%eventvalue1%
endon

... and that seems to be ok.

So then easypeasy that to call it back after a reset or power loss???

Code: Select all

on System#Boot do
	LoopTimerSet,1,2
	[Dummy#SET]=%v41%
endon

[M*I*B]

... ohhhh FU**

In the old FW I can switch the status of the button via TaskValueSet from 1->0 and verse visa (Result: OK). In the new FW that isn't possible (Result: NOT_A_DUMMY_TASK)

That's very bad...
I'm understanding that if the Button is set as switch, but as PushButton?

[TD-er]

Tools->Advanced
Check "Allow TaskValueSet on all plugins:"

Just try to imagine we don't want to make it worse
Only to make it such that new users have less chance to create something that will not always work.

[M*I*B]

Bild_2022-12-18_204555399.png (42.81 KiB) Viewed 5342 times

On this place I never ever have search for that

[Ath]

Code: Select all

on System#Boot do
	LoopTimerSet,1,2
	[Dummy#SET]=%v41%
endon

That's never going to work, actually, on every reboot Dummy#SET will be reset to 0, because the internal variables (%vN% / [var#N]) are reset to 0, where on a warm reboot the task values will be restored from a saved state ('RTC' memory in Espressif speak). That will not restore after a power-cycle though.

[TD-er]

Apart from that, you can't assign something to a taskvalue like that, you need taskvalueset.

[taskname#taskvaluename] syntax will be evaluated before the rule is being parsed.

So this will be kinda bogus for the rules parser: (assume the dummy taskvalue to be 123.4 and the variable [var#41] being 0.0)

Code: Select all

[Dummy#SET]=%v41%
---> 123.4 = 0.0

The rules cannot assign a number to a number.

[M*I*B]

Ok... That exceeds my current knowledge right now; I can't keep up...

So let me ask the other way around:
How can I save the value from the dummy via a reset/power failure?

[TD-er]

You can't.
What you can do, you can send a command from another node or via MQTT to the ESPEasy node.
But then I probably need to know a bit more about your setup.

[M*I*B]

You can't.

Ok.. or rather not ok. That's not the answer I really wanted to hear...
Am I the first user to encounter such a problem?

I can't really imagine that either. Surely there are still a few bytes in the flash that could be used for this? I mean, such a failsafe is actually not an unusual request, especially when it comes to temperature controls...

Your idea of transferring from other systems is not an option from my point of view. In the event of a brownout (certainly coming soon) or even a blackout, all systems are down. When the network returns, it is not really certain in which order the systems will start up again and be ready for use and whether all systems will actually start up again independently; this is a lottery game...
The only option might be an energy-saving WeMOS, which is connected to a large battery and is only responsible for reinitializing the entire system...
In any case, it would be better if the individual components of the entire system could go back to the grid independently...

If there is no sensible and safe solution for this, I will have to exchange at least the safety-related S20 with mechanical thermostats. I can't control them remotely, but they don't care whether there's electricity or not...

[TD-er]

Nope, you're not the first user to encounter this.
But the problem is that we really should limit the number of writes to the flash.
There is some work-around, as the "level" plugin is allowed to write its level setting and also fetch it. (via [taskname#getlevel] as if it is a taskvalue)
It also has a setlevel command.

See: https://espeasy.readthedocs.io/en/lates ... -available

And just to think about...
When you need to 'recover' from a blackout, it is probably best not to switch to the last state, but rather some failsafe situation.

[M*I*B]

Nope, you're not the first user to encounter this.

... that would have really surprised me if I had been the first ...
I'll read through it and try to implement it. Thanks a lot for this!

EDIT: I don't find this device in the flashed FW. I think I have to flash an other version 1st?


In the meantime, I installed an emergency solution; not nice, but works for now... However, it requires that the WIFI be the first system to be restarted (see below)...

Code: Select all

on WiFi#Connected do
	TaskValueSet,4,1,3.5
endon

When you need to 'recover' from a blackout, it is probably best not to switch to the last state, but rather some failsafe situation.

That is of course correct. In theory at least. Because the majority of households will simply leave the devices in the ON position, if only because they then have other worries and don't think about them and/or simply don't know.
For my part, I have made provisions accordingly, since I switch to our diesel in the event of a brownout/blackout. Then I have to shed part of the load anyway that isn't strictly necessary; my diesel only manages 10kW max. When the power returns, the same process takes place. First, the heating system, communication (DSL, radio system) and the cooling devices are switched back on to the mains, then the auxiliary heating if the outside temperature is below +5°C, then bit by bit the rest.

[budman1758]

Nope, you're not the first user to encounter this.
But the problem is that we really should limit the number of writes to the flash.
And just to think about...
When you need to 'recover' from a blackout, it is probably best not to switch to the last state, but rather some failsafe situation.

A long time ago in a galaxy far, far away there was some discussion about ESPEasy support for I2c Memory chip support that would solve this saved task value issue. At the time we discussed this chip

Code: Select all

https://www.digikey.com/en/products/detail/microchip-technology/AT24C32A-10PI-1-8/523462#product-details-substitutes

which is apparently obsolete now. I bought some of them at the time. Been sitting somewhere in my parts ever since. They do list this substitute as being drop in compatible

Code: Select all

https://www.digikey.com/en/products/detail/microchip-technology/24AA32AF-I-P/2125464

Doesnt seem like it would be too hard to support these. I realize it adds complexity to a particular board setup but that seems a small price to pay for the benefit.

Food for thought.....

[TD-er]

I know, I have a similar drawer, filled with stuff needed to be implemented for ESPEasy.
And as I recently found out, while unpacking stuff that has been in storage for about 28 months while my house was being demolished and rebuilt... I now need >1 of such drawers to store all sensors that need to be supported.

[M*I*B]

... none of you have seen my drawers, which surely fill a small house ...

I think the idea with the ext. memory not bad. There are certainly applications that need to be constantly writing to memory. That's certainly a good thing for that.
In my case, I think this is unnecessary. The value is written so seldom that the memory certainly lasts longer than the peripherals. At the beginning, the value is reset maybe 5-10 times in order to optimize it to the circumstances, then probably never again.

But something else:
I spent some time yesterday trying to find information on how to get the "level plugin" in resp. in which repro this can be found; I didn't succeed ^^
Do I have to compile a BIN myself? I've never done that and unfortunately I can't...

[Ath]

You seem to have installed the Custom .bin, but has only a limited set of plugins available by default, and doesn't include the Level plugin.
Unless you need a plugin that's only available in that Custom build you'd better install a Normal .bin file, that has the Level plugin included, and also the plugins you have shared in your last Devices overview.

[M*I*B]

... thanx for the hint.
Unfortunately the only "normal" out of 2022 are for 4M1M and other. The latest normal for 1M I can find is from 20210223 ...

[TD-er]

... thanx for the hint.
Unfortunately the only "normal" out of 2022 are for 4M1M and other. The latest normal for 1M I can find is from 20210223 ...

And what about the one I linked here: viewtopic.php?p=61798#p61798
The dropbox link....

[M*I*B]

... japp, haven't think about that ... Alzheimer is shit, believe me

The 1st link I can't handle; no idea what that means... The 2nd I have now create a DB-account to get it... I will try...
BTW: What means the "VCC" at the end of the filename?

[Ath]

BTW: What means the "VCC" at the end of the filename?

That build has the ESP(8266) Analog input configured to read the VCC level, so it can't be used as an independent analog input. For the S20 that would be fine, as you won't have a connection available for that A0 pin

[TD-er]

Huh, since when do you need to create a DropBox account to download such links?
If you really need to create a DB account, I will think about some other setup to share files as this was by no means my intention.

[M*I*B]

... yes, wasn't possible due popup "hey register before download" ...
But no problem.

BTW: If you need Space for files... Ask me... Got enough on my webserver


EDIT:
My 2nd S20 seems to be broken. Not flashable... Looks like the RX-port are blown. TX works while testing with TTY; can see the boot up message... Ok... Let me dive into my stuff... maybe a have one more (somewhere...)

[TD-er]

I do have a colocated server and have 1Gb fiber here at home.
Thus I have enough hardware/connectivity resources for sharing stuff.

But the problem is, I might then need to adapt my workflow and setup some sharing software.
And/or use some FTP upload.
So the time resource to setup/change is the limiting factor here.

But when Dropbox is requiring people to create an account, then that's no longer a viable (user friendly) option IMHO.

[M*I*B]

... japp, it's ok ...
If it's supposed to be something more than the simple display of the files in a folder, then of course there has to be appropriate software working in the background...
... just wanted to have it offered ...

[TD-er]

I think I'll just install some "own cloud" VM on my NUC PC in the metering cabinet downstairs.
But then I might need to upgrade that SSD first as it only has a 240 GB one which already is quite full and also has like 40-ish % lifetime left (based on TBs written)
So that's something for the holidays as it was already on my todo list to upgrade/replace that SSD. (or maybe replace that NUC)

[M*I*B]

... that's also a way to have the stuff at home ...
I have a NAS also (based on OMV in a 19" with 12 HDD-Slots 17T-R10) but my DSL is not for traffic ^^ So I have rent a VPS where I also drive some local sides and my MX, and for special use an non-default SFTP and URL's to give files to outside.

[TD-er]

I also do some work (network maintainance) for a company.
This sometimes requires me to move large files around and that's why I choose the fastest upload possible from my provider.
Since I need a fixed (and native) IPv4 address, I was already in the non-standard subscription tier and thus the extra costs for 1 Gbps wasn't that much anymore.

But to be honest, it is really hard (as in requires network knowledge) to achieve > 500 Mbps.
For example you need to have multiple streams to really get > 500-ish Mbps.

Anyway, I've had quite slow DSL for a long time, so I know what you mean and how frustrating a slow upload is.
So I feel quite priviledged I now -finally- have a fiber connection

[M*I*B]

... unsuccessful search for my third S20 ...
Just bought another one. We'll see when it gets here. The S20 are rare actually. So better I search for some more to buy for a nice price ...

So I feel quite priviledged I now -finally- have a fiber connection

[M*I*B]

Ok... Looks like the port isn't broken after all...
If the flasher is on my NAS, it simply doesn't work! Only after I put the whole folder back on my C disk does something happen again.
The flasher obviously does not work if it is called via an SMB share (here: R:\Operating Systems\ESP Easy, SONOFF, WeMOS\). A second USB2SER connected in parallel via RX<-TX from the UART used for flashing shows that the flasher called by the SMB release is not sending any data in the direction of the ESP.

I just downloaded the current one (0.04.009). Compared to the 007, the 009 version has the problem that it does not recognize a single COM port as active; but still works...

Bild_2022-12-22_162259959.png (29.03 KiB) Viewed 4976 times

[TD-er]

Have you also tried the "Espressif Download Tool" which is included in the zip file?
See here for some screenshots:
https://espeasy.readthedocs.io/en/lates ... html#esp32
The ESP32 screenshots are very similar to what you need for ESP8266.
Just make sure to only use the .bin files (not .bin.gz).

[M*I*B]

... I haven't checkout the other tool yet. I will do that the next days. Looks like that I have take much more attention about many things...

Some more to my former text...
It is not possible to use "program only". Every time I try I get an "COM port is already in use... Why is that?

Bild_2022-12-22_163619794.png (18.23 KiB) Viewed 4973 times

EDIT:
I have downgrade the "ESP Easy Flasher" to .007 and now they find the active COM-ports... Just like to say ...