Thank you for your code snippet. Unfortunately, any attempt to use receivedEvent.getEvent results in an error message like this:
2019-09-29 18:44:08.405 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'myrule': 'getEvent' is not a member of 'org.eclipse.smarthome.core.thing.events.ChannelTriggeredEvent'; line 61, column 28, length 24
this works properly, for both Triggers, came up at that moment. Very mysterious.
I have to say that I only tried the Astro-Binding. But I can’t believe that this Binding-specific.
Edit: Just saw in your other post, that you use it in this way
var String ButtonEvent = receivedEvent.getEvent()
Have you tried it in this way:
var ButtonEvent = receivedEvent.getEvent()
or
val ButtonEvent = receivedEvent.getEvent()
The statement itself fails independent of the declaration. As far as I can judge @cweitkamp, @maggu2810 and @rancor187 have been investigating the issue but there is no activity in that Github issue since end of July.
This issue is frustrating me too. And I have a personal interest in solving it. I will raise its priority on my to-do list and try to do some more research in the next couple of days. Hope to get this fixed soon.
I am still not finished with the wireing of the distribution box (Homematic IP Wired components). Takes longer than expected. Hope I am done with it tomorrow evening.
I maybe have a trace: I did some tests on three different systems. On two of them - running from Eclipse IDE with latest code base and a test environment OH2.5.S1706 - it was working fine and on the third one - my live environment (OH2.5.M3) - it always has thrown the above error. The main difference beside OH versions on those systems was that I NGRE (Rule Engine (Experimental)) has been installed in both systems where it is working and not in my live environment. Can anyone confirm this?
Unfortunately not. I have installed the Rule Engine (Experimental) and restarted the OH service but no difference (2.5.0 M3). The error message is still the same.
May be this helps to find the issue. I think its in channel code.
I have a similar issue with the MQTT binding. (openhab-2.5.0-M3)
I’ve created a Channel through PaperUI under a MQTT Broker Thing.
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:
[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.
Hi all,
For those who are trying to deal with a Hue dimmer switch and suffering from this issue, I observed in the Hue binding documentation an alternative way to characterise the event generated by the dimmer switch, which does not require using the misfunctionning getEvent() call.
The only drawback is that it requires writing several rules (one per type of event you want to handle) instead of one single rule with different action based on the content of getEvent().
So instead of:
rule "Turn Lights On"
when
Channel "hue:0820:00178828911b:2:dimmer_switch_event" triggered
then
switch(receivedEvent.getEvent()) {
case "1002.0": {
callScript("Lights_Max_Level.script")}
case "2002.0": {
callScript("Lights_Mid_Level.script")}
}
end
I suggest:
rule "Turn Lights On Max level"
when
Channel "hue:0820:00178828911b:2:dimmer_switch_event" triggered 1002.0
then
callScript("Lights_Max_Level.script")
end
rule "Turn Lights On Mid level"
when
Channel "hue:0820:00178828911b:2:dimmer_switch_event" triggered 2002.0
then
callScript("Lights_Mid_Level.script")
end
welcome to the openHAB community and thank you for your posting!
Yes, exactly! If you want to evaluate all possible combinations of those 4 buttons with 4 states each (see Philips Hue Binding Trigger Channels), you would have to write 16 (!) rules with almost the same code. This is not really an option as there is the getEvent() function that is supposed to work. I would prefer the latter to avoid confusing duplicated code which is difficult to maintain.
thank you for your workaround it took me at least a bit further.
i´m not sure if that helps anyone to actually solve the issue but i found it wired enough to document what i found.
to avoid having to much code copied like miba pointed out i tried to create handlers for all buttonevents and redirecting these to my original handler that i altered to be a function.
Unfortunatly this didn´t resolve the issue for me but showed that any call deeper in the callstack would fail, so the issue is not realy related to getEvent or ChannelTriggeredEvent
surprisingly the call to remoteNum.toString() works in the handler it self but wouldn´t work in myBadTriggerHandler.
[ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule ‘genericRemote8_1002’: cannot invoke method public java.lang.String java.lang.Integer.toString() on null
also the call to myBadTriggerSubHandler failes
[ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule ‘genericRemote8_1002’: cannot invoke method public abstract void org.eclipse.xtext.xbase.lib.Procedures$Procedure0.apply() on null
var remoteNum = 8
rule "genericRemote8_1002"
when
Channel "deconz:switch:e12c892c:90fd9ffffe0579c6011000:buttonevent" triggered 1002
then
logInfo("Remote #"+remoteNum.toString()+" tripped", "1002")
myBadTriggerHandler.apply("center short")
logInfo("Remote #"+remoteNum.toString()+" completed", "1002")
end
var myBadTriggerHandler = [String actionName|
logInfo("myBadTriggerHandler triggered", actionName)
myBadTriggerSubHandler.apply()
logInfo("Remote #"+remoteNum.toString(), "actionName")
logInfo("myBadTriggerHandler triggered again", actionName)
]
var myBadTriggerSubHandler = [|
logInfo("myBadTriggerSubHandler triggered", "")
logInfo("Remote #"+remoteNum.toString(), "actionName")
logInfo("myBadTriggerSubHandler triggered again", "")
]
I hope this helps anyone to find a fix as my girlfriend startet using our wallswitches again and no one can want that to happen…
I want to check on the status here. I also found those 2 threads mentioned above marked as [SOLVED]. Event this [WORKAROUND] here has no real solution.
What I could say: The problem still persist. I see this with the Shelly binding, already on my old RPI3 setup with 2.5.2 and now also with my new setup based on 2.5.7. This means
problem is not solved
not dedicated to a specific OH release
not dedicated to a specific binding
rule engine doesn’t matter
The Shelly binding provides 7 different alarm event types. So having 7 rule duplicates for each group of devices is no option.
This is an essential feature from my point of view. It WOULD make the alarm handling for my devices very compact, but having a rule per event type is no option.
@markus7017 Thanks for the reminder. But I am afraid I did not find a solution for it. I focused to migrate my own rules to new rule engine (JSR322 Jython). In my testings I was not able to reproduce similar issues like these with NGRE.