Android and IOS 2.0 releases


(Dan Cunningham) #1

I’m am please to announce we have pushed out version 2.0 of our mobile applications.

Our Android client had the most activity with many people contributing. I would especially like to thank @mueller-ma for stepping up with not only code contributions, but reviewing and managing PR’s, tagging issues and other needed house keeping. I would also like to thank maniac103, lolodomo , FlorianSW and boc-tothefuture (github handles) for their contributions and help getting 2.0 out the door! For a full list of changes see https://github.com/openhab/openhab.android/blob/master/CHANGELOG.md .

The IOS client was updated to work with the latest version of IOS, the iPhone X as well as other small fixes.

Both clients now have our updated logos and graphics.

Enjoy!


Announcing openHAB 2.2
(Dries) #2

Awesome, thanks!
I was waiting for several of these improvements.

Keep up the good work!!


(Wouter Born) #3

@digitaldan Thanks for the new release! Is it a known issue that SVG icons are flashing while updates are being processed on Android? Now it is certainly an improvement because previously I didn’t see any SVG icons at all! :wink: I’m on a Google Pixel with Android 8.1.0.


(Dan Cunningham) #4

@wborn go ahead and open a ticket https://github.com/openhab/openhab.android/issues , I’m not sure this is a known issue yet.


(Garry Mitchell) #5

Thanks all for the work on the Android app - I’m in the process of getting stuff set up, and graphs consistently stopped working in the previous version, which was making it difficult! Now, however - seems to be working really nicely!


(Ronny) #6

Would you guy please check this behavior on your Android as well. My devices are running Android 6.0.1


(Steve Higton) #7

Is there a way to have a setpoint item behave as it used to in previous versions? I have setpoints for a few rooms that control volume of the audio zone for that room. Previously I could tap the plus and minus buttons until the volume was sufficient. My sitemap uses a setpoint with a minimum of 0 and a maximum of 70 (so the children can’t really annoy the neighbours) with a step size of 5. Now, I need to go through the tap-to-bring-up-the-setpoint-choices, swipe-to-choose-the-setpoint-value, then tap to set it. If the volume I choose isn’t quite right I have to do that all over again. The plus and minus buttons were perfect for this use case.

Alternatively, is there another way I can replicate the plus and minus button functionality?

The rest of the changes look awesome, many thanks for all the hard work!


(Miika Jukka) #8

+1 to what @higgers is saying. I’m using setpoint item to control the speed of my air ventilation unit so this new control mechanism suits much more better for this kind of ‘selection’. But when you are controlling volume, old style was much more better for that use case. Worked nicely as a traditional remote controller.

But yeah, everything else is spot on!


(Mueller Ma) #9

I opened a issue for that: https://github.com/openhab/openhab.android/issues/541


(Mueller Ma) #10

@higgers @gitMiguel The new option has some advantages over the old one:

  1. Less trafic between app and server
  2. No changes are “lost” when tapping many times
  3. Easier to change a larger difference
  4. Feels more “Android”

(Steve Higton) #11

@mueller-ma I totally understand it’s advantages and I’m not suggesting the behaviour be reverted and the advantages be lost to everyone. I’m asking if there’s a way that the old behaviour can be used if needed. As I described in my post yesterday the new system doesn’t work well for my use case and as @gitMiguel described there are situations where the new system is an improvement (ventilation unit speed) and situations where it’s a regression in functionality (volume control).

If users could choose which behaviour suits their situation that would be perfect.


(Mueller Ma) #12

Not directly, but you could create a switch item with mappings “+” and “-” and than a rule that changes your fan speed item.


(Garry Mitchell) #13

Ah, I didn’t notice that change… and it now works differently to how BasicUI works, which isn’t great if you’ve got people using both…

I’d certainly like the option to select which style to use on an item-by-item basis - do we need a different item type other than just “SetPoint” to differentiate between the two? (I know that this means it’ll need support from as far back up the chain as ESH to do so)


(HomeAutomation) #14

I run in a problem with displaying sitemap correct on the android app.
Roller Shutter items are displayed a little bit strange

a little bit better in horizponal view


Is it planed to solve it in the future?

I use the app 3hou.se on android. This one is much better.


(Maciek B) #15

Where can I download old revision of android app? After upgrade my diagrams are less readable. It looks like font on X and y axis are too big.


(Salexes) #16

Is there a notification center widget planned for iOS for quick access ?


(Manuel Alberto Guerrero Díaz) #17

Thank you very much for these great works.
Excellent app (and excellent openHAB).

I found two bugs in 2.0 Android version:

  1. Sending a voice command by widget throws error. Voice command is successfully sent by remote connection (myopenhab) but app closes showing an error. When local connection to openHAB is available (LAN), app closes showing an error, and no voice command is sent to openHAB.
  2. Rollershutter item icon does not change with height state, as it has always done in previous versions (Classic UI web interface icon shows height state properly).

Bugs found in Android App 2.0