Polling isn’t the problem, its how it is polled. You can’t just get all the statuses of the lock in one poll. In order to keep the devicetype up to date, you have to loop through all the statuses, lock, codes, battery status, etc. and that’s how the devicetype was written.
Battery status is only updated once out of like 50 polls. However, you can hard code a battery poll, but this would be overkill, since excessive polling can lead to battery drain…
I suspect that everytime the platform resets (has been a lot lately) the polling sequence starts over, so battery can take a day or more to update, and if the devicetype resets, it may never get updated. As it is one of the last poll items to get refreshed, after user codes.
Anyway, I’m not a zwave expert, but this is how it was explained to me.
Zwave has alarm codes, 167 = battery low, 168 = battery crit, 169 = battery too low to operate.
However, ST has a zwave function to get battery level response(secure(zwave.batteryV1.batteryGet())) which should get the actual value, but will only be called if alarm 167 is the case.
Also, look at the poll section, every hour a single code is checked, it could take days to get to the battery code, if ever.