Hello!
It is currently not possible to do it natively using commands. You will need to rebuild and flash the firmware with the above settings.
I’ve managed to do so without the need of a minimal firmware, the final bin size is small enough to flash directly.
There a risk involved but no way out.
You can flash all of them by uploading the firmware online and doing it by OTA. Tasmoadmin is your best friend.
Thanks.
@Schneider thanks for the quick reply! I thought so, to bad… Weird thing is, i had these issues with 2.4///6.4.1 then i’ve uploaded 2.3///6.4.1 and it was solved. Now after i’ve updated to hass 87 i’m seeing more and more offline devices.
Just cant link it to updating hass…
It depends on the firmware size of the currently flashed firmware, too!
You are correct sir!
It’s not hard to compile minimal as well and do a 2 step flash the first time…
Why would you, just ota latest version minimal and asap upload the newly compiled, right?
I may be a little late on in the conversation here, but I originally flashed my RF bridge with sonoff-classic (it is my first Sonoff device and I had no idea which was the most suitable Tasmota firmware to use) using core 2.3.0. It was stable.
I then wanted to test out the OTA update (just for sh1ts and giggles), so did an OTA flash with sonoff.bin core 2.4.2, and immediately started to get the disconnects. So, I flashed it again using OTA sonoff-classic.bin core 2.4.2 and it seems to be stable (no disconnects in 24 hours).
Just my observations and admittedly it is a very small sample group of 1 x Sonoff device - I wonder if this is something specific to the sonoff firmware and sonoff-classic firmware is not affected. Something to ponder and perhaps test for those of you with multiple Sonoff devices flashed with Tasmota.
Also, for those who think it may be a fix to use core 2.3.0, it is vulnerable to KRACK, as documented at https://github.com/arendst/Sonoff-Tasmota/wiki/Theo’s-Tasmota-Tips#20180523---relation-tasmota-and-esp8266arduino-core-version. I personally would rather have an unstable Sonoff than a vulnerable network.
I personally want a stable switch… you do know it’s practically impossible for that vulnerability to have any real effect in a home network don’t you? IE the risk while non zero is insignificant.
In any case, Tasmota Support fixed the issue with core 2.3.0 and I now have stability back again along with the cool new stuff from dev 6.4.1.21.
I also have tried core 2.5.0 latest builds of that and it’s better than the earlier ones and better than 2.4.2 but still problematic…
Hello everyone!
Just a heads up: I’ve completely given up on Tasmota and MQTT. I’ve switched all of mine 39 ESP devices running on my home and office to the ESPHome project.
Been using the native API to connect them to HA and de firmware is amazingly fast and reliable. ESPHome is almost like a small version of Home Assistant running inside a Sonoff Basic, for example.
I strongly suggest all of you to switch to ESPHome ASAP and avoid using MQTT (in general) and TASMOTA firmware. It has been weeks now with no disconnects and instabilities over wifi network so far, the customization inside the firmware is incredible, very powerful and simple to learn/use.
Thanks!
I have been using below esphome yaml, just change the ip and switch name, you still have to setup your wifi setting 1 time only and can you can deploy your switches quickly. Works with S20 and Basic, maybe others
substitutions:
plug_name: myswitch
ip_address: 192.168.1.8
esphome:
name: ${plug_name}
platform: ESP8266
board: esp01_1m
board_flash_mode: dout
wifi:
ssid: xxxxx
password: xxxxxx
manual_ip:
static_ip: ${ip_address}
gateway: 192.168.1.1
subnet: 255.255.255.0
reboot_timeout: 15min
fast_connect: yes
#domain: lan
api:
password: 'xxxxx'
ota:
password: 'xxxxx'
logger:
web_server:
port: 80
time:
- platform: homeassistant
id: homeassistant_time
binary_sensor:
- platform: gpio
pin:
number: GPIO0
mode: INPUT_PULLUP
inverted: True
id: button
name: ${plug_name}_button
on_press:
- switch.toggle: relay_template
- platform: status
name: "${plug_name}_status"
sensor:
- platform: wifi_signal
name: "${plug_name}_wifi"
update_interval: 10s
- platform: uptime
name: "${plug_name}_uptime"
text_sensor:
- platform: version
name: "${plug_name}_version"
switch:
- platform: gpio
pin: GPIO12
id: relay
#restore_mode: ALWAYS_ON
- platform: template
name: "${plug_name}"
id: relay_template
lambda: |-
if (id(relay).state) {
return true;
} else {
return false;
}
turn_on_action:
- light.turn_on: led
- switch.turn_on: relay
turn_off_action:
- light.turn_off: led
- switch.turn_off: relay
- platform: restart
name: "${plug_name}_restart"
output:
- platform: esp8266_pwm
id: green_led
pin:
number: GPIO13
inverted: True
light:
- platform: monochromatic
name: "${plug_name}_green_led"
output: green_led
id: led
default_transition_length: 1ms # controls the light fade/transition timeI would love to change all of my devices also but the inability to emulate as a Wemo device as Tasmota supports is preventing me. Apparently the ESP Home dev isn’t wanting to support it either (fauxmo etc).
Out of utter frustration with Tasmota I was looking to switch to esphome as well but could not find a config that worked the same as I had been using with Tasmota (or even EweLink for that matter). I found the support inadequate…
There was a nasty bug in Tasmota - couldn’t compile core 2.3.0. Using core 2.4.2 or 2.5.0 resulted in dropouts all the time. Adrian at Tasmota worked out what the problem was and fixed it this week and I can again compile/use core 2.3.0. The error only happened if you used MQTT discovery but it’s fixed now and 100% stable again. Firmware 6.4.1 gave them a black eye as in this firmware they switched to core 2.4.2 as the default. Core 2.3.0 is rock solid even though it’s not supposed to be stable with a FritzBox and mesh networks. I don’t know what core espeasy uses. It seems odd to me that to change a setting on esphome, you have to reflash firmware!! In Tasmota it’s just a SetOption or MQTT command.
I also see people in raptures over the ‘native API’ in EspHome… yet you still have to use an addon and integration… exactly like MQTT so I don’t see the advantage at all…
Each to their own…
I’m not sure if i can even blame Tasmota anymore. Since switching over to RabbitMQ from Mosquitto i have a few days of stable v6.4.1, Core 2_4_2/2.2.1 switches running. The independence from home assistant of the Wemo Emulation is a must for me, so i’ll stick with Tasmota for now. If it turns out to be stable enough i might not revert to core 2.3.0 anymore.
Hm… interesting point regarding Fritz mesh which I can’t confirm.
I’m running a Fritz mesh with 7590 Router and two 1750 nodes flawlessly with Tasmota 6.4.1 on core 2.3.0 (aec24ac9) falshed to Sonoff S20s and Shelly1s. Also discovery is enabled.
With 2.4.x the WiFi connection was terribly bad and didn’t try 2.5.x for now.
My own ESP8266 thermostat firmware also runs flawless with arduino core 2.5.0.
I have no issues with Fritz Mesh but if you check the Tasmota troubleshooting, it’s a problem apparently. Core 2.3.0 is rock solid for me.
@elRadix any idea how to make the esphome yaml for CE Smart Switches?
https://github.com/arendst/Sonoff-Tasmota/issues/4003
I don’t even care it they dim, I can worry about that part later. I have 4 connected right now and 2 of them, no matter which version of Tasmota I try, nothing but Unavailable.
Hello @DavidFW1960. There is no addon needed to use ESPHome, just add the devices using integrations and you are done. What feature do you miss comparing to Tasmota? Thanks.
There is an addon for Esphome or if not using hassio there is an esphome installation.
I was having trouble getting a switch to turn on the LEDs when it was on and also had issues getting a switch to toggle on for 2 seconds and turn off again.
The whole setup of esphome is convoluted… changing firmware to enable to use a feature or just sending a command in Tasmota… I know which I fine easier and more intuitive.
Yes, there is an addon indeed but you don’t need it to connect or run ESPHome native API. I’ve compiled all of my firmware using terminal on my Windows PC, I don’t think the RPI3B is suitable for that task… I can test, compile and upload everything with ease.
What device does this problem occurs? Sonoff Basic? I’ve also had problems with the LED being on when relay as turned on. This was solved by removing the status_led component and creating a light entity inside the project. Here is an example:
output:
- platform: gpio
id: main_relay
pin: GPIO12
- platform: esp8266_pwm
id: basic_green_led
pin:
number: GPIO13
inverted: True
switch:
- platform: output
name: ${switch_entity_id}
id: main_switch
output: main_relay
icon: ${switch_icon}
on_turn_on:
then:
- light.turn_on: led
on_turn_off:
then:
- light.turn_off: led
light:
- platform: monochromatic
output: basic_green_led
id: led
This will create a switch entity that turns on the led according to the current state.
The status_led feature can now be achieved by the new trigger Otto just released: wifi_connected, using automation.
ESPHome was just updated last night with great new features and fixes. I really recommend you investing some time on it.
Let me know if you need any help with it.
