Added support for particulate matters sensors #2571

ghost · 2016-07-20T10:19:27Z

Description: Adds support for serial-connected particulate matter sensors. See http://www.open-homeautomation.com/2016/07/19/measuring-air-quality/ on a bit more information about these sensors.

Related issue (if applicable): -

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#765

Example entry for configuration.yaml (if applicable):

sensor:
  platform: serial_pm
  serial_device: /dev/tty.SLAB_USBtoUART
  name: Nova
  brand: novafitness,sds011

Checklist:

If user exposed functionality or configuration variables are added/changed:

Documentation added/updated in home-assistant.io

If code communicates with devices, web services, or a:

Local tests with tox run successfully. Your PR cannot be merged unless tests pass
New dependencies have been added to the REQUIREMENTS variable (example).
New dependencies are only imported inside functions that use them (example).
New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
New files were added to .coveragerc.

If the code does not interact with devices:

Local tests with tox run successfully. Your PR cannot be merged unless tests pass
Tests have been added to verify that the new code works.

ghost · 2016-07-20T10:21:51Z

Please have a look at the source. It is for sensors like this:
http://www.open-homeautomation.com/2016/07/19/measuring-air-quality/

If this is ok in general, I will add the documentation.

balloob · 2016-07-20T20:14:11Z

I'm confused by the name. the name particulate matter is what it is measuring right?

The platforms should focus on a specific brand/model and be named after that. What would that be here ?

We also have a policy to not include device specific protocol code in our repo but instead depend on 3rd party lib for that. That way other people can use it too while not having to use Home Assistant. So could you move the interact with device code to an external lib?

balloob · 2016-07-20T20:15:58Z

particulate_matter.py

+        thread.daemon = True
+        thread.start()
+
+    def refresh(self):


Don't use this. Instead, Home Assistant will call update(…) on your device every 15 seconds, by throttling this call (using util.Throttle()) you can get to the required interval.

Oh I see now that this is not an entity. In that case you can have the entities call update() on this from entity.update() and still have apply the throttle to the PMDataCollector.update()

Letting each sensor call the update method is a bit problematic as they would read different data frames. This would result in inconsistent states (e.g. PM10 could be lower than PM2.5 when read from different data blocks). What is the recommended way to synchronise updates on multiple sensors?

use Throttle, it will take care of this for you. It will ensure that there is a cooldown of specified period in which calls to the method will not go through.

ghost · 2016-07-20T20:25:23Z

There are different sensors like this on the market. They all share a similar serial protocol (basically a block of data), but the start bytes, length of frame and position of the data are different. The idea was to have a generic driver that can be used for all these devices.
What would be a good approach to implement these? Having a different driver for each in Hass is a bit overkill in my opinion.

kellerza · 2016-07-20T20:59:55Z

What about calling it serial_dust_sensor or just dust_sensor?

Here in DustSensor.py is an example of an external module. Unfortunately this one requires a PI to control the ventilator, where it seems that you use the DTR pin, but if you use read_data() it might be possible to get around the PI requirement, since only measure() requires the Pi. You will just have to get a workaround for the DTR pin.

It imports Rpi.GPio, but homeassistant.components.rpi_gpio also uses it.

With this library you might be able to cover rpi and a normal serial implementation?

ghost · 2016-07-20T21:06:54Z

@kellerza If you like, we can call it dust, but basically dust is particulate matter ;-)
The linked library won't work as this is for sensors that sends pulses. The sensor here is a sensor that sends already processed data over a serial interface.
Update: I checked the source again. It really reads some data over the serial interface, but the protocol is different.

@balloob @kellerza I'm not sure if it would be better to create a generic "serial_sensor"? But the configuration for the user will become even more complicated than it already is.

ghost · 2016-07-20T21:12:49Z

What about "serial_pm_sensor"?

kellerza · 2016-07-20T21:43:41Z

dust just sounds so much cleaner... 😄

balloob · 2016-07-22T06:27:05Z

I like adding serial to the name. That way we leave room for other sensors.

About the config, would it be possible to name the models so that you put in your model and the platform knows which config settings it needs ?

ghost · 2016-07-22T16:48:30Z

ok, then I go for "serial_pm_sensor".

Adding configurations for a few sensors I can test is possible. I would recommend to have the option to configure everything by the user or use a pre-defined configuration (like "oneair" for the Oneair sensor I'm using right now). I will look into this in the next days.

balloob · 2016-07-23T20:54:01Z

Okay, so there is a brand: oneair. I suggest we rename the platform oneair. That is exactly in line with all the other platforms in Home Assistant: named after the brand/product.

Since you will have to extract the logic for communication into a standalone lib, it will be possible to have multiple platforms (one for each brand/product) reference the same lib. The code will still be shared but we follow the Home Assistant naming pattern.

ghost · 2016-07-24T08:40:30Z

Even with extracting the logic into a separate lib, supporting these sensors from different vendors would mean duplicating a lot of code.
It is possible to support multiple platforms with a single module in home assistant? Otherwise we would end up with 5-10 modules, that are basically the same except for the platform name. I don't think this would be the is the right way to implement it.
I think it should be similar to the MQTT platform, which isn't about a brand or product, but a communications protocol. Same here. There is a basic communication protocol, but the parameters are configurable.

balloob · 2016-07-26T06:20:01Z

I see your point, but in that case I would love to see the platform named after the name of the protocol. If that's not available, I guess serial_pm_sensor could work. Although, that would add the word sensor twice (it being a sensor platform). I'm fine with either serial_pm or particulate_matter_serial.

With all the logic be put in a standalone lib (including brand specific configs), the final config could look something like this:

sensor:
  platform: serial_pm  # <- or whatever is decided
  brand: oneair

ghost · 2016-07-26T06:26:01Z

Ok, makes sense. I will go this route. As I'm still waiting for 2 other sensors to arrive, it will take some time until I will finish this.

balloob · 2016-07-26T06:29:22Z

Alright. No problem.

You could create a standalone lib that just supports the oneair sensor 👍

ghost · 2016-07-29T15:13:39Z

Ok, all sensor functionality including definition of the data formats have been moved to the pmsensor library.
Now, you only have to define a the brand and the serial interface name.
It has been tested with 4 different sensors now :-)

ghost · 2016-08-03T05:39:27Z

Any comments on this? The code should be ready now.

kellerza · 2016-08-03T10:41:45Z

homeassistant/components/sensor/serial_pm.py

+                                  pm.SUPPORTED_SENSORS[config.get(CONF_BRAND)])
+    except KeyError:
+        _LOGGER.error("Brand %s not supported", config.get(CONF_BRAND))
+        _LOGGER.error(" supported brands: %s", pm.SUPPORTED_SENSORS)


Maybe combine this into a single .error() and remember to return

Ok, I can do this.

- Additional exception handling

ghost · 2016-08-07T18:41:20Z

The SCAN_INTERVAL code has been removed now. The code should be ready now.

kellerza · 2016-08-07T18:50:23Z

Almost. Are you sure you can still add a SCAN_INTERVAL in the config with your current schema?

You might have to change your schema to:

PLATFORM_SCHEMA = homeassistant.components.sensor.PLATFORM_SCHEMA.extend({

ghost · 2016-08-07T20:11:52Z

Derived config from sensor.PLATFORM_SCHEMA

kellerza · 2016-08-07T20:13:14Z

Looks good & thanks for you patience! 🐬

ghost · 2016-08-07T20:14:58Z

Thanks you for the support.

Added support for particulate matters sensors

0a38d07

Bugfix: .coveragerc

ac3c61e

balloob reviewed Jul 20, 2016
View reviewed changes

Daniel Matuschek added 2 commits July 29, 2016 16:04

Add support for serial particulate matter sensors

16550eb

old code not needed anymore

63c6ec2

Bugfixed for failed tests

50230a2

kellerza reviewed Aug 3, 2016
View reviewed changes

growers12 and others added 4 commits August 3, 2016 15:44

- Polling interval fixes

ccb0971

- Additional exception handling

Removed debug code

0fefc1d

Bugfix global variable

6b39a24

Removed scan interval code

4b1911a

Use default schema as configuration base

7f35c39

kellerza merged commit a3ca3e8 into home-assistant:dev Aug 7, 2016

home-assistant locked and limited conversation to collaborators Mar 17, 2017

ghost deleted the pm-sensor branch July 20, 2017 11:53

Uh oh!

Added support for particulate matters sensors #2571

Added support for particulate matters sensors #2571

Uh oh!

Conversation

ghost commented Jul 20, 2016 • edited by fabaff Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Jul 20, 2016 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

balloob commented Jul 20, 2016

Uh oh!

balloob Jul 20, 2016

Choose a reason for hiding this comment

Uh oh!

balloob Jul 20, 2016

Choose a reason for hiding this comment

Uh oh!

ghost Jul 20, 2016

Choose a reason for hiding this comment

Uh oh!

balloob Jul 22, 2016

Choose a reason for hiding this comment

Uh oh!

ghost commented Jul 20, 2016

Uh oh!

kellerza commented Jul 20, 2016

Uh oh!

ghost commented Jul 20, 2016 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Jul 20, 2016

Uh oh!

kellerza commented Jul 20, 2016

Uh oh!

balloob commented Jul 22, 2016

Uh oh!

ghost commented Jul 22, 2016

Uh oh!

balloob commented Jul 23, 2016

Uh oh!

ghost commented Jul 24, 2016

Uh oh!

balloob commented Jul 26, 2016

Uh oh!

ghost commented Jul 26, 2016

Uh oh!

balloob commented Jul 26, 2016

Uh oh!

ghost commented Jul 29, 2016 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Aug 3, 2016

Uh oh!

kellerza Aug 3, 2016

Choose a reason for hiding this comment

Uh oh!

ghost Aug 3, 2016

Choose a reason for hiding this comment

Uh oh!

ghost commented Aug 7, 2016

Uh oh!

kellerza commented Aug 7, 2016

Uh oh!

ghost commented Aug 7, 2016

Uh oh!

kellerza commented Aug 7, 2016

Uh oh!

ghost commented Aug 7, 2016

Uh oh!

Uh oh!

ghost commented Jul 20, 2016 •

edited by fabaff

Loading

ghost commented Jul 20, 2016 •

edited by ghost

Loading

ghost commented Jul 20, 2016 •

edited by ghost

Loading

ghost commented Jul 29, 2016 •

edited by ghost

Loading