I get bad location updates periodically which result in my device notifying me that it is ‘leaving’ and ‘entering’ my zone via an existing automation
I can access the ‘to’ and ‘from’ latitudes in my automation. I have tested these are accessible by including them in the notification from the automation and they always populate when the automation fires.
I would like to ignore the bad data and it is characterised by impossibly big jumps in location that I could not actually do in the time between updates.
Is there a way I can setup a condition in my automation to ensure, for example, that the automation only runs if the difference between the two latitudes is less than 1 ?
Run automation if (trigger.to_state.attributes.latitude - trigger.from_state.attributes.latitude ) < 1
I am confused if I can achieve this through a value template in a numeric state condition or if I should be doing something else?
No, but the bad values I want to filter out or ignore are crazy bad.
For example, I am in Sydney Australia and the bad values put me off the coast of central america for one GPS update then they jump back to ‘correct values’.
Hence if I can just filter out any updates with big ‘jumps’ I will be fine. I just don’t know the best approach to compare the two ‘from’ and ‘to’ state attribute values in my automation’s condition (trigger.to_state.attributes.latitude and trigger.from_state.attributes.latitude)
I am using a USB connected UBlox GPS receiver that sends its updates in via GPSD - the updates are all coming in okay but I get these odd/invalid ones once in a while.
I think that the reason I see these occasional bad results is that GPSD is sending over (or HA is parsing) an occasional GST message rather than sticking to the location updates (TPV time-position-velocity messages) - the bad values exactly match GST data (down to the time stamp) which is actually a noise report and not a lat/long pair (see here gpsd_json(5))
I thought the easy thing might be to filter out the impossibly big jumps in lat/lon I am seeing but I don’t really know where how to get started in the automation?
Ok lets look at a template condition then. To do this I need:
All your current trigger configuration for the automation.
An example of the state of the trigger entities and their attributes. An obfuscated screenshot from developer tools → states will do. Just don’t obscure the location so much that I can’t see the format of the data.
Could be a GPS tracking server issue, or a local position tracking issue (for instance, when GPS services are jammed).
So I ended up filtering definitely wrong coords (0 with some delta) & coords with gps_accuracy > xxxxx.
Absolutely, because HDOP/VDOP is not accuracy. That’s a very common misconception. The *DOP values basically tell you how ideal the current satellite positions are for trilateration. But it’s only one of many factors that affect the accuracy achieved in practice. DOP does not take into account signal reception fading and noise, multipath reflections (very common in urban environments), atmospheric absorption and refraction, etc. All these will heavily influence the accuracy, but DOP alone can’t tell you that.
I’ve been playing around with some UBlox chips for my embedded boat monitor / tracker and ran into issues like that. UBlox chips actually send a specific accuracy parameter in meters, in additional to the usual NMEA phrases. They perform an internal calculation using DOP, snr, multipath, etc. It’s part of their $PUBX,00 extended NMEA phrases (see specs, page 69). They also send a status / validity flag that tells you exactly the type of lock they have and how reliable it is (2D/3D/DR/RTK/etc).
The Hacc / Vacc params are actually very reliable from my experience. I run the chip on very low power mode with partially updating ephemeris tables and a position every 2 hours in standby mode. The accuracy is about 2.5 to 6m usually according to Hacc, which I can visually confirm as my boat is moored in a fixed position.
Strange that these “zero coords” issues occurred with 2 similar Android devices (Redmi 7A/9A) from 29.11 till 11.12 almost every night ))).
Blaming a Traccar location service - although they say that just using coords reported by a device.
Also could be GPS/GLONASS jamming issues. It’s rashist Russia, you know…
Depends on the GNSS chip you have. Normally these chips will not give you zero coords, they will just give you an invalid lock flag. It’s the software that reads the data from the chip and interprets it that will sometimes put 0 coords in when the lock is lost (which is common, but kinda crappy practice).
A good DOP with no lock usually means that even if the satellites are positioned OK for a lock (good H/V/PDOP), something is wrong with the signal. This can be something harmless like a partially shielded antenna or maybe a thunderstorm in the signal path, or it can be something more nefarious like jamming.
Hmm, these are Chinese mobile phones bought on AliExpress.
They probably have support Beidou.
I’ll will try to check it.
Imho a device which supports several positioning services (gps, glonass, …) probably should have kind of toggles for every service, i.e. you may disable GPS or any other service.
iOS devices seem to be not having these toggles (Apple policy “do not allow users …”).