Espeasy: Problems with the _P053_PMSx003 Dust Plugin
Hello everybody,
I have some devices with the dust sensor PMS7003 and some with the SDS021.
The devices with the SDS021 run smoothly for weeks.
Those with the PMS7003 only make a few measurements and then hang. The dust levels are no longer updated.
After a reset or disconnection of the voltage, the values are updated only a couple of times, then nothing comes up.
The rest of the measurements, such as BME280 BH1750, continue.
micropet
All 78 comments
I don't know the PMSx003 sensor. Do you need to write to it to get the
data? (GPIO => RX)
If so, then you'll probably want to try other pins for this device.
Does the other setup, with the SDS0x1 sensor also have another serial
device like the CO2 sensor?
Perhaps using 2 serial devices can cause issues?
The SDS011 I use has an uptime of 52 days and is running fine (in freezing
temperatures) so that one is indeed stable :)
Verzonden vanaf laptop
On 21 February 2018 at 09:46, micropet notifications@github.com wrote:
Hello everybody,
I have some devices with the dust sensor PMS7003 and some with the SDS021.The devices with the SDS021 run smoothly for weeks.
Those with the PMS7003 only make a few measurements and then hang. The
dust levels are no longer updated.After a reset or disconnection of the voltage, the values are updated only
a couple of times, then nothing comes up.The rest of the measurements, such as BME280 BH1750, continue.
[image: device_4]
https://user-images.githubusercontent.com/2838584/36470671-fe9aa8e0-16eb-11e8-92fe-9feddcc3d5f4.png
[image: device_page_1]
https://user-images.githubusercontent.com/2838584/36470672-feb4900c-16eb-11e8-95e5-79026b48f820.png—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/914, or mute the thread
https://github.com/notifications/unsubscribe-auth/ADk9ljlPVUnmHKcrYQ7iCgp-7xXzxE2yks5tW9fogaJpZM4SNQbs
.
TD-er
on 21 Feb 2018
The device with the SDS also has a MH-Z19 CO2 sensor.
I think the PMS sends the data by itself.
The connections I would not like to change.
micropet
on 21 Feb 2018
Have you also tried another power supply and other cable to power the node?
These sensors may peak in current use and it may be just enough to let the voltage drop too much when both the CO2 and the dust sensor peak at the same time.
A lot of USB cables often have quite some resistance, which will result in voltage drop at higher currents.
TD-er
on 21 Feb 2018
Yes, I know that with the cables. There are a lot of high-impedance cables on the market.
I had the power supply and the cable changed this morning.
I have set paralell to the 5V a 2800μF capacitor. This has been enough for all devices so far.
The PMS has then sent his values twice and is frozen again.
But it must be due to the software, with Tasmota it runs perfectly.
micropet
on 21 Feb 2018
I've looked into the source and it looks very likely to give exactly the issues you mention.
I will fix it, although I have not (yet) such a sensor to test myself.
The problem with this implementation is that the reader (ESPboard) can get out of sync with the writer (sensor) and can't get into sync anymore (not within a few hours, perhaps never)
Apart from that, the implementation is made overly complicated to support the hardware serial, which is a great idea, but at the wrong place.
TD-er
on 25 Feb 2018
The PMS is already connected via software serial.
What does your answer mean? Cant we do anything?
Then you should remove the plugin.
I will buy a SDS021 that works in other devices.
And for the PMS I will use Tasmota.
micropet
on 25 Feb 2018
What I meant is, I will try to fix it in ESPeasy.
All plugins in the releases should work and if not, we should make them work.
Simple as that.
So thanks for your report, I will have a look at it.
TD-er
on 25 Feb 2018
That is a word!
micropet
on 25 Feb 2018
@TD-er I have got PMS sensor, maybe can help here
Where do You think problem is?
uzi18
on 25 Feb 2018
@uzi18
You will get a version to test later this week.
Do you also experience similar issues?
TD-er
on 25 Feb 2018
My sensor were never used before but this is a time ;)
uzi18
on 25 Feb 2018
It is PMS3003
uzi18
on 25 Feb 2018
See Pull Request #976
@micropet and/or @uzi18 Can you test it to see if it is now more stable.
I don't have such a sensor yet, so I cannot test it.
TD-er
on 28 Feb 2018
Good morning Gijs,
you are awake early!
The plugin has already failed after two measurements.
Now it has been running for 15 minutes with some Errors in the Logfile.
504669: PMSx003: invalid framelength - 142
506220: MHZ19: Raw PPM: 905 Filtered PPM value: 1043 Temp / S / U values: 23/0 / 0.00
506224: EVENT: MH-Z19 # PPM = 1093.00
506366: ACT: NeoPixelAll, 50,70,0,0
506492: EVENT: MH-Z19 # MHZ19Temp = 22.20
506721: EVENT: MH-Z19 # U = 0.00
515541: WD: Uptime 9 ConnectFailures 0 FreeMem 13104
528697: EVENT: PMS7003 # pm1.0 = 5.00
528971: EVENT: PMS7003 # pm2.5 = 8.00
529217: EVENT: PMS7003 # pm10 = 14.00
....
564627: PMSx003: invalid framelength - 32772
567203: MHZ19: Raw PPM: 917 Filtered PPM value: 1053 Temp / S / U values: 23/0 / 0.00
567207: EVENT: MH-Z19 # PPM = 1103.00
567348: ACT: NeoPixelAll, 50,70,0,0
567444: EVENT: MH-Z19 # MHZ19Temp = 22.20
567672: EVENT: MH-Z19 # U = 0.00
575544: WD: Uptime 10 ConnectFailures 0 FreeMem 13088
589198: EVENT: PMS7003 # pm1.0 = 3.00
589444: EVENT: PMS7003 # pm2.5 = 7.00
589717: EVENT: PMS7003 # pm10 = 8.00
597648: MHZ19: Raw PPM: 920 Filtered PPM value: 1058 Temp / S / U values: 23/0 / 0.00
597652: EVENT: MH-Z19 # PPM = 1108.00
......
742633: EVENT: PMS7003 # pm1.0 = 3.00
742881: EVENT: PMS7003 # pm2.5 = 8.00
743125: EVENT: PMS7003 # pm10 = 10.00
743662: EVENT: Clock # Time = Wed, 06: 04
748652: PMSx003: invalid framelength - 142
edit:
Looks good. Runs for 30 minutes.
micropet
on 28 Feb 2018
Those errors are not that bad, as long as it can keep sync. Or at least regain sync.
And I was nerding late, it is now 8am here.
TD-er
on 28 Feb 2018
If it has just failed, no values are displayed anymore.
It ran for over three hours.
There is no entry from the dust sensor in the logfile.
micropet
on 28 Feb 2018
It is almost perfect now with @TD-er fix.
My idea is to not do anything unnecessary, it is only related to overhead.
uzi18
on 28 Feb 2018
It only runs for a few hours. That's not enough.
micropet
on 28 Feb 2018
Code is better it must be ok.
I think you have got some connection problems sometimes, now it will auto sync.
uzi18
on 28 Feb 2018
I have no connection problems.
The device ran for weeks under Tasmota without failing once.
micropet
on 28 Feb 2018
@micropet Can you show the last output of the sensor (log output)?
And also try to see if that specific ESP module is showing some accurate uptime (disable NTP for this test)
I will add the extra check on the dummy parameter. Maybe you have some valid value in the stream that has the same byte value as the first byte in the sequence and then you'll never get a valid output anymore.
So test the 'dummy' value as suggested and then stop reading if it is not matching the start sequence.
TD-er
on 28 Feb 2018
Is that correct that the log file is only so short? Or is there a "full" version of it?
micropet
on 28 Feb 2018
You can try to send it to a logserver.
But in one of the releases someone reported issues with that. Still have to look into that.
TD-er
on 28 Feb 2018
OK, then I'm waiting for the version with the extra check on the dummy parameter.
micropet
on 28 Feb 2018
Did you check with this morning's build?
TD-er
on 3 Mar 2018
Yes I have. I download the source as soon as I discover something new.
It still does not work. It runs for a few minutes and then it stops.
I had platformio installed yesterday and flashed with it. But no difference.
I think we have to wait until you get your PMS.
Peter
micropet
on 4 Mar 2018
That may take some time...
Departed country of origin
2018-03-02 23:30:00 [GMT+8]
TD-er
on 4 Mar 2018
I order every few days something in China and get every 2 to 3 days a small letter. It is always a surprise to open the letter. :)
Time passes faster than you think.
micropet
on 4 Mar 2018
Any updates on this?
m-anish
on 26 Jun 2018
No, it still does not work.
The measurement runs for a few minutes, then freezes.
micropet
on 26 Jun 2018
Last weekend I found an issue which affects "realtime" performance needed for processing this data stream.
I hope issues like these will also be fixed when that issue is resolved.
I am a little short on time today, but my hope is that I have time to fix that issue Wednesday or Thursday evening and then we can also test this one.
TD-er
on 26 Jun 2018
Yes, great Gijs,
I still have some devices with the PMS, they are currently sleeping.
micropet
on 26 Jun 2018
Any updates on this?
m-anish
on 26 Jun 2018
@m-anish Please read 2 comments above.
TD-er
on 26 Jun 2018
Hi, i'm using PMS sensor, but i'm having the same problem
I dont know if the sensor is bad or somehitng in my code is wrong
some times i get reads but suddenly, it stops sending data.
I'm working with de lubrary node-plantower, but i'm having the same problem.
help!!!!
please.
X3sar
on 7 Jul 2018
The Sensos is definitely fine.
I have the same problem for months.
TD-er wanted to take care of it
micropet
on 8 Jul 2018
@TD-er please provide more info about issue you found, thx
uzi18
on 8 Jul 2018
@uzi18 Last week I had very little time to work on this, so more delay than I hoped for.
What I found was this:
There were some parts in the code using way too much time for themselves. This resulted in the 50/sec and 10/sec tasks to get way less runs than expected.
Sometimes routines even needed > 1 second to finish, which results in 0 calls to those time critical routines.
This can lead to simply missing bursts of data, which is typical for this sensor.
Second issue is that the software-serial appears to have some issues handling interrupts in due time. (see discussion on forum regarding Nextion display)
This last part should not really be an issue. Just wait for the next burst of data and you're back in sync again. But of the 1/50th and 1/10th calls are not processed, it is very difficult to get in sync again.
Also the burst of this sensor is close to the used buffer size, which makes it near impossible to find the sync again.
I have already fixed a number of routines taking a lot of time.
You can also run the last build to see the time-statistics logging (each 30 second, only visible in the serial log) to see what function takes how much time.
There should be no function using > 20 msec per run. Occasional is not an issue, but average is bad.
Currently there is no logging yet on the controllers, but my guess is there are some taking way more time than desired. So I will add those as well.
Yet to do:
Have a second look at the routine to regain a sync on the data, but now taking into account there may be some bitflips due to the mentioned interrupt issues on software serial.
TD-er
on 8 Jul 2018
23117235 : LoopStats: shortestLoop: 46 longestLoop: 1058298 avgLoopDuration: 88.41 systemTimerDuration: 25.19 systemTimerCalls: 31 loopCounterMax: 652173 loopCounterLast: 330765 countFindPluginId: 0
On a wemos without hardware.
micropet
on 8 Jul 2018
Please increase your loglevel a bit.
There should be more time statistics.
TD-er
on 8 Jul 2018
OK. Here is a part with a PCA9685.
Clock # Time takes 22 ms and the rules 200 ms.
70712866 : PluginStats P_22_Extra IO - PCA9685 WRITE Count: 10 Avg/min/max 441.50/363/796 usec
70712876 : PluginStats P_22_Extra IO - PCA9685 FIFTY_PER_SECOND Count: 1491 Avg/min/max 15.30/10/43 usec
70712885 : Plugin call 50 p/s stats: Count: 1491 Avg/min/max 587.23/508/913 usec
70712893 : Plugin call 10 p/s stats: Count: 300 Avg/min/max 559.54/500/879 usec
70712900 : Plugin call 10 p/s U stats: Count: 300 Avg/min/max 3565.16/3297/4033 usec
70712907 : Plugin call 1 p/s stats: Count: 30 Avg/min/max 9431.93/1659/202361 usec
70712915 : checkSensors() stats: Count: 30 Avg/min/max 840.90/602/2236 usec
70712922 : WD : Uptime 1178 ConnectFailures 2 FreeMem 13424
70742923 : LoopStats: shortestLoop: 46 longestLoop: 1058298 avgLoopDuration: 89.73 systemTimerDuration: 25.16 systemTimerCalls: 31 loopCounterMax: 652173 loopCounterLast: 326870 countFindPluginId: 0
70742930 : PluginStats P_22_Extra IO - PCA9685 ONCE_A_SECOND Count: 30 Avg/min/max 16.47/14/30 usec
70742939 : PluginStats P_22_Extra IO - PCA9685 TEN_PER_SECOND Count: 301 Avg/min/max 11.07/3/34 usec
70742948 : PluginStats P_22_Extra IO - PCA9685 FIFTY_PER_SECOND Count: 1500 Avg/min/max 15.90/10/46 usec
70742957 : Plugin call 50 p/s stats: Count: 1500 Avg/min/max 592.04/504/903 usec
70742965 : Plugin call 10 p/s stats: Count: 301 Avg/min/max 524.72/500/840 usec
70742972 : Plugin call 10 p/s U stats: Count: 301 Avg/min/max 3570.82/3275/4024 usec
70742979 : Plugin call 1 p/s stats: Count: 30 Avg/min/max 1848.23/1778/2090 usec
70742987 : checkSensors() stats: Count: 30 Avg/min/max 667.87/645/783 usec
70742994 : WD : Uptime 1179 ConnectFailures 2 FreeMem 13424
70751684 : EVENT: Clock#Time=Mon,07:37
70751705 : EVENT: Clock#Time=Mon,07:37 Processing time:22 milliSeconds
70768683 : EVENT: Rules#Timer=1
70768696 : ACT : Publish ESP-218/IP,192.168.0.218
70768708 : Command: publish
70768714 : ACT : Publish ESP-218/MAC,68:C6:3A:A5:FB:B5
70768727 : Command: publish
70768733 : ACT : Publish ESP-218/Time,07:37:17
70768745 : Command: publish
70768751 : ACT : Publish ESP-218/Uptime,1179
70768763 : Command: publish
70768770 : ACT : Publish ESP-218/RSSI,-71
70768781 : Command: publish
70768787 : ACT : Publish ESP-218/SSID,SMC
70768799 : Command: publish
70768806 : ACT : Publish ESP-218/BSSID,78:8A:20:D1:9B:D9
70768818 : Command: publish
70768824 : ACT : Publish ESP-218/CH,1
70768836 : Command: publish
70768842 : ACT : Publish ESP-218/SYSHEAP,11656
70768855 : Command: publish
70768859 : ACT : timerSet,1,60
70768871 : Command: timerset
70768884 : EVENT: Rules#Timer=1 Processing time:200 milliSeconds
70772995 : LoopStats: shortestLoop: 46 longestLoop: 1058298 avgLoopDuration: 90.23 systemTimerDuration: 25.35 systemTimerCalls: 31 loopCounterMax: 652173 loopCounterLast: 324928 countFindPluginId: 0
70773002 : PluginStats P_22_Extra IO - PCA9685 READ Count: 1 Avg/min/max 15.00/15/15 usec
70773011 : PluginStats P_22_Extra IO - PCA9685 ONCE_A_SECOND Count: 30 Avg/min/max 15.87/11/27 usec
70773020 : PluginStats P_22_Extra IO - PCA9685 TEN_PER_SECOND Count: 300 Avg/min/max 12.05/3/38 usec
70773029 : PluginStats P_22_Extra IO - PCA9685 WRITE Count: 10 Avg/min/max 453.00/387/796 usec
70773039 : PluginStats P_22_Extra IO - PCA9685 FIFTY_PER_SECOND Count: 1489 Avg/min/max 15.60/10/46 usec
70773048 : Plugin call 50 p/s stats: Count: 1489 Avg/min/max 587.28/504/922 usec
70773056 : Plugin call 10 p/s stats: Count: 300 Avg/min/max 538.97/500/857 usec
70773063 : Plugin call 10 p/s U stats: Count: 300 Avg/min/max 3551.89/3204/3978 usec
70773070 : Plugin call 1 p/s stats: Count: 30 Avg/min/max 9547.20/1782/203298 usec
70773078 : checkSensors() stats: Count: 30 Avg/min/max 882.50/637/2346 usec
70773085 : WD : Uptime 1179 ConnectFailures 2 FreeMem 13424
70803086 : LoopStats: shortestLoop: 46 longestLoop: 1058298 avgLoopDuration: 89.71 systemTimerDuration: 25.16 systemTimerCalls: 31 loopCounterMax: 652173 loopCounterLast: 326935 countFindPluginId: 0
70803093 : PluginStats P_22_Extra IO - PCA9685 ONCE_A_SECOND Count: 30 Avg/min/max 11.53/10/23 usec
70803102 : PluginStats P_22_Extra IO - PCA9685 TEN_PER_SECOND Count: 301 Avg/min/max 14.98/3/39 usec
70803111 : PluginStats P_22_Extra IO - PCA9685 FIFTY_PER_SECOND Count: 1500 Avg/min/max 15.33/10/39 usec
70803120 : Plugin call 50 p/s stats: Count: 1500 Avg/min/max 586.89/504/879 usec
70803128 : Plugin call 10 p/s stats: Count: 301 Avg/min/max 572.03/499/867 usec
70803135 : Plugin call 10 p/s U stats: Count: 301 Avg/min/max 3564.61/3261/3997 usec
70803142 : Plugin call 1 p/s stats: Count: 30 Avg/min/max 1728.70/1655/1936 usec
70803150 : checkSensors() stats: Count: 30 Avg/min/max 617.63/602/717 usec
70803157 : WD : Uptime 1180 ConnectFailures 2 FreeMem 13424
70811683 : EVENT: Clock#Time=Mon,07:38
70811705 : EVENT: Clock#Time=Mon,07:38 Processing time:22 milliSeconds
Maybe I should open another issue for the timing issues.
Just to get things a bit organized.
TD-er
on 9 Jul 2018
micropet
on 9 Jul 2018
I had hoped that the many changes in the past time the PMSx003 plugin could be positively affected.
But it still does not work. After booting, a value is read once or twice, then it does not work anymore.
micropet
on 23 Jul 2018
@micropet
Just to give you a heads-up.
I have been thinking about this issue quite a bit and this evening I started to make a "braindump" of this idea I have to fix this.
See my initial commit: https://github.com/TD-er/ESPEasy/commit/5309396bd0eb493ebe0a27fdabb7b47d857355b7
It is not even compiled yet, just a dump of my ideas, so it is still pre-pre-alpha state :)
In short, this plugin will be more than halved in the end, regarding the number of lines.
Also it will only call proces() in the 50/sec call and when a packet is available, it will start processing it.
Those are all non-blocking and it will never loose track of finding the packet start, since every attempt to find the packet will look into the buffer to see if there is a full packet. The whole packet can be inspected for this, not only a peek at the next byte.
Also, it will implement a double-buffer system. One in the software serial and one in this reader.
If this will not solve the issue, then we are having a hardware issue, which means the bits are damaged between sensor and ESP.
TD-er
on 24 Jul 2018
@ TD-er
that sounds good and complicated. :) If you have something to try say it.
Although I am 100 km away from home, I have RDP access to my computers.
I do not believe in a hardware problem. I tried it on several devices. Every morning, if there is a new version I test it briefly.
If I flash the original examples of the PMSx003, then it runs perfectly for several weeks.
micropet
on 24 Jul 2018
That's a good reason why it should be considered a software issue :)
Tonight and tomorrow I don't have much time, but I will continue on that serial reader, since I am convinced it is the way to serialize (pun intended) the jobs in a non-blocking way and leave the hard part in a single set of code and make plugins much simpler.
TD-er
on 24 Jul 2018
If rewriting the PMSx003 plugin that much, how's about considering #487 ?
A plugin that reduces the lifetime of the PMS to less then one year does not make much sense.
Due to datasheet the PMSx003 have a lifetime of around 8000h, so permanently driven it will run for 333 days. The laser diode has a limited lifetime so after this period the values will get unreliable.
I've made a crude ruleset to pull it offline and just let it run every 30 seconds. This should be implemented within the plugin.
The sensor can be set to sleep by pulling the "SET" pin to low. I suggest to use the "Delay" field and process some steps:
- Wake the sensor (put "SET" to high),
- wait some seconds to get new values,
- read sensor values and put it back to sleep for [delay] seconds (put pin "SET" to low)
ShardanX
on 27 Jul 2018
Maybe it should be mentioned:
Some changes seem to make the plugin more unstable.
I've two sensors with PMS7003 running on v2.0-20180209.
The only issue I see is that they reboot every some days. Not nice, but doesn't affect me much as they return to work silently. Values are read permanently evetry 30 sec. without stopping:
ShardanX
on 27 Jul 2018
Can you see the last reboot reason?
I added a more descriptive text in the webinterface a few weeks ago.
TD-er
on 27 Jul 2018
I'm using a ESPEasy version from february so i can't, sadly. The System info says "manual reboot" - which is obviously wrong.
I'm using timing rules to put the sensor to sleep - this might be the reason why reading does not stop for me.
on System#Boot do
gpio,16,0
timerSet,1,20
endon
On Rules#Timer=1 do
LongPulse,16,1,5
timerSet,1,20
endon
GPIO 16 connected to the "SET" pin at the PMS is used to push the sensor into sleep mode.
On system boot the pin is set to 0 (low), sensor sleeps.
Timer 1 is set to run for 20 seconds, then trigger a 5 sec pulse on GPIO 16.
Timer 1 is set again to 20 seconds so it loops the sensor pulse.
ShardanX
on 27 Jul 2018
FYI, maybe it's useful:
I'm running a PMS7003 with almost all recent mega-builds and don't experience issues with stability. I'm running on a Wemos Mini D1 in combination with BME280 and BH1750. Maybe relevant is I'm not updating the device to main controller via the Device Setting but via rules:
on System#Boot do
gpio,14,0
timerSet,1,50
endon
On Rules#Timer=1 do
Longpulse,14,1,30
timerSet,1,300
timerSet,2,28
endon
On Rules#Timer=2 do
Publish %sysname%/PMS7003/pm1.0, [PMS7003#PM1.0]
Publish %sysname%/PMS7003/pm2.5, [PMS7003#PM2.5]
Publish %sysname%/PMS7003/pm10, [PMS7003#PM10]
endon
blb4github
on 27 Aug 2018
Hmm, that's something that will also be resolved when this PR is finished.
TD-er
on 27 Aug 2018
An interesting approach.
I have not got my PMS running since last year.
After a restart, only one measurement is executed. Then nothing happens anymore.
What does your device page look like?
Thats mine:
micropet
on 30 Aug 2018
My device page attached. to get the PMS7003 in sleep you need to connect the Reset Pin, see https://www.letscontrolit.com/wiki/index.php/PMSx003
blb4github
on 30 Aug 2018
OK, thank you. I do not use Sleepmode.
micropet
on 30 Aug 2018
Hi,
I am bit struggling with getting the 5003 sensor to sleep - I've been experimenting with rules and followed tutorials above, but sensor seems to be active all time and data is read according to sensor delay setting no matter the GPIO16 set high or low. The fan is also working right from the boot (I can hear it) although the GPIO16 is set to low on boot. Do you have any idea what the problem might be?
Best regards,
Andrzej
AndrewB82
on 5 Oct 2018
GPIO16 is used to get the ESP8266 out of deep sleep (when connected to GPIO0)
This has nothing to do with the sensor itself.
As far as I know, the sensor has to be told to switch the fan on/off and that is not implemented yet.
As a work-around you could disable power to the sensor and control that via the ESP8266, but that has to be done via external commands and is not yet included in the plugin for this sensor.
It will, but I've been too busy getting stuff stable the last few month, so I've not yet looked into this sensor. :(
TD-er
on 5 Oct 2018
UPDATE: [SOLVED] - it was a wiring issue with SET pin, now it works like a charm.
Thanks for the answer, but I am confused now - @ShardanX described his way of getting the sensor to sleep few posts above, similar to the one on the plugin website:
I'm using a ESPEasy version from february so i can't, sadly. The System info says "manual reboot" - which is obviously wrong.
I'm using timing rules to put the sensor to sleep - this might be the reason why reading does not stop for me.
on System#Boot do gpio,16,0 timerSet,1,20 endon On Rules#Timer=1 do LongPulse,16,1,5 timerSet,1,20 endonGPIO 16 connected to the "SET" pin at the PMS is used to push the sensor into sleep mode.
On system boot the pin is set to 0 (low), sensor sleeps.
Timer 1 is set to run for 20 seconds, then trigger a 5 sec pulse on GPIO 16.
Timer 1 is set again to 20 seconds so it loops the sensor pulse.
It does not work for me, however, just as I wrote before. I connected GPIO16 to SET on PMS. Should it work then?
AndrewB82
on 6 Oct 2018
@AndrewB82 I guess I must be mistaken then, mixing up sensors I guess.
TD-er
on 6 Oct 2018
@TD-er thanks anyway - btw I solved my issue - it was a wiring problem - now the sensor goes to sleep and works like a charm.
AndrewB82
on 6 Oct 2018
Is it also stable in readings?
There is still an issue about these sensors regarding stability of readings. Not the values read, but only occasionally a value is read and others claim to be missed/rejected.
TD-er
on 6 Oct 2018
@TD-er I have set up rules to get readings every 5 minutes and send them to domoticz, but not tested it on longer run. I am planning to put the sensor in some case and then test its working. I will pay attention to this issue.
AndrewB82
on 6 Oct 2018
I'm testing a PMS7003 sensor to. It was running for hours ok, but then got stuck. Now it's get stuck after one or two readings after boot. Use a Wemos D1 mini, GPIO3/1. Going to test with above mentioned rules.
red55der
on 22 Oct 2018
Mine 5003 has worked flawlessly for almost 2 weeks now with readings every 5 minutes, sent to Domoticz and Fibaro. Readings seem accurate and I see correlation with outside sensors, although from time time some outlier readings occur which I cannot explain.
AndrewB82
on 22 Oct 2018
Hi
The rules doesn’t work for me. I connected pin set from Pms7003 to gpio16 and fan don’t stop. Any solution ?
fzdunek
on 6 Nov 2018
Have you double checked wiring @edwarpan ? For me it was the case. Do you use rules set explicitly in example?
AndrewB82
on 6 Nov 2018
Yes, i tried pin Reset and set on pms but still nothing. I used rules from example I have two other devices - OLED and bmp280 you thinking is it a problem? Or the pms be damaged.
On 6 Nov 2018, at 18:22, Andrzej Browarski notifications@github.com wrote:
Have you double checked wiring @edwarpan ? For me it was the case. Do you use rules set explicitly in example?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
fzdunek
on 6 Nov 2018
I also have OLED and bme280, but no reset pin, only set on gpio16 and it works.
AndrewB82
on 6 Nov 2018
i checked, set pin from pms to d0 (gpio16) and get 5V because earlier i delivered 3.3V from esp. And still nothing. In dust device interval set to 30s.
I also have OLED and bme280, but no reset pin, only set on gpio16 and it works.
fzdunek
on 7 Nov 2018
I had similar problems and I was able to fix it.
The LongPulse command doesn't work properly if you don't configure a Switch Input on the GPIO you want to use.
Once I configured the Switch Input it started working :
EVENT: Rules#Timer=1
ACT : Longpulse,16,1,30
SW : GPIO 16 Pulse set for 30 sec
ACT : timerSet,1,300
ACT : timerSet,2,28
SW : Switch state 1 Output value 1
EVENT: PMS5003_Enabled#Switch=1.00
Command: timerset
Command: timerset
EVENT: Rules#Timer=2
ACT : Publish /WeatherStation/PMS5003/pm1.0, 5
ACT : Publish /WeatherStation/PMS5003/pm2.5, 10
ACT : Publish /WeatherStation/PMS5003/pm10, 10
Command: publish
Command: publish
Command: publish
SW : Switch state 0 Output value 0
EVENT: PMS5003_Enabled#Switch=0.00
Without the Switch Input, the GPIO pin would switch to 1 when the LongPulse gets executed, but would never switch back. Using the switch allows it to work.
I also use the rules mentioned by @blb4github instead of sending it via the device controller, and it works very stable now, no timing problems.
on System#Boot do
gpio,16,0
timerSet,1,50
endonOn Rules#Timer=1 do
Longpulse,16,1,30
timerSet,1,300
timerSet,2,28
endonOn Rules#Timer=2 do
Publish /%sysname%/PMS5003/pm1.0, [PMS5003#PM1.0]
Publish /%sysname%/PMS5003/pm2.5, [PMS5003#PM2.5]
Publish /%sysname%/PMS5003/pm10, [PMS5003#PM10]
endon
According to the documentation of the PMSx003 the 30 seconds high on the SET pin are required to get a stable output from the sensor anyway... the 5 seconds simply isn't good enough.
Hopefully this will get fixed in the future so this kind of workarounds isn't necessary.
apszowski
on 7 Nov 2018
I did have problem with Longpulse, sorry I didn't mention before...
I did fix it on another way (without switch);I did use gpio,x,0 and gpio,x,1:
on System#Boot do
gpio,14,0
timerSet,1,20
endon
On Rules#Timer=1 do
gpio,14,1
timerSet,1,300
timerSet,2,28
endon
On Rules#Timer=2 do
Publish %sysname%/PMS7003/pm1.0, [PMS7003#PM1.0]
Publish %sysname%/PMS7003/pm2.5, [PMS7003#PM2.5]
Publish %sysname%/PMS7003/pm10, [PMS7003#PM10]
gpio,14,0
endon
blb4github
on 7 Nov 2018
@edwarpan actually, I forgot to mention - I haven't used longpulse either - my solution is similar to the one by @blb4github
AndrewB82
on 8 Nov 2018
AndrewB82
Can you describe how you connected ESPEASY with FIBARO?
jawilczek
on 15 Feb 2019
Here you have code excerpts - I got it through virtual device button which is shceduled to be pressed every 15 minutes - honestly I found some code on Fibaro Forum and fine tuned it to my needs, but do not remember where exactly:
local thisdevice = fibaro:getSelfId() -- make sure youve correctly set the ip adress of the ESPEasy node
local taskId = {"1","3"} -- make sure this matches the task id on your ESPEasy
local conn = Net.FHttp(fibaro:getValue(thisdevice, 'IPAddress'), fibaro:getValue(thisdevice, 'TCPPort'))
local values = {};
local valueCounter = 1;
local err = false;
local PM25global = "PM25IndoorDIY"; -- this is global variable where PM reading is stored
local PM25norm = 25;
local PM10norm = 50;
local varTelegram = "TelegramMessage";
local telegramTimeSTART = 7;
local telegramTimeSTOP = 22;
local icon1 = 1105;
local icon2 = 1106;
local icon3 = 1107;
local icon4 = 1108;
local icon5 = 1109;
local icon6 = 1110;
local icon0 = 1112;
local currentHour = os.date("%H");
for i = 1, #taskId do
if (not err) then
response, status, errorCode = conn:GET('/json?tasknr=' .. taskId[i])
if errorCode == 0 then
fibaro:debug("Request "..i.." status: "..status)
jsonTable = json.decode(response);
for j = 1, #jsonTable.TaskValues do
values[valueCounter] = jsonTable.TaskValues[j].Value
valueCounter = valueCounter + 1;
end
else
err = true;
fibaro:debug("Connection Error");
fibaro:log("Connection Error");
fibaro:call(thisdevice, "setProperty", "currentIcon", icon0);
fibaro:call(thisdevice, "setProperty", "ui.lblPM25.value", "Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPM10.value", "Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblTemperature.value", "Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblHumidity.value", "Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPressure.value", "Connection Error");
local counter = 10;
fibaro:debug("Telegram buffer: "..fibaro:getGlobalValue(varTelegram));
while ((fibaro:getGlobalValue(varTelegram) ~= "0") and (counter > 0)) do
fibaro:debug("Waiting for Telegram buffer - trial no. "..10-counter+1);
fibaro:sleep(200);
counter = counter - 1;
end
fibaro:sleep(500);
fibaro:setGlobal(varTelegram,"Uwaga! Problem z połączeniem z domowym czujnikiem pyłu zawieszonego PM2.5.");
end
end
end
for k = 1, #values do
fibaro:debug(values[k]);
if (not err) then
if (values[k] == "nil") then
err = true;
fibaro:call(thisdevice, "setProperty", "currentIcon", icon0);
fibaro:call(thisdevice, "setProperty", "ui.lblPM25.value", "Value Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPM10.value", "Value Error");
fibaro:call(thisdevice, "setProperty", "ui.lblTemperature.value", "Value Error");
fibaro:call(thisdevice, "setProperty", "ui.lblHumidity.value", "Value Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPressure.value", "Value Error");
local counter = 10;
fibaro:debug("Telegram buffer: "..fibaro:getGlobalValue(varTelegram));
while ((fibaro:getGlobalValue(varTelegram) ~= "0") and (counter > 0)) do
fibaro:debug("Waiting for Telegram buffer - trial no. "..10-counter+1);
fibaro:sleep(200);
counter = counter - 1;
end
fibaro:sleep(500);
fibaro:setGlobal(varTelegram,"Uwaga! Domowy czujnik pyłu zawieszonego PM2.5 przesyła błędne dane.");
end
end
end
if (not err) then
fibaro:setGlobal(PM25global,values[2]);
local PM25Proc = (values[2]/PM25norm)*100;
local PM10Proc = (values[3]/PM10norm)*100;
if (tonumber(values[2]) < 13) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon1);
elseif (tonumber(values[2]) < 37) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon2);
elseif (tonumber(values[2]) < 61) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon3);
elseif (tonumber(values[2]) < 85) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon4);
elseif (tonumber(values[2]) < 121) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon5);
else
fibaro:call(thisdevice, "setProperty", "currentIcon", icon6);
end
if ((PM25Proc > 150) and ((tonumber(currentHour) >= telegramTimeSTART) and (tonumber(currentHour) < telegramTimeSTOP))) then
local counter = 10;
fibaro:debug("Telegram buffer: "..fibaro:getGlobalValue(varTelegram));
while ((fibaro:getGlobalValue(varTelegram) ~= "0") and (counter > 0)) do
fibaro:debug("Waiting for Telegram buffer - trial no. "..10-counter+1);
fibaro:sleep(200);
counter = counter - 1;
end
fibaro:sleep(500);
fibaro:setGlobal(varTelegram,"Uwaga! Poziom pyłu zawieszonego PM2.5 w pomieszczeniu wynosi "..tostring(PM25Proc).."% normy.");
end
fibaro:call(thisdevice, "setProperty", "ui.lblPM25.value", values[2].." µg/m3 ("..PM25Proc.."%)");
fibaro:call(thisdevice, "setProperty", "ui.lblPM10.value", values[3].." µg/m3 ("..PM10Proc.."%)");
fibaro:call(thisdevice, "setProperty", "ui.lblTemperature.value", values[4].." °C");
fibaro:call(thisdevice, "setProperty", "ui.lblHumidity.value", values[5].."%");
fibaro:call(thisdevice, "setProperty", "ui.lblPressure.value", values[6].." hPa");
end
AndrewB82
on 15 Feb 2019
dziękuję za błyskawiczną odpowiedz.
spróbuje zaimplementować u siebie :)
Jacek
W dniu 2019-02-15 09:00, Andrzej Browarski napisał(a):
Here you have code excerpts - I got it through virtual device button
which is shceduled to be pressed every 15 minutes - honestly I found
some code on Fibaro Forum and fine tuned it to my needs, but do not
remember where exactly:local thisdevice = fibaro:getSelfId() -- make sure youve correctly set
the ip adress of the ESPEasy node
local taskId = {"1","3"} -- make sure this matches the task id on your
ESPEasy
local conn = Net.FHttp(fibaro:getValue(thisdevice, 'IPAddress'),
fibaro:getValue(thisdevice, 'TCPPort'))local values = {};
local valueCounter = 1;
local err = false;local PM25global = "PM25IndoorDIY"; -- this is global variable where
PM reading is stored
local PM25norm = 25;
local PM10norm = 50;local varTelegram = "TelegramMessage";
local telegramTimeSTART = 7;
local telegramTimeSTOP = 22;local icon1 = 1105;
local icon2 = 1106;
local icon3 = 1107;
local icon4 = 1108;
local icon5 = 1109;
local icon6 = 1110;
local icon0 = 1112;local currentHour = os.date("%H");
for i = 1, #taskId do
if (not err) then
response, status, errorCode = conn:GET('/json?tasknr=' .. taskId[i])if errorCode == 0 then fibaro:debug("Request "..i.." status: "..status) jsonTable = json.decode(response); for j = 1, #jsonTable.TaskValues do values[valueCounter] = jsonTable.TaskValues[j].Value valueCounter = valueCounter + 1; end else err = true; fibaro:debug("Connection Error"); fibaro:log("Connection Error"); fibaro:call(thisdevice, "setProperty", "currentIcon", icon0); fibaro:call(thisdevice, "setProperty", "ui.lblPM25.value","Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPM10.value",
"Connection Error");
fibaro:call(thisdevice, "setProperty",
"ui.lblTemperature.value", "Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblHumidity.value",
"Connection Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPressure.value",
"Connection Error");local counter = 10; fibaro:debug("Telegram buffer:"..fibaro:getGlobalValue(varTelegram));
while ((fibaro:getGlobalValue(varTelegram) ~= "0") and
(counter > 0)) do
fibaro:debug("Waiting for Telegram buffer - trial no.
"..10-counter+1);
fibaro:sleep(200);
counter = counter - 1;
end
fibaro:sleep(500);
fibaro:setGlobal(varTelegram,"Uwaga! Problem z połączeniem z
domowym czujnikiem pyłu zawieszonego PM2.5.");
end
endend
for k = 1, #values do
fibaro:debug(values[k]);
if (not err) then
if (values[k] == "nil") then
err = true;
fibaro:call(thisdevice, "setProperty", "currentIcon", icon0);
fibaro:call(thisdevice, "setProperty", "ui.lblPM25.value", "Value
Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPM10.value", "Value
Error");
fibaro:call(thisdevice, "setProperty", "ui.lblTemperature.value",
"Value Error");
fibaro:call(thisdevice, "setProperty", "ui.lblHumidity.value", "Value
Error");
fibaro:call(thisdevice, "setProperty", "ui.lblPressure.value", "Value
Error");local counter = 10; fibaro:debug("Telegram buffer:"..fibaro:getGlobalValue(varTelegram));
while ((fibaro:getGlobalValue(varTelegram) ~= "0") and
(counter > 0)) do
fibaro:debug("Waiting for Telegram buffer - trial no.
"..10-counter+1);
fibaro:sleep(200);
counter = counter - 1;
end
fibaro:sleep(500);
fibaro:setGlobal(varTelegram,"Uwaga! Domowy czujnik pyłu
zawieszonego PM2.5 przesyła błędne dane.");
end
endend
if (not err) then
fibaro:setGlobal(PM25global,values[2]);
local PM25Proc = (values[2]/PM25norm)100;
local PM10Proc = (values[3]/PM10norm)100;if (tonumber(values[2]) < 13) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon1);
elseif (tonumber(values[2]) < 37) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon2);
elseif (tonumber(values[2]) < 61) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon3);
elseif (tonumber(values[2]) < 85) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon4);
elseif (tonumber(values[2]) < 121) then
fibaro:call(thisdevice, "setProperty", "currentIcon", icon5);
else
fibaro:call(thisdevice, "setProperty", "currentIcon", icon6);
endif ((PM25Proc > 150) and ((tonumber(currentHour) >= telegramTimeSTART)
and (tonumber(currentHour) < telegramTimeSTOP))) thenlocal counter = 10; fibaro:debug("Telegram buffer:"..fibaro:getGlobalValue(varTelegram));
while ((fibaro:getGlobalValue(varTelegram) ~= "0") and (counter >
0)) do
fibaro:debug("Waiting for Telegram buffer - trial no.
"..10-counter+1);
fibaro:sleep(200);
counter = counter - 1;
end
fibaro:sleep(500);
fibaro:setGlobal(varTelegram,"Uwaga! Poziom pyłu zawieszonego
PM2.5 w pomieszczeniu wynosi "..tostring(PM25Proc).."% normy.");
endfibaro:call(thisdevice, "setProperty", "ui.lblPM25.value",
values[2].." µg/m3 ("..PM25Proc.."%)");
fibaro:call(thisdevice, "setProperty", "ui.lblPM10.value",
values[3].." µg/m3 ("..PM10Proc.."%)");
fibaro:call(thisdevice, "setProperty", "ui.lblTemperature.value",
values[4].." °C");
fibaro:call(thisdevice, "setProperty", "ui.lblHumidity.value",
values[5].."%");
fibaro:call(thisdevice, "setProperty", "ui.lblPressure.value",
values[6].." hPa");end
--
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].Links:
[1]
https://github.com/letscontrolit/ESPEasy/issues/914#issuecomment-463943676
[2]
https://github.com/notifications/unsubscribe-auth/AbK3uuqFGEq8XboAYqPShZA8MYSQ-sHNks5vNmkGgaJpZM4SNQbs
jawilczek
on 15 Feb 2019
Hello @ShardanX
Due to datasheet the PMSx003 have a lifetime of around 8000h, so permanently driven it will run for 333 days. The laser diode has a limited lifetime so after this period the values will get unreliable.
Can you post link to the datashet with 8000h lifetime?
Plantower support answer me about PMS-A003 sensor:
Our sensor lifetime in our datasheet is 3years, but actually it can use more than 4.5year with works continuously.
Best regards,
Holly Gao（Ms.）
Sales Executive-Marketing Dept.
Beijing Plantower Technology Co., Ltd.
#613,Building 9,Yuxi Road No.9,Houshayu,Shunyi District,Beijing, P.R.China.
I see in the PMS 5003/7003/A003 manuals "_MTTF ≥3 Year(Y)_"
zbx-sadman
on 19 Aug 2019
@blb4github
I did have problem with Longpulse, sorry I didn't mention before...
I did fix it on another way (without switch);I did use gpio,x,0 and gpio,x,1:on System#Boot do
gpio,14,0
timerSet,1,20
endonOn Rules#Timer=1 do
gpio,14,1
timerSet,1,300
@AndrewB82
actually, I forgot to mention - I haven't used longpulse either - my solution is similar to the one by @blb4github
It shouldn't work when we set GPIO High for PMSx003 SET Pin - sensor won't sleep. We need to cycle sleep/awake:
on System#Boot do
gpio,YOUR_GPIO_FOR_SET_PIN,0
timerSet,1,30
endon
On Rules#Timer=1 do
gpio,YOUR_GPIO_FOR_SET_PIN,1
timerSet,2,30
On Rules#Timer=2 do
gpio,YOUR_GPIO_FOR_SET_PIN,0
timerSet,1,30
mrdc
on 19 Oct 2019
Related issues
jobst
·
5Comments
TD-er
·
5Comments
ghtester
·
3Comments
wolverinevn
·
5Comments
TD-er
·
3Comments