Add myuplink specific sensor descriptions #109867
Conversation
|
Hey there @pajzo, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
|
Thank you @MartinHjelmare for your valuable comments and suggestions. Much cleaner now. |
| key="priority", | ||
| device_class=SensorDeviceClass.ENUM, | ||
| icon="mdi:priority-high", | ||
| ), |
There was a problem hiding this comment.
S series an F series have overlapping number series (at least with the old f series numbering) so this might not be enough. I kind of doubt that myuplink upgraded F series have adapted the numbering of the S series.
Ive not looked at the numbering for S series on myuplink uet but it would sort of make more sense if matched modbus numbers, but maybe it doesnt?
There was a problem hiding this comment.
We are prepared for overlapping numbers. The numbers in the descriptor keys can be qualified with category name if needed. However I suspect that this can be a source of more work until everything calmes down...
I would really like to know how S-series presents itself in the myuplink API to try to find the most efficient solution.
The new firmware for my F730 was released about two weeks ago and i upgraded and migrated last week and quite a lot of sensors are missing in the public API. I noted that Nibe/myUplink have made some significant upgrades to the capabilities in the ios-app and on the web for F730 the last few days.
There was a problem hiding this comment.
So far as S series and F series never have same number for anything. So i think it should always be qualified.
If want to see the mostly complete databases, they are here https://github.com/yozik04/nibe/tree/master/nibe/data
We can probably ask some S series guys using the modbus setup test the myuplink integration of you dont have any such testers. Once the new release is public i suspect they will test it.
There was a problem hiding this comment.
@elupus when you mention S serie, i have a NIBE VVM S320 E EM 3x400V DK - what do you want me to test?
Without fully understand you point, i think it's fine to have these parameter_id config, and fallback to parameter_unit.
There was a problem hiding this comment.
@pajzo what does your parameter 43108 represent
There was a problem hiding this comment.
Or 49994? Or some other parameter for 'priority' you have
There was a problem hiding this comment.
@pajzo what does your parameter 43108 represent
It is "Current fan mode" in the F730, = [0, 1, 2, 3, 4] It is assigned % as unit which is incorrect.
49994 is labelled Priority and can be Off, Hot water, Heating, Pool and so on.
From the metadata in each device-point I think we can make an educated guess what entity platform that is suitable. E.g. a parameter that can be zero or one and is writable should be represented by a switch. If it is read-only, a binary sensor would be appropriate.
There was a problem hiding this comment.
Im asking for S series report from @pajzo . As i said their number series are very likely overlapping and with completely different meaning for same number.
There was a problem hiding this comment.
Yes, I fully understand that there are overlapping number series.
Please regard the current code more of a proof-of-concept than the ultimate solution. If we change the "49994" key to "NIBEF F730 CU 3x400V-49994" it will be correct for F730 and the sensor will show a number value with default icon for all other devices with a "49994".
I am currently working on a better method to interpret the point metadata and assign proper platform, device_class and other properties. Hopefully this will be reasonably correct. The ambition should be that the need for "manual" overrides is not too big.
The overall aim with the intergration is to make use of the metadata and do the best we can with it. The alternative is to maintain a huge database from all manufacturers connected to myUplink and all their models and that seems rather unattractive to me.
There was a problem hiding this comment.
Here is a output for my S320 - seems like the parameter_id's is unique.
[
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "4",
"parameterName": "Current outdoor temperature (BT1)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:53:53+00:00",
"value": 0.4,
"strVal": "0.4°C",
"smartHomeCategories": [
"sh-outdoorTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "8",
"parameterName": "Supply line (BT2)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:54:54+00:00",
"value": 38.4,
"strVal": "38.4°C",
"smartHomeCategories": [
"sh-supplyTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "10",
"parameterName": "Return line (BT3)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:54:38+00:00",
"value": 28.2,
"strVal": "28.2°C",
"smartHomeCategories": [
"sh-returnTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "11",
"parameterName": "Hot water top (BT7)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:46:44+00:00",
"value": 48.8,
"strVal": "48.8°C",
"smartHomeCategories": [
"sh-hwTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "12",
"parameterName": "Hot water charging (BT6)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:47:25+00:00",
"value": 46.0,
"strVal": "46°C",
"smartHomeCategories": [
"sh-hwTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "54",
"parameterName": "Average temperature (BT1)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-08T22:58:57+00:00",
"value": -0.6,
"strVal": "-0.6°C",
"smartHomeCategories": [
"sh-outdoorTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "781",
"parameterName": "Degree minutes",
"parameterUnit": "DM",
"writable": true,
"timestamp": "2024-02-09T03:54:58+00:00",
"value": -796.0,
"strVal": "-796DM",
"smartHomeCategories": [],
"minValue": -30000.0,
"maxValue": 30000.0,
"stepValue": 20.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "1708",
"parameterName": "Calculated supply climate system 1",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:40:12+00:00",
"value": 35.0,
"strVal": "35°C",
"smartHomeCategories": [
"sh-supplyTemp"
],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "Varmepumpe 1",
"parameterId": "2491",
"parameterName": "Return line (EB101-BT3)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:55:09+00:00",
"value": 27.9,
"strVal": "27.9°C",
"smartHomeCategories": [],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "Varmepumpe 1",
"parameterId": "2494",
"parameterName": "Supply line (EB101-BT12)",
"parameterUnit": "°C",
"writable": false,
"timestamp": "2024-02-09T03:53:54+00:00",
"value": 36.8,
"strVal": "36.8°C",
"smartHomeCategories": [],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [],
"scaleValue": "0.1",
"zoneId": null
},
{
"category": "NIBE VVM S320 E EM 3x400V DK",
"parameterId": "10895",
"parameterName": "Pump: Heating medium (GP6)",
"parameterUnit": "",
"writable": false,
"timestamp": "2024-02-08T23:45:49+00:00",
"value": 0.0,
"strVal": "0",
"smartHomeCategories": [],
"minValue": null,
"maxValue": null,
"stepValue": 1.0,
"enumValues": [
{
"value": "0",
"text": "0",
"icon": ""
},
{
"value": "1",
"text": "1",
"icon": ""
}
],
"scaleValue": "1",
"zoneId": null
}
]
MartinHjelmare
changed the title
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
Yes, I agree. But this is not the final version. It will be OK for F730 and all other the models will get same generic sensors for all unspecific parameters as before this PR. So I think we can merge this to be able to proceed. Then we need diagnostic data from a variety of pumps in "myUplink terminology" to be able to figure out a method for grouping based on available metadata. I am almost ready with a solution that sorts out which DevicePoints that should create sensors, sensors with enum device_class, binary sensors and switches repectively. All by looking at the metadata from the API. Those features will come in later PR:s. However I hope the diagnostics.py can be merged soon. That is a simple way to get more information from the early adopters of the integration. |
OK thats good to know. Then it simple to qualify with "NIBEF F" from the category string. But it would be nice to have seen real data from one or two other models instead of guessing how the API categorizes the models. I can produce follow up PR with this more liberal model for qualification - it will probably not harm. |
My guess would be "NIBEF" and "NIBEF" prefix on the category. The second F in "NIBEF FXXX" is part of the model name. So if you link it to to "NIBEF" for now, that is okey. |
|
Ready for final review. ?! |
| @@ -102,4 +157,36 @@ def __init__( | |||
| def native_value(self) -> StateType: | |||
| """Sensor state value.""" | |||
| device_point = self.coordinator.data.points[self.device_id][self.point_id] | |||
| if device_point.value == -32768: | |||
There was a problem hiding this comment.
What does this check mean?
There was a problem hiding this comment.
Normally the API will not include device_point that are permanently unavailable. The API will return -32768 if data is temporarily unavailable. I.e. "Unknown" with HA terminolgy. It happens on two data_points in my F730. I think it is better to show "Unknown" than showing -32768.
There was a problem hiding this comment.
That constant kind of needs to be defined in the library, but it at least need a constant defined for it here.
|
Example from real life
|
|
Screenshot from heat-pump in Orsa
|
Breaking change
Proposed change
Add support for more sensor descriptions to enable assignment of device_classes and more. These descriptions can be global for each parameter_id or specific for a certain categgory (i.e. heat pump model).
If the device_class is set to ENUM the options will be extracted from enumValues.
Needs myuplink lib >= 0.1.0
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.To help with the load of incoming pull requests: