#Modbus no longer leaks memory (hopefully
calm mulch
By the way, I saw that PR for stiebel eltron
One thing I didn't get was, in theory this uses the modbus as abstraction layer, so how come this integration doesnt work anymore as is?
tacit wadi
AFAICT modbus used to store the library object in hass.data, now it an internal hub object from the integration there so its accessing hass.data and getting a completely different object than it expects
calm mulch
now -> with that PR?
tacit wadi
that PR restored it to the object type it expects
calm mulch
right
But that PR now changes the YAML to just detach itself from modbus
And I am now not sure if this would be an exception of a breaking change in YAML
tacit wadi
I think an alternate fix would be to extract the underlying pymodbus object from the modbus intergration hub object
than no YAML change needed
if that can't happen than I'd say it probably warrents an exception since its broken now
but AFAICT, it should be possible to get the object it wants from the pymodbus object...
but I did a TPAC flight last night and haven't slept yet so I might be missing something
hmm its more messy
modbus has a AsyncModbusTcpClient
and stiebel_eltron is expecting a ModbusTcpClient
so probably no way to fix it to use the AsyncModbusTcpClient from the modbus hub object without converting the whole thing to async
calm mulch
-# What's a TPAC
tacit wadi
trans pacific
tacit wadi
since its broken now, it makes sense to allow an exception since its not the integrations fault that modbus changes broke it, and its not realistic to convert the whole thing to a config flow before beta cutoff
calm mulch
I think the hardest part to get this to a config flow is actually getting the data from the modbus config
But I haven't actually have any encountered any YAML breaking changes before, since I only joined the project 2 years ago, so is there any risk into doing this?
Otherwise I can just pump out a config flow in an hour
tacit wadi
But I haven't actually have any encountered any YAML breaking changes before, si...
The risk is bad UX since we have to put them through two breaking changes
If we do config flow now at least it’s only one time they have to reconfigure it
calm mulch
Aight, I am going to grab a cup of tea and get going
tacit wadi
You can skip the deprecation period on the YAML as well as there is no point in preserving the broken config
calm mulch
but we can still import it
tacit wadi
If you can figure out the settings from the modbus hub object AKA https://github.com/home-assistant/core/blob/653ff4717105b9c33d5312eeba65c75073af35bb/homeassistant/components/modbus/modbus.py#L247 that they currently have configured you should be able to migrate it
that would avoid the breaking change and give a reason to keep the yaml around for a bit even if its only to import it
calm mulch
the current entrypoint is setup, that means that full config object is dumped in there right?
So we can just fetch it from the modbus section
tacit wadi
I think you inspect the hass.data[MODBUS_DOMAIN][config[DOMAIN][CONF_HUB]] aka ModbusHub object, to get the client_config out of it to create the config entry details and use the code in https://github.com/home-assistant/core/pull/136482 to create the expected ModbusTcpClient
You might have to add something to ModbusHub to be able to get it to give up the client_config data in a non protected way