OH 4.3.0-SNAPSHOT Overview with oh-cell popups crashes Android App and browser

Mark_VG · July 27, 2024, 1:49pm

Hi All

I have raised this question before, but was not able to solve it. I have however started looking at the issue again and thought it best to start a new thread. The one reason I gave up has been addressed (Setting Variables on Overview page), So I thought to try resolve again.

I have an Overview page with multiple oh-cell components that link to various f-popup when the oh-cell is activated.

I have a wall mounted Android Tablet running the latest version of the Android App, usually open on the Overview page.

I have noticed that regularly the Android App stops responding and eventually closes.

I have narrowed this down to two “widgets” which when open have some animation and charting, so assume that it is a resourcing issue - even though these components “shouldn’t” be using resources until opened.

I have narrowed down to these two "widgets by removing them from the Overview page completely and when they are removed the issue does not occur.

As a part of diagnosing I have used the Developer Tools to investigate the page (while the oh-cell is closed.

The component output is:

<div>
	<div class="block" style="--cell-green: rgba(165,236,176,255); --cell-red: rgba(255,156,151,255); --cell-yellow: rgba(254,229,128,255); height: 100%; margin: 0px; padding: 0px; position: absolute; width: 100%;"/>
	<div class="block" style="bottom: 5px; left: 0px; margin: 0px; padding: 0px; position: absolute; width: 100%;">
		<a href="#" data-popup=".sunSynk-pop" class="button popup-open" action="variable" actionvariable="visibleSunSynkPop" actionvariablevalue="true" slot="default" style="height: 100%; width: 100%;">
			<span>OPEN</span>
		</a>
	</div>
	<div class="popup sunSynk-pop" style="--f7-popup-tablet-height: 720px; --f7-popup-tablet-width: 360px; background-color: rgb(220, 220, 220); border-radius: 30px; height: 720px; text-overflow: ellipsis; width: 360px;">
		<!---->
	</div>
</div>

This shows no evidence of the actual popup as far as I can tell.

Also, there is no evidence of the actual popup:

Until I “OPEN” the popup:

As an additional measure I have also ensured that the child f7-block of the f7-popup is not visible.

    - component: f7-popup
      config:
        class: sunSynk-pop
        style:
          --f7-popup-tablet-height: 720px
          --f7-popup-tablet-width: 360px
          background-color: rgb(220,220,220)
          border-radius: 30px
          height: 720px
          text-overflow: ellipsis
          width: 360px
      slots:
        default:
          - component: f7-block
            config:
              popupClose: .sunSynk-pop
              style:
                --f7-popup-tablet-height: 720px
                --f7-popup-tablet-width: 360px
                background-color: rgb(220,220,220)
                border-radius: 30px
                height: 720px
                margin: 0
                padding: 0
                text-overflow: ellipsis
                width: 360px
              visible: =(vars.visibleSunSynkPop) == true

The original topic I created is: OH4: Overview Page with widgets causing Android App to Crash (Suspected)

The full widget code for the two “offending” oh-cell are as follows:

SunSynk Summary.txt (37.2 KB)
Mains TOTAL Energy.txt (13.0 KB)
And a simple template I used to test the “hidden” block is:
Template for Hide.txt (4.2 KB)

The animated widget looks as follows:

Sunsynk Animation

I accept that the tablet I am using may be running out of resources, I just cannot work out why that would be a problem if the “offending” components are not being rendered at all?

Would really love to get some advise on how to debug and resolve this further.

Thanks
Mark

JustinG · July 27, 2024, 3:34pm

Chrome based browsers (and possibly FireFox, but I don’t know) have a built in task manager which will easily let you see the memory and processor loads of each individual tab. If this is a resource issue than you should be able to see those values growing over time when the cells are on the page.

Your animation is an svg. The whole point of svgs is that they are not resource intensive so I would be surprised if this is ultimately the issue. But it’s hard to say sometimes with the various optimizations made for mobile browsers. So the other thing you can do is leave the oh-cell in place, but remove the whole svg part of the tree (or even just the animate directives) and see if that alleviates the issue as well, then you’ll know for sure whether it’s the animation or something else.

Mark_VG · July 28, 2024, 6:49am

The task manager only seems to be available on the desktop version. I have however run it there and do not see any change:

Started with:

Any just now (12 hours later):

I will try this now and report back.

In the meantime I have been running the Overview page in a Chrome Browser on the tablet to rule out the App, and see the same - The Browser eventually shows the “AW Snap” error. So confirm/assume this is not an APP issue

What I really don’t understand though is why this happens if the cell is closed and the contents not visisble?

JustinG · July 28, 2024, 7:18pm

Yeah, mobile debugging is difficult. In most cases it cannot be done directly and you have to connect the mobile browser or app to a desktop environment and arrange to have debugging running on the desktop. I had hoped if the problem was something obvious like this you would still see the growth in the desktop task manager even though that doesn’t run out of resources as easily as the mobile.

Well, that’s informative at least.

If the cell has visible false, then it is not even rendered by the Vue processing. This means that it is not a part of the final html of the page and not an accessible element in the DOM. Notably, however, this does not guarantee that the entire thing is ignored. In deed, for example, the visible property itself must be processed. So there it a chance that somewhere there’s a memory leak that is still being engaged even if the rest of the component is not fully rendered in the end.

Do you have to open the cell at any point before this happens or will it happen if you just load the page and have no further interaction with the page at all?

Mark_VG · July 30, 2024, 7:58am

Happens even if you do not open the cell at all.

I have done some more testing as follows:

I removed the animation from the SunSynk widget ( at the same time I removed the Monthly Power Widget) to try and limit interaction between the two.

With no animation I did not get any crashes etc.

Next step was to put back the Monthly Power Widget, again after about 90 minutes the page crashed.

I then realized that my visible: statement was on the incorrect block in this widget, so I corrected and tried again and again after 90 minutes or so the page crashed.

Next step was to use visible:false for the entire popup block.

This time no crash for many hours. This led me to realise that my expression was not working correctly as I was clearing my variable and not setting to false

So I have now updated the widget to have visible: false unless the actual f7-popup is open. This seems to be working now - just waiting for a few more hours to confirm.

So lessons learned so far:

Closed popups can still consume resources
visible: seems to ignore anything other than false, so clearing a variable is not going to trigger the visible condition. (Test Widget to demo widget_test_variable.txt (1.5 KB)
)

Will report back later with update

JustinG · July 30, 2024, 3:22pm

It’s still a little strange to me that simple svg handling should be causing the issue to begin with. So I went back and looked more carefully at your SunSynk widget. I note that you have a mixture of the two different methods of getting arbitrary tags:

- component: f7-row
  config:
    tag: TagName

and

- component: TagName

I wonder if the underlying crash problem isn’t related to the use of the f7-row method. When you just put the tag name as the component, the OH vue renders it directly. When you use the f7-row method, it has to go through the f7 library first. I have no idea what the f7 library does in terms of computation to go from f7-row → arbitrary tag, but it is already, by definition less direct and therefore more computationally intensive than not using the f7 library at all.

If you go back through and carefully convert all the f7-row components to direct tags, does that get the animation to stop crashing the page in the first place, even when it’s just left running?

Mark_VG · July 30, 2024, 4:44pm

Thanks Justin.

I have been focusing on the Energy widget as that seems to cause the issue much sooner than tthe SunSynk widget. Will give your suggestions a go and see. It just takes a while before is crashes when not using the Energy widget.

The visible workaround seems to be working so far though.

supersjel · August 23, 2024, 6:12pm

Interesting, found this topic while searching for my issue. Not completely the same but I upgraded to openhab 4.2 and noticed my browser crashes after 12 to 24 hrs. In 4.1 it would run one to two weeks before this happened. I also got a wall mounted screen with one dashboard with a lot of popups (with charts, no svg animations but they run on a canvas if you look in the html code). I already noticed in debug mode (on a laptop) that these load data when you don’t expect it.

So if I understand right your workaround is using the visible option. I’ll give that a go. Will also check memory usage.

edit: memory (on a laptop) seems stable (2 hrs test). 350-360 mb. So same as above. Next step to follow your quest. Copy my dashboard and remove all popup’s and see if this runs stable.

Edit 2: unfortunately no difference so my issue must be something else. Will try your approach to disable widgets one by one to see if it’s content related.

Edit 3 Maybe too soon. Found another popup ;-). Running for 8 hrs now …

Mark_VG · August 23, 2024, 6:59pm

Yes. Since i implemented a working visible exoression i have not seen the issue.

supersjel · August 26, 2024, 7:08pm

@Mark_VG. Still running so seems to be the same issue. I tried your solution inline (i.e. in one widget), in that case as soon as a formula is used for the visible property it loads the entire tree (including popup). Is that the reason you put the popup in a separate widget and include it with the component:widget: name?

Mark_VG · August 27, 2024, 5:37am

Not what I saw. Once I had a correct expression for the visible property I have not seen the issue again.

That was my first attempt at a solution - but found that the issue still occurred so when back to the all in one version

supersjel · August 28, 2024, 9:31am

Thanx. As for the visible/tree loading, maybe it’s my 4.2 versus your 4.3. Or it depends if you check in the widget editor or the final dashboard, Or… Doesn’t really matter, if it’s solves the crashing it’s ok for me.

Good that a separate widget isn’t needed, it complicates the configuration.

I’m working on a setup for my case. Testing will take a long time I fear. If you’re interested, main elements are:

A string item with an expiration timer that sets it to ‘OFF’.
Pressing the button will activate the F7-popup and set the string item to a unique value (examples dimmer itemname or color itemname). I use this item and value in visible (popup content) AND the opened (popup itself). Of course this fits my usecase, it can only work if you got one single page dashoard running on one device (because with only one item only one popup can be active at a time)
For the chart popups I use an additional variable that is used in the key (to force a refresh). Only when opening the popup I fill this variable with the actual value of the refresh timer item. This is a second way to prevent invisible popup charts from loading data. And of course the above setup to also set visible/opened.
I also changed my clock/date widget with a piece of javascript that will force a page refresh somewhere between 2-3 at night (I run my dashboard in a plain chrome browser). Got that working, not sure if I’m going to use it, but if this is some kind of running out of resources (looking at the error threads or connections) this will free them once a day. But let first see what the other two do.

Done with the switch/dimmer/color widget for switches and lights. Working on the chart popups that I use in several widgets (more work). And then start testing/optimizing. When done I will let you know if I also found a working solution. The dashboard without popups is still running at the moment, so I’m confident the cause has to do with the popups. So thanks again for your investigation to pinpoint this issue.

edit: cooked something, seems ok but let’s see how it holds the next days. Changed approach a little, also put the popup-key-timer in an item (no variable). And ditched the “popoverOpen” for the “opened” property to open the popup. The popoverOpen (or maybe the place of the popup code in the tree, changed that in one go) forced loading of all popup chart data if you opened just one popup. Using the opened just loads the chart data for the relevant popup so worked better. So the oh-link changes the value of the popup item, and the opened property in the popup looks at this item (value==my-name). Important is to also add the target property in the popup to get it in the right position. If it all really works I’ll dump the code/setup.