I have an atomberg(tuya) fan that has Espressif chip.
So I was wondering if there is a way to bring it to esphome to remove the cloud dependency
This is probably not the product you are referring to, as it does not have a ESP chip. That said, it might give you some ideas. I am very impressed by this groups work making Tuya device 100% local, check out their github as well as the write ups on this forum. Good hunting!
Thanks for the reply @dproffer .
The product I am referring to is Deal of the day: Atomberg Renesa Smart + 1200mm BLDC Motor with Remote Energy Saving Ceiling Fan (Oak Wood) https://amzn.eu/d/9W6uusF
Damn that Amazon, donât you love/hate those tech deals of the day and prime sale 
more added to the todo queue!
Are you sure this product has the âold schoolâ ESP chip and not the newer chips? It looks like a pretty new product, and I am finding most new Tuya stuff has moved away from ESP. This is why the work of the group I cited is so interesting and worth supporting. There are a lot of interesting and useful Tuya products out and coming out. But making the 100% local as you citing in your initial post is a big win.
Another thing that is nice about the device I cited, is that is should work with the universe of âdumbâ fans, more selection and a fall back to a simple fan if all the enhancements do not work for the âsignificant otherâ
Now back to the Amazon web site
@dproffer I also initially thought that the fan has newer chip but the Mac address of the device is registered as espressif and not as tuya chip
1 Like
I heavily suggest to go the libretuya way instead. Not only they have a working esphome port already but they also plan to upstream the work to esphome 
Thatâs awesome 
and you should be perfectly fine flashing esphome on that.
Only thing you also want to know (probably upfront) is what other peripherals are connected to the esp and if all are supported by esphome 
@orange-assistant both groups are doing excellent work and should be supported. As well as the work by tuya-cloudcutter. The Holy Grail is to have the ability to do a OTA firmware replacement with Tasmota, ESPHome or Arduino framework clone. These three groups and others are making fine progress.
What I learned the last two decades is that there is open source and open source. 
While for both the source code is available only one of them actively upstreams (or mainlines) their code. This has various advantages for users and programmers. First obvious one is that if stuff gets integrated in other software it can be easily be updated (the opposite would be just to cherry pick code snippets which are a pain to maintain/update). 
What I found out for myself the hard way is that I actually only want (arm/x86-64) hardware that has active (linux) mainline support. This is even true for the peripherals like wifi or bluetooth sticks. You might wanna ask why that? Simply because I want future proof hardware and not being forced to EOL perfectly working gear simply because it doesnât get any software support anymore. 
Many projects (like libreelec for example) donât allow âout-of-treeâ drivers (for example for wifi) in their project - so everything that isnât mainlined doesnât work. 
IMHO is to support and push software which does active upstreaming. Libretuya looks like to be one of thoose as it aims for nothing else as platformio which on the other hand is the base for many projects like esphome and tasmota(?). 
I am really not trying to disagree with you here, but just inject the timing importance of the work being done here. Which IMHO tops for now the idea of upstreaming for the term. If this door is closed by the vendor, that sux!
Not sure if I fully understand your use and emphasis of the term âupstreamâ. All three of these groups are or have done yoemans (nee yoepersons) work to reverse engineer very proprietary and not local firmware. Where is the âupstreamâ to? Back to the vendor, I question that. Look at the failure of this vendor to work on the commitment that I understand they made to making their product more âlocalâ. As to âupstreamingâ to works like Tasmota and ESPHome, would not the term âforkâ be a better term. Not only is this work we are talking about based on this ânon-openâ environment vs. the relative open environment of the Espressif ESP product, but also not supported by any for profit vendor ( at least that I know of).
So, I just want to give full âpropsâ to all of the folks making products local, open and transparent, whether they are âupstreamingâ or not. In the nacient stage of all of this, that adds a lot of cycles. Not that consolidation and simplicifcation should not be one of the items on the priority list. I get the goal that think you want to include but get the basics first, I am okay if I have to deal with some differences between BK and Tas for a while, if that give me more local control of this vendors products sooner. Because, guess what, this vendor is going to close these windows of openness as soon as they can, they have already demoed this behavior.
This discussion is under the whole umbrella of âright to repairâ IMHO, and is a very important topic.
Hoping we all get a lots of âresponsiveâ and secure home automation devices for our homes!
ESPHome works with Atomberg smart +
here is the config i used.:
esphome:
name: kids_fan
friendly_name: kids_fan
esp8266:
board: esp01_1m
# Enable Home Assistant API
api:
ota:
web_server:
port: 80
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "kids-Fan Fallback Hotspot"
password: !secret wifi_password
captive_portal:
# Make sure logging is not using the serial port
logger:
baud_rate: 0
uart:
rx_pin: GPIO13
tx_pin: GPIO15
baud_rate: 9600
# Register the Tuya MCU connection
tuya:
number:
- platform: "tuya"
name: "kids Room Fan Speed"
id: kids_fan_speed
number_datapoint: 3
min_value: 1
max_value: 5
step: 1
internal: true
on_value:
- lambda: !lambda |-
if(id(kids_room_fan).speed != id(kids_fan_speed).state){
auto call = id(kids_room_fan).make_call();
call.set_speed(id(kids_fan_speed).state);
call.perform();
}
switch:
- platform: "tuya"
name: "kids Room Fan Switch"
id: kids_fan_switch
switch_datapoint: 1
internal: true
on_turn_on:
- lambda: !lambda |-
if(!id(kids_room_fan).state){
auto call = id(kids_room_fan).turn_on();
call.perform();
}
on_turn_off:
- lambda: !lambda |-
if(id(kids_room_fan).state){
auto call = id(kids_room_fan).turn_off();
call.perform();
}
output:
- platform: template
id: test_output
type: float
write_action:
- lambda: |-
ESP_LOGD("main", "Dummy output");
fan:
- platform: speed
name: "kids room fan"
output: test_output
id: kids_room_fan
speed_count: 5
on_turn_on:
- lambda: !lambda |-
if(!id(kids_fan_switch).state) {
id(kids_fan_switch).publish_state(true);
}
on_turn_off:
- lambda: !lambda |-
if(id(kids_fan_switch).state) {
id(kids_fan_switch).publish_state(false);
}
on_speed_set:
- lambda: !lambda |-
if(id(kids_room_fan).speed != id(kids_fan_speed).state){
if (id(kids_room_fan).speed == 1) {
id(kids_fan_switch).publish_state(true);
auto call = id(kids_fan_speed).make_call();
call.set_value(1);
call.perform();
}
if (id(kids_room_fan).speed == 2) {
id(kids_fan_switch).publish_state(true);
auto call = id(kids_fan_speed).make_call();
call.set_value(2);
call.perform();
}
if (id(kids_room_fan).speed == 3) {
id(kids_fan_switch).publish_state(true);
auto call = id(kids_fan_speed).make_call();
call.set_value(3);
call.perform();
}
if (id(kids_room_fan).speed == 4) {
id(kids_fan_switch).publish_state(true);
auto call = id(kids_fan_speed).make_call();
call.set_value(4);
call.perform();
}
if (id(kids_room_fan).speed == 5) {
id(kids_fan_switch).publish_state(true);
auto call = id(kids_fan_speed).make_call();
call.set_value(5);
call.perform();
}
if (id(kids_room_fan).speed == 0) {
id(kids_fan_switch).publish_state(false);
}
}
you need to solder directly on the chip for 3.3v and not use the pads. the image shows it WRONG here. i had to change the soldering point.
2 Likes
Can we do it ota as we already know the IP as it is already connected to our network?
did you get any success flasing newer atomberg fans?
newer fans have esp32-c3-mini-1
Can someone put up clear pics of both sides if control board for new esp32 fans?