ST Presence Fob v4

Not for me yet, 4 ST sensors with 124

My 2 fobs went from displaying "0%" in the logs to displaying no battery status what so ever. It's still showing "0%" in my dashboard though. . . I was hoping they would have fixed this. -Joel

I am new to these ST Fobs v4. Never even looked at them before 2 weeks ago when I bought two. I've stayed away because they are Zigbee and until a month or two ago, I chose not to use Zigbee. Now I have 7 devices and these 2 Fobs make 9.

dev:9352019-03-21 07:10:09.603 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:10:09.555 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:10:03.429 am warnPresence timeout set to: 180 seconds
dev:9352019-03-21 07:10:03.428 am warndescription logging is: true
dev:9352019-03-21 07:10:03.427 am warndebug logging is: true
--- Loading Past Logs... ---

Current States
battery : 30
presence : present

State Variables
bv : 18

I'm seeing a "Match" between the value reported by the Fob for battery and the State Variable "bv" and that the range of values of bv is not zero to a hundred. Thus there's some 'equation' in play that takes "18" and displays that as "30" percent.

Very chatty battery, apparently:

dev:9352019-03-21 07:16:07.897 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:16:07.868 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:15:48.006 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:15:47.956 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:15:28.097 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:15:28.056 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:15:08.156 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:15:08.139 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:14:48.250 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:14:48.234 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:14:28.340 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:14:28.328 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:14:08.436 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:14:08.419 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:13:48.551 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:13:48.521 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:13:28.637 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:13:28.614 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:13:08.748 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:13:08.710 am debugST presence sensor, reporting in...
dev:9352019-03-21 07:12:48.815 am debuggetBatteryResult- value:18
dev:9352019-03-21 07:12:48.790 am debugST presence sensor, reporting in...

Bv is in internal variable, battery voltage. It's used to track changes at .1 volt.
This sensor uses battery reports every 20 seconds to determine presence, but obviously we don't want to actually send a battery event every 20 seconds, so when the battery events come in and the new value doesn't match bv we send a battery report.

1 Like

@mike.maxwell. any news on these things triggering presence events on reboot of the hub again. Everytime I update to a hotfix on restart the hub triggers a bunch of automations as if I just arrived. Kinda annoying.

thanks for reminding me to look into it...

@mike.maxwell

I keep getting these errors on the logs for v4 of the arrival sensor after the latest update, are these anything to worry about?

dev:XXXX2019-03-24 10:50:06.084 pm errorgroovy.lang.MissingMethodException: No signature of method: stPresenceV4.checkPresenceCallback() is applicable for argument types: () values: [] (checkPresenceCallback)

I don't seem to have any issues though with both of my arrival sensors, I even removed and repaired them but still getting the same errors.

Which SW version?
I have not yet updated as I'm away for the weekend. But have not seen that until the version I had.

It looks like an application is trying to run that method in the driver, that method has never existed in any of our drivers.
What apps are using this device?

I'll have to check when I get home tonight to see, I don't think I have any custom apps using that device but I'll check to make sure

@mike.maxwell
I only have a RM rule setup on this device for now, plan on using it with my RM rules for presence at some point but haven't set that up yet:

dev:10002019-03-25 09:23:06.083 pm errorgroovy.lang.MissingMethodException: No signature of method: stPresenceV4.checkPresenceCallback() is applicable for argument types: () values: (checkPresenceCallback)

This error is showing every minute in the logs.

Extremely basic rule to tell me when this device isn't responding anymore:

I figured it out, not sure what this scheduled job is from for CheckPresenseCallback:

I removed/readded the device with replacing the battery and seemed to fix it. I remember using a custom driver previously and did remove/readd both of my ST Presense Sensors to use the new driver on the last update but not sure that was still happening to both of these devices.

That job was added when you switched to the st driver, I didn't ask that question since you told me that you rejoined the device and we're still having the issue...

How accurate and reliable are these sensors? I'm trying to come up with a solution for my parents when they visit or look after our house while we are gone.

They work well but range is not very good. You should have a zigbee repeater near the front of the house or door like an Xbee3.
Battery life is not great either I modded mine some with 2 AA batteries in my son's backpack and others to 5 volts in my cars.

I also use life360 app on our phones.

Think about what it is, and you can calculate the answer.

They are Zigbee devices joined to your Zigbee network. Therefore it's access to your Zigbee network is almost 100% of the answer. Yes, battery is a factor.. those 2032 batteries are small relative to the job of pinging your Zigbee network every few seconds. If space permits, an external battery upgrade is a great idea.

Let me say the same thing another way... If you're Zigbee network is weak in the direction you're expecting the Fob to be using, then your accuracy and reliability plummet. Add Zigbee repeaters to extend the strong part of your network, and accuracy and reliability improve.

I have one, unmodified, in each car. I'm on the 2nd battery (factory + a brand new) and they are 90% and working into month 2. They tell me when the car is inside the garage or on the driveway, that's it.

Okay, how about battery life? I'm thinking of giving one to my father.

I’ve only had my set for 6-7 weeks. I think the battery kinda sucks going by others needing to add AA packs externally

If you find an Iris key fob, the 4 buttons, the battery last better than the ST, and it has 4 buttons so you can try.

My ST sensors has been very stable, I have 3 with the 2 AA mod(in the cars), and one stock, the battery last like 3 months, depending how long it spends time in home. I have 2 Iris fobs.

Does anyone have a lead on a decent price for a pack of batteries for these?