strange behaviour indeed. I see you are working with some absolute positions, maybe that is causing the issues. You also could consider to use popup instead of expandable card.
anyway, a very nice widget. i have a watering system in my garden as well and need to start working on a widget soon as spring is arriving soon . I see you are handling with “Grenzwert” on rain? how are you including this, i suspect in a rule? What is your measurement here?
I guess the positioning issue could be related to this comment from @ysc .
However I’m not sure how to solve it.
I implemented the “rain automatic” feature in my watering system last year in OH2.5 using old DSL rules.
I use the data from Netatmo for old/current rain and OpenWheather Binding for forecasts.
With this I calculated whether I can decrease the water in case of less rain, or skip the watering at all.
I set a watering interval (e.g. every 5 days) and rain threshold (e.g. 10mm).
At the scheduled watering time I checked the rain in the past 24hrs, 3days, days set as interval. In case the total volume of rain was exceeded the threshold, then I rescheduled the watering by 1 day.
The next day I did the same check, and so on. Once the rain volume was lower than threshold, I start watering, if no rain was forecasted. (taken the amount to forecasted rain into account).
This worked very well in OH2.5, but now I need to migrate this to OH 3.0 - but now using Phyton script.
Hi Stefan, i dont think this is related as the comment from @ysc was related to a OH-CELL which has some additional slots pre-defined to make standard widget building for simple use cases easier.
The f7 card is more flexible. I will have a look into some of my widgets and see if i can draw some conclusions why this happens in your example.
thanks for shedding some light into your strategy to determine watering. i have been working with Netatmo, openweathermap data etc. but was not entirely happy yet. i might come back for some more advise.
I did some further checks and was able to reproduce the issue on my laptop as well.
I highlighted interesting part but I have no explanation for it.
Not sure why the value in content width is not 100% anymore, but disappeared in the code.
It seems the width after the card is collapsed again is equal to the total screen size.
You can see in the last screenshot that the grass icon is set outside the visible screen and completely disappeared.
what i see in your widget is that you have placed all content with “absolute” positioning, everything what goes in expanded is nicely in rows and colums. i believe this is the root cause. This does not explain why the position absolute is disapearing, but as a test if you just remove the absolute element from the gras, it obviously will be re-positioned like everything else ( as absolute is related to each other ), but if you do the test then with expanding and colapsing, the gras is still there where it was. I believe to sort the problem, you need to work in rows and colums to properly position the elements within the card-content part of the widget unless someone has another solution.
There is a nice discussion in another post around this topic of placement, this might eventually help:
Expandable card content (card-content ) is set to 100vw width when collapsed (closed). It is done to improve card open/close transition performance, so you need to take care about its content positioning. You can make its content width also animatable and responsive by adding additional card-expandable-animate-width class to card element, but performance can be worse in this case.
The 100vw width will overwrite the applied styling on the card-content component after the first expansion of the card. Performance seems okay for me after adding the mentioned class, which would be the easiest soloution for your case, I think.
The expand transformation will applied for each element outside of card content-elements (card-header, card-content, card-footer) which leads to the stretched icon - so it’s needed that any visible element for the opened card is inside these card content-elements.
I had a quick look at your widget and done some small optimizations to the mentioned problems - but only for the ones that were obvious at a first glance, so its worth checking all components again.
i leave it to Stefan to further comment on this widget, but thank you so much @RGroll for sharing your knowledge. I believe this widget with the expandable opportunities gives quite some possiblities to build functionable widgets, eg. for thermostate control and some other stuff and to replace the popup / popover hickups.
Thanks a lot Rainer - much appreciated
Without your help I would have never find this card-expandable-animate-width - even I read the Card doc already
FYI - I had to change the width of the f7-card from 100% to auto.
Otherwise the Widgets was right aligned on the mobile screen.
But now it is perfect
I will review the code again - I already found a WhnZ_Licht_Main_Dimm item, which doesn’t belong to my watering system