Feature Request: Please add I2C support for the grove HM3301 Particulate Sensor.

[Teleportist]

Please add I2C support for the grove HM3301 Particulate Sensor.

Thanks.

[sfromis]

New sensor additions are usually the result of someone being "sufficiently interested" doing the coding, and submitting a PR to the open source project. Such contributions are very welcomed.

[barbudor]

And it's much more easy for people owning the sensor than for people who just having the datasheet

[barbudor]

I can't find any documentation on the I2C protocol.
There is a redacted datasheet on Seed's site with manufacturer name documenting only serial protocol.

[sfromis]

This Python code looks like an I2C driver for the sensor. Also.

[barbudor]

SeedStudio has a library and Arduino sample https://github.com/Seeed-Studio/Seeed_PM2_5_sensor_HM3301
I'm porting this to Tasmota as we speak
Should be ready to test by tonight

[Teleportist]

Thanks for the quick replies guys.

I’d have no idea on how to do the coding, but very happy and grateful to test this out and report back as required.

[barbudor]

@Teleportist Here is a test version of tasmota-sensors. Same as official with HM330X as I2CDriver63

After upgrade, be sure to assign I2C SCL and I2C SDA to a pair of GPIO.
I2CDriver63 must be enabled and drivers 1, 9, 14, 35, 45 must be disabled.

If if doesn't work as expected, please set WebLog 4 and restart with restart 1
Copy/paste the logs here.

Looking forward for your feedback

tasmota-hm330x.zip

[Teleportist]

Many thank Barbudor.

Will hopefully get a chance to do this tomorrow and report back.

[barbudor]

Hi @Teleportist, any feedback?

[Teleportist]

I've fallen at the first hurdle unfortunately. The ESP32 only seems to flash without failure when using the Web Installer. I've tried PyFlasher, ESP-Flasher and NodeMCU flasher in an attempt to install both the latest build and the binary barbudor kindly supplied.

Obviously the issue is that there seems to be no way to use the Web Installer to install barbudor's file. I also tried to install that as an upgrade to 9.5.0, which didn't work either.

[barbudor]

You didn't tell it was for ESP32. I provided you a esp8266 version
I'll compile an ESP32 version within the next ext hour
Then you can upgrade from the Web GUI from a standard version

[barbudor]

Here is a tasmota32 version
tasmota32-hm330x.zip

Did you tried Jason's ESP-Flasher ? did you tried to flash tasmota32.bin or tasmota.bin?
NodeMCU flasher is not for ESP2 AFAIK

[barbudor]

By the way, I have implemented a 30 second power-up delay as recommended by the datasheet
The data will be ignored for the first 30 seconds after a power-up or restart.
My comment about I2Cdriver as above are still valid

[Teleportist]

Thanks again Barbudor.

I've now upgraded using your file (v9.5.0.8 now reported in the web interface).
All seems to work well from startup, but I did notice that drivers 9 and 14 were still listed after disabling.
Albeit with a '!' prefix. Drivers 1, 35 and 45 were removed from the list fine.
RSL: RESULT = {"I2CDriver":"7,8,!9,10,11,12,13,!14,15,17,18,20,24,29,31,36,41,42,44,46,48,58,62,63"}
But as I say, works great. Most appreciate your work here Barbudor.

One issue I am left with, which I'm not sure if you can help with.

As the lifetime of the laser inside the sensor is rated at only ~2 years continuous use, I was planning to
sleep the sensor by pulling its 'set' pin low. I've achieved this fine by assigning GPIO 23 as Relay_i. Toggling
this on the sensor sleeps, confirmed by the fan stopping. However, toggling again (fan restarts) the ESP32
doesn't report any readings (unless restarted).

I've tried to resolve this by;

1. Setting GPIO 19 as Relay_i and connecting to the sensor's reset pin. Didn't solve.
2. Running 'I2Cscan' in the console to rescan the bus. Also didn't resolve.
   RSL: RESULT = {"I2CScan":"Device(s) found at 0x40"}
   I tried step 2 both before and after step 1.

Any suggestions gratefully received.
I'd like to avoid having to restart the sensor every time I bring it out of sleep mode, but if this is my only option...
Especially as I may try setting up the sleep/wake cycle as a rule, rather than driving it from Home Assistant over MQTT.

[barbudor]

Hi @Teleportist
I didn't forget about you 😁 but I have been busy with other stuff

Please find attached a new test version.
I have done some refactoring so first please test it in the default configuration with SET (and RESET) always active.
Data will be pulled from the sensor after a 30 seconds warmup like before.

If ok, then you can go to the next test: you can now define a GPIO as HM330X SET and connect it to the SET pin of the module
With this pin, the timings are now:

• GPIO (SET) is set HI at boot, start the warmup (30 sec)
• At end of warmup, starts pulling data from the sensor and feed the Web GUI
• At Teleperiod, SENSOR message is sent with latest data from the sensor
• Then, GPIO (SET) is set LOW to put the sensor in low power and stop the fan
• 33 seconds before the next Telemetry, GPIO SET is set HI and a new warmup sequence start
• 2..3 seconds before the next Telemetry, starts pulling data from the sensor
• At Teleperiod, SENSOR message is sent and cycle restart again

If Teleperiod is less than 33 seconds, the sensor is never put to sleep.

This seems working with simulation, hopefully it will work with the real device
The main difference with what you tried is that at the end of the warmup, I'm sending the I2C command that enables proper I2C mode (described at the beginning of Appendix 2 of the datasheet).

Let me know

tasmota32-hm330xV2.zip

[Teleportist]

Hi Barbudor,

I'm happy to report this works perfectly. You're a genius! Many thanks.

Just a couple of questions;

1. I plan to add a SGP30 (TVOC and CO2) sensor, which I see is already supported and thankfully uses a different address on the I2C bus.
   Will your modification effect the operation of this in any way? Presumably they'll share the same TelePeriod?

2. I've noticed the sensor reading disappear from the Web GUI when the sensor is sleeping. Any way to 'retain' the display of these until the next wake/update? No worries if not, as it's just minor. I suspect it's a standard feature of Tasmota, to denote a sensor isn't connected.

Many Thanks

[barbudor]

There is a single teleperiod and all sensors values will be reported in the same SENSOR message.
The operation of HM30X, with or without sleep mode will not impact the operation of SGP30.
I haven't yet looked at SGP30 and I don't know if it supports/requires such life-saving sleep mode. It is unlikely that you can use the same control signal because the SGP30 driver would probably be aware of sensor awakening to send some commands. This would need to be handled in his driver if this is needed.

The disappearing of the data from the web GUI is my choice in for this driver to avoid displaying outdated data.
This is indeed questionable and I can change that or even make it configurable (by compilation option or by setting).
For now, if this is your wish, I'll will display it all the time.
I will PR this tonight, should be in Tasmota soon (Theo will decide if the driver will part of standard build or requires an custom compile)

[Teleportist]

Great stuff, thank again Barbudor.

The SGP30 (index 18, driver xsns_21) doesn't require the life-saving sleep mode, as it's solid state. So no need for anything special.
So long as it'll communicate quite happily on the same I2C bus as the HM3301 with your new commands, without issue.

What about showing outdated data in red text in the GUI, so there's no confusion?

Look forward to seeing this appear in Tasmota.

[barbudor]

PR : #13250

Showing data in a different color is in line with current Tasmota graphic chart