I’d like to second the question. I set up a tile and I’ve been looking all over the place and can’t seem to find it…
Once enabled, you need to configure your device. Pull down twice, edit, and add the tile.
2 Likes
I love it, really. I think it’s very good idea to switch on/off some light or the tv easily.
Wow… this is awesome… really like that feature! 
Thank you for adding this!
1 Like
This is a great feature and we’ll implemented. My only critique is that, when arranging tiles, they display as Tile 1, Tile 2, etc., instead of the name. But once arranged, they display the name. Not a big deal, but the only thing lacking polish.
1 Like
Yep, that’s what I’m doing. Nothing there. Only loads of other tiles.
Any special requirements for Android version or anything like that? This is on Galaxy S10e running Android 10.
edit: Ah, found it! Actually after pulling down twice you have to press the three-dot-menu and select “button order” and then move the OH button down to the active buttons.
I’ve to define the names at compile time. I can only update them during runtime when they’re active (moved to the area where you can use them). This is why they’re named Tile 1 to 12, which is the same name used in the settings.
Android 7 or higher is required. On older versions it’s not possible for apps to defince quick settings tiles.
The exact way may differ on different Android distributions. I tested it with a plain Android by Google: There’s no button called “button order”, but an icon with a pencil.
A TileService provides the user a tile that can be added to Quick Settings. Quick Settings is a space provided that allows the user to change settings and take quick actions without leaving the context of their current app.
from TileService | Android Developers
This is the official naming, but I can add a hint like “[…] Quick Settings, the space where the toggles for Wi-Fi, Bluetooth and more are”.
This is a great feature.
It would be even better if it showed the state. Much like WiFi does.
Is that something the API allows?
The (QS tile) API allows for that, but doing so would require regular polling of the current state from the OH server, which isn’t ideal in terms of battery consumption and data usage.
2 Likes
1 Like
2.13.10-beta adds a setting that will enable listening to events, like Wi-Fi connected, and send updates to associated items. Basically it makes “schedule based” items “event based” ones.
3 Likes
When are we going to support multiple openhab instances with different username password and url?
2 Likes
When I (or somebody else) have time to complete the nontrivial amount of stuff that needs updating in this PR. Multi-server support is quite a niche use case though, so it’s not terribly high on my priority list.
2 Likes
I just tried setting this up, I created an item:
Switch stevephoneChargingState "Steve Phone Charging State [%s]"
And configured the device identifier as “stevephone”, I turned the “Event listener” switch on and switched on the “Charging state” option and left the item name as “ChargingState”. The “Send device information to server” screen looks like this:
If I plug the phone in to charge the phone gets a notification that says:
1 item could not be updated
Item 'stevephoneChargingState' update failed: HTTP code 400
Any suggestions on how I could make it work?
Try using a String item. From the code, the charging state is sent as a string containing the connected charger: https://github.com/openhab/openhab-android/blob/master/mobile/src/main/java/org/openhab/habdroid/background/BackgroundTasksManager.kt#L545
@mueller-ma I think also supporting switch items would make sense here, as ‘charging state’ seems most logically connected to a boolean charging/not charging instead of a string.
Changing the item to a string seems to have fixed it. I can now see the item value changing between UNDEF and AC when I disconnect and connect the charging cable. The contents of events.log looks like this:
2020-07-16 23:58:22.879 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-16 23:58:22.880 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-16 23:59:00.715 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-16 23:59:58.573 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:00:18.491 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:00:22.637 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:00:22.638 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:00:44.014 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:02:12.991 [ome.event.ItemUpdatedEvent] - Item 'stevephoneChargingState' has been updated.
2020-07-17 00:02:55.773 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:02:55.774 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from NULL to AC
2020-07-17 00:02:58.950 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:03:02.557 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:03:02.558 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:03:05.888 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:03:09.378 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:03:59.548 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:03:59.549 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:04:02.313 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:04:05.748 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:04:05.750 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:04:07.903 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:04:21.833 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:04:21.834 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:04:25.128 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:04:29.188 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:04:31.232 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:04:57.599 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:04:57.600 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:05:02.152 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:05:06.884 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:05:06.886 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
2020-07-17 00:05:14.864 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from AC to UNDEF
2020-07-17 00:05:23.280 [ome.event.ItemCommandEvent] - Item 'stevephoneChargingState' received command AC
2020-07-17 00:05:23.282 [vent.ItemStateChangedEvent] - stevephoneChargingState changed from UNDEF to AC
There were a few occasions where connecting or disconnecting the charging cable didn’t change the value of the item though I was connecting and disconnecting very quickly, far more often anyone would do normally. It’s getting a bit late now so I’ll do some more tests tomorrow and see if can find a way to recreate what I’ve seen.
Thanks for the help, this new functionality is great.
I just noticed that if you tap on the question mark on the input box for the event listener item name then a web page with an example rule that describes the different possible charging state item values. They are USB, AC, WIRELESS, UNKNOWN_CHARGER or UNDEF (when the device is not charging).
@mueller-ma I think also supporting switch items would make sense here, as ‘charging state’ seems most logically connected to a boolean charging/not charging instead of a string.
I would agree with this, “charging state” to me means that it’s either charging or not charging, “charging method” might be a more intuitive name. Though, it’s a fairly minor detail and it would be easy to write a rule to set the state of a switch based on whether the chargingstate item is UNDEF or not.
I’m definitely seeing some missing charging events in the events.log on my system here. If connect and disconnect a charging cable or put the phone on a wireless charger and take it off again within ten seconds sometimes the charging state event is not sent. Or not received. Is there a way I can see if the event is attempted to be sent from the phone?
There should be a line in the log of the app whenever a battery or charging action is received by the app. Battery or charging state changed: [...]
Most likely it wasn’t possbile to sent the update in these ten seconds and whenever a new action is received, all pending updates are discarded.
I think a new value type called “OffIfUndef” (or similar) makes sense and can be reused for other use cases, if needed.