The current solution that I know of:
Alternatively you could write a script that perform a “pre-processing” of your source sitemaps that compiles them into the output .sitemap file.
I understand you’re wanting this all done for you in core, though. I’m just offering current solutions that you can use/do right now.
Thanks for the ideas. I already build my sitemaps using jython scripting.
But fragments fail validation in vscode and include syntax is quite bad. Also handling of proper indention is cumbersome and error-prone (while i defenitely could improve that…)
All in all, this still feels like a feature that should be native to the system and not some homebrew solution…
How about implementing a return variable from a rule back to the widget?
Use case: From a widget you run a rule. This rule creates a return value (like „ok“ (rule has run succesfully), or an error message) which can be shown e.g. as an actionFeedback value in the same widget
We could either use actionRuleContext variables or variables which are defined in oh-context.
Yes, I know you could return a value through an item, but sometimes this does not work in a more complex widget. In one of my recent cases I have a dashboard widget which has several list items each of them launching different rules.
In order to have day/night info I have a switch item linked to Elevation (Astro binding) using a range profile. In my case Elevation 5º to 90º is day, all other cases is night. My purpose is to automatically switch lights on at night using presence sensors, The Astro thing is updated every 5 mins.
You can use negative values for range limits if needed.
Wouldn‘t illuminance sensors combined with motion/presence sensors be a better solution? Sometimes it’s dark enough during the day that you need to turn lights on.
Yes
In my Country using elevation is acceptable 90% of the time.
Examples from NodeRed:
In the gauge one can set ranges and colors.
Considering 2 colors seems great, but in my example I am using 3 colors.
My main use is for temperature ranges like:
from 0 to 18 blue (cold)
from above 18 to 25 green (good)
above 25 red (hot)
There is also the needle that points to the value, but it could be another shape like a “sphere” indicator from the second example.
This is my current NodeRed setup.
The ranges can be pressure, humidity, light, etc.
Well it looks like one of my feature requests might be under development (RBAC) so that’s one!
A couple others I’d like to see:
Someone (who uses it) would need to write it.
I was hoping someone would volunteer 
Maybe its something I’ll put into my own backlog, seeing as I use it.
I would like to see “compound types” which creates a new type based on several of the types we have today.
Let me give an example: I want to show a card similar to the one homeassistant has for each of my plants.
I can create a plugin for openplantbook which for a given plant (a thing) get an image, a couple of names, min+max temp in air and in soil, humidity, moisture, light. 13 items per type of plant I have.
Then I can write a plugin for my Apollo PLT-1’s, or use the esphome binding. I can read soil and air temperature, air humidity, soil moisture, light, battery - 6 items per plant.
If I want to have a “plant” card, I need 19 item inputs - or I need everybody that uses it to use the same naming convention? If I have 10 plants of 5 different spices, I will have 15 things and 125 items which I have to connect correctly 190 times.
I would instead like to see the “openplantbook binding” provide a “plantinformation” type, and “Apollo binding” provide a “plant” type. Maybe a user editable property on the “plant” could be the “id” of the thing with the plantinformation? I would like to create 10 plant things, 5 plant spices things, maybe connect them together?
Then I would like some “foreach item of type” thing in the page designer. It would let me say “foreach item of type plant: render a plant card”. It would layout as many cards as it was space for and wrap them around.
Maybe there could be a “battery” type, which was made up of “battery type” - again possibly user provided and percentage. Then the same “foreach type” card, maybe with a “sort percentage asc” modifier.
Other compound types could be “song”, “album”, “metered plug”, “time period”
Minor ask as binding developer: I would like the thingDiscovered() method to be available from Handlers.
I find that the handler is involved with the I/O, and for those scenarios where we need to poll is the class that has the information of what is found.
Now we need some register of classes that implement AbstractDiscoveryService. We need to create a discovery service that register themselves, and we need to iterate over them to give them the information that they transform and put into thingDiscovered. It feels unnecessary and adds things that can go wrong instead of putting a 10 line method in the handler.
For discovery which finds bridges, like UPnP discovery, separate classes makes lots of sense.
Sorry for the question, does this mean that DSL rules will continue to be supported as before or do you think here I have to prepare for breaking changes.
Second question so far I only use 100% test-based DSL rules, if I want to continue to stay with text-based which language would be your recommendation to gradually switch.
There is no plan to remove DSL rules.
Oh, I’m very happy about that - I easily have over 1000 rules - that would have been a lot of work to rewrite.
And if something like that should come up, I am happy to be prepared and prefer to start early.
But the other question for future rules what is a permanent alternative to DSL here?
And one more wish from my side, since I like to update early - could you introduce a category Breaking Changes at the top of the change logs in advance?
Wow.
Maybe there are some options to optimize the rules? e.g. rules, which are identical except for the items in question…
