Hey Guys,
Just an observation, but the button item (the switch with button mappings) does not return to OFF like it should (according to the docs) in iOS. The item works fine in chrome.
Maybe somebody could have a look at this.
Hey Guys,
Just an observation, but the button item (the switch with button mappings) does not return to OFF like it should (according to the docs) in iOS. The item works fine in chrome.
Maybe somebody could have a look at this.
Hi @psych
Are you talking about a push button with a single mapping? Could you post your item definition and sitemap placement?
And which versions of openHAB and the iOS app are you running?
This is my config:
Text label="Misc" icon="settings" {
Group item=Batteries label="Battery Levels" icon="battery"
Switch item=Test_Button mappings=[ON:OFF="On"]
Input item=Test_Label label="Test Label" icon="text" inputHint="text"
}
Switch Test_Button "Test Button"
String Test_Label "Test Label"
I am using OH 5.1 and iOS app version 3.1.42 (99)
I’m also on OH 5.1, but am using the TestFlight version 3.1.45 of the iOS app – which has been and is currently getting great new features and under the hood modernisation.
So with versions 3.1.45 at least
Switch item=Test_Button mappings=[ON:OFF="On"]
should work as expected, as long as you don’t have {autoupdate="false"} for the Test_Button item definition.
Thanks Hans,
So I am assuming the TestFlight version is like the beta of the next release? So I can just wait for that version to be the live version and everything will be fixed?
The items and the sitemap definition I posted earlier are exactly what I am testing right now, so no autoupdate parameters.
Either wait for the next official release, or also install the TestFlight version, which helps in finding any possible issues when you give feedback about it before any release in the App Store.
I am tempted to try that, just to confirm it actually works on my handset, lol (not saying you didnt test it, but just to be sure)
It would seem I need an invite link to try any beta versions
You can always just reinstall the official release from the App Store if you think the TestFlight version is not for you, while still keeping all of your settings. So not really scary at all, and the TestFlight version is indicated by a small yellow dot in front of its name ![]()
What if you go to the IOS app’s GitHub page on your iPhone
then scroll down to the TestFlight section and click on the TestFlight link or icon. That is, once you have installed the TestFlight app on your iPhone beforehand.
Good job I checked, because it still does not work. Item changes to ON but doesn’t return to OFF as it should.
So weird, it is working fine for me.
Are you using the actual Sitemap view in the iOS app, or possibly the web view?
I’ve just installed openhab on my works iphone, and its still not working. So that’s 2 handsets.
Are you sure when you are testing it that the switch returns to off in the logs? (or you can tell because the switch icon stays green, it should return to red)
I was actually only talking about the push button state as is, as I don’t use any of the default icons and do not change any icon colour with push buttons. But you are correct, in the Karaf console I can see that the state stays ON - so {autoupdate="false"} should be assigned to the Switch item. I did have this before, but it then has a wrong behaviour in the BasicUI in any web browser - well, I tested with Safari and Firefox on macOS only.
So with {autoupdate="false"} on the Item definition, does it behave correctly for you in the IOS app. Then the BasicUI behaviour in browsers might be an issue to log, unless we both need to update to OH 5.1.1 where this might have been addressed, although I could see anything when. quickly skimming the release notes.
No, it still does not return to OFF.
As far as chrome is concerned, the behaviour works exactly as expected, press on, release off.
Correct, also in Safari and Firefox. What I was seeing was the actual behaviour of the iOS app, keeping the stat as ON, then showing a selected coloured push button in the web browsers. And as my rules only ever get triggered by command ON, everything also workd=ed fine there, even if the state was constantly ON ![]()
Nice catch!
There should be a new TestFlight version available tomorrow. Let’s see if anything changed there. I will also see if the big change for the Sitemap view controller is already testable
as this should be where this issue should be addressed for any future releases.
So should this be reported somewhere?
I commented the future Sitemap View Controller PR, with the correct expected behaviour might already making it into the current next TestFlight releases.
I still recommend {autoupdate="false"} for the Item definition, as in case of sending a programmatically ON command to the item won’t take the sitemap mapping into account and then also keep the state as ON.
I thought so, but then the actual click behaviour is messed up - in the currently working web browsers ![]()
@rlkoshak Any comment on this? As I remember this mappings=[ON:OFF="On"] push button behaviour is quote newish, and you even suggested an expire of 1 second not too long again, before it was implemented.
But now this stump mapping works fine when the push button is clicked in the sitemap on any browser, but gets mended up with {autoupdate="false"} which would be required when programmatically sending an ON command to the item.
Any chance of getting both work work as previously – I cannot remember quite in which past OH version – or would a slightly delayed OFF command now be required for any programmatically triggering a push button.
Not really. I haven’t used sitemaps in years and have never used the iOS app. Unlike MainUI, sitemaps are rendered by the apps directly. So when you look at it a browser you are seeing the sitemap rendered by BasicUI but the iOS app has it’s own rendering of the sitemaps. So comparing the behaviors between the two isn’t super useful except to find differences between the two and posting an issue if there are differences.
If it behaves differently, an issue should be filed on one or the other. Probably the iOS app since that’s the one that recently went through a major rewrite. And the docs for the app apparently indicate that it’s supposed to return to OFF.
By default autoupdate is set to true.
If this is truly intended to be a stateless push button autoupdate must be set to false. The widget should show the current state of the button through the coloring of the button. When autoupdate is true (or absent which is the same thing) autoupdate will predict the new state for the Item and change it’s state based on that prediction.
So the flow will be:
Sitemap sends OFF command → Item receives command → autoupdate predicts Item will become OFF → Item will update the Item to OFF → sitemap continues to render the button showing the Item’s state is OFF.
With autoupdate set to false the flow will be
Sitemap sends OFF command → Item receives command → based on the docs, the sitemap returns the color of the button to the “not selected” color
If I did so not too long before it was implemented was years ago. I do not remember commenting on this, but there is more in this world I’ve forgotten than I remember.