Skip to content
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

Plant state unknown after update #210

Open
MD0005 opened this issue Dec 5, 2024 · 12 comments
Open

Plant state unknown after update #210

MD0005 opened this issue Dec 5, 2024 · 12 comments

Comments

@MD0005
Copy link

MD0005 commented Dec 5, 2024

Hello. After update to v2024.11 all plants based on esp32 sensors have changed the state to unknown and attributes to null. Downgrading didnt resolve the issue.
Strangely plants based on Mija sensor are working properly.

Im not sure how to recover the proper plant entities to more than 15 plants :(

IMG-20241205-WA0017
IMG-20241205-WA0019

@Olen
Copy link
Owner

Olen commented Dec 5, 2024

What is the status of the actual sensors (the physical source sensors that the plant device is copying the data from)

@MD0005
Copy link
Author

MD0005 commented Dec 5, 2024

Actual sensor is fine. Showing value. The value is also shown by the Plant Monitor Soil Moisture 'virtual' sensor. The issue is with the plant.x entity that is not evaluating related sensors.

IMG-20241205-WA0033
IMG-20241205-WA0032

@klaptafel
Copy link

Same here! 👎🏻

@Tamago2000
Copy link

Same here.

@Balooforever
Copy link

Same here...

@Olen
Copy link
Owner

Olen commented Dec 8, 2024

It would be really nice if anyone could provide slighty more info than "me too".
Some logs, some info about the sensor values, some debug output, your settings for what shold trigger a problem state...

@Balooforever
Copy link

Balooforever commented Dec 8, 2024

Hi Olen,

My log :
Update for plant.aechmea fails Traceback (most recent call last): File "/usr/local/lib/python3.13/site-packages/homeassistant/helpers/entity.py", line 960, in async_update_ha_state await self.async_device_update() File "/usr/local/lib/python3.13/site-packages/homeassistant/helpers/entity.py", line 1320, in async_device_update await hass.async_add_executor_job(self.update) File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/plant/__init__.py", line 745, in update and self.dli.state is not None ^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/homeassistant/components/sensor/__init__.py", line 556, in state unit_of_measurement = self.unit_of_measurement ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/homeassistant/components/sensor/__init__.py", line 537, in unit_of_measurement := self.platform.default_language_platform_translations.get(translation_key) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'default_language_platform_translations'

I have update the plugin too 2024.11 and the card in beta (but he doesn't work in section anymore :()

@MD0005
Copy link
Author

MD0005 commented Dec 8, 2024

Underneath is my log. But I think I know what might be the cause. Im using ESP32 to get the conductivity and temperature. I have disabled all other entities under these plants that I was sure I will be not using (f.e. air humidity). I didnt wanted to keep so many artifical entities with status 'unknown'. With previous version it was working, with the new version, the main plant.x entity is not working with even one sub-entity disabled.

If you have the same issue, after you enable back the other entities, remember to restart HA.
After restart, all works again 👍

Logger: homeassistant.helpers.entity
Source: helpers/entity.py:960
First occurred: 21:32:49 (1755 occurrences)
Last logged: 22:21:20

Update for plant.epipremnum_2 fails
Update for plant.kalanch fails
Update for plant.epipremnum_3 fails
Update for plant.epipremnum_4_bottom fails
Update for plant.euphorbia fails
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 960, in async_update_ha_state
    await self.async_device_update()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1320, in async_device_update
    await hass.async_add_executor_job(self.update)
  File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/plant/__init__.py", line 745, in update
    and self.dli.state is not None
        ^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 556, in state
    unit_of_measurement = self.unit_of_measurement
                          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 537, in unit_of_measurement
    := self.platform.default_language_platform_translations.get(translation_key)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'default_language_platform_translations

@Olen
Copy link
Owner

Olen commented Dec 8, 2024

Sounds like this can be related to the translateable units of measurements that I think are new.

Not sure how to fix that in a hurry

@eUwSqBTm
Copy link

I got mine working again by enabling all the disabled entities under sensors (my sensors only do temp/moisture) and then reinstalling the home assistant plant integration.

My ESP32 ones that have all the sensors never stopped working.

@Olen
Copy link
Owner

Olen commented Dec 12, 2024

Have you also updated the list of sensors that should trigger a "problem" status?
Could it be a mismatch between the sensors there and the sensors provided by the esp32 integration?

@klaptafel
Copy link

I only use the soil moisture as problem trigger, and only the Dli entities were disabled (all 3). This situation caused the 'unknown' state. Enabling the 3 Dli entities and restarting Home Assistant fixed it.

However, ideally when not using the other categories as problem triggers it should be no issue to disable them (either manually or maybe even automatically after (re)configuring).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants