-
Notifications
You must be signed in to change notification settings - Fork 518
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
Parkside PMRDA 20-Li A1 reports wrong (or not exhaustive) statuses and incorrect problems #1983
Comments
Lawn Mower Activity only has the four possible values currently implemented. The vacuum entity is for backwards compatibility, as the lawn_mower platform is relatively new (introduced in HA 2023.9, and added to tuya-local in 2024.1.0), so users originally used these devices as vacuums, and the deprecated entity is kept around for some time to allow existing users time to adjust to the new lawn_mower platform. |
Although this seems to have some non-problematic statuses, it is reportedly stuck on "Tilted", which may be because it is no longer being sent, and that was the last value. Treat it as non-persistent, with a default value of OK, to clear non-current problems if that is the case. Issue #1983
I have focused on the "MOWER_LEAN is reported all the time" for now, as that is possibly a resolvable issue. If the device is only reporting this when there is a problem, and otherwise just not reporting anything, it would have become stuck on the last received value. So I have changed the config to mark it as non-persistent, and optional, with a default of "OK" for the case where nothing is received. |
Well, some curious things are happening here. The OK is appeared, but actually the "device still reports" MOWER_LEAN for 103. (it always reports this, independently what is the current / was the last error / or is there any. Everytime is leaning time.. :D)
|
@cociweb did you figured out if/where/how to get notifications from the lawnmower from the rain and "lift" sensors? Is it DPID 6 that provides these values? |
not yet dpid6 is the battery |
@make-all what can we do to help make this possible? |
um, I'm afraid, it's not really resolved. |
It isn't clear what problem still remains. As explained earlier, most of the "issues" in your original report are not issues at all. If your device is always reporting MOWER_LEAN, then that is an issue with the device. The change included in the previous release was to cover the possibility that it reports nothing when all is OK, but other users have not reported such an issue. |
It's related with 2. point: then maybe some more feedback is required from other users. I would not state it explicitly, since everywhere (here in this github repo and even in HA's forum) MOWER_LEAN is reported for 103, but nobody identified it as a problem. (there is no report with missing/empty/null or ANY other values) - so maybe there is something behind the scenes, but let's wait for further feedbacks in the discussion of the lawnmower's topic! Anyways, thank's in advance! |
@rufik, thank you for highlighting this issue! In the meantime we can reopen the ticket - What do you think? |
I don't think it is appropriate to reopen the ticket for a problem with the device itself. |
I'll try to enable debug for |
I think most likely you are going to have to ignore the "Tilted" state in any automations. The original Moebot S seems to treat this correctly, only the Parkside seems to use MOWER_LEAN as a default "OK" state (or is missing the sensor and giving false reports about it all the time). |
Unfortunetly it looks like DPS 103 (problem sensor) always acts as I wrote - gives us true message for a very short period then changing to kinda "default" state It doesn't look useful for me, time-based patterns are useless for automations/templating as they often bringing race condition problems...maybe DP 103 is misbehaving? Maybe it's just for notification only? And one more thing - I can see some missing mapping for
|
Hmmm, take a close into device abilities (20-Li B2 for me), DPS 101-103:
DPS 101 is device state (enum). |
ok, I've played a little with the device. it seems, that the problems are reported correctly for less than 1 sec (even if it is really "Tilted" aka lifted). However, every state change of the problem sensor is followed by a new value as "Tilted" state. @rufik Dpid 6 is the battery. but it maps only for the 2nd attempt. (mapping happens for lawn mower and vacuum types as well - one of them is unsuccessful as I indicated above) |
The debug messages about dp6 are not a concern. It is just HA checking if the sensor has fixed values list to see if it should report a warning that it should be an enum. |
Although this seems to have some non-problematic statuses, it is reportedly stuck on "Tilted", which may be because it is no longer being sent, and that was the last value. Treat it as non-persistent, with a default value of OK, to clear non-current problems if that is the case. Issue make-all#1983
Describe the bug
Parkside PMRDA 20-Li A1 lawn mower ("type": "moebot_s_mower") sometimes has incorrect mappings in specific cases, and the fault reports always return "Tilted"
To Reproduce
Steps to reproduce the behaviour including the device the issue was observed with:
use and test the device.
Expected behavior
mapping the states and faults correctly (see below)
Additional context
correct info is returned from the raw_action attribute of the status but no such attribute for the problems, so individual remapping is not possible. (it would be nice if it is attached as well, but this FR is not the scope of the current ProblemRiport.) Digging deeper, the problem state (103) always return MOWING_LEAN
Only protocol 3.3 is supported.
If the bug involves a device, then please include device diagnostics from
mower.txt
Please check if there are messages from Tuya Local in the Home
....And no unhandled ERROR is raised in python.
the states and problems are collected here:
Parkside lawn mower PMRDA 20-Li A1 #758 (reply in thread)
so the state (101) mappings should look like:
CHARGING -> charging (currently docked)
CHARGING_WITH_TASK_SUSPEND -> "resume after recharged" or something like that, (currently docked)
MOWING -> mowing (ok)
DOCKED -> docked (ok)
PAUSED -> paused (ok)
STANDBY -> standby (currently docked)
PARK -> docking (currently paused)
LOCKED - locked (currently docked)
Additional unmentioned state:
FIXED_MOWING - "Spot mode" or something like that (currently mowing)
EMERGENCY, and ERROR cannot be distinguished until it is not combined with another sensors (problem state or the binary sensor of the cover )
EMERGENCY - can be when the cover is opened, and also when emergency button is pressed. (so it can be well combined with the binary sensor of the cover)
ERROR - other errors. (ok)
For the problem state (103) I was not able to confirm problems and discover more, because MOWER_LEAN is reported all the time. so we need to resolve that, before making the mappings for the problems.
and there is an vacuum.* type entity along the lawn_mower.* type entity which is also irrelevant. (it also maps the values incorrectly)
The text was updated successfully, but these errors were encountered: