wave plus released #4
Comments
|
I don’t own a Wave Plus nor do I plan to buy one any time soon, so I’m personally not interested. However, if you can either describe how to get the data off the device or even change the code in such a way that it can be used with both devices, I would happily accept a pull request. |
|
I'm planning to buy a wave plus too. I already read that the current script does not work with it. |
|
I really don’t know. If the platform is the same, uses Bluetooth Low Energy, and the company didn’t decide to explicitly hide the radon level, then it is probably simple to figure out how to get the value. I would hope that only the UUIDs need to be changed. Then the nRF Connect app would help, yes. Alternatively, using Please note that I cannot promise anything, though! It may well be that Airthings doesn’t like people tinkering with their devices and has tried to lock them out in this new version. However, if it works and you figure out how to get the levels off the device, I’ll gladly help you to integrate this into the current script so it would work for both devices. |
|
They made it more difficult to decode as there is no explicit labelling and
it appears to return all the monitored values in one value.
Here is a sample value:
01-44-00-00-5C-00-00-00-CC-08-DE-C1-C9-02-93-02-00-FE-98-01.
What i figured out is bytes 5&6 (5C-00) represent radon.... 14&15 seems to
be TVOC. Haven't figured out anything else.
…On Tue, Oct 30, 2018 at 3:06 PM Marcel Martin ***@***.***> wrote:
I really don’t know. If the platform is the same, uses Bluetooth Low
Energy, and the company didn’t decide to explicitly hide the radon level,
then it is probably simple to figure out how to get the value. I would hope
that only the UUIDs need to be changed. Then the nRF Connect app would
help, yes. Alternatively, using gatttool on the Linux command line as
described in the README is also a good idea. It’s a bit more complicated to
use, but copying&pasting the UUIDs into the script is simpler this way.
Please note that I cannot promise anything, though! It may well be that
Airthings doesn’t like people tinkering with their devices and has tried to
lock them out in this new version.
However, if it works and you figure out how to get the levels off the
device, I’ll gladly help you to integrate this into the current script so
it would work for both devices.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEI8NRcUpeJV9z_or0JDsPY13M_rfJ1rks5uqLErgaJpZM4XdUSz>
.
|
|
Ah, thanks for the details. It could be that this change isn’t meant to make things more complicated, but perhaps to make reading faster. For some reason, reading each characteristic takes quite a lot of time. So if you put everything in a single characteristic, that could speed things up. |
|
May have been wrong earlier, 13&14 appear to be CO2 while 15&16 appear to be TVOC. |
|
The UUID of the service/characteristic is: |
|
Thanks, I will try to integrate this unless you want to try yourself to come up with a patch. |
|
The ones I think I've figured out this far are:
|
|
That's cooI! I never thought to try dividing or multiplying.
…On Sun, Dec 16, 2018, 7:15 AM gkreitz ***@***.*** wrote:
The ones I think I've figured out this far are:
- Byte 0: always 1 (version number perhaps?)
- Byte 1: humidity (divide by 2)
- Byte 2-3: ??
- Byte 4-5: radon (short)
- Byte 6-7: radon (long)
- Byte 8-9: temp (divide by 100)
- Byte 10-11: pressure (multiply by 2)
- Byte 12-13: CO2
- Byte 14-15: VOC
- Byte 16-19: ??
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEI8NcRdw1yM8PLr0FA7urWEZO8ZtgDhks5u5keHgaJpZM4XdUSz>
.
|
|
Cool! Anyone wants to send a pull request? I don’t think that I can integrate this myself after all, at least at the moment, as I don’t have the device. If you’re not actually using the script, you could just update the README. |
|
Airthings published their own python script (MIT license) for reading the values: https://github.com/Airthings/waveplus-reader/blob/master/read_waveplus.py#L167 |
|
Their script seems to require root to run. |
|
I have a wave plus since yesterday. the "official" script linked above seems to work for 5 minutes and then die (and needs python 2 and root and seems to have no error handling... but it does at least seem to document the decode of the bytes) In addition to the official script being flaky, the official andriod app didn't work for me either - connected once and then not again, hence the interest in the pi :). Had to pull the batteries to reset it |
|
I implemented something really hackish to get the data into my local home-assistant, https://github.com/gkreitz/homeassistant-airthings/blob/master/airthings.py . Seems to be reasonably stable at least. A few things I noticed when building that may be useful for others:
|
|
Just managed to bodge something to send to thingspeak https://thingspeak.com/channels/674115 Should update every 10 minutes. Once I work out quite how github works, and python, will post some code... first experience of both :) --edit-- learned a bit about github, forked it and placed my code on https://github.com/snyggapa/waveplus-reader run with a system cron job and uploading stats to the thingspeak URL above |
|
I tried to strip out the home-assistant pieces of your script but for some
reason I don't get reasonable values. Not sure why. I always get -0.5 for
humidity and 65535 for voc.
…On Thu, Jan 10, 2019 at 12:29 PM gkreitz ***@***.***> wrote:
I implemented something *really* hackish to get the data into my local
home-assistant,
https://github.com/gkreitz/homeassistant-airthings/blob/master/airthings.py
. Seems to be reasonably stable at least. A few things I noticed when
building that may be useful for others:
- I went with disconnecting and connecting for every poll, based on
what airthings wrote in the docs for the script for the wave, I assume only
one thing can be connected to the airwave at once.
- I had to increase the timeout for connections quite significantly,
sometimes the wave plus simply seems horribly slow to connect.
- For some reason, reading the characteristic via UUID didn't work in
gattool (and therefore, not in pygatt). Did not seem to be an issue with
bluepy (which the airthings script uses)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEI8NUWaf3ctjZMkp3SCmIbP59Sq9vPrks5vB4aegaJpZM4XdUSz>
.
|
|
My bad. Seems my device flaked out and I had to pull the battery. Unfortunately seems very common with this device :( |
|
I think that it sets all bits to 1 as some sort of error condition for individual measurements, so if you get those, treat it as an error. I didn’t see them often enough yet to bother with more proper error handling in my script yet. (You get -0.5 for humidity as it will parse 0xff as -1 and then divide by 2.)
… On 12 Jan 2019, at 23:36, dvand ***@***.***> wrote:
I tried to strip out the home-assistant pieces of your script but for some
reason I don't get reasonable values. Not sure why. I always get -0.5 for
humidity and 65535 for voc.
On Thu, Jan 10, 2019 at 12:29 PM gkreitz ***@***.***> wrote:
> I implemented something *really* hackish to get the data into my local
> home-assistant,
> https://github.com/gkreitz/homeassistant-airthings/blob/master/airthings.py
> . Seems to be reasonably stable at least. A few things I noticed when
> building that may be useful for others:
>
> - I went with disconnecting and connecting for every poll, based on
> what airthings wrote in the docs for the script for the wave, I assume only
> one thing can be connected to the airwave at once.
> - I had to increase the timeout for connections quite significantly,
> sometimes the wave plus simply seems horribly slow to connect.
> - For some reason, reading the characteristic via UUID didn't work in
> gattool (and therefore, not in pygatt). Did not seem to be an issue with
> bluepy (which the airthings script uses)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#4 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEI8NUWaf3ctjZMkp3SCmIbP59Sq9vPrks5vB4aegaJpZM4XdUSz>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AELDK3hsVersua5hTPU2H-dy3XTM7gzbks5vCmN6gaJpZM4XdUSz>.
|
|
Just an FYI - I am running on a fork of the "official" script but it died after 28 days (and never gave me any long-term radon readings) Link to the issue in case anyone has the same: |
|
If anybody wants to collaborate on getting history from the Wave+ ping me at [email protected] . I think I have the basics worked out, but wouldn't hurt to have more eyes on it. |
Any interest in figuring out how to get data from a wave plus?
It presets the data in a different way but I think I may have figured out how to get the radon value.
The text was updated successfully, but these errors were encountered: