Open Waldzio opened 6 months ago
I'm wondering if you carry LYWSD02 in your travel case, or live on a boat. 😅
That aside, tz_offset
is implemented by LYWSD02 on its own and it doesn't seem to support fractional hours. There are 2 ways around it:
tz_offset
to the timestamp value before writing it into LYWSD02, such that LYWSD02 always would think that tz_offset
is 0
. Probably the best thing so that it'd be easier to use this integration, but would require changes to the integration and I don't have leeway this very moment.timestamp
parameter. So set your tz_offset
to 0, but instead don't rely on the default value of the timestamp
parameter, but rather compute it on your own. E.g., start with {{ utcnow().timestamp()|int }}
and add/substract the computed offset value in seconds and pass it as the timestamp
parameter's value. I'd imagine something like {{ utcnow().timestamp()|int + (state_attr('sensor.z_flip_5_sm_f731b_current_time_zone', 'utc_offset') | int // 1000 -1) }}
Hello, thank you very much for this integration. It's very useful because I travel a lot by sea. I often change time zones, but not always according to the actual location; sometimes I do it earlier or later depending on how long we'll be at sea.
That's why I set the time zone on my phone, and I would like the watches to immediately synchronize with the time zone set on my phone. It works great, but the watches act up when we're in places like Sri Lanka, where it's GMT+05:30.
Unfortunately, your service doesn't accept tz_offset: 5.5.
Generally, my automation looks like this:
It works only with full hour offset, but even manual invocation doesn't work anymore:
Do you think you could somehow add the ability to handle tz_offset in the format X.X?
Thanks, Waldek B.