Hi all,
Maybe we could use the counter sensor now: keep a counter for each room. If counter = 0 then turn off the light :-).
Hi,
Do you mean each event in the room (PIR sensor/open door sensor/BLE tracker) to be added to the counter and then have the counter reset (at 0) when there are no events for 1 hour/10 minutes/etc?
Pls correct me if Iâm wrong. From my understanding, the band power consumption will not be more than what itâs already is. The gateway wonât actually pair it like the phone pair with it. The gateway just âsniffâ the BLE signal and itâs strength which is readily available.
I donât think counter sensor works like this.
No, the band wonât connect to the Gateway (but neither to the phone as otherwise it wonât send the beacon signal).
As the band it is not connected it will broadcast, continuously, this signal in order to find the device it was paired to. Iâm unsure how much battery will drain each case.
I have a semi-smartwatch (screen always on) that should lasts about 1 mo per charge and sometimes disconnects from the phone (quite antique) and it wonât reconnect by its own (for days). I found that the battery lasts longer (3-4 days longer) when it is connected to the phone. However, it also depends on a lot more factors such as type of activity (as it monitors steps, sleep), room temperature, etc.
I rarely pair my band to my phone coz I donât want to drain my phone battery by leaving the Bluetooth on all the time. At most once a day to see my sleep quality. I guess it wonât makes any different in my case coz I donât really connect my band to any phone anyway.
True
I think that @clyra mentioned in the other topic about modifying the code for the BLE on the gateway in order to be used with the room component but I donât know if itâs yet included in the beta
When you pair the band to the phone it disappear from the scanner. So you shouldnt want to pair it.
i believe it will appear in the scanner after I disconnect it from my phone even though I have paired it, right?
The counter sensor is generic. We should be able to write automations to use then.
right. I use to wear a garmin watch and can confirm that. The problem is when you forget to unpair it or turn of the phone BT.
1 Like
Iâm testing the multigateway feature. Now I have 2 gateways using the same version (0.4-beta) and same MQTT topic. When I wave my hand at my PIR sensor, I can see sometimes, the value appear twice in the same topic and sometimes once but most of the time twice. Anything Iâm missing?
For RF there is the time_avoid_duplicate (of 3 seconds, user editable) however Iâm unsure if this should exist also for BT. I think a duplicate removal for BT is not needed as this signal is used for âtriangulationâ.
Anyway, I consider that for BT, in order to have room component working, different topics for the gateways are needed (at least for BT topic).
Yes I have already seen this too, I currently donât have this configuration to reproduce it. I need to update my main arduino platform first.
Interested in counter too, but I donât know how to use, would you share some examples?
Hm⌠Iâm seeing a strange behaviour where my BT tag is at home but I started to receive notifications that I came back (i have a automation that send me a message when the state goes from away to home). Yesterday i turned off one of my gateways so Iâm using only one now. Seems stable for now. Iâm planning to look more carefully on this duplication thing. Also update to 0.4 as Iâm running 0.3 right now.
@Petrica yes. Actually Iâm referring to RF because BT is not working for me, yet.
@1technophile. Thanks.
Hi,
The issue with the BT reading is that RSSI will vary significantly depending on the environment so it is not an exact science (even if staying in the same spot it might generate 100 of 100 different readings).
In the example on the Github Iâve used the binary sensor depending on the statistical data, however with a sampling size of 10. You can increase this value (10 readings at default rate of 10 seconds means less than 2 minutes of data so it might not be a representative statistical sample).
HI,
I donât think that RSSI is a problem. I have two BT sensors: one publish to âhallâ topic and the other to âofficeâ topic. My automation sends a message when the device goes from âawayâ to âhallâ, so it shouldnât matter how much it changed its state from hall to office or office to hall, as long as one sensor picks the device and publish to its topic. If the device is going to away the reason should be either itâs not being picked by any sensor, or somehow the sensors/mqtt is misbehaving. I changed the battery of the device and increased the âaway_timeoutâ to 5 minutes, but still got a few (in fact very few) false positives.
On a side note, is there a way to have state âpersistenceâ between restarts? I always get a notification on ha restarts. Shouldnât HA remember the last state of the things?
HA would remember the state only if the message was published with retain flag.
You can define automation for different items that pick up the initial sensor/switch state and publish it in another topic, this time with retain topic, thus creating a new sensor/switch that retains state even after HA restart.