Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request additional support for v330l_petfeeder #2947

Open
pergolafabio opened this issue Feb 13, 2025 · 35 comments
Open

Request additional support for v330l_petfeeder #2947

pergolafabio opened this issue Feb 13, 2025 · 35 comments
Labels
awaiting confirmation Wating for confirmation the issue is solved device improvement Improvement to an existing device config unreleased Will be in next release

Comments

@pergolafabio
Copy link
Contributor

Log message

2025-02-13 07:58:43.814 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 113 value from None to False
2025-02-13 07:58:43.814 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 113 value from None to False
2025-02-13 07:58:43.814 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.815 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.815 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.815 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.815 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.815 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.927 DEBUG (MainThread) [custom_components.tuya_local.device] Petfeeder received {"101": false, "full_poll": false}
2025-02-13 07:58:43.929 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 113 value from None to False
2025-02-13 07:58:43.929 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 113 value from None to False
2025-02-13 07:58:43.929 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.930 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.930 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.930 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.930 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False
2025-02-13 07:58:43.930 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Pet feeder: Mapped dps 206 value from None to False

Product ID

ibnk6keua0zzc2gr

Product Name

No response

DPS information

{
  "result": {
    "model": "{\"modelId\":\"000004ajdj\",\"services\":[{\"actions\":[],\"code\":\"\",\"description\":\"\",\"events\":[],\"name\":\"默认服务\",\"properties\":[
{\"abilityId\":101,\"accessMode\":\"rw\",\"code\":\"basic_indicator\",\"description\":\"设备指示灯是否打开,true打开,false关闭\",\"name\":\"指示灯\",\"typeSpec\":{\"type\":\"bool\"}},
{\"abilityId\":103,\"accessMode\":\"rw\",\"code\":\"basic_flip\",\"description\":\"true反转,false正常\",\"name\":\"录制画面翻转\",\"typeSpec\":{\"type\":\"bool\"}},
{\"abilityId\":104,\"accessMode\":\"rw\",\"code\":\"basic_osd\",\"description\":\"true打开水印,false关闭水印\",\"name\":\"视频osd功能\",\"typeSpec\":{\"type\":\"bool\"}},
{\"abilityId\":106,\"accessMode\":\"rw\",\"code\":\"motion_sensitivity\",\"description\":\"0-2,灵敏度依次增加;仅为灵敏度,0并不是关闭移动侦测报警;规定0为低灵敏度,1为中灵敏度,2为高灵敏度。\",\"name\":\"移动侦测报警灵敏度\",\"typeSpec\":{\"type\":\"enum\",\"range\":[\"0\",\"1\",\"2\"]}},
{\"abilityId\":108,\"accessMode\":\"rw\",\"code\":\"basic_nightvision\",\"description\":\"0:自动\\n1:关\\n2:开\",\"name\":\"红外夜视\",\"typeSpec\":{\"type\":\"enum\",\"range\":[\"0\",\"1\",\"2\"]}},
{\"abilityId\":113,\"accessMode\":\"rw\",\"code\":\"motion_record\",\"description\":\"true打开,false关闭\\n摄像头本地功能:功能打开的时候,只有检测到移动才开始录像。\",\"name\":\"移动侦测录像\",\"typeSpec\":{\"type\":\"bool\"}},
{\"abilityId\":115,\"accessMode\":\"ro\",\"code\":\"movement_detect_pic\",\"description\":\"该功能实现请参考SDK\\n---------------\\n{\\\"dp_id\\\",\\\"bucket;object;key\\\"}/{\\\"dp_id\\\",\\\"bucket;object;\\\"}\\n\\nbucket:根文件夹;objcet:文件路径;key:加密\",\"name\":\"检测到移动\",\"typeSpec\":{\"type\":\"raw\",\"maxlen\":128}},
{\"abilityId\":134,\"accessMode\":\"rw\",\"code\":\"motion_switch\",\"description\":\"\",\"name\":\"移动侦测\",\"typeSpec\":{\"type\":\"bool\"}},
{\"abilityId\":201,\"accessMode\":\"rw\",\"code\":\"feed_num\",\"description\":\"返回错误码:\\n0 :投食失败\\n\\n//正数为投食的数量,若下发的投食3分,都投成功了,则返回3,APP则显示投食成功。\\n\",\"name\":\"喂食机-投食\",\"typeSpec\":{\"type\":\"value\",\"max\":20,\"min\":-2000,\"scale\":0,\"step\":1,\"unit\":\"份\"}},
{\"abilityId\":202,\"accessMode\":\"ro\",\"code\":\"food_weight\",\"description\":\"每份食物的重量,单位g \",\"name\":\"每份食物克重\",\"typeSpec\":{\"type\":\"value\",\"max\":100,\"min\":1,\"scale\":1,\"step\":1,\"unit\":\"g\"}},
{\"abilityId\":203,\"accessMode\":\"rw\",\"code\":\"control\",\"description\":\"控制类命令,执行结束后返回历史数据\",\"name\":\"控制命令\",\"typeSpec\":{\"type\":\"value\",\"max\":2147483646,\"min\":0,\"scale\":0,\"step\":1,\"unit\":\"\"}},
{\"abilityId\":204,\"accessMode\":\"ro\",\"code\":\"realtime_data\",\"description\":\"设备实时状态数据,按时上报到服务器。包括设备出错类型,出粮份数等\",\"name\":\"设备状态\",\"typeSpec\":{\"type\":\"value\",\"max\":2147483647,\"min\":0,\"scale\":0,\"step\":1,\"unit\":\"\"}},
{\"abilityId\":205,\"accessMode\":\"rw\",\"code\":\"weight\",\"description\":\"百位数为是否使能远程控制出粮,个位十位数为自动出粮分数\",\"name\":\"自动出粮份数\",\"typeSpec\":{\"type\":\"value\",\"max\":255,\"min\":1,\"scale\":0,\"step\":1,\"unit\":\"\"}},
{\"abilityId\":206,\"accessMode\":\"ro\",\"code\":\"history_data\",\"description\":\"设备执行完成后上报历史数据,上报历史数据时,value由4个字节拼接而成,最高位字节表示错误码(1:无粮  2:食物不足   3:粮食堵塞);次高位字节百位表示出粮类型(2:Alex  1:手动   0:自动);第三字节表示实际出粮份数;最后一字节表示上报ID,每次上报后加1。\\nresult = ((uint32)devState.errType<<24|(uint32)foodCount<<16|(uint32)rebackCount<<8|(uint32)sendID);\\n\",\"name\":\"上报历史数据\",\"typeSpec\":{\"type\":\"value\",\"max\":2147483645,\"min\":0,\"scale\":1,\"step\":1,\"unit\":\"\"}},
{\"abilityId\":207,\"accessMode\":\"rw\",\"code\":\"schedule\",\"description\":\"面板将一个单任务用15个字节表示,然后转为string类型下发给设备端。前9位为有效位,后6位000000。\\n注意:设备端收到指令后先转换格式,byte2~byte8转为十进制整型数,byte0~byte1按照十六进制处理。\\n1. bit0 ~ bit6 代表周日到周六,某bit为1表示当天有效。\\n2. 全为0表示仅限一次。\\n\",\"name\":\"定时\",\"typeSpec\":{\"type\":\"string\",\"maxlen\":255}},
{\"abilityId\":208,\"accessMode\":\"rw\",\"code\":\"feed_voice_record\",\"description\":\"目前只需设置数值0(正常状态)、1(开始录音) 2 录音异常触发Toast弹框,APP下发“1”表示设备进入录音模式,下发“0”标示停止录音,设备上报“1”设备正在录音,上报“0”标示录音停止,上报“-1”表示录音异常\",\"name\":\"喂食录音\",\"typeSpec\":{\"type\":\"enum\",\"range\":[\"0\",\"1\",\"2\"]}}]}]}"

Information about how the device functions

Hi, the v330 is already part of the intergration, but a few things are not correct/working, can you help me with this one?
https://github.com/make-all/tuya-local/blob/main/custom_components/tuya_local/devices/v330l_petfeeder.yaml

  1. Can you changee the exact model?
  - id: ibnk6keua0zzc2gr
    model: V330

it should be:

  - id: ibnk6keua0zzc2gr
    model: V330L_AF3V_223A
  1. The manual feed number entity works, but the entity always becomes back unavaible afterwards, can that be fixed? shouldnt it poll for last state?
    When we use it, it displays a number, but then a few seconds later => unavaible

Image

  1. why are some switches look like on/off buttons, while others are like thunder icons?
    They do work, but the state only updates when we change from tuya app? its always back to default after restart HA? is that normal? Maybe bcause the device doesnt send updates?
    The "indicator" button is a strange one, when we turn it on, it actually turns off afterwards, also on tuya app? i dont see that behaviour when using thee cloud integration?

Image

  1. the diagnostics entities, i never see them working, they are always on "OK" , maybe the code is wrong? its DP 206 , they are bitfields? see description above? maybe the code is wrong?

Image

  1. dp 115 is camera snapshot, but i dont see any camera entity at all?

thnx a lot for your help!!!

Image

@pergolafabio pergolafabio added the new device Unsupported device label Feb 13, 2025
@make-all make-all added device improvement Improvement to an existing device config and removed new device Unsupported device labels Feb 13, 2025
@make-all
Copy link
Owner

  1. I don't know what card that is. At first I thought that it must be the default behaviour of the entities card, as all the entities that are displayed as toggle switches are not switch entities, but other entity types that have an on/off toggle. But on my installation, switch entities are also displayed as toggle switches, so maybe you are using a different card?
  2. I will add a "raw" attribute on the Food empty sensor, so you can see actual values received before decoding/masking.
  3. I think the dp 115 is not returning an image? It is attached as an attribute on the record switch so you can see it's value, and decode using an online base64 decoder to see the contents (which I think is a json object containing a relative url link to the actual image, on some unknown tuya cloud server, as one of the contents).

make-all added a commit that referenced this issue Feb 13, 2025
- default manual feed to 0 rather than letting it go unavailable
- update product details
- add raw attribute to Food empty for monitoring

Issue #2947
make-all added a commit that referenced this issue Feb 13, 2025
Re-reading the doc string, the highest byte is the one with fault codes.

Issue #2947
@pergolafabio
Copy link
Contributor Author

Hi, much appreciated for taking the time for improvemant!

  1. its not a card i use, ite a screenshot from the device itseelf in the local tuya integration, my guess they are thunder icons, because they have an unkown state , see screen below

Image

  1. ok, will test that soon!

  2. is there a way to debug tha json maybe? ot do you think its not possible to download snapshot? otherwhise dont spend time for this one

maybe a cleanup of the yaml is needed too?

@pergolafabio
Copy link
Contributor Author

for example the flip, at restart HA its unknown :

Image

when i change in tuya app, it does have a state:

Image

and the thunder icon changes to a boolean switch

Image

is it needed for this integration to poll the state on restart HA?

@make-all
Copy link
Owner

make-all commented Feb 13, 2025

The integration polls all the status every 30s. You can try adding "force: true" to some of the optional dps to use the 3.2 style of polling instead of 3.1 and 3.3+, but it generally only works for power/voltage/current sensors on smartplugs, and causes some devices that do not handle it to crash.

@pergolafabio
Copy link
Contributor Author

ok, will try the force method, i keep you posted, maybe i try also 3.3 again, maybe the code was wrong before....
keep you posted

@pergolafabio
Copy link
Contributor Author

also question, i see this number entity, but actually only the 201 is important, its to feed ... why are all those other entities there?
Those are not visible?

entities:
  - entity: number
    name: Manual feed
    icon: "mdi:food-drumstick"
    dps:
      - id: 201
        type: integer
        name: value
        unit: portions
        optional: true
        persist: false
        range:
          min: 0
          max: 10
        mapping:
          - dps_val: null
            value: 0
            hidden: true
      - id: 202
        type: integer
        name: food_weight
        optional: true
        mapping:
          - scale: 10
      - id: 203
        type: integer
        name: control
        optional: true
      - id: 204
        type: integer
        name: realtime_data
        optional: true
      - id: 205
        type: integer
        name: weight
        optional: true
      - id: 207
        type: string
        name: schedule
        optional: true
      - id: 208
        type: string
        name: voice_record
        optional: true

@make-all
Copy link
Owner

They are attributes, not entities. They either were too complex to make sense of, or not important enough to make into full entities. Since the manual feed is the "main" entity for this device, it becomes a dumping ground for the extra attributes that need an entity to attach to.

@make-all
Copy link
Owner

202 and 205 look like they might be useful to separate into their own entities, but I can't remember the history for this, maybe they are not returning useful info.

@make-all
Copy link
Owner

204 might be a better option than 206 for the fault sensors, but it was not documented in as much detail (I suspect the history_data though is a series of realtime_data - maybe the 206 has to be explicitly requested then runs through the last 10 or something)

@pergolafabio
Copy link
Contributor Author

pergolafabio commented Feb 13, 2025

ok, tested the force: true on the "flip switch", it indeed creates a boolean now, but what happens:
i turn it on:

Image

i restart HA, after restart HA is finished, thee flip is OFF again (on tuya) i think , its back an thunder icon, and aftre 30 seeconds it changes to boolen with OFF state, my guess it sends an OFF state to the devicee? that should not happen, right?
Above tested wirth 3.2
i changed to 3.3 , did a restart, now it seems better, it keeps the state !!

also the indicator issue is now fixed!!
so adding force: true to all swirch + light entities are fixed

edit; and also the 2 x select entities

@pergolafabio
Copy link
Contributor Author

202 and 205 look like they might be useful to separate into their own entities, but I can't remember the history for this, maybe they are not returning useful info.

maybe indeed remove and add 202 and 205 as seperate?

@pergolafabio
Copy link
Contributor Author

204 might be a better option than 206 for the fault sensors, but it was not documented in as much detail (I suspect the history_data though is a series of realtime_data - maybe the 206 has to be explicitly requested then runs through the last 10 or something)

ok, maybe add 204 as a test entitie also, so next time a jam occurs , i can check what works?

@pergolafabio
Copy link
Contributor Author

hmm, maybe back to 3.2 ... seems 3.3 makes all entities unavaible again for some reason after some time.... that was the issue before too

Image

@pergolafabio
Copy link
Contributor Author

3.2 gives back issues to the status indicator and doesnt poll the state ... hmm gonna try maybe 3.4 or 3.5 , how do i know what protocol i need to usee? :-)

@pergolafabio
Copy link
Contributor Author

ok, testing some more, wth 3.3 again, and force to false on all light/switch/select, i think this is more stable it seems

@make-all
Copy link
Owner

It could be that 3.22 is appropriate for this device if it is partially working in 3.3, and partially working in 3.2.

@make-all
Copy link
Owner

DP 204 is one of the attributes under Manual feed. If you can confirm that 202 and 205 are returning useful data, I will add the entities for these.

@pergolafabio
Copy link
Contributor Author

hmm, testing 3.22 after restart, all entities are unavaible
ok, gonna stick with 3.3 for now with force: false again

gonna test this, if all is stable

for the attributes 204,202,205 , where can i see the date for those, they aree attribute on the number entity, but i dont se it here ?

Image

@make-all
Copy link
Owner

This may mean that there are no values being sent for them.

@pergolafabio
Copy link
Contributor Author

Or maybe cause the event didn't happen yet? I'm back on 3.2, ... Can't get it to work on 3.22

@pergolafabio
Copy link
Contributor Author

for now , i added those 202,204,205 as seperate entities below, thats easier to troubleshoot, since attributes dont show up in the logbook... is it ok like below for thos specific DP according to the description of those?

  - entity: sensor
    name: Food weight
    class: problem
    category: diagnostic
    dps:
      - id: 202
        type: integer
        name: sensor
        optional: true
  - entity: sensor
    name: realtime data
    class: problem
    category: diagnostic
    dps:
      - id: 204
        type: integer
        name: sensor
        optional: true
  - entity: sensor
    name: Weight
    class: problem
    category: diagnostic
    dps:
      - id: 205
        type: integer
        name: sensor
        optional: true

Image

@pergolafabio
Copy link
Contributor Author

pergolafabio commented Feb 13, 2025

ok, did some testing, i enabled on those 7 entities below the force: true, after restart, they all have a state... so far so good

Image

when enabling the force, now it seems the "food weight" sensor also works, without the force on the other entities not!!

Image

But 1 problem, lets say i enable this one

Image

i see the camera flipped, thats good, i restart HA ,and seems the camera is back to its default, so a restart of the integration seems is sending a command that should not do? same bevaviour on the other entities too...
EDIT: seems after 30 sec again, the flip is back ON again...
so doing a reboot is sending an instruction and 30 sec later again :-)
when i remove the force command, after restart the device stays like it was

@pergolafabio
Copy link
Contributor Author

ok, force to false again, hmm seems its destroyng the device, it goes offline :-(

@make-all
Copy link
Owner

Like I said, so far force: true has only been found to be suitable for power/voltage/current readings on some smartplugs.

It might be OK here on read-only sensors that can't get toggled.

@pergolafabio
Copy link
Contributor Author

Yeah, i removed it, and used it indeed in the "food weight" sensor to test, but that one doesnt update anymore, not sure why, I will keep en eye on it in next days... The most important sensor, is the event where the food is stuck.. need to wait some time for it :-)

@make-all make-all added the awaiting feedback Needs more information label Feb 14, 2025
@make-all make-all moved this to 🏗 Stalled in Tuya Local Feb 14, 2025
@make-all
Copy link
Owner

Once you are done testing out improvements, please summarise here. The above has become quite long and difficult to follow what is actually a worthwhile change to make.

@pergolafabio
Copy link
Contributor Author

Ok, will do that, just the last point about the cameras/snapshot, can that work? How can I debug that, you told me about some json data and an URL?

@make-all
Copy link
Owner

make-all commented Feb 14, 2025

If you look at the details for the Record switch after triggering a camera event, you should see a "snapshot" attribute that contains the contents of what is sent.

I expect the result will be the same as #2105 (comment)

@pergolafabio
Copy link
Contributor Author

pergolafabio commented Feb 14, 2025

ok, did some testing with debug on

  1. for the camera, i indeed see the same, also a base64 , like in that comment, probably its a snapshot stored somewhere, maybe in cloud or on the device, but probably we cant retrieve it?

2025-02-14 10:37:39.800 DEBUG (MainThread) [custom_components.tuya_local.device] Pet feeder received {"115": "eyJ2IjoiMy4wIiwiYnVja2V0IjoidHktZXUtc3RvcmFnZTMwLXBpYyIsImZpbGVzIjpbWyIvMjE5MTE1LTU5MjE1OTAtZ3pqazk0ZTU3MTU5YzQ2MDdjZDIvZGV0ZWN0LzE3Mzk1MjU4NTcuanBlZyIsIjE3ZGJmNWQxOGRkODMzNTciXV19", "full_poll": false}

  1. its very strange, but i test for example the "flip" or "indicator" , it turns itself off after a HA reboot and also on the device itself, with force: true , it turns it off after 30 sec... so its very unreliable , i dont see the command shooting at the device in the debug... maybe its the device itself, not sure why

  2. as seen in screenshots, those 7 switch/light/list entities, we talked about it before, but without "force: true" , afer a restart HA , they dont have the correct state, they are always "OFF", somehow force: true is needed... ?

  3. No sure why, but below entity "food_weight" , i ONLY see it working when i have enabled force: true on ALL those 7 entities , then i see a value coming there like "10 grams"
    i added a seperate food sensor (DP 202)
    Image
    But that takes me to the next problem, if i enable force: true on all devices, the device itself is constantly dropping of the nerwork, i left a ping running, and i see below in th debug

2025-02-14 09:52:05.093 DEBUG (MainThread) [custom_components.tuya_local.device] Retrying after exception <class 'AttributeError'> Unexpected Payload from Device (0/3)
2025-02-14 09:52:05.286 DEBUG (MainThread) [custom_components.tuya_local.device] Retrying after exception <class 'AttributeError'> Network Error: Unable to Connect (1/3)
2025-02-14 09:52:05.290 DEBUG (MainThread) [custom_components.tuya_local.device] Retrying after exception <class 'AttributeError'> Network Error: Unable to Connect (2/3)
2025-02-14 09:52:05.290 ERROR (MainThread) [custom_components.tuya_local.device] Failed to update device dps for Pet feeder
2025-02-14 09:52:10.292 DEBUG (MainThread) [custom_components.tuya_local.device] Pet feeder persistant connection set to False

whats strange, if i disable the force: true on the 2 list entities (nightvision/motion sensitivity) , then the device is reliable, no drop, but then for some reason, the food_weight doesnt work anymore???? no idea why ...
Is the drop off because of to many force connections? maybe, but why do i need to have force: enabled on those 7 entities to have my food_weight sensor working... are the 2 list entities wrong configured? allthough they do work, and with force; true they get the correct state...

all was tested on 3.2 , i tested others, but they dont work good, key error, json error ....

very strange behaviour ... not sure if there is a solution to one of the problems :-)

Image

@pergolafabio
Copy link
Contributor Author

pergolafabio commented Feb 14, 2025

as for the "history_data" & "realtime_data" , whats the best approach to have the 3 below working, i still need to wait until that event occurs, you changed those bitfield values already, but i was not able to test those yet
i wll have a look on the IOT cloud website what DP 204 or 206 is the best way ... "history_data" & "realtime_data"

Image

EDIT:
ok, the petfeeder was blocked, i saw the entity now going to: blocked state! thats good

Image

But the error didnt clear? i see online its cleared?

Image

Image

@pergolafabio
Copy link
Contributor Author

Hey @make-all , I see you already merged the changes in a new release? Can you have a look on my last 2 replays?

make-all added a commit that referenced this issue Feb 22, 2025
It seems the device just doesn't report the problem sensor when there are
no problems, it does not explicitly report 0.

Issue #2947
@make-all
Copy link
Owner

There isn't much that can be done here. The problems persisting after they cleared in the cloud can probably be fixed by the above change, but the root cause of all this misbehaviour is that the device is simply not telling what its state is over the local protocol.

@pergolafabio
Copy link
Contributor Author

ok, let me tru that persist, if that works , its already a huge improvemant for the device, thnx already

regarding point 2... 4 replys above , that is changes back after 30 sec for the light/switch entities, any idea?
Even if for example i turn on the indicator light, it this component switches it back ?

@make-all
Copy link
Owner

This is because the state never comes back from the device. In order to make the HA UI responsive even when the device itself is laggy, the integration optimistically fakes state changes that it has requested. But since the device may legitimately not have made that requested change, the fake state is expired after 30s, or on receiving a status update from the device, whichever comes first.

@pergolafabio
Copy link
Contributor Author

Ah ok, nothing todo then.. ok, np..! :+)

I give you an update about the persist you added, hopefully that works, the block sensor is very useful :-)

@make-all make-all added awaiting confirmation Wating for confirmation the issue is solved unreleased Will be in next release and removed awaiting feedback Needs more information labels Feb 22, 2025
@make-all make-all moved this from 🏗 Stalled to ✅ Done in Tuya Local Feb 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting confirmation Wating for confirmation the issue is solved device improvement Improvement to an existing device config unreleased Will be in next release
Projects
Status: ✅ Done
Development

No branches or pull requests

2 participants