[FR] PMSA003i support for P053 Dust - PMSx003 / PMSx003ST plugin

[Tyrant1919]

Is your feature request related to a problem? Please describe. I have a PMSA003i that is not listed as a supported model for the Dust - PMSx003 / PMSx003ST plugin. It does show up as an i2c device on 0x12, however I'm unable to select 0x12 as an i2c address for the sensor.

Describe the solution you'd like Would like to add full support for it and add it to list of supported devices for plugin. I believe it's largely the same as the other PMSx003 family, but I'm not 100% sure. Attempted to figure out how to add additional options for i2c addresses but it's beyond my skill level. I'd be able to send a unit to someone if they want to spend time (they can keep it). I'm also probably able to compile and test a firmware image if someone is able to add this new device and i2c address in a new branch. Think 0x12 is the only address it has.

Describe alternatives you've considered I currently have the PMSA003i plugged into an arduino and feeding data over serial to the Esp using taskvalueset. Works like a charm, just clunky. Can't think of a way to translate the 0x12 address to 0x48 for instance as one of the selectable addresses.

Additional context Add any other context or screenshots about the feature request here.

[tonhuisman]

Usually, the changed I2C address indicates there's a change in the protocol. Probably they have changed to data format to be in units of 16 bits instead of 8 bits (seen that with other, newer sensors too).

I'll have a look at how much effort it will be to integrate with the current plugin, or if we need to start a new plugin for this sensor.

[tonhuisman]

however I'm unable to select 0x12 as an i2c address for the sensor.

Biggest 'issue' is that P053 is a plugin that's using RS232-like serial communication with the PMSx003 sensors, and the PMSA003i only supports I2C communication. Currently, we don't have a way for plugins to change their 'type', or communication-nature, and there are no plans to add that. This implies we'll have to create a new plugin for this I2C sensor, as we can't include it in P053.

I've reserved P175 for a new plugin for this sensor.

[tonhuisman]

@Tyrant1919 You haven't mentioned with what type of ESP you want to use this sensor? I'm aiming for ESP32 flavor only, as for ESP8266 we're running out of room in the binaries in most builds. As an alternative you can create a Custom build that would include P175, to have it available for ESP8266 too.

[tonhuisman]

@Tyrant1919 I've created a PR to add support for this sensor. Downloads available from this GH Actions run. Can you please test?

NB: Only available in ESP32 Climate and MAX builds, for ESP8266 a Custom build can be made, or I'll create one on request if you don't have the opportunity to build it yourself. NB2: We won't be adding features/plugins to ESP8266 builds for build-size reasons. It's too much effort to make builds fit, for a platform that's deprecated by the manufacturer (Espressif).

Edit: Fixed Actions run link.

[Tyrant1919]

ESP32-C6 was what I'm testing. I have a 'plain' ESP32 as well. Will give it a shot tomorrow and let you know.

[Tyrant1919]

Shows up in i2c scan. Also notes P175 compatible. Added device. Getting a plethora of "PMSx003 : Checksum error" in the logs on all 4 of the possible output values available. Guessing 2nd option probably shouldn't work.

[tonhuisman]

Getting a plethora of "PMSx003 : Checksum error" in the logs

Hm, made a few slipups in reading the data & checksum, fixed that. New build available from this GH Actions run.

[Tyrant1919]

updated, set decimals to 0, kicked up some dust around the sensor and chefs kiss

[TD-er]

Ehh you can already access all collected data from the first task. I think having 2 tasks interacting with the same sensor may cause delays.

[Tyrant1919]

"Events for non-output values:" !!!! Nice, ok seeing everything in the logs now with one device. Best way to get extra values into a dummy device is through rules I'm thinking.

[Tyrant1919]

Everything with the sensor is working exactly as I'm expecting it to. There are a few checksum errors in the logs, maybe very roughly every 30 seconds. PMSx003 : Checksum error (0x19c expected: 0x1b2) Not an issue on my end, and if the data is bad we don't want it anyways.

Do have to breakout the rules since the non-output values aren't included in the "Single event with all values" option.

4222278: PMSx003: Oversampling using 2 samples 4222293: EVENT: PMSA003i#cnt0.3=99.0 4222297: ACT : TaskValueSet 16,1,99.0 4222311: taskValueSet: TaskValueSet 16,1,99.0 taskindex: 15 varNr: 0 result: 99.000000 type: 6 4222317: EVENT: PMSA003i#cnt0.5=40.5 4222323: ACT : TaskValueSet 16,2,40.5 4222336: taskValueSet: TaskValueSet 16,2,40.5 taskindex: 15 varNr: 1 result: 40.500000 type: 6 4222342: EVENT: PMSA003i#cnt1.0=0.0 4222348: ACT : TaskValueSet 16,3,0.0 4222352: taskValueSet: TaskValueSet 16,3,0.0 taskindex: 15 varNr: 2 result: 0.000000 type: 6 4222368: EVENT: PMSA003i#cnt2.5=0.0 4222376: ACT : TaskValueSet 17,1,0.0 4222379: taskValueSet: TaskValueSet 17,1,0.0 taskindex: 16 varNr: 0 result: 0.000000 type: 6 4222406: EVENT: PMSA003i#cnt5.0=0.0 4222415: ACT : TaskValueSet 17,2,0.0 4222429: taskValueSet: TaskValueSet 17,2,0.0 taskindex: 16 varNr: 1 result: 0.000000 type: 6 4222437: EVENT: PMSA003i#cnt10=0.0 4222447: ACT : TaskValueSet 17,3,0.0 4222450: taskValueSet: TaskValueSet 17,3,0.0 taskindex: 16 varNr: 2 result: 0.000000 type: 6 4222456: EVENT: PMSA003i#All=0.0,0.0,0.0

On PMSA003i#cnt0.3 do TaskValueSet 16,1,%eventvalue1% endon On PMSA003i#cnt0.5 do TaskValueSet 16,2,%eventvalue1% endon On PMSA003i#cnt1.0 do TaskValueSet 16,3,%eventvalue1% endon On PMSA003i#cnt2.5 do TaskValueSet 17,1,%eventvalue1% endon On PMSA003i#cnt5.0 do TaskValueSet 17,2,%eventvalue1% endon On PMSA003i#cnt10 do TaskValueSet 17,3,%eventvalue1% endon

[tonhuisman]

@Tyrant1919 I've made some optimizations in the code (mostly de-duplication, but had to do some small restructuring), available from this GH Actions run. Can you also test that build, to check if I didn't break anything? 🤔

[Tyrant1919]

Nothing broke. I don't see checksum errors in the logs anymore. That's a win.

I have a BME280 and an oled on the i2c as well. The oled display was garbled with the dust sensor connected. Forced the oled to slow and it fixed the garbled screen. I wasn't checking out the oled at all during this. I loaded the previous firmware to check and the issue was still there, I'm guessing some i2c don't like to mix with slow devices?

[TD-er]

How is the I2C wired? It should be wired as a 'bus' and not a 'star network'. Also most I2C devices put on boards already have some pull-up resistor present, so when you add multiple, you effectively reduce the effective pull-up resistance.

Not all I2C devices can pull as hard as needed when you have made your pull-up strength too strong. You could lower the I2C bus frequency.

Also the I2C total bus length should not be too long. Typically it should be less than a few decimeter.

[tonhuisman]

Nothing broke. I don't see checksum errors in the logs anymore. That's a win.

Great 😃

I have a BME280 and an oled on the i2c as well. The oled display was garbled with the dust sensor connected. Forced the oled to slow and it fixed the garbled screen. I wasn't checking out the oled at all during this. I loaded the previous firmware to check and the issue was still there, I'm guessing some i2c don't like to mix with slow devices?

When not having the PMS connected, the display should work fine at 400 kHz (Slow not checked), though some displays seem to need a better reset, but most of the OLeds don't have that available. A reboot or power-cycle sometimes fixes that, so it may be that's you're looking at a bad boot/reset sequence for the display, if the garbled display returns. The BME280 should work fine at the default (high) speed too.

Another possibility is that the combined I2C pull-up resistors are too much for the display, at that speed. You can check that by connecting only the display, or the display combined with the PMS. If it works in those situations, you can consider to use an I2C multiplexer (configuration on the Hardware tab), to connect each I2C device via it's own channel on the multiplexer, then they will all need to have their own (by default installed) pull-up resistors, as well as some pull-ups on the ESP - multiplexer connection.

[Tyrant1919]

Had it setup like this. Bottom power rails I have as my i2c bus. Makes sense might that it might need a multiplexer. I'll throw this in and see what happens.

I purchased the sensor from adafruit. It works on their breakout board as well as a generic breakout I got from elsewhere. Still working as expected.