Any consideration to adding the Structure ETA (write only) capability so one can set these parameters via the binding? Also eta_begin (read_only) to check that ETA is active?
Cheers!
Mike
Yes it’s still unsupported. Haven’t ever used it myself so I’m no hands on expert and also don’t know if you can add several ETAs at the same time. My first impression is always that it’s not straightforwardly mapped to a few additional thing channels.
Wouter,
From how I interpret the API documentation, it’s a property of the Structure and thus there is only one ETA. When one is away from the Structure, one can set an ETA window in the future. Then, once that time window triggers, eta_begin gets set.
I would use it to set an estimated return time so that when I’m traveling I have a “failsafe” in case I don’t have network or location services (e.g., I’m in a plane) for when the house needs to bring it’s devices back to active (e.g., the AC/Heat needs to come on in time to get the house to temperature).
Mike
I agree it’s definitely useful functionality when travelling. 
The binding already supports reading eta_begin. The API doesn’t seem to allow for reading the other ETA values.
A possible implementation could be handling DateTime commands on to the existing eta_begin channel so
- trip_id: some hard coded value
- estimated_arrival_window_begin: the value of the command send to the
eta_beginchannel - estimated_arrival_window_end: calculated value
command value + configurated duration, whereconfigurated durationis a channel configuration parameter
Though that approach will not support multiple structure inhabitants sending their ETAs using different trip IDs.
Nest may store all trips in a database and use these to determine when to start heating/cooling.
If that needs to be supported the channel would have to handle commands with strings containing several (e.g. comma separated) values. 
The Away Guide suggests Nest stores all ETAs:
ETA is independent of home state. If the arrival time of an ETA conflicts with another ETA, the earliest arrival time takes precedence.
eta_begin is READ_ONLY. It only gets set by Nest when an ETA begin/end period has been triggered. Strangely, the other ETA fields are WRITE_ONLY (i.e., the values one sets cannot be queried from Nest. Now that you describe it, it does seems that there can be multiple trip IDs with their own ETA begin & end values. However, without being able to read, it appears that tracking the trip IDs and their respective begin/end values needs to be done by the user’s application (i.e., me within my openHAB rules).