Rule not working after update to 2.5.6-2

Tags: #<Tag:0x00007f616b9a55a0> #<Tag:0x00007f616b9a5488> #<Tag:0x00007f616b9abdd8>

OH 2.5.6-2

Seeing that there have been a lot of changes to the Enocean binding since OH 2.4.0-1, I decided to take the plunge and upgrade to the latest build.
First I noticed that I was getting an error on the loading of my (one and only) JSR223 rule. Apparently I needed to upgrade to the latest libraries. I downloaded the package and installed it in the conf directory. I had to comment that line containing “me.” as before to get rid of that error - same as in the old libraries.

Now my rule load without any error, but it doesn’t do anything. It’s not triggered every 2 minutes as before. PaperUI shows the rule as “idle”, but executing it manually doesn’t do anything either. It was working perfectly before.

This is the timer trigger:

	        TimerTrigger("0 0/2 * * * ?")

Please help! In the meantime I’ll swap in my backup SD card.

Edit: the problem was that the debug log, activated by default before for rules, is not activated by default in the new build. You need to go and activate it by adding a ton of lines to the log configuration file as described in the post cited near the bottom of the post.

Incidentally, I know when the rule is running because it outputs several lines to openhab.log.

What programming language?


The output I used to get from the rule looked like this:

2020-06-23 21:48:00.288 [INFO ] [lesupport.internal.shared.SimpleRule] - |Brink Indoor temperature: 27.1| 

In case that gives any clues.

I suspect posting the entire rule will be required. I haven’t done much with JavaScript using the Helper Libraries so I can’t help much with the specifics but I do know there have been massive changes in the Helper Libraries and the rules engine in general since OH 2.4 two years ago.

It’s pretty straightforward. Incidentally, I get the feeling that everyone is using Jython and that I’m going to make life difficult for myself by using Javascript. The library include is from the old rule (which is the one I can see now because I swapped the cards). I believe the new one was:


The rule:


	    name: "Open/close ventilation bypass in summer",
	    description: "Opens and closes the ventilation bypass as needed in summer",
	    /*Runs every 2 minutes*/
	        TimerTrigger("0 0/2 * * * ?")
	    execute: function( module, input)
	        var itemBrinkOutdoorTemp = getItem("BrinkDataCurrentTemperatureFromOutdoorsSensor4009_ValueAsString");
	        var itemBrinkIndoorTemp = getItem("BrinkDataCurrentTemperatureFromDwelling_ValueAsString");
	        var itemBypassSwitch = getItem('BrinkDataWriteBypassValve6006_ValueAsSwitch');
	        var itemTadoTemperature = getItem('TadoHeating_Temperature');
	        var itemOWMObservationTime = getItem('OWMLocalWeatherAndForecast_Current_ObservationTime');
	        var itemOWMOutdoorTemperature = getItem('OWMLocalWeatherAndForecast_Current_OutdoorTemperature');
	        var nBrinkIndoorTemp = parseFloat(itemBrinkIndoorTemp.state);
	        var nBrinkOutdoorTemp = parseFloat(itemBrinkOutdoorTemp.state);
	        var nTadoIndoorTemp = parseFloat(itemTadoTemperature.state);
	        var nOWMOutdoorTemp = parseFloat(itemOWMOutdoorTemperature.state);
	        var dateOWMObservationTime = new Date(itemOWMObservationTime.state);
	        //logInfo('OWM observation time: ' + itemOWMObservationTime.state);

			// Basic time info
			var nMinuteInMilliseconds = 60*1000; 
			var nHourInMilliseconds = 60*60*1000; 
			var nDayInMilliseconds = 60*60*24*1000; 
	        // Get current date-time
        	var dateNow = new Date();
	        // Compare OWM observation date to current date
	        var nHoursDifference = Math.floor(((dateNow - dateOWMObservationTime) % nDayInMilliseconds) / nHourInMilliseconds);
	        var nMinutesDifference = Math.floor(((dateNow - dateOWMObservationTime) % nDayInMilliseconds) / nMinuteInMilliseconds);        	
	        // If OWM outdoor temp is more than 2 degrees above Brink number, just make it Brink + 2
	        var nOWMAdjustedOutdoorTemp = nOWMOutdoorTemp;
	        if (nOWMOutdoorTemp > nBrinkOutdoorTemp && (nOWMOutdoorTemp - nBrinkOutdoorTemp) > 2)
	        	nOWMAdjustedOutdoorTemp = nBrinkOutdoorTemp + 2;
	        // Work out difference between Brink outdoor temp and OWM temp
	        var nOutdoorTempDiff = Math.abs(nOWMAdjustedOutdoorTemp - nBrinkOutdoorTemp);
	        var nMaxOutdoorTemp = nBrinkOutdoorTemp;
	        // Take larger of OWM/Brink if OWM observation is recent
	        if (nMinutesDifference < (nOutdoorTempDiff * 60))
	       		nMaxOutdoorTemp = Math.max(nOWMAdjustedOutdoorTemp, nBrinkOutdoorTemp);

	        // Show values in log
	        logInfo('Brink Indoor temperature: ' + nBrinkIndoorTemp);
	        logInfo('Brink Outdoor temperature: ' + nBrinkOutdoorTemp);
	        logInfo('Brink Bypass switch state: ' + itemBypassSwitch.state);
	        logInfo('Tado kitchen temperature: ' + nTadoIndoorTemp);
	        logInfo('OWM outdoor temperature: ' + nOWMOutdoorTemp + '; Age of OWM observation in minutes: ' + nMinutesDifference);	        
	        logInfo('Ajusted OWM outdoor temperature: ' + nOWMAdjustedOutdoorTemp);
	        //logInfo('Min Indoor temperature: ' + nMinIndoorTemp);
	        logInfo('Max Outdoor temperature: ' + nMaxOutdoorTemp);
	        // If indoor temperature is higher than the outdoor temp...
	        if (nTadoIndoorTemp > nMaxOutdoorTemp)
	        	// Open the bypass
		        logInfo('Bypass needs to be open');
		        sendCommand(itemBypassSwitch, ON);
	        	// Close the bypass
		        logInfo('Bypass needs to be closed');	        	
		        sendCommand(itemBypassSwitch, OFF);

May be a manifestation of this javascript problem

So, the conclusion is: stick with the old build for now? Is there a more recent one without this problem?

Would I be right in guessing that problems get fixed faster in Jython because that’s what most people are using?

I’m not really invested in anything right now, so I could go the Jython route if it’s going to be easier.

I think an hour and a half from problem report to fix identified is pretty fair.

Oh, is it fixed?
Not a criticism of anybody’s response time. I just observed that 100% of the community libraries were for Jython.

So far as I can see you can work around it with a sertenv

These are clickable links to github issues and patches

I don’t appear to have that line in setenv

I don’t know if it’s related, but in the log, right after the new build boots up, I see this:

2020-06-23 21:34:13.809 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.weatherunderground.internal.handler.WeatherUndergroundBridgeHandler$ ~[?:?]
	at java.util.concurrent.Executors$ ~[?:1.8.0_252]
	at ~[?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201( ~[?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$ [?:1.8.0_252]
	at [?:1.8.0_252]

It seems to refer to WeatherUnderground, which was a failed attempt to connect to that service - but it also mentions scheduling.


I upgraded to, and I had Java exceptions and errors reported of my Python rules upon the first start. I restarted the openhab2 service and all was normal afterward. I don’t know if what I saw is related to your issue, but I thought it worth mentioning.


Thanks. I restarted several times, so I don’t think that’s it.

Jython does indeed have the most support and the largest collection of users here on this forum compared to JavaScript. But there are some JavaScript users around as well.

In the short run, Jython will be easier. In the long run I suspect both will be well supported with examples, helper libraries and such.

I don’t think it’s related as I believe the bindings interact with the scheduler differently from the Timers and cron triggered rules (there is no intermediary). But anything is possible.

Is the above the only cron triggered rule you have and if not, does that rule work? Do Timers work? If these work, the problem isn’t a generic scheduling problem but something with that specific rule.

1 Like

I only have one rule, yep.

When you say timers, do you mean like cron jobs? I have a backup run via a cron job, and that ran at 3am last night as usual.

If there’s a problem with the rule, wouldn’t there be an error in the log?

I’ve removed all the content from the rule, and it still doesn’t do anything:


	    name: "Open/close ventilation bypass in summer",
	    description: "Opens and closes the ventilation bypass as needed in summer",
	    /*Runs every 2 minutes*/
	        TimerTrigger("0 0/2 * * * ?")
	    execute: function( module, input)

I also tried eliminating the log filter that removes the Modbus connection error, in case it was filtering out something it shouldn’t. Same result. The last thing you see in the log is:

2020-06-24 17:29:17.733 [INFO ] [me.core.service.AbstractWatchService] - Loading script 'OpenOrCloseBypass.js'

After that, nothing, except for those filtered-out Modbus connection errors.

Even when I execute the rule from PaperUI, I see “rule executed”, but no output. So it’s not just a timer thing.

Wait a sec… has the required location for rules changed? What’s the path where they need to be placed?