OpenHAB Binding for AirGradient

#21

Thanks! I will look into that when I am back.

I used double for a lot of those because it felt safer from a parsing point of view (allowing more values). The API is only documented as “Number”. O-1PP e.g. had two particle sensors and returned the average of them, which might be a reason to keep some of these as double.

Off course, parsing as double and rounding to integer is also an option. Will have to think about it. And if anybody has a “will never ever return a decimal value” for some of those values, I am eager to learn about that!

#22

For some reason I don’t yet understand, OpenHAB shows Airgradient humidity as, e.g., 0.42. Even though the channel is declared with min=0 max=100:

Maybe it would already help if OpenHAB would report 42.0 instead of 0.42. To be frank, I am quite confused how OpenHAB processes and presents numeric values. All I know is that for other humidity sensors, like Homematic, I needed to create an extra item that presents humidity in the 0-100 range, an not in the 0-1 range, for other consumers, like Google Assistant/Google Home, to correctly process and display it.

Yes, it would be great to get a statement from Airgradient here, if the returned values will always be integers. CC @Achim_AirGradient
I think the Airgradient firmware already does exactly that, if a value is a float, e.g., because it was calculated as the average of two sensor values, then it is still represented as integer. Which, I guess, is for most values besides temperature sensible.

BTW, looking at my OpenHAB logs, I found:

 [DEBUG] [l.handler.AirGradientLocationHandler] - Channel name tvoc is null

It looks like tvoc is not correctly wired up in the local case , as it’s either tvocIndex or tvoc_raw in the JSON.

#23

I also see humidity displayed in different ways. In the logs the percentage is shown as “42%”, other places as 0.42, could be that some places has forgotten to convert it using the unit? Just speculating.

#24

@Jorgen_Austvik thank you for pointing these things out. We will look into it and revert back.

#25

@Achim_AirGradient : to be clear: the different ways to show percentage are in OpenHAB, and not AirGradients fault.

If it makes sense to specific some of the measures values as integers, that would be great, though, but if they could become decimal later it is probably better not to.

#26

@Flow: I have uploaded a new v0.8 which uses the system type for humidity and temperature. Does it work now?

image
image1821×668 30.1 KB

#27

Added “boot” channel in v0.9

#28

Better autodetection (less need to scan) and lots of improvements from reviewing for inclusion are available in v 0.10.

#29

Thanks for the updates.

I’ve updated the bundle to 0.10. I could add the device via the local API. However, it appears that I have to add two things to get OpenHAB to show the Aigradient values. Probably because an AirGradient Location still needs an Airgradient bridge, even in the local case.

#30

Great. I have code to add single local device running here, but it has some code duplication which I want to get rid of before I push it.

#31

Can’t wait for 0.11 then :slight_smile:

#32

@Flow 0.11 is out!

It has gone through a lot of reviews, so I think it is getting very close to being integrated into the official distribution (unless this last minute local device addition messes that up :slight_smile:

Next step (and the last step I can think of) is to add local configurations after beta release with a configuration endpoint is out.

#33

Good news: the binding is accepted into the official distribution, and will be part of the next official release! It should support most basic functionality for both cloud api and local sensor users.

When the next beta firmware is out, ill add corrected/raw temperature and humidity and lots of local configuration settings.