drolla / waveplus_bridge Goto Github PK

View Code? Open in Web Editor NEW

21.0 5.0 9.0 1.51 MB

Airthings Wave Plus Bridge to Wifi/LAN and MQTT

License: MIT License

Shell 0.79% Python 91.49% HTML 0.94% CSS 1.27% JavaScript 5.52%

airthings mqtt radon raspberry-pi python airthings-wave-plus

waveplus_bridge's People

Contributors

Stargazers

Watchers

Forkers

idcmp rkoshak jmagnuson qk-sampson calmarc zeyus nasdim dem5867 hanschdennis

waveplus_bridge's Issues

Application crashes if 'period' or'data_retention' are not explicitly defined by the YAML file

This issue relates to pull request #7. In case period or data_retention is not explicitly defined by the YAML configuration file, the application returns with the following failure

Read configuration file /opt/waveplus_bridge/waveplus_bridge.fusion18.basic.yaml
2021-11-14 08:45:50 - Opening CSV data log file None
2021-11-14 08:45:50 -   Error accessing CSV file! None : unsupported operand type(s) for /: 'str' and 'int'

This error is also encountered if the two parameters are not defined by the YAML file, but if they are explicitly defined by the command line arguments --period and --data_retention.

Improve the MQTT interface: Use the Homie library/specification

This is a remaining suggestion from @rkoshak taken over from #6 to use the Homie library/specification for the MQTT interface.

bluetooth connection issues after some time - with easy workaround ?

I have now currently 3 devices that are being read with the Bridge and have run in a strange issue - sometimes some devices stop responding (not always the same one, though some more often than others).

But its immediately fixed with restarting the waveplus bridge python script.

so for now, I just have a cronjob that restarts it hourly...

I realize this is difficult to diagnose, with all the variables of different hardware, range and bluetooth in general...
maybe you have some idea though ?

Readme typo

Readme says it was tested on a Rasperry Pi nano W. Surely you mean Raspberry Pi Zero W?

not compatible with python 3.11 ?

I'm trying this on Rasbian bookworm wiht python 3.11 and getting weird errors, i.e.

#~ python3 /opt/waveplus_bridge/waveplus_bridge.py --config /opt/waveplus_bridge/waveplus_bridge.yaml 293014466
Traceback (most recent call last):
  File "/opt/waveplus_bridge/waveplus_bridge.py", line 804, in <module>
    main()
  File "/opt/waveplus_bridge/waveplus_bridge.py", line 586, in main
    config = ReadConfiguration()
             ^^^^^^^^^^^^^^^^^^^
  File "/opt/waveplus_bridge/waveplus_bridge.py", line 83, in __init__
    self.read_yaml_config_file(config['config']).items():
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'items'

even though the basic function works, but it seems to ignore the --period setting ? 2-3 seconds instead of 10 ?


~# python3 /opt/waveplus_bridge/waveplus_bridge.py --period 10 2930144663 
2024-01-26 16:39:02 -      __main__[  DEBUG] - Available logger:
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger libs.logdb (WARNING)>
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger libs (WARNING)>
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger libs.threadedsendmail (WARNING)>
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger libs.performancecheck (WARNING)>
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger libs.waveplus (WARNING)>
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger libs.threadedmqttpublisher (WARNING)>
2024-01-26 16:39:02 -      __main__[  DEBUG] -    <Logger __main__ (DEBUG)>
2024-01-26 16:39:02 -      __main__[   INFO] - Setup WavePlus device access
2024-01-26 16:39:02 -      __main__[   INFO] -   Done
2024-01-26 16:39:02 -      __main__[   INFO] - Start main loop. Press ctrl+C to exit program!
2024-01-26 16:39:02 -      __main__[  DEBUG] - Reading sensor data for device 2930144663
2024-01-26 16:39:02 - libs.waveplus[WARNING] - Failed to communicate with device                                2930144663 (attempt 1 of 4): Device disconnected
2024-01-26 16:39:08 -      __main__[  DEBUG] -   -> {'humidity': 43.0, 'radon_st': 35, 'radon_lt': 66, 'temperature': 22.23, 'pressure': 997.32, 'co2': 1185.0, 'voc': 46.0, 'illuminance': 5, 'battery': 100}
2024-01-26 16:39:12 -      __main__[  DEBUG] - Reading sensor data for device 2930144663
2024-01-26 16:39:14 -      __main__[  DEBUG] -   -> {'humidity': 43.0, 'radon_st': 35, 'radon_lt': 66, 'temperature': 22.23, 'pressure': 997.32, 'co2': 1185.0, 'voc': 46.0, 'illuminance': 5, 'battery': 100}
2024-01-26 16:39:22 -      __main__[  DEBUG] - Reading sensor data for device 2930144663
2024-01-26 16:39:24 -      __main__[  DEBUG] -   -> {'humidity': 43.0, 'radon_st': 35, 'radon_lt': 66, 'temperature': 22.23, 'pressure': 997.32, 'co2': 1185.0, 'voc': 46.0, 'illuminance': 5, 'battery': 100}
2024-01-26 16:39:32 -      __main__[  DEBUG] - Reading sensor data for device 2930144663
2024-01-26 16:39:35 -      __main__[  DEBUG] -   -> {'humidity': 43.0, 'radon_st': 35, 'radon_lt': 66, 'temperature': 22.23, 'pressure': 997.32, 'co2': 1185.0, 'voc': 46.0, 'illuminance': 5, 'battery': 100}
2024-01-26 16:39:42 -      __main__[  DEBUG] - Reading sensor data for device 2930144663
2024-01-26 16:39:45 -      __main__[  DEBUG] -   -> {'humidity': 43.0, 'radon_st': 35, 'radon_lt': 66, 'temperature': 22.23, 'pressure': 997.32, 'co2': 1185.0, 'voc': 46.0, 'illuminance': 5, 'battery': 100}
^C2024-01-26 16:39:48 -      __main__[WARNING] - Interrupt/termination request detected
2024-01-26 16:39:48 -      __main__[   INFO] - WavePlus_bridge ended

The only thing I can think of, that makes a difference - would be the python version ?

Connection failed most of the time

Hello, I am testing the software and I've noticed that most of the time I get this error in the logs:
Failed to communicate with device <serial_number> / basement : Failed to connect to peripheral <MAC_Address>, addr type: public
sometimes the values are read and sometimes this error is displayed. What can be the cause?

battery always 100%

I've just realised that the script always reads the battery at 100%


connect to 2930144663
Initialize scanning/discovery
  Run scan
  Found device None
  Found device 2930144663
  Device 2930144663 found, MAC address=None
Control characteristics: Handle=16/16
  CCCD value (indication disabled): b'\x00\x00'
  CCCD value (indication enabled): b'\x02\x00'
Waiting on notificaiton
  Received notification (16): b'm\x00G^\x01\x00\x02O\x00\x82\x04 \x00\x00\x00\x00@L\x14\x00'
  Received notification (16): b'\x8e3\x08\x00p\x00L\x0b\t\x00'
Received data: b'm\x00G^\x01\x00\x02O\x00\x82\x04 \x00\x00\x00\x00@L\x14\x00\x8e3\x08\x00p\x00L\x0b\t\x00'
  -> s={'humidity': 44.0, 'radon_st': 45, 'radon_lt': 45, 'temperature': 21.09, 'pressure': 993.92, 'co2': 1151.0, 'voc': 97.0}, c={'illuminance': 79, 'battery': 100}
+------------+------------+------------+------------+------------+------------+------------+------------+------------+------------+
|  2930144663|        44.0|          45|          45|       21.09|      993.92|      1151.0|        97.0|          79|         100|
+------------+------------+------------+------------+------------+------------+------------+------------+------------+------------+
Reading sensor data for device 2930144663
Connect to 2930144663
Control data: Address=f4:60:77:6f:a9:fb, used cached data: b'm\x00G^\x01\x00\x02O\x00\x82\x04 \x00\x00\x00\x00@L\x14\x00\x8e3\x08\x00p\x00L\x0b\t\x00'
  -> s={'humidity': 44.0, 'radon_st': 45, 'radon_lt': 45, 'temperature': 21.09, 'pressure': 993.92, 'co2': 1151.0, 'voc': 97.0}, c={'illuminance': 79, 'battery': 100}
+------------+------------+------------+------------+------------+------------+------------+------------+------------+------------+
|  2930144663|        44.0|          45|          45|       21.09|      993.92|      1151.0|        97.0|          79|         100|
+------------+------------+------------+------------+------------+------------+------------+------------+------------+------------+
Reading sensor data for device 2930144663
Connect to 2930144663
Control data: Address=f4:60:77:6f:a9:fb, used cached data: b'm\x00G^\x01\x00\x02O\x00\x82\x04 \x00\x00\x00\x00@L\x14\x00\x8e3\x08\x00p\x00L\x0b\t\x00'
  -> s={'humidity': 44.0, 'radon_st': 45, 'radon_lt': 45, 'temperature': 21.09, 'pressure': 993.92, 'co2': 1151.0, 'voc': 97.0}, c={'illuminance': 79, 'battery': 100}
+------------+------------+------------+------------+------------+------------+------------+------------+------------+------------+
|  2930144663|        44.0|          45|          45|       21.09|      993.92|      1151.0|        97.0|          79|         100|
+------------+------------+------------+------------+------------+------------+------------+------------+------------+------------+

The Android App shows 89%.

Exception:MailAlerts: Error accessing radon_st

Looking through the logs I'm seeing the following error every time a record is pulled from a device:

2023-05-04 10:44:11 -      __main__[  DEBUG] - MailAlerts: Error accessing basement:radon_st: 'radon_st'
Traceback (most recent call last):
  File "/srv/waveplus_bridge/waveplus_bridge.py", line 448, in check_levels
    value = data[source[0]][source[1]]
KeyError: 'radon_st'
2023-05-04 10:44:11 -      __main__[  DEBUG] - MailAlerts: Error accessing basement:radon_st: 'radon_st'
Traceback (most recent call last):
  File "/srv/waveplus_bridge/waveplus_bridge.py", line 448, in check_levels
    value = data[source[0]][source[1]]
KeyError: 'radon_st'
2023-05-04 10:44:11 -      __main__[  ERROR] - Failed to trigger alerts: MailAlerts: Error accessing basement:radon_st: 'radon_st'
2023-05-04 10:44:11 -      __main__[  DEBUG] -   Stack trace:
Traceback (most recent call last):
  File "/srv/waveplus_bridge/waveplus_bridge.py", line 763, in main
    actions.check_levels(sensor_data_no_ts)
  File "/srv/waveplus_bridge/waveplus_bridge.py", line 455, in check_levels
    raise Exception(error_msg)
Exception: MailAlerts: Error accessing basement:radon_st: 'radon_st'

The "basement" device isn't being detected at the time so there is no record. I think what needs to be done is to skip calling "check_levels" when the connection to the device failed and there is no record.

It doesn't seem to disrupt the overall use of the software but it would be nice if these errors didn't get generated in this case.

I don't know the full impacts of this but I think just moving line 746-749 to before the except so that when there is no data it doesn't try to save or analyze it would be the thing. But I don't know this code that well. Maybe just add a check in the MailAlerts to exit quietly when there's no data to analyze.

Not able to read characteristic from Wave Plus

I am trying to access my new Wave Plus device over BLE from a Raspberry Pi using the waveplus_bridge_py application.

I am able to scan and find the device over BLE, but the application fails when reading the sensor data characteristic.
The waveplus.py attempt to read the characteristic UUID b42e2a68-.., but it fails.
And accessing the device using the nRF app from a phone shows that the device does not have such a UUID. It have some other (eg b42ebc9e-..), but they do not advertise with the READ property.

The device is also setup to use WiFi - and correctly sending data to your servers and my Airthings app.

Default configuration handling does not work correctly

If the Yaml configuration file does not contain one of the following keys, the application does not apply correctly the default values: period, data_retention, retries, retry_delay.

The application crash with the following error stack trace:

Traceback (most recent call last):
  File "<path>/WavePlus_Bridge/waveplus_bridge.py", line 694, in <module>
    config = ReadConfiguration()
  File "<path>/WavePlus_Bridge/waveplus_bridge.py", line 99, in __init__
    if config[key] is None:
KeyError: 'retries'

MQTT publish makes the WavePlus bridge hanging

Since the MQTT publishing feature has been added and enabled, the WavePlus bridge was hanging a few times. After disabling the feature again (in the YAML configuration file), this issue could not be observed anymore, which gives a high indication that the problem is related to the MQTT publishing feature.

Improve the MQTT interface: Use persistant connection, publish the timestamp, use the Homie library/specification

There are 3 improvements regarding the MQTT interface that have been originally proposed by @rkoshak:

The use of a persistent connection in combination with an LWT message
Publishing of the timestamp
Use the Homie library/specification

Failed to communicate with device

When I Run sudo /opt/waveplus_bridge/waveplus_bridge.py \ --config /opt/waveplus_bridge/waveplus_bridge.yaml \ --log ""
I get the Error: Failed to communicate with device ******
And Could not find device

Unable to setup the waveplus bridge as a service

In the discussion regarding ticket #9, @nasdim reported the following concern:

I am still not able to set it up as a service and isntead opted for running it using the .bashrc file. Here is a reference of how I did it: https://www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup/#amzn_assoc_ad_div_adunit_3.

Messages published to the LWT topic should be retained

I'm very happy to see the LWT topic being utilized. However, the messages are not retained. Consequently, if the subscribers and other MQTT clients who want to know if the WavePlus_Bridge is online or not needs to actively be online and subscribed to the status topic. If not, when they connect they won't know the current status.

https://github.com/rkoshak/sensorReporter/blob/main/mqtt/mqtt_conn.py#L106 shows how to configure the LWT message to be retained.

The fact that it publishes Online repeatedly helps as the client will know when it's Online, but it won't be certain that it's Offline if that's the case.

In truth, because you publish the update_time and everything is a sensor reading, it wouldn't be awful if all the messages published are retained. As a rule to thumb, I always set sensor readings and statuses to retained and commands as not retained. That way the clients don't have to wait minutes before they can start working. And if they care about how old the data is, they can check the timestamp.

This isn't a huge deal but it would make it work a little bit better on the client's side.

Publish sensor data to an MQTT server

Add the option to WavePlus_Bridge to publish sensor data on an MQTT server