You’ll have to enter the API access ID as well, Robin (at the red arrow).
It says “Official API Access ID”
You only entered the API access secret there…
Did you mids the example screen maybe?
1 Like
Thanx. I have entered the ID correct now. But now i got the 1106 permission deny. App is linked in Tuya developer, Smartlife password checked (linked gmail account)
UPDATE: Changed the Smartlife password. Now its al working.
2 Likes
I have this working, which is great. It shows all the tp-link plugs. I have just added a whole bunch of wifi tuya contact sensors. They are working in the tuya app, and I can see them in the tuya developer platform, but they do not appear to be showing up in homey pro. I have tried restarting the tuya cloud app in homey pro, but that doesn’t seem to work.
I also added some new plugs and they are not appearing either. How do I get the app to refresh and add the new devices to homey pro?
Do you choose to add a new Tuya Cloud device in Homey?
Otherwise try restarting your Homey
They don’t appear by themselves, you have to add them by adding a new device like Rudi wrote, one by one.
When there’s no device match, no problem, but you’ll have to use a little workaround → In post # 1, search for tap-to-run (to control devices) and RAW Commands (to control Tuya devices and to let Tuya devices control Homey (devices)) / receive any value).
Peter & Rudi,
Firstly thanks for the swift responses and I feel a little silly not having tried to add a device. I was able to add all the plugs fine.
The window sensors were not added. I have been playing around with Raw commands and execute a scene methods. I need to work out what i really want and do some testing first by looks of it.
But just wanted to say thanks as well.
1 Like
You are most welcome. Don’t feel bad. Speaking for myself: I know this, because I made the exact same mistake.
Just feel bad if this happens multiple times 
Peter is the king of RAW commands. I haven’t seen the need to use those yet.
1 Like
[EDITED]
I am trying to get the contact devices to be devices in homey.
That way, if they are opened or closed I am can do something with it.
After some testing, I don’t think I use the tap to run scenes because:
a) They are not mains powered, they are all battery powered
b) I just want the sensor change, and to create as a tap to run scene, I cannot configure the tuya app to just send a notification, it has to do something or run another automation, and running another automation wont work because the automation will only kick in when the sensor contact changes, unless the tap to run, runs indefinitely? Either way, I suspect approach a) is what is ruling this approach out and why it isn’t working for me.
I tried to follow the raw commands approach but to me there seems to be something missing. I can get homey to listen for an event in the flow, but I don’t understand how I can get the variables DeviceID, ‘Function name’ and ‘Function value’ to show actual values that are from the tuya cloud app that trigerred the flow i nthe first place. I just get notified with the default values for the homey variables and that is it. I see no mapping logic for this to happen?
Any ideas? @Peter_Kawa
It"s correct you cannot ‘listen’ to sensors, or anything sending values & commands TO Homey, with tap-to-run scenes.
Those can be used to control Tuya devices (or anything you can program with tap-to-run’s).
Just in case, you did find this howto below?
If yes, what’s the first thing you expect but doesn’t work?
You have to create logic text compare cards
The tags used, are provided by the RAW Commands triggercards:
When you build and enable this flow, it should “spam” you with messages containing the device ID, the function name, and the function value.
Save all the data for later use.
Now you know which device sends which values for certain functions, so you can filter the trigger events to have Homey start things you programmed:
Hi @Peter_Kawa ,
Thanks for replying. I did go through the raw commands section. I am going to list what I did to help validate with what you propose in the screenshots.
For the first image, created the tuya cloud text event received card, and connected it to a timeline notifiication card.
I created three variables (device id, functionanname, functionvalue) and their default values are the same as the variable name.
I do get homey flooding me with timeline notifications but they all literally say:
“A notifiction:
Device ID: DeviceID
Function: Functionname
Value: Functionvalue”
I understand the second image that tells me that if the deviceid is equal to X then you can do Y.
The problem is the variable @deviceid is not recording the deviceid for the logic to even work. The device id is always the default value of the variable deviceid.
So, if my garage door is opened, and my garage door has a deviceid of “mygaragedoor123” - i assume that based on your first screenshot, the listerner should be recording the deviceid of “mygaragedoor123” into the value for the variable @deviceid - but it is not - the default value remains.
No! Where did you read you’ll have to create variables? 
Just follow instructions, please, sorry
It shows you aren’t familiar yet with a very important part of Homey: tags
Tags are read-only variables provided by apps and flowcards
The tags you see in the notification card of my xmpl flow are so called “Flow tags” which appear on top of all other tags and variables when you’d like to select them for adding.
They are provided by the Tuya “[event type] event received” trigger card.
They become visible by hovering the tag symbol of the trigger card;
Screenvid (hit the 
on the bottom-right):
In advanced flow, always connect the flow cards prior to selecting tags
I hope you now do succeed in receiving messages per timeline notification cards!
I was trying to follow instructions 
And no - you didn’t say anything about variable sbut the screenshot looked like variables!
I wasn’t aware and even when I was looking i nthe tags for the timeline i didn’t spot the variables/tags that were under the section “This Flow”.
I guess that is what happens when tuya spoil things and you get non-techie people trying to do techie things…
Anyway, thank you for enlightening me on this, I absolutely wasn’t aware of the tags and opens up a whole new dimension for me.
I have updated and can confirm i am now getting proper values.
Thank you once again - genuinely appreciate the time and patience.
1 Like
Glad I could help out.
I agree they should show variables and tags with their own layout!
I took me a long time until I finally understood the difference between variables and tags.
Despite getting this working, it does appear (or not as the case may be) that battery devices are not sending data that can be listened to, and therefore I cannot get the door/window sensors event data.
I may have to look at getting tuya local working to solve the problem - although it looks like that suggests mains powered as well.
I guess I am back to square one.
I have some sensors which only report high, mid or low battery levels. Literally with these words as text.
If you were expecting numbers, try using the “text event received” card.
When you open your developer project @ Tuya Smart Developer Center
and go to the Devices tab, you can view values a device could send.
Hi @Peter_Kawa
OK, so I have found an alternative method for battery devices until Tuya official is available. It’s not pretty though.
Tuya app is linked to Amazon Alexa. I see all Window/Door Sensors in Alexa.
I create a virtual device in Homey Pro and relink Homey Pro in Alexa so I can see the virtual device. The virtual device cannot be a window sensor as it won’t appear in Alexa. It can be a light or a plug though.
I then create a routine so that when the actual window/door sensor is activated, it turns the virtual device on. The virtual device state is then changed in homey as a result of the homey/alexa integration. This means I now have the states i need for the battery sensors in homey.
I have two routines in alexa, one for sensor activated/open, and one routine for sensor ‘closed’.
The response time between alexa and homey is quick. Quicker than the actual sensor notifying tuya.
Its not pretty but a workaround for now.
I will eave it at that for this topic thread, and again just want to say thanks again for helping guide me through how to use your app.
2 Likes
Thanks so much.
From what I’ve read, and seeing opinions of both Athom founders (@ Youtube), I don’t believe there will be an ‘official’ app soon™ 
Hi,
Suddenly my devices stopped responding in Homey, tried to repair one and was popped up to the redirect login page from openapi.tuyaeu.com where when I try to login it says my accounts is not found. However I’m logged into the developer platform just fine with that login and see all my devices online there. In the tuya app op my phone I see it’s linked aswel.
I double checked all my details and everything is correct.
What could be wrong?
EDIT/ Sorry just saw the official app notification in the app store. I’m no new user though but assume this is the issue. Apologies.
No, this is the community app. This one should still work
This morning I received the following message. Most likely it will not affect the official app, but it will perhaps affect this community app that a lot of people are still using. If that becomes unusable because of this measure, it will increase the importance of an official app.
Dear Developers,
Hello! We’ve noticed that during the firmware development process, some developers have set up an unreasonable message reporting logic, resulting in an excessive amount of data. This not only increases device power consumption and affects the stability of device control, but also leads to an increase in consumer complaints and after - sales costs.
To optimize the message reporting mechanism and ensure service stability, we issued an announcement regarding the limitation of message reporting data volume in July 2024. According to the original plan, starting from August 5, 2024, we would stop the free policy for message reporting data exceeding the daily limit. However, considering that some developers may not have fully noticed this change, we have decided to provide a certain transition period.
After careful consideration, we have decided to postpone the implementation time of this policy adjustment to January 1, 2025. That is, for products newly created after this time point and the corresponding newly ordered and authorized devices, if the number of message reports exceeds the daily limit, they will no longer enjoy free services. If developers have special business - scenario requirements, they can purchase additional message reporting volume as needed. Products created and devices authorized before this date will not be affected.
We sincerely hope that developers can make use of this transition period to reasonably optimize the message reporting logic and jointly improve the user experience.
Please check the updated announcement and detailed rules in a timely manner to make corresponding adjustments. Thank you for your understanding and support. For details, please visit the developer documentation:https://developer.tuya.com/en/docs/iot/message-reporting-total?id=Kbuemg6s7vkej
Thank you again for your support of Tuya Smart. We will continue to provide you with better services.
Tuya Developer Platform Team
