Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[icalendar] eventfilter not returning event informations #9029

Closed
rgrollfitz opened this issue Nov 14, 2020 · 5 comments · Fixed by #9230
Closed

[icalendar] eventfilter not returning event informations #9029

rgrollfitz opened this issue Nov 14, 2020 · 5 comments · Fixed by #9230
Labels
bug An unexpected problem or unintended behavior of an add-on

Comments

@rgrollfitz
Copy link

The newly introduced version of the iCalendar binding for OH3 adds eventfilter. I tried this today with my Synology NAS calendar as the source but don't get any item state back for the events that should be grabbed via the eventfilter. Everything else is working as expected.

I used the binding config from the docs as you see here

I don't get any warnings or errors in the openhab.log. I'm using Build 2005.

@rgrollfitz rgrollfitz added the bug An unexpected problem or unintended behavior of an add-on label Nov 14, 2020
@cweitkamp
Copy link
Contributor

I am facing a similar problem but it only appears after a restart of openHAB. All my items are still NULL. It helps to disable and enable the Thing to get the values populated.

@rgrollfitz
Copy link
Author

Thanks for the hint - but restart or disabling/enabling the thing/bridge does not work here. Even updated to build 2010 today - nothing changed.

@daMihe
Copy link
Contributor

daMihe commented Dec 4, 2020

@rgrollfitz This may be a race condition (i can't reproduce directly). Are the properties set correctly after a "refreshTime" period?

daMihe added a commit to daMihe/openhab-addons that referenced this issue Dec 4, 2020
…dler

Should fix openhab#9029. The channels do not get updated as the known channels by the binding where only updated if Bridge was already online while initializing EventFilterHandler.
Also added a bit more output.

Signed-off-by: Michael Wodniok <michi@noorganization.org>
cpmeister pushed a commit that referenced this issue Dec 5, 2020
…dler (#9230)

* [icalendar] Fix race condition while initialization of EventFilterHandler

Should fix #9029. The channels do not get updated as the known channels by the binding where only updated if Bridge was already online while initializing EventFilterHandler.
Also added a bit more output.

* [icalendar] use implicit conversion to string for logging

Signed-off-by: Michael Wodniok <michi@noorganization.org>
Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com>
@daMihe
Copy link
Contributor

daMihe commented Dec 5, 2020

I've fixed a race condition which could lead to this behavior. That had to be fixed anyway. I got the behavior exactly once yesterday while debugging but i could not reproduce the behaviour getting always "NULL". If the issue still persists using icalendar including the fix (as your environment seems to favor this behaviour, should be included in next daily build thanks to @cpmeister), please feel free to reopen this issue. Please share then a minimal ical where the issue occurs.

@rgrollfitz
Copy link
Author

Hey @daMihe

sry for my late response.
I looked into it today and I think I found the error. I'm using text-files only for configuration normaly but had a look in the UI today.

There were no linked channels in my thing configuration of the eventfilter visible. I used the example configuration from the docs (which was updated at that time, I think).
The example items config refered to 'event_0#xy' as the channel-scheme for the eventfilter - now I recognized that 'result_0#xy' would be the correct scheme here.

It's also mentioned in the decription itself correct now (I'm unsure it was there at the time I looked it up ) but the example item configuration still shows the wrong 'event_0#xy' scheme:

String first_event_name_tomorrow "first event [%s]" <calendar> { channel="icalendar:eventfilter:feedd0d0:event_0#title" }

Thanks for your help and as least it's a good thing, that this pushes the race-condition fix a bit. :-)

chrisonline pushed a commit to chrisonline/openhab-addons that referenced this issue Dec 7, 2020
…dler (openhab#9230)

* [icalendar] Fix race condition while initialization of EventFilterHandler

Should fix openhab#9029. The channels do not get updated as the known channels by the binding where only updated if Bridge was already online while initializing EventFilterHandler.
Also added a bit more output.

* [icalendar] use implicit conversion to string for logging

Signed-off-by: Michael Wodniok <michi@noorganization.org>
Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com>
Signed-off-by: Christian Grasser <info@christiangrasser.at>
boehan pushed a commit to boehan/openhab-addons that referenced this issue Apr 12, 2021
…dler (openhab#9230)

* [icalendar] Fix race condition while initialization of EventFilterHandler

Should fix openhab#9029. The channels do not get updated as the known channels by the binding where only updated if Bridge was already online while initializing EventFilterHandler.
Also added a bit more output.

* [icalendar] use implicit conversion to string for logging

Signed-off-by: Michael Wodniok <michi@noorganization.org>
Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com>
marcfischerboschio pushed a commit to bosch-io/openhab-addons that referenced this issue May 5, 2022
…dler (openhab#9230)

* [icalendar] Fix race condition while initialization of EventFilterHandler

Should fix openhab#9029. The channels do not get updated as the known channels by the binding where only updated if Bridge was already online while initializing EventFilterHandler.
Also added a bit more output.

* [icalendar] use implicit conversion to string for logging

Signed-off-by: Michael Wodniok <michi@noorganization.org>
Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants