Once more about PMS5003
Moderators: grovkillen, Stuntteam, TD-er
-
- Normal user
- Posts: 543
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Once more about PMS5003
Below are two screenshots of the ESP configuration containig PMS5003 dust sensor.
On the first screenshot (with a list of sensors) it is indicated that the connection of PMS looks like this:
TX - D8
RX - D7
In the second screenshot from the PMS configuration we have:
TX -> D7
RX -> D8
My physical existing connections are:
TX (PMS) - D8
RX (PMS) - D7
Are there sometimes TX/RX connections are swapped?
Of course, it would be simpler to swap TX/RX and check. But I need to climb a ladder and I'm afraid of space.
That's why I'm asking.
On the first screenshot (with a list of sensors) it is indicated that the connection of PMS looks like this:
TX - D8
RX - D7
In the second screenshot from the PMS configuration we have:
TX -> D7
RX -> D8
My physical existing connections are:
TX (PMS) - D8
RX (PMS) - D7
Are there sometimes TX/RX connections are swapped?
Of course, it would be simpler to swap TX/RX and check. But I need to climb a ladder and I'm afraid of space.
That's why I'm asking.
Re: Once more about PMS5003
Please have a look at the differences in notation:
Both imply the same, only describe it from a different perspective:
RX: GPIO-xx
GPIO-xx <-- TX
On the ESP side, you define a GPIO pin to act as a RX pin.
On the sensor side, you connect a TX pin to a GPIO pin on the ESP.
Both imply the same, only describe it from a different perspective:
RX: GPIO-xx
GPIO-xx <-- TX
On the ESP side, you define a GPIO pin to act as a RX pin.
On the sensor side, you connect a TX pin to a GPIO pin on the ESP.
-
- Normal user
- Posts: 543
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: Once more about PMS5003
Hmmm... That would mean the connection I'm using is swapped.
Physically existing connections are:
TX (PMS) - D8 (GPIO-15)
RX (PMS) - D7 (GPIO-13)
Please confirm this fact.
I did this sensor setup 4-5 years ago. Back then, there was no SET and RESET support yet, so I replaced it with a rule script.
Then I just changed the FW version and it worked properly until the version from March last year.
It stopped working using sources from March this year.
Strange that it worked at all.
I think I have to delete the current configuration of the sensor and define it again because the menu shows what it shows, but probably in FLASH the old configuration is remembered all the time.
And climb the ladder with the soldering iron and change the connections.
Are my conclusions about the need to swap connections correct?
Physically existing connections are:
TX (PMS) - D8 (GPIO-15)
RX (PMS) - D7 (GPIO-13)
Please confirm this fact.
I did this sensor setup 4-5 years ago. Back then, there was no SET and RESET support yet, so I replaced it with a rule script.
Then I just changed the FW version and it worked properly until the version from March last year.
It stopped working using sources from March this year.
Strange that it worked at all.
I think I have to delete the current configuration of the sensor and define it again because the menu shows what it shows, but probably in FLASH the old configuration is remembered all the time.
And climb the ladder with the soldering iron and change the connections.
Are my conclusions about the need to swap connections correct?
Re: Once more about PMS5003
I think that the old firmware was using SW serial.
The plugin stores the GPIO pins and it deducts from these pins which setting is used.
GPIO 15 and 13 -> Hardware Serial0 with swapped pins.
I assume you have used a PNP transistor on GPIO-15 to prevent it from locking up during boot?
Just to confirm the GPIO pin mapping: http://arduino.esp8266.com/Arduino/vers ... tml#serial
If I'm not mistaken, the current settings do also store the index of the selector, so you now can also select software serial and select the soldered pin configuration.
It shouldn't switch back to HW serial 0 swapped.
You may need to reboot as I don't think Serial0 will be swapped back automatically.
This may then cause conflicts as SW serial wants to use the same pins as HW serial.
The plugin stores the GPIO pins and it deducts from these pins which setting is used.
GPIO 15 and 13 -> Hardware Serial0 with swapped pins.
I assume you have used a PNP transistor on GPIO-15 to prevent it from locking up during boot?
Just to confirm the GPIO pin mapping: http://arduino.esp8266.com/Arduino/vers ... tml#serial
Thus GPIO-15 = TX and thus should be connected to RX on the sensor.Serial uses UART0, which is mapped to pins GPIO1 (TX) and GPIO3 (RX). Serial may be remapped to GPIO15 (TX) and GPIO13 (RX) by calling Serial.swap() after Serial.begin. Calling swap again maps UART0 back to GPIO1 and GPIO3.
If I'm not mistaken, the current settings do also store the index of the selector, so you now can also select software serial and select the soldered pin configuration.
It shouldn't switch back to HW serial 0 swapped.
You may need to reboot as I don't think Serial0 will be swapped back automatically.
This may then cause conflicts as SW serial wants to use the same pins as HW serial.
-
- Normal user
- Posts: 543
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: Once more about PMS5003
Now everything is clear to me. Thank you very much for the clear explanation.
So GPIO15 acts as RX - so it works with old FW.
So with new FW it is necessary to to add one.
Not good. I'll have to climb the ladder. With a soldering iron. So I wanted to avoid it.
Yes, for sure (as I remember)I think that the old firmware was using SW serial.
At this moment (with old software) - no. But everything seems to indicate that for the current FW version, TX/RX are swapped.I assume you have used a PNP transistor on GPIO-15 to prevent it from locking up during boot?
So GPIO15 acts as RX - so it works with old FW.
So with new FW it is necessary to to add one.
Not good. I'll have to climb the ladder. With a soldering iron. So I wanted to avoid it.

Re: Once more about PMS5003
Only if you can't configure Software Serial for the device. If you can, then you can configure the currently wired up pins as-is, and won't need the transistormackowiakp wrote: ↑21 Mar 2023, 10:01 So with new FW it is necessary to to add one.
Not good. I'll have to climb the ladder. With a soldering iron. So I wanted to avoid it.![]()

/Ton (PayPal.me)
-
- Normal user
- Posts: 543
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: Once more about PMS5003
No, because it is not possible to set GPIO-15 as ESP RX input.
But it is possible to set GPIO-15 as TX input of ESP
But it is possible to set GPIO-15 as TX input of ESP
Re: Once more about PMS5003
I just checked on an ESP8266 node and indeed you can't select GPIO-15 as RX pin as it is marked as "output only".
Problem with GPIO-15 is that it must have a specific state during boot or else the ESP may not boot anymore.
And if you configure it as an input pin, then it is quite likely people may use it as input pin.
Not sure whether I should make an override for such pin select protection.
I guess we can add a checkbox on the tools->Advanced page to disable those checks when offering select boxes.
But it should then be documented with a warning as you can create configurations which may even damage your system.
For example GPIO-12 on ESP32 should absolutely never be pulled high or low by something during boot as this may even fry the flash chip. The state of this pin on ESP32 during boot determines the flash voltage.
Problem with GPIO-15 is that it must have a specific state during boot or else the ESP may not boot anymore.
And if you configure it as an input pin, then it is quite likely people may use it as input pin.
Not sure whether I should make an override for such pin select protection.
I guess we can add a checkbox on the tools->Advanced page to disable those checks when offering select boxes.
But it should then be documented with a warning as you can create configurations which may even damage your system.
For example GPIO-12 on ESP32 should absolutely never be pulled high or low by something during boot as this may even fry the flash chip. The state of this pin on ESP32 during boot determines the flash voltage.
-
- Normal user
- Posts: 543
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: Once more about PMS5003
Yep, as I set 4 years ago software serial, ESP still use it.
Output from HW serial:
I wanted to use software serial (serial swap) to keep RX GPIO-3 (D9) and TX GPIO-1 (D10) pins free for possible debugging.
So I have these pins free.
It seems to me that the easiest way would be to connect the TX and RX cables from the PMS to the RX GPIO-3 (D9) and TX GPIO-1 (D10) in the ESP (HW Serial0).
No additional components are then needed.
All you need to do is set the speed of the serial port to 9600 bps in "Advanced" - according to the PMS specification.
And setting in the sensor definition, serial to "HW Serial0"
Output from HW serial:
Code: Select all
10105 : Info : WiFi : Scan finished, found: 6
10108 : Info : WiFi : Best AP candidate: maciek24 54:A0:50:CC:BF:02 Ch:8 (-64dBm) WPA/WPA2/PSK
10109 : Info : WiFi : Added known candidate, try to connect
10210 : Info : WIFI : Arduino wifi status: WL_IDLE_STATUS 0 ESPeasy internal wifi status: DISCONNECTED
10211 : Info : WIFI : Set WiFi to OFF
10325 : Info : INIT : Free RAM:25784
10357 : Info : PMSx003 : using software serial
10358 : Info : PMSx003: Wake sensor
10420 : Info : INFO : Plugins: 29 (ESP82xx Core 2843a5ac, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA )
So I have these pins free.
It seems to me that the easiest way would be to connect the TX and RX cables from the PMS to the RX GPIO-3 (D9) and TX GPIO-1 (D10) in the ESP (HW Serial0).
No additional components are then needed.
All you need to do is set the speed of the serial port to 9600 bps in "Advanced" - according to the PMS specification.
And setting in the sensor definition, serial to "HW Serial0"
Who is online
Users browsing this forum: Ahrefs [Bot] and 16 guests