Problems with the _P053_PMSx003 Dust Plugin #914
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 ***@***.***> 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
<#914>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADk9ljlPVUnmHKcrYQ7iCgp-7xXzxE2yks5tW9fogaJpZM4SNQbs>
.
|
|
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.
|
|
Have you also tried another power supply and other cable to power the node? |
|
Yes, I know that with the cables. There are a lot of high-impedance cables on the market. 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. |
|
I've looked into the source and it looks very likely to give exactly the issues you mention. 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) |
TD-er
added
Type: Bug
|
The PMS is already connected via software serial. What does your answer mean? Cant we do anything? I will buy a SDS021 that works in other devices. |
|
What I meant is, I will try to fix it in ESPeasy. |
|
That is a word! |
|
@TD-er I have got PMS sensor, maybe can help here |
|
@uzi18 Do you also experience similar issues? |
|
My sensor were never used before but this is a time ;) |
|
It is PMS3003 |
- Use peek instead of read, to make sure a complete packet is in the buffer. - Flush buffer after processing a packet. - Increased software serial buffer to the size of 3 packets. - Peek (+ read garbage) 10 times per second to get the buffer in sync to start with start byte of packet. - Decent delete + clean up of software serial allocation when changing settings (prevent memory leak) - Move log String allocation to inside scope of function, not permanent allocated. - Split into separate functions to make it better readable.
|
Good morning Gijs, The plugin has already failed after two measurements. 504669: PMSx003: invalid framelength - 142 edit: |
|
Those errors are not that bad, as long as it can keep sync. Or at least regain sync. |
|
If it has just failed, no values are displayed anymore. There is no entry from the dust sensor in the logfile. |
|
It is almost perfect now with @TD-er fix. |
|
It only runs for a few hours. That's not enough. |
|
Code is better it must be ok. |
|
I have no connection problems. |
|
@micropet Can you show the last output of the sensor (log output)? |
|
Is that correct that the log file is only so short? Or is there a "full" version of it? |
|
You can try to send it to a logserver. |
|
OK, then I'm waiting for the version with the extra check on the dummy parameter. |
|
GPIO16 is used to get the ESP8266 out of deep sleep (when connected to GPIO0) As far as I know, the sensor has to be told to switch the fan on/off and that is not implemented yet. |
|
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:
It does not work for me, however, just as I wrote before. I connected GPIO16 to SET on PMS. Should it work then? |
|
@AndrewB82 I guess I must be mistaken then, mixing up sensors I guess. |
|
@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. |
|
Is it also stable in readings? |
|
@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. |
|
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. |
|
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. |
|
Hi |
|
Have you double checked wiring @edwarpan ? For me it was the case. Do you use rules set explicitly in example? |
|
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 ***@***.***> 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.
|
|
I also have OLED and bme280, but no reset pin, only set on gpio16 and it works. |
|
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 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 :
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.
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. |
|
I did have problem with Longpulse, sorry I didn't mention before... on System#Boot do On Rules#Timer=1 do On Rules#Timer=2 do |
|
@edwarpan actually, I forgot to mention - I haven't used longpulse either - my solution is similar to the one by @blb4github |
|
AndrewB82 Can you describe how you connected ESPEASY with FIBARO? |
|
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 values = {}; local PM25global = "PM25IndoorDIY"; -- this is global variable where PM reading is stored local varTelegram = "TelegramMessage"; local icon1 = 1105; local currentHour = os.date("%H"); for i = 1, #taskId do end for k = 1, #values do end if (not err) then end |
|
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
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
--
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].
Links:
------
[1]
#914 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/AbK3uuqFGEq8XboAYqPShZA8MYSQ-sHNks5vNmkGgaJpZM4SNQbs
|
|
Hello @ShardanX
Can you post link to the datashet with 8000h lifetime? Plantower support answer me about PMS-A003 sensor: I see in the PMS 5003/7003/A003 manuals "MTTF ≥3 Year(Y)" |
It shouldn't work when we set GPIO High for PMSx003 SET Pin - sensor won't sleep. We need to cycle sleep/awake: |
|
This seems to be solved, so can be closed. |
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.
The text was updated successfully, but these errors were encountered: