Wifi disconnect renders devices useless.

[Geitde]

I just noticed that when Tasmota is loosing wifi for some reason. e.g. weather related range change it completly fails. This not only happens on boot, but also on runtime.

I have these OBI Plug devices and one of them is on good dry/warm conditions with 22% signal strenght connected. It worked nicely until the weather got colder and we got a little rain, which seems to caused that the 8266 was not able to connect anymore.

This should be no big deal, but somehow it is. The device gets to focused on regaining a proper wifi connection that even timers and the button failed to work properly.

Being able to connect to a device and use it via SmartHome stuff is just one feature, but if wifi fails and everything stops working, this is IMHO a huge problem.

I havend used any SmartHome stuff and every device is working on its own, so a dropped wifi should have no effect. Strangly it has. Timed lights failed to work properly and even the devices button, just caused a quick on/off, when pushed.

As soon as I plugged the device with 5.12.0k firmware into a plug where it regained a connection, it worked like expected again. I replugged it where it belonged and it failed.

For me this seems to be a design flaw.

[Frogmore42]

Perhaps it is a design decision. Tasmota was not designed to be standalone. Timers were only added recently. Previously, it was designed to be part of a larger system and had nothing of significant value that it could do without network connectivity.

[arendst]

You might want to take a look in the wiki - commands regarding wificonfig options and learn more about wifi oriented smarthome equipment.

Bottomline, without wifi, or zigbee, or any other communication protocol it's no home automation at all but just a remote controlled switch.

[Geitde]

The point is that without wifi tasmota it is nothing, as it completly fails, even for tasks it can perform inside the device, like unlocking the cat door in the morning or turn the light on via timers.

If your bottomline is true, why are there timers in the first place, when anyone can block them anyway? In that case tasmota can save much space inside the 8266 and drop timers completly as the home automation server could handle them with the same failure rate.

Without wifi a tasmota controlled device is nothing. Not even a remote controlled switch as you named it, as there is nothing you can control it with, as even the hardwired buttons fail.

Anyone with a portable AP can break tasmota timers, by just cloning the APs name and sending a better signal, or by blocking wifi completely, which is quite easy by simply using some old AV tranceiver.

No warning when there is water in the basement even with the siren connected to the same device, because there is no wifi? That is not even close to smart home.

I would have expected that timers inside a device would work perfectly to switch relays inside the same device, even without wifi, which is not even needed for that and other tasks at all.

[arendst]

If I were you I would:

• Read the wiki - commands first and set my wificonfig accordingly.
• Look around how other people are solving issues
• As a last resort ask kindly how they did it.
• Or make a PR with a solution you can live with

[Geitde]

I am not stupid. I know how to setup my network. Other people are not solving the problem. They simply did not run into it yet (or did not notice) and so there is no need to ask how they solve this.

Fact is wifi can be corrupted by anyone from the outside and loosing the wifi connection should at no point interfere with the normal device operation as that may be a timer, a hardwired switch or some connected sensor which drives a relay.

The device should try regain connection for sure, but not as its main task and not as a loop, where nothing else matters. This has to be done asynchronous, while normal operation like probing sensors, timers and actions on the relays still have priority.

Wifi is a link to the world, but failing should never overtake device internal stuff. Just imagine a heating system, which just shut down the heater, because the destination temperature was reached. Now some wifi AP dies randomly. The heater never turns on again, even if the sensor claims it starts freezing, because the new priority is not to regulate temperature, but to find wifi.

Same for the basement alarm, which never gets triggered when wifi gets lost.

People are using their devices for all kind of stuff and home automation must not be the centre for any of that. You want somethings be handled internally, so in case of a wifi failure nothing bad happens.

Timed lights never go on or off because wifi search is the most important problem in the world.
Instead of saving enery the lamp now stays on 24/7 for weeks, Or the presence emulation fails for the same reason, when the lights never turn on.

Instead of lights it could be the garden watering connected to the sonoff. Ups, flood incoming, because the off timer got ignored due a wifi problem.

The point is loosing wifi is an attack point to any tasmota driven device. It may be random or on purpose. Devices may simply freeze in their current state until wifi comes back, Depending on what people use their devices for, this can be dangerous.

That is my point.

[Jason2866]

yes your point... feel free to change the things you do not find ok, or leave it and use a other solution.
Many people see things from a other point and are very happy with that what the got for free

[Frogmore42]

@Geitde it seems that Tasmota is not for you. I am not sure what other open source projects you have encountered (or closed source for that matter) but I find Tasmota to be quite useful. I also find it works much better to not criticize something before I have spent more time understanding what its design goals were. It is clear (from your investigation) that Tasmota was not designed to do what you consider to be the most important thing in the world.

Or, you could take a look at the documentation and see if one of the wifi config modes would be more to your liking.
https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#wifi
Seems like 4 or 5 might work for you.

But, if you are really concerned about WiFi attacks and security, I would say home automation is not ready to meet your requirements. Just remember, "to err is human, to really mess things up you need a computer"

[Geitde]

Well, seems I am not that stupid after all.

#2544 and the resulting fix seems to fix my issue as well.

[Frogmore42]

I don't see anyone saying you are stupid at all. The issue that was fixed addresses WiFi reliability, which will make it much less likely to cause the issue you observed, but does not actually fix that issue.

Your complaint was not that the connection was dropping, but rather that when it did it was a "huge problem" (which many people would read as stupid 😃) that it spent all its time trying to get the connection back. By default it still does that. I have a Particle Photon that has a default mode that is similar. The original SmartThings hub was similar. In all cases those were design decisions. I never bought one of the original SmartThings hubs because I thought that was a stupid design decision.

I am happy that Tasmota is working for you now. Personally, I am impressed with the code that Theo created and the effort that he puts into maintaining it. I don't believe people thank him enough. I have no idea how he manages to find the time to do it all. So, if its working for you, it might be a good idea to say thanks to Theo. (Thanks Theo!)

[titomontes]

Perhaps you should explore Zigbee or Z-Wave; both protocols have an independent band, and are in fact more reliable and spend much less energy than WiFi. The downpoint: one sonoff: 5$. One Z-Wave switch: $50.

[Geitde]

My problem was never about the reliability of the wifi connection.

It was that without wifi the devices simply failed completely and stopped working in any way.

The entire device crashed with wificonfig 4 & 5 and no wifi available.

No wifi resulted in non working light switches and non working timers. Just a crashed peace of hardware doing nothing and consuming power. This bug got fixed.