Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
12.17k stars 1.68k forks source link

[New device support]: Aqara Cube T1 Pro support request #15652

Closed dabrahim closed 1 year ago

dabrahim commented 1 year ago

Link

https://www.aqara.com/en/product/cube-t1-pro

Database entry

{"id":5,"type":"EndDevice","ieeeAddr":"0x54ef44100062e05a","nwkAddr":25105,"manufId":4447,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.remote.cagl02","epList":[1,2,3],"endpoints":{"1":{"profId":260,"epId":1,"devId":259,"inClusterList":[0,3,6],"outClusterList":[0,3],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}},"2":{"epId":2,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}},"3":{"epId":3,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":25,"stackVersion":2,"hwVersion":1,"dateCode":"20220602","swBuildId":"2019\u0000www.","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1671404743897,"defaultSendRequestWhen":"immediate"}

Comments

I tried creating a custom converter using the one already exisiting for the older model MFKZQ01LM but I was stuck at some point, I didn't know how to properly fill the fromZigbee array in.

External converter

const fz = {...require('zigbee-herdsman-converters/converters/fromZigbee'), legacy: require('zigbee-herdsman-converters/lib/legacy').fromZigbee};
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;

const definition = {
    zigbeeModel: ['lumi.remote.cagl02'],
    model: 'CTP-R01',
    vendor: 'Xiaomi'
    description: 'Aqara Cube T1 Pro',
    fromZigbee: [fz.xiaomi_basic],
    toZigbee: [], // Should be empty, unless device can be controlled (e.g. lights, switches).
    exposes: [e.battery(), e.battery_voltage(), e.angle('action_angle'), e.device_temperature(), e.power_outage_count(false), e.cube_side('action_from_side'), e.cube_side('action_side'), e.cube_side('action_to_side'), e.cube_side('side'), e.action(['shake', 'wakeup', 'fall', 'tap', 'slide', 'flip180', 'flip90', 'rotate_left', 'rotate_right'])],
};

module.exports = definition;

Supported color modes

No response

Color temperature range

No response

ybizeul commented 1 year ago

Is anyone experiencing lack of reporting anything when in action mode, and you pick up the cube and put it back on a face ? Tapping it or flipping it reacts well, but gently holding and putting it back down doesn’t do anything. I’ll try to use scene mode maybe

EDIT : indeed scene mode works perfectly for this use case

JJPro commented 1 year ago

@ybizeul that's normal: https://github.com/Koenkk/zigbee2mqtt/issues/15652#issuecomment-1373787896

ybizeul commented 1 year ago

Perfect explanation thank you !

dedeckerni commented 1 year ago

Testing with two of these cubes running the latest converter code, but I don't get consistent results. I'm new to zigbee/Z2M and not fully sure how to debug.

Observations/questions: Events/actions don't register consistently. Sometimes I'm trying the all the actions and they register fine, but then all of a sudden some actions start missing and I don't get any events. Scene mode seems more consistent: reports the side and hold action also works. A shake action also always works. But when in action mode it seems random: doesn't register rotate, slide or flip events. And then all of a sudden it does work.

While debugging in node red and in z2m log I also notice 4 events when doing one single action. sample outfput of my log:

info 2023-01-29 01:26:14: MQTT publish: topic 'zigbee2mqtt/AqaraCube_Nick', payload '{"action":"flip_to_side","action_angle":null,"action_from_side":null,"battery":100,"current":0,"device_temperature":25,"linkquality":255,"operation_mode":"scene_mode","power":1,"power_outage_count":10,"side":5,"update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null,"voltage":3082}' info 2023-01-29 01:26:14: MQTT publish: topic 'zigbee2mqtt/AqaraCube_Nick', payload '{"action":"","action_angle":null,"action_from_side":null,"battery":100,"current":0,"device_temperature":25,"linkquality":255,"operation_mode":"scene_mode","power":1,"power_outage_count":10,"side":5,"update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null,"voltage":3082}' info 2023-01-29 01:26:14: MQTT publish: topic 'zigbee2mqtt/AqaraCube_Nick/action', payload 'flip_to_side' info 2023-01-29 01:26:15: MQTT publish: topic 'zigbee2mqtt/AqaraCube_Nick', payload '{"action":"side_up","action_angle":null,"action_from_side":null,"battery":100,"current":0,"device_temperature":25,"linkquality":255,"operation_mode":"scene_mode","power":1,"power_outage_count":10,"side":5,"update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null,"voltage":3082}' info 2023-01-29 01:26:15: MQTT publish: topic 'zigbee2mqtt/AqaraCube_Nick', payload '{"action":"","action_angle":null,"action_from_side":null,"battery":100,"current":0,"device_temperature":25,"linkquality":255,"operation_mode":"scene_mode","power":1,"power_outage_count":10,"side":5,"update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null,"voltage":3082}' info 2023-01-29 01:26:15: MQTT publish: topic 'zigbee2mqtt/AqaraCube_Nick/action', payload 'side_up'

=> is that normal? I would expect just 1 event with all the payload because otherwise it's hard to define actions against it. When I installed the last version of the converter I also removed the devices and restarted Z2M. Am I missing something?

Link quality is good and testing this sitting close zo my sonoff zbdongle-e coördinator.

any ideas?

JJPro commented 1 year ago

@dedeckerni That's total normal behavior. z2m emits empty action when you have home assistant integration enabled. See here.

About flip_to_side, see this note.

Rhysgh commented 1 year ago

So close, yet so far.. any idea where i went wrong?

image

JJPro commented 1 year ago

@Rhysgh r u talking about Null values for battery stuff? Those info takes a long time to show. It's normal for battery powered devices. But you can make them show immediately by pressing on LINK, or give your cube a throw motion.

Rhysgh commented 1 year ago

Hi, yes, sorry, I'm terrible for lacking context.

I did try a throw, but I guess I didn't throw it right .. I see it's disabled here. Could that be the issue? i still have all null entries

image

OstfrieseUnterwegs commented 1 year ago

I would try to remove/unlink and add the device again - maybe even a couple of times.

Rhysgh commented 1 year ago

Ok tried deleign (forece reoved) , reatrted and readded .. i noticed the values where N/A and then changed to Null .. but are always Null nomatter what I try.. and the avalibility is still disabled.

filipeaparicio91 commented 1 year ago

@Rhysgh, when you perform an action on the cube, does Z2M produce any logs? You should be seeing a payload with the action show up when you rotate, flip, shake, etc. On HA and Z2M, the values show as Null or N/A for side, rotate, etc. because they are instant. If they show up in the Z2M logs, it means that the cube is functioning properly. To make automations, you can use MQTT as a trigger or condition, and just use the payload content instead of the device state. Example:

Trigger - MQTT Topic - "zigbee2mqtt/CUBE NAME/action" Condition - Template - {{ trigger.payload == "rotate_left" }}

This will trigger the automation when an action payload is detected by MQTT, and only perform it if the cube was rotated left.

The Availability showing up as "Disabled" is standard on Z2M. To change this you need to modify your Z2M configuration: https://www.zigbee2mqtt.io/guide/configuration/device-availability.html

EDIT:

If you want to enable availability, edit your configuration.yaml in the zigbee2mqtt folder and add this line: availability: true

Rhysgh commented 1 year ago

Thanks, I had a look. I see this.

Re availability, I had figured that was the issue. Do I need to set it to available? or is it ok as it is?

image

jzee923 commented 1 year ago

Make sure you're using the latest code (https://github.com/JJPro/CTP-R01-converter/blob/trunk/CTPR01.js) I was having this issue when the cube wasn't configuring properly. Might also be worth a shot trying the orange reconfigure button

filipeaparicio91 commented 1 year ago

@Rhysgh The availability feature doesn't affect the Cube's functionality - it simply reports if the device is online or not. Based on the logs, it looks like the converter was not properly set up. Did you include the file in your zigbee2mqtt configuration.yaml file? Also, have you restarted Z2M after adding the converter and editing the file?

Rhysgh commented 1 year ago

I used this file - https://github.com/JJPro/CTP-R01-converter image

This is my setup. Is that correct?

image

OstfrieseUnterwegs commented 1 year ago

@Rhysgh That looks correct. Also, Z2M seems to have recognized the device as it shows up in a details page (your earlier screenshot) Another guess: When you add the device to the network, did you limit the pairing to the coordinator? Sometimes it makes a difference if one adds new devices via a repaeter.

Rhysgh commented 1 year ago

@OstfrieseUnterwegs

No, I was permitted to join all, yea before adding the file ( I didn't know it wasn't supported), I got unsupported, but now I see it as you say.

its connected, and seeing it as in the sate I see what mode its in, and it changes when i click 5 times image

Rhysgh commented 1 year ago

I am on

Home Assistant 2023.2.0b7 Supervisor 2023.01.1 Operating System 9.5 Frontend 20230130.0 - latest

maybe that's an issue?

OstfrieseUnterwegs commented 1 year ago

I cannot help with the HASS environment. But if you have not done so far, try:

JJPro commented 1 year ago

Also check your battery, the first screenshot you posted has a linkquality of 42. That's probably too low. If distance to your coordinator isn't an issue, then it might be the battery.

JJPro commented 1 year ago

The pairing process will draw a lot of power.

JJPro commented 1 year ago

The minimum working linkquality from my experiment, just tested minutes ago, in my environment, is around 67.

Rhysgh commented 1 year ago

Ok, removed, restarted, join coordinator, re-added.

image

I have these logs

image

Do I need something in here? image

I think ill delete everything and start again.

Rhysgh commented 1 year ago

This may help you diagnose the issue.

image

JJPro commented 1 year ago

Hey @Rhysgh, telegram me if u still need help diagnosing the problem. We can set up a Zoom meeting. Besides helping you out, you can also help me make the converter better, because yours reported genOnOff cluster messages that I never come across, it's a good chance for me to dig more into it.

Let me know. Telegram: contact info deleted

amaisano commented 1 year ago

Ah shoot, already added. I just saw this pop up on the 2023.2 HA update log:

Sensor sensor.cube_action_angle has device class None, state class None and unit ° thus indicating it has a numeric value; however, it has the non-numeric value: None (<class 'str'>); Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mqtt%22
JJPro commented 1 year ago

@amaisano It's nothing about the converter. z2m emits empty action values when you have home assistant integration enabled. See here., and the empty value (null value) is interpreted as None by HA.

After looking at HA codebase, it's the newly introduced precision feature that puts stricter constraints on numerical values, that raised this warning. z2m may needs an update to cope with the new HA release. There's already an open issue about it. #16360

SirGoodenough commented 1 year ago

Has anyone noticed that the temp reported by this thing is always 25C? I even see it in the shared logs and cube data above from other users. Is it a code problem not reading the right variable?

It should currently be reading about 15c... Always 25.

    operation_mode: 'scene_mode',
    voltage: 3061,
    battery: 100,
    device_temperature: 25,
    power_outage_count: 17,
    current: 0,
    ...
oskarslusitis commented 1 year ago

yes, it's always 25°C for me as well.

JJPro commented 1 year ago

The device reports static temperature 25 °C, rendering device_temperature useless. So I have created a PR to remove it. Koenkk/zigbee-herdsman-converters#5446

SirGoodenough commented 1 year ago

The device reports static temperature 25 °C, rendering device_temperature useless. Koenkk/zigbee-herdsman-converters#5446

What a shame. I use that as a sensor on the old cubes...

Related / unrelated question. @JJPro ... The ZigPY version of the cube driver (used by ZHA) does not include the features you have found. Would you consider looking at that? I understand if you don't. Thought maybe your knowledge could give them a boost.

https://github.com/zigpy/zha-device-handlers/issues/2145#issue-1560726748

JJPro commented 1 year ago

@SirGoodenough Unfortunately, I'm not familiar with ZigPY, and don't have the time to learn a new system. However, feel free to ping me if you find someone who wants to work on it, I'd love to give him/her some hints and share knowledge about my implementation (specifically mode switch).

NicoQubo commented 1 year ago

Hi everyone,

The scene mode of the new cube is amazingly accurate indeed.

I wanted to ask if anyone else experiences the same (inconsistent) behaviour of the cube as I do:

  1. When placed on a surface it accurately displays the side_up:{"action":"side_up","linkquality":116,"operation_mode":"scene_mode","side":4}

  2. When rotated right or left - then sometimes the payload doesn't come trough and sometimes it does. {"action":"rotate_right","action_angle":11.7,"linkquality":105,"operation_mode":"scene_mode","side":4}

This second message/payload:

So, it feels a bit like 'rotating_left' and 'rotating_right' directly is not working as expected right now? In the ideal situation, you would like to choose a face up - like 'lights on' and use rotate_left/right to dim those lights directly. Or have consistent feedback when using the cube and rotating left or right.

Or maybe I'm missing something here? What are you guys thinking?

JJPro commented 1 year ago

Hi @NicoQubo, I see what you were trying to achieve. If I understand you correctly, you want to achieve "rotating on side change", e.g. turning on lights and dimming at the same time. Unfortunately, that won't work, side change and rotation can't be triggered in one go, because flip_to_side and rotate actions are reported from the same multistate cluster, and it reports one action at a time.

Always comes through, when placing the cube down and after waiting for a bit (like 3 seconds) and then rotating right or left.

That is the expected behavior. This is what happened during the operation sequence:

  1. You place down the cube and let go (OR wait for 3s like you did). (Side won't be reported unless you let go, otherwise it'll think you are still fiddling with it, and will wait until you let go to report the final up-facing side)
  2. multistate cluster reports flip_to_side event.
  3. aqaraOpple cluster reports side_up event.
  4. You rotate cube
  5. multistate cluster reports rotation event.

Hope this clears your confusion.

NicoQubo commented 1 year ago

Hi @JJPro,

Thanks for your insightful reply! There was something in what you said that triggered me. 'Place down the cube and let go.'

This sounds pretty obvious, but actually was the key for me!

I now also understand the inconsistency in 1. and 2., because I wasn't aware that my hand resting on the cube in between actions influenced the sensors! I probably sometimes 'let go' or 'rested hand on it' which obviously gave these weird reports. So: THANKS for that brilliant remark.

  1. Sometimes immediately comes through, when placing the cube down and directly rotating it left or right.
  2. Sometimes doesn't come through at all, when placing the cube down and directly rotating it left or right. After waiting for a bit and rotating again... it does come through.

In both these cases: I placed down the cube and probably sometimes removed my hand from it in advance of wanting to rotate. This is the key. REMOVE YOUR HANDS FROM THE CUBE :-)

I tried 'placing down, letting go and rotating' a dozen times now, and it works every time. In which case you can almost immediately rotate left or right!