I would like to propose a git repository (GitHub or GitLab) instead of posting code snippets - at least the “released” once only into the community pages.
I believe this make collaboration between the involved parties easier and contributions to these great widgets better controllable.
Additionally it would easily be possible to see what changed between two released versions.
I would volunteer to create the public repository in GitHub and copy the current versions of all widgets into it as a start.
a probably wiered question, but how to I get the configuration parameters passed to the weather widget?
e.g. I can’t get the itemPrefix set in the Main-UI.
All items are available and it looks great in the widget editor:
Wouldn’t it be nice to be able to configure all items the same way through the “page setup” (settings/pages/layout/<pageid>) as it is possible with locationTitle?
Then all page-widgets could remain unchanged - and easier maintained - and we have a single source of truth for the configuration?
It would have the drawback of having to connect all items through e.g. Main->Home->Weather but I think it’s worth it.
No, what we want to achieve is a zero conf solution with gathering all needed information from the semantic model.
The original weather widget only uses the item prefix as param and also sets a default value, cause it would make manually configure the widget to complex. Think of a 12hour forecast with I think 3 or more items per hour, plus weekly forecast…
If you follow the guidance to create equipment from thing and set the prefix like shown, you don‘t need any config for the weather widget/card.
Location is a bit different, as I did not find a way to retreive this one from the model, but still working on a solution.
Edit: Yes this should work, I will put it on the short list for the next update.
Edit2: Only solution I can see so far is to create a „normal“ openweathermap thing and bind the stationName channel to an item to pass it into the widget.
We are working on improving the documentation and the will be a big update soon.
In generall, it will work on tablets, but the design is mainly made for smartphones.
You already can change widgets or add new ones, you just need to make according changes to FloorsAndRooms.
What do you want to tell or ask ?
This topic is not about other widgets tha the ones we develop and publish.
So the Conditioner Card for Daikin AC is out of scope here.
Sorry!
I am using DSL .rules files. I would need four of those when using weekend support which I have to do soon as my wife was today under the shower when the shutter opened
Good that she adjusted the time herself.
rule "rule-storen-timer-up-OG_Diele_Strasse"
when
Time is Shutter_OG_Diele_Strasse_timeUp timeOnly
then
if(Shutter_OG_Diele_Strasse_timerActive.state == ON) {
Shutter_OG_Diele_Strasse.sendCommand(UP)
}
end
So for example for this rule, which calculates a next action string like next_action = "▲ " + timeUp,
I can use groups:
rule "storen-timer-next-action-string"
when
Member of gShutter changed
or
Member of gShutter_timeUp changed
or
Member of gShutter_timeDown changed
then
and find out with var strItemBaseName = triggeringItem.name
and g.members.filter[i|i.name.equals(strItemBaseName)].head
which item caused the trigger and serve it accordingly.
So the same rules serves all Roller-shutters for the task “next action string”,
This would be handy for Time is DateTimeItem timeOnly too.
As long as we don’t have such a feature in openHAB, you have to live with having one rule for each device.
And that’s what I have documented as well, one rule each.
This is getting even more complex when using the extended Radiator Control as well, as It will support timestamps for comfort and eco temperatures, following the sme logic.
In my installation,this means
Radiators : 10 x 4 rules
Shutters: 7 x 4 rules
Total: 68 rules only for this little bit of comfort
I had a rough look at your results.
The concept is very interesting but also very complex. I mean here the structure of the page with variables.
This makes it impossible to program WYSIWYG in the widget editor.
Or I don’t know the trick?
Is there a reason why you didn’t put the navigation on items?
Mainsection-Item (as string) with HOME, FLOORS, ROOMS as possible value.
Subsection-Item 1 for FLOORS
Subsection-Item 2 for ROOMS
The values of the items are set by the repeaters.
This would also make it possible to control the content via e.g. rules.
e.g. In the morning the HOME content is displayed.
Surely there is a reason why you preferred variables.
Yes, it is very complex, but to be honest, this parts of the widgets is not mine, kudos got to @Nic0205.
As I (we) already see some performance issues with the extensive use of oh-repeater components, I started thinkin about a complete redesign and moving to itemPrefix usage instead.
Still under the aim to achieve a nearly zero config solution for the users.
We have to check whether there would/could be side effects, as oh-repeater is actually the only way to fetch metadata like uiSemantics, which is used for the fancy naming.
Is there a reason why we should use Items
I think no. IMHO, usage of items will introduce another issue, as you would always come back to your last selection, wanted or not. Even excluding those items from persistence would lead to that, as long as openHAB service is running.
Anyway, really appreciate you started that discussion, as it might lead us to overthink some parts of the concept.
