wave plus released

[dvand]

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.

[marcelm]

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.

[Digitalvitamin]

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?

[marcelm]

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.

[dvand]

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> .

[marcelm]

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.

[dvand]

May have been wrong earlier, 13&14 appear to be CO2 while 15&16 appear to be TVOC.

[dvand]

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

[marcelm]

Thanks, I will try to integrate this unless you want to try yourself to come up with a patch.

[gkreitz]

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: ??

[dvand]

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> .

[marcelm]

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.

[jmagnuson]

Airthings published their own python script (MIT license) for reading the values:

https://github.com/Airthings/waveplus-reader/blob/master/read_waveplus.py#L167

[dvand]

Their script seems to require root to run.

[snyggapa]

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

[gkreitz]

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)