"Feature" request: on boot do hardware init before Wifi connect

[paxi]

Especially with the sometimes unstable sonoffs it can take a long time until the configured boot states for GPIOs get applied.
Found the reason in ESPEasy.ino (line 564ff): hardwareInit() is run after the wifi stuff is done.

I use several sonoffs buried in lamps, they are powered through the original (wall)switches. This way the lamps can be used in the normal way. Just the delay between flipping the switch and the lamp coming on is irritating (especially if the wifi connection fails three times until AP mode is firered) and I think it would greatly improve the WifeAcceptanceFactor to do the hardware init first.

Is there anything speaking against moving hardwareInit() a few lines up?

[gajotnt]

Then maybe you should leave your esp device always on, and use a GPIO to control the relay. Im using this setup and works fine.
Im even using the sonoffs multiple GPIO to control the relay and another sonoff.

[paxi]

The lamps are controled by relais and can of course be controled remotely.
The point is to make them also controlable manually and boot as fast as possible into "relay on" so the tech-stuff becomes mostly transparent.

Improve usability and prevent confusion and anger if the "home automation administrator" isn't availible.

[gajotnt]

Exactly how i am using...

Theres maybe a few milli seconds delay, if thats what you're talking about, i dont think there's anything one can do.

[paxi]

My setup is different, the wallswitch breaks power to sonoff.

Mains > switch > sonoff > lamp

Wiring the switch to gpio would require to open walls and run additional wires or dig holes to burry the units...

[gajotnt]

Then theres your problem...the sonoff must always be connected to mains if you dont want the delay with the bootup of the device.

Then.... why have sonoffs? I dont get the advantage of using sonoffs with your current setup.

You have to flip the wall switch to turn on the light and sonoff and only then be able to control remotely?

[paxi]

Well yes, thats my problem and I know the alternative - it's just not practical. I don't think I'm the only one with such a setup. Most of us have to work with the existing wires.

To me it makes simply no sense to have pins boot states configurable when these are executed "long" after boot. At the instant when wifi is connected also the rules are processed and one can set states there... As of now it makes no difference and I'd like that to be changed.

Again: its a matter of wife-compatibilty paired with missing wires in walls and ceilings. A failsafe if Wifi doesn't work.

On another note: being a feature request this topic is addressed to developers - about a possible improvement of the firmware, not how to setup the hardware. No offence meant and thanks for your suggestion, but if you aren't a programmer there's nothing to discuss here, refer to the single question in the OP.

[Shardan]

Same here.

I can't set up additional wires so i have to connect the sonoff through the wall switch.

Besides that remote control is nice but e.g. for a visitor using the wall switch is easier then learning to handle a tablet/phone/pc remote.

Regards
Shardan

[paxi]

Exactly. Almost everyone will intuitive flip the switch a second time (if lamp was remote-off) but then it has to come on fast (or you'll hear "your lights are broken").

We are almost neighbours,
Grüße aus Enger

[gajotnt]

Just tried To help

[paxi]

Sure, everything's fine.

[psy0rz]

I understand the need for this. I also think the bootup is too slow in some cases.

It should enable default output settings as fast as possible, so that hardware is in an ok config while its still trying to connect.

Please post a feature request on the github issue tracker for this.

[paxi]

Done - in the "official" repo.

Thanks!

[psy0rz]

Thanks!

I also want to remind everyone to use the forum first and keep the issue tracker clean. Only if you're sure you found a bug post it on the issue tracker. Feature requests should be first discussed on the forum before posting them on the tracker.

Support requests or questions should never go in the issue tracker, only on the forum where there are many great people that can help.

We have limited development resources, and we dont want to get those overwhelmed with "useless" features or support requests. (Thats why Martinus was reluctant to open the issue tracker)

Edwin

[neykov_t]

Nice job, i will wait for release. It's realt usefull feature !!!