-
Notifications
You must be signed in to change notification settings - Fork 633
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
Comments
|
- default manual feed to 0 rather than letting it go unavailable - update product details - add raw attribute to Food empty for monitoring Issue #2947
Re-reading the doc string, the highest byte is the one with fault codes. Issue #2947
Hi, much appreciated for taking the time for improvemant!
maybe a cleanup of the yaml is needed too? |
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. |
ok, will try the force method, i keep you posted, maybe i try also 3.3 again, maybe the code was wrong before.... |
also question, i see this number entity, but actually only the 201 is important, its to feed ... why are all those other entities there?
|
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. |
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. |
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, tested the force: true on the "flip switch", it indeed creates a boolean now, but what happens: 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? also the indicator issue is now fixed!! edit; and also the 2 x select entities |
maybe indeed remove and add 202 and 205 as seperate? |
ok, maybe add 204 as a test entitie also, so next time a jam occurs , i can check what works? |
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? :-) |
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 |
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. |
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. |
This may mean that there are no values being sent for them. |
Or maybe cause the event didn't happen yet? I'm back on 3.2, ... Can't get it to work on 3.22 |
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?
|
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 when enabling the force, now it seems the "food weight" sensor also works, without the force on the other entities not!! But 1 problem, lets say i enable this one 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... |
ok, force to false again, hmm seems its destroyng the device, it goes offline :-( |
Like I said, so far It might be OK here on read-only sensors that can't get toggled. |
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 :-) |
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. |
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? |
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) |
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 EDIT: But the error didnt clear? i see online its cleared? |
Hey @make-all , I see you already merged the changes in a new release? Can you have a look on my last 2 replays? |
It seems the device just doesn't report the problem sensor when there are no problems, it does not explicitly report 0. Issue #2947
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. |
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? |
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. |
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 :-) |
Log message
Product ID
ibnk6keua0zzc2gr
Product Name
No response
DPS information
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
it should be:
When we use it, it displays a number, but then a few seconds later => unavaible
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?
thnx a lot for your help!!!
The text was updated successfully, but these errors were encountered: