The Ephemeris Binding makes the bridge with Ephemeris core actions, providing access via Items to Ephemeris data without using scripting language.
Things gives you direct access to:
default holiday data (thing holiday)
personal holidata data file (thing file)
daysets (thing dayset)
weekend (thing weekend)
The binding will auto create a folder in openhab configuration folder where it expects to find your Jollyday event definition files. Eg. for a linux system : /etc/openhab/misc/ephemeris/
Oddly when I try to install this through the add-on store it fails without an error in the logs. I think the problem is the link to the file on Google Drive doesnât return the actual jar file. When I use wget with the URL provided I get a web page instead of the jar.
Installation through MainUI wonât work unless the URL is directly to the jar file. I donât know how/whether thatâs possible with a file shared through Google Drive.
-folder ephemeris correctly was created in /opt/openhab/conf/misc/
Maybe it is wise to change the recommended folder for creating custom bank holidays and language files in the Ephemeris docs from /services to /misc/ephemeris to not have inconsistent entries:
(1), (2)
What am I missing are:
translations donât seem to work. The raw String is presented. I have my holiday_descriptions_de.properties and also country_descriptions_de.properties in the same /misc/ephemeris folder, also the Regional settings both from openHAB and the Ephemeris are set to German, but the outcome is:
it would be nice to have a switch not only for weekends and workdays, but also for the holidays: isBankHoliday and isBankHoliday(<offset>) (at least for isBankHoliday(1), as this is often used for garbage calenders).
For the core part, it is only a recommendation.
If this pinding happens to finish in official repo, unifying these will be better, youâre correct.
Youâre correct, I did nothing as of today on this side. I plan to add a channel description providing translated strings for raw strings.
Good idea the switch for holidays.
I also planned to include a configurable channel, allowing the usage of the offset.
I also thought of a basic discovery service that could automatically generate weekend and holiday things.
When I added the binding from the marketplace today, I got the following errors;
openhab.log
[ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while calling thing handler factory 'org.openhab.binding.ephemeris.internal.EphemerisHandlerFactory@554f5d73': Can't find bundle for base name descriptions.holiday_descriptions, locale en_CA
java.util.MissingResourceException: Can't find bundle for base name descriptions.holiday_descriptions, locale en_CA
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045) ~[?:?]
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1683) ~[?:?]
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1586) ~[?:?]
at java.util.ResourceBundle.getBundle(ResourceBundle.java:1280) ~[?:?]
at de.jollyday.util.ResourceUtil.getResourceBundle(ResourceUtil.java:174) ~[?:?]
at de.jollyday.util.ResourceUtil.getHolidayDescriptions(ResourceUtil.java:152) ~[?:?]
at de.jollyday.util.ResourceUtil.getHolidayDescription(ResourceUtil.java:83) ~[?:?]
at org.openhab.core.ephemeris.internal.EphemerisManagerImpl.getHolidayDescription(EphemerisManagerImpl.java:435) ~[?:?]
at org.openhab.binding.ephemeris.internal.handler.HolidayHandler.<init>(HolidayHandler.java:52) ~[?:?]
at org.openhab.binding.ephemeris.internal.EphemerisHandlerFactory.createHandler(EphemerisHandlerFactory.java:80) ~[?:?]
at org.openhab.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:129) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.doRegisterHandler(ThingManagerImpl.java:531) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerHandler(ThingManagerImpl.java:512) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerAndInitializeHandler(ThingManagerImpl.java:927) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.setEnabled(ThingManagerImpl.java:1009) ~[?:?]
at org.openhab.core.io.rest.core.internal.thing.ThingResource.setEnabled(ThingResource.java:609) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.6.2]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.6.2]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.6.2]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.6.2]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.6.2]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.6.2]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:304) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.6.2]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:520) ~[bundleFile:4.0.4]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:279) ~[bundleFile:3.6.2]
at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.52.v20230823]
at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:320) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.52.v20230823]
at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.52.v20230823]
at java.lang.Thread.run(Thread.java:840) [?:?]
If I create an Ephemeris Holidays thing, I also get this error in events.log:
Thing 'ephemeris:holiday:82367f647b' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_REGISTERING_ERROR): Can't find bundle for base name descriptions.holiday_descriptions, locale en_CA
In my /etc/openhab/misc/ephemeris folder, I have a copied the following files from the focus-shift/jollyday github;
Holidays_ca.xml
holiday_descriptions.properties
country_descriptions.properties
Iâve also tried appending â_enâ and â_en_CAâ to both *_descriptions.properties files (as in âholiday_descriptions_en.propertiesâ and âholiday_descriptions_en_CA.propertiesâ), but the errors persist.
Correct - I get a similar error when trying to use holiday descriptions in my rules with the core Ephemeris capabilities.
I had hoped that with the addition of the description provider you mentioned above, weâd also be able to specify the location of the holiday_descriptions.properties file (much like we can specify the Holidays.xml file).
There doesnât appear to be any documentation on where the holiday_descriptions.properties file(s) should be located (or named) to satisfy the locale checks.
Unfortunately for you the binding gets its descriptions directly from the core, so if core fails youâre out. Take a look above @sihui seems also to use property files, maybe he can tell us if it works and where he puts them. If not, it may be worth opening an issue in the core .
I used to have properties files in $OH_CONF/misc/ephemeris, but when tinkering with this binding I realized those are not needed at all, at least not for the core functions:
I have a custom xml file in $OH_CONF/misc/ephemeris which get picked up nicely with the core function and also with this binding.
Localization works with the core functions, even I donât have any language properties files in the $OH_CONF/misc/ephemeris folder anymore. Example:
val String nextHoliday = Ephemeris.getHolidayDescription(Ephemeris.getNextBankHoliday())
val long daysuntilnextHoliday = Ephemeris.getDaysUntil(Ephemeris.getNextBankHoliday())
if (daysuntilnextHoliday < 1) {
logInfo("Test_ephemeris","Heutiges Event: " + nextHoliday)
}
else {
logInfo("Test_ephemeris","Heute liegt nichts an. NĂ€chster wichtiger Tag: " + nextHoliday + ", noch " + daysuntilnextHoliday + " Tage")
There is no Holidays_xx.xml or language properties file needed if you configure this in the MainUI settings for your country. This was surprising for me, too
Yes, normally Jolliday (basis of the core implementation of Ephemeris in OH) comes with localized versions of all holidays so maybe apart of weird country/language combinations, you should have everything embedded.
A thing for weekends and weekdays doesnât work either. The channel values remain permanently OFF. When starting, there is a warning that daysets are not defined. But they are in the empemeris.config.
Hello, the holidays, weekend and weekday daysets are now working. But the birthday.xml doesnât work even if I remove the validFrom mentions. Strange. Any more ideas?
OH4.1.2 stable on openHABian.