Do you have a Profile on that? I’m not seeing any Switch Channels on the Astro binding. But I do see that I missed the Sun Phase Channel.
Link that Channel to a String Item and test to see if the Item is “NIGHT”. That would be more straight forward than using Elevation or Azimuth.
Given what I’m seeing in the docs @ErikDB either has a profile on the link between an Astro Channel (not sure which one(s)) and Switch Item, or they have a simple rule to command the Switch based on the sunrise/sunset events generated by the Astro binding.
The Rule approach would be pretty straight forward and wouldn’t need any code. Trigger the rule on the start of one of the dawn events and update the daylight Switch to ON and another rule at the start of end event of one of the dusk events to update the dayligh Switch to OFF.
Sorry, I meant I have a JavaScript rule that switches a switch item on the sunrise and sunset events. These items are not “from” that Astro binding though, but from the OpenWeatherMap Binding
Wait, am i misunderstanding something?
If we give the time zone, the region and the city in the ephemeris menu, can’t that be used to produce other information as well? Like precisely the period of day?
We used the Astro binding to solve the issue yes - but is it really needed if openHAB already knows where it is located?
Ephemeris ^ yes but… can’t we use that information to infer more?
Edit: after writing this the following thought came to my mind:
“Likely yes but then where would we stop?”
I don’t have an answer to this one…
To know where it is located is not sufficient.
You need the time for sunrise/sunset to determine if night or day. And those come from Astro or weather Bindings.
Thoeretically yes. As implemented, no. Astro is a separately installed and configured add-on. It’s not part of core. Ephemeris is a part of core.
The calculations from Astro could be added to core I imagine but that couldn’t replace the separate add-on completely as Astro does a whole lot of stuff that probably shouldn’t be a part of core.
It’s also complicated. Should OH core start night at nautical dusk or civic dusk? If it’s part of core and not a binding we won’t be able to link to Items anymore. That eliminates a ton of flexibility and use cases.
That doesn’t mean it can’t be done, just that a lot of thought needs to go into it.
If I were to move some of the sun calculations into core, that’s where/how I would expose it.
But it is worth mentioning that when you set the regional settings location, Astro gets that information and uses it to add a sun and moon Thing to the inbox. So the information does get to Astro.
You could just say not equal to DAYLIGHT in the astro day phase name but also that changes as there is a NOON day phase name but that doesn’t last long but you can account for that. Then in the rule use the but only if part which is AND statements.
A little late to the party, but since Christmas is around the corner my 5.x wishlist would include:
%include-like syntax for sitemaps
Why? How?(click to expand)
Why?
In typical operation, I use Basic UI and full-on text based configuration almost exclusively. This means my primary sitemap file gets large (> 1500 LOC) which is not too fun to manage. Judging from this forum threads, there are others still using OH this way and the very feature of modular sitemap has been proposed years before (but got no traction then).
Any reuse of particular widget definition in more than one place (via copy-paste) opens up for them getting out of sync and is just an unnecessary nuissance.
How?(just some loose alternative proposals as food for thought)
[native] Extend the XText DSL definition of a sitemap and introduce a new keyword (ex. %include(./part1.sitemap.part)). Each part file would be a self-contained sub-definition which parses on its own, the outer parser only handles nesting into Frame or Text elements. Have the runtime stitch it at load-time (handling errors just in time, preserving their actual location). This way, the UIs don't need awareness of this feature
[preprocessor] Add native (built-in) support for textual definition pre-processor (ex. #include ../some.text.file). Would work on text-level and require 2-pass processing, but (except error messages and appropriate source location) might be the most generic and easy. Arguably can be done today, off-system, by a simple script launching on startup.
[new UI element]Instead of working on definition, have the UI be able to load sitemaps into nested widgets like so:
native support for ~ ‘thingItem’ (thing-properties-as-items indirection)
Why? How?(click to expand)
Why?
This may be quite controversial to some (I'm aware of at least a few long debates on Things being things and not belonging in user-UIs), but:
There are numerous precedents where thing's (physical object's) configuration is modeled as OH Thing property and not a channel (I claim it is intuitive, actually - see how ZWave or Homematic bindings expose device-side configurations). Some of such configurations are not set-once, but may benefit from being directly cotrolled by an User (not an admin!) from a regular UI (incl. Basic UI).
Thing's ONLINE/OFFLINE status can be useful to regular users in some contexts.
How?
[note] All the above (manipulating Thing configuration*, changing state, pushing online/offline state to String items)can be done via Items today using rules * - except for changing config of text-configured things. I am successfully using this approach myself. However, I think this rule boilerplate rather belongs to the core (as an opt-in) to make user's life easier.
[the idea] I'm thinking OH could allow a first-class concept of a companion item (deliberately calling it a thingItem to distinguish, but technically it could be just new definition syntax for Items). A thingItem would be linked to a single trait of a Thing (similar to how items are linked to channels). For example:
//File: things/sample.things (just a sample - this actually needs to be in JSONDB for dynamic config to work)
Thing zwave:fibaro_fgs223_00_000:controller:node42 "Sample Thing" (zwave:serial_zstick:controller) @ "Bathroom" [
node_id=9,
ch1_delay_after_on=900
]
//File: items/sample.thingitems
Contact thing1Online "Thing 1 - AVAILABILITY" {
thingProperty="zwave:fibaro_fgs223_00_000:controller:node42::available"
// ^-- thingId::property syntax ---^^
// 'available' maps to thing's ONLINE status
// If linked to a Contact, ONLINE means CLOSED, OPEN otherwise
// If linked to a Switch, similar to above, but turning it off means Disable
// If linked to a String, reports the state verbatim...
}
Number::Time thing1DelayOnTimeConfig "Thing 1 - Built-in delay timer value" {
thingProperty="zwave:fibaro_fgs223_00_000:controller:node42::properties:ch1_delay_after_on"
// thingId::property syntax ---^^
}
Add some predefined wildcard/groupings like:
//File: items/sample2.thingitems
Group:Contact:OR(OPEN, CLOSED) GOfflineThingsUserCaresAbout "Offline things [(%d)]"
<contact> {
thingProperty="*::properties:available"
// * for all the things or [predicate] syntax for filtering
}
Opt-in auto-UNDEF linked items on device going OFFLINE
Why? How?(click to expand)
Why?
Some bindings do it already, can be done by rules (and quite generic), but leads to inconsistencies...
How?
Have a global (opt-in) setting and built-in support for managing state of Channels/Items when the associated Thing is no longer offline.
Default would be DO_NOTHING (today's behavior), but could add a SET_UNDEF or SET_NULL options together with Item-level override config (ex. don't want to zero a last seen state).
Allow runtime changes of (some!) properties of Things defined via .things file
Why? How?(click to expand)
Why?
*Not* proposing to revisit the JSONDB vs. .things file discussion. Rather making an observation that in certain bindings and for certain devices, Thing configuration comprises of both: 1) an actual OH-side immutable configuration, and 2) device-only configuration (affecting its operation, but not how OH speaks to it) - ex. see how zwave binding models configuration properties.
#1 must stay immutable not to risk definition conflicts. #2 however is typically discovered at runtime and never (allowed to be) entered into the .things file in the first place. As such, there's no risk of de-sync of state and even though the Thing definition needs to stay immutable, these properties in reality live only in the JSONDB overlay, and there's not much risk 'unlocking' them for edit.
How?
Extend core APIs to allow binding authors to express which properties are of cat. #2 (above). Either prevent these items to be configured via .things file, or force them having no default.
When such a pre-designated (by binding author!) property is not explicitly defined in the .things file -> allow to modify it at runtime even if Thing definition comes from text file (persist changes to JSONDB only).
RBAC for Items
Why? How?(click to expand)
Why?
This is probably the biggest complexity adder and may be YAGNI, but since there's a skeleton user/role model already, a fine-grained permisson management would be a nice and logical extension. I.e. an user with role=Child can't turn off parental controls (item is read-only).
How?
I think item-level might be good enough (esp. when combined with my idea #2 above) Example:
//File: items/permission_sample.items
Switch ParentalControls "TV Parental Control"
{
channel="some:dev:id:somechannel",
permissions="" [ visibleForUsersInGroup="Everyone", changeableByUsersInGroup="Parent,Admin"]
// ^-- could use this name for a predefined permission target
}
UIs could benefit from being smart (hide controls, make them read-only), but merely a core-based implementation might do the trick (serve NULLs if user has no read access and reject commands if no write access).
Allow full sitemap representation to be captured via .items definition
Why? How?(click to expand)
Why?
With latest changes, sitemaps allow to use quite powerful syntax for element's color or icon. Ex.
However, it seems impossible to encode these icon/colors conditionals into item definition and so:
Default item=tvPower //sample.sitemap
displays differently than the sample above. This is not an issue when standalone, but makes it impossible to display a group of such items with precise control over each’s display.
How?
Allow the conditionals from icon/color to be expressed in .things file - either in the place icon is in today, or via metadata.
Autogen/display configuration property keys for things
Why? How?(click to expand)
Why?
Textual configuration is no longer primary, but still used by some (myself included) and very well supported by core.
All of thing's static configuration properties can be defined via a .things file. However, the description of what can be configured by which property is input manually into each binding's README.
Some binding authors forget about it, and while a property is reachable, its name is undocumented and one needs to grep through binding source/definition XML to find out the name. For example, WLED binding offers a parameter called sortEffects but does not document it anywhere. One could argue it's a bug in the readme, but to be honest, duplicating definitions are always prone to such omissions and I get that some binding authors don't use text definitions at all, so it is unrealistic to assume they'll all be updating it by hand (I've seen numerous such examples in the past - WLED is merely the one I remembered, don't want to pick on that great binding!).
Main UI does display the property, of course so you know something can be configured. When set to default value though, the entry name (key in the parameter map) is not visible in the UI anywhere (or I am blind :))
What?
Have Main UI display the textual property key next to a property (or on hover, etc.), and/or...
Change the CI/CD pipelines in such a way that these sections of READMEs are always auto-generated from XML (remove duplicate definitions, move textual descriptions straight into XML), or there's a linter/test ensuring all config knobs defined in things metadata are present in the README.
Graalpython / Python3 support
Why? How?(click to expand)
Pretty self-explanatory, I bet (and well discussed here before).
That'd be it for my (heavily opinionated) list of ideas for christmas gifts :christmas_tree:. I know Santa may not like any of them :grinning:, which is why I get by with set of rules in the overlay today.
Would like to see what you guys think on this direction for the OH engine however, so feel free to throw darts at them :dart:
Some of these may be quite heavy, so I’m happy to move them to separate threads if there would be any interest of a follow-up discussion. Cheers!
Building sitemaps using JRuby has been possible for some time. But it does require some familiarity with Ruby syntax. It can be as simple as a plain “include” (e.g. looping through your rooms, TV, etc. and calling a method to render the controls for that room/TV) or as complex as you wish to make it (e.g. making it conditional, object-oriented, etc.). This pairs very well with semantic model too.
You can even make on-the-fly changes to existing sitemaps, responding to events.
Thanks! I wasn’t aware of it. Great hint - will give it a spin when I find some time.
For the undefined “future release”, I would still hope of something simpler (less powerful, but native) to be available ‘inbox’ though.
See, I already have quite some rule code in all of (ruleDSL, Python and JS) so adding a +1 language engine and a new SitemapProvider is not exactly my dream solution (mostly for the runtime performance overhead reasons ). I guess it doesn’t have to be Ruby - seems like one could technically create a basic add-on, providing a new OSGI module supporting something like .sitemap_ex files (a superset of current syntax, w/ the include support I mentioned), but still a +1 OSGI bundle doing a thing similar to a built-in.
I wonder if others have similar use case for sitemaps. And if so, if it would make sense to consider inclusion of such functionality in the default/primary provider (for “some, distant future”).
Sorry, my bad - should have linked this thread myself.
I’m vaguely aware of the awesome work @holger_hees is doing in this area. What I meant, was to say was it would be really, really awesome if this intercepted OH5 and with all bells and whistles like helper-libraries integration, docs on IDE configuration, transitioning from Jython etc…
Thanks, I tried to make it as self-contained as possible (I often forget my own ideas , so it also serves as a self-reminder). Unfortunately this makes the writeup quite long and all over the place, but hope is still comprehensible.