Outputs 0 when connection seems bad

[dimalo]

Hi @ChristianKuehnel! Really appreciate your work, implementing this in openHAB was very straight forward - thanks!

I have one issue:

• my raspi is working indoor
• some plants are outside
• from time to time the connection seems to be unstable
• plantgateway then reports all values with zeroes

Is there any chance, you can build some handle to block plantgateway from sending these values? for example the battery value cannot jump from 100 to 0% - even better: when battery was 0% the thing would not send anything!

Can I help you out with something to track this down? log? do you have any debug preferences to activate?

[ChristianKuehnel]

Hi @dimalo,

that's quite strange, I never observed this behavior with my sensors. If the connection fails, the plant gateway should not transmit any data via MQTT. Can you attach either a log file or the console output? The log will contain the binary data that was received from the sensors. That would probably be the level where we can filter out that data. it will also contain the version number of the sensor...

[dimalo]

Hi @ChristianKuehnel unfortunately the log does not show raw data, nor version number. I see some reties, but few final fails. Would be helpful if the log showed timestamps too... here is the tail of the log with the last two readings:

INFO:root:loaded config file from /home/openhabian/.plantgw.yaml
INFO:root:Getting data from sensor elefantenfuss
INFO:root:MQTT connection returned result: Connection Accepted.
INFO:root:sent data to topic openhabian/plants/elefantenfuss/
INFO:root:Getting data from sensor heidelbeere
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 1 of 5)
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 2 of 5)
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 3 of 5)
INFO:root:sent data to topic openhabian/plants/heidelbeere/
INFO:root:Getting data from sensor feige
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 1 of 5)
INFO:root:sent data to topic openhabian/plants/feige/
INFO:root:loaded config file from /home/openhabian/.plantgw.yaml
INFO:root:Getting data from sensor elefantenfuss
INFO:root:MQTT connection returned result: Connection Accepted.
INFO:root:sent data to topic openhabian/plants/elefantenfuss/
INFO:root:Getting data from sensor heidelbeere
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 1 of 5)
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 2 of 5)
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 3 of 5)
INFO:plantgw.misensor:function <class 'bluepy.btle.Peripheral'> failed (try 4 of 5)
INFO:root:sent data to topic openhabian/plants/heidelbeere/
INFO:root:Getting data from sensor feige
INFO:root:sent data to topic openhabian/plants/feige/

at least one call tell from the config loading info, when a new cycle began. I execute plantgw with a cronjob hourly.

interesting: the first reading for heidelbeere got 0 values (but only for plant data, not battery), the second didn't. they are looking the same from the log though. Also my first suggestion to filter 0 battery values is not sufficient. As I understand battery and plant data are different handles, so each one can fail seperately, as it did with the first reading.

So things could be, that the raw data gets corrupted somehow from time to time. plantgw then parses this to zero and sends everything out. as you see, it's not a generally failing connection, but a quite bad one. by the way, feige got plausible values both times.

At the moment I'm working around that by deleting 0 values in my mysql db...

[dimalo]

OK had a little investigation... first of all modified your code to get what I wanted:

• option in config file to set debug: true for logfile
• nice format for the log

have updated the sensors from 2.6.2 to 2.9.2 at the moment the connection fails every time. thats OK as long as when it works the values are right 😄

I wrote this on the fly so I'll just copy my code to a naked PR for you - no fork or branch...

Edit: will never do patches online on github again, you have to commit each file change 😞

[ChristianKuehnel]

First off: Thanks for the patches on the debug features!

It seems that your system is only showing the "INFO" logs and not the "DEBUG" logs. Do you have any system wide logging settings suppressing DEBUG logs?

For me the output looks like this:

INFO:root:Getting data from sensor Ficus
INFO:root:MQTT connection returned result: Connection Accepted.
DEBUG:plantgw.misensor:connected to device C4:7C:8D:60:D6:41
DEBUG:plantgw.misensor:Raw data for char 0x35: ee 00 00 00 00 00 00 28 0b 02 02 3c 00 fb 34 9b
DEBUG:plantgw.misensor:temp: 23.800000
DEBUG:plantgw.misensor:brightness: 0
DEBUG:plantgw.misensor:conductivity: 523
DEBUG:plantgw.misensor:moisture: 40
DEBUG:plantgw.misensor:Raw data for char 0x38: 49 1e 32 2e 39 2e 32
DEBUG:plantgw.misensor:battery: 73
DEBUG:plantgw.misensor:version: 2.9.2
INFO:root:sent data to topic pflanzen/Ficus/

There you can also see the raw data that was read from the sensors.

[dimalo]

this was what I added 😄 . you had debug automatically enabled, when logging was off. so debug massages only showed up in the console. now with "debug" uncommented in the config the logger writes debug messages also to the file

[ChristianKuehnel]

ah right, you know my code better than I do ;)

Can you send me the "Raw data" line for the cases where you get zeros in the measurements?

[dimalo]

no problem, glad I could improve something 👍 so for now I'll let it log all events and will get back when I catch the problematic readouts... cheers! 🍺

[dimalo]

hey @ChristianKuehnel what can I say... no more faults since I updated to 2.9.2. so I close this one... Thanks for your support anyway!