Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why mocktuyacloud + custom firmware? #5

Open
browntownington opened this issue May 3, 2019 · 5 comments
Open

Why mocktuyacloud + custom firmware? #5

browntownington opened this issue May 3, 2019 · 5 comments

Comments

@browntownington
Copy link

Hii sorry if I missed the point here.

But I'm trying to figure out why you would use mocktuyacloud and custom firmware.
Wouldn't putting custom firmware (tasmota?) eliminate the 'Tuya code' and communication to their cloud?

And is the point of mocktuyacloud simply not to stop communication to their cloud without modifying the firmware?

I wish to purchase some 240v switches and power point wall sockets. I'm a little worried to be doing custom firmware on something that wasn't specifically designed for. But I also don't want the devices needing the cloud to perform their task.

Thanks in advance!

@kueblc
Copy link
Owner

kueblc commented May 3, 2019

Hi @browntownington, thanks for your interest in this project.

At this point, the contents of this repository is primarily useful for developers. It provides a base implementation of the Tuya cloud service that can be extended to do fun things, such as getting a Tuya device to install a 3rd party firmware. That's the example that is set up right now.

You can also certainly use this framework to sandbox devices from the Tuya cloud, so you can use stock firmware without cloud interaction.

To do this, redirect DNS calls to *.tuya(us|eu|cn).com using dnsmasq or similar running on your home server, with your router set to use this as the primary DNS. You'll also want an MQTT broker such as mosquitto running on this home server. Then write a simple node script that imports lib/server and lib/mqtt, which will receive and respond to requests from the device to communicate with the cloud.

If there's sufficient interest I'll invest some time into cleaning up this library and add better examples of common use cases.

@browntownington
Copy link
Author

Hi @kueblc thanks for the detailed response and your work among this!

These Tuya turnkey devices are everywhere, and I think their use will only continue to grow and span further. I have a couple issues around custom firmware for the Tuya 240v rated devices (such as power point and switches.)

The devices are rated and approved as stock. Changing the firmware for a 240v rated device would break it's compliance and if something went wrong it could it would be hard to forgive. But also, all the reading up people that have applied custom firmware for these have advised that certain important things don't work (e.g the lights on the on/off buttons.) Note to mention what happens if new owners or tenants reside in houses where these are installed.

So Mockcloud makes heaps of sense. If full functionality can be achieved with the reassurance of knowing you are cloudless. I personally would love to see some better examples of common use-cases in the future and I am sure there are many others like me. Even a HA docker addon in the future would be super neat and maybe something I can look into once I've figured it all out.

I might buy a light bulb to test out your suggestions above and if all good I might commit to the switches/power-points. thanks man!

@browntownington
Copy link
Author

Setting up DNS and MQTT shouldn't be too difficult. But I think the part I will need to figure out is how to "write a simple node script that imports lib/server and lib/mqtt, which will receive and respond to requests from the device to communicate with the cloud." If you have any examples of this I think that would be super helpful!

@TRSx80
Copy link

TRSx80 commented Jun 22, 2020

I came here today wondering the same thing.

My case is slightly different however. I would be perfectly fine with flashing alternative firmware, but I've learned I bought some of the TW-02-based (WinnerMicro W600-based) devices, which are not supported by any of these alternative firmwares...

So, until any hacking efforts (updates on that front in linked thread) produce results, I wonder how possible it would be to get these devices working with stock firmware and just contain them within the LAN using this project software?

If there's sufficient interest I'll invest some time into cleaning up this library and add better examples of common use cases.

@kueblc,

I realize you are probably busy, but I think the more we see these other types of modules being used, the more of a need there will be for this sort of thing. Just my $0.02.

As always, cheers, mate! 🍻

@TRSx80
Copy link

TRSx80 commented Jun 22, 2020

Update: I made a post at tuyapi asking a couple questions to confirm couple things, but I think that software might fit my needs for containing the devices in the LAN without "phoning home."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants