For Gladys’s response
This button normally.
1 Like
That’s the one
You can then go to your Gladys machine and from the command line run:
docker logs gladys-tuya-test -f to
Hello @Papashultz,
I might have some good news!! I found a service that supports protocol 3.5. I’m updating the test image, build in progress. If you want to test, it works for me!!
I validate, image updated, the automatic detection of IP addresses even in protocol 3.5 is now functional!! 
If you can test by clicking on « Automatic local scan » that would be great.
If it doesn’t work, please send me the logs again privately like last time!!
For information, I also added an option to disconnect from the cloud on the Configuration page :
We can perfectly retrieve devices that are completely disconnected (if present on the same network as Gladys thanks to the local UDP scan). However, without going through the cloud, some information will be missing, such as the device name, because that is only stored on the application and not on the device.
By retrieving via the cloud and then doing the local scan, we get all the information.
I was able to test local control of a Tuya plug end-to-end without going through the cloud, it works perfectly.
Now we just need to add support for the rest ^^
Hello,
Circumstances are working against this trial.
Sorry I couldn’t reply sooner. I’m not at home right now; I had to make a 690 km trip to do some grandparent-sitting. I won’t be back home for at best eight days.
I was happy to start this trial and I would really like to be able to finish it.
If there’s no one else and it’s not too urgent, we can reschedule it. If the integration is done by then, I’ll test it as well.
Good luck, see you in 8 days.
2 Likes
Hello!
Quick feedback.
I went to get two plugs this afternoon with an energy meter. €6.50 each. They’re big and ugly but behind a piece of furniture…
After adding them in the app, switched to Gladys, fresh install. Everything works perfectly!
I already had a cloud account and after renewing the contract, everything ran smoothly right away. And on that topic, there was no error message in Gladys telling me that renewal was necessary…
I was able to request 6 months directly.
When switching to local mode, the devices disappear from the dashboard but after adding them again, control is instant!
It would be good to mention that when you control locally, you don’t lose control via the app. I tested version 3.5, no issues!
I tested the “propose support” button via GitHub but isn’t there a risk of creating duplicates? Shouldn’t it ask for a brief description of the request or the hardware? Say that for cameras, the stream will not be accessible (but alerts maybe?)
So, I proposed via GitHub the clamp-on energy meter and the doorbell (you never know if the button might be accessible…).
I haven’t paired the second plug yet if you want me to do more tests (and even though they’re the same, I got two different versions 
) …
Well done anyway! And local control is awesome!
Hello @Papashultz,
No worries, that’s nice of you to let us know. You’ll of course be welcome to test again when you return. And it might have fixed a few things that weren’t working properly.
@GBoulvin is also taking part in the tests. We should make good progress together!!
Enjoy the grandchildren 
Hi @GBoulvin,
Ah darn, this point interests me greatly ^^ :
- Did you get an error message when attempting to connect nonetheless? Even something other than the expected one? Or nothing at all, just no connection?
I wanted to test, but I admit I was afraid to try stopping the trial period (can you really do that, by the way) to request it again afterwards… I preferred not to touch anything ^^
But for this, we’ll need to find a way to run the test so I can find the related logs.
Indeed yes ^^ Do you happen to have more than 10 devices? ^^ Otherwise I’ll buy them to test how it behaves in terms of info reporting / read-controllable / cloud-local. If the control only applies to the cloud but it works locally and we still have the read for the >10 then it shouldn’t be restrictive anymore ^^
I’ll test to see how it behaves locally without the cloud control. Because it’s dumb, once made Controllable you can’t put them back to read only 
Oh!! Not good ^^ I hadn’t tested that ^^ I’ll see what I can do ^^
Indeed, I’ll add that to the « Local » section of the configuration page info.
Top! So you have devices on 3.5? Control OK?
That’s a good question ^^ Haven’t tested, I’ll test that on a plug but for me:
- Cloud yes of course
- Local normally no since it communicates directly with the device but needs testing
- If yes locally, then we’d need to test a reappearance via the auto local scan
Indeed!! I suppose that applies to other integrations that include this option. We can add a blurb explaining to check in parallel that a request doesn’t already exist. See if we can do it automatically …
Indeed! Even though normally via the cloud we have all the info needed to add it. But yes, people can put whatever they want ^^
So I can… but for this… it might be possible via an addition ^^ I was able to do it for Netatmo ^^ (Even if still not released 
)
And for alerts… we’ll see, the GitHub request might say more!
Having a link between the camera stream and the control/alert features could be useful… with AI… image analysis => check alert => control camera…
Awesome!
I’ll delete them, I add things, I realize there’s not enough info, notably for local, if we do the local DP Poll, we need the info for adding.
I see that the issue titles include the types of hardware, I’ll add whether it’s a local or cloud management request + the product_id allowing maybe to search beforehand if an issue exists
If not paired yet, I’d like you to run the local control test without having given control on the Tuya Cloud
Great thanks!! I see what I can do with that ^^
I’ll let you know when I’ve reported back on all of that!! Thanks again
1 Like
Ok so that’s taken care of ^^ No more risk 
From now on there is a search on the title to guard against that:
If no issue is found then we go to the creation page which now integrates the local dps (dps locaux) and whose title contains the product_id and whether it’s a cloud management request (simpler) or local
If an issue already exists, we return directly to our discovery page, « Proposer ce périphérique » becomes unclickable and a small explanatory note appears, with direct forum access
And access to the filtered issues page
1 Like
Following additions/clarifications in response to your comments :
Documentation/UX (Tuya configuration page)
- Added the limit of 10 controllable devices (Tuya Cloud trial).
- Explanation about making devices “Controllable” in Tuya IoT Platform (button “Change”).
- Clarification that local mode does not disable control via the Tuya/Smart Life app.
- Mention of the current limitation for cameras: no video stream (alerts possible later).
“trial expired” message
- If the Tuya API returns an error containing trial/expired/subscription/resource pack, a more explicit message is displayed with a link to the Tuya platform.
Local mode: devices that “disappear”
- In local-only (cloud disconnected), the local scan now also shows devices already created in Gladys, which avoids the feeling of “disappearance” and allows the local update directly.
Added the ability to save a device with missing functionality. For example here an air conditioner with a binary to turn it on — this allows you to continue using it. We can propose implementing new functions. When we do it the button will switch to « Update ».
@GBoulvin image updated if you want to try again!
And so if you can recreate your 2 issues after having done a local poll please ! (it will give me more info ^^
3 Likes
When you get to it, it really works hard!
I tried pairing the second plug without using the app but have no idea how to do it. It doesn’t broadcast an AP (access point) and doesn’t appear over BT (Bluetooth), so I don’t see how to set its WiFi credentials.
I recreated the GitHub issues but it seems I can create several for the same device. I got this when clicking ‹ Suggest new features › for the plug:
And at the same time, I don’t really see which features to add… (apart from virtual devices for the 30-minute consumption calculation) Unless… the child lock, for example?
Anyway, one, but not fifteen! Well, maybe two, but not fifteen! Although…
To answer your earlier question, I didn’t have any specific message saying the trial had expired in Gladys (and I had to look in Tuya Cloud). Just ‹ Connected to Tuya Cloud account ›.
I confirm that the devices no longer disappear from the dashboard.
In the logs, I often see the following:
2026-02-22T18:12:30+0100 <warn> tuya.loadDeviceDetails.js:28 (TuyaHandler.loadDeviceDetails) [Tuya] Failed to load specifications for bf0e59548489fcb4ea62of: getaddrinfo EAI_AGAIN openapi.tuyaeu.com
<<<<<< !!! debug log is NOT enabled !!! >>>>>>
******debug flag is false *****
******debug flag is false *****
Indeed, you have to pair them mandatorily.
For my part I tested Pairing → Gladys registration → Test OK → Unpairing the app → Test KO => This confirms what I was reading on the Home Assistant (HA) forum. When you unpair, Tuya breaks the possibility of communication even locally and removes the id from the device!! Crazy. Now I’ll have to test whether it’s possible to continue communication if we just cut communication with the Tuya servers by blocking the route in the firewall!!
I think it’s related to some DP (data points) that I need to “hide”. For example, DP 11 is broadcast inside which is a ‹ countdown › that represents a timer if you ask your plug to switch off after a lapse of time. But it’s not a Gladys feature, so I don’t take it into account, but there are plenty of others.
Okay, thanks, we’ll see that in 6 months or on user feedback then ^^
No I’ll try to recreate an account, it should match
Meh… I just ran into the same with my AC ^^ The request is immensely long to create the issue with lots of functionality…
We found a solution with our friend AI: if the request returns an error, we close it, go back to Gladys and display a box to copy the data + a button to access an issue again but only with the title pre-filled:
I’ll update the image, I’ll let you know, but if possible you’ll need to recreate the requests — I’m sorry. At the limit, if you see it’s not good, don’t create them for the moment ^^ Since we’re testing… it will avoid polluting the issues ^^
And I just found the request we were missing to get the link between dps_id (local usage) vs the specific codes (cloud usage). So with that we should greatly simplify hardware integrations
1 Like
I found what was wrong: actually if you didn’t refresh the page, it didn’t redo the verification on the same instance. The button is now locked until a refresh or a page change (the goal being to avoid reaching GitHub’s allowed limit of 60 requests if someone clicked repeatedly).
In case of a post length issue for the issue, we now go back to the page, we can copy the logs to the clipboard, then click « Create an empty issue » which will contain only the title (allowing it to be formalized and therefore avoid creating duplicates) then paste directly into the description Easy and effective :
And the image updates, @GBoulvin, you can update it whenever you want!
1 Like
!! Attention !! Do not implement in the provided test image for the moment
And thanks to the issue data, almost-complete development by the AI in a short time with just a small prompt and a copy/paste of the issue for integrating the air conditioners (here Airton):
Full management locally or in the cloud.
I had to revise the folder/file configuration because it’s the first one so it put everything into 1 or 2 global files!! But going forward it should work almost in one go ^^
1 Like
Hello !
I tested the available image and re-did the proposals on GitHub.
Two questions come to mind :
-
What is the difference between the request (local) and (cloud)? Do I need to do both?
-
I repeatedly received the message saying that the issue existed when that wasn’t the case (well, it did, but I had closed it). Is there a filter to apply so the
1 Like
Hello @GBoulvin,
The cloud request contains only the cloud info. So I specify it in the title because the local issue will have additional info. This can be useful if someone can’t establish local communication with one of their devices; they can still manage them in the cloud.
But of course you should recommend making the request after doing the local polling, allowing everything to be integrated at once
Indeed, I purposely kept the search to include closed issues. If closed (besides, you also see them if you follow the link), it’s because there was either a negative response due to impossibility, or it’s integrated and the person has a Gladys that’s not up to date.
What do you think?
So, to be able to recreate it with the correct data, I went into the closed issue and removed the code between [brackets] in the title. So they no longer see it.
1 Like
Unless Tuya decides to add features gradually for the same device…
Edit:
So, the button will no longer be ‹ propose a device ›. But ‹ add additional features ›.
1 Like
