0.31.x: Missing entities

[zxdavb]

0.31.x: Missing entities

[zxdavb]

@trvrnrth
Would be good if you could remember to:

• pre-commit run --all
• mypy

before you commit (I am not sure if the workflow forces you do do this).

[zxdavb]

I am not sure if this is related to #118?

IIRC, v0.31.1 is the first public release that includes this commit.

[zxdavb]

@trvrnrth See above - do you have any thoughts - I've had a quick look, but cannot see what's the issue - I am using the latest dev branch of HA.

I think these are a separate issue:

binary_sensor.13_237335_active
water_heater.stored_hw
binary_sensor.01_145038_schema
sensor.01_145038_hw_heat_demand

... and I will chase them down tomorrow-ish.

[zxdavb]

These coudl be in either group - dunno:

sensor.10_064873_boiler_output_temp
sensor.10_064873_ch_max_setpoint
sensor.10_064873_ch_water_pressure
binary_sensor.10_064873_dhw_enabled
binary_sensor.10_064873_fault_present

[zxdavb]

See:

• commit bba4b06 restore missing binary_sensor: CTL.active_fault
• commit 09ef8dd restore missing binary_sensor: BDR.active

[trvrnrth]

Diagnostic sensors (ie. entities with an category of EntityCategory.DIAGNOSTIC) are not included in the default dashboard.

I'll take a look at the other reported issues and see if I can spot anything.

[trvrnrth]

For binary_sensor.13_237335_active your fix looks correct. I had misread the intention of the old RamsesActuator entity class and must have forgotten to bring it up during review.

The change made in bba4b06 could probably be moved to the base RamsesBinarySensor as there's no harm doing the cast for all entities but otherwise seems correct.

[trvrnrth]

binary_sensor.01_145038_schema is renamed binary_sensor.01_145038_status. I thought we'd had a conversation about that on a previous PR but I can't find it at the moment.

[trvrnrth]

sensor.10_064873_boiler_output_temp
sensor.10_064873_ch_max_setpoint
sensor.10_064873_ch_water_pressure
binary_sensor.10_064873_dhw_enabled
binary_sensor.10_064873_fault_present

I can't see anything on the ramses_cc side that would make these unavailable but I do notice that they are also no longer available in my "production" setup so I would suspect a recent ramses_rf change?

[trvrnrth]

water_heater.stored_hw
sensor.01_145038_hw_heat_demand

I suspect that this will be because the DhwZone is not getting picked up from a system at

ramses_cc/custom_components/ramses_cc/broker.py

Line 186 in db1f60e

new_zones = new_entities(

I can PR something that should resolve these but unfortunately don't have a DHW system to test against.

[trvrnrth]

I believe #131 should resolve discovery of the DhwZones.

[trvrnrth]

sensor.10_064873_boiler_output_temp
sensor.10_064873_ch_max_setpoint
sensor.10_064873_ch_water_pressure
binary_sensor.10_064873_dhw_enabled
binary_sensor.10_064873_fault_present

I can't see anything on the ramses_cc side that would make these unavailable but I do notice that they are also no longer available in my "production" setup so I would suspect a recent ramses_rf change?

I believe the problem lies here: zxdavb/ramses_rf#99

[zxdavb]

Diagnostic sensors (ie. entities with an category of EntityCategory.DIAGNOSTIC) are not included in the default dashboard.

That I did not know!

The change made in bba4b06 could probably be moved to the base RamsesBinarySensor as there's no harm doing the cast for all entities but otherwise seems correct.

I agree completely - I pulled it out partly because I am becoming a big fan of strict typing.

Certainly, the issue with 09ef8dd would have been picked up via mypy.

binary_sensor.01_145038_schema is renamed binary_sensor.01_145038_status. I thought we'd had a conversation about that on a previous PR but I can't find it at the moment.

I think you're right - I had that in the back of my head - was going to look at it next.

I can't see anything on the ramses_cc side that would make these unavailable but I do notice that they are also no longer available in my "production" setup so I would suspect a recent ramses_rf change?

You're right again - I alluded to this in the HA forum (do you keep an eye on that?) - I suspect it has something to do with changes to use_native_ot:

ramses_cc:
  ramses_rf:
    use_native_ot: always  # always, prefer (default), avoid, never

[zxdavb]

I can PR something that should resolve these but unfortunately don't have a DHW system to test against.

There are a couple of ways around this.

• fake a DHW sensor (turn of HW priority, have it set to permanently off)
• load a contrived cache into HA (via .storage/ramses_cc)
• 'feed' a stream of packets (an old log) into HA via ser2net

But what I really need to do is setup some tests.

[zxdavb]

Diagnostic sensors (i.e. entities with an category of EntityCategory.DIAGNOSTIC) are not included in the default dashboard.

I think every device should have one - and only one - non-DIAGNOSTIC attr.

• TRVs: heat_demand (%) - a change from temp
• BDR: active (bool)
• DHW (sensor): temperature
• THM: (indoor) temperature
• CTL: heat_demand (call for heat) of FC, with ext_state_attr of FA, etc.
• UFC: (probably) heat_demand
• OTB: modulation_level (%)

This will complicate the table - main attr is temperature for THM, but heat_demand for TRV.

[trvrnrth]

You're right again - I alluded to this in the HA forum (do you keep an eye on that?) - I suspect it has something to do with changes to use_native_ot:

I went looking: zxdavb/ramses_rf#99

[trvrnrth]

I think every device should have one - and only one - non-DIAGNOSTIC attr.

That seems reasonable.

This will complicate the table - main attr is temperature for THM, but heat_demand for TRV.

That shouldn't be too terrible; there will be a small amount of duplication but probably nothing horrific. If necessary the rf_class on the description can also accept a union (ie. rf_class=DeviceClassA | DeviceClassB)

[zxdavb]

I went looking: zxdavb/ramses_rf#99

Wow! Too quick! Thanks.

Now: how did that get past mypy?

[zxdavb]

I have added some typing to ramses_cc, so that is passes a basic mypy check.

Sadly, you'll need to merge it into your work - sorry for making work, but I have learned that strict typing is the way forward - it simply prevents bugs.