Interesting. I guess that is all you really need, though I suppose the Govee app also shows the battery. I’m eager to get my sonoff rf and try things out…but of course it’s going to be another 3-4 weeks!
The battery level should also be communicated through 433mhz as well, so it should be possible to get that. The more difficult part would be capturing what that signal is. I know the app shows three bars, but I’m assuming it just is either “nominal” or “low”. Bur I’m not home now to mess around with them.
I’m also ordering a Sonoff RF as a result of this so, hopefully I can chime in again in a month or so.
Just got my bridge and have started testing things out. Obviously get a hex code when the sensor sends a signal. Have found that the active sensors sends 20CCFB for an alarm and then if you push the button or remove/insert the battery I get 20CCFC. So I am guessing the 20CCF is the device and the ‘B’ or ‘C’ is what determines what the “message” is. I did get a random 20CCFD, but not sure what that correlates to. Need to install Portisch and see what, if anything, else I can find in regard to message “patterns”.
Funny coincidence. I just flashed a sonoff rf bridge with tasmota and came here to suggest trying that for the Govee water sensors. I never got notifications that there were new posts on this thread, so was surprised to see that you were discussing exactly that. Now I have to get the sensors.
Nice. Yeah I got 5 of mine working. Have been setting them off every once and a while myself and making sure I get the HA notification on my phone. So far it’s been working great so I unplugged the gateway for now. It’s so quick that I will get the notification on my phone a half a second prior to the actual sensor alarm going off. I installed Portisch on my bridge so when I get some time, maybe I can try to figure out the battery situation. But I am just happy the alert works!
Excellent. I have not (yet) installed Portisch on the bridge. It looks about 1.5 years old, so wasn’t sure if it is still maintained. I am eager to see if that gets the battery problem fixed.
@smoysauce Thats awesome! Thank you for sharing your experience. I haven’t gotten the RF bridge yet. But that is very encouraging it works. Did you install tasmota on the RF bridge when you got this working, or just using the Sonoff firmware?
Hopefully portisch can help decode the battery status. I wonder if that “D” part of the hex code is part of a battery status update. I have had my sensors installed for ~10 months and they are still full battery on the Goveee app. Which is great, but probably harder to decipher the battery status. I guess one could try putting in known low batteries to see what the sensor sends out. Or hooking the terminal up to a power supply with a controllable voltage to do some tests would surely do it.
Yep, flashed tasmota right away. So far with Portisch I have no clue what I am doing just trying to figure things out. I was thinking the “D” code was battery status as well. I also thought about getting some low batteries, the voltage control is above my knowledge/skill level right now!
I got my sensors and just started playing around. So far, with two sensors, I see that
7xD2FC = battery powered device on
7xD2FB = water detected
7xD2FA = button pressed
where ‘x’ was different for the two devices out of the same box. I will check the other three soon, but since they were manufactured consecutively, the overlap in codes could be meaningless. (edit: that was just coincidence. Only the last two hexadecimal digits mean something. The first 4 identify the sensor.)
However, the FA,FB,FC ending the code is the same a @smoysauce.
I doubt that the battery is in this code at all. Each code is a unique signal of an event.
Either it is in the portisch codes, or it might also be that the sonoff bridge occasionally pings a query to the device to get the battery state. To check this you could have your Govee bridge sit next to your sonoff bridge for awhile, and see if the sonoff detects anything. If we are lucky, it sees the ping from the Govee bridge, and the response from the detector. But I am just guessing.
Just curious (and so I can sub the thread!), has anyone flashed the govee bridge?
I don’t think anyone here has, but it should be possible with that chip. You would then have to figure out how the pins are used. Since I don’t have one, is was just easier to flash the sonoff bridge.
Yeah I have been using the sonoff bridge and unplugged my govee bridge. Would definitely be nice to get something figured out, but for now this seems to work. (I usually will test the sensors every so often when I think about it to see if the alert comes to my phone, so far they have been pretty solid!)
Hi
I have a sonoff bridge flashed with Tasmota. Can you explain how you get the Govee Sensors reporting via this method?
This is the video I used to help me understand and configure the bridge with the sensors, it’s very helpful: https://www.youtube.com/watch?v=Ega4U1KRlso
Basically, I logged into the Sonoff Bridge Console and set off each of the senors and wrote down the hex code associated with each sensor. I then used those hex codes in my binary sensor yaml file to create the sensors in HA, then I used automations to push an alert to my phone if one of the senors goes off.
I think the video posted above will probably help you solve it, but as they said: just manually activate them (I just used a screwdriver to short out the bottom contacts of the sensor), and then you can set up your binary_sensors as below (modify the state topic and payload_on/off):
from my configuration.yaml:
binary_sensor:
- platform: mqtt
name: "kitchen sink leak detector"
payload_on: "00D6FB"
payload_off: "00D6FC"
device_class: moisture
state_topic: "tele/tasmota_C370F0/RESULT"
value_template: "{{ value_json.RfReceived.Data }}"
availability_topic: "tele/tasmota_C370F0/LWT"
payload_available: "Online"
payload_not_available: "Offline"
- platform: mqtt
name: "bathroom sink leak detector"
payload_on: "001BFB"
payload_off: "001BFC"
device_class: moisture
state_topic: "tele/tasmota_C370F0/RESULT"
value_template: "{{ value_json.RfReceived.Data }}"
availability_topic: "tele/tasmota_C370F0/LWT"
payload_available: "Online"
payload_not_available: "Offline"
from my automations.yaml:
- id: '1599002167148'
alias: Leak Alert
description: ''
trigger:
- entity_id: binary_sensor.bathroom_sink_leak_detector
from: 'off'
platform: state
to: 'on'
- entity_id: binary_sensor.kitchen_sink_leak_detector
from: 'off'
platform: state
to: 'on'
- entity_id: binary_sensor.valve_leak_detector
from: 'off'
platform: state
to: 'on'
- entity_id: binary_sensor.water_heater_leak_detector
from: 'off'
platform: state
to: 'on'
condition: []
action:
- data_template:
message: '{{ trigger.from_state.attributes.friendly_name }}: Leak Detected!'
service: notify.notify
- data: {}
entity_id: switch.elexa_consumer_products_inc_dome_water_shut_off_valve_switch
service: switch.turn_off
Thanks for all your help. I will give it a try.
So, I got ON working, was pretty easy once I understood how to see the payload (I’m a bit new to Tasmota). I am unclear on how you have a value for OFF, as I do not see the sensor reporting anything once the alarm stops.
So that is where I used the example from the video. You don’t really have an “OFF” signal sent. So you can either setup for it to persist, or maybe make it a ‘switch’ that you then have to manually turn off which would ensure the alarm doesn’t clear in HA until you actually verify the leak and manually turn the switch off. I think this is what I will end up doing as I start to refine it. Right now it just sends a persistent push notification to my phone but may setup a swtich that will trigger an automation that will continue to push a notification or do something at a regular interval until turned off by me.
In my case, I used the button press on the sensor for that code. So it will be ‘ON’ until the button is manually pressed on the sensor that reported it. Sorry about leaving that detail (it’s been awhile since I did it now), but as mentioned above - there are several approaches you could take! I wanted something that forced me to have the sensor itself checked.
Great idea, thanks