Very strange, now i get a real time, but i don´t have any alarm times at this time… Look at the miliseconds from the datetime-item - i can´t set an alarm to this time with .160 miliseconds.
Last week when i tested this last, date was ok but time was always 00:00
First line of the log is the miliseconds since 1972? (is this called epoch time or joda time???) and second log line is the readable format as datetime.
Both 102 and 102.0 are correct behavior in that case…that’s a statement I got from @Kai in the past; I just can’t find the reference at this moment :-/
The bindings are supposed to deal with that correctly. In what case does this not work for you? I remember the KNX binding receiving a fix for this lately. In case you’re dealing with a broken binding, you can work around this by adding integer formatting to the item’s label (“My Item [℅d]”).
Thanks for this update, great improvement and it looks great. There is one thing I’m really missing compared with the previous version: The oled dark theme. On oled screens black is not really black when using the current dark theme.
Not sure if android’s dark mode changes anything here, but if it does androids dark mode is still not available in older android versions (AFAIK). Any ideas how to get oled dark mode with the current app?
Now i can see com.alarmclock.xtreme in the log, this is my alarm-app on my android phone.
I set up a new alarmtime on my phone in about 2 hours - It changed to the new alarm time inside openhab.
After that, i deactivated the alarm in 2 hours and my next alarm is tomorrow morning in about 22h. I can see in the log: com.android.providers.calendar, igrnoring
–> The alarm inside openhab is still on the old alarm in about 2h - but this alarm is not active on my phone anymore…
So i can say, it is working only partly with your changes.
The Android dark mode is basically a global switch between light and dark theme for all apps. For Android versions that don’t have this dark mode, the battery saver controls if the app is bright or dark.
It would need to implemented in the app. I haven’t seen many apps with amoled themes, so I’m not sure if this is wanted by many people.
I see. Let’s say you have the following alarms. Current time is 7:00.
9:00 ignored alarm
12:00 alarm
Create an alarm at 8:00 and the app will send this alarm to the server as it’s the next alarm and not ignored.
Delete this alarm and the app won’t send the 12:00 alarm to the server as the next alarm is at 9:00 (earlier than 12:00), but ignored.
It’s only possible to get the next alarm. So the app cannot know about alarms after the ignored one.
I can think of storing the sent alarm time and if the next alarm clock changes, check if the previous alarm was reached and executed or not reached and thus canceled. If canceled, send 0 as alarm time to cancel server-side alarms.
The optical experience when it’s dark, is major. I have a Galaxy Tab S2 on the wall. With the old version with Oled/amoled theme the background is invisible. With the new app it looks like a bad LCD TV with a lot of back light bleeding. I haven’t looked at the code yet, but would it be hard to implement?
It’s not hard per se, it’s just quite a bit of boring and annoying theming work, as we can’t use a Google provided base theme for that…Google’s base theme for the ‘night’ mode provides that dark gray background.
Maybe it’s just a matter of getting used to the changed look though?
(BTW, I wonder … did we really use black as background color for the frame background ‘cards’? I thought it also was a dark gray, something among the lines of #111111)
But the ignored alarm is no real alarm… I don´t know, why there is this alarm at this time…
But the old alarm stays in the item, the alarm time of the removed alarm is over but there is no new alarm time… So i can still see the old alarm from yesterday in openhab log.
The current official (non-beta) version 2.8.0 is running nicely on it. But the the installation of the current beta from f-droid is throwing a minimum-sdk-error.
While I can understand to abandon support for stone age Android versions, I’d be really happy to prolong the life of it…
So, what’s the current minimum api version?
If higher than mentioned above, is there a technical reason which prevents you from supporting older api phones?
:
