sendNotification not working inside DSL script in a rule

Hi,

I’m struggling to get sendNotification to work inside a DSL script in a rule built using the UI. I’ve created a very simple rule that fires every minute and have added two actions: the first executes a one line script containing the sendNotification command and the second action uses the built-in UI ‘send a notification’ option. Both target the same email address (I’ve double checked this!) I get the message from the UI ‘send a notification’ but not the one from inside the DSL script.

I’m running OH 3.3.0 and recently restarted the cloud Add-on but that hasn’t helped. Here’s what the rule looks like:

And here’s what’s inside the script (email address changed):

sendNotification("myemail@address.com", "Hello world!")

If anyone has any ideas that would be very helpful, thanks!

Same problem several month ago. I had to use pushover, because the my openhanded cloud service seems to be broken.

add a delay between them.
I’m all but certain there is throttling at the endpoint on myopenhab.org and the standard notification services provided by Google and Apple. If you send two notifications within a second I’m not surprised one is dropped.

I think you should still see them listed under the notifications tab at myopenhan.org though I’ve never tried to send notifications this far so could be wrong.

If I remove the UI based notification from the rule altogether (so there’s no overlap issue) then I still don’t receive the one inside the Rules DSL script. In both cases, I see nothing in the openHAB cloud notifications for the ones from the script (the ones from the UI notification action are there though).

Logs?

openhab.log shows nothing - no error message.

Put the logging into debug or trace level and see if you can see it actually trying to send the notification.

Ok, here are the entries from the trace log:

2024-02-12 15:02:00.241 [DEBUG] [o.openhabcloud.internal.CloudService] - Sending message ‘Hello world!’ to user id myemail@address.com
2024-02-12 15:02:00.241 [TRACE] [.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks
2024-02-12 15:02:00.242 [DEBUG] [io.openhabcloud.internal.CloudClient] - No connection, notification is not sent
2024-02-12 15:02:00.242 [INFO ] [org.openhab.core.model.script.Alerts] - Notification sent
2024-02-12 15:02:00.243 [DEBUG] [e.automation.internal.RuleEngineImpl] - The rule ‘afd0b389b6’ is executed.

It says ‘No Connection’ but I’m pretty sure I’m connected (other messages are coming through from other rules - the UI configured ones - and the cloud platform says I’m connected)…

It says “no connection” but then it says “notification sent”. That’s kind of weird.

Can you send a notification from a text file based rule?

Add back in the UI call to send the notification and see if the logs are different.

Ok, I set up the following:

  1. Text file rule in a file called ‘TestNotification.rules’ with the following rule in it:
rule "TestSendNotification"
	when
		Time cron "0 * * * * ? *"
	then
		logInfo("Alerts", "About to send my notification 2")
		sendNotification("myemail@address.com", "Hello World 2!")
		logInfo("Alerts", "My notification 2 sent!")
end
  1. Rule defined in UI as before but with the UI notification set up as well as the DSL script notification as follows:
logInfo("Alerts", "About to send my notification")
sendNotification("myemail@address.com", "Hello world!")
logInfo("Alerts", "My notification sent!")

Note that in the original log I sent, the entry saying ‘notification sent’ came from the logInfo I had added to the script - sorry for the confusion!

Anyway, here are the log entries I get with the above two rules set up:

2024-02-12 16:43:00.206 [DEBUG] [e.automation.internal.RuleEngineImpl] - The trigger '0' of rule 'TestNotification-1' is triggered.
2024-02-12 16:43:00.207 [TRACE] [ore.internal.scheduler.SchedulerImpl] - Scheduled a task to run in 59 seconds.
2024-02-12 16:43:00.208 [DEBUG] [ipt.internal.ScriptEngineManagerImpl] - Added ScriptEngine for language 'application/vnd.openhab.dsl.rule' with identifier: 331718c7-5873-48aa-9306-77fafe330dc3
2024-02-12 16:43:00.209 [TRACE] [internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/rules/TestNotification-1/state, source=RuleEngineImpl, type=RuleStatusInfoEvent, payload={"status":"RUNNING","statusDetail":"NONE"}, timestamp=1707756180208}
2024-02-12 16:43:00.209 [DEBUG] [time.internal.engine.DSLScriptEngine] - Script uses context 'TestNotification-1'.
2024-02-12 16:43:00.210 [TRACE] [automation.internal.RuleEventFactory] - creating ruleEvent of type: RuleStatusInfoEvent
2024-02-12 16:43:00.210 [TRACE] [ab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.metrics.RuleMetric).
2024-02-12 16:43:00.211 [DEBUG] [.monitor.internal.metrics.RuleMetric] - Rule TestNotification-1 RUNNING - updating metric.
2024-02-12 16:43:00.213 [TRACE] [ab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).
2024-02-12 16:43:00.213 [TRACE] [ab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).
2024-02-12 16:43:00.214 [TRACE] [.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks
2024-02-12 16:43:00.214 [TRACE] [internal.events.ThreadedEventHandler] - wait for event
2024-02-12 16:43:00.222 [INFO ] [org.openhab.core.model.script.Alerts] - About to send my notification 2
2024-02-12 16:43:00.223 [DEBUG] [b.io.openhabcloud.NotificationAction] - sending notification 'Hello World 2!' to user myemail@address.com
2024-02-12 16:43:00.223 [DEBUG] [o.openhabcloud.internal.CloudService] - Sending message 'Hello World 2!' to user id myemail@address.com
2024-02-12 16:43:00.224 [DEBUG] [io.openhabcloud.internal.CloudClient] - No connection, notification is not sent
2024-02-12 16:43:00.224 [INFO ] [org.openhab.core.model.script.Alerts] - My notification 2 sent!
2024-02-12 16:43:00.225 [DEBUG] [e.automation.internal.RuleEngineImpl] - The rule 'TestNotification-1' is executed.
2024-02-12 16:43:00.225 [TRACE] [internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/rules/TestNotification-1/state, source=RuleEngineImpl, type=RuleStatusInfoEvent, payload={"status":"IDLE","statusDetail":"NONE"}, timestamp=1707756180225}

2024-02-12 16:43:00.636 [DEBUG] [e.automation.internal.RuleEngineImpl] - The trigger '1' of rule 'afd0b389b6' is triggered.
2024-02-12 16:43:00.636 [TRACE] [ore.internal.scheduler.SchedulerImpl] - Scheduled a task to run in 59 seconds.
2024-02-12 16:43:00.636 [INFO ] [org.openhab.core.model.script.Alerts] - About to send my notification
2024-02-12 16:43:00.637 [TRACE] [internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/rules/afd0b389b6/state, source=RuleEngineImpl, type=RuleStatusInfoEvent, payload={"status":"RUNNING","statusDetail":"NONE"}, timestamp=1707756180636}
2024-02-12 16:43:00.637 [DEBUG] [b.io.openhabcloud.NotificationAction] - sending notification 'Hello world!' to user myemail@address.com
2024-02-12 16:43:00.637 [DEBUG] [o.openhabcloud.internal.CloudService] - Sending message 'Hello world!' to user id myemail@address.com
2024-02-12 16:43:00.637 [TRACE] [automation.internal.RuleEventFactory] - creating ruleEvent of type: RuleStatusInfoEvent
2024-02-12 16:43:00.637 [DEBUG] [io.openhabcloud.internal.CloudClient] - No connection, notification is not sent
2024-02-12 16:43:00.637 [TRACE] [ab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.metrics.RuleMetric).
2024-02-12 16:43:00.638 [TRACE] [ab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).
2024-02-12 16:43:00.638 [DEBUG] [.monitor.internal.metrics.RuleMetric] - Rule afd0b389b6 RUNNING - updating metric.
2024-02-12 16:43:00.638 [INFO ] [org.openhab.core.model.script.Alerts] - My notification sent!
2024-02-12 16:43:00.638 [TRACE] [ab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).
2024-02-12 16:43:00.638 [TRACE] [internal.events.ThreadedEventHandler] - wait for event
2024-02-12 16:43:00.638 [TRACE] [.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks
2024-02-12 16:43:00.638 [DEBUG] [o.openhabcloud.internal.CloudService] - Sending message 'This is a notification from the UI action' to user id myemail@address.com
2024-02-12 16:43:00.639 [DEBUG] [e.automation.internal.RuleEngineImpl] - The rule 'afd0b389b6' is executed.
2024-02-12 16:43:00.641 [TRACE] [internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Eve

The first block of the log shows the text file based rule running. You can see there are two lines in there, one saying ‘sending notification’ and one saying ‘Sending message’, which seems a bit odd. In any case, the next line says no connection as before (then my logInfo line gets inserted).

The second block is for the UI defined rule and it also has the two ‘sending Notification’ and ‘Sending message’ lines and the ‘no connection’ message (all of which I assume relate to the script based action, which is triggered first). Then a few lines later the UI defined message gets sent with a log entry of ‘Sending message’ but not followed with a ‘no connection’ error.

I don’t get any of the notifications from the two script based rules but I do get the one from the UI defined one. I need to use the script based one as I want to include variable text in the message depending on the state of certain items which isn’t possible using the UI defined notification.

Do I need to create a connection of some sort before using the sendNotification command?

Not sure I’m much further along but maybe the above can provide some insight to someone?

The two middle two lines of logging come from the add-on.

One more thing to do. Create a Blockly rule that sends a notification so we can see if it’s just a Rules DSL problem or more pervasive than that.

I suspect it’s a Rules DSL problem as most people are using something else these days (I personally recommend against new development of rules in Rules DSL) so maybe no one has run into it yet.

Yeah, Blockly working just fine.

So if not using Rules DSL then how would you build dynamic text (i.e. based on the state of multiple items) to send as a notification message?

Under the “Text” category you’ll find a block that looks like this:

image

Click the gear and you can add “items” creating slots to append as many Strings together as you need.

Still do file the issue on openhab-core (I think) though. Link to this thread and make it clear that sendNotification appears to fail for Rules DSL but appears to work everywhere else.

Just to say that sendNotification in DSL rule is still working as expected for me. So not a general problem.

Same here, working fine in Rules DSL.

Ok, will log the issue but wonder if it’s worth checking my setup in case there’s something obvious that could be causing an issue:

  • openhab 3.3.0
  • running in a Docker container on a Synology (DSM 6.2.4-25556)
  • PiHole running on network but issue still persists when it’s disabled
  • Openhab app is on an android phone (but still not seeing notifications on the Web page)

Anything else that could be affecting it?

Email address must be registered in the myopenhab cloud if you are not using the initial address.

Yeah, it is - I don’t think the Blockly and UI based rules would work if it wasn’t.

Ok, I’ve raised it as a bug on Github in openhab-core; here’s the link for anyone looking in the future:

I don’t think it makes sense to report a bug if you’re on OH 3.3, since people using OH 4 are saying it works properly. I’m on 4.1.1 and have DSL notifications that trigger every day without issue. I was on OH 3.4 until just a few months ago, and don’t recall any issues there.

I’d suggest that you try upgrading to 4.1 (even if it’s just a test), to see if the problem persists.