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

Daemon reads sensor moisture and conductivity as 0 #179

Open
gianmarco-mameli opened this issue Jul 17, 2024 · 3 comments
Open

Daemon reads sensor moisture and conductivity as 0 #179

gianmarco-mameli opened this issue Jul 17, 2024 · 3 comments

Comments

@gianmarco-mameli
Copy link

Hi,
I'm using this fantastic project to read 10 sensors on my garden and works like a charm (running on docker).
Few days ago I found that a sensor seems having power problems on reading the values, so I've switched it with a spare, but the readings of Moisture and Conductivity are every loop at 0 (sometimes Moisture shows 1%.
The sensor works well in app, only the daemon reads 0, the other values are correct.

Example log:

[2024-07-17 10:19:29] Retrieving data from sensor "Limone" ...
[2024-07-17 10:19:31] Result: {"light": 1743, "temperature": 29.3, "moisture": 0, "conductivity": 0, "battery": 100}
[2024-07-17 10:19:31] Publishing to MQTT topic "homeassistant/sensor/limone/state"

Any clue?

Thanks

@ThomDietrich
Copy link
Owner

Hey there! Thanks, happy to hear this is useful for you!

My first guess would have been a limitation of the underlying library, however, did I understand correctly that the library itself reads data just fine?

basnijholt/miflora#177

@gianmarco-mameli
Copy link
Author

Hi @ThomDietrich , thanks for your reply.
I admit that I opened that issue without having a closer look at your code, it uses miflora library and In fact is the library that get incorrect values.
In my issue you mentioned, there's a little block of log, obtained calling the miflora library directly with a simple python code that shows a working sensor in app, getting moisture 1 and conductivity 0.
As additional information the sensor with the incorrect values is the only from the total of ten that has a different starting mac address: 9 of them starts with C4:7C:8D the 10th starts with 80:EA:CA. I forgot to mention that in the library issue

Thanks

@ThomDietrich
Copy link
Owner

I see. In this case this issue indeed needs to be solved in the linked issue first. We can leave this one open until resolved.

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

2 participants