Tuya and Smart Life alarm device eray T1

Configuration
1

Hi

I have tried to add my Eray T1 alarm to Tuya App and Smart Life App, both are working with the alarm.

What i want now, is to add the sensor to HA (atm. i’m using Smart-Life)
in my config i have:

# TUYA Alarm
tuya:
  username: !secret my_tuya_username
  password: !secret my_tuya_password
  country_code: 45
  platform: smart_life

I then restart HA, and can see that an Entity Tuya is installed and i’m logging into it, with the same username and password, as on my phone Smart Life App.
But no entityes is showed.

I know my IP and can ping it, to my Alarm on my network… but how can I add the alarm to the HA ?

2

You might want to try to add it via the localtuya integration. I have an alarm (tuya based) and I’m able to have a sensor on homeassistant with the alarm status and have my automations based on it.

https://github.com/rospogrigio/localtuya-homeassistant

3

Hi Paulo,
I have added the alarm system via local tuya. After adding this device from local tuya integration, it pops out a few IDs I can choose to add as entities. Only the first one I can understand - disalarm. Rest are mostly booleans values. How did you know which is which? Is there any documentation I can refer to? Thank heaps!

Edit: All good. I figured out. When you get device details from Tuya IOT platform, scroll down the debugging result and “code”:“value” is all displayed down there.

1 Like
4

I am trying to integrate a yunlink alarm, which appears identical to the eray T1. Could you please share some more detail about the entities/ID? Or Some more detail on how did you manage to figure them out?

EDIT It seems that when the Tuya Smart app retrieves the list of the RF sensors associated with the alarm, on HA the following log appears:

The “AQEAAAAAUABvAHIAdABhADE…” Stuff changes according to the state of the senors, e.g. the 6th character switches from A to Q when the door switch is open

Any idea on how to solicite this report and how to decode it?

Decrypted payload: {}
Decrypted payload: {"devId":"XXXXXXXXXX","dps":{"113":"AAU="},"t":1627405926}
Decrypted payload: {"devId":"XXXXXXXXXX","dps":{"113":"AQEAAAAAUABvAHIAdABhADE="},"t":1627405926}
Decrypted payload: {"devId":"XXXXXXXXXX","dps":{"113":"AQIAAQAAUABvAHIAdABhADI="},"t":1627405926}
Decrypted payload: {"devId":"XXXXXXXXXX","dps":{"113":"AQMAAAAAUABJAFIAMg=="},"t":1627405926}
Decrypted payload: {"devId":"XXXXXXXXXX","dps":{"113":"AQQAAAAAUABJAFIAMQ=="},"t":1627405926}
Decrypted payload: {"devId":"XXXXXXXXXX","dps":{"113":"AQUAAAAAUAB1AGwAcwBhAG4AdABl"},"t":1627405926}
1 Like
5

Did you ever figure this out. I am trying to do the same.

6

What type of device did you choose? I only get one device and one entity. Details of your config would be very helpful!

7

No, I skipped the TUYA alarm, and now I have a Ring Alarm System and IT’s working 100% using MQTT-Ring/Ring-MQTT :slight_smile:

8

Can’t say I blame you. Wish I would not have wasted money on Tukya. I have made some progress but they have been less than helpful.

9

I purchased a Staniot alarm system (Tuya SmartLife compatible). I did the cloud integration and now I can turn the alarm on/off via Home Assistant and Apple Homekit.
But I cannot see the Staniot door sensors in HA, and therefore I cannot create any kind of automations when, for instance, the front door is open (Stanior door sensor).

Should I modify the Staniot integration to localtuya, as of above? I’m a bit new to HA and doesn’t seem very easy.

Many thanks!

10

I also have a Staniot alarm system. I was able to add it with both Tuya Cloud and localtuya. With localtuya I could even add some automations based on alarm state, for example when armed I set my Reolink cameras to activate Human detection notifications; when disarmed I turn them off.

But I’m also looking into more advanced features like showing the current status of sensors. I started to play with tinytuya and was able to get sensor data successfully, but still need a lot of work to be done, for instance:

  • You have to poll the device to get sensor statuses, the alarm hub doesn’t send updates of individual sensor changes.
  • it sends all the data (current status open/closed, battery level, sensor name, etc) on a string encoded in base64. need to convert to hex and split in pieces to get each sensor data individually, and each sensor data point.
  • it sends data of at most 5 sensors per report, so if you have more than 5 you need to listen to multiple reports to get all of them.

I’m using this documentation as a reference.

I’m currently writing a custom module AlarmHostDevice for tinytuya which could even work with other Tuya based alarm systems, but I’m testing with the model I have (Staniot 7 inch Alarm system)

Beyond that, I have 2 main goals:

  • Create a compatible device that can be used in Home Assistant, probably using tuya-local integration, they already have a couple of Tuya alarm devices there with very basic functionality, which I can base from.
  • create a custom card (?) so I can display sensor status in a dashboard

But this is a bit beyond my knowledge, I am a developer but it’s the first time I try to do something custom for Home Assistant, and also the first time I’m using Python as a programming language. I trying to learn how I can do all that, this would be an interesting challenge to myself :sweat_smile:

1 Like
11

Ciao Fabiano,

Instead of collecting the data from the device it self, that seems to be a bit complicated, wouldn’it it be easier to capture the 433 mhz bandwidth with something like a broadlink? Theoretically when the sensor changes status, they should transmit some data in that frequency, and might be easier to capture it with a RM4 pro or something similar, so you can have the alarm that works standlone and the sensor that are read by the broadlink…
What you think?

12

Ah, that’s actually a great idea! I didn’t thought about it before… I’ve been struggling to get sensor status from the alarm host directly via Tuya protocol. the need to be constantly pooling the alarm host is not ideal, you don’t have a real time status of sensors this way. Capturing the signals directly from sensors would make more sense, indeed. I will certainly look into this. Thanks for the suggestion!