Also make sure you toggle the switch next to your device you want to subscribe to. Scratched my head a few mins when I first installed the driver.
Got it. I searched the web page until I finally found it. Then I toggled the subscribe button and the status showed up. I was entering the Weather Unit number, not the hub number.
Thanks for all your help.
3 Likes
It is definitely well hidden. Glad you got it sorted out!
I noticed that when 1.0.6 was released, the package manifest was updated, except for the version, it still lists 1.0.5 even though the description and dates have been updated.
I submitted a GitHub pull request to address this.
Thanks.
Jeff
Just pushed an update adding the water sensor capability and fixing the manifest version.
3 Likes
I just started playing with the rain accumulation info and noticed that it's rounding to zero. Possible to have option of showing decimals? We had a whopping .02" this morning lol 
Aaaand 0.21" yesterday
3 Likes
@eibyer It should already be rounding to 2 decimal places.
Can you turn on debug logging and post the value that starts with “parsed:”?
2 Likes
You're right! It is indeed in decimal, the dashboard I was using had rounding enabled 
3 Likes
I have HSM configured to alert on water sensors and now it triggers whenever it rains.
Is there another way to signal water w/o HSM thinking it's a water leak?
Thanks.
Jeff
My first move would be to remove your Weatherflow device from the HSM leak sensor device list. It has the same capability and I'm just guessing that it is included in the All Water sensor list.
3 Likes
1 Like
Obviously.
The question here is semantics. HSM seems assume this is a "water leak" sensor so it includes it if you check "all water sensors". So now I have to manually maintain a list of what is a water sensor.
The Z-Wave protocol defines the alert from a water sensor as a "Water Leak Alarm". I posit that rain does not fall into that definition.
I'm not saying that getting an indication of the presence of rain is not useful. But it should be implemented w/o overloading some other definition, such as a virtual switch.
Thanks.
Jeff
Actually, it isn't. My guess is that you haven't seen the Hubitat list of standard capabilities for Drivers and Attributes.
From my reading of that list, there is only one standard capability to detect water. That being "WaterSensor". Here are the attributes for that capability:
WaterSensor
Device Selector
capability.waterSensor
Driver Definition
capability "WaterSensor"
Attributes
water - ENUM ["wet", "dry"]
Commands
So it makes total sense for @augoisms to have used this capability for the rain sensor within the Tempest - which has two states (wet/dry).
The same two states exist for every other sensor that detects water - not all of which are used to detect leaks.
Therefore, it falls on the end-user (you or me) to determine which of our water sensors are used to pick up leaks, and which ones are not. And only incorporate the ones used to detect leaks for leak detection by HSM.
So I'm certain that is the reason @eibyer and @rlithgow1 correctly suggested that the issue isn't with the Tempest driver; rather, with the list of water sensors used in your HSM setup.
P.S. Also - needless to add, z-wave protocol definitions cannot be expected to correspond to capabilities in Hubitat drivers, because there are water sensors that use other protocols - like WiFi or zigbee.
2 Likes
More semantics but I have always had to maintain a list of water sensors because I have HSM turn off my water valve if water is detected. This is the perfect solution until you start adding water sensors to sump pump buckets, HVAC drip pans, and other places that don’t have to do with the house water valve like I have. I don’t add new water sensors that often, in fact never since I setup my hub 4 years ago converting from ST.
There is no other capability to report water so IMO it makes sense that this driver uses the water sensor capability. You could always comment out that capability in your copy of the driver as a work around.
1 Like
I do this anyway. I have a few water sensors I do not want turning off my main water valve. I have a water sensor on my water softner. The pig tail extension sits on top of the salt. When the salt gets low enough to hit the brine water it notifies our phones that salt needs to be added and repeats once a day until the sensor is dry. It would suck to have the whole house turned off because I was low on salt.. 
Naming convention helps in the listing. Mine are listed by device type-location
Watersensor-1st floor powder room
Watersensor-Water heaters
Watersensor-MasterBathroom
Watersensor-KitchenSink
etc etc. You get the idea. So being able to pick the ones I want is fairly easy.
1 Like
Thanks for pointing out the Hubitat capabilities. I get the point.
As I also have a problem with HSM battery monitoring. Some devices always report 1% (Aeotech doorbells) so either need to reset the daily alert or exclude them. And then forget to add new battery devices when I add them. I should file a feature request for HSM to have an exclude list for the various alerts.
Thanks.
Jeff
If you run a refresh() each time the doorbell rings, the button will give you an accurate battery reading.
1 Like
I have two Aeotech doorbells, one always presents 1% battery, the other one seems accurate. I defined a rule to do a refresh() when the doorbell rings and that didn't seem to change anything. I believe this one is just broken.
1 Like
This driver has been working great. But I'm getting an error unfortunately. See debug info below:
Here's the response that is causing the error:
response: [
summary: [
pressure_trend: steady,
strike_count_1h: 6,
strike_count_3h: 6,
precip_total_1h: 0.0,
strike_last_dist: 1,
strike_last_epoch: 1662568057,
precip_accum_local_yesterday: 5.663966,
precip_accum_local_yesterday_final: 4.735254,
precip_analysis_type_yesterday: 1,
feels_like: 24.9,
heat_index: 24.9,
wind_chill: 24.9,
pulse_adj_ob_time: 1662568416,
pulse_adj_ob_wind_avg: 0.6,
pulse_adj_ob_temp: 25.0,
raining_minutes: [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
dew_point: 24.0,
wet_bulb_temperature: 24.3,
wet_bulb_globe_temperature: 25.1,
air_density: 1.16682,
delta_t: 0.6,
precip_minutes_local_day: 0,
precip_minutes_local_yesterday: 33
],
serial_number: XXXXXXX,
hub_sn: XXXXX,
type: obs_st,
source: mqtt,
obs: [
[
1662568477,
0.0,
0.43,
0.83,
254,
3,
998.3,
24.9,
95,
11315,
1.23,
94,
0.0,
0.0,
0,
0,
2.81,
1,
0.0,
0.0,
0.0,
0
]
],
device_id: XXXXX,
firmware_revision: 165
]
I think there's a chance that the precipitationType was sent over the websocket with a value of 0.0 instead of 0, which is unexpected. But that's just a cursory look...Any ideas?
Hi, I started using it yesterday and after a while the log showed the message 'logging disabled'.
Is this expected behaviour?
