Im fine really, my wishes above are in no way crucial
for the sake of being 100% clear: no, I am not referring to the icon interface here, but to the image interface we get when we click ‘Afbeelding wijzigen’ (change entity picture/image).
I understand. But what I meant was, the example you gave was not showing an image file, but an MDI, which is different.
uhm yes it was?
this is the configuration for the picture:
and this is how it shows in the Areas overview:
click through to the actual Area
not here to argue though, so please keep it as you desire.
Ok, I got confused because you also had an icon selected, which is MDI (and I don’t read Dutch, and I’ve never used that feature for an area.)
So, that is somewhat equivalent to the file upload option I already added, albeit it doesn’t show a previously uploaded image file, nor does it show a new image if you select one (it just shows the file name.) So, for areas, that must be a special frontend function. The standard file upload selector apparently doesn’t do that. And, again, I don’t know how to make it do so, if there is a way. I suppose I can look at the area config flow code to see what it does, but no promises.
Released 3.4.0b1
Released 3.4.0
Enhance “last seen” attribute processing to allow a datetime string format. Basically, these attributes (last_seen or last_timestamp) can be any one of the following:
- a naive Python
datetimeobject which is assumed to be in HA’s configured time zone - an aware Python
datetimeobject in any time zone - anything
homeassistant.util.dt.utc_from_timestampwill accept (after being converted to afloat) - anything
homeassistant.util.dt.parse_datetimewill accept
Also, back out support for last_located (added in 3.4.0b0) since iCloud3 is being changed to provide a last_timestamp attribute that satisfies the above.
Released 3.4.2
Originally input entities were checked at startup before possibly restoring state of the composite entity. This could cause an input entity with data older than the most recent data the composite used before shutdown to temporarily cause the composite to use that old data and abort the restore process. However, the restore process should happen first, so that input data older than the restored state can be properly reject. This release reverses those processes so that restoring happens first.
Previously released 3.4.1
Import cached_property from functools instead of backports.
EDIT: NEVERMIND. THINK I FOUND IT. I HAD MY SPEED AT 0MPH OPPOSED TO IT JUST BEING EMPTY
Hey Phil, whys is my composite showing as driving when all the trackers are showing away? (My bluetooth on phone is not connected to anything either). I am not sure what the ‘Use all states’ box means so I may have something wrong there?
So for the use all states , in my case I have 3 GPS (HA app, google, traccar) and one non-gps (ping).
Since I have ping set to use all states, if my ping shows me away but all my GPS devices show me home, my composite will be show away?
If I turn all states OFF on ping, then in above scenario, my composite would still show me home?
I also have question on the moving option. I must not be understanding something. It says it will ignore an update from a GPS device if the coordinates have not changed (or changed enough I guess). But what im confused about is if the coordinates haven’t changed, the GPS device would report me in the same zone I was already reported in. So why does it matter if it re-reports to same information?
Yes, until one of the GPS entities updates and shows you home again.
Yes.
In your situation, which is the norm, you should remove all the inputs from the Use All States option. The GPS based inputs use all states anyway, and generally ping entities are terrible at changing to away (i.e., not_home) at the right time, which is why composite doesn’t use those states by default.
Composite does not use the state/zone of a GPS input; it only uses the coordinates & accuracy. The HA decides which zone the composite may be in and sets its state accordingly.
The “require movement” option is for scenarios when the composite uses more than one input, and it’s possible some of the input devices leave home with you, but others are (possibly accidentally) left behind at home (or any location, for that matter.) Without this option the composite would constantly switch between the two locations (where the device or devices are that are with you, and the other device or devices that are left behind somewhere.) By using this option, composite will ignore the devices that aren’t moving.
EDIT:
To add to what I said above, if all the inputs are tied to the same device (i.e., different tracker mechanisms for the same device, using the same GPS data), then require movement really doesn’t matter.
2 Likes
Released 3.4.3b0
Released 3.4.3
Fix new error w/ HA 2024.8
- Apparently, it’s no longer allowed to call
async_get_hassindirectly viaCONFIG_SCHEMA, so move YAML config processing to config.py. - Also, a couple other minor fixes/improvements.
Starting with HA 2024.8, if you use YAML configuration, and if you use entity_picture in that configuration, the integration will not load. This release should fix that problem.
If anyone has experienced that problem, please try this beta release and let me know if it fixes it. Thanks!
Released 3.4.4
Add missing PACKAGE_MERGE_HINT to config.py.
Released 3.4.5b0
- Use UTC datetimes internally to avoid DST → Standard Time issues