radonwave
radonwave copied to clipboard
marcelm
wave plus released
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.
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. Do you think it should be possible to adapt the script using the nRF Connect app?
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.
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 [email protected] 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 https://github.com/marcelm/radonwave/issues/4#issuecomment-434449891, 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: b42e2a68-ade7-11e4-89d3-123b93f75cba Sample value: Properties: READ Parsed value: (0x) 01-46-09-00-00-00-00-00-8C-08-F7-BF-23-03-1F-00-00-FE-CE-03 Raw value: (0x) 01-46-09-00-00-00-00-00-8C-08-F7-BF-23-03-1F-00-00-FE-CE-03
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:
- 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: ??
That's cooI! I never thought to try dividing or multiplying.
On Sun, Dec 16, 2018, 7:15 AM gkreitz <[email protected] 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 https://github.com/marcelm/radonwave/issues/4#issuecomment-447642554, 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
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) Happy to provide any assistance / testing if required. Will work on posting the results to thingspeak too
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:
- 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)
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 [email protected] 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 https://github.com/marcelm/radonwave/issues/4#issuecomment-453202999, 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 [email protected] 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 [email protected] 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 https://github.com/marcelm/radonwave/issues/4#issuecomment-453202999, 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 https://github.com/marcelm/radonwave/issues/4#issuecomment-453786178, 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:
https://github.com/Airthings/waveplus-reader/issues/10
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.
