Merge of two plugins???

[IWCaldwell]

Device Infomation JSON File

Detail Informations

I am curious, we have homebridge-tuya which is great but relys on Tuya servers, we have homebridge-tuya-plus which uses tuya locally, but doesn't support everything perfectly.

What would you say if I were combind the two together, I could have a setting in there, you can choose cloud or local and do you settings, one plugin to have either local control or cloud control. Thoughts? I am happy to put together an example of this.

Here is Tuya plus:
https://github.com/adrianjagielak/homebridge-tuya-plus

[tassy-h]

Thanks for the awesome idea! Really appreciate you sharing it.
Having a plugin that can switch between cloud and local modes sounds super handy.
The only concern is that local control might go against Tuya’s terms of use, which could put this plugin at risk. Since I’m maintaining the repo, I need to make sure it stays safe and available for everyone.
Because of that, instead of adding this feature directly here, it might be better to fork the project and build a new plugin around that concept.

Tuya Terms of Use, Section 6.5

[IWCaldwell]

I reviewed the terms of service, and it doesn't violate their terms of service, but can understand the hesitation.

What the Plugin Does
The plugin uses TuyaAPI (created by @codetheweb), which is a reverse-engineered implementation of Tuya's local LAN protocol. This means:

• It allows devices to be controlled locally on your network without going through Tuya's cloud
• The protocol was reverse-engineered through analysis of network traffic between Tuya devices and the Tuya Smart app
• It communicates directly with devices over port 6668 using the local network

Section 6.4 specifically prohibits:

Reverse engineer or extract source codes from the Licensed Software

What was reverse-engineered: The network protocol (how devices communicate)
What the terms protect: The Licensed Software (the Tuya mobile app itself)

While the plugin itself doesn't directly violate the terms (it's not redistributing Tuya's software), it relies on reverse-engineered protocols, which Tuya doesn't officially support.

I can understand some hesitation with this, and happy to not do it, just always nice to have the option to do it locally or in the cloud.

[tassy-h]

Since English isn’t my first language, I’ll trust that your interpretation is the correct one.
Anyway, I think merging the two plugins would mean reworking a lot of the design. When I get some free time, I’ll at least take a look through the homebridge-tuya-plus plugin’s source code.

[tassy-h]

After reviewing the source code of homebridge-tuya-plus, I found that its implementation differs significantly from homebridge-tuya. Integrating the two would not be a simple merge; it would require substantial conversion or porting work. This also means that any future updates or fixes committed to homebridge-tuya-plus would be difficult to incorporate into this plugin.

Additionally, this applies to both plugins: the definitions of accessories and the implementation of their characteristics are only partially organized within the source code. Because of this, it is not feasible to unify the implementations of the two plugins, and therefore there is little benefit in combining them into a single plugin. If the internal logic simply ends up calling each plugin separately, it would be more stable for users to install and use the two plugins independently.

Even if I wanted to address these issues, I cannot properly test or verify the behavior without having the actual devices on hand. If the source code could be reused as-is, it might have been possible to skip some of the verification, but because the integration would require extensive modifications, thorough testing is essential—and without the devices, that testing cannot be done.

I have a Smart Plug device, and since both plugins support it, it might be a good first step to reorganize only the Smart Plug–related code and try implementing the LAN functionality as a small experiment.

[IWCaldwell]

Put together a proposal: #20

It makes some major upgrades, took me a bunch of time to put it together, and test it. I used both tuya-plus & tinytuya to get local fully working correctly. I wanted it to be backwards compatible so people did not need to change their config if they upgraded. Will need to cleanup the Wiki if we decide we would like to use this.

Wanted to shoot this over to you so you can check it out, see how I changed things, etc...

[IWCaldwell]

@tassy-h Issue still looks open to me here

[IWCaldwell]

I am running the beta on my homebridge, I upgraded and the config continued to work from the cloud.

Then switched it over to local from cloud, and it works, woo hoo

[tassy-h]

Thanks for checking the beta release!
I tried running the beta on my side as well, but it didn’t work — looks like something’s going wrong.
It might be an issue with my environment, so I’ll try a few things again when I have some time.

And, Issue was open. I mistook it for PR. I closed the PR by mistake. I'm sorry.

Also, I have a suggestion. Since we now have a hybrid setup with both LAN and Cloud, maybe we could automatically map the command and dp_id information from the Cloud API with the dp_id values retrieved over LAN when the setting is set to “both”? That way, users wouldn’t need to manually map them in the settings screen.
It looks like switching from API v1.0 to v1.1 would allow us to fetch dp_id:
https://openapi.tuyaus.com/v1.1/devices/${deviceID}/specifications
With the current design, I think the logic would be added to LocalDeviceManager#_buildSyntheticSchema, but since it’s a Local DeviceManager, it feels a bit odd to have it call the Cloud API.
So maybe it would make sense to introduce something like a HybridDeviceManager instead.

[IWCaldwell]

Oh interesting! So if I'm understanding right, you're saying when someone has both LAN and Cloud enabled, we could automatically match up the dp_id info from the Cloud API with what we get from LAN, instead of making users manually map everything? That would definitely be smoother!

The HybridDeviceManager idea makes sense too — calling Cloud APIs from LocalDeviceManager does feel a bit weird. I'm happy to work on refactoring this if you think it's worth doing!

Also, just thinking out loud here: what if we made it fully hybrid where if a LAN call fails, we automatically fall back to the Cloud API? That way people get the best of both worlds without having to think about it too much.

And no worries about the PR/issue mix-up, happens to everyone!

[tassy-h]

Exactly! Since we can take advantage of both LAN and Cloud, the idea is all about making the most of that.
And if we can also implement the fallback you suggested, most users will be able to immediately experience the benefits of both LAN and Cloud. I think that’s a really great direction.

[IWCaldwell]

I will work on it next week, great idea!!

[tassy-h]

Thanks! I’m really excited — it feels like this is turning into something great.
If there’s anything you need from me, just let me know anytime.

[IWCaldwell]

Ok, got a new PR up for this: #23

[tassy-h]

Thanks for the update!
I tested the plugin you updated on my machine, and it seems that devices not detected over LAN behave strangely when using the both mode.
The devices that fail to appear on LAN are actually Virtual Devices I added in the Tuya Cloud Project for testing, so this might be a situation that wouldn’t normally happen.
I’ll look into what’s causing it when I have some time, but I wanted to share the situation for now.

Also, I’m working on fixes for the v2.x branch for another issue, but I plan to merge those after things settle down with the v3.x updates.
So no need to worry about the v2.x changes at the moment.