Didn’t know they’d brought out a new model. Looks good! Looks like it fixes a few of my complaints with the old ones
The increased accuracy means the way the data is encoded won’t be the same. Afraid I probably won’t be buying one any time soon so won’t be able to make the change myself.
We now have both a regular Tilt and “Tilt Pro” that is identical data format except the Tilt Pro has an extra decimal in both the temperature and SG. This means to read it correctly, the software needs to divide by 10 for temperature and divide by 10000 for SG. The way I have it setup for our software to determine if a Tilt is a standard Tilt or Tilt Pro is to look at the SG and if it’s below 5000, it is a standard Tilt and if 5000 or above it is a Tilt Pro.
We’re waiting for our Tilt to arrive, and then we’ll pick up some development work for it.
Ah interesting. I wonder why its not picking up, then. Are they using the same device IDs? I guess it could be picking up but the data’s being dropped because it’s out of range of the filtering we added. @Ash Could you check the logs to see if the service is finding the Tilt?
Yes I can post the log. Appears to me that the decimal point is in the wrong place. It’s reading 10.226 instead of 1.0226. Could this be stopping it from showing up?
Yeh. We throw out data thats massively out of range as that usually happens when a packet gets corrupted. It could be fixed with a simple check as @Bob_Steers says. If @Bob_Steers doesn’t get to it, I’ll pick it up one evening/this weekend when I have free time. I seem to remember I need to change where the software builds happen for the tilt integration too, though. So might require a little more faff.
For now, if you only have the Pro, and don’t mind seeing offset values, you can also edit the command section for the tilt config in docker-compose.yml, and edit the bounds.
Edit the file, and add command: --lower-bound=5 --upper-bound=100