@thebearmay, thank you for this feedback! I measured the signal strength where the device is mounted, and you are correct -- the signal strength is not consistently as strong as I expected.
I modified the driver to do 2 things:
- It now does an asynchronous httpget instead of a synchronous httpget, so that it won't tie up resources when there is a delay in getting a reply.
- I added retry logic. I will retry up to 5 times before giving up and logging an error.
I just started running it but I have already seen it recover from a couple of errors.
I'll test it for the next week and if it continues to work properly, I will post the code in case others want to use it.
A final comment that cursor.com is a pretty amazing AI-based coding system for doing things like this. It only took about 10 minutes to make the changes, including a second iteration to resolve a mistake that it made on the first iteration. Sharing this in case others find it helpful information.
Marc
I had the same question so I did some digging. If set to "false", then you will get the 2-minute average. If set to "true", then you will get real-time readings.
While I like the hyper-aware 2 min option, would be nice if we could select an even broader default like (10min, 30min, 1hr, 6hr, 1 day, 1 week) like they display on map.purpleair.com
From what I can see the purpleair device only provides the option of "real time" or "2 minute average". The website is probably doing the work to compute the other averages, so to make this happen, one would need to compute the various averages in the driver. This is an FYI in case you want to undertake making those changes.
Marc
At @sidjohn1's request, I have removed my version of his driver that implements retry logic from this thread and created this separate thread with the code.
Marc
Please create a new thread for your code. I dont want there to be any confusion between the 2 and yours is now a separate fork. Also for the sake of confusion i’d give yours a new name… my code is still active.
Your are more than welcome to give me credit for the initial codebase, but as we did not collaborate on this, your could be should be separate from mine. THX.
I should have been clearer -- my intent was to contribute it back to you, as this solves a problem that has been plaguing my deployment and could impact others. I would have created a pull request, but it's been a long time, and I don't recall all the mechanics of doing so. If you would like to include this in your release, I have no concerns if you prefer to remove my name from the comments.
If you prefer that I make this a separate fork, let me know and I will remove it from this thread.
Thanks!
Marc
Marc,
If you had the intent to collaborate, all you had to do is reach out. I’m pretty active in this community and you chose not to.
There were reasons I chose synchronous over asynchronous communications to the device. If you had reached out i would have let you know. So now there is an architectural difference between how your driver communicates vs mine. These differences should be treated differently and supported separately.
I’m not asking you to remove anything, but as you have decided to share your code publicly it needs to be supported separately as our communication methods to the device are distinct. Not better or worse, just different.
Hi Sidney, I have moved the code to a separate thread, per your request.
If you had the intent to collaborate, all you had to do is reach out. I’m pretty active in this community and you chose not to.
I think there has been a mutual misunderstanding of intent. Based on your reply to robby earlier on this thread ("feel free to review the device docs and submit the code to github for feature enhancements"), I incorrectly inferred that your preference was that change requests come with a suggested implementation.
I now see that this is not the case and that I read something into that post that you did not intend. It was not my intent to not be collaborative. (hummm...Maybe I should avoid those double negatives 
)
Hope this makes sense and I look forward to having the opportunity to collaborate in the future.
Marc
1 Like
I'm attempting to install this app.
When I paste: "https://raw.githubusercontent.com/sidjohn1/hubitat/main/repository.json"
Into package manager ( Install a Package from URL), I get:
" You are about to install null . Click next when you are ready."
Once installed (?), I can't find PurpleAir in Apps...
Am I not doing the correct steps? What am I missing?
Thank you.
Thanks. I've already done that. (What do I do next?)
It’s like 1 post down from the last link i sent
Thanks.
I'm using Basic Rules to pull sensor data. I see that the driver provides temperature and humidity. Any way to pull other data, such as PM 2.5 ?
Not from Basic Rules, no it’s a limitation of that application. RM has access to all the atttributes.
before you ask… No i will not help with RM.
Thanks. No, I don't need help w/ RM.
1 Like
