[ERROR] using receivedEvent.getEvent() in a rule

[rancor187]

Hej there,

I (and others) run into the following error when trying to fetch the name of the event that has been triggered using command: var trigger = receivedEvent.getEvent()

2019-04-06 17:28:19.811 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule ‘Lamp2’: ‘getEvent’ is not a member of ‘org.eclipse.smarthome.core.thing.events.ChannelTriggeredEvent’; line 46, column 20, length 24

OH version is 2.4

See detailed description and code examples: https://community.openhab.org/t/solved-getevent-is-not-a-member-error-since-oh-2-4/61791/11 https://community.openhab.org/t/solved-getevent-is-not-a-member-error-since-oh-2-4/61791/12 (Thread says "solved" but that is not the case)

Thanks

[5iver]

I've tested this with the rules DSL and the NGRE using S1603, and both worked without issue. Here are the rules I used...

from core.rules import rule
from core.triggers import when
@rule("Example Channel event rule (decorators)", description="This is an example rule that is triggered by the sun setting", tags=["Astro"])
@when("Channel astro:sun:local:set#event triggered")
def channelEventExampleDecorators(event):
    channelEventExampleDecorators.log.info("Sunset triggered [{}], [{}]".format(event.channel, event.event))

rule "Test trigger Channel getEvent"
when
    Channel "astro:sun:local:set#event" triggered
then
    val event = receivedEvent.getEvent()
    logWarn("Rules", "event=[{}]", event)
end

I triggered the rules by running these in Karaf...

openhab> smarthome:things trigger astro:sun:local:set#event START
openhab> smarthome:things trigger astro:sun:local:set#event END

Some of the examples in the forum seemed to be using the wrong format for the trigger Channel, so I tested it without the # (Channel "astro:sun:local:set:event" triggered). The Jython rule wouldn't load, since I do validation checking, but the DSL rule would load without issue. However, the rule would never trigger. [Edit: for anyone who read this previously, I had another rule that made me think it was firing :roll_eyes:]

I think the issue here may be the use of the wrong formatting for the trigger, and possibly a gap in the rule validation in the rules DSL. @cweitkamp, could you please test this using the # and see if you come up with the same results? Also, the automation tag should be removed from this issue.

[cweitkamp]

could you please test this using the # and see if you come up with the same results?

IIRC the "#" is the channel group separator. It has nothing to do with an event. The things in the Astro binding uses channel groups whereas the things Hue binding do not.

rule "Hue example trigger rule"
when
    Channel "hue:0820:1:dimmer-switch:dimmer_switch_event" triggered <EVENT>
then
    ...

rule "Astro example trigger rule"
when
    Channel "astro:sun:local:set#event" triggered <EVENT>
then
    ...

[5iver]

Thank you! I'd searched for a long while trying to figure out what the # meant. I'll go look for some information on Channel groups and to reproduce this with another binding. Still seems odd to me that it would work without issues using astro.

[sparkplug23]

Any progress here? Still getting in randomly and can't seem to shake it.

[cweitkamp]

I implemented two rules on my 2.5.0-SNAPSHOT Build 1641 test environment. Both of them triggered nicely during the whole week. Can anyone confirm this behavior in his setup?

rule "Dark Sky SUNRISE triggered START"
when
    Channel "darksky:weather-and-forecast:api:local:current#sunrise-event" triggered START
then
    logInfo("weather", "Dark Sky SUNRISE triggered START: {}", receivedEvent)
    val event = receivedEvent.getEvent()
    logInfo("weather", "event=[{}]", event)
end

rule "Dark Sky SUNRISE triggered"
when
    Channel "darksky:weather-and-forecast:api:local:current#sunrise-event" triggered
then
    logInfo("weather", "Dark Sky SUNRISE triggered: {}", receivedEvent)
    val event = receivedEvent.getEvent()
    logInfo("weather", "event=[{}]", event)
end

2019-07-16 05:23:02.211 [INFO ] [lipse.smarthome.model.script.weather] - Dark Sky SUNRISE triggered: darksky:weather-and-forecast:api:local:current#sunrise-event triggered START
2019-07-16 05:23:02.211 [INFO ] [lipse.smarthome.model.script.weather] - Dark Sky SUNRISE triggered START: darksky:weather-and-forecast:api:local:current#sunrise-event triggered START
2019-07-16 05:23:02.212 [INFO ] [lipse.smarthome.model.script.weather] - event=[START]
2019-07-16 05:23:02.212 [INFO ] [lipse.smarthome.model.script.weather] - event=[START]
...
2019-07-17 05:24:18.157 [INFO ] [lipse.smarthome.model.script.weather] - Dark Sky SUNRISE triggered START: darksky:weather-and-forecast:api:local:current#sunrise-event triggered START
2019-07-17 05:24:18.157 [INFO ] [lipse.smarthome.model.script.weather] - Dark Sky SUNRISE triggered: darksky:weather-and-forecast:api:local:current#sunrise-event triggered START
2019-07-17 05:24:18.158 [INFO ] [lipse.smarthome.model.script.weather] - event=[START]
2019-07-17 05:24:18.158 [INFO ] [lipse.smarthome.model.script.weather] - event=[START]
...

[maggu2810]

@rancor187, @sparkplug23 Can you give it a try and comment if the problem exist in the most recent snapshot?

[rancor187]

@sparkplug23, @cweitkamp I'll test ASAP. However I can't during the next two weeks. Until then, thanks for your contribution and the good work.

You'll hear from me hopefully during first half of August.

[Race666]

I have a similar issue with the MQTT binding. (openhab-2.5.0-M3)

I've created a Channel

mqtt:broker:mosquitto:OpenHabMQTTSubscription

and this simple rule

rule "Subscribe for commands and updates from the event bus"
when
    Channel 'mqtt:broker:mosquitto:OpenHabMQTTSubscription' triggered
then
    logInfo("MQTT","Channel trigger event received")
    logInfo("MQTT", ("Channel triggered:"+  receivedEvent.channel.id))
    var String resEvent=receivedEvent.toString()
    val itemName = resEvent.split("/").get(2)
    val type = resEvent.split("/").get(3).split("#").get(0)
    val state = resEvent.split("#").get(1)
    logInfo("MQTT", ("Channel triggered Item:" + itemName + " Type:" + type + " State:"+state))
end

Then I publish a topic at the broker by MQTTfx

Topic: openHAB/in/KinderzimmerRechtsAutomationEnabled/command 
Value: OFF

May be this is an initialisation of an object or timing problem during openhab startup. Because: After restarting openhab (without any config changes) the rule sometimes work:

[INFO ] [org.eclipse.smarthome.model.script.MQTT                 ] - Channel trigger event received
[INFO ] [org.eclipse.smarthome.model.script.MQTT                 ] - Channel triggered:OpenHabMQTTSubscription
[INFO ] [org.eclipse.smarthome.model.script.MQTT                 ] - Channel triggered Item:KinderzimmerRechtsAutomationEnabled Type:command State:OFF

and sometimes not

[org.eclipse.smarthome.model.script.MQTT                 ] - Channel trigger event received
[ERROR] [rthome.model.rule.runtime.internal.engine.RuleEngineImpl] - Rule 'Subscribe for commands and updates from the event bus': 'channel' is not a member of 'org.eclipse.smarthome.core.thing.events.ChannelTriggeredEvent'; line 45, column 45, length 21       

If it fails once all other attempts failed too. If it works once then forever.

[rancor187]

Hej there,

I have a little update. But first I want to appologize because I thought I'd have more time for that and be faster with my tests and findings :/

Following @maggu2810 s suggetions, I upgraded to the most recent snapshot (that was a few weeks ago). Currently I am on openhab2.noarch 0:2.5.0~S1685-1. I know we have a new Milestone now and I'll update soon.

However, I did not receive that error (‘getEvent’ is not a member of ‘org.eclipse.smarthome.core.thing.events.ChannelTriggeredEvent’) ever since ... but as I said, didn't have the time to do much testing.

I'll keep you posted once I have more info so share.

[sparkplug23]

Currently running M4, and I haven't faced this issue in a while (not for maybe 2 months with various snapshots and M3). MQTT v2 binding in general though has been very buggy for me. Receiving seems to have become pretty stable, but I randomly get periods where mqtt data is not being sent (logs show it is, but nothing is arriving to the broker). Anyone else facing this issue?

[regnets]

Just to give you some more information. I experience this issue still with the current M4 docker build. See this thread for more information: https://community.openhab.org/t/unreliable-philips-hue-dimmer-switch-events-with-current-2-5-milestone-m4-build/84650/4

[Race666]

Regarding to . I setuped openhab-2.5.0-M3 completly from scratch then the same rule works as expected and is reliable. May be it is a problem when referencing/migrating config (userdata, conf) from older versions? In my case config was taken since OH2.4.

rule "Subscribe for commands and updates from the event bus"
when
    Channel 'mqtt:broker:mosquitto:OpenHabMQTTSubscription' triggered
then
    logInfo("MQTT","Channel trigger event received")
    logInfo("MQTT", ("Channel triggered:"+  receivedEvent.channel.id))
    var String resEvent=receivedEvent.toString()
    val itemName = resEvent.split("/").get(2)
    val type = resEvent.split("/").get(3).split("#").get(0)
    val state = resEvent.split("#").get(1)
    logInfo("MQTT", ("Channel triggered Item:" + itemName + " Type:" + type + " State:"+state))
end

[cweitkamp]

May be it is a problem when referencing/migrating config (userdata, conf) from older versions?

Yes, I have the slight feeling that the root cause may be something like that. Why do I have this feeling? I tested a 100% similar rule in three different setups: Running latest code from within the Eclipse IDE, a test environment based on latest snapshot, set-up from scratch and my live environment which I am using since OH2.2 or earlier. In the first two setups it is working without any problem whereas my live environment throws the getEvent() is not a member of ... error the whole time - even after upgrading it to latest milestone OH2.5.M4.

[kaikreuzer]

@cweitkamp How shall we proceed with this issue? If it doesn't occur on setups from scratch, it must be some migration issue, which will be tough to tackle. I honestly have no clue of what could have possibly changed between the versions - the classes of the rule engine are more or less untouched...

[cweitkamp]

@kaikreuzer To be honest: I have no idea what to check next. I tried to compare folders and files in my different setups but was not able to identify the culprit.

I identified a minor issue when injecting parameters into rules multiple time (similar to https://github.com/eclipse/smarthome/pull/5164) and prepared a small fix for it (https://github.com/cweitkamp/openhab-core/commit/94e82a2a8e257689c1c111acfc522557c03c74e3). But again I do not think that this might be related or the cause.

[kaikreuzer]

Do we run the risk that everyone upgrading from 2.4 will have this issue (although the number of users that use this method in rules should hopefully not be too large)? Or is it also only happening on some updates systems, but not all? Any idea on this from your tests? If it doesn't hit all, I would suggest to close the issue and pray 🙏.

[rancor187]

Hallo @kaikreuzer, actually I have no ideo how to go forward from here. I know that I'd like to use and need this feature/function getEvent()

Also I am not quite sure this has something to do with migrations. First time I run into this problem, was from a clean (CentOS + OH 2.4) installation on a non-RaspPi machine.

[cweitkamp]

This can be closed now. The receivedEvent value has been changed to a String now in https://github.com/openhab/openhab-core/pull/1770.