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.
Hi mueller-ma,
I’m having issues installing the current beta on my desk phone while trying to install from f-droid.
Unfortunately, my beloved phone is still on Android 4.2.2 and will never get an update again from the manufacturer 
:
You said last year:
… is this still valid?
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?
It’s 19 (Android 4.4).
Yes. We fixed video views, and for that we needed a library which requires API 19. See Use new androidx.media2 video playback library by maniac103 · Pull Request #1503 · openhab/openhab-android · GitHub
Please also note we’ll bump the min API level to 21 (Android 5.0) soon … see [SOLVED] Raise minimum supported Android version to Android 5 for the rationale.
O.k. got it. Thank’s for clarifying 
I know, it’s been a while now:
Short question: Do you plan to implement a way to select/open a sitemap/frame from Tasker via the plugin? Or is this yet possible?
It’s not yet planned. Can you open a feature request on Github?
I´m on 2.9.11 beta now and i see in the log:
Alarm sent by com.android.calendar
I get 25.10.2019 00:00 as my next alarm time.
That´s not correct, my next alarm time is 25.10.2019 06:15
Can you set this to ignore too?
Yes, I can do that. Any other packages you see in the logs?
At the moment this is the only one.
Is there a reason, why sometimes there are 3 assets on the release-download-page in github and sometimes there are only 2 files available (sourcecode).
For the latest release 2.10.1 beta there is no apk-file provided.
EDIT: Strange, now i get 3 files ant there is a apk too.
Do i have to wait some time when you provide a new version, until there is an apk-file?
Sometimes the UI tests fail and this causes the complete build job fail. In this case, no apk is uploaded.
I usually retrigger the build than.
I tried 2.20.2 beta now.
My old alarm inside openhab was the false one from the calendar, 31-10-2019 — 00:00
I made a new alarm inside my alarm clock app at today 14:00 and i got the new alarm time provided into openhab with 30-10-2019 — 14:00
This is working.
After that, i removed the alarm at 14:00 o´clock and i was able to see a ignoring for com.android.calendar
So still the old alarmtime at 14:00 is visible.
And that is the problem. Is there a way to get the next alarm from my alarm clock instead of ignoring the calendar-alarm?
So it is not usable, because i only get a real alarm time inside openhab, when there is a real alarm between now and midnight. When the next real alarm is tomorrow morning, i think i will get the real alarm time at midnight… Because for the openhab-app the next alarm is the false one from the calendar which is ignored. --> So there is no change for the openhab-alarm-item.
Maybe a solution could be, to edit myself inside the openhab-app, which android-service is providing the real alarm times. Then the openhab-app could listen only to this service and you don´t need to ignore the other ones? Maybe this could be a solution? Don´t know, if this could help.
Pumpkins! Very good! 
3 Likes
I did not know that coders also doing jokes 
At first I thought my Pi was hacked …
So @mueller-ma did seemingly a good job 
Thanks for this!
1 Like
I have a PR that adds a switch in the settings to show/hide the sitemaps in the drawer. The sitemaps are hidden by default.
This feature has two advantages:
- Sitemaps aren’t presented as a navigation element. It’s not possible to switch between Sitemap in other UIs, like Basic UI, and thus everything should be on one sitemap.
- It makes them less discoverable for your non-tech-savvy family members
I want to get some feedback on this. Should I make the sitemaps shown by default when upgrading?