8000 Version `1.2.3 Build 240617 Rel.153525` for the P110M added and renamed some fields · Issue #1269 · python-kasa/python-kasa · GitHub
[go: up one dir, main page]
Skip to content

Version 1.2.3 Build 240617 Rel.153525 for the P110M added and renamed some fields #1269

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.

Sign up for GitHub

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

Jump to bottom
Closed
MrEbbinghaus opened this issue Nov 17, 2024 · 13 comments · Fixed by #1335
Closed

Version 1.2.3 Build 240617 Rel.153525 for the P110M added and renamed some fields #1269

MrEbbinghaus opened this issue Nov 17, 2024 · 13 comments · Fixed by #1335

Comments

@MrEbbinghaus
Copy link

Looks like firmware version 1.2.3 Build 240617 Rel.153525 for the P110M added some fields and renamed the overheated field, causing it to no longer be listed as a feature. (And therefore has become an unavailable entity in HA.)

This is a sample diff, of what my P110M reports compared to the P110 test fixture.

"get_device_info": {
    "auto_off_remain_time": 0,
    "auto_off_status": "off",
    "avatar": "plug",
    "default_states": {
        "state": {},
        "type": "last_states"
    },
    "device_id": "0000000000000000000000000000000000000000",
    "device_on": false,
    "fw_id": "00000000000000000000000000000000",
-   "fw_ver": "1.2.3 Build 230425 Rel.142542",
+   "fw_ver": "1.2.3 Build 240617 Rel.153525",
    "has_set_location_info": false,
    "hw_id": "00000000000000000000000000000000",
    "hw_ver": "1.0",
    "ip": "127.0.0.123",
    "lang": "en_US",
    "latitude": 0,
    "longitude": 0,
    "mac": "48-22-54-00-00-00",
-   "model": "P110",
+   "model": "P110M",
    "nickname": "I01BU0tFRF9OQU1FIw==",
    "oem_id": "00000000000000000000000000000000",
    "on_time": 0,
-   "overheated": false,
+   "overheat_status": "normal",
+   "overcurrent_status": "normal",
+   "charging_status": "normal"
    "power_protection_status": "normal",
    "region": "Europe/Berlin",
    "rssi": -42,
    "signal_level": 3,
    "specs": "",
    "ssid": "I01BU0tFRF9TU0lEIw==",
    "time_diff": 60,
    "type": "SMART.TAPOPLUG"
}
@MrEbbinghaus MrEbbinghaus mentioned this issue Nov 17, 2024
Merged
@MrEbbinghaus
Copy link
Author

I can't say what other states there are besides normal. I'm not really keen to test. 😄

@rytilahti
Copy link
Member

It's worth checking if there are some clear hints in the component listing that could be used to detect what is supported.

We could also just fallback and make a != normal comparison to keep it a binary sensor.

@MrEbbinghaus
Copy link
Author

I checked the android app code, and it seems the possible values are:

overheat_status: normal, cool_down and overheated

the values for
overcurrent_status: normal and lifted
charging_status: normal and finished
powerprotection_status: normal and overloaded

@a81j
Copy link
a81j commented Nov 28, 2024

The P110M still doesn't work in Home Assistant with the version in dev that uses 0.8.0

The device_current_consumption still shows as unavailable

Is this the reason why?

@sdb9696
Copy link
Collaborator
sdb9696 commented Nov 28, 2024

Shouldn't be. Is that the only issue? Have you checked the date and time is correct on the device?

@a81j
Copy link
a81j commented Nov 28, 2024 •
edited
Loading

Shouldn't be. Is that the only issue? Have you checked the date and time is correct on the device?

I've put some more info in #1243

When the power fails, the time will go out.

With incorrect time everything works fine in the app and all the rest of the works fine in Home Assistant. Using the command line tool also shows it correctly despite giving the error as well.

@rytilahti rytilahti mentioned this issue Dec 3, 2024
Merged
@rytilahti
Copy link
Member
rytilahti commented Dec 3, 2024 •
edited
Loading

The linked PR adds support for reading the overheated information from overheat_status key, feel free to give it a test to confirm it's working as expected :-)

Support for overcurrent_status and charging_status (are these related?) belongs to separate issue(s)/PR(s).

@rytilahti rytilahti linked a pull request Dec 3, 2024 that will close this issue
Improve overheat reporting #1335
Merged
@MrEbbinghaus
Copy link
Author
MrEbbinghaus commented Dec 3, 2024 •
edited
Loading

Support for overcurrent_status and charging_status (are these related?) belongs to separate issue(s)/PR(s).

Those are not related. overcurrent_status seems to be for "Power Protection", which acts like a circuit breaker.

And I guess charging_status belongs to the "Charge Guard" Feature, where the plug turns off automatically after a user defined amount of energy has been consumed.

From their support documents:
image

@rytilahti
Copy link
Member
rytilahti commented Dec 3, 2024 •
edited
Loading

Thanks for the clarification! I think adding support for those might be rather straightforward, but IMO they are not that important at the moment.

If you don't mind, could you create a separate issue for both of those so we can track them more easily, or even create pull requests if you wish to do so? Having them separate makes it easier to avoid forgetting about those, plus as features are usually implemented one module at a time, it makes it easier to close issues for already implemented features.

@MrEbbinghaus
Copy link
Author

Sure, I will open new issues. Also, I've just realised that I made a mistake, and there is also the existing power_protection_status, so overcurrent_status does not belong to that feature.

So my next guess would be that overcurrent_status (like overheat_status) is indeed a safety feature, which would be kind of important to implement so that users aren't confused when their device shuts down without explanation. (Not to mention the potential danger of pushing such a device to the limit.)

There is no mention of an overcurrent (or overheat) protection display in their Tapo App Guide and I don't have the time right now to look for clues in the app's code, as for how exactly they work.

@rytilahti
Copy link
Member

Sure thing! I took a quick look at the power protection yesterday:

> kasa --host 192.168.x.x command get_max_power
{"get_max_power": {"max_power": 3942}}
> kasa --host 192.168.x.x command get_protection_power
{"get_protection_power": {"protection_power": 0, "enabled": false}}
> kasa --host 192.168.x.x command set_protection_power '{"enabled": True, "protection_power": 1}'
{"set_protection_power": null}
> kasa --host 192.168.x.x command get_protection_power
{"get_protection_power": {"protection_power": 1, "enabled": true}}

After a while, this will turn the device off & set the "power_protection_status": "overloaded".

I'll create a quick PR for this, unsure about the validity of max_power response, the website says the max load of 3680W.

@MrEbbinghaus
Copy link
Author

3680 W are 16 A at 230 V.

ISO IEC 60038:1983 defines the voltage in Europe to be 230 V ± 23 V.
So that value could be at the max voltage your plug has seen.

(get_emeter_data gives me ~235,6V right now, which would be 3770 W at 16 A. My max_power is 3896 W)

@rytilahti rytilahti mentioned this issue Dec 4, 2024
Merged
@rytilahti
Copy link
Member
rytilahti commented Dec 4, 2024 •
edited
Loading

#1337 implements power protection in the library, home-assistant/core#132267 exposes them to homeassistant.

About overcurrent_status, the fixture files should be checked to see if this should also be contained in the same module or somewhere else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Improve overheat reporting python-kasa/python-kasa
4 participants
@MrEbbinghaus @rytilahti @a81j @sdb9696
0