RELEASE: AcuRite Weather Station

⚙️ Custom Apps and Drivers Custom Drivers
62

Would you like to have access to my modified version?

It could be adapted to your setup.

63

Can you explain what that means or link me to something that does? Where would I use this?

64

I'd love to! I'll pm you my email.

65

No need here is the link:

66

thanks! too late already sent :slight_smile:

67

Just to let you know: It is based on an early version of david driver and I striped off some info I did not care about. Also some stuff is hardcoded so if you care to modify it to suit different setup it would be welcome since other had interest in that.

68 
for (sensor in [data.devices[preferenceName.toInteger()].sensors, data.device[preferenceName.toInteger()].wired_sensors].flatten()) {
69

David,

Thanks for the code. It worked lovely from initial download.

I did notice a couple of things.

  1. the date time format that is being reported by acurite is a format that only reports in GMT. I did a slight format change in my code and have it reporting in the local time zone. This ends up being the time that the device uploads its data to the acurite cloud.

  2. acurite is not reporting the Feels Like temperature (although they use it in their display). So I added to my code a section that calculates feels like from the given data.

I also added a attribute called poll data. This is the time that hubitat polls for the data. I needed this to try to understand the issues I was seeing with the odd format of data that acurite was reporting. .

Thanks again for your code!!

  1. additionally
70

I just wanted to note something I noticed using this neat code. The code uses simple, unencrypted text for the password to the acurite account. I sadly had to stop using this as it was transmitting this openly and is recognizable from within HE as well when the drive tries to log into the My AcuRite site. Some may not be concerned with this, but hashing a password is fairly simple and it is something that should be done whenever any password/credential is stored and/or transmitted. I had to stop using this driver due to this, but if this is correctly (hopefully it will) I will be happy to start using it again as it really is a great integration into HE. I just wanted to mention this for transparency and hope it can be corrected.

71

Isn’t the connection to the acurite API endpoint encrypted with TLS?

1 Like
72

It may be but the actual password is stored in the drive unencrypted as well which you can see both within the logs as well when it is sent. Its a security issue, and I attempt to minimize security issues.

73

I don’t disagree it would be more secure if the password wasn’t stored in clear text.

But since the password is transmitted over the internet encrypted by TLS, that seems like a much smaller security issue in terms of real world risk to me.

Someone would need access to your LAN, and the hub interface itself, I think.

I’m neither a developer nor a security expert though, so I’m sure it’s possible I’m misunderstanding the implications of this.

1 Like
74

It’s been some time since I’ve looked at Hubitat features, but I don’t believe there’s any alternative (eg. a credential store) to storing the passwords in cleartext. The driver only logs the password incidentally as part of the login_params data structure, but I’ve pushed an update that suppresses the password in that logging statement. Alternatively, you can just turn debugging logging off.

The actual transmission of the credentials is TLS-encrypted, so an adversary would need access to the Hubitat device to access it in the clear.

2 Likes
75

That’s awesome @david22.. I’ll redeploy and test it out.. Thank you

76

Thanks for confirming that. In that kind of scenario, a compromised password to a weather station should presumably not be anywhere near the top of a list of things to be worried about.

1 Like